Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01

[Yimin Shen <[e-mail]>]

Hi Sasha,

Thanks again for the comments. Please see the following 4 items in response to the 4 comments in your email.

1. Today when an egress PE detects an egress AC failure, it will simply have to drop packets, until the remote PE stops sending traffic over the PW. This draft is intended to improve this behavior. By no means the local repair on egress PE will prevent the AC failure from being converted to and handled as a bi-directional AC failure. Note that bi-directional AC failure handling must involve the CE, but the CE may detect the failure at a slower pace, or it may not be able to detect it in a timely manner, depending on the actual situation. E.g. there may be other L2 devices between the PE and CE; the AC may itself be a logical wire across another network; the type and location of the failure may make it easier for the PE to detect it; and so on. In any case, before the AC failure is handled more gracefully (or bi-directionally), the egress traffic has been locally repaired by the egress PE.

2. As mentioned before, this draft doesn't have a dependency on a specific PSN tunnel technology.

3. The draft already talks about scalability when describing the centralized protector model vs the co-located protector model. We can improve the text to explicitly mention that the requirement for setting up LSPs on a per <primary PE, protector> basis rather than per primary PE basis can potentially increase the number of LSPs in a network. This is a tradeoff. As mentioned before, this does not necessarily cause a scaling issue.

4. We will leave this to PWE3 WG to decide whether this is really necessary.

Thanks,

/Yimin


From: Alexander Vainshtein [mailto:[e-mail]]
Sent: Wednesday, August 06, 2014 5:11 AM
To: Yimin Shen
Cc: [e-mail]<mailto:[e-mail]>; Yakov Rekhter; [e-mail]<mailto:[e-mail]>
Subject: RE: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01


Yimin and all,

I would like to summarize the issues that I have with this draft. Digging for them in a very long email thread with multiple levels of in-lining is not very effective IMO.



1.       Protection against unidirectional AC failures looks problematic to me:

a.       The draft explicitly differentiates between "ingress" and "egress" AC failures

b.      The outcome can be using a different AC for each direction of CE-to-CE traffic with potentially destructive effect that cannot be mitigated at the PWE3 level

c.       IMHO and FWIW a viable alternative could be to employ native AC mechanisms converting unidirectional AC failures into bi-directional ones. This would eliminate the differentiation between ingress and egress AC failures and facilitate using the PW redundancy mechanism for bi-directional protection

2.       Dependency upon specific mechanisms for setting up PSN tunnels seems to break some common PWE3 architectural principles:

a.       I am pretty well sure that the mechanisms specified in the draft cannot be used with the PSN tunnel LSPs set up by LDP in DU mode

b.      If the authors, refer to LDP in the DoD mode augmented with some CR-LDP-like mechanisms (e.g., for exclusion of specific links when setting up the bypass LSP between the PLR and the Protector), this should, at the very least, be discussed with and approved by the MPLS WG

3.       Scalability of the proposed solution should be, at least, explicitly presented. In particular, the draft assumes that a dedicated LSP would be used between PE1  PE2 for each combination of PE2 with a specific Protector LSR.

4.       The Protector LSR could be either a kind of S-PE (if different from the secondary T-PE) or the secondary T-PE itself. In both cases it should be capable of handling labels from specific context spaces as if they were PW labels. This requires (at the very least) an update of RFC 4447 and should be explicitly presented and discussed.

Hopefully this summary will be useful.





Regards,

       Sasha

Email: [e-mail]<mailto:[e-mail]>

Mobile: [phone]