Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW"

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 13 Jun 2011 15:43:26 +0300

Dear Ma and all,
Adding the PWE3 WG to my response.

The PW redundancy mechanism supports linear protection of MS-PWs as one of many additional application use cases:
Appendix A of the PW redundancy Bit draft<http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/?include_text=1> describes 5 application uses cases in addition to MS-PW with single-homed CEs (which is listed there as use case 5).
And it is equally applicable to IP/MPLS and MPLS - with the help of  the Static PW Status Messages draft<http://datatracker.ietf.org/doc/draft-ietf-pwe3-static-pw-status/?include_text=1>( if, for whatever reason, you do not want  to, or cannot, use RFC 4447<http://datatracker.ietf.org/doc/rfc4447/?include_text=1>).

Hence I doubt the need for yet another PW redundancy  mechanism with narrow scope of applicability.

Regards,
     Sasha

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, June 13, 2011 3:25 PM
To: [email-masked]
Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW"

Hi all,

The linear protection mechanism for LSP and PW(including MS-PW) should be the same and it is valuable to describe it clearly.

BTW, there is a typo, it is "T-PE Z" instead of "T-PE B".

 "
  Figure 1 illustrates such a scenario, where two MS-PWs are
  established between T-PE A and T-PE B, over S-PEs 1-2 and 3-4
  respectively. Each PW segment is established over an LSP (e.g. PW-
  s12 over LSP12).
 "

-----Original Message-----
From: Daniel Cohn
Sent: Tuesday, May 17, 2011 4:14 PM
To: mpls
Subject: Seeking feedback on I-D "MPLS-TP Linear Protection
Applicability to MS-PW"
Importance: High

Hi MPLSers,

I uploaded "MPLS-TP Linear Protection Applicability to MS-PW" I-D
(http://tools.ietf.org/html/draft-cohn-mpls-tp-pw-protection-00)

The abstract goes:

One of the requirements of the MPLS transport profile [RFC 5654] is
to provide linear protection for transport paths, which include both
LSPs and PWs. The functional architecture described in [SurvivFwk]
is applicable to both LSP and PWs, however [LinearProt] does not
explicitly describe mechanisms for PW protection in MPLS-TP.

This document extends the applicability of the linear protection
mechanism described in [LinearProt] to MPLS-TP segmented PWs
(MS-PWs) as defined in [RFC 6073].

Could you please review it and send feedback to the mailing list or
directly to the author?

Looking forward to your feedback,

Daniel

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: binny jeshan <[email-masked]>
Date: Mon, 13 Jun 2011 18:28:08 +0530

Hello authors,

I have a generic question on the *co-existence* of PW monitoring at the
MS-PW level (PSMEG) and the individual segment level (PMEG). Firstly, I
believe there is no such restriction on having co-existence in monitoring
these independently..

Now lets say if a monitored mid segment (a simple PMEG) of a 5 segment MSPW
fails, its quite possible that the PSMEG also detects it at the endpoints.
Now, what would determine the switching priority? Wouldn't it become *
costlier* if the PSMEG does a MS-PW level switching? Instead, one could
prefer to switch to a backup path at a segment level itself. Is this
addressed?

Thanks,
Binny.

On 13 June 2011 18:13, Alexander Vainshtein <
[email-masked]> wrote:

> Appendix A of the PW redundancy Bit draft<http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/?include_text=1>describes 5 application uses cases in addition to MS-PW with single-homed
> CEs (which is listed there as use case 5).
>
> And it is equally applicable to IP/MPLS and MPLS - with the help of  the Static
> PW Status Messages draft<http://datatracker.ietf.org/doc/draft-ietf-pwe3-static-pw-status/?include_text=1>(
> if, for whatever reason, you do not want  to, or cannot, use RFC 4447<http://datatracker.ietf.org/doc/rfc4447/?include_text=1>
> ).
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> [email-masked]
> *Sent:* Monday, June 13, 2011 3:25 PM
> *To:* [email-masked]
> *Subject:* Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection
> Applicability to MS-PW"
>
>
>
> Hi all,
>
> The linear protection mechanism for LSP and PW(including MS-PW) should be
> the same and it is valuable to describe it clearly.
>
> 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: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 13 Jun 2011 15:02:24 +0200

Hi,

I would like to second Sasha.

End-to-end PW protection (with diverse paths) does not scale, and put
hard restrictions on the utilization of the resources.  

MPLS-TP PWs are carried across the network inside MPLS-TP LSPs.
Therefore, an obvious way to provide protection for a PW is to protect
the LSP that carries it.  

If the PW is a multi-segment PW, then LSP recovery can only protect the
PW in individual segments.  This means that a single LSP recovery action
cannot protect against a failure of a PW switching point (an S-PE).

When protecting against an AC or T/S-PE failure by dual connectivity, PW
redundancy mechanisms provide means for the PEs to coordinate over which
LSP the traffic of the PW is carried. 

I also doubt why there is a need for additional mechanism. 

Best regards,

Nurit

From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Alexander Vainshtein
Sent: Monday, June 13, 2011 3:43 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP
LinearProtection Applicability to MS-PW"

Dear Ma and all,

The PW redundancy mechanism supports linear protection of MS-PWs as one
of many additional application use cases:

Appendix A of the PW redundancy Bit draft
<http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy-bit/?include
_text=1>  describes 5 application uses cases in addition to MS-PW with
single-homed CEs (which is listed there as use case 5).

And it is equally applicable to IP/MPLS and MPLS - with the help of  the
Static PW Status Messages draft
<http://datatracker.ietf.org/doc/draft-ietf-pwe3-static-pw-status/?inclu
de_text=1> ( if, for whatever reason, you do not want  to, or cannot,
use RFC 4447 <http://datatracker.ietf.org/doc/rfc4447/?include_text=1>
).

Hence I doubt the need for yet another PW redundancy  mechanism with
narrow scope of applicability.

