Job,
On 2/10/26 16:54, Job Snijders wrote:
The document highlights that if there's a need to include validation
state in a transitive fashion that it capital SHOULD be removed upon
propagation. Such things are only readily possible when the
implementations are aware of the feature to do such scrubbing. This
is generally documented in draft-haas-idr-bgp-attribute-escape (which
I need to refresh and see if I can get IDR to consider publishing).
Part of the issue being discussed in the document is a given AS's (at
a given router) perspective on validation. Any such new feature that
includes things transitively should consider including enough scoping
material to permit things to be deconsidered outside of the scoping
boundary.
With the above in mind, do you have a specific change you'd like to see
in the internet-draft under consideration?
This is the statement that is problematic:
"If local technical requirements or the implementation used by an
operator necessitates the use of transitive attributes to signal RPKI
Validation State, the operator SHOULD ensure that these attributes are
removed in NLRI announced to EBGP neighbors."
The advice is correct. However, being able to implement the SHOULD may
depend on support for that feature consistently across an AS. When that
support is not present, leaking will happen.
My suggestion is to make note that such cleanup may not be consistently
possible. It doesn't violate the SHOULD, but it leads to the conditions
this draft is intended to discuss.
PERHAPS:
This document discusses signaling locally significant RPKI Validation
States to external BGP neighbors through transitive BGP attributes.
This includes operator-specific BGP Communities to signal Validation
States, as well as any current or future standardized transitive
well-known BGP Communities denoting Validation State. Furthermore, it
is RECOMMENDED that operators also consider this guidance within
their network, i.e., between their IBGP speakers when using
[RFC8097].
Reasoning: while indeed RFC8097 communities aren't intended to be
transitive across domain boundaries, they still carry a potential for
causing (large?) churning events (a router losing its RPKI caches will
cause BGP UPDATEs for half the Internet routing table to signal a
different new non-transitive RFC8097 community to its IBGP peers) - some
of this might become externally visible depending on the exact
parameters in play.
I think I'd suggest leaving that bit of the text unchanged for the iBGP
scenario. While I agree there is churn that is associated with internal
signaling changes, it should be happening because that's intentional
operator policy.
This draft highlights the consequences when things go awry. (Yay!)
However, trying to tell an operator "you can't do these things
internally" goes exactly as one would expect when you tell an operator
"you can't do that". The easy example for validation being that ingress
marking is done, and the results of that marking are intentionally used
as part of redistribution policy at AS edges.
Also, these non-transitive communities are encoded inside an optional
*transitive* bgp path attribute.... so turmoil supposed to be internal
might be somewhat externally visible, right? But I totally agree that in
this context RFC 8097 communities are _less_ of a problem than regular
transitve communities.
This is an attribute escape consideration. If your implementation
doesn't understand extended communities, then the marking communities
will escape.
This is now where I must ask... what ASBRs are deployed these days that
don't understand them?
I'm also OK to tighten up this document's scope and focus exclusively on
EBGP and remove this sentence """Furthermore, it is RECOMMENDED that
operators also consider this guidance within their network, i.e.,
between their IBGP speakers using [RFC8097]""" entirely.
I think that helps clarity for the core scenario.
-- Jeff
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
