Hi Jeff, > The only thing that is intended to be altered here is originating > a non-transitive extended community into the next AS over.
If extended communities need to be propagated to the peering AS it's T bit should be set to 0. RFC4360 does not prohibit in any text I can find sending originated locally extended communities with T bit set to 1. If so where does it say so ? And if it does not prohibit it why do we again need a -bis RFC ? Anyway the added text in this respect to *T=1* says: *"If the BGP speaker is attaching the community, it also sends the community over external BGP sessions."* Well it is clearly too broad as written now - not acceptable IMO - very sorry. I can see valid cases where I originate non-transitive extended communities (other than link-bw), but I do not want to spam all of my EBGP peers with it. So technically this needs to be deleted or at least reworded to say for example *"If the BGP speaker is originating the extended community it also MAY send it over selected external BGP sessions". * But considering that on EBGP boundaries we set next hop self and that we do have ways to pass path metrics across with different encodings perhaps a much better option would be to consider using new attribute instead (as defined in: draft-ietf-idr-bgp-generic-metric) by including the link bw into the carried accumulated metric. On the other hand if we set T=0 to secure it goes only as far as planned and no further I would recommend to resurrect AS_PATHLIMIT idea as described in https://datatracker.ietf.org/doc/html/draft-ietf-idr-as-pathlimit-03 Then let's observe that the concern of this going too far is likely theoretical as the use case of draft-ietf-bess-ebgp-dmz is RFC7938 type of deployments which the risk of leaking this to the wild is rather non existent. Last but worth to highlight is that the addictiveness of values carried is completely orthogonal to the topic of specific ext. community transitiveness across EBGP boundaries. Same naturally applies to any policy filtering or altering. > Noted. And also raised as a stylistic question by the chairs when we discussed the work. > We fully intend that the original authors get full recognition in the draft as originating the work. > A challenge we have in terms of process is top of line authors are expected to be responsive > on the document and would get document-related emails. Glad to see the agreement here. I pointed this out as a general remark not only specific to the discussed subject RFC. We may have the very same issue when 4271 goes to -bis soon although Tony and Sue are still pretty active in IETF :). Kind regards, Robert On Fri, Aug 22, 2025 at 10:38 PM Jeffrey Haas <[email protected]> wrote: > Robert, > On 8/22/25 15:41, Robert Raszuk wrote: > > Hi Jeff and WGs, > > #1 > > Could you kindly elaborate how changing the definition of T bit in -bis > draft does address this scope: > > - Address the origination and reception of non-transitive routes across > eBGP boundaries. > > The change in question is the poster of this message screwed up and should > have said non-transitive extended communities. So, my fault here. > > #2 > > I am completely not comfortable to adopt this document. To me RFC4360 was > always very clearly written and in fact flexibility of having opaque > transitiveness across ASNs was a good feature not a bug. > > The only thing that is intended to be altered here is originating a > non-transitive extended community into the next AS over. By direct and > exact analogy, it's the same consideration that NO_EXPORT and NO_ADVERTISE > have. If you find the document's text doesn't cover the intended semantic > appropriately, kindly submit text that clarifies it to your liking. > > This work was covered by adopted work in bess for the DMZ document, but > wasn't going to be carried over in that document since this is a general > problem. See IETF 122 and 123 presentations and even prior chair notes and > minutes. > > #3 > > I am against wiping out original authors of RFC4360 with just a few lines > of pretty much at best cosmetic changes ... replacing them with a single > name - even if such practice complies with IETF process (not sure if -bis > is even needed here). > > Noted. And also raised as a stylistic question by the chairs when we > discussed the work. We fully intend that the original authors get full > recognition in the draft as originating the work. > > A challenge we have in terms of process is top of line authors are > expected to be responsive on the document and would get document-related > emails. Of the original three authors, one is still active for IETF work. > And we've not signed Srihari up to have to deal with this bit of janitorial > work. :-) > > If we're supplied with a mechanism to carry the original authors without > the additional considerations, we'll happily do so. > > -- Jeff > > > > > Network Working Group S. Sangli > Request for Comments: 4360 D. Tappan > Category: Standards Track Cisco Systems > Y. Rekhter > Juniper Networks > February 2006 > > Kind regards, > Robert > > > > On Fri, Aug 22, 2025 at 9: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] >> >> >> _______________________________________________ >> BESS 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]
