RFC 7911 - Advertisement of Multiple Paths in BGP

Overview

Positive

what Ze has

Neutral

measures that are neither good news nor bad

The 8 shares marked as a part above are the whole of the 9 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: Advertisement of Multiple Paths in BGP (ADD-PATH): nine MUST-level requirements. Eight are met: 3-1 (a 4-octet Path Identifier is prepended to NLRI when ADD-PATH is negotiated), 4-1 (a single ADD-PATH capability instance lists all AFI/SAFIs), 5-1 and 5-2 (a path is sent only if the local speaker advertised Send/Both and the remote advertised Receive/Both), 5-3 (Path IDs are not added when ADD-PATH is not negotiated for the family), 5-4 (the RIB is keyed by prefix and Path ID and the egress encodes the Path ID), and 5-5 (a negotiated family's received NLRI is parsed with its 4-octet Path ID) carry positive+negative tags. 2-1 (the same prefix with different Path IDs is treated as different paths) is {single-polarity: positive}: the per-peer RIB key is (prefix, Path ID) by construction. 2-2 (a speaker re-advertising a path generates its own Path Identifier) carries positive+negative tags since 2026-08-14: ze mints its own value per ingress path in `internal/component/bgp/reactor/forward_path_id.go` and both forward rails read it, so no requirement of this RFC is a gap.

What the public ledger says

Status: Supported

What the ledger says remains:

Coverage

Positive and negative tests (9): RFC7911-2-1, RFC7911-2-2, RFC7911-3-1, RFC7911-4-1, RFC7911-5-1, RFC7911-5-2, RFC7911-5-3, RFC7911-5-4, RFC7911-5-5

Requirements

Gaps and untested MUSTs

RFC 7911 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.

RFC7911-2-1

However, the Path Identifier MUST be assigned in such a way that the BGP speaker is able to use the (Prefix, Path Identifier) to uniquely identify a path advertised to a neighbor. (Section 2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Read RFC7911 Section 2 in full and both current tagged functions. TestForwardPathIDsDifferForCollidingSources supplies two distinct ingress SourceIDs announcing the same native prefix under the same received identifier and requires different outgoing identifiers. TestForwardPathIDStableAcrossUpdates requires the first source's exact native prefix/identifier pair to remain stable after the colliding second source and a repeat advertisement. The shared output reader checks the actual prefix as well as the identifier, one complete NLRI and no trailing framing. These discriminate source collision and per-message minting without inventing a requirement that a local number differ numerically from the received number. These two carriers exercise buildFwdBody's same-context output, not a remote receiver; complementary RFC7911-2-2 carriers cover converted output and runtime writing. Inspected generatePath, canonical ingress keys, same-context rewrite, converted NLRI handling and both final writer dispatches preserve the generated association. No residual whole-clause gap identified.

RFC7911-2-2

A BGP speaker that re-advertises a route MUST generate its own Path Identifier to be associated with the re-advertised route. (Section 2)

Audit verdict: enforced (the tests do what the requirement demands), shifted: internal/le/interoplab/bgp/check_rfc.go::checkAddPathReadvertiseCollision moved. Read RFC7911 Section 2 and all current tagged carriers. Colliding sources must remain distinct for the same native prefix, while replacements and inverse withdrawals retain the locally generated association. Current assertions cover received identifiers zero and maximum, occupied wrap candidates, unframed ingress, independent destinations, IPv4 same/cross-context conversion, and IPv6 MP_REACH/MP_UNREACH same-context, cross-context and unframed-source conversion. The changed probe checks exact prefix/identifier pairing and that retiring one prefix cannot renumber another using the same ingress identifier. Churn carriers drive reactorForwardRS through actual destination writes and cache eviction, including rebuilt reflection frames and a mixed withdraw/reannounce; they check exact recipient-visible identities rather than treating internal table counts as the RFC obligation. The foreign FRR checker separately requires two source-attributed paths with distinct identifiers and stable replay; the functional carrier separately checks live/replay wire framing. Its pinned zero is a deterministic fixture expectation, not an RFC allocation rule. The allocator, rewrite, rebuilt SourceID preservation, release boundary and raw/converted writer consumers were traced. No numerical inequality from ingress, globally unique identifiers across prefixes, identical numbers across destinations or allocator reclamation policy is claimed as a normative requirement. No residual whole-clause gap identified.

RFC7911-3-1

In order to carry the Path Identifier in an UPDATE message, the NLRI encoding MUST be extended by prepending the Path Identifier field, which is of four octets. (Section 3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Sentence: NLRI encoding MUST be extended by prepending the four-octet Path Identifier field. Forbidden: no field, a field of other size, or the field placed after the prefix. TestWriteNLRI_WithStoredPathID asserts buf[0..3]==0000002a and n==4+Len() (red if absent, mis-sized, or appended, since buf[0] would then be the prefix length); TestWriteNLRI_AddPath disabled subtest asserts n==Len() without ADD-PATH; TestINETWithAddPath decodes 00000001 then 8,10 as id 1 and 10.0.0.0/8; test/plugin/adj-rib-in-replay-addpath-source.ci asserts exact wire hex 00000000180A0000 vs 180A0000 per destination negotiation. Rejudged 2026-10-17 (independent reader, not the author of 3f6bb1965e) after the owner-approved command-text change in 3f6bb1965e (injection grammar: nlri <family> became mp <family> for MP families and bare nlri for IPv4 unicast): the cmd/update units changed only the section keyword of their command arguments (nlri ipv4/mpls-label became mp ipv4/mpls-label); TestPathInformationZeroIsAnIdentifierOnTheWire still asserts the four zero octets before the labeled prefix when ADD-PATH is negotiated, and TestPathInformationIsNotWrittenWithoutTheNegotiation still asserts the wire equals the labeled NLRI without them. Package re-run green 2026-10-17. RFC 7911 Section 3: "In order to carry the Path Identifier in an UPDATE message, the NLRI encoding MUST be extended by prepending the Path Identifier field, which is of four octets." Verdict stands.

RFC7911-4-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 ADD-PATH Capability. (Section 4)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Now reads Ze's built OPEN. Positive: default send/receive over two families -> exactly one code-69 instance listing both, mode 3. Negative: per-family overrides only over three families with directions 2/1/3 -> still one instance holding all three. Judge break: config_capabilities.go appending one AddPath capability per family turned both red. Old parse-level TestAddPathCapability/TestAddPathMultipleFamilies tags are supplementary.

RFC7911-5-1

For a BGP speaker to be able to send multiple paths to its peer, that BGP speaker MUST advertise the ADD-PATH Capability with the Send/ Receive field set to either 2 or 3, and MUST receive from its peer the ADD-PATH Capability with the Send/Receive field set to either 1 or 3, for the corresponding <AFI, SAFI>. (Section 5)

Audit verdict: enforced (the tests do what the requirement demands), fresh. RFC 7911 Section 5: "For a BGP speaker to be able to send multiple paths to its peer, that BGP speaker MUST advertise the ADD-PATH Capability with the Send/Receive field set to either 2 or 3, and MUST receive from its peer the ADD-PATH Capability with the Send/Receive field set to either 1 or 3, for the corresponding <AFI, SAFI>." All three current carriers read: capability/negotiated_test.go TestNegotiateAddPath, context/rfc7911_negotiated_test.go TestFromNegotiatedAddPath (all nine direction-mode pairs), capability/rfc7911_family_scope_test.go TestRFC7911AddPathNegotiationIsPerFamily. The new matrix crosses IPv4/IPv6 and unicast/multicast, both send-capable local modes and both receive-capable peer modes, while MP negotiation offers all families; exactly the intersection family can send. Thus local Receive-only, remote Send-only, wrong AFI and wrong SAFI independently cannot grant send. Negotiate keys both mode maps by the full Family and FromNegotiatedSend/Recv preserve the directional result. This closes the prior family-blindness gap rather than merely re-sealing it. Independent source rejudgment only; no test, mutation, build or gate was executed by this auditor. Native observed-red renewal is a separate parent step. Post-lint independent source rejudgment: TestRFC7911AddPathNegotiationIsPerFamily now computes matchingFamilies = (localFamily == remoteFamily), then wantSend = matchingFamilies && (fam == localFamily). By equality transitivity this is exactly (fam == localFamily && fam == remoteFamily): false for crossed AFI or SAFI; true only for the matching queried family. All three session families are offered by MP on both sides, so lack of MP negotiation cannot mask leakage. All four local-send/remote-receive combinations and all nine family pairs still run. Re-read both companion carriers, including the nine direction-mode context matrix, and Negotiate maps indexed by the full Family. Positive and negative tags test distinct matrix inputs. Enforced remains; all four existing records on this changed unit require native renewal, which is not observed here.

RFC7911-5-2

For a BGP speaker to be able to send multiple paths to its peer, that BGP speaker MUST advertise the ADD-PATH Capability with the Send/ Receive field set to either 2 or 3, and MUST receive from its peer the ADD-PATH Capability with the Send/Receive field set to either 1 or 3, for the corresponding <AFI, SAFI>. (Section 5)

Audit verdict: enforced (the tests do what the requirement demands), fresh. RFC 7911 Section 5: "For a BGP speaker to be able to send multiple paths to its peer, that BGP speaker MUST advertise the ADD-PATH Capability with the Send/Receive field set to either 2 or 3, and MUST receive from its peer the ADD-PATH Capability with the Send/Receive field set to either 1 or 3, for the corresponding <AFI, SAFI>." All three current carriers read: capability/negotiated_test.go TestNegotiateAddPath, context/rfc7911_negotiated_test.go TestFromNegotiatedAddPath (all nine direction-mode pairs), capability/rfc7911_family_scope_test.go TestRFC7911AddPathNegotiationIsPerFamily. The new matrix crosses IPv4/IPv6 and unicast/multicast, both send-capable local modes and both receive-capable peer modes, while MP negotiation offers all families; exactly the intersection family can send. Thus local Receive-only, remote Send-only, wrong AFI and wrong SAFI independently cannot grant send. Negotiate keys both mode maps by the full Family and FromNegotiatedSend/Recv preserve the directional result. This closes the prior family-blindness gap rather than merely re-sealing it. Independent source rejudgment only; no test, mutation, build or gate was executed by this auditor. Native observed-red renewal is a separate parent step. Post-lint independent source rejudgment: the family-equality hoist preserves the truth table, not merely the assertion count. A queried family is send-enabled exactly when localFamily == remoteFamily == fam; crossed AFI, crossed SAFI, or a different queried family are false. Both remote Receive and Both and local Send and Both are crossed while MP offers all families. The companion TestNegotiateAddPath pins Both/Receive to exact Send, and TestFromNegotiatedAddPath tests all nine modes including peer Send-only disabling transmission. Negotiate reads localModes[f] and remoteModes[f] for each negotiated family. Enforced remains, with native renewal owed for both polarities of each row on the changed family-scope unit.

RFC7911-5-3

A BGP speaker MUST follow the procedures defined in [RFC4271] when generating an UPDATE message for a particular <AFI, SAFI> to a peer unless the BGP speaker advertises the ADD-PATH Capability to the peer indicating its ability to send multiple paths for the <AFI, SAFI>, and also receives the ADD-PATH Capability from the peer indicating its ability to receive multiple paths for the <AFI, SAFI> (Section 5)

Audit verdict: enforced (the tests do what the requirement demands), fresh. RFC 7911 §5, rfc/full/rfc7911.txt:241-250: 'A BGP speaker MUST follow the procedures defined in [RFC4271] when generating an UPDATE message for a particular <AFI, SAFI> to a peer unless the BGP speaker advertises the ADD-PATH Capability to the peer indicating its ability to send multiple paths for the <AFI, SAFI>, and also receives the ADD-PATH Capability from the peer indicating its ability to receive multiple paths for the <AFI, SAFI>, in which case the speaker MUST generate a route update for the <AFI, SAFI> based on the combination of the address prefix and the Path Identifier, and use the extended NLRI encodings specified in this document.' Read the full sentence, not only the short row's first clause. All five covers read: both polarities of rfc7911_family_generation_test.go::TestRFC7911GeneratedPathsAreScopedToTheNegotiatedFamily negotiate local Send/remote Receive for each of IPv4 unicast, IPv6 unicast and IPv4 multicast, call AnnounceNLRIBatch and inspect written UPDATEs. Exact concatenated NLRI equality requires IDs7/9 only for the negotiated family; other AFI/SAFI output is plain. rfc7911_forward_body_test.go::TestForwardSplitConvertsAddPathContext requires destination-context parsed splitting, size limits, fully consumed plain /24 entries and exact concatenation of all80 original prefixes without IDs. ::TestForwardSplitSameContextKeepsRawSplit requires raw split output, exact source prefixes/order, complete ADD-PATH parsing, unique local identifiers and different identifiers for the same prefixes from two sources. rfc7911_forward_path_id_gen_test.go::TestForwardPathIDLeavesNonAddPathDestinationAlone requires one raw body aliasing the original and no borrowed buffer; this last unit alone is principally a zero-copy control, not the strongest byte-content oracle, and the family/output units supply that oracle. Producers/consumers read: buildFwdBody → fwdUpdateForDestination/fwdReencodeNLRIs and raw ID regeneration; forward_pool.go::fwdBatchHandler explicitly sends both rawBodies and parsed updates then flushes. Originating AnnounceNLRIBatch uses announceFactsFor's per-family addPath, buildBatchAnnounceUpdate/writeBatchNLRI and announceBatchToPeers/sendUpdateWithSplit. Q1 yes; Q2 yes by exact byte and identifier assertions; Q3 yes through distinct family/context controls; Q4 yes for negotiated-family framing/generation, not every RFC4271 decision rule. No semantic mutant or foreign interoperability was run. Pending note: retain enforced with this full population, cross-boundary routing and evidence limitations.

RFC7911-5-4

A BGP speaker MUST follow the procedures defined in [RFC4271] when generating an UPDATE message for a particular <AFI, SAFI> to a peer unless the BGP speaker advertises the ADD-PATH Capability to the peer indicating its ability to send multiple paths for the <AFI, SAFI>, and also receives the ADD-PATH Capability from the peer indicating its ability to receive multiple paths for the <AFI, SAFI>, in which case the speaker MUST generate a route update for the <AFI, SAFI> based on the combination of the address prefix and the Path Identifier, and use the extended NLRI encodings specified in this document. (Section 5)

Audit verdict: enforced (the tests do what the requirement demands), fresh. RFC 7911 Section 5: "A BGP speaker MUST follow the procedures defined in [RFC4271] when generating an UPDATE message for a particular <AFI, SAFI> to a peer unless the BGP speaker advertises the ADD-PATH Capability to the peer indicating its ability to send multiple paths for the <AFI, SAFI>, and also receives the ADD-PATH Capability from the peer indicating its ability to receive multiple paths for the <AFI, SAFI>, in which case the speaker MUST generate a route update for the <AFI, SAFI> based on the combination of the address prefix and the Path Identifier, and use the extended NLRI encodings specified in this document." TestRFC7911GeneratedPathsAreScopedToTheNegotiatedFamily additionally sends identifiers 7 and 9 for the SAME prefix and requires both extended entries exactly; all crossed AFI/SAFI outputs remain plain. reactor_test.go TestWriteAnnounceUpdateWithAddPath contributes the width/control check (not sufficient alone); rfc7911_forward_split_test.go TestSplitUpdateAddPathEndToEnd and TestSplitUpdateEndToEnd retain exact concatenated extended/plain NLRI through splitting. Producers buildBatchAnnounceUpdate generate from each NLRI and the destination family-specific addPath fact. Prefix-only collapse, wrong identifiers, family leakage, or adding the four octets without negotiation fail. The unrelated unknown-withdraw tag is no longer attached to this row. Independent source rejudgment only; no test, mutation, build or gate was executed by this auditor. Native observed-red renewal is a separate parent step.

RFC7911-5-5

The peer SHALL act accordingly in processing an UPDATE message related to a particular <AFI, SAFI>. (Section 5)

Audit verdict: enforced (the tests do what the requirement demands), fresh. RFC 7911 Section 5: "The peer SHALL act accordingly in processing an UPDATE message related to a particular <AFI, SAFI>." Read together with the immediately preceding full send/receive negotiation and extended-(prefix,Path Identifier) encoding sentence. All four current carriers read: TestRFC7911AddPathStateAppliesPerFamily, TestEnforceRFC7606_MPAddPathLargePathIDAccepted, TestEnforceRFC7606_IPv4BodyAddPathLargePathIDAccepted and TestRFC7606Section54ReadsTypedNLRIUnderAddPath. The receive matrix positively accepts only the encoding selected for each family and negatively requires exact SessionReset on wrong framing in both IPv4/IPv6 orientations; large identifier octets isolate the framing misread. The typed test now installs a real receive context and verifies the recognized EVPN route retains its identifier while the unknown route disappears. enforceRFC7606 and typedNLRIEdit consult recvCtx.AddPathFor on the specific family. This is receive-side evidence, not an extra generation claim. Independent source rejudgment only; no test, mutation, build or gate was executed by this auditor. Native observed-red renewal is a separate parent step.

Extraction sign-off

Sections

Excluded sentences

Superseded

No document obsoletes RFC 7911, so its obligations are stated where they were written.