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

From: "David Allan" <[email-masked]>
Date: Fri, 2 Jun 2000 12:49:58 -0400

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

---

From: Vishal Sharma <[email-masked]>
Date: Fri, 2 Jun 2000 13:47:57 -0400

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

---

From: "David Allan" <[email-masked]>
Date: Fri, 2 Jun 2000 13:09:04 -0500

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

---

From: Vishal Sharma <[email-masked]>
Date: Fri, 2 Jun 2000 16:19:52 -0400

Dave,

> different, in that they not only would share a trail, but label forwarding

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

> 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

>  << File: ATT00012.html >>

---

From: "David Allan" <[email-masked]>
Date: Tue, 6 Jun 2000 13:34:15 -0500

I think I need to back this distinction up into the framework draft rather
than introducing it into the path-protection document. I'd rather get
agreement there first.

Dave

> From:	Vishal Sharma [SMTP:[email-masked]]
	<snip>