Subject: Re: [PWE3] Poll for WG adoption of draft-shen-pwe3-endpoint-fast-protection-04

From: Jiangyuanlong <[email-masked]>
Date: Mon, 2 Sep 2013 08:01:10 +0000

Support.

Thanks,
Yuanlong

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bocci, Matthew (Matthew)
Sent: Friday, August 30, 2013 10:26 PM
To: [email-masked]
Subject: [PWE3] Poll for WG adoption of draft-shen-pwe3-endpoint-fast-protection-04

This email begins a two week poll to help the chairs determine if there is consensus to adopt draft-shen-pwe3-endpoint-fast-protection-04 as an PWE3 working group draft.

The draft can be found here:
http://tools.ietf.org/id/draft-shen-pwe3-endpoint-fast-protection-04.txt

Please read the draft and indicate to the list if you support adoption, or if you do not support adoption (giving reasons).

Please note that this is only a call for adoption. There needs to be consensus that this draft is a good basis for the work, but it does not need to be perfect at this stage.

The poll for adoption will close in two weeks time, on Friday 13th September.

Best regards,

Matthew

---

From: Yimin Shen <[email-masked]>
Date: Mon, 2 Sep 2013 13:19:48 +0000

I'm not aware of any IPR related to the draft.

Thanks,

-Yimin

On Aug 30, 2013, at 10:34 AM, "Bocci, Matthew (Matthew)" <[email-masked]<mailto:[email-masked]>> wrote:

Coincidentally, we are also polling for knowledge of any IPR that applies to this draft, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond to this email whether or not you are aware of any relevant IPR. The draft will not be adopted until a response has been received from each author and contributor.

If you are on the PWE3 WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

Matthew

On 30/08/2013 15:26, "Bocci, Matthew (Matthew)" <[email-masked]<mailto:[email-masked]>> wrote:

Best regards,

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

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Mon, 2 Sep 2013 14:26:20 +0000

Me neither

From: Yimin Shen <[email-masked]<mailto:[email-masked]>>
Date: Monday 2 September 2013 15:19
To: "Bocci, Matthew (Matthew)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [PWE3] IPR check for draft-shen-pwe3-endpoint-fast-protection-04

Thanks,

-Yimin

Matthew

Best regards,

Matthew

---

From: Mingui Zhang <[email-masked]>
Date: Tue, 3 Sep 2013 01:51:14 +0000

Hi, 

I have read the draft and have the following comments and questions. 

1. When I read the ICCP draft and RFC 6718, I thought PW-RED offered the mechanism for PE and AC protection. Is there any difference between the solution here and the PW-RED?
 
2. Whether providers need manually configure the protector?

3. There seems no detail for the proxy method to be followed by the implementers. Add a reference here or elaborate it?

4. I am glad to see there is some text talking about the " Revertive Behavior ". I was designing a protection mechanism before, knowing that this is not an easy problem to be solved. If the PLR revert to the new primary PW ahead of time (before the convergence). Loops or packet loss may happen. I remember I was asked by the question: how does the PLR determine the time to revertive? Timers are what I can think of. I wonder whether there is any better idea. 

5. A minor issue. What is "control plane repair"? See para3 of the introduction. I think both global repair and local repair involves both data plane and control plane behaviors. 

If I missed anything, please correct me.

Thanks,
Mingui

>-----Original Message-----
>Subject: [PWE3] Poll for WG adoption of
>draft-shen-pwe3-endpoint-fast-protection-04
>
>This email begins a two week poll to help the chairs determine if there is
>consensus to adopt draft-shen-pwe3-endpoint-fast-protection-04 as an PWE3
>working group draft.
>
>Please note that this is only a call for adoption. There needs to be consensus
>that this draft is a good basis for the work, but it does not need to be perfect at
>this stage.
>

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 3 Sep 2013 01:57:45 +0000

yes, support

I think that the draft addresses real scenario and offers solution to it. It is in good state to be adopted as PWE3 WG draft.

                Regards,
                                Greg

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bocci, Matthew (Matthew)
Sent: Friday, August 30, 2013 7:26 AM
To: [email-masked]
Subject: [PWE3] Poll for WG adoption of draft-shen-pwe3-endpoint-fast-protection-04

Best regards,

Matthew

---

From: Yimin Shen <[email-masked]>
Date: Tue, 3 Sep 2013 15:25:19 +0000

Hi Mingui,

Thanks for your questions. Please inline...

Thanks,

-Yimin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mingui Zhang
Sent: Monday, September 02, 2013 9:51 PM
To: [email-masked]
Subject: Re: [PWE3] Poll for WG adoption of draft-shen-pwe3-endpoint-fast-protection-04

Hi, 