Regards,

     Sasha

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, June 13, 2011 3:25 PM
To: [email-masked]
Subject: Re: [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection
Applicability to MS-PW"

Hi all, 

The linear protection mechanism for LSP and PW(including MS-PW) should
be the same and it is valuable to describe it clearly. 

 " 

-----Original Message-----
From: Daniel Cohn 
Sent: Tuesday, May 17, 2011 4:14 PM
To: mpls
Subject: Seeking feedback on I-D "MPLS-TP Linear Protection
Applicability to MS-PW"
Importance: High

Hi MPLSers,

The abstract goes:

Daniel 

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: binny jeshan <[email-masked]>
Date: Mon, 13 Jun 2011 19:01:28 +0530

Hello,

Though on one side I'd think its costlier to do a MS-PW level protection
considering the resource usages, pre-configuration and monitoring overload,
on the other i would think - why wouldn't having such a mechanism help in
case if a local repair procedure fails ( failure in protection switch) for a
underlying broken LSP or a mid-PW segment. A provider would never hesitate
look into his pocket to have an end-end level protection considering a risky
situation for an high priority service that he runs on the MS-PW. Wouldn't
he? I believe he could be only concerned in the view of giving precedence to
efficient switching the server layers, and not messing up with multiple
switches happening for one failure.

-Binny.

On 13 June 2011 18:32, Sprecher, Nurit (NSN - IL/Hod HaSharon) <
[email-masked]> wrote:

> End-to-end PW protection (with diverse paths) does not scale, and put hard
> restrictions on the utilization of the resources.
>
> MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore,
> an obvious way to provide protection for a PW is to protect the LSP that
> carries it.
>
> If the PW is a multi-segment PW, then LSP recovery can only protect the PW
> in individual segments.  This means that a single LSP recovery action cannot
> protect against a failure of a PW switching point (an S-PE).
>
> redundancy mechanisms provide means for the PEs to coordinate over which LSP
> the traffic of the PW is carried.
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *ext Alexander Vainshtein
> *Sent:* Monday, June 13, 2011 3:43 PM
> *To:* [email-masked]
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 13 Jun 2011 15:38:48 +0200

Hi,

For end-to-end, you can do it on the client service level. 

If the intention is to protect against a S/T-PE  failure, I think the
solution should be efficient and not necessarily on the end-to-end PW
level. 

We may come soon with idea how to do it. 

Best regards,

Nurit

From: ext binny jeshan [mailto:[email-masked]] 
Sent: Monday, June 13, 2011 4:31 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: ext Alexander Vainshtein; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP
LinearProtection Applicability to MS-PW"

Hello,

Though on one side I'd think its costlier to do a MS-PW level protection
considering the resource usages, pre-configuration and monitoring
overload, on the other i would think - why wouldn't having such a
mechanism help in case if a local repair procedure fails ( failure in
protection switch) for a underlying broken LSP or a mid-PW segment. A
provider would never hesitate look into his pocket to have an end-end
level protection considering a risky situation for an high priority
service that he runs on the MS-PW. Wouldn't he? I believe he could be
only concerned in the view of giving precedence to efficient switching
the server layers, and not messing up with multiple switches happening
for one failure.

-Binny.

On 13 June 2011 18:32, Sprecher, Nurit (NSN - IL/Hod HaSharon)
<[email-masked]> wrote:

Hi,

Best regards,

Nurit

Dear Ma and all,

Regards,

     Sasha

Hi all, 

 " 

-----Original Message-----
From: Daniel Cohn 
Sent: Tuesday, May 17, 2011 4:14 PM
To: mpls
Subject: Seeking feedback on I-D "MPLS-TP Linear Protection
Applicability to MS-PW"
Importance: High

Hi MPLSers,

The abstract goes:

Daniel

---

From: "Daniel Cohn" <[email-masked]>
Date: Mon, 13 Jun 2011 17:54:56 +0300

Hi,

Thanks all for the feedback. I believe we all agree that PW protection
is only required in the event of S-PE failure at an MS-PW - this  is
clearly stated in the draft. Now, both Sasha and Nurit mention that the
PW redundancy mechanism can meet the MPLS-TP PW protection requirements.

First of all a word on scalability. Please note that in an MPLS-TP
environment without a control plane, the PW redundancy mechanism must
also rely on proactive connectivity check for fast failure detection to
meet the sub-50 ms requirement. Therefore any scalability considerations
that apply to the PW protection draft apply to the PW redundancy draft
as well.

Also wrt scalability, there is no such thing as "scales" or "doesn't
scale" - scalability is not a binary concept. You can say that PW
protection scales worse than LSP protection, just like you can say that
LSP protection scales worse than interface protection. Which didn't stop
IETF from defining LSP protection for scenarios where interface
protection doesn't do the job.

Now let's turn our attention back to whether the PW redundancy draaft
can be used to meet MPLS-TP PW protection requirements. I can identify
the following reasons why in its current form it doesn't:

-          It explicitly ("outside the scope") does not define
protection triggers and how to handle coexisting triggers, as requested
in RFC 5654 (MPLS-TP Requirements), reqs #75, #76 and #79

-          It does not support the ability to distinguish between
different types of triggers (i.e. one end doesn't know why the other end
triggered switch), as requested in RFC 5654 (MPLS-TP Requirements), req
#77

-          It does not define revertive/nonrevertive behavior, as
requested in RFC 5654 (MPLS-TP Requirements), req #64

-          It does not define holdoff support, which is especially
important to avoid race conditions with LSP protection when it exists

-          It doesn't support 1+1 mode, as requested in RFC 5654
(MPLS-TP Requirements), req #65

-          It's a two-phase protocol, with the consequent impact on
timing

-          It doesn't define retransmission of protection coordination
messages, so loss of a single PDU can result in switchover not taking
place, thus not supporting sub-50 ms recovery in this case

In summary, PW redundancy was not designed with TP requirements in mind,
and as such does not meet the TP requirements. Of course modifications
may be introduced, but why reinvent the wheel when there is a protocol
(draft-ietf-mpls-tp-linear-protection-06) in the standards track that
supports all the above requirements and can be applied to MS-PW
protection with minor modifications?

Regards,

Daniel

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: Monday, June 13, 2011 4:02 PM
To: ext Alexander Vainshtein; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] [PWE3] Seeking feedback on I-D
"MPLS-TPLinearProtection Applicability to MS-PW"

