Subject: RE: Last Call: Routing Extensions in Support of Generalized MPLS vto Proposed Standard

From: Kireeti Kompella <[email-masked]>
Date: Tue, 4 Mar 2003 09:51:39 -0800 (PST)

Hi Stephen,

On Tue, 4 Mar 2003, Stephen Shew wrote:

> Kireeti, I can provide text but I need about a day to think about it and
> write it succinctly.

That's plenty quick.

> On the matter of the limitations of bandwidth value, I
> can live with your suggestions (a) and (b).

Great!

Kireeti.

---

From: "Stephen Shew" <[email-masked]>
Date: Tue, 4 Mar 2003 10:33:04 -0500

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:[email-masked]] 
Sent: Monday, March 03, 2003 17:40
To: Shew, Stephen [SKY:Q850:EXCH]
Cc: Jonathan Sadler; [email-masked]; [email-masked]; [email-masked]
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.