Re: Framework Last Call

["XiPeng" <xiaoxipe@cse.msu.edu>]

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
> 
> 
>