Hi,

Best regards,

Nurit

Dear Ma and all,

Regards,

     Sasha

Hi all, 

 " 

-----Original Message-----
From: Daniel Cohn 
Sent: Tuesday, May 17, 2011 4:14 PM
To: mpls
Subject: Seeking feedback on I-D "MPLS-TP Linear Protection
Applicability to MS-PW"
Importance: High

Hi MPLSers,

The abstract goes:

Daniel

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 13 Jun 2011 18:10:59 +0300

Daniel and all,
Please see some comments inline below.

Regards,
     Sasha

From: Daniel Cohn [mailto:[email-masked]]
Sent: Monday, June 13, 2011 5:55 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Alexander Vainshtein; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW"

Hi,

Thanks all for the feedback. I believe we all agree that PW protection is only required in the event of S-PE failure at an MS-PW - this  is clearly stated in the draft. Now, both Sasha and Nurit mention that the PW redundancy mechanism can meet the MPLS-TP PW protection requirements.

First of all a word on scalability. Please note that in an MPLS-TP environment without a control plane, the PW redundancy mechanism must also rely on proactive connectivity check for fast failure detection to  meet the sub-50 ms requirement. [[[Sasha]]] IMO there is nothing specific to MPLS-TP here. Detecting S-PE failures based on the control plane would  not fast enough.
Therefore any scalability considerations that apply to the PW protection draft apply to the PW redundancy draft as well.[[[Sasha]]] I have not raised the scalability issue. My issue was limited applicability scope when compared to PW redundancy. E.g., the PW redundancy mechanisms take care of dual-homed CEs in SS- and MS-PWs - something that liner protection of PWs cannot do.
Also wrt scalability, there is no such thing as "scales" or "doesn't scale" - scalability is not a binary concept. You can say that PW protection scales worse than LSP protection, just like you can say that LSP protection scales worse than interface protection. Which didn't stop IETF from defining LSP protection for scenarios where interface protection doesn't do the job.

Now let's turn our attention back to whether the PW redundancy draaft can be used to meet MPLS-TP PW protection requirements. I can identify the following reasons why in its current form it doesn't:

-          It explicitly ("outside the scope") does not define protection triggers and how to handle coexisting triggers, as requested in RFC 5654 (MPLS-TP Requirements), reqs #75, #76 and #79
[[[Sasha]]] So what? Definition of triggers is orthogonal to how coordinated protection switching happens.

-          It does not support the ability to distinguish between different types of triggers (i.e. one end doesn't know why the other end triggered switch), as requested in RFC 5654 (MPLS-TP Requirements), req #77

-          It does not define revertive/nonrevertive behavior, as requested in RFC 5654 (MPLS-TP Requirements), req #64

-          It does not define holdoff support, which is especially important to avoid race conditions with LSP protection when it exists

-          It doesn't support 1+1 mode, as requested in RFC 5654 (MPLS-TP Requirements), req #65
[[[Sasha]]] All these claims are correct - and  this should not be a surprise, because MPLS-TP requirements have been defined much later than the PW redundancy mechanism.
But I do not think that this justifies co-existence of two different mechanisms.

-          It's a two-phase protocol, with the consequent impact on timing[[[Sasha]]] Could you please elaborate?

-          It doesn't define retransmission of protection coordination messages, so loss of a single PDU can result in switchover not taking place, thus not supporting sub-50 ms recovery in this case
[[[Sasha]]] The PW redundancy protocol runs either on top of LDP (which benefits from TCP retransmissions) or on top of static PW status messages (where retransmission is defined).

In summary, PW redundancy was not designed with TP requirements in mind, and as such does not meet the TP requirements. Of course modifications may be introduced, but why reinvent the wheel when there is a protocol (draft-ietf-mpls-tp-linear-protection-06) in the standards track that supports all the above requirements and can be applied to MS-PW protection with minor modifications?
[[[Sasha]]] As I said, because the applicability scope is by far too narrow to justify a dedicated protocol.

Regards,

Daniel

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: Monday, June 13, 2011 4:02 PM
To: ext Alexander Vainshtein; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW"

Hi,
I would like to second Sasha.
End-to-end PW protection (with diverse paths) does not scale, and put hard restrictions on the utilization of the resources.
MPLS-TP PWs are carried across the network inside MPLS-TP LSPs. Therefore, an obvious way to provide protection for a PW is to protect the LSP that carries it.
If the PW is a multi-segment PW, then LSP recovery can only protect the PW in individual segments.  This means that a single LSP recovery action cannot protect against a failure of a PW switching point (an S-PE).
When protecting against an AC or T/S-PE failure by dual connectivity, PW redundancy mechanisms provide means for the PEs to coordinate over which LSP the traffic of the PW is carried.
I also doubt why there is a need for additional mechanism.
Best regards,
Nurit

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Alexander Vainshtein
Sent: Monday, June 13, 2011 3:43 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW"

Dear Ma and all,

Regards,
     Sasha

Hi all,

 "

-----Original Message-----
From: Daniel Cohn
Sent: Tuesday, May 17, 2011 4:14 PM
To: mpls
Subject: Seeking feedback on I-D "MPLS-TP Linear Protection
Applicability to MS-PW"
Importance: High

Hi MPLSers,

The abstract goes:

Daniel

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 13 Jun 2011 17:23:25 +0200

If you do it on the client service layer, you can protect also the
T-PE...

Why do you want to protect only against a failure of the S-PE? The PW
starts at the T-PE...

From: ext Alexander Vainshtein [mailto:[email-masked]]

Sent: Monday, June 13, 2011 6:11 PM
To: Daniel Cohn
Cc: [email-masked]; [email-masked]; Sprecher, Nurit (NSN - IL/Hod
HaSharon); [email-masked]
Subject: RE: [mpls] [PWE3] Seeking feedback on I-D
"MPLS-TPLinearProtectionApplicability to MS-PW"

Daniel and all,

Regards,

     Sasha

From: Daniel Cohn [mailto:[email-masked]] 
Sent: Monday, June 13, 2011 5:55 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Alexander Vainshtein;
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls] [PWE3] Seeking feedback on I-D
"MPLS-TPLinearProtection Applicability to MS-PW"

