The MPLS WG Archive

[Vishal Sharma <Vishal.Sharma@tellabs.com>]

Dave,

I see your point, and the distinction could make things clearer.
Related to this train of thought, I'd like to point out the following.

You say that an LSP is p2p, and may be overlaid on a tree. There are
actually two cases here:

(i) A true multipoint-to-point LSP, which means traffic labeled with distinct
incoming labels on the ingress links is assigned the same label (one
label) on the egress link. In this case, the LSP and the tree it is overlaid
on are isomorphic.

(ii) A collection of p2p LSPs, all of which terminate at the same destination,
and happen to share a route from some point on (we call such LSPs
"virtually merged" (a term one of my co-authors came up with)). In this
case, any given LSP is overlaid upon a portion of the tree (where the "tree"
is an abstract entity consisting of all the links that all of these LSPs traverse).

In our mechanism draft, we were initially thinking only of (i), so we
though we did not need the distinction between the LSP and the tree (we know now
that (ii) is equally easily covered by our mechanism). Our thinking was that, depending 
on where the fault was, either all sources (more precisely PSLs) or some
of subset them would switch to a backup path (after the affected PSLs
were notified of the fault).

I realize now that there is a problem with the above reasoning as well, since,
for some types of faults, only a portion of the (point-to-multipoint) LSP could be switched 
to a protection path, and we did not have terminology to make this clear.

About the retrofitting... I guess we'd need to do that in the upcoming revision. If you
see some issues with doing that, please let us know.

-Vishal
On Friday, June 02, 2000 12:50 PM, dallan@nortelnetworks.com [SMTP:dallan@nortelnetworks.com] wrote:
> 	Vishal:
> 
> 	One additional comment that I will throw out is that I cannot
> distinguish in MPLS terminology between an LSP and the tree which it is
> overlaid upon (I  see interchangable references in a number of documents). 
> 
> 	I think it would be worthwhile making the explicit distinction
> between an label switched tree (LST) and label switched path (LSP) (which is
> these days is a unidirectional p2p path which may be overlaid on a merged
> tree). So when we discuss restoration, we can distinguish between specific
> per LSP strategies and dealing with the LST. I know much discussion on this
> draft and others could have gone faster with this explicit distinction.
> Re-routing, or having pre-planned fail over strategies for an LSP then would
> have a distinct meaning.
> 
> 	If we agree to this distinction, then next question is how do we
> retrofit it ?....;-)
> 
> 	cheers
> 	Dave