Hi Robert, Thanks for your review of draft-ietf-bess-evpn-dpath. I’ll address your questions about draft-ietf-bess-evpn-ipvpn-interworking before replying to the other email. Please see in-line. Thanks, Jorge
From: Robert Raszuk <[email protected]> Date: Tuesday, April 7, 2026 at 6:34 AM To: Jorge Rabadan (Nokia) <[email protected]>, Ali Sajassi (sajassi) <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: draft-ietf-bess-evpn-ipvpn-interworking-18 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. Dear WG, Why I do realize that this doc was already approved I would like to ask a few questions - main reason being is that I am asked to review draft-ietf-bess-evpn-dpath proposed to extend further D-PATH attribute to be used with other EVPN route types. This document however is the base for the evpn-dpath draft. Q1: Draft says: Gateway PE: An Interworking PE that connects two or more distinct domains, where each domain may be either a regular domain or a composite domain. A Gateway PE may establish either IBGP (Internal BGP [RFC4271]) or EBGP (External BGP [RFC4271]) sessions with peers in the connected domains. How interconnecting two or more distinct domains can be done with IBGP ? [jorge] Note that the Gateway PE, as described in the document, is not a route reflector. It does not reflect the route, but it really imports the route in an IP-VRF and re-originates the route to advertise it to another BGP peer. So the re-origination can be done to an EBGP or an IBGP peer. That is how it is deployed in many EVPN DC Gateways. Let us know if that helps. Q2: Why this document reinvents the wheel and defines a new term "DOMAIN-ID" when semantically and syntactically it is really the very same as Site-of-Origin encoded as Route Origin (per RFC4360/RFC4364) ? Section 5.1 alludes that Route Origin "does not guarantee detection or prevention of all potential loops" - has there been discussion on this in BESS ? If so I would appreciate a link to such discussion. In fact if not adding purely for informational purposes the ISF_SAFI_TYPE this entire notion of inventing D-PATH attribute could be completely avoided with the use of AS-PATH at re-origination as well as propagation of SoO. [jorge] Good point. Route Origin (SoO) and AS_PATH were indeed considered during the design of D-PATH. If I remember correctly, the key reasons they were found insufficient are: * AS_PATH loop prevention does not work reliably in IBGP re-origination scenarios, since AS_PATH is not modified on IBGP re-originated routes by default. Gateway PEs in DC deployments frequently use IBGP, so AS_PATH alone cannot guarantee loop prevention in those cases. * SoO identifies the origin site but does not carry ordered domain traversal information, nor does it encode the ISF SAFI type of each domain traversed. D-PATH provides both, which is essential for deterministic best path selection across heterogeneous EVPN and IPVPN domains. * D-PATH also influences best path selection in a well-defined way across both EVPN and IPVPN families, which SoO was not designed to do. You are correct that ISF_SAFI_TYPE is informational, but the ordered domain sequence and its integration with best path selection are the core functional requirements that drove the definition of D-PATH as a new attribute. D-PATH was discussed extensively over many years, with IDR review from two chairs as well. D-PATH is deployed pervasively in EVPN DC Gateways today. Q3: If the interworking assumes to be also covering IPVPNs (SAFI 128) how do you deal with a pretty common situations where vanilla RFC4364 domain does not support D-PATH Attribute ? I do not see in the specification any mapping of D-PATH content to AS-PATH + SoO at re-origination. Or does this specification define as normative MUST (at least for the gateways) support for the D-PATH attribute in order to do any inter-networking ? Let's note that D-PATH being an optional attribute can be simply dropped by the other EBGP peer if not recognized. What happens then ? There is no BGP capability extension defined to indicate to the peer the requirement to support D-PATH …. [jorge] this point was raised by the IDR chairs too. The main use case was DC Gateways and EVPN / IPVPN families, and we didn’t want to define a capability to avoid upgrading route reflectors or even the rest of the leaf nodes in the DC. In most cases, only Gateways really need to understand D-PATH. Originally D-PATH was also supported by SAFI 1, but due to the potential risks and leaks into the Internet we agreed on removing support for SAFI 1. The Security Considerations section provide some information about cases where D-PATH may come from unexpected PEs. Q4: Draft says: Immediately after applying the Local Preference comparison step from [RFC4271], the PE MUST remove from consideration any routes that do not have the shortest D-PATH attribute. Routes with no D-PATH attribute are considered to have a D-PATH length of zero. Please observe that this section aims to modify BGP Best Path selection and not BGP Best Route selection steps. So what is being compared is a set of paths for a single route. You can not remove "routes" but you can remove "paths". Likewise paths which do not contain D-PATH can be considered like having D-PATH of zero length ... I suppose per this text - the most preferred as zero would be shortest. This entire section 6.1 is subject to day one errata :) Section 6.2 as well ... the draft all together uses terms: route, path, prefix pretty loosely in more casual way then a BGP specification would deserve. [jorge] Section 6.1 follows the wording and structure of RFC4271's tie-breaking procedure in Section 9.1.2.2, inserting the D-PATH comparison as an additional step in that ordered sequence. The tie-breaking criteria in RFC4271 operate on routes, so the terminology in Section 6.1 is consistent with that. The document may use those terms loosely in places, but the intent of the procedure is clear from context, and multiple independent implementations have applied it consistently and interoperably. We are open to an editorial errata to tighten the terminology if there is WG consensus to do so. Q5: Draft says: BGP speakers beyond the "walled garden" that support D-PATH and receive the attribute in SAFI 1 routes MUST apply the "treat-as-withdraw" behavior, as described in Section 4 and consistent with [RFC7606]. Does this really deserve treat-as-withdraw ? If CE receives a healthy D-PATH attribute which it understands in SAFI 1 can't it simply remove this attribute from the routes while logging a SYSLOG message ? Is there a real need to treat-as-withdraw action here ? [jorge] you are right that could have been an alternative, but that was the agreement with the IDR chairs due to the concerns raised with the potential leaking of D-PATH in the Internet. Kind regards, Robert
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