Hi,

First of all a word on scalability. Please note that in an MPLS-TP
environment without a control plane, the PW redundancy mechanism must
also rely on proactive connectivity check for fast failure detection to
meet the sub-50 ms requirement. [[[Sasha]]] IMO there is nothing
specific to MPLS-TP here. Detecting S-PE failures based on the control
plane would  not fast enough.

Therefore any scalability considerations that apply to the PW protection
draft apply to the PW redundancy draft as well.[[[Sasha]]] I have not
raised the scalability issue. My issue was limited applicability scope
when compared to PW redundancy. E.g., the PW redundancy mechanisms take
care of dual-homed CEs in SS- and MS-PWs - something that liner
protection of PWs cannot do.

[[[Sasha]]] So what? Definition of triggers is orthogonal to how
coordinated protection switching happens.

[[[Sasha]]] All these claims are correct - and  this should not be a
surprise, because MPLS-TP requirements have been defined much later than
the PW redundancy mechanism. 

But I do not think that this justifies co-existence of two different
mechanisms.

-          It's a two-phase protocol, with the consequent impact on
timing[[[Sasha]]] Could you please elaborate? 

[[[Sasha]]] The PW redundancy protocol runs either on top of LDP (which
benefits from TCP retransmissions) or on top of static PW status
messages (where retransmission is defined). 

[[[Sasha]]] As I said, because the applicability scope is by far too
narrow to justify a dedicated protocol.

Regards,

Daniel

Hi,

Best regards,

Nurit

Dear Ma and all,

Regards,

     Sasha

Hi all, 

 " 

-----Original Message-----
From: Daniel Cohn 
Sent: Tuesday, May 17, 2011 4:14 PM
To: mpls
Subject: Seeking feedback on I-D "MPLS-TP Linear Protection
Applicability to MS-PW"
Importance: High

Hi MPLSers,

The abstract goes:

Daniel

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 13 Jun 2011 21:53:51 -0400

Dear All,
I cannot find any reference to Inter-Chassis Communication Protocol (ICCP) as part of MPLS-TP Control Plane. That might be our omission but as of now Control plane solution for PW redundancy might be outside of MPLS-TP scope.

    Regards,
        Greg
________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Monday, June 13, 2011 8:11 AM
To: Daniel Cohn
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TPLinearProtection Applicability to MS-PW"

Daniel and all,

Regards,
     Sasha

Hi,

Regards,

Daniel

Hi,

Dear Ma and all,

Regards,
     Sasha

Hi all,

 "

-----Original Message-----
From: Daniel Cohn
Sent: Tuesday, May 17, 2011 4:14 PM
To: mpls
Subject: Seeking feedback on I-D "MPLS-TP Linear Protection
Applicability to MS-PW"
Importance: High

Hi MPLSers,

The abstract goes:

Daniel

---

From: "Daniel Cohn" <[email-masked]>
Date: Tue, 14 Jun 2011 14:30:42 +0300

Hi Nurit,

The exact same argument can be made for LSP linear protection as in
draft-ietf-mpls-tp-linear-protection - it protects LSRs (transit LERs)
but doesn't protect head/tail LERs. So why not drop LSP linear
protection altogether and protect the client service layer instead? 

Protection is a statistical business. Protecting S-PE will improve
availability, even when T-PE is not protected - especially when you
remember that typically there are many more S-PEs than T-PEs in a given
PW. Also as the T-PE is typically closest to the edge, a T-PE will
typically carry less PWs than an S-PE so S-PE protection would be more
significant for the operator. 

AC protection (required in order to protect T-PE) using ICCP or similar,
as Greg pointed out, is not defined as part of the MPLS-TP framework. In
the most extreme case, which is gradually becoming the norm, operators
deploy MPLS to the customer edge, so the T-PE will actually be a CE in
which case CE/T-PE protection is technically an impossibility.

On the other hand, there is a clear MPLS-TP requirement to provide
protection for MPLS-TP transport paths, which includes PWs. The purpose
of this draft is to meet this requirement, for which there is currently
no solution. If you have an alternative solution please share it with
the list so we can discuss it.

Thanks,

Daniel

From: Sprecher, Nurit (NSN - IL/Hod HaSharon)
[mailto:[email-masked]] 
Sent: Monday, June 13, 2011 6:23 PM
To: ext Alexander Vainshtein; Daniel Cohn
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls] [PWE3] Seeking feedback on I-D
"MPLS-TPLinearProtectionApplicability to MS-PW"

Daniel and all,

Regards,

     Sasha

Hi,

Regards,

Daniel

Hi,

Best regards,

Nurit

Dear Ma and all,

Regards,

     Sasha

Hi all, 

 " 

-----Original Message-----
From: Daniel Cohn 
Sent: Tuesday, May 17, 2011 4:14 PM
To: mpls
Subject: Seeking feedback on I-D "MPLS-TP Linear Protection
Applicability to MS-PW"
Importance: High

Hi MPLSers,

The abstract goes:

Daniel

---

From: "Daniel Cohn" <[email-masked]>
Date: Tue, 14 Jun 2011 14:33:46 +0300

Hi Sasha, thanks again and see inline with [DC].

From: Alexander Vainshtein [mailto:[email-masked]] 

Daniel and all,

Regards,

     Sasha

Hi,

[DC] Agreed - I just pointed our that MPLS-TP has a requirement for
sub-50ms protection.

Therefore any scalability considerations that apply to the PW protection
draft apply to the PW redundancy draft as well.[[[Sasha]]] I have not
raised the scalability issue. My issue was limited applicability scope
when compared to PW redundancy. 

[DC] Correct - scalability issue was a response to Nurit's comment.

E.g., the PW redundancy mechanisms take care of dual-homed CEs in SS-
and MS-PWs - something that liner protection of PWs cannot do.

[DC] I'm afraid I don't follow you here. Where does PW redundancy take
care of dual-homed CE? Actually PW redundancy draft explicitly states:
"The method for dual-homing of CE1 to PE1 and to PE3 nodes, and the
protocols used, are outside the scope of this document". 

