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]> 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]> 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]
