[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: WG last call: draft-ietf-tewg-diff-te-reqts-04.txt
Sudhakar,
At 11:52 07/06/2002 -0400, Sudhakar Ganti wrote:
>Francois,
>
>If I understand correctly, a default BC model is
>enforced so that a service provider atleast
>can choose the default model as a "common" model across
>different vendor boxes. Is that correct?
yes.
>If so, there should be a finite set of models that must
>be common across different boxes rather than mandating
>one. What if the service provider does not believe in
>the default model and other models are not implemented?
>Therefore, the specification need to suport two or three
>common BC models such as Max Allocation (complete
>partitioning) and Russian Doll model (partial sharing)
>and any other in the "common" set.
I am not opposed to specifying more than one model. But my recommendation
is for:
- mandating one
- optionally allowing others
I feel we could close on one default model faster than if we try to close
on all/multiple models.
Also, some BC models may require additional extensions, so this could delay
specification of the base protocol extensions.
As usual, I would prefer to specify something relatively simple first so we
get more implementations/experience before trying specifying an all
emcompassing solution.
>The text in the draft
>should also clearly say the purpose of these default BC
>models.
There is some reasonable text that explains why one default model should be
used. If you feel you can suggest specific text which would be clearer,
please do so.
>On the other hand, a default model is mandated because
>the DS-TE solution does not work without a uniform BC model
>across the whole domain, that may take flexibility away.
>Irrespective of the BC model mix in the network, the
>DS-TE solution must work.
Do we know Service Providers who have a requirement for supporting multiple
BC models in a given network?
Personnaly, I haven't heard any yet. (Frankly I think DS-TE is
sophisticated enough with a single BC model at any one time, I don't see
the point for such complexity)
So as per my earlier email:
- let's make sure we make it work with one single BC model
- let's allow BC model mix *IFF* it doesn't cost us anything in
terms of complexity, but let's not make the spec more complicated for
something which is not required -at least now-.
Cheers
Francois
>-Sudhakar
>
> > -----Original Message-----
> > From: Francois Le Faucheur [mailto:flefauch@cisco.com]
> > Sent: Thursday, June 06, 2002 12:59 PM
> > To: Indra Widjaja
> > Cc: Sudhakar Ganti; Jim Boyle; te-wg@ops.ietf.org
> > Subject: Re: WG last call: draft-ietf-tewg-diff-te-reqts-04.txt
> >
> >
> > 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 _________________________________________________________
> >
> >