[DC] It is. But still it needs to be defined by the recovery framework,
e.g. what should the endpoint do when one PW is in SF and the other is
in SD, or when both are in SD. Operators expect well-defined behavior in
these and other scenarios, and PW redundancy does not define them
(because it was not in their scope). 

[DC] So how do you propose to meet the PW protection requirement? 

-          It's a two-phase protocol, with the consequent impact on
timing[[[Sasha]]] Could you please elaborate? [DC] In
draft-ietf-mpls-tp-linear-protection, each endpoint will immediately
switch traffic to the other path upon identifying an SF condition in a
path, without waiting for the far end to acknowledge the switch
(1-phase). In PW redundancy, an endpoint detecting an SF condition in a
path will not switch until the far end has acknowledged the switch
(2-phase). Needless to say, recovery is slower in a 2-phase protocol.

[DC] True - but static PW status defines slow retransmission ("will be
transmitted twice at an initial interval of one second") while
draft-ietf-mpls-tp-linear-protection specifies fast retransmission when
required for fast recovery (section 3.1.4). 

[DC] If we were discussing designing a new protocol, I might agree with
you. But from a practical standpoint, the PW protection draft is not a
dedicated protocol - it's an applicability statement to an existing
protocol. Both from the implementation and the operational point of view
it defines a new use case for an existing protocol and concept.

Regards,

Daniel

Hi,

Best regards,

Nurit

Dear Ma and all,

Regards,

     Sasha

Hi all, 

 " 

-----Original Message-----
From: Daniel Cohn 
Sent: Tuesday, May 17, 2011 4:14 PM
To: mpls
Subject: Seeking feedback on I-D "MPLS-TP Linear Protection
Applicability to MS-PW"
Importance: High

Hi MPLSers,

The abstract goes:

Daniel

---

From: Maarten vissers <[email-masked]>
Date: Tue, 14 Jun 2011 11:41:22 +0000

Nurit,

If I translate your proposal in terms of SDH protection, then your proposal would imply that LOVC (e.g. VC-12, VC-11 protection should not be deployed, instead only HOVC (VC-4, VC-3) protection should be deployed. We all know that the SDH network has many protected LOVC connections, and that this is scaling well. My question is therefore why protecting MS-PW connections (and Service-LSP connections) would not scale?

Regards,
Maarten

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: 13 June 2011 15:02
To: ext Alexander Vainshtein; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP LinearProtection Applicability to MS-PW"

Hi,

Dear Ma and all,

Regards,
     Sasha

Hi all,

 "

-----Original Message-----
From: Daniel Cohn
Sent: Tuesday, May 17, 2011 4:14 PM
To: mpls
Subject: Seeking feedback on I-D "MPLS-TP Linear Protection
Applicability to MS-PW"
Importance: High

Hi MPLSers,

The abstract goes:

Daniel

---

From: "Daniel Cohn" <[email-masked]>
Date: Tue, 14 Jun 2011 14:44:00 +0300

Hi Binny,

The assumption is that lower-layer protection (LSP or link protection)
will take care of single-segment failures not affecting S-PEs. The
hold-off mechanism defined in [LinearProt], when properly configured,
prevents MS-PW switchover in this scenario. As you say, this is because
lower-layer protection is more efficient so it should be used when
possible.

Regards,

Daniel

From: [email-masked] [mailto:[email-masked]] On Behalf Of
binny jeshan
Sent: Monday, June 13, 2011 3:58 PM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP Linear
Protection Applicability to MS-PW"

Hello authors,

I have a generic question on the co-existence of PW monitoring at the
MS-PW level (PSMEG) and the individual segment level (PMEG). Firstly, I
believe there is no such restriction on having co-existence in
monitoring these independently..

Now lets say if a monitored mid segment (a simple PMEG) of a 5 segment
MSPW fails, its quite possible that the PSMEG also detects it at the
endpoints. Now, what would determine the switching priority? Wouldn't it
become costlier if the PSMEG does a MS-PW level switching? Instead, one
could prefer to switch to a backup path at a segment level itself. Is
this addressed?

Thanks,
Binny.

On 13 June 2011 18:13, Alexander Vainshtein
<[email-masked]> wrote:

Dear Ma and all,

Regards,

     Sasha

Hi all, 

 " 

-----Original Message-----
From: Daniel Cohn 
Sent: Tuesday, May 17, 2011 4:14 PM
To: mpls
Subject: Seeking feedback on I-D "MPLS-TP Linear Protection
Applicability to MS-PW"
Importance: High

Hi MPLSers,

The abstract goes:

Daniel

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 14 Jun 2011 15:02:10 +0300

Daniel,
Please see more inline (bold purple italics). I've also stripped the portions of the text that are not related to this round of comments.

Regards,
     Sasha

From: Daniel Cohn [mailto:[email-masked]]
Sent: Tuesday, June 14, 2011 2:34 PM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]
Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW"

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Monday, June 13, 2011 6:11 PM
To: Daniel Cohn
Cc: [email-masked]; [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]
Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW"

Daniel and all,

Regards,
     Sasha

Hi,

Thanks all for the feedback. I believe we all agree that PW protection is only required in the event of S-PE failure at an MS-PW - this  is clearly stated in the draft. Now, both Sasha and Nurit mention that the PW redundancy mechanism can meet the MPLS-TP PW protection requirements.
[[[Sasha]]] ... snipped ...
E.g., the PW redundancy mechanisms take care of dual-homed CEs in SS- and MS-PWs - something that liner protection of PWs cannot do.
[DC] I'm afraid I don't follow you here. Where does PW redundancy take care of dual-homed CE? Actually PW redundancy draft explicitly states: "The method for dual-homing of CE1 to PE1 and to PE3 nodes, and the protocols used, are outside the scope of this document".
[[[Sasha]]] Quoting from the draft:
15.2. Multiple Multi-homed CEs with single SS-PW redundancy

             |<-------------- Emulated Service ---------------->|
             |                                                  |
             |          |<------- Pseudo Wire ------>|          |
             |          |                            |          |
             |          |    |<-- PSN Tunnels-->|    |          |
             |          V    V    (not shown)   V    V          |
             V    AC    +----+                  +----+     AC   V
       +-----+    |     |....|.......PW1........|....|     |    +-----+
       |     |----------| PE1|......   .........| PE3|----------|     |
       | CE1 |          +----+      \ /  PW3    +----+          | CE2 |
       |     |          +----+       X          +----+          |     |
       |     |          |    |....../ \..PW4....|    |          |     |
       |     |----------| PE2|                  | PE4|--------- |     |
       +-----+    |     |....|.....PW2..........|....|     |    +-----+
                  AC    +----+                  +----+    AC

     Figure 15-2 Multiple Multi-homed CEs with single SS-PW redundancy

   The application in Figure 15-2 makes use of the Independent mode of
   operation.

   CE1 is dual-homed to PE1 and PE2. CE2 is dual-homed PE3 and PE4. The
   method for dual-homing and the used protocols are outside the scope
   of this document.  Note that the PSN tunnels are not shown in this
   figure for clarity. However, it can be assumed that each of the PWs
   shown is encapsulated in a separate PSN tunnel.

   Assume that the AC from CE1 to PE1 is Active, from CE1 to PE2 is
   Standby; furthermore, assume that the AC from CE2 to PE3 is Standby
   and from CE2 to PE4 is Active. The method of deriving Active/Standby
   status of the AC is outside the scope of this document.

   PE1 advertises the preferential status "Active" and operational
   status "Pseudowire forwarding" for pseudowires PW1 and PW4 connected
   to PE3 and PE4. This status reflects the forwarding state of the AC
   attached to PE1. PE2 advertises preferential status "Standby" and
   operational status "Pseudowire forwarding" for pseudowires PW2 and
   PW3 to PE3 and PE4. PE3 advertises preferential status "Standby" and
   operational status "Pseudowire forwarding" for pseudowires PW1 and
   PW3 to PE1 and PE2. PE4 advertise the preferential status "Active"
   and operational status "Pseudowire forwarding" for pseudowires PW2
   and PW4 to PE2 and PE1 respectively. Thus by matching the local and
   remote preferential forwarding status of "Active" and operational
   status of "Pseudowire forwarding" of pseudowires, the PE nodes
   determine which PW should be in the Active state. In this case it is
   PW4 that will be selected.

   On failure of the AC between CE1 and PE1, the forwarding state of
   the AC on PE2 is changed to Active. PE2 then announces the newly
   changed 'preferential forwarding' status bit of "active" to PE3 and
   PE4. PE1 will advertise a PW status notification message indicating
   that the AC between CE1 and PE1 is operationally down. PE2 and PE4
   match the local and remote preferential forwarding status of
   "Active" and operational status "Pseudowire forwarding" and select
   PW2 as the new active pseudowire to send traffic to.

   On failure of PE1 node, PE2 will detect it and will transition the
   forwarding state of its AC to Active. The method by which PE2
   detects that PE1 is down is outside the scope of this document. PE2
   then announces the newly changed 'preferential forwarding' status
   bit of "Active" to PE3 and PE4. PE2 and PE4 match the local and
   remote preferential forwarding status of "Active" and operational
   status "Pseudowire forwarding" and select PW2 as the new active
   pseudowire to send traffic to. Note that PE3 and PE4 may have
   detected that the PW to PE1 went down via T-LDP Hello timeout or via
   other means. However, they will not be able to forward user traffic
   until they received the updated status bit from PE2.

   Because each dual-homing algorithm running on the two node sets,
   i.e., {CE1, PE1, PE2} and {CE2, PE3, PE4}, selects the active AC
   independently, there is a need to signal the active status of the AC
   such that the PE nodes can select a common active PW for end-to-end
   forwarding between CE1 and CE2 as per the procedures in the
   independent mode.

   Note that any primary/secondary procedures, as defined in sections
   5.1.  and 5.2. , do not apply in this use case as the Active/Standby
   status is driven by the AC forwarding state as determined by the AC
   dual-homing protocol used.

I believe you've taken your "out of scope" reference from this text, but IMHO you misinterpreted it.
What it means (or so I read it) is that specific dual-homing protocol is out of scope as long as it meets certain assumptions.
Aside: It would be good if the authors of the PW redundancy drafts could explicitly specify these assumptions.

[[[Sasha]]] ... snipped ...

-          It explicitly ("outside the scope") does not define protection triggers and how to handle coexisting triggers, as requested in RFC 5654 (MPLS-TP Requirements), reqs #75, #76 and #79
[[[Sasha]]] So what? Definition of triggers is orthogonal to how coordinated protection switching happens.
[DC] It is. But still it needs to be defined by the recovery framework, e.g. what should the endpoint do when one PW is in SF and the other is in SD, or when both are in SD. Operators expect well-defined behavior in these and other scenarios, and PW redundancy does not define them (because it was not in their scope).
[[[Sasha]]] I wonder if you have followed the discussion regarding ability to define SD condition for LSPs and PWs on the MPLS-TP list? IMO it is not possible to define it in a meaningful way. Hence I do not see a proposal that does not address a scenario that does not exist in reality as a flawed one.

-          It's a two-phase protocol, with the consequent impact on timing[[[Sasha]]] Could you please elaborate? [DC] In draft-ietf-mpls-tp-linear-protection, each endpoint will immediately switch traffic to the other path upon identifying an SF condition in a path, without waiting for the far end to acknowledge the switch (1-phase). In PW redundancy, an endpoint detecting an SF condition in a path will not switch until the far end has acknowledged the switch (2-phase). Needless to say, recovery is slower in a 2-phase protocol.
[[[Sasha]]] To the best of my understanding, 1-phase protection is only possible in 1+1 unidirectional architectures. And yes, I know that MPLS-TP requires a  mechanism to support this; whether anybody would really do that in the packet-switching network is not clear to me. And I acknowledge that the PW redundancy drafts do not support 1+1 unidirectional scheme.

-          It doesn't define retransmission of protection coordination messages, so loss of a single PDU can result in switchover not taking place, thus not supporting sub-50 ms recovery in this case
[[[Sasha]]] The PW redundancy protocol runs either on top of LDP (which benefits from TCP retransmissions) or on top of static PW status messages (where retransmission is defined).
[DC] True - but static PW status defines slow retransmission ("will be transmitted twice at an initial interval of one second") while draft-ietf-mpls-tp-linear-protection specifies fast retransmission when required for fast recovery (section 3.1.4).

In summary, PW redundancy was not designed with TP requirements in mind, and as such does not meet the TP requirements. Of course modifications may be introduced, but why reinvent the wheel when there is a protocol (draft-ietf-mpls-tp-linear-protection-06) in the standards track that supports all the above requirements and can be applied to MS-PW protection with minor modifications?
[[[Sasha]]] As I said, because the applicability scope is by far too narrow to justify a dedicated protocol.
[DC] If we were discussing designing a new protocol, I might agree with you. But from a practical standpoint, the PW protection draft is not a dedicated protocol - it's an applicability statement to an existing protocol. Both from the implementation and the operational point of view it defines a new use case for an existing protocol and concept.

Regards,

Daniel

Hi,

Dear Ma and all,

Regards,
     Sasha

Hi all,

 "

-----Original Message-----
From: Daniel Cohn
Sent: Tuesday, May 17, 2011 4:14 PM
To: mpls
Subject: Seeking feedback on I-D "MPLS-TP Linear Protection
Applicability to MS-PW"
Importance: High

Hi MPLSers,

The abstract goes:

Daniel

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 20 Jun 2011 11:49:39 +0300

Dear Ma,
Lots of thanks for our response. Please see some comments/answers inline below.

Regards,
     Sasha

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, June 20, 2011 11:31 AM
To: Alexander Vainshtein
Cc: Daniel Cohn; [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]
Subject: 答复: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TPLinearProtectionApplicability to MS-PW"

Hi Sasha,

"Linear protection" is different from "Multi-homed CE redundancy" and has no reference with AC.
[[[Sasha]]] Absolutely.

Working path(s) and protection path(s) have same source and sink endpoints in linear protection type.
[[[Sasha]]] Of course.

IMHO, When S-PE fails, it is more simple to use "Linear protection" to protect it.
[[[Sasha]]] Well, simplicity , like beauty, is in the eye of the beholder:).
But IMHO  introducing multiple simple ad hoc solutions (each for its specific case) and maintaining them  eventually make your life more  complicated when compared with one generic mechanism…

