Ballot for draft-ietf-sidrops-avoid-rpki-state-in-bgp
Discuss
Yes
No Objection
No Record
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
Section 2, paragraph 0 > This document discusses signaling locally significant RPKI validation > states through BGP Path Attributes propagated to EBGP neighbors. > This includes operator-specific BGP Communities to signal validation > states, as well as any current or future standardized well-known BGP > Communities denoting validation states. As BGP message churn is > associated with internal signaling changes, it is RECOMMENDED that > operators also consider the guidance (Section 5) within their > network, i.e., between their IBGP speakers. RFC 8097 defines the BGP non-transitive opaque extended community (type 0x43) for signaling RPKI validation state. Its normative text states: - Implementations SHOULD attach the community to IBGP UPDATE messages - By default, SHOULD NOT send to EBGP peers - By default, MUST drop if received from EBGP - EBGP use is explicitly permitted when adjacent ASes share administrative control or in route-server scenarios This document creates two unacknowledged conflicts: IBGP: Section 2's RECOMMENDED guidance (apply Section 5 guidance to IBGP as well) directly contradicts RFC 8097's SHOULD for IBGP use. Operators have contradictory SHOULD-level guidance from two documents, with no basis to resolve it. EBGP exceptions: RFC 8097 explicitly permits—and provides configuration guidance for—EBGP use in shared-administration and route-server scenarios. This document's Section 5 "SHOULD NOT signal... across EBGP sessions" covers these scenarios without acknowledgment. The Shepherd write-up confirms the WG discussed RFC 8097 in WGLC and decided not to reference it. That decision is not tenable: the document creates normative guidance that conflicts with a Proposed Standard, and the conflict must be explicitly addressed. The options are: reference RFC 8097 and explain the relationship; carry "Updates: RFC 8097" if superseding its IBGP recommendation and EBGP exceptions; or narrow the Section 2 IBGP recommendation to avoid the contradiction.
Section 3.1.1, paragraph 2 > * When an operator issues new ROAs for their netblocks, possibly by > issuing one ROA with a non-minimal maxLength (Section 4.3.2.2 of > [RFC9582]) covering a large number of prefixes. This may also > occur when incorrectly migrating to minimally covering ROAs > ([RFC9319]). One example of such a circumstance is when the > previous ROA is first revoked (see Section 3.1.2) and the new ROAs > are only issued after this revocation has been propagated (due to > an operational error or a bug in the issuance pipeline). Netblock is used in this section and in 3.1.2 and 4 without definition. Replace with "prefix" or "address block." (Also flagged by Routing AD Gunter Van de Velde.) Section 4, paragraph 3 > * Avoids having to resend, e.g., more than 500,000 BGP routes > towards BGP neighbors (for the own customer cone towards peers and > providers, for the full table towards customers) if the RPKI cache > crashes and RTR sessions are terminated, or if flaps in validation > are caused by other events. The 500,000-route figure is below the current global table size (>1M prefixes). The February 2024 percentage data in Section 3.4 is a point-in-time measurement. Adding a note that these represent data at time of writing would help to get a better picture. Section 5, paragraph 1 > The document acknowledges that specific operational requirements, > such as a BGP implementation used by an operator still being > dependent on annotating RPKI-derived validation states using BGP Path > Attributes, may necessitate the use of BGP path attributes to signal > validation states between BGP speakers. If this is the case, the > dependent operator MUST ensure that these attributes are removed > before announcing Network Layer Reachability Information (NLRI) to > EBGP neighbors. Depending on the supported functionality of the BGP > implementations in use in a given AS, removal of the aforementioned > attributes may not be consistently possible across the AS, leading to > the conditions this document is intended to discuss. "between BGP speakers" should read "between IBGP speakers within the same AS" — as written it could be read to include EBGP, conflicting with the preceding SHOULD NOT. (Also flagged by BGPDIR reviewer by John Scudder, thanks John.)
Excellent work from the author team and the working group.
Thanks to Scott Kelly for their secdir review.
I have read this and from a transport protocol perspective, I have no concerns.
Thank you for this work. It is an interesting read and well written text. Could you add a few words in the doc what the reader should understand when the term 'netblock' is used? Thank you, Gunter Van de Velde, Routing AD
Thanks to the authors and the WG for this document that provides important and useful guidance to the Internet Routing community. Also thanks for the discussion and addressing the concerns in my original ballot.
Thank you to Paul Kyzivat for the GENART review. ** Section 1 In the past, some operators and vendors suggested to use BGP Communities ([RFC1997] and [RFC8092]) to annotate received routes with validation states local to a router. Some claim that the practice of signaling validation states could be useful, -- Where are/have these claims being made? -- Who are these parties referenced by “some claim …”? ** Section 3.1.3 While, in general, implementations should not have bugs, operators should not make mistakes, and the network should be reliable, this is usually not the case in practice. Isn’t it a false premise that hypothetical software stack or operators don’t make mistakes/have bugs?