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

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 18 Jun 2011 18:42:46 +0300

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.

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 18 Jun 2011 09:17:01 -0700

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 <
[email-masked]> wrote:

> 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.
>
>
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 18 Jun 2011 21:58:41 +0300

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 [[email-masked]]
Sent: Saturday, June 18, 2011 7:17 PM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Vladimir Kleiner; Andrew Sergeev; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen; Robert Rennison; Stewart Bryant ([email-masked])
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.

Kind regards,
Greg

On Sat, Jun 18, 2011 at 8:42 AM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> 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.

 1.

Regards,

     Sasha

_______________________________________________
pwe3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pwe3

---

From: [email-masked]
Date: Sat, 18 Jun 2011 20:43:38 +0000

Sasha

All traffic except LSP OAM traffic from protection LSP must be discarded in Rx. So what is the issue?

Thx
Shahram
Sent via BlackBerry by AT&T

-----Original Message-----
From: Alexander Vainshtein <[email-masked]>
Sender: [email-masked]
Date: Sat, 18 Jun 2011 21:58:41 
To: Greg Mirsky<[email-masked]>
Cc: [email-masked]<[email-masked]>; Vladimir Kleiner<[email-masked]>; Mishael Wexler<[email-masked]>; pwe3<[email-masked]>; Oren Gal<[email-masked]>; John Shirron<[email-masked]>; Stewart Bryant \([email-masked]\)<[email-masked]>; Rotem Cohen<[email-masked]>
Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane:
 are they compatible?

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 19 Jun 2011 07:04:45 +0300

Shahram,
The problem IMHO is in the combination of two points :

- At the LSP level both LSP OAM and PW traffic look exactly the same (after popping the Tunnel label a labeled packet remains). You can only differentiate between them when you look up the next label in the stack

- When you look at the next label after having popped the tunnel label, PW packets received from both active and inactive LSPs look exactly the same with the same label from the per-platform label space.

IMO this means that you cannot describe the desired behavior in the terms of RFC 3031 and 3032.

Hopefully this clarifies my question.

Regards,
     Sasha

________________________________________
From: [email-masked] [[email-masked]]
Sent: Saturday, June 18, 2011 11:43 PM
To: Alexander Vainshtein; [email-masked]; Greg Mirsky
Cc: [email-masked]; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; John Shirron; Stewart Bryant ([email-masked]); Rotem Cohen
Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane:are they compatible?

Sasha

Thx
Shahram

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 19 Jun 2011 21:13:55 +0300

Shahram, Greg and all,
After some thought:
One way to model selection in 1+1 linear protection architecture could be to define a "special" internal interface in the box and to define the ILM action on the tunnel label of an inactive LSP as "Pop and forward to special interface".

The special interface then would then forward resulting labeled packets with a reserved top label to control and discard all the rest. This behavior would not be part of "normal" MPLS data plane hence no contradictions with its architecture.

I assume that this is roughly the formal model for what Shahram and Greg have said.

Regards,
     Sasha

________________________________________
From: Alexander Vainshtein
Sent: Sunday, June 19, 2011 7:04 AM
To: [email-masked]; [email-masked]; Greg Mirsky
Cc: [email-masked]; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; John Shirron; Stewart Bryant ([email-masked]); Rotem Cohen
Subject: RE: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane:are they compatible?

Shahram,

Regards,
     Sasha

Sasha

Thx
Shahram

---

From: "Shahram Davari" <[email-masked]>
Date: Sun, 19 Jun 2011 22:22:32 -0700

Hi Sasha,

That is correct. But the behavior is what I call Leaky drop. Meaning that all the Protection LSP packets must be dropped (including the PW traffic) except the LSP OAM packets.

Thanks
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Saturday, June 18, 2011 9:05 PM
To: [email-masked]; [email-masked]; Greg Mirsky
Cc: [email-masked]; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen; Stewart Bryant ([email-masked])
Subject: Re: [PWE3] [mpls] 1+1 linear LSP protection and MPLS-TP data plane:are they compatible?

Shahram,

Regards,
     Sasha

Sasha

Thx
Shahram

---

From: "Shahram Davari" <[email-masked]>
Date: Sun, 19 Jun 2011 22:41:16 -0700

Hi Sahsa,

Actually what you can do is to define 2 special interfaces, one for working and one for protection LSP. Then for working interface, set the behavior as pop and forward as normal, and for protection interface pop and forward to control plane only reserved labels. In case of failure the behavior of the two interfaces must be changed.

IS that correct?

Thx
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Sunday, June 19, 2011 11:14 AM
To: [email-masked]; [email-masked]; Greg Mirsky
Cc: [email-masked]; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen; Stewart Bryant ([email-masked])
Subject: Re: [mpls] [PWE3] 1+1 linear LSP protection and MPLS-TP data plane:are they compatible?

Shahram, Greg and all,
After some thought:

Regards,
     Sasha

Shahram,

Regards,
     Sasha

Sasha

Thx
Shahram

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 20 Jun 2011 09:51:01 +0300

Shahram,

I doubt the value of two special interfaces: IMHO at least one of the LSPs (Active) should be terminated (i.e. the ILM for its action would look "Pop and look up the next label").

But the "leaky drop" interface seems to be the right thing to do. The name is nice.

