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

[Sam Aldrin <[e-mail]>]

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.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 
> 
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
> 
>