[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG last call: draft-ietf-tewg-diff-te-reqts-04.txt
Indra,
At 14:54 06/06/2002 -0500, Indra Widjaja wrote:
>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?
I'm saying:
- I expect SPs will want to run a single BC model throughout their
DS-TE domain
- thus, I feel we ought to ensure that all implementations have
one BC model in common
- while I don't expect it will be commonly used in practise, I
don't see a need to exclude running multiple BC models in a given network.
In such situations, it must be understood that overall behaviour may be
hard to predict and some features will simply not be possible at all (e.g.
optimisation by head-end in the case of multiple LSP path computation). I
don't think we should go out of our way to change the spec to allow this,
but conversely I don't see a need to exclude it.
Francois
>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 confiure 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
> > _________________________________________________________
_________________________________________________________
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
_________________________________________________________