Best Regards,
Ma

Alexander Vainshtein <[email-masked]> 写于 2011-06-14 20:02:10:

> Daniel,
> Please see more inline (bold purple italics). I’ve also stripped the
> portions of the text that are not related to this round of comments.
>
> Regards,
>      Sasha
>
> Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-
> TPLinearProtectionApplicability to MS-PW"
>
> Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-
> TPLinearProtectionApplicability to MS-PW"
>
> Daniel and all,
> Subject: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-
> TPLinearProtection Applicability to MS-PW"
>
> Hi,
>
> Thanks all for the feedback. I believe we all agree that PW
> protection is only required in the event of S-PE failure at an MS-PW
> – this  is clearly stated in the draft. Now, both Sasha and Nurit
> mention that the PW redundancy mechanism can meet the MPLS-TP PW
> protection requirements.
> [[[Sasha]]] … snipped …
> E.g., the PW redundancy mechanisms take care of dual-homed CEs in
> SS- and MS-PWs – something that liner protection of PWs cannot do.
> [DC] I’m afraid I don’t follow you here. Where does PW redundancy
> take care of dual-homed CE? Actually PW redundancy draft explicitly
> states: “The method for dual-homing of CE1 to PE1 and to PE3 nodes,
> and the protocols used, are outside the scope of this document”.
> I believe you’ve taken your “out of scope” reference from this text,
> but IMHO you misinterpreted it.
> What it means (or so I read it) is that specific dual-homing
> protocol is out of scope as long as it meets certain assumptions.
> Aside: It would be good if the authors of the PW redundancy drafts
> could explicitly specify these assumptions.
>
> [[[Sasha]]] … snipped …
>
> Now let’s turn our attention back to whether the PW redundancy
> draaft can be used to meet MPLS-TP PW protection requirements. I can
> identify the following reasons why in its current form it doesn’t:
>
> -          It explicitly (“outside the scope”) does not define
> protection triggers and how to handle coexisting triggers, as
> requested in RFC 5654 (MPLS-TP Requirements), reqs #75, #76 and #79
> [DC] It is. But still it needs to be defined by the recovery
> framework, e.g. what should the endpoint do when one PW is in SF and
> the other is in SD, or when both are in SD. Operators expect well-
> defined behavior in these and other scenarios, and PW redundancy
> does not define them (because it was not in their scope).
> [[[Sasha]]] I wonder if you have followed the discussion regarding
> ability to define SD condition for LSPs and PWs on the MPLS-TP list?
> IMO it is not possible to define it in a meaningful way. Hence I do
> not see a proposal that does not address a scenario that does not
> exist in reality as a flawed one.
>
> different types of triggers (i.e. one end doesn’t know why the other
> end triggered switch), as requested in RFC 5654 (MPLS-TP
> Requirements), req #77
> -          It doesn’t support 1+1 mode, as requested in RFC 5654
> [[[Sasha]]] All these claims are correct – and  this should not be a
> surprise, because MPLS-TP requirements have been defined much later
> than the PW redundancy mechanism.
> -          It’s a two-phase protocol, with the consequent impact on timing
> [[[Sasha]]] Could you please elaborate? [DC] In draft-ietf-mpls-tp-
> linear-protection, each endpoint will immediately switch traffic to
> the other path upon identifying an SF condition in a path, without
> waiting for the far end to acknowledge the switch (1-phase). In PW
> redundancy, an endpoint detecting an SF condition in a path will not
> switch until the far end has acknowledged the switch (2-phase).
> Needless to say, recovery is slower in a 2-phase protocol.
> [[[Sasha]]] To the best of my understanding, 1-phase protection is
> only possible in 1+1 unidirectional architectures. And yes, I know
> that MPLS-TP requires a  mechanism to support this; whether anybody
> would really do that in the packet-switching network is not clear to
> me. And I acknowledge that the PW redundancy drafts do not support
> 1+1 unidirectional scheme.
>
> -          It doesn’t define retransmission of protection
> coordination messages, so loss of a single PDU can result in
> switchover not taking place, thus not supporting sub-50 ms recovery
> in this case
> [[[Sasha]]] The PW redundancy protocol runs either on top of LDP
> (which benefits from TCP retransmissions) or on top of static PW
> status messages (where retransmission is defined).
> [DC] True – but static PW status defines slow retransmission (“will
> be transmitted twice at an initial interval of one second”) while
> draft-ietf-mpls-tp-linear-protection specifies fast retransmission
> when required for fast recovery (section 3.1.4).
>
> In summary, PW redundancy was not designed with TP requirements in
> mind, and as such does not meet the TP requirements. Of course
> modifications may be introduced, but why reinvent the wheel when
> there is a protocol (draft-ietf-mpls-tp-linear-protection-06) in the
> standards track that supports all the above requirements and can be
> applied to MS-PW protection with minor modifications?
> [DC] If we were discussing designing a new protocol, I might agree
> with you. But from a practical standpoint, the PW protection draft
> is not a dedicated protocol – it’s an applicability statement to an
> existing protocol. Both from the implementation and the operational
> point of view it defines a new use case for an existing protocol and concept.
>
>
> Regards,
>
> Daniel
>
>
> Subject: Re: [mpls] [PWE3] Seeking feedback on I-D "MPLS-
> TPLinearProtection Applicability to MS-PW"
>
> Hi,
> End-to-end PW protection (with diverse paths) does not scale, and
> put hard restrictions on the utilization of the resources.
> Therefore, an obvious way to provide protection for a PW is to
> protect the LSP that carries it.
> If the PW is a multi-segment PW, then LSP recovery can only protect
> the PW in individual segments.  This means that a single LSP
> recovery action cannot protect against a failure of a PW switching
> point (an S-PE).
> When protecting against an AC or T/S-PE failure by dual
> connectivity, PW redundancy mechanisms provide means for the PEs to
> coordinate over which LSP the traffic of the PW is carried.
> The PW redundancy mechanism supports linear protection of MS-PWs as
> one of many additional application use cases:
> Appendix A of the PW redundancy Bit draft describes 5 application
> uses cases in addition to MS-PW with single-homed CEs (which is
> listed there as use case 5).
> Static PW Status Messages draft( if, for whatever reason, you do not
> want  to, or cannot, use RFC 4447).
>
> The linear protection mechanism for LSP and PW(including MS-PW)
> should be the same and it is valuable to describe it clearly.
>
> 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.
> 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.
> 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. ﹎z冠??br>

