Partial

RFC 8669 - Segment Routing Prefix Segment Identifier Extensions for BGP

Every requirement this repository extracted from RFC 8669, the tests bound to it, and what a reader has verified about them. This summary is enrolled and gated by ./le rfc check.

Overview

Positive

what Ze has

Tested both ways50.0%12 of 24 gated MUSTs

a positive test proves Ze does what the requirement demands and a negative one proves it refuses what the requirement forbids

One polarity plus reason20.8%5 of 24 gated MUSTs

the requirement admits no counter-case, so one polarity plus a recorded reason is the whole proof available for it

One polarity, unexcused0.0%0 of 24 gated MUSTs

one direction is tested, the other is neither tested nor excused, and nothing states which

Partial proof; remaining gap0.0%0 of 24 gated MUSTs

scoped tests exist; the remaining obligation is unmet or unproven, with zero whole-requirement credit

Proven by a recorded break74.7%62 of 83 tagged units

a red was observed once under a recorded procedure, and the unit, the claim and the producer it rested on still hash to what was recorded. The break is not re-run. A test pair is not a proof until one has been observed

Neutral

measures that are neither good news nor bad

Gated MUSTs24of 46 this summary declares

MUST-level requirements the gate HOLDS. A population, not a result: the shares beside it are what says how Ze stands

Out of scope0of 24 gated MUSTs

an obligation that does not bind Ze. A {not-applicable} annotation says it never bound; a {feature-declined} annotation says its condition is an optional feature Ze does not offer, and quotes the RFC sentence that makes it optional. Scope, not coverage: it stays in the denominator every share on this page is taken over

Not applicable0.0%0 of 24 gated MUSTs

a {not-applicable} annotation says the obligation does not bind Ze, so no test is owed for it. It stays in the denominator every share here is taken over

Met below Ze0.0%0 of 24 gated MUSTs

a {lower-layer} annotation says a layer under Ze performs the behavior, on state Ze installs into that layer, and names the producer that installs it. The obligation binds Ze and is met; Ze proves none of it, because its own boundary carries no value the behavior reads

Optional feature declined0.0%0 of 24 gated MUSTs

a {feature-declined} annotation says the obligation is conditional on a feature the RFC makes optional and Ze does not offer, and it quotes the sentence that makes it optional. The condition is false, so nothing is owed and nothing is missing. It stays in the denominator every share here is taken over

Negative

what Ze owes

No test at all29.2%7 of 24 gated MUSTs

no test carries the requirement id, whether or not a gap states why

The 8 shares marked as a part above are the whole of the 24 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.

How to read the colors

A color names what the measure MEANS, not how well Ze scores on it. Green is a good outcome at any value, red is a bad one, and neither a population nor a scope count is an outcome, so both take no color. The number under the label is what says how far Ze has got.

Card	Tone here	Why that color
Gated MUSTs	neutral	no color: a population is a scale, and a larger one is neither good news nor bad. It is the accounting total
Out of scope	neutral	no color: an obligation that never bound Ze is neither an achievement nor a failure, and counting it either way would be a claim
Tested both ways	ok	green at every value: a test pair is the outcome this gate exists to produce, and the share under the label is what says how far Ze has got
One polarity plus reason	ok	green at every value: where no counter-case exists, one polarity IS the complete answer, and a recorded reason is what the gate demands beside it
One polarity, unexcused	ok	green at zero, RED above it: half a proof with no reason for the other half
Partial proof; remaining gap	ok	green at zero, RED above it: a tested clause cannot prove the whole requirement
No test at all	bad	green at zero, RED above it: a binding obligation nothing exercises is a claim with nothing behind it, whether or not a reason is stated
Not applicable	neutral	no color: an obligation that never bound Ze is neither an achievement nor a failure, and counting it either way would be a claim
Met below Ze	neutral	no color: an obligation met below Ze is neither a test Ze wrote nor work Ze owes, and the two green shares above are what says how much Ze proves itself
Optional feature declined	neutral	no color: an obligation whose condition Ze never meets is neither an achievement nor a failure. The absent FEATURE is disclosed on the RFC's own status row, as an implementation gap a later scope decision can revisit
Proven by a recorded break	ok	green at every value: an observed break is the outcome the discrimination gate exists to produce. The denominator is TAGGED UNITS, not obligations, so this share is not one of the parts above
Audit verdicts	warn	RED on the first weak, wrong or unimplemented verdict, amber while a verdict is no longer current or a gated MUST is unjudged, green when every one is judged sound and current

At a glance

Field	Value
Public status	Partial
Enrolment	Enrolled
Requirements	46
Gated MUST-level	24
Not applicable, so out of scope	0
Declared gaps	7
Declared gaps a test demonstrates	0
Gated with no test	0
Nightly-only evidence	0
Test tags	83
Tagged units	83
Recorded audit verdicts	15
Discrimination records	62
Summary	`rfc/short/rfc8669.md`
Requirement shard	`rfc/requirements/rfc8669.md`
RFC text	`rfc/full/rfc8669.txt`

Enrolment

Enrolled: SR Prefix Segment Identifier Extensions for BGP

What the public ledger says

Status: Partial

What the ledger says is covered

Attribute code 40 is registered as optional transitive (internal/core/bgp/attribute/attribute.go) and carried end to end: the Label-Index TLV (type 1) and the Originator SRGB TLV (type 3) are encoded from route configuration with their Reserved and Flags octets cleared (internal/core/bgp/attribute/prefixsid.go) and attached to labeled-unicast and VPN UPDATEs (internal/component/bgp/message/update_build_labeled.go)
on reception every TLV is bounds-checked with Section 6 attribute-discard for an overrunning TLV length or trailing bytes (internal/component/bgp/message/rfc7606.go), a duplicate attribute is discarded unexamined in favor of the first for PROCESSING purposes (internal/component/bgp/message/rfc7606.go), a duplicate recognized Service TLV never displaces the first (internal/component/bgp/plugins/rib/pool/srv6sid.go), the Section 4 EBGP boundary discards the attribute unless the peer is configured to accept it (internal/component/bgp/reactor/session_validation.go), the Section 8 boundary removes it on egress toward an EBGP peer the operator has not configured for propagation, on every rail that writes an UPDATE: the two forward rails, the two origination rails and the API/readvertise announce rail all ask prefixSIDAllowedTo (internal/component/bgp/reactor/forward_prefix_sid.go, internal/component/bgp/reactor/reactor_api_batch.go), unknown TLVs and the Reserved/Flags fields are ignored and left byte-identical for propagation, and the label carried in a received labeled-unicast NLRI is the outbound label programmed toward the next hop (internal/core/bgp/nlri/nlrisplit/labeled.go to internal/plugins/fib/kernel/nexthop_linux.go). Requirements bound per line in rfc/short/rfc8669.md.

What the ledger says remains

Unproven duplicate-attribute wire handling remains recorded by RFC8669-6-2: the keep-first strip in enforceRFC7606 removes repeated attributes, but code-40 forwarding proof is still owed. Missing SR-MPLS semantics remain explicit in RFC8669-3.1-1, RFC8669-4.1-3 (conflict detection), RFC8669-4.1-4 (ignoring a "conflicting" attribute; an "invalid" one, with no Label-Index TLV, is already discarded under Section 6, proven by RFC8669-4.1-2 and RFC8669-6-1), RFC8669-4.1-5 (dynamic local label allocation), RFC8669-4.1-7 (implicit-NULL pop) and RFC8669-5.1-1 (advertised local/incoming label programming). A discarded Prefix-SID logs one ERROR record naming attribute 40 at the default level, rate-limited per peer and attribute code (Session.logRFC7606Discards, Session.logRFC7606Error), proven for RFC8669-6-4, RFC8669-4-2 and RFC8669-4.1-15 in internal/component/bgp/reactor/rfc8669_error_log_test.go. An UPDATE that discards another attribute as well logs one record for each discarded attribute, each with its own reason, so the Prefix-SID record no longer depends on which discard the validator met first (TestRFC8669PrefixSIDDiscardBesideAnotherLogsBoth). A kept Prefix-SID, well-formed or accepted from an EBGP peer configured inside the SR domain, logs no record. The Debug diagnostics with the whole UPDATE keep their proof in internal/component/bgp/reactor/rfc8669_discard_diagnostics_test.go. That proof does not establish missing conflicting-state detection.

Coverage

Bucket	Count	What it counts
Positive and negative tests	12	one part of the gated population
Annotated (including scoped evidence)	12	one part of the gated population
One polarity only	0	one part of the gated population
No test and no annotation	0	one part of the gated population
Partial proof; remaining gap (subset of annotated; zero whole-requirement credit)	0	an overlay: each of these is also counted by the part it falls in
Evidence that runs nightly only	0	an overlay: each of these is also counted by the part it falls in
Derived from other rows	1	outside the gated population: each asserts nothing and derives its state from the rows it names, which the parts above already count
Gated MUST-level requirements	24	every gated MUST falls in exactly one bucket above

Positive and negative tests (12): RFC8669-3-1, RFC8669-3.1-3, RFC8669-3.1-4, RFC8669-3.1-5, RFC8669-3.1-6, RFC8669-3.2-2, RFC8669-4-1, RFC8669-4.1-1, RFC8669-4.1-2, RFC8669-8-1, RFC8669-6-1, RFC8669-6-3

Annotated (including scoped evidence) (12): RFC8669-3.1-1, RFC8669-3.1-2, RFC8669-3.2-1, RFC8669-3.2-3, RFC8669-3.2-4, RFC8669-4.1-3, RFC8669-4.1-4, RFC8669-4.1-5, RFC8669-4.1-7, RFC8669-4.1-8, RFC8669-5.1-1, RFC8669-6-2

Derived from other rows (1): RFC8669-4.1-6

Requirements

Requirement	Level	Section	Tests
`RFC8669-3-1`	For future extensibility, unknown TLVs MUST be ignored and propagated unmodified. (§3, §6)
	MUST	3	positive`unit/verifyTestClearTransmittedLabelIndexOnlyOnLabeledUnicast` positive`unit/verifyTestRFC8669UnknownTLVIsIgnored` positive`unit/verifyTestRFC8669UnknownTLVPropagatedAcrossANextHopChange` negative`unit/verifyTestRFC8669UnknownTLVPropagatedAcrossANextHopChange` positive`functional/verifyprefixsid-malformed-receive.ci`
