Hi Jeff, Some explicit text would be appreciated. While escape isn't expected, we're partially having some of this review because escape has been observed from existing implementations. [jorge] OK, added some text in the security considerations section, and also in section 4. We can always improve it at a later version.
Part of the additional text you've added is this: "As an additional security mechanism, a PE following this specification that receives an EVPN route from a non-upgraded PE should discard the route via policy if the route contains the D-PATH attribute." How do you tell if the PE is "non-upgraded"? Note that such considerations were part of the reason I urged the dpath authors towards a BGP capability. :-) Note that this is for layer 2 routes that are NOT redistributed to any PE-CE protocol or any other AFI/SAFI, and the D-PATH is generated/modified exclusively by the Gateways. The gateways are typically redundant and upgraded in pairs, and they are well known in an EVPN domain. So the non-upgraded gateways are well known and if needed, it should be easy to apply a policy for routes coming from them with D-PATH. We can go through the scenarios as we did for the dpath draft, but we are confident this is a controlled walled garden layer 2 environment. The additional text is hardening the implementation in case it is needed as per your suggestion. When you say “escape has been observed from existing implementations” I assume you meant “existing implementations of dpath for ISF routes (IP reachability)”, and not for layer-2 routes, right? The text in this document indicates that this is only for routes imported in layer 2 FIBs. Thanks! Jorge From: Jeffrey Haas <jh...@pfrc.org> Date: Monday, June 24, 2024 at 6:40 AM To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> Cc: draft-ietf-bess-evpn-dp...@ietf.org <draft-ietf-bess-evpn-dp...@ietf.org>, bess@ietf.org <bess@ietf.org>, idr-cha...@ietf.org <idr-cha...@ietf.org> Subject: Re: 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. Jorge, On Jun 24, 2024, at 8:04 AM, Jorge Rabadan (Nokia) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>> wrote: I understand that for this D-PATH feature that the providers should be "mutually cooperating" and thus this may be a trivial or even silly concern. But if it ever becomes competing providers, this becomes a conversation about money. [jorge] ok, I think ask the chairs for 5 minutes at IETF120 to discuss this and bring awareness. For the moment we can leave it as is, since there are implementations doing this. Thanks for the discussion. I'll try to be available for that discussion. However, as usual, bess has conflicts with other work of interest for me. It'd be helpful if you did. I'm glad I came to the appropriate conclusion as a semi-informed reader, but for these sorts of steps having the algorithm explicitly written out can remove doubt. [jorge] hopefully the text makes it better now: “Then routes with the numerically lowest left-most Domain-ID are preferred (only the Domain-ID is compared, and not the ISF_SAFI_TYPE). Hence, routes not tied for the numerically lowest left-most Domain-ID are removed from consideration. When comparing two Domain-IDs, the two six byte values are compared starting with the Global Admin field. The lowest value in the first differing byte between the two six byte values, is considered to belong to the "numerically lowest Domain-ID"” This works. Some explicit text would be appreciated. While escape isn't expected, we're partially having some of this review because escape has been observed from existing implementations. [jorge] OK, added some text in the security considerations section, and also in section 4. We can always improve it at a later version. Part of the additional text you've added is this: "As an additional security mechanism, a PE following this specification that receives an EVPN route from a non-upgraded PE should discard the route via policy if the route contains the D-PATH attribute." How do you tell if the PE is "non-upgraded"? Note that such considerations were part of the reason I urged the dpath authors towards a BGP capability. :-) -- Jeff
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
