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

[Yimin Shen <[e-mail]>]

Hi Sasha,

Thanks again for the comments and questions!

Regarding AC failure detection on PE, in the typical cases, if there is a fiber cut, or a hardware failure affecting the port on the PE, or a hardware failure affecting the port on the CE (assume the CE is directed attached to the PE), the PE should be able to directly and independently detect the failure at physical or link layer.

Regarding LDP, I agree with you that LDP by its nature is not as straight-forward as RSVP-TE in this scenario. Since a context ID are advertised by both primary PE and protector, we should avoid creating an ECMP scenario. That's why section 4.2.2 provides a suggestion to advertise the context ID as a proxy node (i.e. a virtual node attached to the two routers), and make its reachability via the primary PE more favorable than that via the protector. MRT and other mechanisms could be used to help LDP improve protection coverage. Also, nothing would prevent LDP from using RSVP bypass tunnels. As you can see, there may be many different approaches, and there may new approaches coming in the future. In this PWE3 document, we just want to stay at PW level and be generic with PSN level. In any case, this mechanism is achievable with LDP, and LDP as a tunnel signaling protocol really doesn't need any new extension.

Hope this clarifies it.

Thanks,

/Yimin


From: Alexander Vainshtein [mailto:[e-mail]]
Sent: Thursday, August 07, 2014 10:37 AM
To: Yimin Shen
Cc: [e-mail]; Yakov Rekhter; [e-mail]
Subject: RE: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01

Yimin hi,
Please see some comments inline below.

Regards,
       Sasha
Email: [e-mail]<mailto:[e-mail]>
Mobile: [phone]

From: Yimin Shen [mailto:[e-mail]]
Sent: Thursday, August 07, 2014 5:34 AM
To: Alexander Vainshtein
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

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

[[Sasha]] Could you please explain how the egress PE detects an egress AC failure? I have always thought that egress AC failure has to be detected first by corresponding CE which would then notify the egress PE using some suitable "Remote Failure"/BDI/RDI mechanism. Specific examples would really help.

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.
[[Sasha]] Please see above. IMHO and FWIW if the CE cannot detect its "Receive Failure", the PE would not never know about the "Transmit Failure.

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.
[[Sasha]] I have provided my comments on this in my response to Eric. From my point of view some LDP-specific issues still require clarification, but my bottom line is that operating the draft over an MPLS network that uses LDP in DU mode for setting up tunnel LSPs may sometimes be possible but would always be tricky. This does not match my understanding of "no dependency on a specific PSN tunnel technology", but this may be a matter of taste.

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.
[[Sasha]] Yes, I have found the corresponding text in the draft.  From my point of view this issue is resolved.

4. We will leave this to PWE3 WG to decide whether this is really necessary.[[Sasha]] I tend to agree with Eric that usage of context-specific labels in the draft does not mean update to 4447. From my point of view this issue is resolved as well.

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]