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

[Yimin Shen <[e-mail]>]

Hi Sasah,


     *   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.

EVPN can be supported in a similar manner as Layer 3 VPN, although this document doesn’t provide a detailed example.

Thanks,

-- Yimin


From: Alexander Vainshtein <[e-mail]>
Date: Thursday, November 29, 2018 at 3:50 AM
To: Yimin Shen <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: RtgDir review: draft-ietf-mpls-egress-ptotection-framework-03

Yimin,
Lots of thanks for a prompt and very encouraging response.

It seems that all my comments would be resolved with the proposed changes. I will be waiting for the next revision of the draft to confirm that.

Please see some remarks inline below.

Regards,
Sasha

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

From: Yimin Shen <[e-mail]>
Sent: Thursday, November 29, 2018 2:53 AM
To: Alexander Vainshtein <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: RtgDir review: draft-ietf-mpls-egress-ptotection-framework-03

Hi Sasha,

Thanks very much again for the detailed review and the constructive comments and suggestions!

Please see [yshen] inline below.

Thanks,
-- Yimin


From: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, November 20, 2018 at 4:41 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RtgDir review: draft-ietf-mpls-egress-ptotection-framework-03
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: <[e-mail]<mailto:[e-mail]>>, Jeyananth <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, Loa Andersson <[e-mail]<mailto:[e-mail]>>
Resent-Date: Tuesday, November 20, 2018 at 4:41 AM


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<https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_area_rtg_trac_wiki_RtgDir&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=2-nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=xu90MfAW_jm6lYh6hyEgpJehTmsKq0dHrkE5tND9658&s=lmNRlXjT4KG6xOton77vla3JlOuHmrmtA-DTbeS-eI8&e=>

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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8104&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=2-nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=xu90MfAW_jm6lYh6hyEgpJehTmsKq0dHrkE5tND9658&s=ZQnSkVQtt1y5mvUspbxj3ex47FimKytILN6VNLAAXIk&e=>.  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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_mpls_current_msg17033.html&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=2-nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=xu90MfAW_jm6lYh6hyEgpJehTmsKq0dHrkE5tND9658&s=zeQV7i8GATWDPu-c_ILYWpjPkln0Wz5-0D6Al_gpPFU&e=>. 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.

[yshen] Thanks again!

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:
     *   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”
     *   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.
     *   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

[yshen] Actually, this framework does allow a context label to point to a layer-2 switching table, if the packets coming to a protector have a layer-2 header (rather than a label or IP header) below the context label, which could be the case of MAC address table.  In theory, a context label may point to any type of look-up table. IOW, depending the use case, any meaningful context-based “layer-N” forwarding/switching is allowed by this framework. We will add a section to the end of draft to make it future compatible.[[Sasha]] Sounds good. I will be waiting for the actual text in the next revision of the draft.


  1.  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:
     *   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

     *   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
     *   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
     *   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.

[yshen] We will mention VPLS and EVPN for future study, as well as services where no other router is able to learn or establish its own connectivity with service destination in advance of a primary PE failure, to serve as a protector.[[Sasha]] This should suffice I think.


  1.  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.
     *   With this scheme, the usage of the proposed egress protection framework is quite straightforward.
     *   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
     *   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.

[yshen] We will clarify that the primary PE (PE2) may allocate VPN labels by using per-VRF, per-route, or per-interface mode. The protector (PE3) should set up the nexthop for each label route in pe2.mpls table as below:

  *   If the VPN label is a per-VRF label, the nexthop of the label route should point to the protection VRF.
  *   If the VPN label is a per-route label, the nexthop of the label route should be based on the protector’s own connectivity with the IP prefix.
  *   If the VPN label is a per-interface label, there are two cases. (A) If the distribution of IP prefixes over the interfaces on the primary PE aligns completely with the distribution of IP prefixes over the interfaces on the protector, the nexthop of the label route should point to the corresponding interface of the IP prefix on the protector. (B) Otherwise (or for simplicity), the nexthop of the label route should point to the protection VRF.
[[Sasha]] Would it not be simpler to say that, regardless of the way the primary egress PE allocates its VPN application labels, the Protector should always treat them as pointing to the relevant VRF and performing context IP forwarding? The logic that matches routes learned by the primary egress PE and by the Protector would be complicated and eventually could fall back to the same scheme – so what is the gain?


  1.  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:
     *   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)
     *   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
     *   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.
     *   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.

[yshen] We will add similar text to the draft. As a framework, the draft presents and discusses a number of options in a general manner. These options are technically equal and all feasible, although they each may have pros and cons. This is also based on our goal to make egress protection applicable to a variety of networks of different technologies. Hence, the draft does not mandate any option as a MUST. That decision of which option to use in a given network is left to the specific technology deployed and the vendors involved.
[[Sasha]] This should do it IMHO.

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.

[yshen] We will add these RFCs to the normative reference section.
[[Sasha]] And to refer to them in the “Specification of Requirements” section.

Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[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.
___________________________________________________________________________

___________________________________________________________________________

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.
___________________________________________________________________________