`RFC8669-3.1-1`	Label-Index TLV MUST be present in the BGP Prefix-SID attribute attached to IPv4/IPv6 Labeled Unicast prefixes (§3.1)
	MUST	3.1	positive`no test`no positive test negative`no test`no negative test {gap}: neither the sender nor the receiver requires TLV type 1 for labeled unicast -- validatePrefixSIDAttr accepts a Prefix-SID with no Label-Index TLV (internal/component/bgp/message/rfc7606.go:837) and BuildLabeledUnicast attaches whatever bytes the route configuration produced, including an SRv6-only attribute (internal/component/bgp/message/update_build_labeled.go:189)
`RFC8669-3.1-2`	It MUST be ignored when received for other BGP AFI/SAFI combinations. (§3.1)
	MUST	3.1	positive`unit/verifyTestClearTransmittedLabelIndexOnlyOnLabeledUnicast` positive`unit/verifyTestParsePrefixSIDAcceptsOffFamilyLabelIndexLength` positive`unit/verifyTestRFC8669LabelIndexAnyLengthIgnoredOffLabeledUnicast` positive`unit/verifyTestRFC8669LabelIndexIgnoredOnNonLabeledUnicastFamily` negative`no test`no negative test positive`functional/verifyprefixsid-malformed-receive.ci` {single-polarity}: ze has no receive-side Label-Index consumer for any family -- ExtractSRv6SIDFull steps over TLV type 1 by length (internal/component/bgp/plugins/rib/pool/srv6sid.go:47) and no other reader of TLV type 1 exists in internal/component/bgp or internal/core/bgp -- so the TLV is ignored on every AFI/SAFI and there is no label-index-driven behavior to drive negatively
`RFC8669-3.1-3`	RESERVED: 8-bit field. It MUST be clear on transmission (§3.1)
	MUST	3.1	positive`unit/verifyTestClearTransmittedLabelIndexOnlyOnLabeledUnicast` positive`unit/verifyTestRFC8669LabelIndexTLVReservedAndFlagsClearOnTransmission` positive`unit/verifyTestRFC8669LabelIndexTransmissionClearsReservedAndFlags` positive`unit/verifyTestRFC8669SRGBFormLabelIndexReservedAndFlagsClearOnTransmission` negative`unit/verifyTestRFC8669LabelIndexTransmissionClearsReservedAndFlags`
`RFC8669-3.1-4`	RESERVED: 8-bit field. It MUST be clear on transmission and MUST be ignored on reception. (§3.1)
	MUST	3.1	positive`unit/verifyTestRFC8669LabelIndexReservedAndFlagsZeroAccepted` positive`unit/verifyTestRFC8669ReservedAndFlagsClearOnTransmissionIgnoredOnReception` negative`unit/verifyTestRFC8669LabelIndexNonZeroReservedIgnored` negative`unit/verifyTestRFC8669ReservedAndFlagsClearOnTransmissionIgnoredOnReception`
`RFC8669-3.1-5`	Flags: 16 bits of flags. None are defined by this document. The Flags field MUST be clear on transmission (§3.1)
	MUST	3.1	positive`unit/verifyTestClearTransmittedLabelIndexOnlyOnLabeledUnicast` positive`unit/verifyTestRFC8669LabelIndexTLVReservedAndFlagsClearOnTransmission` positive`unit/verifyTestRFC8669LabelIndexTransmissionClearsReservedAndFlags` positive`unit/verifyTestRFC8669SRGBFormLabelIndexReservedAndFlagsClearOnTransmission` negative`unit/verifyTestRFC8669LabelIndexTransmissionClearsReservedAndFlags`
`RFC8669-3.1-6`	Flags: 16 bits of flags. None are defined by this document. The Flags field MUST be clear on transmission and MUST be ignored on reception. (§3.1)
	MUST	3.1	positive`unit/verifyTestRFC8669LabelIndexReservedAndFlagsZeroAccepted` positive`unit/verifyTestRFC8669ReservedAndFlagsClearOnTransmissionIgnoredOnReception` negative`unit/verifyTestRFC8669LabelIndexNonZeroFlagsIgnored` negative`unit/verifyTestRFC8669ReservedAndFlagsClearOnTransmissionIgnoredOnReception`
`RFC8669-3.2-1`	Flags: 16 bits of flags. None are defined in this document. The Flags field MUST be clear on transmission (§3.2)
	MUST	3.2	positive`unit/verifyTestRFC8669OriginatorSRGBTLVFlagsClearOnTransmission` negative`no test`no negative test {single-polarity}: parsePrefixSIDWithSRGB hardcodes both Flags octets to 0 on encode with no non-zero path to reject (internal/core/bgp/attribute/prefixsid.go)
`RFC8669-3.2-2`	Flags: 16 bits of flags. None are defined in this document. The Flags field MUST be clear on transmission and MUST be ignored on reception. (§3.2)
	MUST	3.2	positive`unit/verifyTestRFC8669ReservedAndFlagsClearOnTransmissionIgnoredOnReception` positive`unit/verifyTestRFC8669SRGBFlagsZeroAccepted` negative`unit/verifyTestRFC8669ReservedAndFlagsClearOnTransmissionIgnoredOnReception` negative`unit/verifyTestRFC8669SRGBNonZeroFlagsIgnored`
`RFC8669-3.2-3`	Originator SRGB TLV MUST NOT be changed during the propagation of the BGP update (§3.2)
	MUST NOT	3.2	positive`unit/verifyTestRFC8669SRGBUnchangedThroughReceiveValidation` negative`no test`no negative test {single-polarity}: no producer writes into an Originator SRGB TLV. The receive validator reads TLV headers and never writes a value (internal/component/bgp/message/rfc7606.go:837-856). The forward path's only code-40 operation is a whole-attribute suppress on a next-hop change (internal/component/bgp/reactor/peer_forward_facts.go:241) -- that removes the Originator SRGB along with everything else in the attribute rather than changing it, so it is not a counter-example to "MUST NOT be changed" but it does mean the TLV survives propagation only on the rails that keep the attribute. On those rails the SRGB octets are byte-identical, and no input produces changed SRGB bytes to drive negatively
`RFC8669-3.2-4`	The Originator SRGB TLV may only appear in a BGP Prefix-SID attribute attached to IPv4/IPv6 Labeled Unicast prefixes ([RFC8277]). It MUST be ignored when received for other BGP AFI/SAFI combinations. (§3.2)
	MUST	3.2	positive`unit/verifyTestParsePrefixSIDAcceptsOffFamilyLabelIndexLength` positive`unit/verifyTestRFC8669SRGBAnyLengthIgnoredOffLabeledUnicast` positive`unit/verifyTestRFC8669SRGBIgnoredOnNonLabeledUnicastFamily` negative`no test`no negative test {single-polarity}: ze has no receive-side Originator SRGB consumer for any family -- ExtractSRv6SIDFull steps over TLV type 3 by length (internal/component/bgp/plugins/rib/pool/srv6sid.go:47) and the only SRGB code in internal/component/bgp is the config-side encoder -- so the TLV is ignored on every AFI/SAFI and there is no SRGB-driven behavior to drive negatively
`RFC8669-4-1`	A BGP speaker receiving a BGP Prefix-SID attribute from an External BGP (EBGP) neighbor residing outside the boundaries of the SR domain MUST discard the attribute unless it is configured to accept the attribute from the EBGP neighbor. (§4)
	MUST	4	positive`unit/verifyTestRFC8669PrefixSIDFromEBGPAcceptedWhenConfigured` positive`unit/verifyTestRFC8669PrefixSIDKeptPathsKeepExactlyOneCopy` negative`unit/verifyTestRFC8669PrefixSIDEveryOccurrenceDiscardedFromEBGP` negative`unit/verifyTestRFC8669PrefixSIDFromEBGPDiscardedByDefault`
`RFC8669-4.1-1`	When the BGP Prefix-SID attribute is attached to a BGP Labeled IPv4 or IPv6 Unicast [RFC8277] AFI/SAFI, it MUST contain the Label-Index TLV (§4.1)
	MUST	4.1	positive`unit/verifyTestRFC8669ConformingTLVLengthsAcceptedOnLabeledUnicast` negative`unit/verifyTestRFC8669NoLabelIndexInvalidOnLabeledUnicast`
`RFC8669-4.1-2`	A BGP Prefix-SID attribute received without a Label-Index TLV MUST be considered to be "invalid" by the receiving speaker. (§4.1)
	MUST	4.1	positive`unit/verifyTestRFC8669NoLabelIndexInvalidOnLabeledUnicast` negative`unit/verifyTestRFC8669NoLabelIndexInvalidOnLabeledUnicast` negative`functional/verifyprefixsid-malformed-receive.ci`
`RFC8669-4.1-3`	If multiple different prefixes are received with the same label index, all of the different prefixes MUST have their BGP Prefix-SID attribute considered to be "conflicting". (§4.1)
	MUST	4.1	positive`no test`no positive test negative`no test`no negative test {gap}: ze keeps no label-index-to-prefix reverse index and reads no label index at all -- the only reader of the Prefix-SID TLV list is the SRv6 extractor, which skips TLV type 1 (internal/component/bgp/plugins/rib/pool/srv6sid.go:47), so no conflict can be detected
`RFC8669-4.1-4`	When a BGP speaker receives a path from a neighbor with an "invalid" or "conflicting" BGP Prefix-SID attribute, or when a BGP speaker receives a path from a neighbor with a BGP Prefix-SID attribute but is unable to process it (e.g., local policy disables the functionality), it MUST ignore the BGP Prefix-SID attribute. (§4.1)
	MUST	4.1	positive`no test`no positive test negative`no test`no negative test {gap}: the "invalid" half is implemented and the "conflicting" half is absent. A labeled-unicast Prefix-SID with no Label-Index TLV is classified PrefixSIDInvalidAttribute (internal/core/bgp/attribute/prefixsid_classify.go, ClassifyPrefixSID) and validatePrefixSIDValue maps it to attribute-discard (internal/component/bgp/message/rfc7606.go), so the attribute is ignored and not relayed; TestRFC8669InvalidPrefixSIDLoggedAtDefaultLevel drives it through enforceRFC7606 and RFC8669-4.1-2 is proven both ways. The "conflicting" state is never computed: ze reads no label index and derives no label against a configured SRGB (see RFC8669-4.1-3), so nothing triggers ignoring a conflicting attribute. Ze derives no label from any Label-Index, so no SR-MPLS behavior follows from an attribute it is unable to process