--------------------------------------------------------

ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.

This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: "Daniel Cohn" <[email-masked]>
Date: Mon, 20 Jun 2011 12:50:38 +0300

Sasha,

I think the main question here is why call PW linear protection an ad-hoc mechanism when it’s simply an extension of LSP linear protection. From an implementation point of view, the differences are minimal – you could even say semantic. I think this is what Ma means by simplicity and I wholly agree with her – you have a single mechanism to protect all transport paths – be them LSP or PW. 

My two cents,

DC

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Monday, June 20, 2011 11:50 AM
To: [email-masked]
Cc: Daniel Cohn; [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]
Subject: RE: RE: [mpls] [PWE3] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW"

Dear Ma,

Regards,

     Sasha

Hi Sasha, 

[[[Sasha]]] Absolutely.  

[[[Sasha]]] Of course.

[[[Sasha]]] Well, simplicity , like beauty, is in the eye of the beholderJ. 

Best Regards, 
Ma

---

From: [email-masked]
Date: Mon, 20 Jun 2011 16:31:26 +0800

Hi Sasha,

"Linear protection" is different from "Multi-homed CE redundancy" and has 
no reference with AC.

Working path(s) and protection path(s) have same source and sink endpoints 
in linear protection type.

IMHO, When S-PE fails, it is more simple to use "Linear protection" to 
protect it.

