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]