I wonder if adding a clarification would benefit the linear protection draft?

Regards,
     Sasha

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Monday, June 20, 2011 8:41 AM
> To: Alexander Vainshtein; [email-masked]; [email-masked];
> Greg Mirsky
> Cc: [email-masked]; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal;
> John Shirron; Rotem Cohen; Stewart Bryant ([email-masked])
> Actually what you can do is to define 2 special interfaces, one for
> working and one for protection LSP. Then for working interface, set the
> behavior as pop and forward as normal, and for protection interface pop
> and forward to control plane only reserved labels. In case of failure
> the behavior of the two interfaces must be changed.
> 
> IS that correct?
> 
> Thx
> Shahram
> 
> Cc: [email-masked]; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal;
> John Shirron; Rotem Cohen; Stewart Bryant ([email-masked])
> One way to model selection in 1+1 linear protection architecture could
> be to define a "special" internal interface in the box and to define
> the ILM action on the tunnel label of an inactive LSP as "Pop and
> forward to special interface".
> 
> The special interface then would then forward resulting labeled packets
> with a reserved top label to control and discard all the rest. This
> behavior would not be part of "normal" MPLS data plane hence no
> contradictions with its architecture.
> 
> Cc: [email-masked]; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal;
> John Shirron; Stewart Bryant ([email-masked]); Rotem Cohen
> - At the LSP level both LSP OAM and PW traffic look exactly the same
> (after popping the Tunnel label a labeled packet remains). You can only
> differentiate between them when you look up the next label in the stack
> 
> - When you look at the next label after having popped the tunnel label,
> PW packets received from both active and inactive LSPs look exactly the
> same with the same label from the per-platform label space.
> 
> Cc: [email-masked]; Vladimir Kleiner; Mishael Wexler; pwe3; Oren Gal;
> John Shirron; Stewart Bryant ([email-masked]); Rotem Cohen
> Cc: [email-masked]<[email-masked]>; Vladimir
> Kleiner<[email-masked]>; Mishael
> Wexler<[email-masked]>; pwe3<[email-masked]>; Oren
> Gal<[email-masked]>; John Shirron<[email-masked]>;
> Stewart Bryant \([email-masked]\)<[email-masked]>; Rotem
> Cohen<[email-masked]>
> 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.
>

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Mon, 20 Jun 2011 17:19:50 -0500

Hi Sasha, Greg-

  If I understand correctly, the point that's being raised is that an
implementation must distinguish Rx'd P-LSP packets it needs to discard
(e.g. user traffic) vs. those that it must not (managmentm such as CC
and PSC).

  If this is the point, I agree with it.  But I don't see that it's any
cause for concern.  An implementation ought to be able to examine all
traffic in an LSP and decide what it wants to keep; for CC and PSC (and
for everything, as far as I can see), all traffic we want to keep will
be in the GACH.

eric

> From: Alexander Vainshtein [mailto:[email-masked]]
> Sent: Saturday, June 18, 2011 2:59 PM
> To: Greg Mirsky
> Cc: [email-masked]; [email-masked];
> [email-masked]; Eric Osborne (eosborne); Vladimir Kleiner; Andrew
Sergeev;
> Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen; Robert
> Rennison; Stewart Bryant (stbryant)
> Subject: RE: [PWE3] 1+1 linear LSP protection and MPLS-TP data plane:
are
> they compatible?
> 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.
> 
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Vladimir Kleiner; Andrew Sergeev;
> Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem Cohen; Robert
> Rennison; Stewart Bryant ([email-masked])
> 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.
> and thus PW labels are different. Then the sink selects one of PWs as
> active but there should be no issue with PW labels.
> 
> On Sat, Jun 18, 2011 at 8:42 AM, Alexander Vainshtein
> <[email-masked]> wrote:
> 
> 
> 	Hi all,
> 		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
> 				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.
> 
> 
> 
> 	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
> 
> 
> 
> 
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 21 Jun 2011 11:47:38 +0300

Eric,
I believe the issue has been successfully resolved with help from Shahram and Greg.

The way to resolve it, from my point of view, was to say that the inactive LSP would not be terminated in the tail-end in the normal way LSPs are terminated i.e., the ILM-defined action on its label would not be "Pop and look up the next label (if it exists)". Rather, this action would be "Pop and forward to a "leaky drop" interface". Thus the problem has been effectively removed from the scope of MPLS data plane architecture (as defined in RFC 3031 and 3032): it would be the responsibility of the "leaky drop" interface to "leak" GACH packets to control while dropping all the rest (user traffic). Accordingly, implementation could be partitioned into two components:
- implementation of the "leaky drop" interface (one such per box would suffice)
- manipulation of the ILM entries referring to the labels of the two LSPs.

Hopefully these notes will be useful.

Regards,
     Sasha

> From: Eric Osborne (eosborne) [mailto:[email-masked]]
> Sent: Tuesday, June 21, 2011 1:20 AM
> To: Alexander Vainshtein; Greg Mirsky
> [email-masked]; Vladimir Kleiner; Andrew Sergeev; Mishael Wexler; pwe3;
> Oren Gal; John Shirron; Rotem Cohen; Robert Rennison; Stewart Bryant
> (stbryant)