[cc: grow] Thanks to Paolo for also pinging grow, which I pay somewhat more foreground attention to. A few of my comments are possibly applicable to them as well.
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. §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. 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. -- Jeff > On Feb 2, 2026, at 07:59, Luigi Iannone <[email protected]> wrote: > > Dear WG > > As requested by the authors, this message starts a two-week WG Last Call for > ending on February 16th 2026. > > https://datatracker.ietf.org/doc/draft-ietf-sidrops-avoid-rpki-state-in-bgp/ > > Title: Guidance to Avoid Carrying RPKI Validation States in Transitive BGP > Path Attributes > > Abstract: > This document provides guidance to avoid carrying Resource Public Key > Infrastructure (RPKI) derived Validation States in Transitive Border > Gateway Protocol (BGP) Path Attributes. Annotating routes with > transitive attributes signaling Validation State may cause needless > flooding of BGP UPDATE messages through the global Internet routing > system, for example when Route Origin Authorizations (ROAs) are > issued, or are revoked, or when RPKI-To-Router sessions are > terminated. > Operators SHOULD ensure Validation States are not signaled in > transitive BGP Path Attributes. Specifically, Operators SHOULD NOT > associate Prefix Origin Validation state with BGP routes using > transitive BGP Communities. > > Please review this WG document and let the WG know if you agree that it is > ready to be handed over to the AD. > > If you have objections, please state your reasons why, and explain what it > would take to address your concerns. > > Note: silence IS NOT consensus. > > Thanks > > On behalf of the chairs > Luigi > _______________________________________________ > Sidrops mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