Best Regards,
Ma

Alexander Vainshtein <[email-masked]> 写于 2011-06-14

---

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Thu, 23 Jun 2011 17:22:52 +0200

Dear Daniel,
many thanks for bringing to our attention this issue.

It makes sense for me having the same linear protection mechanisms applied at both LSP and PW level (in the MPLS-TP framework).

It is obvious that there are circumstances where PW redundancy mechanisms can be exploited because they cover the requirements of certain architectural approaches
but I do not believe it can be claimed that PW redundancy mechanisms cover the same requirements  covered by linear protection mechanism. Therefore there is a gap that need to be filled and extending the already defined linear protection for LSPs seems the most appropriate way to proceed.

Actually, I do not see any argument below confuting your hypothesis and therefore I support your proposal.

Best regards,
Alessandro
------------------------------------------------------------------
Telecom Italia
Alessandro D'Alessandro
Transport Innovation
Via Reiss Romoli, 274 - 10148 Torino
phone:  +39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 639 07

Da: [email-masked] [mailto:[email-masked]] Per conto di Daniel Cohn
Inviato: lunedì 20 giugno 2011 11:51
A: Alexander Vainshtein; [email-masked]
Cc: [email-masked]; [email-masked]
Oggetto: Re: [PWE3] [mpls] Seeking feedback on I-D "MPLS-TP Linear Protection Applicability to MS-PW"

Sasha,

My two cents,

DC

Dear Ma,

Regards,
     Sasha

Hi Sasha,

Best Regards,
Ma

Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> 写于 2011-06-14 20:02:10:

> From: Daniel Cohn [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Sprecher, Nurit (NSN - IL/Hod
> HaSharon); [email-masked]<mailto:[email-masked]>
> From: Alexander Vainshtein [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Sprecher, Nurit (NSN - IL/Hod
> HaSharon); [email-masked]<mailto:[email-masked]>
> From: Daniel Cohn [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
> [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of
> To: ext Alexander Vainshtein; [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of
> ext Alexander Vainshtein
> To: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of
> [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.