Subject: [mpls] Comments/Questions on the p2mp shared protection draft

From: Yaacov Weingarten <[email-masked]>
Date: Thu, 15 Mar 2012 15:43:26 +0200

Hi, authors

I have read your draft and find that I have quite a few questions and
comments about the proposals in the draft and the presentation:

1.  You present two different scenarios for protection of p2mp MPLS-TP
traffic, but you do not really define what the architecture of your
protection domain is.
Taking the first solution, where you propose using a 1:n protection scheme
- normally, and as presented in the Survivability Framework a 1:n
protection domain consists of several working paths and a single protection
path that all have the same set of root and leaves.  Yet in your figure 3
you show a 1:2 domain that the working paths have different roots and
different sets of leafs!  It would be helpful, IMO, if you could define
what protection domain you are referencing.

2. In the scenario that you present in figure 3, your protection path
starts at a different root than either working path (for which I commented
above) but what worries me more is that its destination leafs seem to be
the union of the leafs of all of the working paths.  Doesn't this raise
some security and congestion problems?  For example, let's take the simple
case of a single failure on one of the working paths - by switching over to
the protection path the traffic from this service will be delivered to some
destinations that it was not intended to receive the packets?  In addition,
the sections to this destination are suddenly carrying packets that are
unnecessary and just causing additional traffic on the links!

3. Both of your solutions are greatly dependent upon the RDI functionality,
and you state that the root will be able to identify the relevant working
transport path based on this information.  However, the RDI for MPLS-TP is
defined as part of the Extension to BFD and only within the CC messages (it
is ignored in the CV message) that do not include a LSP/PW identifier TLV.
 And considering that p2mp paths in MPLS-TP are unidirectional, I think
that you need to clearly explain how the root receives the RDI and how it
correlates this RDI to a particular LSP.

4. In your solution that is based on (1:1)^n protection - you state that
the root must "compare the priority among these protection paths..." - but
I thought that in this protection scheme the protection switch is performed
within a single 1:1 domain, so there is nothing for the root to compare to!
 What I believe that you meant is that each shared segment may need (in the
case of multiple faults) to compare the priorities of the different
requests for the shared resources!

5.  Can you explain the relationship between your proposals and the drafts
that are available for 1:n protection and shared mesh protection (in
particular draft-cheung that is also based on (1:1)^n protection)?  Can you
use the same extensions that are proposed in those drafts?

Thank you,
Yaacov Weingarten