[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Framework Last Call
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
>
>
>