`RFC8669-4.1-5`	For the purposes of label allocation, a BGP speaker MUST assign a local (also called dynamic) label (non-SRGB) for such a prefix as per classic Multiprotocol BGP IPv4/IPv6 Labeled Unicast ([RFC8277]) operation. (§4.1)
	MUST	4.1	positive`no test`no positive test negative`no test`no negative test {gap}: ze allocates no local label for a BGP prefix at all -- the label programmed for a labeled-unicast route is the one carried in the received NLRI (internal/component/bgp/plugins/rib/rib_bestchange.go:900), and the only MPLS ingress allocators are LDP and RSVP-TE (internal/plugins/ldp/fib.go:135, internal/plugins/rsvpte/fib.go:45)
`RFC8669-4.1-6`	In the case of an "invalid" BGP Prefix-SID attribute, a BGP speaker MUST follow the error-handling rules specified in Section 6. (§4.1)
	MUST	4.1	positive`no test`no positive test negative`no test`no negative test {rollup}: RFC8669-4.1-2, RFC8669-6-1; the sentence asserts nothing of its own and binds the "invalid" verdict (RFC8669-4.1-2, a Prefix-SID received without a Label-Index TLV) to the Section 6 rule for "a malformed or invalid BGP Prefix-SID attribute attached to an IPv4/ IPv6 Labeled Unicast prefix" (RFC8669-6-1). ClassifyPrefixSID returns PrefixSIDInvalidAttribute and validatePrefixSIDValue answers attribute-discard for it, which TestRFC8669InvalidPrefixSIDLoggedAtDefaultLevel drives through enforceRFC7606 derived: met
`RFC8669-4.1-7`	Specifically, a BGP speaker receiving a prefix with a BGP Prefix-SID attribute and a label NLRI field of Implicit NULL [RFC3032] from a neighbor MUST adhere to standard behavior and program its MPLS data plane to pop the top label when forwarding traffic to the prefix. (§4.1)
	MUST	4.1	positive`no test`no positive test negative`no test`no negative test {gap}: the received NLRI label is programmed as an MPLS encapsulation without any implicit-NULL exception -- validateMPLSLabels accepts label 3 like any other value (internal/plugins/fib/kernel/mpls.go:23) and buildMPLSEncap pushes whatever labels it is given (internal/plugins/fib/kernel/nexthop_linux.go:75), so an implicit-NULL labeled-unicast route is programmed as a push of label 3 rather than a pop
`RFC8669-4.1-8`	The label NLRI defines the outbound label that MUST be used by the receiving node (§4.1)
	MUST	4.1	positive`unit/verifyTestRFC8669NLRILabelIsTheOutboundLabel` negative`no test`no negative test {single-polarity}: the label taken off the received NLRI is carried unchanged to the forwarding plane (internal/core/bgp/nlri/nlrisplit/labeled.go:110 to internal/component/bgp/plugins/rib/rib_bestchange.go:900 to internal/plugins/fib/kernel/nexthop_linux.go:75); the rule states which label to use, not a condition to reject, so there is no non-conforming input whose rejection could be asserted
`RFC8669-5.1-1`	In all cases, the Label field of the advertised NLRI ([RFC8277] [RFC4364]) MUST be set to the local/incoming label programmed in the MPLS data plane for the given advertised prefix. (§5.1)
	MUST	5.1	positive`no test`no positive test negative`no test`no negative test {gap}: BuildLabeledUnicastNLRIBytes writes the label taken from the route configuration into the NLRI (internal/component/bgp/message/update_build_labeled.go:278, fed by internal/component/bgp/reactor/peer_static_routes.go:86) and nothing programs a matching incoming MPLS entry -- the only emitters of MPLS ingress/transit entries are LDP and RSVP-TE (internal/plugins/ldp/fib.go:135, internal/plugins/rsvpte/fib.go:50)
`RFC8669-8-1`	The propagation to other ASes MUST be explicitly configured (§8)
	MUST	8	positive`unit/verifyTestAnnounceRailKeepsPrefixSIDInsideTheSRDomain` positive`unit/verifyTestPrefixSIDEgressBoundary` positive`unit/verifyTestPrefixSIDOriginationBoundary` positive`unit/verifyTestStaleReadvertiseKeepsPrefixSIDInsideTheSRDomain` negative`unit/verifyTestAnnounceRailKeepsPrefixSIDInsideTheSRDomain` negative`unit/verifyTestPrefixSIDEgressBoundary` negative`unit/verifyTestPrefixSIDOriginationBoundary` negative`unit/verifyTestStaleReadvertiseKeepsPrefixSIDInsideTheSRDomain` positive`functional/verifyprefixsid-announce-rail-boundary.ci` positive`functional/verifyprefixsid-ebgp-egress-boundary.ci` negative`functional/verifyprefixsid-announce-rail-boundary.ci` negative`functional/verifyprefixsid-ebgp-egress-boundary.ci`
`RFC8669-6-1`	When a BGP speaker receives a BGP UPDATE message containing a malformed or invalid BGP Prefix-SID attribute attached to an IPv4/ IPv6 Labeled Unicast prefix ([RFC8277]), it MUST ignore the received BGP Prefix-SID attribute and not advertise it to other BGP peers. (§6)
	MUST	6	positive`unit/verifyTestRFC8669ConformingTLVLengthsAcceptedOnLabeledUnicast` positive`unit/verifyTestRFC8669WellFormedAttributeAccepted` negative`unit/verifyTestRFC8669EmptyAttributeMalformed` negative`unit/verifyTestRFC8669LabelIndexLengthMalformedOnLabeledUnicast` negative`unit/verifyTestRFC8669MalformedAttributeDiscardedAndNotAdvertised` negative`unit/verifyTestRFC8669SRGBLengthMalformedOnLabeledUnicast` negative`unit/verifyTestRFC8669TrailingBytesDiscarded` negative`functional/verifyprefixsid-malformed-receive.ci`
`RFC8669-6-2`	As per [RFC7606], if the BGP Prefix-SID attribute appears more than once in an UPDATE message, all the occurrences of the attribute other than the first one SHALL be discarded and the UPDATE message will continue to be processed. (§6)
	SHALL	6	positive`no test`no positive test negative`no test`no negative test {gap}: unproven for code 40, no longer unimplemented. The processing half holds -- an already-seen non-MP attribute code is skipped without validation (internal/component/bgp/message/rfc7606.go, ValidateUpdateRFC7606) and recorded in DuplicateRanges, on the attribute-discard result as well as the clean one. The wire half is the RFC 7606 Section 3.g keep-first strip in enforceRFC7606 (internal/component/bgp/reactor/session_validation.go), which removes every recorded later copy through StripAttrRanges before the in-place attribute discard runs, so a malformed first occurrence is tombstoned and its duplicate is gone too. What is missing is the proof: no test tagged to this row drives a repeated code 40 through enforceRFC7606 and reads the bytes forwarded on
`RFC8669-6-3`	Similarly, if a recognized TLV appears more than once in a BGP Prefix-SID attribute while the specification only allows for a single occurrence, then all the occurrences of the TLV other than the first one SHALL be discarded and the Prefix-SID attribute will continue to be processed. (§6)
	SHALL	6	positive`unit/verifyTestRFC8669DuplicateRecognizedTLVFirstWins` positive`unit/verifyTestRFC8669DuplicateServiceTLVDiscardedOnReceive` negative`unit/verifyTestRFC8669DuplicateRecognizedTLVCannotOverrideFirst` negative`unit/verifyTestRFC8669SingleOccurrencePrefixSIDKeptWhole` positive`functional/verifyprefixsid-duplicate-tlv-relay.ci`
`RFC8669-4-2`	A BGP speaker SHOULD log an error for further analysis when discarding an attribute. (§4)
	SHOULD	4	positive`unit/verifyTestRFC8669EBGPBoundaryDiscardLoggedAtDefaultLevel` positive`unit/verifyTestRFC8669PrefixSIDDiscardBesideAnotherLogsBoth` negative`unit/verifyTestRFC8669EBGPAcceptedPrefixSIDNoErrorLog`
`RFC8669-6-4`	When discarding an attribute, a BGP speaker SHOULD log an error for further analysis. (§6)
	SHOULD	6	positive`unit/verifyTestRFC8669MalformedPrefixSIDDiscardDiagnostic` positive`unit/verifyTestRFC8669PrefixSIDDiscardBesideAnotherLogsBoth` positive`unit/verifyTestRFC8669PrefixSIDDiscardLoggedAtDefaultLevel` negative`unit/verifyTestRFC8669CleanPrefixSIDNoDiscardDiagnostic` negative`unit/verifyTestRFC8669CleanPrefixSIDNoErrorLog`
`RFC8669-4.1-9`	If multiple valid paths for the same prefix are received from multiple BGP speakers or, in the case of [RFC7911], from the same BGP speaker, and the BGP Prefix-SID attributes do not contain the same label index, then the label index from the best path BGP Prefix-SID attribute SHOULD be chosen with a notable exception being when [RFC5004] is being used to dampen route changes. (§4.1)
	SHOULD	4.1	positive`no test`no positive test negative`no test`no negative test
`RFC8669-4.1-10`	When a BGP speaker receives a path from a neighbor with an "acceptable" BGP Prefix-SID attribute and that path is selected as the best path, it SHOULD program the derived label as the label for the prefix in its local MPLS data plane. (§4.1)
	SHOULD	4.1	positive`no test`no positive test negative`no test`no negative test
`RFC8669-4.1-11`	In the case of a "conflicting" BGP Prefix-SID attribute, a BGP speaker SHOULD NOT treat it as an error (§4.1)
	SHOULD NOT	4.1	positive`no test`no positive test negative`no test`no negative test
`RFC8669-4.1-12`	In the case of a "conflicting" BGP Prefix-SID attribute, a BGP speaker SHOULD NOT treat it as an error and SHOULD propagate the attribute unchanged. (§4.1)
	SHOULD	4.1	positive`no test`no positive test negative`no test`no negative test
`RFC8669-4.1-13`	A BGP speaker SHOULD log a warning for further analysis, i.e., in the case the conflict is not due to a label-index transition. (§4.1)
	SHOULD	4.1	positive`no test`no positive test negative`no test`no negative test
`RFC8669-4.1-14`	When a BGP Prefix-SID attribute changes and transitions from "conflicting" to "acceptable", the BGP Prefix-SID attributes for other prefixes may also transition to "acceptable" as well. Implementations SHOULD ensure all impacted prefixes revert to using the label indices corresponding to these newly "acceptable" BGP Prefix-SID attributes. (§4.1)
	SHOULD	4.1	positive`no test`no positive test negative`no test`no negative test
`RFC8669-4.1-15`	A BGP speaker SHOULD log an error for further analysis. (§4.1)
	SHOULD	4.1	positive`unit/verifyTestRFC8669InvalidPrefixSIDDiscardBesideAnotherLogsBoth` positive`unit/verifyTestRFC8669InvalidPrefixSIDLoggedAtDefaultLevel` negative`unit/verifyTestRFC8669CleanPrefixSIDNoErrorLog`
