Re: WG last call: draft-ietf-tewg-diff-te-reqts-04.txt

[Francois Le Faucheur <flefauch@cisco.com>]

Indra, Ganti,

I don't believe the current text nor the new proposed text actually exclude 
the possibility of running different BC models in a given network, if a 
particulat Service Provider wanted to do that for some reason.
What we are on about, is to avoid SPs being forced to deal with multiple 
BCs, when most (if not all) of them probably don't want that.

Assumption 1: We do not mandate a default model.
Then, Vendor A comes out with a superb DS-TE implementation supporting 
Russian Doll model, Vendor B with a wonderful implementation supporting 
Separate Constraint model and Vendor C with a magnificent implementation 
supporting this Super Sophisticated BC model for which his developper just 
did a PhD on.
Practically speaking, Mr Network Administrator would only have two real 
options:
         - pick only one of these vendors and deploy DS-TE
         - deploy multiple vendors' equipment but forget about DS-TE 
because you have to configure different DS-TE parameters on differnet LSRs 
and have differnet BC capabilities on different LSRs (ie this one can limit 
this but not that).
That doesn't seem like the best avenue to promote practical DS-TE 
interoperability.

Assumption 2: We do mandate a default BC model.
Then, Vendor A comes out with a superb DS-TE implementation supporting 
Default model, Vendor B with a wonderful implementation supporting Default 
Model and Vendor C with a magnificent implementation supporting Default 
Model AND this super sophisticated BC model for which his developper just 
did a PhD on.
Practically speaking, Mr Network Administrator would have many options:
         - deploy one or multiple vendors' equipment and deploy DS-TE with 
Default BC model (with same DS-TE parameters on all LSRs and same BC 
capabilities on all LSRs ( and live happily forever)
         - try vendor C's super sophisticated model in a lab.
         - if the SP likes interesting stuff, deploy multiple vendors' 
equipment and deploy DS-TE with Default BC model on Vendor A and vendor B 
LSRs and start playing with super sophisticated BC model on vendor C LSRs 
and see what happens.
         - put pressure on vendor A and B to implement super sophisticated 
model because it is proven to work well , and then deploy multiple vendors 
equipment all with super sophisticated BC model.
         - pick only vendor C and deploy super sophisticated BC model 
everywhere
Does this not seem more like promoting interoperable DS-TE deployment?

Cheers

Francois


At 17:32 05/06/2002 -0500, Indra Widjaja wrote:
>Sudhakar Ganti wrote:
> >
> > Jim,
> >
> > Unless the document defines what exactly is a "consistent
> > behavior" across multiple implementations and discusses
> > what are the implications of not having a default model,
> > the requirements document should not mandate that a default
> > model (whatever that is) must be supported by any DS-TE
> > implementation.
>
>I'd like to echo Sudhakar's concern in that the whole picture
>of BC models seems not fully understood yet.
>Wouldn't it be possible to have multiple BC models in a domain
>and let an LSR optimize its individual LSP depending on whether
>bandwidth sharing or isolation is more important? Would this
>so-called "inconsistency" have adverse effect on the network
>efficiency or some other factors?
>
>indra
>
> >
> > -Sudhakar
> >
> > > > The DS-TE technical solution must specify one
> > > > default bandwidth constraint model which must be supported by any
> > > > DS-TE implementation.  Having a default bandwidth constraint model
> > > > allows for the network administrator to have at least one
> > > consistent
> > > > behavior when working with multiple implementations of DS-TE.
> > > > Additional bandwidth constraint models may also be
> > > specified. In the
> > > > selection of a default model, at least the following
> > > criteria must be
> > > > considered:
> > > > (1) addresses the scenarios in Section 2
> > > > (2) works well under both normal and overload conditions
> > > > (3) applies equally when preemption is either enabled or disabled
> > > > (4) minimizes signaling load processing requirements


_________________________________________________________
Francois Le Faucheur
Development Engineer, IOS Layer 3 Services
Cisco Systems
Office Phone:          +33 4 97 23 26 19
Mobile :               +33 6 19 98 50 90
Fax:                   +33 4 97 23 26 26
Email:                 flefauch@cisco.com
_________________________________________________________
Cisco Systems
Domaine Green Side
400, Avenue de Roumanille
06 410  Biot - Sophia Antipolis
FRANCE
_________________________________________________________