Subject: Re: LSP hierarchy comments

From: Kireeti Kompella <[email-masked]>
Date: Thu, 13 Jul 2000 10:24:23 -0700 (PDT)

Hi Olle,

> The Link Mux Capability TLV: 
> 
> - is it flexible enough to allow more integrated nodes? How should one
> describe a network element that can switch both wavelengths, TDM channels,
> and packets, on the same interface?  As having multiple capability values
> (using sub-TLVs?), or as being a cluster of nodes and links with different
> capabilites? 

Are there interfaces that can switch wavelengths, TDM channels AND
packets?  We don't cater to these (yet), as we are not aware of such
interfaces.

[...]

> - which value should we use for IP routers that do not understand MPLS?
> PCS-0? 

Routers that don't understand MPLS should not be advertising TE links.

> - more important, could there be any problems with having the LSRs advertise
> the capabilities of other nodes, instead of having each router advertise its
> own capabilities? The words "coordinated configuration" can easily make an
> operator think about "manual" and "errors".  

True.  We MAY do something about this.

> - a small comment on terminology: In section 4.3.1-2 "link type" means
> having certain "Link Mux Capabilities". But in 4.1.1 "link type" is a
> parameter that is set to "point-to-point".  

There are several places that should say Link Mux Capability, not type.
Thanks for pointing this out; these will be fixed in the next revision.

> - To correctly advertise an FA-LSP, one must identify the "tail end", and
> know which is the "last link". Could there be any problems to agree where
> the LSP ends, if PHP is used at the far end? 

No.  Signalling (RSVP/CR-LDP) is always absolutely clear where an LSP
ends.  Where labels end is irrelevant.

> Signalling aspects: 
> 
> - The routing aspects cover both ISIS and OSPF, but all the signalling
> examples are for RSVP-TE only. Would there be any principal differences if
> LDP was used instead?  

LDP doesn't fit the bill.  Perhaps you mean CR-LDP; we say how both
RSVP and CR-LDP can be used.

> - It is stated that an FA-LSP can be torn down by the LSR at the head-end.
> But more generally, any LSP can be closed by any LSR along its path, for
> reasons that we may not always know, can't it?  The expectations on the
> head-end LSR seems to be that it withdraws the FA-LSP from being advertised,
> and that it tries to save the tunneled LSPs.  

Yes.

Thanks for your comments!

Kireeti.

---

From: Olle Pers <[email-masked]>
Date: Fri, 14 Jul 2000 17:42:04 +0200

Hi Kireeti, 

* 
*  Are there interfaces that can switch wavelengths, TDM channels AND
*  packets?  We don't cater to these (yet), as we are not aware of such
*  interfaces.
* 
*  [...]

I haven't seen any such things, yet. I intended to ask whether this simple
attribute can handle more complex capabilities than the ones described, if
and when such capabilities would emerge in the future. 

(For example, I could imagine a device where the wavelengths on an incoming
fiber are being lambda switched, either directly to utgoing fibers, or
internally to another circuit board within the same box, where the lambda
paths are terminated and their content is TDM switched. If such a device
would like to appear as a single node to its routing neighbors, which link
mux capability should be advertised for that incoming fiber link?)  

* 
*  > - which value should we use for IP routers that do not understand MPLS?
*  > PCS-0?
* 
*  Routers that don't understand MPLS should not be advertising
*  TE links.
*  

The current draft says that the new attribute is "Associated with each link
(including forwarding adjacencies)", and I guessed that meant all links in
the ISIS/OSPF area.

I understand the use of this attribute is to determine "regions" where LSPs
of the same "level" are possible. This way an LSR at the edge of such a
region can find which node is at the other edge of the region, and correctly
set the tunnel endpoint address in the RSVP message.  
This seems applicable to packet-switched LSPs as well. The LSRs should
somehow be able to know where the MPLS-domain ends. They cannot always
assume that it covers the entire ISIS/OSPF area. (Maybe there is already
some applicable TLV defined for this, that I am not aware of. Or maybe just
the lack of a LMC TLV would be sufficient to identify a link as non-MPLS
capable.)    

*  > - more important, could there be any problems with having the LSRs
advertise
*  > the capabilities of other nodes, instead of having each router
advertise its
*  > own capabilities? The words "coordinated configuration" can easily make
an
*  > operator think about "manual" and "errors". 
* 
*  True.  We MAY do something about this.

Fine. 

*  > - To correctly advertise an FA-LSP, one must identify the "tail end",
and
*  > know which is the "last link". Could there be any problems to agree
where
*  > the LSP ends, if PHP is used at the far end?
* 
*  No.  Signalling (RSVP/CR-LDP) is always absolutely clear where an LSP
*  ends.  Where labels end is irrelevant.
* 

Fine. 

*  > - The routing aspects cover both ISIS and OSPF, but all the signalling
*  > examples are for RSVP-TE only. Would there be any principal differences
if
*  > LDP was used instead? 
* 
*  LDP doesn't fit the bill.  Perhaps you mean CR-LDP; we say how both
*  RSVP and CR-LDP can be used.
* 

Yes, I meant CR-LDP. It was mentioned in the overview section, but never
again in the rest of the draft.

* 
*  Thanks for your comments!
* 
*  Kireeti.
*  

Thanks. 

Olle