`RFC8669-5-1`	A BGP speaker that advertises a path received from one of its neighbors SHOULD advertise the BGP Prefix-SID received with the path without modification as long as the BGP Prefix-SID was acceptable. (§5)
	SHOULD	5	positive`no test`no positive test negative`no test`no negative test
`RFC8669-5.1-2`	Since the label-index value must be unique within an SR domain, by default an implementation SHOULD NOT advertise the BGP Prefix-SID attribute outside an AS unless it is explicitly configured to do so. (§5.1)
	SHOULD NOT	5.1	positive`no test`no positive test negative`no test`no negative test
`RFC8669-8-2`	By default, a BGP Prefix-SID attribute SHOULD NOT be attached to a prefix and advertised. (§8)
	SHOULD NOT	8	positive`no test`no positive test negative`no test`no negative test
`RFC8669-8-3`	Hence, BGP Prefix-SID Advertisement SHOULD require explicit enablement. (§8)
	SHOULD	8	positive`no test`no positive test negative`no test`no negative test
`RFC8669-5-2`	In order to prevent distribution of the BGP Prefix-SID attribute beyond its intended scope of applicability, attribute filtering SHOULD be deployed to remove the BGP Prefix-SID attribute at the administrative boundary of the SR domain. (§5)
	SHOULD	5	positive`no test`no positive test negative`no test`no negative test
`RFC8669-3.2-5`	If a BGP speaker receives a node's SRGB as an attribute of the BGP-LS Node NLRI and the BGP speaker also receives the same node's SRGB in a BGP Prefix-SID attribute, then the received values should be the same. If the values are different, the values advertised in the BGP- LS NLRI SHOULD be preferred, and an error should be logged. (§3.2)
	SHOULD	3.2	positive`no test`no positive test negative`no test`no negative test
`RFC8669-9-1`	Since BGP-LS is the preferred method for advertising SRGB information, the BGP speaker SHOULD log an error if a BGP Prefix-SID attribute is received with SRGB information different from that received as an attribute of the same node's BGP-LS Node NLRI. (§9)
	SHOULD	9	positive`no test`no positive test negative`no test`no negative test
`RFC8669-9-2`	To prevent a Denial-of-Service (DoS) or Distributed-Denial-of-Service (DDoS) attack due to excessive BGP updates with an invalid or conflicting BGP Prefix-SID attribute, error log message rate limiting as well as suppression of duplicate error log messages SHOULD be deployed. (§9)
	SHOULD	9	positive`no test`no positive test negative`no test`no negative test
`RFC8669-1-1`	A BGP Prefix-SID MAY be attached to a BGP prefix (§1)
	MAY	1	positive`no test`no positive test negative`no test`no negative test
`RFC8669-5.1-3`	A BGP speaker that originates a BGP Prefix-SID attribute MAY optionally announce the Originator SRGB TLV along with the mandatory Label-Index TLV. (§5.1)
	MAY	5.1	positive`no test`no positive test negative`no test`no negative test
`RFC8669-5-3`	If the path did not come with a BGP Prefix-SID attribute, the speaker MAY attach a BGP Prefix-SID to the path if configured to do so. (§5)
	MAY	5	positive`no test`no positive test negative`no test`no negative test
`RFC8669-3.2-6`	Note that the SRGB field MAY appear multiple times. If the SRGB field appears multiple times, the SRGB consists of multiple ranges that are concatenated. (§3.2)
	MAY	3.2	positive`no test`no positive test negative`no test`no negative test

Gaps and untested MUSTs

Requirement	State	Reason
`RFC8669-3.1-1` Label-Index TLV MUST be present in the BGP Prefix-SID attribute attached to IPv4/IPv6 Labeled Unicast prefixes (§3.1)	{gap}, no test	neither the sender nor the receiver requires TLV type 1 for labeled unicast -- validatePrefixSIDAttr accepts a Prefix-SID with no Label-Index TLV (internal/component/bgp/message/rfc7606.go:837) and BuildLabeledUnicast attaches whatever bytes the route configuration produced, including an SRv6-only attribute (internal/component/bgp/message/update_build_labeled.go:189)
`RFC8669-4.1-3` If multiple different prefixes are received with the same label index, all of the different prefixes MUST have their BGP Prefix-SID attribute considered to be "conflicting". (§4.1)	{gap}, no test	ze keeps no label-index-to-prefix reverse index and reads no label index at all -- the only reader of the Prefix-SID TLV list is the SRv6 extractor, which skips TLV type 1 (internal/component/bgp/plugins/rib/pool/srv6sid.go:47), so no conflict can be detected
`RFC8669-4.1-4` When a BGP speaker receives a path from a neighbor with an "invalid" or "conflicting" BGP Prefix-SID attribute, or when a BGP speaker receives a path from a neighbor with a BGP Prefix-SID attribute but is unable to process it (e.g., local policy disables the functionality), it MUST ignore the BGP Prefix-SID attribute. (§4.1)	{gap}, no test	the "invalid" half is implemented and the "conflicting" half is absent. A labeled-unicast Prefix-SID with no Label-Index TLV is classified PrefixSIDInvalidAttribute (internal/core/bgp/attribute/prefixsid_classify.go, ClassifyPrefixSID) and validatePrefixSIDValue maps it to attribute-discard (internal/component/bgp/message/rfc7606.go), so the attribute is ignored and not relayed; TestRFC8669InvalidPrefixSIDLoggedAtDefaultLevel drives it through enforceRFC7606 and RFC8669-4.1-2 is proven both ways. The "conflicting" state is never computed: ze reads no label index and derives no label against a configured SRGB (see RFC8669-4.1-3), so nothing triggers ignoring a conflicting attribute. Ze derives no label from any Label-Index, so no SR-MPLS behavior follows from an attribute it is unable to process
`RFC8669-4.1-5` For the purposes of label allocation, a BGP speaker MUST assign a local (also called dynamic) label (non-SRGB) for such a prefix as per classic Multiprotocol BGP IPv4/IPv6 Labeled Unicast ([RFC8277]) operation. (§4.1)	{gap}, no test	ze allocates no local label for a BGP prefix at all -- the label programmed for a labeled-unicast route is the one carried in the received NLRI (internal/component/bgp/plugins/rib/rib_bestchange.go:900), and the only MPLS ingress allocators are LDP and RSVP-TE (internal/plugins/ldp/fib.go:135, internal/plugins/rsvpte/fib.go:45)
`RFC8669-4.1-6` In the case of an "invalid" BGP Prefix-SID attribute, a BGP speaker MUST follow the error-handling rules specified in Section 6. (§4.1)	no test	no test carries this requirement id; annotated {rollup}: RFC8669-4.1-2, RFC8669-6-1; the sentence asserts nothing of its own and binds the "invalid" verdict (RFC8669-4.1-2, a Prefix-SID received without a Label-Index TLV) to the Section 6 rule for "a malformed or invalid BGP Prefix-SID attribute attached to an IPv4/ IPv6 Labeled Unicast prefix" (RFC8669-6-1). ClassifyPrefixSID returns PrefixSIDInvalidAttribute and validatePrefixSIDValue answers attribute-discard for it, which TestRFC8669InvalidPrefixSIDLoggedAtDefaultLevel drives through enforceRFC7606
`RFC8669-4.1-7` Specifically, a BGP speaker receiving a prefix with a BGP Prefix-SID attribute and a label NLRI field of Implicit NULL [RFC3032] from a neighbor MUST adhere to standard behavior and program its MPLS data plane to pop the top label when forwarding traffic to the prefix. (§4.1)	{gap}, no test	the received NLRI label is programmed as an MPLS encapsulation without any implicit-NULL exception -- validateMPLSLabels accepts label 3 like any other value (internal/plugins/fib/kernel/mpls.go:23) and buildMPLSEncap pushes whatever labels it is given (internal/plugins/fib/kernel/nexthop_linux.go:75), so an implicit-NULL labeled-unicast route is programmed as a push of label 3 rather than a pop
`RFC8669-5.1-1` In all cases, the Label field of the advertised NLRI ([RFC8277] [RFC4364]) MUST be set to the local/incoming label programmed in the MPLS data plane for the given advertised prefix. (§5.1)	{gap}, no test	BuildLabeledUnicastNLRIBytes writes the label taken from the route configuration into the NLRI (internal/component/bgp/message/update_build_labeled.go:278, fed by internal/component/bgp/reactor/peer_static_routes.go:86) and nothing programs a matching incoming MPLS entry -- the only emitters of MPLS ingress/transit entries are LDP and RSVP-TE (internal/plugins/ldp/fib.go:135, internal/plugins/rsvpte/fib.go:50)
`RFC8669-6-2` As per [RFC7606], if the BGP Prefix-SID attribute appears more than once in an UPDATE message, all the occurrences of the attribute other than the first one SHALL be discarded and the UPDATE message will continue to be processed. (§6)	{gap}, no test	unproven for code 40, no longer unimplemented. The processing half holds -- an already-seen non-MP attribute code is skipped without validation (internal/component/bgp/message/rfc7606.go, ValidateUpdateRFC7606) and recorded in DuplicateRanges, on the attribute-discard result as well as the clean one. The wire half is the RFC 7606 Section 3.g keep-first strip in enforceRFC7606 (internal/component/bgp/reactor/session_validation.go), which removes every recorded later copy through StripAttrRanges before the in-place attribute discard runs, so a malformed first occurrence is tombstoned and its duplicate is gone too. What is missing is the proof: no test tagged to this row drives a repeated code 40 through enforceRFC7606 and reads the bytes forwarded on

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.

`RFC8669-3-1`

