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

[Yimin Shen <[e-mail]>]

Hi Sasha,

Thanks for these comments! I agree with your points on these scenarios. Will describe and clarify them in the next rev.


Thanks,

/Yimin


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

Yimin hi!
Lots of thanks for a prompt response.


The problem with splitting the PW traffic is not limited to re0rdering.

In the simplest case, consider the case when the PW s have been set between two IEEE802.1 bridges that perform MAC learning.
Split traffic could easily result in frequent re-learning of a certain MAC address...


The bottom line is that if split traffic cannot be precluded, the dual-homed CE must be aware of this fact and behave accordingly (e.g., by grouping a pair of ports that support its connections to Primary PE and the Protector PE as a LAG:)).

>From my point of view these dependencies should be explicitly defined (say, in the Applicability Statement). To the best of my recollection, this has been a long-established PWE3 WG policy from its early days.

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

From: Yimin Shen [mailto:[e-mail]]
Sent: Tuesday, August 12, 2014 6:26 PM
To: Alexander Vainshtein
Cc: [e-mail]<mailto:[e-mail]>; Yakov Rekhter; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01

Hi Sasha,

Please see inline...


Thanks,

/Yimin


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


Yimin,

Lots of thanks for a prompt response.



My concerns related to ECMP have been mainly about multiple potential PLRs on equal cost LSPs between the ingress PE" and "Primary egress PE".



I do not see how this can be easily avoided and my reading of your response is that you do not consider it either.



[yshen] This draft doesn't preclude or avoid it, as I explained below.



One of the aspects of multiple potential PLRs has been raised by Stewart in his email: if the link between one of these and the Primary PE fails while Primary PE remains OK, the traffic would be split.



[yshen] Packets of "one given PW" may be load-balanced over ECMP to the primary PE, due to no-CW or FAT label. In the above failure case, we only move the affected "branch of flow" over to a bypass tunnel. This shouldn't cause any issue for the CE, because either [1] the CE doesn't care about packet order (in the case where the PW has no CW), or [2] packet order of the sub-flow associated with a FAT label is still preserved.



Another aspect of this scenario is that, in the case of the Primary PE failure, each of these multiple PLRs would select the Protector as its best Next Hop to the Context ID.



[yshen] Yes, and the PLR should move packets from the bypass tunnel back to this LSP, which is now going over the new "best next hop" to the protector.  From the protector's perspective, this LSP will actually be the same as the bypass tunnel, because it's associated with the context ID FEC and hence its label still points to the context label table where PW label should be looked up. We can improve the text of the draft to explicitly clarify this.



Regards,

Sasha

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

Hi Sasha,

By "avoiding ECMP", I was strictly talking about the context ID FEC from the PLR's perspective, rather than avoiding ECMP broadly for other FECs on the PLR or any FECs on other routers.

Specifically, if the PLR has a set of ECMP to the context ID FEC, all the ECMP paths must traverse the primary PE only. This will ensure that all PWs be carried to the primary PE. And this can be achieved by using the proxy node approach suggested in this draft. The path(s) traversing the protector to reach the context ID FEC can be used as bypass LSP(s).

We can improve the text on this to make it clearer.

Thanks,

/Yimin


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


Yimin hi,

Lots of thanks for a prompt response.



I must admit that I have missed the proposal in Section 4.2.2 to treat "context ID" IP address as a proxy node that is adjacent to both the Primary PE and the Protector NEs. (It also has not been mentioned in Eriç's clarification email). I think that this approach would require certain manipulation of both the IGP and LDP, but this requires more thought on my side. One of the issues that come to mind, is the need for LDP in both these nodes to allocate a locally terminated label for the corresponding FEC while not advertising context IP address as one of the IP addresses it owns.



I think that your statement about "avoiding ECMP  scenario" is problematic, because, from my point of view,  ECMP is one of the important characteristics of LDP-based MPLS PSN.  And in any case the draft does not say anything about that (or, at least neither ECMP nor "equal cost multipath" is mentioned in the text).  If you see ECMP avoidance as a pre-condition for using the mechanism defined in draft with LDP LSPs, this should be quite explicit and detailed IMO.



I still fail to understand  what constitutes an egress AC failure in the draft and how it is different from the ingress AC failure. Unfortunately the examples you've provided in your response do not help much: e.g., a fiber cut close to  would be most probably recognized by the PE as a bi-directional AC failure, while a fiber cut that is close to CE but remote from PE would most probably not detected by the PE. (Of course if PE and CE are terminating the same fiber span, the fiber cut would be recognized by both).



My guess (FWIW) that the draft actually discusses protection of traffic in the PE --> CE direction triggered by a failure detected by the PE while leaving protection of traffic in the CE --> PE direction some other mechanism that would be triggered by CE detecting the failure. This mechanism presumably would be different from the PW redundancy mechanism because it would require that an active-active scheme for Primary and Backup  PWs.



If this guess is correct (or close to reality), I would expect some explicit text explaining it. In particular, this text should explain that "redundant PWs" mentioned in the draft are not related to "PW redundancy". The current text makes a mix of these two notions, and this definitely does not help the reader (or at least this reader :-).



Hopefully these comments would be useful.



Regards,

Sasha

________________________________
From: Yimin Shen <[e-mail]<mailto:[e-mail]>>
Sent: Friday, August 8, 2014 5:34 PM
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 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]<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 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]