DRAFT-ABRAITIS-IDR-ADDPATH-PATHS-LIMIT - Scalability Considerations for ADD-PATH with PATHS-LIMIT

Overview

Positive

what Ze has

Neutral

measures that are neither good news nor bad

Negative

what Ze owes

The 8 shares marked as a part above are the whole of the 4 gated MUSTs: they add to 100%. Proven by a recorded break is a share of TAGGED UNITS, a different population, so it is not one of them.

At a glance

Enrolment

Enrolled: BGP ADD-PATH Paths-Limit capability (code 76): four MUST-level requirements with positive and negative test carriers. For 3-1, coalescePathsLimit in internal/component/bgp/reactor/session_negotiate.go merges configuration and plugin declarations; TestBuildOpenCoalescesPathsLimit checks multiple families in one emitted instance and prevents repeated input instances from leaking into OPEN. For 3-2 and 3-3, core capability negotiation tests cover ADD-PATH present/absent and matching/unmatched families; for 3-4, TestParsePathsLimitDuplicateFirstWins covers retaining the first tuple and ignoring later duplicates. SHOULD-level zero handling (3-5) and session-wide sender enforcement (3-6) have separate parser, negotiation, and sender regression carriers.

What the public ledger says

Status: Supported

What the ledger says remains:

Coverage

Positive and negative tests (4): DRAFT-ABRAITIS-IDR-ADDPATH-PATHS-LIMIT-3-1, DRAFT-ABRAITIS-IDR-ADDPATH-PATHS-LIMIT-3-2, DRAFT-ABRAITIS-IDR-ADDPATH-PATHS-LIMIT-3-3, DRAFT-ABRAITIS-IDR-ADDPATH-PATHS-LIMIT-3-4

Requirements

Gaps and untested MUSTs

DRAFT-ABRAITIS-IDR-ADDPATH-PATHS-LIMIT declares no gap, and every gated MUST it carries has a test bound to it.

Proof state

A tagged unit reads unproven where no discrimination record exists for it: nothing in this tree has been observed to break it, so the claim its tag makes is unproven.

DRAFT-ABRAITIS-IDR-ADDPATH-PATHS-LIMIT-3-1

