Hi Jeff, Perfect, many thanks.
Neeraj > On Jul 24, 2025, at 5:14 PM, Jeffrey Haas <[email protected]> wrote: > > Neeraj, > >> On Thu, Jul 24, 2025 at 02:24:33PM +0000, Neeraj Malhotra (nmalhotr) wrote: >> Thanks for the note. Could you please check if the text added in section 7.7 >> is sufficient? This adds a reference to evpn-ipvpn-interworking draft that >> already has a section stating that attributes of type EVPN should NOT be >> preserved from EVPN to non-EVPN networks. There is also text added to >> explain why it is not beneficial to carry EVPN LBW into non-EVPN networks >> (in line with the point you have below). >> >> Wanted to refrain from this draft defining interworking behavior and instead >> leave that for the interworking draft to define. Would it be clearer instead >> if this draft also explicitly states that the attribute should be dropped? > > Avoiding redundant procedures is great. > > The detail as you mention is appropriately captured as you say: > "This extended community is defined of type 0x06 (EVPN Extended Community > Sub-Types)" > > and in ipvpn-inter... > > 5.2.4: > : As discussed in point 1, Communities, Extended Communities, Large > : Communities and Wide Communities SHOULD be preserved from the originating > : ISF route by the gateway PE. Exceptions of Extended Communities that SHOULD > : NOT be propagated are: > : > : BGP Encapsulation extended communities [RFC9012]. > : > : Route Target extended communities. Route Targets are always initialized when > : readvertising an ISF route into a different domain, i.e., they are not > : propagated. The initialized Route Target in the re-advertised ISF route may > : or may not have the same value as the Route Target of the originating ISF > : route. > : > : All the extended communities of type EVPN. > ^^^^^^^^^^ > > So, my concern is addressed. Thanks for pointing out the error of my casual > reading. > > -- Jeff > >> >> Thanks, >> Neeraj >> >> From: Jeffrey Haas <[email protected]> >> Date: Thursday, July 24, 2025 at 6:31 AM >> To: [email protected] >> <[email protected]>, [email protected] <[email protected]> >> Subject: EVPN Link BW community cleanup >> One thing I noted while browsing through the draft again after today's bess >> presentation was a lack of text regarding "cleanup" of the EVPN LBW >> community. (Although perhaps I'm browsing too shallowly.) >> >> The community is defined as transitive, and procedures exist wherein EVPN >> routes that may carry this community may be carried back and forth in >> an Internet context. This means there exists the possibility that such EVPN >> LBW communities may pass between networks where their context is different. >> That is, network 1 shouldn't use network 2's bandwidth. >> >> Community scrubbing is thus recommended. >> >> Please consider reviewing the following document's section 7.5 for some >> general wisdom and consider what text should be added to your draft that >> might be appropriate for this situation. >> >> https://datatracker.ietf.org/doc/draft-ietf-grow-routing-ops-sec-inform/ >> >> -- Jeff _______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
