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 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]
