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> 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 simiilarmeaning 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
> https://www.ietf.org/mailman/listinfo/pwe3
>
>