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]> 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] > To unsubscribe send an email to [email protected] >
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
