Hi Qin, Thanks for reviewing. Revision 16 addresses your comments.
Please see in-line with [jorge] for some comments about your remarks. Thanks. Jorge From: Qin Wu via Datatracker <[email protected]> Date: Friday, December 12, 2025 at 4:26 AM To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: draft-ietf-bess-evpn-ipvpn-interworking-15 ietf last call Opsdir review CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Document: draft-ietf-bess-evpn-ipvpn-interworking Title: EVPN Interworking with IPVPN Reviewer: Qin Wu Review result: Has Issues Hi, I have been selected as the Operational Directorate (opsdir) reviewer for this Internet-Draft. The Operational Directorate reviews all operational and management-related Internet-Drafts to ensure alignment with operational best practices and that adequate operational considerations are covered. A complete set of _"Guidelines for Considering Operations and Management in IETF Specifications"_ can be found at https://datatracker.ietf.org/doc/draft-opsarea-rfc5706bis/. While these comments are primarily for the Operations and Management Area Directors (Ops ADs), the authors should consider them alongside other feedback received. --- ## Summary This standard track document defines the interworking mechanisms among these BGP domains (EVPN, VPN-IP, and IP) to ensure seamless end-to-end tenant connectivity. It also defines a new BGP path Attribute for loop prevention on gateways nodes and update BGP best path selection procedure. I think this document is well written, however it seems to lack some clarity on local policy in several sections such as section 5 and section 12 and also not clear about backward compatibility. ## Major Issues 1. Section 6.1 said: " This procedure extends the standard BGP best path selection behaviour as specified in [RFC4271] for SAFI 128 and EVPN IP Prefix routes by incorporating D-PATH based tie-breaking to prefer routes that traverse the fewest Gateway PEs or domains." [Qin] This document extends standard BGP best path selection behaviour as specified in [RFC4271]? I am wondering whether there are backward compatibility issues when one PE with standard BGP best path selection support talks to the other PE with extended BGP best path selection support. [jorge] The specification has been revised to minimize the risk of backward compatibility issues: • D-PATH is valid only with SAFI 128 and EVPN ISF routes; therefore, only those routes are subject to the extended best-path selection process. • As stated in the Security Considerations section, D-PATH is intended for use in walled-garden environments without Internet connectivity. Nevertheless, the Security Considerations section also states that implementations “SHOULD enforce local policy on upgraded PEs to discard any ISF EVPN or IPVPN routes received from non-upgraded peers if such routes include a D-PATH attribute” in order to prevent potential backward compatibility issues. 2. Section 5.3 said: "If there is at least one contributing ISF route that has a different D-PATH DOMAIN-ID, the gateway PE SHOULD advertise each contributing ISF route with its own D-PATH (prepended with the gateway's domain). An implementation MAY override this behaviour, via policy, to advertise an ISF aggregate route without D-PATH in case the contributing routes did not have the same D-PATH DOMAIN-ID members." [Qin] what does the policy looks like here? local policy, does such local policy introduce inconsistent behaviour of the gateway PE? when such ISF aggregate route without D-PATH, how is such ISF aggregate Route handled? [jorge] the policy would export an aggregate ISF route without D-PATH. I modified the text adding some more details: "An implementation MAY, by local policy, override this behavior and advertise an ISF aggregate route without the D-PATH attribute when the contributing routes do not share identical D-PATH DOMAIN-ID members. In such cases, redundant gateway PEs SHOULD apply a consistent policy to prevent the advertisement of aggregate routes with inconsistent D-PATH usage into the destination domain." ## Minor issues 1. Section 1 said: "Accordingly, this document updates the BGP best path selection procedures specified in [RFC4271], but only in the context of IPVPN and EVPN families." [Qin] Is there a need to indicate update to RFC4271 in the front page? [jorge] ok, added. 2. Section 12 said: "As a further safeguard, implementations SHOULD enforce local policy on upgraded PEs to discard any ISF EVPN or IPVPN routes received from non-upgraded peers if such routes include a D-PATH attribute, to prevent unintended propagation." [Qin] what does local policy look like, policy indicating peer itself is upgraded or non-upgraded?, how does upgraded PEs with such local policy know the ISF EVPN or IPVN routes are received from non-upgraded peers? [jorge] The operator may use different ways, using management systems, based on the next-hops, communities or other indications in the routes or simply based on the peer. We just added this: "The mechanism by which an implementation determines that ISF EVPN or IPVPN routes are received from non-upgraded peers is outside the scope of this document." 3. Section 5.1 where remote IPVPN or IP-based PEs do not require the original EVPN-specific BGP Path Attributes for path selection or policy evaluation. [Qin] where EVPN-specific BGP path attributes for policy evaluation specified? RFC4271?, it will be nice to add reference for policy evluation. [jorge] it refers to the BGP path attributes used in the source domain. We clarified it changing the sentence to: "This mode is suitable for deployment scenarios where the source domain - for example, an EVPN domain - is "abstracted" and treated as a virtual CE, and where remote IPVPN or IP-based PEs do not rely on the BGP Path Attributes of the source EVPN domain for best-path selection or the application of routing policy." 4. Section 6.1 said: "These rules MUST NOT be applied to routes received under AFI/SAFI combinations other than SAFI 128 or EVPN; such routes get a treat-as-withdraw procedures as described in Section 4." [Qin] where treat-as-withdraw procedures are specified in section 4 of this document? is this paragraph related to error handling procedure apply to the D-PATH Path Attribute? How such treat-as-withdraw procedure is different from one defined in RFC7606? [jorge] we clarified: "These rules MUST NOT be applied to routes received under AFI/SAFI combinations other than SAFI 128 or EVPN; such routes - different from SAFI 128 or EVPN - get treat-as-withdraw procedures if they are received with a D-PATH attribute, as described in Section 4<https://author-tools.ietf.org/api/export/79f7fa4b-a32e-44a7-a2f0-53d056789fa5/draft-ietf-bess-evpn-ipvpn-interworking-16.html#sect-4>.” And then in section 4 there is a reference to RFC7606 for treat-as-withdraw, ## Nits s/Interworking PE Section 3/Interworking PE in Section 3 s/reoriginates/re-originates [jorge] fixed, thanks.
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
