Hi Jeff, > If extended communities need to be propagated to the peering AS it's T bit > should be set to 0. > > Propagated != originated. >
Well the point was that if T=0 there is no problem, no doubt on what implementation should do - correct ? Or if there is the same confusion even with T=0 in ext community towards origination of the community then the new text should not be sitting under T=1 sub section only, but should be made more general. Currently it applies only to sub-sections of non-transitive ext. community flag. RFC4360 does not prohibit in any text I can find sending originated locally > extended communities with T bit set to 1. If so where does it say so ? And > if it does not prohibit it why do we again need a -bis RFC ? > > For exactly the point you're raising. While it doesn't seem to be > forbidden, multiple implementations have treated it that way and it has > resulted in interoperability issues and problematic implementation of > scenarios such as that covered in the dmz draft. > > Since you seem to not find the scenario problematic, this should suggest > you don't object to clarifying that it is explicitly permitted? > Well if each vendor's implementation bugs should result in "clarification" to the RFCs we will see lot's of -bis documents in IETF. I am not convinced this is the best path fwd. Talking with such vendors should suffice ... > Anyway the added text in this respect to *T=1* says: > > *"If the BGP speaker is attaching the community, it also sends the > community over external BGP sessions."* > > Well it is clearly too broad as written now - not acceptable IMO - very > sorry. I can see valid cases where I originate non-transitive extended > communities (other than link-bw), but I do not want to spam all of my EBGP > peers with it. So technically this needs to be deleted or at least reworded > to say for example > > *"If the BGP speaker is originating the extended community it also MAY > send it over selected external BGP sessions". * > > That wording may be better. Let's see how others react to it. > > To not lose track of it: > https://github.com/ietf-wg-idr/draft-ietf-idr-rfc4360-bis/issues/5 > Thx ! But considering that on EBGP boundaries we set next hop self and that we do > have ways to pass path metrics across with different encodings perhaps a > much better option would be to consider using new attribute instead (as > defined in: draft-ietf-idr-bgp-generic-metric) by including the link bw > into the carried accumulated metric. > > No thanks. We won't be accepting this bit of goal shifting here. > Not a goal shift. Just a practical alternative looking at big picture. The general pattern we see a need for is "transitive-enough" scoping. > Using BGP fabrics as an example, something that is fabric scoped would be > helpful. > Pretty easy to do today with either proper policy + proper ASN numbering. I am not sure how much this should be IETF duty vs operational common sense. After all, not all mountain roads have steel side bars preventing cars from falling off the cliff if the driver can not control his wheels. AS scoped helps quite a bit, but we've seen a large number of modern > scenarios where larger operators make use of more than one AS as part of > their setup. > Well I have seen such deployments 30+ years back ... so nothing surprising. > Being able to carry non-transitive attributes of various forms across > multi-AS boundaries has become a common case for implementations to need to > vary from BGP specifications. > Nope - I beg to differ. Attribute transitiveness *ONLY* defines what to do when attribute is not recognized. If you recognize it there is no restriction to pass it over ASN boundaries. And this is a good thing as it naturally limits the "escape". Overall, I'd prefer that the existing BGP confederation mechanisms were > used in such cases, but that's not what is deployed. > > We will be seeing the -oad draft hit the adoption queue soon. Its purpose > is to start addressing such multi-AS scenarios. > My personal opinion is that it is not needed. Will result in more harm then good. > Agreed. > > To your original point, an issue was opened to try to address the > recognition the original authors deserve: > > https://github.com/ietf-wg-idr/draft-ietf-idr-rfc4360-bis/issues/4 > Cool ! Regards, Robert
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