For future extensibility, unknown TLVs MUST be ignored and propagated unmodified. (§3, §6)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged after the D-8 fix (applyFactsNextHop records Remove{5,6} on code 40; prefixSIDNextHopHandler rewrites the attribute per route). Clause 'ignored': message/rfc8669_test.go::TestRFC8669UnknownTLVIsIgnored pins RFC7606ActionNone and intact bytes for an unallocated TLV (no discrimination record; supplementary). Clause 'propagated unmodified': reactor TestRFC8669UnknownTLVPropagatedAcrossANextHopChange reads attribute 40 on the wire over both relay rails (forwardUpdateCore, reactorForwardRS): positive, next hop unchanged, [LabelIndex, L3 Svc, type 200, L2 Svc, SRGB] byte-identical; negative (R1b: the input that used to violate), next-hop-self with NEXT_HOP really 10.0.0.254, attribute == LabelIndex+type200+SRGB byte-identical in received order. Observed red: positive with applyFactsNextHop broken, negative with prefixSIDNextHopHandler broken. Buffers isolated (well-formed TLVs, only type 200 unknown). Re-judged 2026-10-14 (independent reader, after 8c1c4013f2 and 7d37dcd562). Two covers added, judged against Section 3 ('unknown TLVs MUST be ignored and propagated unmodified'): reactor TestClearTransmittedLabelIndexOnlyOnLabeledUnicast asserts that a body whose Label-Index TLV carries Reserved A5 and Flags 5AFF on IPv4 VPN, where the TLV is unrecognized, leaves clearTransmittedLabelIndex octet-equal (the egress clear only); test/plugin/prefixsid-malformed-receive.ci frame (f) relays an IPv4 VPN Label-Index with Reserved AA and Flags BBCC octet-equal through the daemon. The earlier covers are unchanged. Verdict unchanged. Rejudged 2026-10-16 (independent reader) after the owner-approved 2026-10-16 change ("5 RFC") to test/plugin/prefixsid-malformed-receive.ci: the only edit is frame (b2), the relayed MP_UNREACH_NLRI for 10.0.2.0/24 RD 65001:1 on IPv4 VPN, whose 3-octet label field now pins 800000 in place of the received 007D01, plus its comment; every other action and expect line is byte-identical. RFC 8277 Section 2.4: "Upon transmission, the Compatibility field SHOULD be set to 0x800000. Upon reception, the value of the Compatibility field MUST be ignored." This row rests on frame (f) (Label-Index with Reserved AA and Flags BBCC relayed octet-equal) and on the Go units, none of which changed; (b2) is a withdrawal carrying no attribute 40, so the edit cannot touch the unknown-TLV relay evidence. RFC 8669 Section 3: "For future extensibility, unknown TLVs MUST be ignored and propagated unmodified." Verdict stands.

Polarity	Test	Kind and tier	Proof state
negative	`TestRFC8669UnknownTLVPropagatedAcrossANextHopChange`	unit/verify	revert, verified
positive	`TestRFC8669UnknownTLVIsIgnored`	unit/verify	unproven
positive	`TestClearTransmittedLabelIndexOnlyOnLabeledUnicast`	unit/verify	revert, verified
positive	`TestRFC8669UnknownTLVPropagatedAcrossANextHopChange`	unit/verify	revert, verified
positive	`prefixsid-malformed-receive.ci`	functional/verify	revert, verified

`RFC8669-3.1-1`

Label-Index TLV MUST be present in the BGP Prefix-SID attribute attached to IPv4/IPv6 Labeled Unicast prefixes (§3.1)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC8669-3.1-1, so no unit is bound to it.

`RFC8669-3.1-2`