[yshen] Yes, the difference is that PW redundancy (RFC 6718) is a global repair mechanism driven by control plane's reactions to failures, while the proposal in this draft is a local repair mechanism driven by data plane. In the later case, bypass path is pre-installed in the data plane, and invoked by a rapid failure detection. As described in the draft, these two mechanisms can really work in tandem and complement each other. IOW, the local repair performs a fast but temporary restoration for traffic, and PW redundancy moves traffic to another permanent and fully functional PW, at a relatively slower pace.

[yshen] A certain amount of provisioning is expected on the protector, e.g. context ID, etc. But the detail is vendor specific.

[yshen] The draft provides a guideline for the proxy mode as below. This is because this mode doesn't require any IGP extension, it's generic, and it is not something new. You may find a little more detail in draft-minto-rsvp-lsp-egress-fast-protection. 

" One approach would be to advertise it as a
   virtual proxy node connected to both routers, with the link between
   the proxy node and the primary PE having a more preferable IGP or TE
   metric than the link between the proxy node and the protector."

[yshen] Local reversion should be triggered by control plane re-convergence after the failed link/node has been recovered. There should be no loop from the perspective of this draft.

[yshen] The important question is - Who drives the traffic repair in the first place ? If it's the data plane that drives it purely based on link layer failure detection, it is local repair. If it is the control plane protocol (RSVP, LDP, IGP) on the adjacent router of the failure, it is called "control plane repair". If it is the control plane on the ingress router (i.e. PE), it is global repair. Of course, C-plane will slowly converge on the new topology caused by the failure, and eventually be update D-plane, but local repair should happen way before that, within 50 ms.

Thanks,
Mingui

>This email begins a two week poll to help the chairs determine if there 
>is consensus to adopt draft-shen-pwe3-endpoint-fast-protection-04 as an 
>PWE3 working group draft.
>
>Please read the draft and indicate to the list if you support adoption, 
>or if you do not support adoption (giving reasons).
>
>Please note that this is only a call for adoption. There needs to be 
>consensus that this draft is a good basis for the work, but it does not 
>need to be perfect at this stage.
>
[email-masked]

---

From: Sam Aldrin <[email-masked]>
Date: Tue, 3 Sep 2013 17:48:44 -0700

Yimin,

Thanks for the reply.
My comments inline with %sam.
On Aug 31, 2013, at 6:40 AM, Yimin Shen <[email-masked]> wrote:

> Sam,
> 
> Thanks for your questions. 
> 
> This draft assumes LDP-signaled PWs, which is the case in most PWE3 deployment. But we can add some text to also address the scenarios that you mentioned with static PWs or mixture of dynamic + static PWs. In fact, all the procedures in the draft will still apply in this case, except that you won't need the LDP extension in section 5, because you don't have LDP. 
%sam - I would definitely like to see explicit text added regarding PW with no dynamic signaling. Would like to see how it affects in static MS-PW with S-TLV, if any. 
> 
> So instead of running LDP between a pair of primary PE and protector, all you need is static configuration on the protector to coordinate it with the primary PE and make sure correct forwarding state is installed, so that the protector can send redirected traffic towards the target CE. The PLR's behavior will be the same as currently specified. In particular, you will need to do the followings on the protector.
%sam - What you say is true for CE protection. But I do not think it is the same for (T/S) PE protection. You are requiring configuration on PHP. See further questions below, on why.
> 
> - know which primary PEs and primary PWs or PW segments that the protector protects.
> - create a context label table for each primary PE.
> - install a label route for each protected PW or PW segment in the corresponding context label table. The next hop should be the backup AC (in the case of SS-PW) or a label swap to the label of the next segment of the backup PW (in the case of MS-PW).
> - point incoming bypass tunnel(s) to their corresponding context label table, to result in a label look-up in that table.
%sam - the above will not work in all the cases.

1. In the case of MSPW interAS option B, it will fail as you cannot tunnel through the PW label and assume it to be constant across the segments.
2. when you perform OAM, like trace of MSPW using LSP ping with VCCV, it will fail with the existing model. There are lot of other scenarios which I could think off, where existing OAM mechanisms.
3. For T/S PE protection(fig 7), you are actually creating protection for the underlying transport lsp. correct? If so, it is not actually PW protection, rather the underlying LSP protection. In that case, it will (configuration) affect any traffic which uses that transport LSP. Have you considered non-PW traffic using the same transport lsp as PW? Also, why is it in PWE3 working group and not in MPLS
4. If you say, the configuration/context label+table is created on PHP (in case of S/T PE) is only for PW, this is now introducing config on PHP, on which there is no PW awareness, right. And I am not clear with the text in this regard.
5. I do not see any section on how this will cause impact on OAM. As in the above question, it will impact and also cause breakage of existing mechanisms.

Like I said earlier, I fail to see the current draft describing clearly the scenarios I have identified for now. would like to see them clarified prior to adoption.

