Thanks Ketan and Robert. I'll stop here too, as per Ketan's suggestion. But before that, just two comments in case they help.
On whether D-PATH is a good idea, people can disagree on design choices and we respect that, but operators deploying large-scale multi-domain EVPN fabrics have found it to be the right solution for their use case. So it is clearly a good idea for those deploying it. On re-origination, gateways interconnecting domains with different encapsulations or AFI/SAFIs cannot simply reflect BGP updates. In the case of EVPN-to-IPVPN, the IP-VRF route is re-originated using a different AFI/SAFI. In the case of EVPN to EVPN, the IP-VRF route is re-originated with different encapsulation parameters. Re-origination is the deployed mechanism for cross-domain tenant connectivity in heterogeneous deployments, not a workaround. D-PATH provides loop prevention in exactly that model. Robert, I'll reply to your comments in the other thread about the other draft shortly. Thanks again for reviewing. Jorge From: Robert Raszuk <[email protected]> Date: Wednesday, April 15, 2026 at 7:36 AM To: Ketan Talaulikar <[email protected]> Cc: Jorge Rabadan (Nokia) <[email protected]>; Ali Sajassi (sajassi) <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: [bess] Re: 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. HI Ketan, Indeed I very much realize that I am coming late into this. And I am coming only since I was asked to review via BGPDIR a new draft which heavily depends on the draft-ietf-bess-evpn-ipvpn-interworking. The fact that something is implemented does not make it suddenly a good idea. Propagating IBGP learned routes to another IBGP peer without enabling route reflection under "Oh we will re-originate it" is not something I endorse and that seems to be the entire culprit for draft-ietf-bess-evpn-ipvpn-interworking Kind regards, Robert On Wed, Apr 15, 2026 at 3:47 PM Ketan Talaulikar <[email protected]<mailto:[email protected]>> wrote: Hi Robert/Jorge, Much of this discussion is happening quite late, as the document is sitting in RFC Editor Q, but more importantly, it has already been implemented and deployed. At this point, perhaps we are better off focussing on any technical issues rather than alternative methods or options that weren't considered? I hope we can leverage BGPDIR for more timely reviews and discussions such as this going forward. Thanks, Ketan On Wed, Apr 15, 2026 at 12:37 AM Robert Raszuk <[email protected]<mailto:[email protected]>> wrote: Hello Jorge, Let's just focus on the points where we seems to be having different view points :) Will type in blue. 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. The above paragraph says two or more distinct domains. To me the term "domain" describes either IGP domain or BGP domain. Both are very different entities with very different properties in the view how BGP operates. This draft is about BGP extension so naturally one can expect you are talking about BGP domains. For BGP domains this would be EBGP sessions - I think there is zero doubt about this and ASBRs would be acting as gateways. For IGP domains with BGP overlay on top indeed you may have ABR acting as gateways and then you will use IBGP peering. Route Reflectors are completely orthogonal to all of the above. Bottom line the text as written is confusing. My recommendation is to specify what type of domain you have in mind. 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. My observations lead me to believe that for good or bad 90% of deployments are using EBGP in DC fabrics. And for IBGP loop prevention in all L3VPN deployments to protect control plane loops SoO is working perfectly fine. * 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. ISF_SAFI as we established is purely informational. Plays no role in BGP best path selection. The notion of "ordered domain traversal using IBGP" just hurts my brain. That's the type of "invention" I would highly recommend forgetting about in an accelerated manner ... Note that even assuming we are all operating under the same ASN ... ABRs acting as gateways can also act as RRs and then you can use CLUSTER_LIST and ORIGINSTOR_ID to prevent intra-domain loops. However what you are doing is accepting IBGP updates on one side ... claiming that gateway is "re-originating" and advertising the same updates on the other side via IBGP. I am really lacking words to describe it politely ... That is why you are also to invent a new loop free circuit breaker in the form of D-PATH ... It is absolutely not needed if whoever would deploy this service would understand BGP protocol to some min degree. * 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. There are also a number of existing ways to influence best path selection. For the application at hand cost community comes as low hanging fruit. Local Pref could be another one. * 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. Note that CLUSTER_LIST also provides an order list of cluster BGP update traverses. I am not sure about current process rules between BESS and IDR but my feeling is that the D-PATH was not sufficiently reviewed by either IDR WG or GROW WG or both. The fact that something is deployed does not make it a good idea :) 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. I am very grateful for removing it from SAFI 1 ! I would highly recommend removing it from SAFI 128. Too much is at stake there. If you want to keep it for SAFI 70 so be it ... but as explained above I am pretty convinced one can build a loop free deployment without it even for SAFI 70 today. 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. Understood. To me that language is just bringing in more confusion to the audience. Keep in mind that the same quoted RFC4271 in the body of the spec is using the correct term "paths" .. it should be clear that state machine was written by someone else :) "Paths with unrecognized transitive optional attributes SHOULD be accepted." "the same policies will apply to all destinations and paths in the equivalence class." 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. I do not follow ... What leaking ? I suggested that the D-PATH is _removed_ so no fear of leaking it anywhere. Hope you will understand my feedback and accept it as constructive ... though I admit pretty late in the game. Cheers, Robert PS. The fact that we can invent new things does not always make it a good idea .... _______________________________________________ BESS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
