Hi Jeff, Top posting for brevity - does this commit in the edit buffer incorporate your feedback?
https://github.com/job/draft-rpki-communities-harmful/commit/f7abd4baa858513fd73a1999b2a9b5964e4647d6 Kind regards, Job On Tue, Feb 10, 2026 at 06:49:09PM -0500, Jeffrey Haas wrote: > 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. ack > > > > 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. ack _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
