Hi Jeff, On Tue, Feb 10, 2026 at 01:58:08PM -0500, Jeffrey Haas wrote: > I support progression of this document to RFC. I have a few comments > that may be worth addressing prior to shipping it. > > §1 - Introduction: > > 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? > §2 - Scope > > RFC 8097 is mentioned, but the document really should mention that > their extended communities are explicitly non-transitive and thus > don't have this sort of problem. OLD: 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 well-known BGP Communities denoting Validation State (for example as specified for Extended BGP Communities in [RFC8097]). Furthermore, it is RECOMMENDED that operators also consider this guidance within their network, i.e., between their IBGP speakers. 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. 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. 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. Thoughts? > Covering a more general comment for the document, if there's a need > for service providers to utilize RPKI validity state marking for their > own internal use distinct from the RFC 8097 cases, non-transitive > extended communities can do so without issue. Non-transitive extended > communities have a permissive IANA allocation policy (FCFS). > Allocating a code point for in-AS personal use is easy enough to > justify: > > https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc4360-bis-02#name-bgp-non-transitive-extended > > Additionally note that the RFC 4360-bis work permits you to originate > a non-transitive extended community into the adjacent AS. This > provides a one-hop scopeable option as well. Thanks for sharing that comment. Kind regards, Job _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
