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).
From: Kireeti Kompella [mailto:email@example.com]
Sent: Monday, March 03, 2003 17:40
To: Shew, Stephen [SKY:Q850:EXCH]
Cc: Jonathan Sadler; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org
Subject: RE: Last Call: Routing Extensions in Support of Generalized MPLS vto Proposed Standard
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.