[RTG-DIR] RtgDir review: draft-ietf-mpls-egress-ptotection-framework-03

[Alexander Vainshtein <[e-mail]>]

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir>

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.
Document: draft-ietf-mpls-egress-protection-framework-03
Reviewer: Alexander (“Sasha”) Vainshtein
Review date: 19-Nov-18
IETF LC End Date: Not known
Intend status: Standards Track

Summary:
I have some minor concerns about this document that I think should be resolved before publication.

Comments:
The draft is well written, requires from the reader has good understanding of multiple technologies including:

·         context label spaces and context labels RFC 5331

·         local and remote LFA mechanisms (RFC 5286 and RFC 7490)

·         Segment Routing Mirror SIDs (RFC 8402) and more.
I doubt it is suitable reading for a beginner, but I also doubt any required background could be skipped.

This is a framework document, with at least one “specialization” of this framework already being published as RFC 8104<https://tools.ietf.org/html/rfc8104>.  I assume that other “specialization” documents are on the way.

I have hold a very constructive off-list discussion with the authors before posting this review. Some of my comments have been already acknowledged. I would like to thank the authors and, especially, Yimin, for cooperation.

Caveat:
I have done an unsolicited review of the precursor individual draft<https://www.ietf.org/mail-archive/web/mpls/current/msg17033.html>. From my POV, the document has been quite in good shape even then, so I may be considered as positively biased (the current version acknowledges my comments). I have noticed that the majority of my then comments have been successfully resolved in the current version of the draft.

Major Issues: No major issues found

Minor Issues:


1)      The document seems to be ambiguous  with regard to expected coverage of L2VPN services by the framework it defines:

a.       On one hand, the requirement for the framework in the 2nd bullet in Section 4 says that it MUST “accommodate existing and future IP/MPLS services, including layer-2 VPNs, layer-3 VPNs, hierarchical LSP, and others”

b.       On the other hand, the overview of the framework (in Section 1) says that “When a PLR does local repair, the protector is responsible for performing "context label switching" for rerouted MPLS service packets and "context IP forwarding" for rerouted IP service packets, to allow the service packets to continue to reach the service destinations”. i.e., MAC-based switching seems to be excluded from the protector responsibility.

c.       Section 3 of the draft only defines the terms “Context label switching”  and “Context IP forwarding”. This also suggests that Context Layer-2 switching is not covered by the framework

2)      I have some doubts regarding applicability of the egress protection framework defined in the draft  to VPLS-based (RFC 4761 and/or RFC 4762)  services because:

a.       With VPLS, CE multi-homing always operates in single-active mode. As a consequence:

                                                               i.      Prior to failure of the primary egress, the VSI that represents the service in the Protector PE would not learn any MAC addresses

                                                             ii.      If the PLR redirects “known unicast” traffic intended for the primary egress PE to the protector, the VSI that locally represents protected service there would flood this traffic as “unknown unicast” and, as such, probably subject it to rate limiting.

                                                           iii.      From the POV of the customer of the VPLS service,  this means that redirecting traffic to the protecting VSI, by and of itself would not fully restore the service, since substantial part of the customer traffic would be dropped until MAC learning in the protecting VSI is completed

b.       It is also worth noting that in VPLS received application labels do not only define egress VSI as the context for the MAC-based switching but also identify remote ingress VSI for MAC learning. Extending such identification to cover also application labels of the redirected traffic looks quite non-trivial to me

c.       I see these concerns as minor issues because, as explained above, it is not clear to me whether the framework is supposed to cover VPLS services. An explicit caveat (possibly defining applicability of the framework to VPLS services as “left FFS”, or to be discussed in a separate document”) would suffice to resolve them IMHO

d.       L2VPN services that use EVPN technology would neither suffer from an empty FIB in the protecting MAC-VRF nor use EVPN application labels for MAC learning. But I cannot say whether they do or do not introduce some other issues with the proposed framework – this would require serious in-depth analysis. Meanwhile such services look to me like another case when an explicit definition of “left FFS” or “to be addressed in a separate document” would be very much in place.

3)      The example of applying the egress protection framework to BGP/MPLS IP VPN (RFC 4364) in Section 8 is explicitly restricted to scenario when both the primary egress VRF and the protector VRF use per-VRF label allocation scheme.

a.       With this scheme, the usage of the proposed egress protection framework is quite straightforward.

b.       However, RFC 4364 defines several label allocation schemes and states that the label allocation scheme can be selected independently in each PE without any impact on interoperability. It is not clear to me, to which extent IP VPN services that use different label allocation schemes in different egress PEs would be covered by the proposed framework

c.       Since we are only speaking about an example in a framework document, there is no need to describe a complete solution here. Simply noting the need for elaboration with regard to other VPN application label allocation schemes  (including the possible mismatch in the primary and protector egress PEs) and sending the reader to a (future) dedicated document would suffice IMHO.

4)      Section 5.8 describes 3 possible approaches to advertisement of the Context ID IP address in IGP. But it does not define any of these approaches as “MUST to implement”. This looks to me like an opening for interoperability issues between implementations that support different approaches. On the other hand, I am not sure whether a framework document is the right place to select a MUST to implement option, especially when the expected areas of applicability are quite different:

a.       The “proxy mode” approach imposes minimal (if any) specific requirements on the routing and TE domain (i.e., no dedicated extensions in IGP,  just support of some FRR mechanism by the signaling protocol used for the tunnel setup)

b.       The “alias mode” seems to require support of at least Segment Routing extensions to the relevant IGP in the routing domain as well as support of the Mirror SID in all potential PLRs. Therefore I think that it is a native scheme to be used in the SR-MPLS environments, but problematic in the environments that do not use SR-MPLS for setup of any LSPs

c.       The definition of the “stub link mode” is accompanied by a somewhat vague caveat: “The correctness of the egress-protected tunnels and the bypass tunnels relies on the path computations for the any-cast IP  address performed by the ingress routers and PLR.  Therefore, care MUST be taken for the applicability of this approach to a given network topology”.  Some clarification here would be welcome IMHO, especially since no analog of this mode could be found in RFC 8104.

d.       I have looked up Section 4.3 in RFC 8104 that discusses two approaches (equivalents of the Proxy and Alias modes in this draft) to advertisement of Context ID, and found the following text there (the critical fragment is highlighted):
   The mechanism in this document intends to be flexible on the approach
   used by a network, as long as it satisfies the above requirements for
   the transport tunnel path and bypass tunnel path.  In theory, the
   network can use one approach for context ID X and another approach
   for context ID Y.  For a given context ID, all relevant routers,
   including primary PE, protector, and PLR, must support and agree on
   the chosen approach.  The coordination between the routers can be
   achieved by configuration.
Adding such ( or similar) text to Section 5.8 looks to me as a reasonable compromise between being excessively strict and being excessively flexible in a framework document.
Nits:

1.       RFC 2119 is mentioned in the text, but does not appear as a Normative reference (BTW, I have pointed to this fact in my unsolicited review more than a year ago, but it still remains unresolved)

2.       RFC 8174 is neither mentioned in the text (as seems to be the norm these days) nor appears as a Normative reference.


Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________