Hi Jeff, Thanks for reviewing this as well.
Please see my comments below, inline with [jorge]. Let me know what you think, and based on this we will add some text to clarify those points. Thanks, Jorge From: Jeffrey Haas <jh...@pfrc.org> Date: Thursday, April 25, 2024 at 7:55 AM To: draft-ietf-bess-evpn-dp...@ietf.org <draft-ietf-bess-evpn-dp...@ietf.org>, bess@ietf.org <bess@ietf.org> Cc: idr-cha...@ietf.org <idr-cha...@ietf.org> Subject: Questions about route selection in draft-ietf-bess-evpn-dpath-00 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. 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? [jorge] there was some feedback to the authors that for L2 EVPN routes people usually do not apply policies to modify attributes that affect best path selection (e.g., LOCAL_PREF, MED, etc.), and, since the domain-id of the D-PATH domains is configured on the routers, it was an easy way to influence the selection, should the operator want to do so. The scope of the (L2) EVPN route types 1,2,3 is much more constrained and controlled, and after evaluating it we included it in this draft, and it is implemented. 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. [jorge] Yes, that’s the intend. 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? [jorge] no, it is not used. The text refers to the domain-ID which is excluding the ISF_SAFI_TYPE. But if you think it is not clear, we can add some text of course. Ignoring that, is the result the same as running C's memcmp() on the two six byte values? [jorge] yes, that was the idea. We can clarify. 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? [jorge] we can add similar text with regards to upgrades if the WG thinks so, but this is a more constrained environment. There is no leaking into any family that facilitate the attribute escape, and the GWs only redistribute MAC/IP routes in the case of EVPN L2 ELAN, and AD per EVI routes in the case of EVPN VPWS. So I don’t think we as authors have any concern, but I agree with your points that we need to provide text warning the implementer about the potential consequences of inconsistent best path selection. -- 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 To unsubscribe send an email to bess-le...@ietf.org