-sam
> 
> Then your forwarding state is ready in place. This is applicable to static SS-PWs, static MS-PWs, and static and dynamic MS-PW segment stitching. Essentially, the forwarding state in the data-plane is the ultimate goal of this PW endpoint protection. If your network already has LDP for PW signaling, you can used the LDP extension to coordinate your protector with primary PE. Otherwise, just use static configuration to achieve the same.
> 
> Hope this has answered your questions.
> 
> 
> Thanks,
> 
> -Yimin Shen
> Juniper Networks
> 
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Sam Aldrin
> Sent: Friday, August 30, 2013 2:29 PM
> To: Bocci, Matthew (Matthew)
> Cc: [email-masked]
> I would like to see the  following questions answered before the document could be adopted.
> Here are the reasons why.
> 1. The scope of the document says End point protection for SS-PW and MS-PW. But what it is failing to consider is the absence of signaling component. I do not see how this will work when the PW's are set up statically w/o the dynamic signaling in both SS-PW and MS-PW?
> 
> 2. Would also like to see how the protection works, in terms of setup and working model, where a MS-PW is made of dynamically signaled SS-PW and statically setup SS-PW stitched to form a MS-PW.
> 3. By reading sec 5. the way I understood that this is only possible with control plane being present. If my understanding is incorrect, would like to see text detailing on how this could be achieved in the absence of CP(control plane).
> 4. In case CP is mandatory, I would like to see the document title and scope to change to reflect the same.
> thanks
> -sam
> 
> On Fri, Aug 30, 2013 at 7:26 AM, Bocci, Matthew (Matthew) <[email-masked]> wrote:

---

From: Yimin Shen <[email-masked]>
Date: Thu, 5 Sep 2013 13:24:03 +0000

Sam,

Hope the following can clarify for you...

PLR (point of local repair) and protector are two different routers in this mechanism. PLR detects failure and performs local repair. In egress PE and S-PE protection, the PLR is the PHP router (most likely a P router), and it repairs the transport tunnel locally by using any existing FRR mechanisms for RSVP, LDP and IP. The PLR (PHP router) shouldn't require configuration in your static PW case. The protector is the router that maintains context label tables and performs context specific label switching. This is where you may need some configuration for your scenario.

In the MS-PW case, there is a PW label swapping at the protector. In the co-located protector model, the protector swaps the PW label to the PW label of the next segment of the backup PW; In centralized protector model, the protector swaps the PW label to the PW label of the current corresponding segment of the backup PW. In any case, the PW label is NOT tunneled unchanged all the way to the egress T-PE.

The transport tunnel should not carry non-PW traffic. This because the destination of the tunnel is the context ID of {primary PE, protector}, rather than a private IP address of the primary PE. The destination should differentiate the tunnel from regular tunnels to the primary PE, and hence the ingress PE should not put non-PW traffic on this tunnel.

This mechanism has no impact on PW OAM (e.g. VCCV). In egress AC failure, OAM should be up, because the primary PW is still up. In egress PE and S-PW failure, OAM should go down (as it does today without egress protection), which is exactly the desired behavior because we want to rely on it to trigger and expedite a global repair at ingress PE.

Thanks,

-Yimin

-----Original Message-----
From: Sam Aldrin [mailto:[email-masked]] 
Sent: Tuesday, September 03, 2013 8:49 PM
To: Yimin Shen
Cc: Bocci, Matthew (Matthew); [email-masked]
Subject: Re: [PWE3] Poll for WG adoption of draft-shen-pwe3-endpoint-fast-protection-04

Yimin,

Thanks for the reply.

1. In the case of MSPW interAS option B, it will fail as you cannot tunnel through the PW label and assume it to be constant across the segments.
2. when you perform OAM, like trace of MSPW using LSP ping with VCCV, it will fail with the existing model. There are lot of other scenarios which I could think off, where existing OAM mechanisms.
3. For T/S PE protection(fig 7), you are actually creating protection for the underlying transport lsp. correct? If so, it is not actually PW protection, rather the underlying LSP protection. In that case, it will (configuration) affect any traffic which uses that transport LSP. Have you considered non-PW traffic using the same transport lsp as PW? Also, why is it in PWE3 working group and not in MPLS 4. If you say, the configuration/context label+table is created on PHP (in case of S/T PE) is only for PW, this is now introducing config on PHP, on which there is no PW awareness, right. And I am not clear with the text in this regard.
5. I do not see any section on how this will cause impact on OAM. As in the above question, it will impact and also cause breakage of existing mechanisms.

-sam
> Subject: Re: [PWE3] Poll for WG adoption of

---

From: Sam Aldrin <[email-masked]>
Date: Fri, 13 Sep 2013 16:58:41 -0700

Yimin,

sorry for the delayed response.

Yes it is clear now. Thanks for the clarifications. 
Though it is not clean as PW requires new transport lsp's and configuration of protectors along with maintaining unique labels is painful, I could not see a better alternative option.

I do not have any objection to be adopted as WG draft.

thanks again
-sam