Hi, Yingzhen & Jimmy. Thanks for the comments. How about the following change:
Current text: " 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. " New text: " By default, when a BGP speaker receives routes with non-transitive extended communities across Autonomous System or Confederation Member-AS boundaries, it *SHOULD 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. " Many Thanks! Nat On Tue, Sep 2, 2025 at 5:45 PM Dongjie (Jimmy) <jie.dong= [email protected]> wrote: > Dear chairs, > > > > I support the adoption of this work. > > > > And I agree with Yingzhen’s comment on the text in section 6. The current > text about the default behavior of the receiving BGP speaker across AS > boundary is not clear. If by default it MUST NOT remove the received > extended communities, then removing the extended communities cannot be set > as one of the “default behavior”. It is suggested that the default > behavior be specified in the draft, then it can say the behavior can be > overridden by a knob. > > > > Best regards, > > Jie > > > > *From:* Yingzhen Qu <[email protected]> > *Sent:* Tuesday, September 2, 2025 2:12 PM > *To:* Jeffrey Haas <[email protected]> > *Cc:* idr <[email protected]>; BESS <[email protected]> > *Subject:* [bess] Re: [Idr] Working Group adoption check, RFC 4360-bis, > ending 5 September, 2025. > > > > 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] > > _______________________________________________ > 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]
