[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Framework Last Call
- To: te-wg@ops.ietf.org
- Subject: RE: Framework Last Call
- From: "Lai, Wai S (Waisum), ALSVC" <wlai@att.com>
- Date: Fri, 18 May 2001 11:28:04 -0400
- Delivery-date: Sat, 19 May 2001 16:04:25 -0700
- Envelope-to: te-wg-data@psg.com
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.
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