[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Framework Last Call



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