I think Robert has some valid points.
    On Friday, August 22, 2025 at 12:41:53 PM PDT, 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. SangliRequest 
for Comments: 4360                                     D. TappanCategory: 
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]
  
_______________________________________________
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to