Robert,
On 8/22/25 17:29, Robert Raszuk wrote:
> The only thing that is intended to be altered here is originating
> a non-transitive extended community into the next AS over.
If extended communities need to be propagated to the peering AS it's T
bit should be set to 0.
Propagated != originated.
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?
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
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.
On the other hand if we set T=0 to secure it goes only as far as
planned and no further I would recommend to resurrect AS_PATHLIMIT
idea as described in
https://datatracker.ietf.org/doc/html/draft-ietf-idr-as-pathlimit-03
Again, out of scope. The goal isn't to limit the route propagation, much
to my embarassment on accidentally claiming that as a goal. It is
solely dealing with handing a non-transitive extended community to the
adjacent AS.
Then let's observe that the concern of this going too far is likely
theoretical as the use case of draft-ietf-bess-ebgp-dmz is RFC7938
type of deployments which the risk of leaking this to the wild is
rather non existent.
I wish that was the case. An unfortunate amount of BGP trash is leaking
out of such environments right now. It's one of the problem cases that
lead to the original attribute escape conversations.
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. 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. 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.
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.
Last but worth to highlight is that the addictiveness of values
carried is completely orthogonal to the topic of specific ext.
community transitiveness across EBGP boundaries. Same naturally
applies to any policy filtering or altering.
I'm not quite able to parse the English here. Perhaps additive in the
DMZ sense?
Glad to see the agreement here. I pointed this out as a general remark
not only specific to the discussed subject RFC. We may have the very
same issue when 4271 goes to -bis soon although Tony and Sue are still
pretty active in IETF :).
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
-- Jeff
_______________________________________________
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
