[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Framework Last Call
Waisum, Xipeng,
If the framework was to incorporate Waisum's proposed paragraph below, then
I suggest:
- turning "an alternative is" into something like "a potential
alternative may be",
- identifying the trade-offs of the potential alternative solution
(e.g. - if I understand correctly- increased signaling)
Cheers
Francois
At 15:40 21/05/2001 -0400, Lai, Wai S (Waisum), ALSVC wrote:
>XiPeng,
> Thanks for the following message. While a full discussion
>may be out of scope, a couple of sentences may give the reader
>a feel for the issues involved:
>"Propagation of class-type information via IGP LSAs may cause
>scalability concerns. An alternative is to use reservation
>feedback signaling in conjunction with measurement-based
>admission control."
>Any support for including this in the Framework?
>Thanks, Waisum.
>
>-----Original Message-----
>From: XiPeng [mailto:xiaoxipe@cse.msu.edu]
>Sent: Saturday, May 19, 2001 12:47 PM
>To: Lai, Wai S (Waisum), ALSVC; te-wg@ops.ietf.org
>Cc: angela.chiu@celion.com
>Subject: Re: Framework Last Call
>
>
>Waisum,
>
>Thanks for your comments! We (the co-authors) will quickly
>address the issue you raised.
>
>Regarding "We could also include a discussion of propagation
>via IGP LSAs versus other methods", you don't mean
>discussion in the TE framework draft, right? I don't think
>such a discussion belong to the framework draft.
>
>Thanks,
>
>XiPeng
>
> > On p. 52 of the new -04.txt version of the Framework document,
> > there is the paragraph:
> >
> > Performing traffic engineering on a per class basis requires certain
> > per-class parameters to be propagated via IGP link state
> > advertisements (LSAs). Note that it is common to have some classes to
> > share some aggregate constraint (e.g. maximum bandwidth requirement)
> > without enforcing the constraint on each individual class. These
> > classes then can be grouped into a class-type and per-class-type
> > parameters can be propagated instead to improve the scalability of
> > IGP LSAs. It also allows better bandwidth sharing between classes in
> > the same class-type.
> >
> > In Jim Boyle's comments on draft-ietf-mpls-diff-te-ext-01.txt, March 19,
> > 2001,
> > there is the requirement:
> >
> > -Scalability. Absolutely minimize the amount of information
> > propagation, storage, processing for routing and signalling given
> > a network with given Diffserv requirements. Large networks
> > shouldn't melt down because they carry 8 times more information
> > than they need to, small, tailored networks shouldn't be hampered
> > by arbitrary constraints on things like Class Types.
> >
> > Further, Jerry Ash and I have made the following comments to the
> > authors of draft-ietf-tewg-diff-te-reqts-00.txt:
> >
> > The draft describes complex IGP extensions of per-class-type
> > link-state advertisements (LSA) to communicate per-class-type
> > available bandwidth, etc. It already gets so complex that the
> > draft proposes to compress the advertisements. This needs to
> > be simplified, or eliminated, and the following requirement is
>proposed:
> >
> > No new LSAs should be used to signal per-class-type available
> > bandwidth, maximum bandwidth, preemption parameters, etc. Rather,
> > class-type-bandwidth should be allocated and protected by mechanisms
> > that do not require new per-class-type LSAs. Such mechanisms include
> > a combination of measurement-based admission control at ingress LSRs
> > (label-switched routers) and reservation feedback signaling at transit
> > LSRs.
> >
> > Hence there are other ways to distribute class-type information,
> > instead of through IGP LSAs. Based on this, I would suggest simplifying
> > the above paragraph in the Framework document as:
> >
> > Performing traffic engineering on a per class basis may require certain
> > per-class parameters to be distributed. Note that it is common to have
> > some classes to
> > share some aggregate constraint (e.g. maximum bandwidth requirement)
> > without enforcing the constraint on each individual class. These
> > classes then can be grouped into a class-type and per-class-type
> > parameters can be distributed instead to improve scalability.
> > It also allows better bandwidth sharing between classes in
> > the same class-type.
> >
> > We could also include a discussion of propagation via IGP LSAs versus
> > other methods. What do others think?
> >
> > Thanks, Wai Sum.
> >
> > -----Original Message-----
> > From: Jim Boyle [mailto:jboyle@Level3.net]
> > Sent: Monday, May 14, 2001 9:40 PM
> > To: te-wg@ops.ietf.org
> > Subject: Framework Last Call
> >
> >
> >
> > This message starts a last call on our working group framework document,
> > for which the most recent version is:
> >
> > draft-ietf-tewg-framework-04.txt
> >
> > Last call will end May 29th, after which the authors will turn it around
> > for IESG review.
> >
> > As you'll recall, a previous version of this draft underwent last call
> > several months ago, however comments were not incorporated in a timely
> > fashion. Once updated, the changes were significant enough to warrant
>this
> > (additional) last call.
> >
> > regards,
> >
> > Jim
> >
> >
> >
PLEASE NOTE NEW CONTACT DETAILS - See below
_________________________________________________________________
Francois Le Faucheur
Development Engineer, IOS Layer 3 Services
Cisco Systems
Office Phone: +33 4 97 23 26 19
Mobile : +33 6 89 108 159
Fax: +33 4 97 23 26 26
Email: flefauch@cisco.com
_________________________________________________________________
Cisco Systems Europe
Domaine Green Side
400, Avenue de Roumanille
Bātiment T3
06 410 BIOT
SOPHIA ANTIPOLIS
FRANCE
_________________________________________________________________