I support the adoption of this work. The following added text in Section 6 is to clarify the behaviors with non-transitive extended communities. "
If a route has non-transitive extended communities, those communities SHOULD NOT be propagated across an Autonomous System boundary and SHOULD be removed from the route. However, non-transitive extended communities SHOULD NOT be removed when advertising the route within the same BGP AS Confederation(as defined in [RFC5065]). As part of configuration or BGP protocol extensions, BGP speakers MAY attach non-transitive extended communities to routes advertised across Autonomous System boundaries. By default, when a BGP speaker receives routes with non-transitive extended communities across Autonomous System or Confederation Member-AS boundaries, it MUST NOT remove these extended communities. This default behavior MAY be configurable. The BGP speaker SHOULD also allow local policies to match against or remove these extended communities. " I'd like to understand the reason for using "SHOULD NOT/SHOULD" in the first paragraph while "MUST NOT" in the second paragraph. Also "This default behavior MAY be configurable.", I think it should be that the draft specifies the default behavior, and there might be configuration knobs to change the behavior. Thanks, Yingzhen On Fri, Aug 22, 2025 at 12:23 PM Jeffrey Haas <[email protected]> wrote: > IDR, BESS, > > During the work driven by draft-ietf-idr-link-bandwidth, the issue of > originating non-transitive was brought up and partially discussed in the > use case work for draft-ietf-bess-ebgp-dmz. As discussed during IDR > sessions at IETFs 122 and 123, the preferred solution for addressing the > ambiguities in non-transitivity was to do a small -bis for RFC 4360. Nat > Kao has kindly agreed to be our editor to move this process along. This > document, and issues vs. it, will be managed in the IDR github.[1] > > Since this is IDR chair commissioned work to address this gap, it's our > intention to adopt this work. However, the chairs would like to provide a > review period to OBJECT to adoption. That said, if you'd like to offer > support for the work, or other technical comments, please do so in this > thread! > > This adoption check ends on 5 September. Please note this overlaps the US > Labor Day holiday and consider that in the timing of your request, in case > that's relevant. > > The scope of the commissioned work is: > > - Address open errata vs. RFC 4360 > - Address the origination and reception of non-transitive routes across > eBGP boundaries. > > The current text of the draft currently addresses these items. > > As part of reviewing this problem, the IETF archives show that there was > prior work covering this issue in > draft-decraene-idr-rfc4360-clarification-00 [2]. We've made sure to > acknowledge those prior efforts in the -bis and would request review from > those authors on this -bis. > > -- Jeff (for the IDR Chairs) > > [1] https://github.com/ietf-wg-idr/draft-ietf-idr-rfc4360-bis > [2] Bruno and company are to be commended for pressing this issue for > several years. While prior IDR mail threads seem to suggest "this works > fine was the answer", the fact that we had non-transitive behaviors as a > point of contention in the BESS LBW work means it's past time to enshrine > fixing the original criticisms in an RFC update. > > Begin forwarded message: > > *From: *[email protected] > *Subject: **I-D Action: draft-chairs-idr-rfc4360-bis-00.txt* > *Date: *August 22, 2025 at 2:46:40 PM EDT > *To: *<[email protected]> > *Reply-To: *[email protected] > > Internet-Draft draft-chairs-idr-rfc4360-bis-00.txt is now available. > > Title: BGP Extended Communities Attribute > Author: Nat Kao > Name: draft-chairs-idr-rfc4360-bis-00.txt > Pages: 13 > Dates: 2025-08-22 > > Abstract: > > This document describes the "extended community" BGP-4 attribute. > This attribute provides a mechanism for labeling information carried > in BGP-4. These labels can be used to control the distribution of > this information, or for other applications. > > This document obsoletes [RFC4360]. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-chairs-idr-rfc4360-bis/ > > There is also an HTMLized version available at: > https://datatracker.ietf.org/doc/html/draft-chairs-idr-rfc4360-bis-00 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > _______________________________________________ > I-D-Announce mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > _______________________________________________ > Idr mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
