[bess] Re: EVPN Link BW community cleanup
Hi Jeff, Perfect, many thanks. Neeraj > On Jul 24, 2025, at 5:14 PM, Jeffrey Haas wrote: > > Neeraj, > >> On Thu, Jul 24, 2025 at 02:24:33PM +, 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 >> Date: Thursday, July 24, 2025 at 6:31 AM >> To: [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]
[bess] Re: EVPN Link BW community cleanup
Neeraj, On Thu, Jul 24, 2025 at 02:24:33PM +, 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 > Date: Thursday, July 24, 2025 at 6:31 AM > To: [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]
[bess] Re: EVPN Link BW community cleanup
Hi Jeff, 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? Thanks, Neeraj From: Jeffrey Haas Date: Thursday, July 24, 2025 at 6:31 AM To: [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]
