Hi Nat, Thanks for addressing my comments.
For "This default behavior MAY be configurable.", it might be better to say "The behavior MAY be configurable" or "The behavior can be changed by configuration." Thanks, Yingzhen On Tue, Sep 2, 2025 at 9:22 AM Nat Kao <[email protected]> wrote: > 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]
