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

[Indra Widjaja <iwidjaja@research.bell-labs.com>]

Francois:

Francois Le Faucheur wrote:
> 
> 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.

Just for a clarification, are you saying that a "uniform BC model" 
(i.e., all LSRs use the same BC) is not required in a given network?
or are you saying that a different BC model may be used in a given
network as long as the BC is the same for all LSRs?

indra


> 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
> _________________________________________________________