A BGP speaker that wishes to indicate support for multiple AFI/SAFIs MUST do so by including the information in a single instance of the PATHS-LIMIT capability. (§3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged on 2026-09-11 against the draft text and both carriers, after the config-parser carrier's claim was reworded. Section 3: "A BGP speaker that wishes to indicate support for multiple AFI/SAFIs MUST do so by including the information in a single instance of the PATHS-LIMIT capability." TestBuildOpenCoalescesPathsLimit is what proves it. It drives buildOpen, the one producer of ze's OPEN, with four PATHS-LIMIT inputs: an empty configured instance, a configured ipv4/unicast tuple, and two raw code-76 plugin payloads carrying a duplicate and a zero tuple. It re-parses the encoded OPEN and makes two distinct assertions, not one wearing two hats. The negative is the draft's own violation shape offered as input, several instances in and require.Len(limits, 1) out. The positive is that the information for both families travels inside that one instance, pinned as exactly [ipv4/unicast 4, ipv4/multicast 3]. buildOpen runs twice in the loop, so a second OPEN over the same caller-owned capabilities cannot leak a second instance either. The read-back drops the plugin's ipv6/unicast limit-0 tuple under 3-5, which is why the expectation names two families and not three; the instance-count assertion is untouched by that skip, so no neighbouring rule decides this one. coalescePathsLimit (internal/component/bgp/reactor/session_negotiate.go) is the enforcing function and buildOpen calls it on every OPEN. Both polarities carry a discrimination record over it: "merged == nil" -> true emits four instances and reds the negative, "seen[f]" -> true empties the merged instance and reds the positive. TestParsePeerCapabilityPathsLimitSingleInstance is a subordinate positive one hop short of the wire, and its reworded claim now matches its body: it reads the capability list parsePeerFromTree BUILDS, asserts one *capability.PathsLimit holding both configured families, and never encodes or parses an OPEN. It adds no proof of this requirement, because the regression it prevents cannot reach a peer: a parser emitting one instance per family is merged back into one by coalescePathsLimit before any OPEN is encoded, and the other readers of ps.Capabilities (configuredCapabilities, read in reactor.go and reactor_api.go) take Multiprotocol families and ConfigProvider values rather than PATHS-LIMIT framing. It stays tagged as a true config-path regression guard whose claim no longer over-states it. Whether a redundant carrier is worth keeping is an owner decision, not an audit finding. Re-read 2026-09-24 against Section 3 ("A BGP speaker that wishes to indicate support for multiple AFI/SAFIs MUST do so by including the information in a single instance of the PATHS-LIMIT capability."): the only change to TestBuildOpenCoalescesPathsLimit was the rename SetPluginCapabilityGetter to setPluginCapabilityGetter. The inputs, the require.Len(limits, 1) negative and the exact two-entry positive are unchanged, and coalescePathsLimit is untouched, so the verdict stands. Re-judged 2026-09-27 by QF-2 after the row was replaced by the verbatim §3 sentence; the obligation is the one the note above judged, and the tagged units are unchanged. Enforced stands.

DRAFT-ABRAITIS-IDR-ADDPATH-PATHS-LIMIT-3-2

The PATHS-LIMIT capability MUST be ignored if the ADD-PATH capability is not present. (§3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged on 2026-09-20 by an independent reader, after Negotiate's signature moved from (local, remote []Capability, localASN, peerASN uint32) to (local, remote []Capability, identity PeerIdentity). Inside each unit named here the change is one line, the call shape, and every assertion is byte-identical (git diff HEAD over internal/core/bgp/capability/negotiated_test.go). The new shape cannot move what these cases prove: Negotiate reads identity only where it stores LocalASN and PeerASN on the Negotiated, and where buildSubComponents copies the struct into n.Identity. No branch in Negotiate, and none in negotiatePathsLimitDirection, reads Internal or either AS number, so the iBGP verdict the struct now carries has no path to the PATHS-LIMIT maps. The identity each call passes is self-consistent too: 65001 against 65002 with Internal left false is an external session, which is what the two positional AS numbers meant before. Section 3: "The PATHS-LIMIT capability MUST be ignored if the ADD-PATH capability is not present." TestNegotiatePathsLimit is the positive: ADD-PATH both-mode for ipv4/unicast on both sides, and the two directions are pinned on exact, distinct values, the remote's 10 in PathsLimitSend and the local's 5 in PathsLimitRecv, so a direction swap and a floor reading each fail it. TestNegotiatePathsLimitNoAddPath is the negative: the same two PATHS-LIMIT capabilities with no ADD-PATH on either side, and both maps must stay at zero. The producing branch is "n.addPath[f]&direction == 0" in negotiatePathsLimitDirection (internal/core/bgp/capability/negotiated.go); remove it and the negative reads 10 and 5, so the assertion discriminates. The negative buffer holds Multiprotocol and PathsLimit only, so no neighbouring rule decides it. Ze is stricter than the sentence, because it requires the negotiated DIRECTION and not the bare presence of ADD-PATH. A limit on paths the session will never carry changes nothing on the wire, so the stricter reading implements the requirement rather than falling short of it. No discrimination record: both tags predate HEAD and the gate grandfathers them. 2026-09-26 RE-AUDIT, stale-requirement: the checklist line lost its quotation marks and gained the sentence's full stop, so it is now a verbatim span of Section 3 of rfc/drafts/draft-abraitis-idr-addpath-paths-limit.txt. The obligation is the sentence this note already quotes, and the tagged units are byte-identical (TestNegotiatePathsLimitNoAddPath re-read this pass: both PATHS-LIMIT maps must stay zero with no ADD-PATH). Verdict unchanged.

DRAFT-ABRAITIS-IDR-ADDPATH-PATHS-LIMIT-3-3

An AFI/SAFI tuple MUST be ignored if the same tuple was not received in the ADD-PATH capability. (§3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged on 2026-09-20 by an independent reader, after Negotiate's signature moved from (local, remote []Capability, localASN, peerASN uint32) to (local, remote []Capability, identity PeerIdentity). Inside each unit named here the change is one line, the call shape, and every assertion is byte-identical (git diff HEAD over internal/core/bgp/capability/negotiated_test.go). The new shape cannot move what these cases prove: Negotiate reads identity only where it stores LocalASN and PeerASN on the Negotiated, and where buildSubComponents copies the struct into n.Identity. No branch in Negotiate, and none in negotiatePathsLimitDirection, reads Internal or either AS number, so the iBGP verdict the struct now carries has no path to the PATHS-LIMIT maps. The identity each call passes is self-consistent too: 65001 against 65002 with Internal left false is an external session, which is what the two positional AS numbers meant before. Section 3: "An AFI/SAFI tuple MUST be ignored if the same tuple was not received in the ADD-PATH capability." TestNegotiatePathsLimitPartialAddPath carries both polarities on two distinct assertions, not one assertion wearing two hats: ipv4/unicast is present in ADD-PATH, so its tuple applies in both directions and is pinned at 10 and 5, and ipv6/unicast is absent from ADD-PATH while its PATHS-LIMIT tuple sits in the same capability, so both directions must stay zero. The buffer isolates this rule: both sides advertise Multiprotocol for ipv6/unicast, so ipv6 is a negotiated family and the only thing that can drop its tuple is the ADD-PATH check. Were ipv6 missing from Multiprotocol, the family intersection would decide the case and the test would prove nothing here. Same producing branch as 3-2, evaluated per family; remove it and ipv6 reads 8 and 3. No discrimination record: the tags predate HEAD. 2026-09-26 RE-AUDIT, stale-requirement: the checklist line lost its quotation marks and gained the sentence's full stop, so it is now a verbatim span of Section 3 of rfc/drafts/draft-abraitis-idr-addpath-paths-limit.txt. The obligation is the sentence this note already quotes, and the tagged units are byte-identical (TestNegotiatePathsLimitNoAddPath re-read this pass: both PATHS-LIMIT maps must stay zero with no ADD-PATH). Verdict unchanged.

DRAFT-ABRAITIS-IDR-ADDPATH-PATHS-LIMIT-3-4

If more than one tuple is received for the same AFI/SAFI pair, only the first tuple should be considered. All others MUST be ignored. (§3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. TestParsePathsLimitDuplicateFirstWins parses two ipv4/unicast tuples, limit 10 then limit 20, and requires one entry whose limit is 10. The positive is the kept value and the negative is the count, which are separate assertions over the same buffer. Removing the "seen[f]" guard in parsePathsLimit (internal/core/bgp/capability/capability.go) yields two entries, so the count assertion discriminates. No discrimination record: the tags predate HEAD. Re-judged 2026-09-27 by QF-2 after the row was replaced by the verbatim §3 sentence; the obligation is the one the note above judged, and the tagged units are unchanged. The quote adds the sentence's lowercase 'should' for the first-tuple half; TestParsePathsLimitDuplicateFirstWins asserts one entry with limit 10 from tuples 10 then 20, so keeping the second or both goes red. Enforced stands.

DRAFT-ABRAITIS-IDR-ADDPATH-PATHS-LIMIT-3-5

If the received Paths Limit is zero (0), the tuple SHOULD be ignored. (§3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged on 2026-09-20 by an independent reader, after Negotiate's signature moved from (local, remote []Capability, localASN, peerASN uint32) to (local, remote []Capability, identity PeerIdentity). Inside each unit named here the change is one line, the call shape, and every assertion is byte-identical (git diff HEAD over internal/core/bgp/capability/negotiated_test.go). The new shape cannot move what these cases prove: Negotiate reads identity only where it stores LocalASN and PeerASN on the Negotiated, and where buildSubComponents copies the struct into n.Identity. No branch in Negotiate, and none in negotiatePathsLimitDirection, reads Internal or either AS number, so the iBGP verdict the struct now carries has no path to the PATHS-LIMIT maps. The identity each call passes is self-consistent too: 65001 against 65002 with Internal left false is an external session, which is what the two positional AS numbers meant before. Section 3: "If the received Paths Limit is zero (0), the tuple SHOULD be ignored." The two parser carriers were re-read and are unchanged in the tree. parsePathsLimit marks a family seen BEFORE it skips a zero limit, which the draft requires: the first tuple is the one considered, and "All others MUST be ignored", so a first tuple of zero leaves that family with no limit whatever a later duplicate says. TestParsePathsLimitSkipZero pins the plain skip on exact entries, one entry holding ipv6 with 5, and TestParsePathsLimitZeroFirst pins that interplay on the exact entry slice, ipv4/unicast absent even though a later duplicate advertises 10. TestNegotiatePathsLimitDuplicateEntries runs one set of tuples through the direct API and through the wire parser and requires both negotiated maps to equal exactly {ipv6: 7}, with an explicit NotContains on ipv4. That assertion is a genuine 3-5 negative and not a 3-4 one in disguise: the ipv4 tuple that arrives FIRST is the zero, so an implementation that kept first-wins and dropped the zero skip would store ipv4 at 0 and the map equality would fail. All three units carry a discrimination record over "limit == 0" -> false in parsePathsLimit, under which each was observed red. Re-judged 2026-09-27 by QF-2 after the row was replaced by the verbatim §3 sentence; the obligation is the one the note above judged, and the tagged units are unchanged. Enforced stands.

DRAFT-ABRAITIS-IDR-ADDPATH-PATHS-LIMIT-3-6

A sender advertising multiple paths for the same prefix SHOULD send only the specified maximum number of paths indicated in the PATHS-LIMIT capability. (§3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. draft-abraitis-idr-addpath-paths-limit-04 §3 states: 'A sender advertising multiple paths for the same prefix SHOULD send only the specified maximum number of paths indicated in the PATHS-LIMIT capability.' This is a per-prefix path COUNT, not a maximum numeric Path Identifier. Re-read the primary clause, summary and unannotated checklist row, all three tagged covers, and their producers. TestPathsLimitSessionAcrossUpdates negotiates limit 2 separately for IPv4 and IPv6 and reads emitted socket frames: announcements must be exactly [0,1,1,4], withdrawals exactly [99,0], and a subsequent all-withheld batch must emit no bytes. These assertions distinguish excess admissions, same-ID changed-MED replacement, an unknown withdrawal that must not free capacity, and a real withdrawal followed by admission. TestPathsLimitForwardWritersShareState exercises raw and re-encoded writers against one session budget and requires exactly [5,7], excluding same-prefix ID 6 while admitting a different prefix; identifiers above the numeric limit therefore demonstrably remain legal. paths-limit-live.ci independently advertises IPv4=1 and IPv6=2 against Ze's receive request of 9 and requires ordered exact wire frames, including different-prefix ID-99 sentinels, replacements, withdrawals and explicit retries. Its final OK marker is printed by pathsLimitLive only after all operator commands and the independent peer workflow succeed, not merely after reaching the producer. Source tracing confirms initPathsLimit uses negotiated outbound limits, pathsLimitSection counts admitted identifiers per family/prefix, and filterPathsLimit supplies the final bytes to the shared socket writer. In job-final-selective-and-vpn-bindings-7b4c75a2.log, the genuine selective guard mutations are killed at the exact [5,7] assertion: guard=true yields [], guard=false yields [5,6,7]. Those observations discriminate admission behavior; the separate whole-function halt can fail at initial EOR and establishes reachability only. The corrected CI comment now accurately describes the existing executable assertions. No partial or implementation-gap annotation is needed for this clause.

DRAFT-ABRAITIS-IDR-ADDPATH-PATHS-LIMIT-3-7

An implementation SHOULD provide a configuration knob to specify the maximum number of paths to accept from a sender. (§3)

Audit verdict: weak (the tests pass over code that does not enforce the requirement), fresh. The pair over TestConfiguredPathsLimitOpen is a strong test of half the sentence and nothing tests the other half. What it checks: the container knob `session > capability > add-path > limit`, the per-family override, and the interaction with disabled, refused and required families decide the tuples encoded in the OPEN, with an omitted limit advertising none and a disabled or refused family unable to carry an orphan tuple. parseAddPathFromTree (internal/component/bgp/reactor/config_capabilities.go) derives the tuples from addPath.Families, the same slice that reaches the wire. What nothing checks, because no code does it: the draft asks for a knob that specifies "the maximum number of paths to accept from a sender", and ze's knob states a number to the peer without bounding what ze accepts. EncodingCaps.PathsLimitRecv is read by internal/core/bgp/context/context.go, internal/component/bgp/format/json.go and internal/component/bgp/reactor/negotiated.go, all of which carry it into a negotiated context or into show output, and no reader drops a received path above it. A peer that ignores the request is not policed. The verdict is weak rather than enforced because the tag ties this body to the whole requirement, and the reading under which "accept" means local enforcement is not proven by anything. The absent behavior is disclosed on the summary's Support remaining row. No discrimination record was written, because the owner's open decision on building the receive side can reword this claim, and rewording stales a record. Re-judged 2026-09-27 by QF-2 after the row was replaced by the verbatim §3 sentence; the obligation is the one the note above judged, and the tagged units are unchanged. Weak stands: the receive-side clause, 'the maximum number of paths to accept from a sender', has no enforcing code and no assertion.

Extraction sign-off

Sections

Excluded sentences

The walk over DRAFT-ABRAITIS-IDR-ADDPATH-PATHS-LIMIT declined no sentence: every site it found is mapped to a requirement.

Superseded

No document obsoletes DRAFT-ABRAITIS-IDR-ADDPATH-PATHS-LIMIT, so its obligations are stated where they were written.