[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: WG last call: draft-ietf-tewg-diff-te-reqts-04.txt
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?
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. The text in the draft
should also clearly say the purpose of these default BC
models.
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.
-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 _________________________________________________________
>
>