Hi Robert, Your quote from RFC 4271 and discussion of Path Attribute transitivity isn’t relevant to this conversation. The former refers to bit 1 of the Attribute Flags. The current context is about the T bit of the Extended Community type field. They’re two different bits, in two different fields, and each has its own semantics, even though they’re similarly named. If 4360 intended to inherit 4271’s semantics, it could have said that. But it didn’t. Expecting implementors to intuitively know how to construe it is not a recipe for interoperable implementations.
I think there’s ample evidence that the rule of “if it ain’t broke, don’t fix it” doesn’t apply here, because examples have been provided of vendors who did implement the spec differently. Saying “oh that’s a bug in the implementation” is all very well, but that only works if you can point to specific text that is unambiguously violated. That isn’t the case here. Q.E.D. it’s a bug in the specification, and here we are. Since you agree that you “are fine to clarify” the semantics, I suggest it would be best to focus on reviewing the text if the document is adopted, and if you disagree with the semantics that are defined there, we can have a substantive discussion with reference to specifics. (I’m sure the chairs will note your objection to adoption when they evaluate the WG consensus.) —John On Aug 26, 2025, at 11:36 AM, Robert Raszuk <[email protected]> wrote: Jeff, This update has everything to do with the treatment of the T flag when interacting with iBGP vs. eBGP speakers. You're in the rough if you believe otherwise. The discussion point and your suggestion about the wording vs. attached has been already noted.[1] Please be kind to observe that T flag indicates transitiveness .. here of the specific type of extended community. Since the beginning of BGP transitiveness is about what BGP speaker has to do with UNRECOGNIZED attribute Quote from RFC4271: It is not required or expected that all BGP implementations support all optional attributes. The handling of an unrecognized optional attribute is determined by the setting of the Transitive bit in the attribute flags octet. It should be crystal clear to anyone that BGP speaker which is originating an attribute or specific type of extended community MUST recognize it. Hence it is implicit that transitiveness has nothing to do with how and where it is sent irrespective if it is set to 0 or 1 in specific type of extended community. Sure you may say that I am in rough or you may try to put your own definitions of top of BGP specifications. I am just pointing out that you are wrong. And to make it very clear I am fine to clarify (if this is really needed) one sentence can be added to say that it is fine to send originated extended community over EBGP session even it is has T bit set to 1. https://github.com/ietf-wg-idr/draft-ietf-idr-rfc4360-bis/issues/5<https://urldefense.com/v3/__https://github.com/ietf-wg-idr/draft-ietf-idr-rfc4360-bis/issues/5__;!!NEt6yMaO-gk!GVOd0lSHz-HfjsDPZEgL63Z0tgCtxf4Ru_BoKTjwIyf5sj2uGh-W9J_AX793-g8Vu5QMY0l9_qvGkA$> But I question the necessity to do so based on the BGP specification and clearly stated definition and concept of of transitiveness in BGP protocol. But I am against putting such clarification text in a place where it does not belong and leads to generate even further confusion down the road. Cheers, Robert _______________________________________________ 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]