It MUST be ignored when received for other BGP AFI/SAFI combinations. (§3.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-14 (independent reader, after 8c1c4013f2 and 7d37dcd562). RFC 8669 Section 3.1: 'It MUST be ignored when received for other BGP AFI/SAFI combinations.' The RA33 finding (the parser refused a Label-Index whose length is not 7 on every family, and no tagged unit fed one off labeled unicast through validation or decode) is answered by the new covers: message TestRFC8669LabelIndexAnyLengthIgnoredOffLabeledUnicast asserts RFC7606ActionNone for a 6-octet Label-Index on IPv4 VPN and IPv6 unicast; attribute TestParsePrefixSIDAcceptsOffFamilyLabelIndexLength asserts ParsePrefixSID accepts it, re-emits it octet-equal and renders it attribute-not-implemented-1; reactor TestClearTransmittedLabelIndexOnlyOnLabeledUnicast asserts the egress clear leaves an IPv4 unicast body octet-equal; prefixsid-malformed-receive.ci frame (c) relays the 6-octet TLV on IPv4 VPN octet-equal; the pool test still asserts the SRv6 extractor ignores it. The producer ClassifyPrefixSID skips type 1 and 3 TLVs off labeled unicast without judging their length. Single-polarity stands: there is no Label-Index behavior off labeled unicast to drive negatively. Not asserted: a 7-octet Label-Index off labeled unicast through the JSON formatter. Rejudged 2026-10-16 (independent reader) after the owner-approved 2026-10-16 change ("5 RFC") to test/plugin/prefixsid-malformed-receive.ci: the only edit is frame (b2), the relayed MP_UNREACH_NLRI for 10.0.2.0/24 RD 65001:1 on IPv4 VPN, whose 3-octet label field now pins 800000 in place of the received 007D01, plus its comment; every other action and expect line is byte-identical. RFC 8277 Section 2.4: "Upon transmission, the Compatibility field SHOULD be set to 0x800000. Upon reception, the value of the Compatibility field MUST be ignored." This row rests on frame (c) (6-octet Label-Index on IPv4 VPN relayed octet-equal) and on the Go units, none of which changed; (b2) carries no attribute 40. RFC 8669 Section 3.1: "It MUST be ignored when received for other BGP AFI/SAFI combinations." Verdict stands, single-polarity unchanged.

Polarity	Test	Kind and tier	Proof state
positive	`TestRFC8669LabelIndexAnyLengthIgnoredOffLabeledUnicast`	unit/verify	revert, verified
positive	`TestRFC8669LabelIndexIgnoredOnNonLabeledUnicastFamily`	unit/verify	unproven
positive	`TestClearTransmittedLabelIndexOnlyOnLabeledUnicast`	unit/verify	revert, verified
positive	`TestParsePrefixSIDAcceptsOffFamilyLabelIndexLength`	unit/verify	revert, verified
positive	`prefixsid-malformed-receive.ci`	functional/verify	revert, verified

`RFC8669-3.1-3`

RESERVED: 8-bit field. It MUST be clear on transmission (§3.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. RFC 8669 §3.1 whole field sentence: "RESERVED: 8-bit field. It MUST be clear on transmission and MUST be ignored on reception." This row owns the transmission clause; reception remains RFC8669-3.1-4. Both internal/component/bgp/config/rfc8669_test.go tagged units (TestRFC8669LabelIndexTLVReservedAndFlagsClearOnTransmission and TestRFC8669SRGBFormLabelIndexReservedAndFlagsClearOnTransmission) pin the reserved octet and independent bare-index/SRGB encoders internal/core/bgp/attribute/prefixsid.go::EncodePrefixSID/parsePrefixSIDWithSRGB. internal/component/bgp/reactor/rfc8669_label_index_transmit_test.go::TestRFC8669LabelIndexTransmissionClearsReservedAndFlags separately supplies clean and dirty Label-Index values to raw, whole-packet, parsed, filter-override, general and route-server paths, then checks exact attribute bytes on the real session writer. clearTransmittedLabelIndex in session_prefix_sid.go clears only the bounded type-1 fields in an owned outgoing buffer; session_write.go invokes it after policy. Whole-value equality also requires unchanged unknown TLV, Originator SRGB, source buffer and NLRI. These distinct input cases fail if a dirty Reserved octet escapes or normalization corrupts adjacent content. This repairs the earlier origination-only proof limitation. No SRv6 SID allocation, transposition, VPP or RFC9252 feature claim follows; no runtime result asserted. Re-judged 2026-10-14 (independent reader, after 8c1c4013f2 and 7d37dcd562). The transmit test now builds an IPv4 labeled-unicast route (rfc8669LabeledUnicastBody), the family Section 3.1 defines the TLV for, with the same exact-bytes assertions; the new TestClearTransmittedLabelIndexOnlyOnLabeledUnicast asserts the Reserved octet cleared on IPv4 and IPv6 labeled unicast with attribute 40 before and after MP_REACH_NLRI. Verdict unchanged.

Polarity	Test	Kind and tier	Proof state
negative	`TestRFC8669LabelIndexTransmissionClearsReservedAndFlags`	unit/verify	revert, verified
positive	`TestRFC8669LabelIndexTLVReservedAndFlagsClearOnTransmission`	unit/verify	revert, verified
positive	`TestRFC8669SRGBFormLabelIndexReservedAndFlagsClearOnTransmission`	unit/verify	revert, verified
positive	`TestClearTransmittedLabelIndexOnlyOnLabeledUnicast`	unit/verify	revert, verified
positive	`TestRFC8669LabelIndexTransmissionClearsReservedAndFlags`	unit/verify	revert, verified

`RFC8669-3.1-4`

RESERVED: 8-bit field. It MUST be clear on transmission and MUST be ignored on reception. (§3.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Transmission: every EncodePrefixSID shape (bare, all-ones index, SRGB-leading) has Label-Index Reserved 0. Reception: Reserved 0xFF gives Action None, no discard, bytes unchanged, ParsePrefixSID ok. Judge break (Reserved 1 in the SRGB-path encoder): red.

Polarity	Test	Kind and tier	Proof state
negative	`TestRFC8669ReservedAndFlagsClearOnTransmissionIgnoredOnReception`	unit/verify	revert, verified
negative	`TestRFC8669LabelIndexNonZeroReservedIgnored`	unit/verify	unproven
positive	`TestRFC8669ReservedAndFlagsClearOnTransmissionIgnoredOnReception`	unit/verify	revert, verified
positive	`TestRFC8669LabelIndexReservedAndFlagsZeroAccepted`	unit/verify	unproven

`RFC8669-3.1-5`

Flags: 16 bits of flags. None are defined by this document. The Flags field MUST be clear on transmission (§3.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. RFC 8669 §3.1 whole field sentence: "Flags: 16 bits of flags. None are defined by this document. The Flags field MUST be clear on transmission and MUST be ignored on reception." This row owns transmission; reception remains RFC8669-3.1-6. internal/component/bgp/config/rfc8669_test.go::TestRFC8669LabelIndexTLVReservedAndFlagsClearOnTransmission and TestRFC8669SRGBFormLabelIndexReservedAndFlagsClearOnTransmission assert both Flags octets zero for internal/core/bgp/attribute/prefixsid.go::EncodePrefixSID and parsePrefixSIDWithSRGB. The clean/dirty subcases of internal/component/bgp/reactor/rfc8669_label_index_transmit_test.go::TestRFC8669LabelIndexTransmissionClearsReservedAndFlags drive six final writer/relay paths, including filter overrides, and demand the full expected Prefix-SID with Flags 0000. session_prefix_sid.go::clearTransmittedLabelIndex and its session_write.go callers operate only on owned outgoing bytes after policy. Exact source, unknown-TLV, SRGB and NLRI preservation isolates the type-1 normalization from unrelated dropping or rewriting. Genuine clean and nonzero cases distinguish both polarities; this is no longer only a configuration-encoder assertion. RFC8669 explicitly defers SRv6 data-plane behavior, so this verdict grants no SRv6/VPP implementation scope. Runtime proof remains the parent recorder responsibility. Re-judged 2026-10-14 (independent reader, after 8c1c4013f2 and 7d37dcd562). The transmit test now builds an IPv4 labeled-unicast route, with the same exact-bytes assertions (Flags 0000); the new TestClearTransmittedLabelIndexOnlyOnLabeledUnicast asserts Flags cleared on IPv4 and IPv6 labeled unicast. Verdict unchanged.

Polarity	Test	Kind and tier	Proof state
negative	`TestRFC8669LabelIndexTransmissionClearsReservedAndFlags`	unit/verify	revert, verified
positive	`TestRFC8669LabelIndexTLVReservedAndFlagsClearOnTransmission`	unit/verify	revert, verified
positive	`TestRFC8669SRGBFormLabelIndexReservedAndFlagsClearOnTransmission`	unit/verify	revert, verified
positive	`TestClearTransmittedLabelIndexOnlyOnLabeledUnicast`	unit/verify	revert, verified
positive	`TestRFC8669LabelIndexTransmissionClearsReservedAndFlags`	unit/verify	revert, verified

`RFC8669-3.1-6`

Flags: 16 bits of flags. None are defined by this document. The Flags field MUST be clear on transmission and MUST be ignored on reception. (§3.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Same unit: Label-Index Flags 0 on every encoded shape; received Flags 0xFFFF ignored with bytes unchanged and ParsePrefixSID ok.

Polarity	Test	Kind and tier	Proof state
negative	`TestRFC8669ReservedAndFlagsClearOnTransmissionIgnoredOnReception`	unit/verify	revert, verified
negative	`TestRFC8669LabelIndexNonZeroFlagsIgnored`	unit/verify	unproven
positive	`TestRFC8669ReservedAndFlagsClearOnTransmissionIgnoredOnReception`	unit/verify	revert, verified
positive	`TestRFC8669LabelIndexReservedAndFlagsZeroAccepted`	unit/verify	unproven

`RFC8669-3.2-1`

Flags: 16 bits of flags. None are defined in this document. The Flags field MUST be clear on transmission (§3.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Non-compliant behaviour: non-zero Originator SRGB Flags emitted. config/rfc8669_test.go::TestRFC8669OriginatorSRGBTLVFlagsClearOnTransmission asserts require.Equal([]byte{0,0}, srgb[3:5]) on EncodePrefixSID output. Single-polarity marker present.

Polarity	Test	Kind and tier	Proof state
positive	`TestRFC8669OriginatorSRGBTLVFlagsClearOnTransmission`	unit/verify	unproven

`RFC8669-3.2-2`

Flags: 16 bits of flags. None are defined in this document. The Flags field MUST be clear on transmission and MUST be ignored on reception. (§3.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Same unit: SRGB Flags 0 on send including all-ones base/range; received SRGB Flags 0xFFFF ignored, bytes unchanged (the assertion the earlier note missed). Judge break (SRGB Flags 1): red.

Polarity	Test	Kind and tier	Proof state
negative	`TestRFC8669ReservedAndFlagsClearOnTransmissionIgnoredOnReception`	unit/verify	revert, verified
negative	`TestRFC8669SRGBNonZeroFlagsIgnored`	unit/verify	unproven
positive	`TestRFC8669ReservedAndFlagsClearOnTransmissionIgnoredOnReception`	unit/verify	revert, verified
positive	`TestRFC8669SRGBFlagsZeroAccepted`	unit/verify	unproven

`RFC8669-3.2-3`

Originator SRGB TLV MUST NOT be changed during the propagation of the BGP update (§3.2)

Audit verdict: not audited: no reader has judged these tests

Polarity	Test	Kind and tier	Proof state
positive	`TestRFC8669SRGBUnchangedThroughReceiveValidation`	unit/verify	unproven

`RFC8669-3.2-4`

The Originator SRGB TLV may only appear in a BGP Prefix-SID attribute attached to IPv4/IPv6 Labeled Unicast prefixes ([RFC8277]). It MUST be ignored when received for other BGP AFI/SAFI combinations. (§3.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-14 (independent reader, after 8c1c4013f2 and 7d37dcd562). RFC 8669 Section 3.2: 'It MUST be ignored when received for other BGP AFI/SAFI combinations.' The RA33 finding (the parser refused an Originator SRGB whose length is not 2 + 6N on every family, untested off labeled unicast) is answered: message TestRFC8669SRGBAnyLengthIgnoredOffLabeledUnicast asserts RFC7606ActionNone for a 3-octet SRGB on IPv4 VPN; attribute TestParsePrefixSIDAcceptsOffFamilyLabelIndexLength asserts ParsePrefixSID accepts it, re-emits it octet-equal and renders it attribute-not-implemented-3; the pool test asserts the SRv6 extractor ignores it. ClassifyPrefixSID judges SRGB length on labeled unicast only. Single-polarity stands. Not asserted: an end-to-end relay of an SRGB off labeled unicast.

Polarity	Test	Kind and tier	Proof state
positive	`TestRFC8669SRGBAnyLengthIgnoredOffLabeledUnicast`	unit/verify	revert, verified
positive	`TestRFC8669SRGBIgnoredOnNonLabeledUnicastFamily`	unit/verify	unproven
positive	`TestParsePrefixSIDAcceptsOffFamilyLabelIndexLength`	unit/verify	revert, verified

`RFC8669-4-1`

A BGP speaker receiving a BGP Prefix-SID attribute from an External BGP (EBGP) neighbor residing outside the boundaries of the SR domain MUST discard the attribute unless it is configured to accept the attribute from the EBGP neighbor. (§4)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Clause 'MUST discard': a Prefix-SID kept from an unconfigured EBGP peer goes red at reactor/rfc8669_test.go::TestRFC8669PrefixSIDFromEBGPDiscardedByDefault assert.False(found) after enforceRFC7606, and for repeated copies at rfc8669_multi_test.go::TestRFC8669PrefixSIDEveryOccurrenceDiscardedFromEBGP. Clause 'unless configured': an over-firing strip goes red at TestRFC8669PrefixSIDFromEBGPAcceptedWhenConfigured assert.True(found); IBGP not affected is pinned in TestRFC8669PrefixSIDKeptPathsKeepExactlyOneCopy.

Polarity	Test	Kind and tier	Proof state
negative	`TestRFC8669PrefixSIDEveryOccurrenceDiscardedFromEBGP`	unit/verify	unproven
negative	`TestRFC8669PrefixSIDFromEBGPDiscardedByDefault`	unit/verify	unproven
positive	`TestRFC8669PrefixSIDKeptPathsKeepExactlyOneCopy`	unit/verify	unproven
positive	`TestRFC8669PrefixSIDFromEBGPAcceptedWhenConfigured`	unit/verify	unproven

`RFC8669-4.1-1`

When the BGP Prefix-SID attribute is attached to a BGP Labeled IPv4 or IPv6 Unicast [RFC8277] AFI/SAFI, it MUST contain the Label-Index TLV (§4.1)

Audit verdict: not audited: no reader has judged these tests

Polarity	Test	Kind and tier	Proof state
negative	`TestRFC8669NoLabelIndexInvalidOnLabeledUnicast`	unit/verify	revert, verified
positive	`TestRFC8669ConformingTLVLengthsAcceptedOnLabeledUnicast`	unit/verify	revert, verified

`RFC8669-4.1-2`

A BGP Prefix-SID attribute received without a Label-Index TLV MUST be considered to be "invalid" by the receiving speaker. (§4.1)

Audit verdict: not audited: no reader has judged these tests

Polarity	Test	Kind and tier	Proof state
negative	`TestRFC8669NoLabelIndexInvalidOnLabeledUnicast`	unit/verify	revert, verified
negative	`prefixsid-malformed-receive.ci`	functional/verify	revert, verified
positive	`TestRFC8669NoLabelIndexInvalidOnLabeledUnicast`	unit/verify	revert, verified

`RFC8669-4.1-3`

If multiple different prefixes are received with the same label index, all of the different prefixes MUST have their BGP Prefix-SID attribute considered to be "conflicting". (§4.1)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC8669-4.1-3, so no unit is bound to it.

`RFC8669-4.1-4`

When a BGP speaker receives a path from a neighbor with an "invalid" or "conflicting" BGP Prefix-SID attribute, or when a BGP speaker receives a path from a neighbor with a BGP Prefix-SID attribute but is unable to process it (e.g., local policy disables the functionality), it MUST ignore the BGP Prefix-SID attribute. (§4.1)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC8669-4.1-4, so no unit is bound to it.

`RFC8669-4.1-5`

For the purposes of label allocation, a BGP speaker MUST assign a local (also called dynamic) label (non-SRGB) for such a prefix as per classic Multiprotocol BGP IPv4/IPv6 Labeled Unicast ([RFC8277]) operation. (§4.1)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC8669-4.1-5, so no unit is bound to it.

`RFC8669-4.1-6`

In the case of an "invalid" BGP Prefix-SID attribute, a BGP speaker MUST follow the error-handling rules specified in Section 6. (§4.1)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC8669-4.1-6, so no unit is bound to it.

`RFC8669-4.1-7`

Specifically, a BGP speaker receiving a prefix with a BGP Prefix-SID attribute and a label NLRI field of Implicit NULL [RFC3032] from a neighbor MUST adhere to standard behavior and program its MPLS data plane to pop the top label when forwarding traffic to the prefix. (§4.1)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC8669-4.1-7, so no unit is bound to it.

`RFC8669-4.1-8`

The label NLRI defines the outbound label that MUST be used by the receiving node (§4.1)

Audit verdict: not audited: no reader has judged these tests

Polarity	Test	Kind and tier	Proof state
positive	`TestRFC8669NLRILabelIsTheOutboundLabel`	unit/verify	unproven

`RFC8669-5.1-1`

In all cases, the Label field of the advertised NLRI ([RFC8277] [RFC4364]) MUST be set to the local/incoming label programmed in the MPLS data plane for the given advertised prefix. (§5.1)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC8669-5.1-1, so no unit is bound to it.

`RFC8669-8-1`

The propagation to other ASes MUST be explicitly configured (§8)

Audit verdict: not audited: no reader has judged these tests

Polarity	Test	Kind and tier	Proof state
negative	`TestAnnounceRailKeepsPrefixSIDInsideTheSRDomain`	unit/verify	revert, verified
negative	`TestStaleReadvertiseKeepsPrefixSIDInsideTheSRDomain`	unit/verify	revert, verified
negative	`TestPrefixSIDEgressBoundary`	unit/verify	revert, verified
negative	`TestPrefixSIDOriginationBoundary`	unit/verify	revert, verified
negative	`prefixsid-announce-rail-boundary.ci`	functional/verify	revert, verified
negative	`prefixsid-ebgp-egress-boundary.ci`	functional/verify	revert, verified
positive	`TestAnnounceRailKeepsPrefixSIDInsideTheSRDomain`	unit/verify	revert, verified
positive	`TestStaleReadvertiseKeepsPrefixSIDInsideTheSRDomain`	unit/verify	revert, verified
positive	`TestPrefixSIDEgressBoundary`	unit/verify	revert, verified
positive	`TestPrefixSIDOriginationBoundary`	unit/verify	revert, verified
positive	`prefixsid-announce-rail-boundary.ci`	functional/verify	revert, verified
positive	`prefixsid-ebgp-egress-boundary.ci`	functional/verify	revert, verified

`RFC8669-6-1`

When a BGP speaker receives a BGP UPDATE message containing a malformed or invalid BGP Prefix-SID attribute attached to an IPv4/ IPv6 Labeled Unicast prefix ([RFC8277]), it MUST ignore the received BGP Prefix-SID attribute and not advertise it to other BGP peers. (§6)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-14 (independent reader, after 8c1c4013f2 and 7d37dcd562). RFC 8669 Section 6, malformed or invalid attribute on IPv4/IPv6 labeled unicast: 'it MUST ignore the received BGP Prefix-SID attribute and not advertise it to other BGP peers.' The three RA findings are answered. TLV length constraints: TestRFC8669LabelIndexLengthMalformedOnLabeledUnicast (Label-Index 6 and 8, both families, attribute 40 before and after MP_REACH_NLRI) and TestRFC8669SRGBLengthMalformedOnLabeledUnicast (2, 3, 9) assert attribute-discard of exactly code 40. Minimum attribute length: TestRFC8669EmptyAttributeMalformed asserts attribute-discard of code 40. Positive: TestRFC8669ConformingTLVLengthsAcceptedOnLabeledUnicast asserts no action for Label-Index 7 alone and with SRGB 8 or 14. 'Not advertise': prefixsid-malformed-receive.ci, octet for octet, relays (a) Label-Index 6, (d) no Label-Index (the 'invalid' case, RFC 8669 Section 4.1) and (e1) empty attribute on IPv4 labeled unicast with attribute 40 absent, replaced by an ATTR_TOMBSTONE (type 252) naming code 40. The earlier overrun and trailing-byte units still assert discard. Producer: ClassifyPrefixSID via validatePrefixSIDValue. Rejudged 2026-10-16 (independent reader) after the owner-approved 2026-10-16 change ("5 RFC") to test/plugin/prefixsid-malformed-receive.ci: the only edit is frame (b2), the relayed MP_UNREACH_NLRI for 10.0.2.0/24 RD 65001:1 on IPv4 VPN, whose 3-octet label field now pins 800000 in place of the received 007D01, plus its comment; every other action and expect line is byte-identical. RFC 8277 Section 2.4: "Upon transmission, the Compatibility field SHOULD be set to 0x800000. Upon reception, the value of the Compatibility field MUST be ignored." This row rests on frames (a), (d) and (e1) (IPv4 labeled unicast relayed with attribute 40 replaced by an ATTR_TOMBSTONE naming code 40) and on the message units, none of which changed; (b2) is an IPv4 VPN withdrawal, outside the labeled-unicast scope of this row. RFC 8669 Section 6: "it MUST ignore the received BGP Prefix-SID attribute and not advertise it to other BGP peers." Verdict stands.

Polarity	Test	Kind and tier	Proof state
negative	`TestRFC8669MalformedAttributeDiscardedAndNotAdvertised`	unit/verify	unproven
negative	`TestRFC8669TrailingBytesDiscarded`	unit/verify	unproven
negative	`TestRFC8669EmptyAttributeMalformed`	unit/verify	revert, verified
negative	`TestRFC8669LabelIndexLengthMalformedOnLabeledUnicast`	unit/verify	revert, verified
negative	`TestRFC8669SRGBLengthMalformedOnLabeledUnicast`	unit/verify	revert, verified
negative	`prefixsid-malformed-receive.ci`	functional/verify	revert, verified
positive	`TestRFC8669WellFormedAttributeAccepted`	unit/verify	unproven
positive	`TestRFC8669ConformingTLVLengthsAcceptedOnLabeledUnicast`	unit/verify	revert, verified

`RFC8669-6-2`

As per [RFC7606], if the BGP Prefix-SID attribute appears more than once in an UPDATE message, all the occurrences of the attribute other than the first one SHALL be discarded and the UPDATE message will continue to be processed. (§6)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC8669-6-2, so no unit is bound to it.

`RFC8669-6-3`

Similarly, if a recognized TLV appears more than once in a BGP Prefix-SID attribute while the specification only allows for a single occurrence, then all the occurrences of the TLV other than the first one SHALL be discarded and the Prefix-SID attribute will continue to be processed. (§6)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged after 465af38f1d against rfc/full/rfc8669.txt Sections 3, 3.1, 3.2 and 6 and rfc/full/rfc9252.txt Section 7. Positive TestRFC8669DuplicateServiceTLVDiscardedOnReceive drives the real receive entry (enforceRFC7606 to publishBase) on an internal and a route-server-client session and asserts no error, RFC7606ActionNone, exactly one attribute 40 equal to the received TLVs less the repeat in received order, the peer's header width, the received attributes after code 40 octet for octet, and the same TLVs on the forward path; its cases are repeated SRv6 L3 and L2 Service TLVs on labelled unicast, Label-Index twice with an unknown TLV between, an unknown TLV after the repeat, a COMMUNITIES attribute after code 40, an Extended Length header, and L3 Service twice on IPv4 unicast (RFC 9252 Section 7 names no family). Negative TestRFC8669SingleOccurrencePrefixSIDKeptWhole pins the 'only allows for a single occurrence' qualifier and the Section 6 MUST 'unknown TLVs MUST be ignored and propagated unmodified': each type once, an unknown TLV twice, an Originator SRGB TLV twice (Section 3.2 'MUST NOT be changed during the propagation', so keeping both copies is the conforming answer) and a Label-Index TLV twice on IPv4 unicast must publish the received body octet-equal and forward every TLV. test/plugin/prefixsid-duplicate-tlv-relay.ci proves the session-in to session-out path with two byte-identical controls (unknown repeat; Label-Index repeat off labelled unicast) and an L3 Service repeat trimmed with the trailing unknown TLV and COMMUNITIES kept. The judge ran five -overlay mutants on HEAD, none recorded: Label-Index single on every family, stop copying after the first discard, family always read as IPv4 unicast, Extended Length header read as 3 octets, and the attributes after code 40 dropped; each turned a tagged reactor test red. Recorded discrimination records cover all three reactor/.ci tags (producer disabled). Readings, not findings: RFC 8669 sets no explicit occurrence limit for Label-Index; Ze treats it as single on IPv4/IPv6 labelled unicast from 'the label index for a given prefix', and off labelled unicast, where Section 3.1 says it 'MUST be ignored when received for other BGP AFI/SAFI combinations', as unrecognized and propagated unmodified (owner decision 2026-10-03). This is a defensible reading of an RFC that is silent, not RFC text. An UPDATE carrying both RFC 4271 NLRI and an MP_REACH_NLRI is judged by the MP_REACH family (prefixSIDRouteFamily), and no test covers it. The pool pair TestRFC8669DuplicateRecognizedTLVFirstWins / CannotOverrideFirst is one read-side first-wins assertion wearing two hats (the SIDs are swapped), so the polarity pair rests on the reactor and .ci tests, not on these two. A malformed repeat stays treat-as-withdraw first (untagged TestRFC8669DuplicateMalformedServiceTLVStillWithdrawn), which is RFC 9252 Section 7 and outside this row. Re-judged 2026-10-14 (independent reader, after 8c1c4013f2 and 7d37dcd562). Both units' labeled-unicast cases now lead with a Label-Index TLV, because a labeled-unicast Prefix-SID without one is invalid (Section 4.1) and would be discarded before the repeat rule is reached; the assertions are unchanged, so each buffer still isolates this rule. Verdict unchanged.

Polarity	Test	Kind and tier	Proof state
negative	`TestRFC8669DuplicateRecognizedTLVCannotOverrideFirst`	unit/verify	unproven
negative	`TestRFC8669SingleOccurrencePrefixSIDKeptWhole`	unit/verify	revert, verified
positive	`TestRFC8669DuplicateRecognizedTLVFirstWins`	unit/verify	unproven
positive	`TestRFC8669DuplicateServiceTLVDiscardedOnReceive`	unit/verify	revert, verified
positive	`prefixsid-duplicate-tlv-relay.ci`	functional/verify	revert, verified

`RFC8669-4-2`

A BGP speaker SHOULD log an error for further analysis when discarding an attribute. (§4)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-15 after f49cfab6e7 by an auditor who authored none of 2f0b126768, c9c935547a, f49cfab6e7. RFC 8669 Section 4: "A BGP speaker receiving a BGP Prefix-SID attribute from an External BGP (EBGP) neighbor residing outside the boundaries of the SR domain MUST discard the attribute unless it is configured to accept the attribute from the EBGP neighbor. A BGP speaker SHOULD log an error for further analysis when discarding an attribute." Producer: validateRFC7606Attrs raises the boundary discard after the walk and records it with AddDiscard even when an earlier discard took result.AttrCode; logRFC7606Discards logs it. Positives: TestRFC8669EBGPBoundaryDiscardLoggedAtDefaultLevel (rfc8669EBGPSession(false), well-formed Label-Index; one ERROR, attr=40, event, peer) and, new, the EBGP boundary case of TestRFC8669PrefixSIDDiscardBesideAnotherLogsBoth (one-octet ATOMIC_AGGREGATE discarded in the walk, so code 6 is result.AttrCode; exactly one attr=40 record citing RFC 8669, whose reason is the boundary description, and one attr=6 record). Negative: TestRFC8669EBGPAcceptedPrefixSIDNoErrorLog (same body on rfc8669EBGPSession(true); ActionNone, no attr=40 ERROR), recorded by the ActionNone-logging mutant of applyRFC7606 instead of a crash; the ignore-accept mutant reddens it on the action assertion first and is evidence of the boundary rule only, not of the log. Independent overlay probes: M1, M7 and M8 redden the EBGP case; M6 (boundary AddDiscard only when it took result.AttrCode, the c9c935547a fix undone) reddens the EBGP case alone, which is exactly the shape this requirement owns; baseline green.

Polarity	Test	Kind and tier	Proof state
negative	`TestRFC8669EBGPAcceptedPrefixSIDNoErrorLog`	unit/verify	mutant, verified
positive	`TestRFC8669EBGPBoundaryDiscardLoggedAtDefaultLevel`	unit/verify	revert, verified
positive	`TestRFC8669PrefixSIDDiscardBesideAnotherLogsBoth`	unit/verify	mutant, verified

`RFC8669-6-4`

When discarding an attribute, a BGP speaker SHOULD log an error for further analysis. (§6)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-15 after f49cfab6e7 by an auditor who authored none of 2f0b126768, c9c935547a, f49cfab6e7. RFC 8669 Section 6: "This is equivalent to the "Attribute discard" action specified in [RFC7606]. When discarding an attribute, a BGP speaker SHOULD log an error for further analysis." Read as binding the attribute discard of the paragraph it closes (malformed or invalid code 40 on labeled unicast); the RFC 7606 Section 3.g keep-first strip of a repeated code 40 (next paragraph, row 6-2) logs only at Debug and is not judged here. Positives: TestRFC8669PrefixSIDDiscardLoggedAtDefaultLevel (TLV overrun, trailing bytes; exactly one ERROR, attr=40, attr-name, event, description, peer, at slogutil.DefaultLevel) and, new, TestRFC8669PrefixSIDDiscardBesideAnotherLogsBoth (TLV overrun with a one-octet ATOMIC_AGGREGATE before and after code 40, plus the EBGP boundary case; exactly one attr=40 record citing RFC 8669 and one attr=6 record that does not), with TestRFC8669MalformedPrefixSIDDiscardDiagnostic keeping the Debug detail. Negatives: TestRFC8669CleanPrefixSIDNoErrorLog (well-formed Label-Index, ActionNone, no attr=40 ERROR) and TestRFC8669CleanPrefixSIDNoDiscardDiagnostic. The weak finding of 452cfef3db/d16c1740fa is closed: the multi-discard unit is now tagged and fingerprinted, its record is the M1 mutant (logRFC7606Discards logs result.AttrCode/result.Description, the pre-c9c935547a behaviour), and the negative's record is a mutant that logs attr 40 on the ActionNone return of applyRFC7606, not a crash. Independent overlay probes (go test -overlay under ./le job run, tree untouched, baseline green): M1 reddens all three BesideAnother cases and both Invalid BesideAnother cases; M7 (log only the first discard entry) reddens the same five; M6 (EBGP boundary AddDiscard only when it took result.AttrCode) reddens the EBGP case; M8 (one rate-limit window shared by all codes) reddens all five BesideAnother cases. Isolation holds: the ATOMIC_AGGREGATE-before ordering makes code 6 result.AttrCode so a first-only log loses attr=40, and the reason assertions catch a record carrying the other attribute's description. Residual, not a finding: records of one code from one peer are rate-limited to one per second with a suppressed count, which keeps the evidence for analysis.

Polarity	Test	Kind and tier	Proof state
negative	`TestRFC8669CleanPrefixSIDNoDiscardDiagnostic`	unit/verify	revert, verified
negative	`TestRFC8669CleanPrefixSIDNoErrorLog`	unit/verify	mutant, verified
positive	`TestRFC8669MalformedPrefixSIDDiscardDiagnostic`	unit/verify	revert, verified
positive	`TestRFC8669PrefixSIDDiscardBesideAnotherLogsBoth`	unit/verify	mutant, verified
positive	`TestRFC8669PrefixSIDDiscardLoggedAtDefaultLevel`	unit/verify	revert, verified

`RFC8669-4.1-15`

A BGP speaker SHOULD log an error for further analysis. (§4.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-15 after f49cfab6e7 by an auditor who authored none of 2f0b126768, c9c935547a, f49cfab6e7. RFC 8669 Section 4.1: "In the case of an "invalid" BGP Prefix-SID attribute, a BGP speaker MUST follow the error-handling rules specified in Section 6. A BGP speaker SHOULD log an error for further analysis." and "A BGP Prefix-SID attribute received without a Label-Index TLV MUST be considered to be "invalid" by the receiving speaker." Producer: validatePrefixSIDForRoutes then validatePrefixSIDValue map PrefixSIDInvalidAttribute to attribute-discard after the walk; logRFC7606Discards logs each discarded code with its own reason. Positives: TestRFC8669InvalidPrefixSIDLoggedAtDefaultLevel (only an Originator SRGB TLV on IPv4 labeled unicast, so the sole fault is the missing Label-Index; one ERROR, attr=40, 'no Label-Index TLV') and, new, TestRFC8669InvalidPrefixSIDDiscardBesideAnotherLogsBoth (the same invalid attribute with a one-octet ATOMIC_AGGREGATE before and after it; one attr=40 record naming the missing Label-Index, one attr=6 record that does not). This closes the earlier finding that no test co-discarded an INVALID Prefix-SID: its record is the M1 mutant of logRFC7606Discards. Negative: TestRFC8669CleanPrefixSIDNoErrorLog (Label-Index present, ActionNone, no attr=40 ERROR), recorded by a mutant that logs attr 40 on the ActionNone return of applyRFC7606, so the negative now discriminates a spurious log rather than reachability. Independent overlay probes: M1, M7 (log only the first entry) and M8 (one rate-limit window shared by all codes) redden both Invalid BesideAnother cases; baseline green. The positive is a genuinely invalid, not malformed, input: the SRGB TLV is well-formed and the asserted reason is the Label-Index one.

Polarity	Test	Kind and tier	Proof state
negative	`TestRFC8669CleanPrefixSIDNoErrorLog`	unit/verify	mutant, verified
positive	`TestRFC8669InvalidPrefixSIDDiscardBesideAnotherLogsBoth`	unit/verify	mutant, verified
positive	`TestRFC8669InvalidPrefixSIDLoggedAtDefaultLevel`	unit/verify	revert, verified

Extraction sign-off

Field	Value
Reviewer	claude
Signed off	2026-09-21
Register	prose
Source	rfc/full/rfc8669.txt
Source fingerprint	bf04f41e726679f9
Record	rfc/extraction/rfc8669.json
Mapped sentences	23
Declined as scope	8
Relocated to a spec, which Ze OWES	0
Unclassified	0

Sections

Section	Name	Sites	Disposition	Reason
`front`	not stated	1	walked	not stated
`1`	not stated	0	walked	not stated
`2`	not stated	3	walked	not stated
`3`	not stated	1	walked	not stated
`3.1`	not stated	4	walked	not stated
`3.2`	not stated	4	walked	not stated
`4`	not stated	1	walked	not stated
`4.1`	not stated	9	walked	not stated
`5`	not stated	0	walked	not stated
`5.1`	not stated	2	walked	not stated
`6`	not stated	4	walked	The separate SHOULD logging sentence applies when discarding malformed or invalid labeled-unicast Prefix-SID attributes; RFC8669-6-4 records it without asserting a particular logging enum or proving the invalid-state trigger. Site 6:4 remains the unknown-TLV propagation occurrence mapped to RFC8669-3-1.
`7`	not stated	1	walked	not stated
`8`	not stated	1	walked	not stated
`9`	not stated	0	walked	not stated
`10`	not stated	0	walked	not stated
`10.1`	not stated	0	walked	not stated
`10.2`	not stated	0	walked	not stated

Excluded sentences

Site	Excluded kind	Reason	Quote
`front:1`	`not-a-requirement` never bound Ze the sentence states a fact or describes another document, and directs no implementation	IETF Trust boilerplate on the Simplified BSD License for extracted Code Components; it binds republication of the document, not any protocol behaviour.	Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
`2:1`	`not-a-requirement` never bound Ze the sentence states a fact or describes another document, and directs no implementation	Overview prose in Section 2: 'if traffic engineering ... is required' and 'may also be required' are lowercase and describe what an SR domain deployment needs, not an obligation on a BGP speaker.	If traffic engineering within the SR domain is required, each node may also be required to advertise topological information and Peer SIDs for each of its links and peers.
`2:2`	`not-a-requirement` never bound Ze the sentence states a fact or describes another document, and directs no implementation	Overview prose: 'This information is required to perform the explicit path computation' is lowercase and describes why the information exists.	This information is required to perform the explicit path computation and to express an explicit path as a list of SIDs.
`2:3`	`not-a-requirement` never bound Ze the sentence states a fact or describes another document, and directs no implementation	Overview prose: 'knowledge of the prefix originator's SRGB is required in order to compute the local label' is lowercase and motivates the Originator SRGB TLV.	If a prefix segment is to be included in an MPLS label stack, e.g., for traffic-engineering purposes, knowledge of the prefix originator's SRGB is required in order to compute the local label used by the originator.
`3.2:4`	`not-a-requirement` never bound Ze the sentence states a fact or describes another document, and directs no implementation	'Since the Label-Index TLV is required for IPv4/IPv6 prefix applicability' is lowercase and restates RFC8669-3.1-1; the rest of the sentence states the consequence that Section 6 error handling (RFC8669-6-1) already carries.	Since the Label-Index TLV is required for IPv4/IPv6 prefix applicability, the Originator SRGB TLV will be ignored if it is not specified in a manner consistent with Section 6.
`4.1:1`	`not-a-requirement` never bound Ze the sentence states a fact or describes another document, and directs no implementation	'A BGP session supporting the Multiprotocol BGP Labeled IPv4 or IPv6 Unicast AFI/SAFI is required' is lowercase and states the deployment precondition for the section, not a behaviour a speaker performs.	A BGP session supporting the Multiprotocol BGP Labeled IPv4 or IPv6 Unicast ([RFC8277]) AFI/SAFI is required.
`6:4`	`duplicate-of` never bound Ze the same obligation is already captured under another requirement id	Section 6 repeats the Section 3 sentence word for word: 'For future extensibility, unknown TLVs MUST be ignored and propagated unmodified.' Site 3:1 is the source and RFC8669-3-1 already cites both sections.	For future extensibility, unknown TLVs MUST be ignored and propagated unmodified.
`7:1`	`not-a-requirement` never bound Ze the sentence states a fact or describes another document, and directs no implementation	IANA Considerations: 'The designated experts must be good and faithful stewards' is lowercase and addresses the registry's designated experts about how they review requests, not a BGP speaker.	The designated experts must be good and faithful stewards of the above registries, ensuring that each request is legitimate and corresponds to a viable use case.

Superseded

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