The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

Title: RE: draft-chang-mpls-path-protection Comments

Vishal:

I was thinking of decomposing (i). There needs to be a way to discuss the constituent tributaries in what you call a "true multi-point LSP". The abstract entity you refer to in (ii) would seem to be more akin to an I.630 VP/CG where a group of LSPs shares a common OAM trail (and which I think doing that in a signalled fashion is somewhat intractable), this is a bit different, in that they not only would share a trail, but label forwarding space.

If I adopt the LST/LSP distinction for (i) then....

My motivation is that a failure in an LST (a.k.a. (i)) does not require that all constituent LSPs switch, only those upstream of the failure. Most would be unaffected and it would be desirable to leave them alone from the point of view of network stability (if it aint broke....). Those that were affected by the failure do not require a strategy that is in any way coordinated with the other failed or still working LSPs as the natual LST grouping really has no meaning once that particular topology configuration has failed (the LSP/LST linkage broke). Currently this is difficult to discuss clearly. That is what I would like to address...

regards
Dave

-----Original Message-----
<snip>
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