Hi John, I think looking at the diffs that all of my comments have made it to the new proposed text so I am not sure if what you are saying means that you have commented hinting to revert all the changes again or for some other reason.
IMO to your comment (and I did have in the past direct discussions with the original authors of RFC4360) on why the T bit was called transitive and not something else that was not just a coincidence of "similar name". It was meant to indicate transitivness as defined in base BGP spec. Cheers, R. On Fri, Aug 29, 2025 at 9:12 PM John Scudder <[email protected]> wrote: > 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]
