[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Framework Last Call
Waisum, Francois,
Thank you for the suggestion. I would assume that the tradeoff has been
discussed in the document where the alternative (i.e. using reservation
feedback signaling in conjuction with measurement-based admission control)
is first introduced. So if we were to mention this alternative in the
draft, we will simply refer the readers to that document on the tradeoff.
And if the tradeoff has not been discussed in that document, it should.
If I understand Francois right, he didn't mean that he supports
mentioning the alternative ("If the framework was to ...", please correct
me if I didn't understand you correctly, Francois).
I would like to see definite support for mentioning the alternative
before doing so.
Thanks,
XiPeng
>
> 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
> _________________________________________________________________
>