The MPLS WG Archive

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

Dave,

On Friday, June 02, 2000 2:09 PM, dallan@nortelnetworks.com [SMTP:dallan@nortelnetworks.com] wrote:
> 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.

I see your point regarding (i), and agree that the additional terminology will
make it possible to talk of the tributaries separately from the LST.
I am not so sure about not being able to signal the virtually merged LSPs,
however, since we are in the process of writing a draft that extends 
RSVP-TE for path protection, and addresses the virtually merged LSP
case. (We'll send you a copy in a few days, once it's finalized, and would
appreciate your feedback. Perhaps, we have overlooked something.)

> 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...

I agree. In fact,  spirit of our description also was the same, but we didn't get
the terminology pinned precisely.  I think adding this distinction will address your 
concern, and make it easier to refer to things unambiguously. In fact, I'd invite you to send
us some suggested text to add to our draft to take care of this, which we'll be happy
to include that our the revision.

-Vishal


> > -----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
> > 
> > 
>  << File: ATT00012.html >>