Re: [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are they compatible?

Dear Greg,
Lots of thanks for a prompt response.

However, I disagree with your conclusion: if you discard the traffic at the LSP level (i.e. based on the incoming tunnel label), you would also discard CC and PSC traffic: at this level they are undistinguishable from the PW traffic.
The situation with the PW protection will be indeed different because Working and Protection PWs would use different PW labels.

Hopefully this clarifies my point.
Regards,
     Sasha
________________________________
From: Greg Mirsky [gregimirsky@gmail.com]
Sent: Saturday, June 18, 2011 7:17 PM
To: Alexander Vainshtein
Cc: yaacov.weingarten@nsn.com; annamaria.fulignoli@ericsson.com; mpls@ietf.org; eosborne@cisco.com; Vladimir Kleiner; Andrew Sergeev; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen; Robert Rennison; Stewart Bryant (stbryant@cisco.com)
Subject: Re: [PWE3] 1+1 linear LSP protection and MPLS-TP data plane: are they compatible?

Dear Sasha,
I think that there is one assumption in line of your logic that changes the result.
When we consider 1+1 LSP protection sink discards traffic from one source on LSP level. As result there should not be issue with Rx on PW client traffic since sink receives PW packets only from Active LSP and PW packets from Inactive LSP would never be seen.
If we consider 1:1 PW protection, then, as I imagine, we have redundant PW and thus PW labels are different. Then the sink selects one of PWs as active but there should be no issue with PW labels.

Please let me know if understood scenarios correctly.

Kind regards,
Greg

On Sat, Jun 18, 2011 at 8:42 AM, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>> wrote:
Hi all,
I would highly appreciate some clarification on the following issue:
Is 1+1 linear protection architecture for LSPs compatible with the MPLS-TP data plane?
We have been recently reminded by Daniel Cohn that 1+1 protection has been declared as MUST to support for MPLS-TP in RFC 5654 (Req. #65). What's more, Req. #65-B states that it MUST be supported in the unidirectional mode for P2P connectivity.

The problematic use case from my point of view is PW traffic carried within a 1+1-protected LSP between a pair of PEs.

To the best of my understanding, unidirectional 1+1 linear protection, in its absolutely minimal form, would imply that:

 1.
Some form of proactive connectivity check (CC) would be applied to both  Working (W) and Protection (P) LSPs. It is my understanding that the GAL/G-ACH mechanism would be used as the encapsulation for the CC packets
 2.
Based on the results of CC, one of the incoming LSPs would be selected as Active
 3.
When in comes to PW client traffic in these LSPs:
    *
In the Tx direction:
       *
Each PW packet would be replicated and forwarded thru both W and P LSPs
       *
 Replication would leave the PW label (and everything after this label) the same for both copies, so that only Tunnel labels and accompanying linke layer encapsulations would be different
    *
In the Rx direction:
       *
Both W and P LSPs would be terminated, i.e., their labels would be popped and, if the resulting packets are still labeled, the next label looked up
       *   PW packets received from the Active LSP would be forwarded to the appropriate PW Forwarder, and PW packets received from the inactive LSP would be silently discarded

If this understanding is correct, this would mean that treatment of the received PW labels would depend on the specific terminated LSP from which the packets labeled with those have been received. In principle, this would be possible if we would treat these LSPs and interfaces and allocate PW labels from the per-interface space(even this would be non-trivial, because there is no way to guarantee that the same label value has simiilar meaning in different label spaces).  But, as per RFC 4447, PW labels MUST be allocated from the per-platform label space.

And of course, simply discarding all the packets received from the inactive LSP would not do because this would affect CC operation.

Did I miss something substantial in my analysis?

Please note also that 1:1 protection could rely on the remote Tx endpoint only sending packets to the (common) Active LSP making life simpler (no real need for selection on the Rx side).

I understand that draft-ietf-mpls-tp-linear-protection is in the final stages of the WG discussion, and apologize for raising this question so late. But late is (sometimes) better than never...

Regards,

     Sasha

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

_______________________________________________
pwe3 mailing list
pwe3@ietf.org<mailto:pwe3@ietf.org>
https://www.ietf.org/mailman/listinfo/pwe3

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.