Kireeti, I can provide text but I need about a day to think about it and
write it succinctly. On the matter of the limitations of bandwidth value, I
can live with your suggestions (a) and (b).
-----Original Message-----
From: Kireeti Kompella [mailto:kireeti(_at_)juniper(_dot_)net]
Sent: Monday, March 03, 2003 17:40
To: Shew, Stephen [SKY:Q850:EXCH]
Cc: Jonathan Sadler; iesg(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org;
ccamp(_at_)ops(_dot_)ietf(_dot_)org
Subject: RE: Last Call: Routing Extensions in Support of Generalized MPLS
vto Proposed Standard
Hi Stephen,
On Mon, 3 Mar 2003, Stephen Shew wrote:
I don't know if the pun was intended, but I do like Kireeti's comment
about "bring them to light".
You're laser sharp, Stephen! :-)
Undoubtedly, this would be within the ITU-T (wavelength) grid! ;-)
After the discussions we've had, I wouldn't dare not comply.
There is, I think, some commonality in the comments and the reply in
that the intent is to generalize the extensions needed for routing to
accomodate non-PSC resources. I agree with the first 4 points that
Jonathan made in that I think layer information must be included in
routing so that important functions can be performed.
Okay. Can you provide text?
I believe that the use of one or two bandwidth
values was motivated by the desire to use a "lowest common
denominator" attribute to generalize on path computation and avoid
extensive details of links. Unfortunately, this can obscure variable
adaptation on a link and the ability to determine a path at a
particular adaptation (e.g., VC-3).
You're right on both counts (about LCD, and about obscuring info). The
thinking was (a) let's see how far we can get with just the LCD;
(b) as we learn more, we can incorporate them, ideally in the SDH routing
doc.
Thoughts?
Kireeti.