RE: Framework Last Call

["Ash, Gerald R (Jerry)" <gash@att.com>]

XiPeng,

I read Francois' comments below as supporting the text Wai Sum proposed,
with some proposed wording changes.

Right now the only document I know of which discusses the alternative
(reservation feedback signaling in conjunction with measurement-based
admission control) is

[ASH3] J. Ash, "TE & QoS Methods for IP-, ATM-, & TDM-Based Networks," Work
in Progress, Mar. 2001.

This I-D is already referenced in the TE framework and could be referenced
again.  

The tradeoff discussed is signaling, as Francois correctly points out.

Jerry Ash
AT&T Labs

-----Original Message-----
From: Xipeng Xiao [mailto:xiaoxipe@cse.msu.edu]
Sent: Tuesday, May 22, 2001 1:49 PM
To: flefauch@cisco.com
Cc: Lai, Wai S (Waisum), ALSVC; xiaoxipe@cse.msu.edu;
te-wg@ops.ietf.org; angela.chiu@celion.com
Subject: 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