This is a fair point, Enke. Based on the extremely limited amount of
work in the text [1], this would normally just be something the chairs
would take up collectively. But we have enough documents in our own
edit piles right now. That's why we solicited (publicly, more than
once) for an editor.
I've pinged Srihari as last author standing for his opinion.
-- Jeff
[1] As somewhat expected, this initial blast of emails will be multiple
orders of magnitude greater than the actual diff to 4360. I may measure
this at the end of the process as a reminder that no good deed goes
unpunished.
On 8/22/25 18:18, Enke Chen wrote:
As I recall, the original authors would be given an opportunity for
the "bis" in the past. Has there been a change to the practice?
Thanks. -- Enke
On Fri, Aug 22, 2025 at 12:41 PM Robert Raszuk <[email protected]> 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.
With that please kindly clarify up front what T bit of extended
community has to do with routes ? Then please explain what is the
issue with current definition of T bit in RFC4360 in respect to
draft-ietf-bess-ebgp-dmz while in the same time it does not
collide in any way or form with draft-ietf-idr-link-bandwidth
(which is proceeding fine forward).
#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.
#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).
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
<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Didr_draft-2Dietf-2Didr-2Drfc4360-2Dbis&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=V7Z_nufM6htxuC6g9hcYAkkpVQS-JyGNHK6Wm1Nuduy7mZoMhsd9pH2Tl1JJ59w8&s=aA4LvJqHxTQVHX4BuMxr4ylT-OVoeP--MNCtTiw1BEg&e=>
[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/
<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dchairs-2Didr-2Drfc4360-2Dbis_&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=V7Z_nufM6htxuC6g9hcYAkkpVQS-JyGNHK6Wm1Nuduy7mZoMhsd9pH2Tl1JJ59w8&s=RsWS4MQQJQBvg31YK91w7KqUwmUR492AyXBTwhY74uw&e=>
There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-chairs-idr-rfc4360-bis-00
<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dchairs-2Didr-2Drfc4360-2Dbis-2D00&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=V7Z_nufM6htxuC6g9hcYAkkpVQS-JyGNHK6Wm1Nuduy7mZoMhsd9pH2Tl1JJ59w8&s=bB2Do7F9QnSCpCWzWD7pnNgyfI_dNwSGpSCPEpFN6UU&e=>
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]
_______________________________________________
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]
