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

[Yimin Shen <[e-mail]>]

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:[e-mail]] 
Sent: Tuesday, September 03, 2013 8:49 PM
To: Yimin Shen
Cc: Bocci, Matthew (Matthew); [e-mail]
Subject: Re: [PWE3] Poll for WG adoption of draft-shen-pwe3-endpoint-fast-protection-04

Yimin,

Thanks for the reply.
My comments inline with %sam.
On Aug 31, 2013, at 6:40 AM, Yimin Shen <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On Behalf 
> Of Sam Aldrin
> Sent: Friday, August 30, 2013 2:29 PM
> To: Bocci, Matthew (Matthew)
> Cc: [e-mail]
> Subject: Re: [PWE3] Poll for WG adoption of 
> draft-shen-pwe3-endpoint-fast-protection-04
> 
> Hi,
> 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) <[e-mail]> wrote:
> 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.t
> xt
> 
> 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
> 
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
> 
>