Hi Jeff, chairs,
* 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.
I obviously support (IOW, I haven’t changed my mind).
I’ll provide a review.
It would help (me) if the datatracker would provide a diff compared to RC4360
(hacking “replace RFC4360”?). Otherwise, I’ll look at github (my understanding
is that the first github version reflects RFC4360)
On a side note, not following the BESS WG, should I understand that this still
an issue? IOW in 16 years the implementations have not been fixed?
* 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.
Looking at github, it seems to also define the filtering as a MUST for an EBGP
session, which is good IMO. (vs a SHOULD in 4360, and
draft-decraene-idr-rfc4360-clarification noted that some implementation did not
implement this filtering at all…).
2 technical questions:
* Do we want to discuss the filtering between Confederation Member-AS?
(just raising the question) Since 4360 > 3065, I would assume that authors may
have intended to filter between members, but this is not explicit.
* draft-decraene-idr-rfc4360-clarification discussed about the addition of
a non-transitive extended community on the outbound policy of an eBGP session,
while the bis is about a router “attaching the community” (I would assume on
the loc-RIB hence possibly for an internal/IBGP use only).This seems different
and crystal clear clarity would be welcomed. I would favour the former ( 😉 ) to
avoid leaking the non-transitive attribute when that was probably not intended)
Thanks
--Bruno
From: Jeffrey Haas <[email protected]>
Sent: Friday, August 22, 2025 9:23 PM
To: idr <[email protected]>
Cc: BESS <[email protected]>
Subject: [Idr] Working Group adoption check, RFC 4360-bis, ending 5 September,
2025.
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]<mailto:[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]<mailto:[email protected]>>
Reply-To: [email protected]<mailto:[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]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
