Authors, As part of reviewing ipvpn interworking, I also have done a higher level review of the new dpath document below.
In section 4.1, the cited rules for route selection change are: : If none of the tie-breaking rules up to (and including) rule 5 : produces a single route, the router compares the D-PATH attribute in : the remaining candidate routes: : : 1. The routes with the shortest D-PATH are preferred, hence routes : not tied for the shortest D-PATH are removed. Routes without : D-PATH are considered zero-length D-PATH. : : 2. Then routes with the numerically lowest left-most Domain-ID are : preferred, hence routes not tied for the numerically lowest left- : most Domain-ID are removed from consideration. The first step is consistent with the ipvpn-interworking document. The second step is new. What's the motivation for this second step? A consequence of this second step is that the configured domain ID, when routes are redistributed between domains, becomes a "hard yank" to influence routes to pick a specific domain. I.e.: - If there are routes with no dpath and routes with at least one dpath, the routes with no dpath will win. Effectively, the current behavior for each of the impacted document sections. - However, if the dpath is at least one, you prefer routes from the domain with the "numerially lowest" domain id. This is somewhat similar to taking BGP's BGP Identifier check at the *end* of the route selection process and moving it near to the top. I suspect this is not what you want. Other issues: "numerically lower" isn't clear with respect to a domain-id, especially with regard to the ISF_SAFI_TYPE component of it. Is that used? Ignoring that, is the result the same as running C's memcmp() on the two six byte values? As discussed in the context of the ipvpn interworking draft, changing route selection after the fact is messy and could in some cases lead to inconsistent selection within a network. However, for the route types that this procedure is recommended for, have you convinced yourselves that inconsistent selection is fine? Or will your recommendation be, similar to the ipvpn interworking draft, that the entire deployment must be upgraded to support the new procedure? -- Jeff On Tue, Apr 02, 2024 at 05:44:06AM -0700, internet-dra...@ietf.org wrote: > Internet-Draft draft-ietf-bess-evpn-dpath-00.txt is now available. It is a > work item of the BGP Enabled ServiceS (BESS) WG of the IETF. > > Title: Domain Path (D-PATH) for Ethernet VPN (EVPN) Interconnect Networks [...] > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-dpath/ _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
