Partial

DRAFT-IETF-BESS-MUP-SAFI - BGP Extensions for the Mobile User Plane (MUP) SAFI

Every requirement this repository extracted from DRAFT-IETF-BESS-MUP-SAFI, 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 ways36.2%17 of 47 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 reason0.0%0 of 47 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 47 gated MUSTs

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

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

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

Proven by a recorded break100.0%45 of 45 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 MUSTs47of 67 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 47 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 47 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 47 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 47 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 all63.8%30 of 47 gated MUSTs

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

Audit verdicts17of 47 gated MUSTs judged

2 weak, wrong or unimplemented, 0 no longer current. Each is named below under its own requirement id

The 8 shares marked as a part above are the whole of the 47 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	bad	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	67
Gated MUST-level	47
Not applicable, so out of scope	0
Declared gaps	30
Declared gaps a test demonstrates	0
Gated with no test	0
Nightly-only evidence	0
Test tags	46
Tagged units	45
Recorded audit verdicts	17
Discrimination records	45
Summary	`rfc/short/draft-ietf-bess-mup-safi.md`
Requirement shard	`rfc/requirements/draft-ietf-bess-mup-safi.md`
RFC text	`rfc/drafts/draft-ietf-bess-mup-safi.txt`

Enrolment

Enrolled: BGP Extensions for Mobile User Plane (MUP) SAFI. Eleven MUST rows added 2026-09-21 from sentences the checklist had not carried, each untested: the TLV rules of Sections 3.1.3.1 and 3.1.4.1 (3.1.3.1-6 through 3.1.3.1-10, 3.1.4.1-3), the Section 3.1.5 rule that a TLV received in a route type for which it is not applicable MUST be ignored (3.1.5-1), and the four Section 3.3.12 route resolution rules that bind a PE receiving a Type 2 ST route to DSD or ISD routes by BGP MUP Extended Community (3.3.12-4 through 3.3.12-7). The MUP codec parses no ST route TLV and resolves no Type 2 ST route.

What the public ledger says

Status: Partial

What the ledger says is covered

The BGP-MUP NLRI codec only: ipv4/mup and ipv6/mup family registration, ISD/DSD/T1ST/T2ST encoding from config and route commands, full route type body decoding, the RFC 7606 Section 5.4 ruling that discards a route whose Architecture Type is not 1 or whose Route Type is outside 1..4 at ingress (internal/component/bgp/plugins/nlri/mup/rfc7606.go, RecognizeNLRI), MUP extended-community config syntax, and family-generic MP_REACH announcement (internal/component/bgp/plugins/nlri/mup). Thirty MUST gaps are annotated per line in rfc/short/draft-ietf-bess-mup-safi.md. Withdrawal: no MUP NLRI reaches the family-generic MP_UNREACH encoder (internal/component/bgp/reactor/peer_rib_routes.go) -- its callers read the PeerOpWithdraw queue, and neither withdrawal entry point parses SAFI 85 (internal/component/bgp/plugins/cmd/update/update_text_nlri.go, internal/component/bgp/plugins/cmd/announce/announce.go) -- so a Type 1 ST or Type 2 ST withdrawal cannot be emitted (3.3.8-1, 3.3.11-1). Receive side: nlrisplit registers SplitMUP for SAFI 85 since 2026-08-04 (internal/core/bgp/nlri/nlrisplit/register.go), so a received MUP route is stored as an opaque Adj-RIB-In entry (insertPoolNLRIs) and a withdrawal deletes exactly the NLRI it names (removePoolNLRIs, internal/component/bgp/plugins/rib/rib.go). Four routing-instance obligations stay open because ze models no MUP routing instance and no route-type-aware wildcard delete exists (DRAFT-IETF-BESS-MUP-SAFI-3.3.3-2, 3.3.6-2, 3.3.9-1, 3.3.9-2). ParseMUP validates the route type body and refuses an NLRI that does not add up (internal/component/bgp/plugins/nlri/mup/types.go), and the same checks run at ingress (ValidateNLRI, called by the registered recognizer, rfc7606.go recognizerFor): a malformed route is treated as withdrawn, or discarded when its route key cannot form (3.1.1-1, 3.1.1-2, 3.1.2-1, 3.1.3-1, 3.1.3.1-1, 3.1.3.1-2, 3.1.3.1-3, 3.1.3.1-6, 3.1.3.1-7, 3.1.3.1-10, 3.1.4-1, 3.1.4.1-1). A non-3gpp-5g architecture type is discarded as an unimplemented type rather than treated as withdrawn (3.1.3.1-4, 3.1.4.1-2), and no treat-as-withdraw fires on an ISD route missing its Prefix-SID, a nexthop/locator mismatch, or a Type 2 ST route without the BGP MUP Extended Community (3.3.3-1, 3.3.3-3, 3.3.3-4, 3.3.6-1, 3.3.6-4). A DSD route announced in an UPDATE with no Prefix-SID attribute, counting one that RFC 7606 attribute-discard removes, is treated as withdrawn by the UPDATE-level check the plugin registers (internal/component/bgp/plugins/nlri/mup/rfc7606.go, CheckDSDPrefixSID; 3.3.6-5). Send side: ze runs no MUP PE or MUP Controller function, so route targets, the BGP MUP Extended Community, the Prefix-SID, the GTP4.E/GTP6.E function, the required T1ST TEID and Endpoint Address, and the PE or controller IPv6 nexthop are whatever the operator configures rather than derived (3.3.1-1, 3.3.1-2, 3.3.1-3, 3.3.1-4, 3.3.2-1, 3.3.4-1, 3.3.4-2, 3.3.4-3, 3.3.4-4, 3.3.5-2, 3.3.7-1, 3.3.10-1, 3.3.10-2).

What the ledger says remains:

Coverage

Bucket	Count	What it counts
Positive and negative tests	17	one part of the gated population
Annotated (including scoped evidence)	30	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	0	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	47	every gated MUST falls in exactly one bucket above

Requirements

Requirement	Level	Section	Tests
`DRAFT-IETF-BESS-MUP-SAFI-3.3.1-1`	When advertising the Interwork Segment Discovery route, a PE MUST attach the export BGP Route Target Extended Community of the associated routing instance. (Section 3.3.1)
	MUST	3.3.1	positive`no test`no positive test negative`no test`no negative test {gap}: parseConfigRoute attaches only the extended communities the operator configures (internal/component/bgp/plugins/nlri/mup/config.go:66) and ze models no routing instance with export route targets, so no export route target is derived for an ISD advertisement
`DRAFT-IETF-BESS-MUP-SAFI-3.3.1-2`	When advertising the Interwork Segment Discovery route, a PE MUST use the IPv6 address of the PE as the nexthop address in the MP_REACH_NLRI attribute. (Section 3.3.1)
	MUST	3.3.1	positive`no test`no positive test negative`no test`no negative test {gap}: EncodeRoute takes the next-hop verbatim from the route command (internal/component/bgp/plugins/nlri/mup/encode.go:173-191) and accepts an IPv4 next-hop for an ISD route, so nothing requires the IPv6 address of the PE
`DRAFT-IETF-BESS-MUP-SAFI-3.3.1-3`	The Interwork Segment Discovery route update MUST have a prefix SID attribute which the SID consists of the PE locater followed by a function. (Section 3.3.1)
	MUST	3.3.1	positive`no test`no positive test negative`no test`no negative test {gap}: parseConfigRoute adds the Prefix-SID attribute only when the config supplies one (internal/component/bgp/plugins/nlri/mup/config.go:71), so an ISD route configured without a prefix SID is advertised without one
`DRAFT-IETF-BESS-MUP-SAFI-3.3.2-1`	When withdrawing the Interwork Segment Discovery route, a PE MUST attach the export BGP Route Target Extended Community of the associated routing instance. (Section 3.3.2)
	MUST	3.3.2	positive`no test`no positive test negative`no test`no negative test {gap}: a MUP withdrawal is built as a bare MP_UNREACH_NLRI with no path attributes (internal/component/bgp/reactor/peer_rib_routes.go:182-197), so an ISD withdrawal carries no export route target
`DRAFT-IETF-BESS-MUP-SAFI-3.3.4-1`	The address in the BGP-MUP NLRI MUST be a unique PE identifier. (Section 3.3.4)
	MUST	3.3.4	positive`no test`no positive test negative`no test`no negative test {gap}: parseDSDFields accepts any parsable address as the DSD NLRI address (internal/component/bgp/plugins/nlri/mup/encode.go:301-310) and never checks that it identifies the PE uniquely
`DRAFT-IETF-BESS-MUP-SAFI-3.3.4-2`	When announcing the Direct Segment Discovery route, a PE MUST attach a BGP MUP Extended community of the associated routing instance. (Section 3.3.4)
	MUST	3.3.4	positive`no test`no positive test negative`no test`no negative test {gap}: parseConfigRoute attaches only the extended communities the operator configures (internal/component/bgp/plugins/nlri/mup/config.go:66), so a DSD advertisement carries a BGP MUP Extended Community only when the operator writes one into the route
`DRAFT-IETF-BESS-MUP-SAFI-3.3.4-3`	When advertising the Direct Segment Discovery route, a PE MUST use the IPv6 address of the PE as the nexthop address in the MP_REACH_NLRI attribute. (Section 3.3.4)
	MUST	3.3.4	positive`no test`no positive test negative`no test`no negative test {gap}: EncodeRoute takes the next-hop verbatim from the route command (internal/component/bgp/plugins/nlri/mup/encode.go:173-191) and accepts an IPv4 next-hop for a DSD route, so nothing requires the IPv6 address of the PE
`DRAFT-IETF-BESS-MUP-SAFI-3.3.4-4`	The Direct Segment Discovery route update MUST have a prefix SID attribute which the SID consists of the PE locator followed by a function. (Section 3.3.4)
	MUST	3.3.4	positive`no test`no positive test negative`no test`no negative test {gap}: parseConfigRoute adds the Prefix-SID attribute only when the config supplies one (internal/component/bgp/plugins/nlri/mup/config.go:71), so a DSD route configured without a prefix SID is advertised without one
`DRAFT-IETF-BESS-MUP-SAFI-3.3.7-1`	The MUP Controller MUST set the nexthop of the route to the address of the controller. (§3.3.7)
	MUST	3.3.7	positive`no test`no positive test negative`no test`no negative test {gap}: EncodeRoute takes the next-hop verbatim from the route command (internal/component/bgp/plugins/nlri/mup/encode.go:173-191) for a Type 1 ST route and ze runs no MUP Controller function that substitutes the controller address
`DRAFT-IETF-BESS-MUP-SAFI-3.3.10-1`	The controller MUST attach a Route Target Extended Community of the routing instances in the PE accommodating the corresponding Interwork Segment. (§3.3.10)
	MUST	3.3.10	positive`no test`no positive test negative`no test`no negative test {gap}: parseConfigRoute attaches only the extended communities the operator configures (internal/component/bgp/plugins/nlri/mup/config.go:66) and ze models no routing instance with export route targets, so a Type 2 ST advertisement carries a route target only when the operator writes one into the route
`DRAFT-IETF-BESS-MUP-SAFI-3.3.10-2`	The controller MUST set the nexthop of the route to the address of the MUP Controller. (§3.3.10)
	MUST	3.3.10	positive`no test`no positive test negative`no test`no negative test {gap}: EncodeRoute takes the next-hop verbatim from the route command (internal/component/bgp/plugins/nlri/mup/encode.go:173-191) for a Type 2 ST route and ze runs no MUP Controller function that substitutes the controller address
`DRAFT-IETF-BESS-MUP-SAFI-3.1-1`	Any other Route Types MUST be silently ignored upon a receipt if a BGP speaker supports only 3gpp-5G architecture type. (Section 3.1)
	MUST	3.1	positive`unit/verifyTestMUPOtherRouteTypesSilentlyIgnoredAtIngress` positive`unit/verifyTestRFCMUPUnknownRouteTypeIsNotRejected` negative`unit/verifyTestMUPDefinedRouteTypesSurviveIngress`
`DRAFT-IETF-BESS-MUP-SAFI-3.3.3-1`	However, the receiving BGP speaker MUST ensure that the value of Address filed in the NLRI is an address of the originator of the locator value in the prefix SID attribute. (Section 3.3.3)
	MUST	3.3.3	positive`no test`no positive test negative`no test`no negative test {gap}: DecodeNLRIHex surfaces only route type, architecture type and RD from a received MUP NLRI (internal/component/bgp/plugins/nlri/mup/mup.go:56-73) and ze reads no prefix SID locator anywhere in internal/component/bgp, so the ISD Address field is never checked against the originator of the prefix SID locator
`DRAFT-IETF-BESS-MUP-SAFI-3.3.3-2`	When a BGP speaker receives an MP_UNREACH_NLRI attribute update message it MUST delete the withdrawn Interwork Segment Discovery route from the routing instance table where it was created. (Section 3.3.3)
	MUST	3.3.3	positive`no test`no positive test negative`no test`no negative test {gap}: nlrisplit now registers SplitMUP for SAFI 85 (internal/core/bgp/nlri/nlrisplit/register.go), so insertPoolNLRIs stores a received MUP NLRI as an opaque entry keyed on the whole NLRI and removePoolNLRIs deletes exactly the NLRI a withdrawal names (internal/component/bgp/plugins/rib/rib.go). What remains is that ze models no MUP routing instance: the entry lives in the peer's Adj-RIB-In alone, and no RFC requirement tagged test drives an ISD withdrawal through it
`DRAFT-IETF-BESS-MUP-SAFI-3.3.6-1`	However, the receiving BGP speaker MUST ensure that the received nexthop value in the MP_REACH_NLRI attribute is identical to the originator of the locator value in the prefix SID attribute. (Section 3.3.6)
	MUST	3.3.6	positive`no test`no positive test negative`no test`no negative test {gap}: DecodeNLRIHex surfaces only route type, architecture type and RD from a received MUP NLRI (internal/component/bgp/plugins/nlri/mup/mup.go:56-73) and ze reads no prefix SID locator anywhere in internal/component/bgp, so the DSD nexthop is never compared with the originator of the prefix SID locator
`DRAFT-IETF-BESS-MUP-SAFI-3.3.6-2`	When a BGP speaker receives an MP_UNREACH_NLRI attribute update message it MUST delete the withdrawn Direct Segment Discovery route from the routing instance table where it was created. (Section 3.3.6)
	MUST	3.3.6	positive`no test`no positive test negative`no test`no negative test {gap}: nlrisplit now registers SplitMUP for SAFI 85 (internal/core/bgp/nlri/nlrisplit/register.go), so insertPoolNLRIs stores a received MUP NLRI as an opaque entry keyed on the whole NLRI and removePoolNLRIs deletes exactly the NLRI a withdrawal names (internal/component/bgp/plugins/rib/rib.go). What remains is that ze models no MUP routing instance: the entry lives in the peer's Adj-RIB-In alone, and no RFC requirement tagged test drives a DSD withdrawal through it
`DRAFT-IETF-BESS-MUP-SAFI-3.3.9-1`	The PE receiving Type 1 ST routes in MP_UNREACH_NLRI attribute MUST delete all the routes from the associated routing instance. (Section 3.3.9)
	MUST	3.3.9	positive`no test`no positive test negative`no test`no negative test {gap}: nlrisplit now registers SplitMUP for SAFI 85 (internal/core/bgp/nlri/nlrisplit/register.go), so insertPoolNLRIs stores a received MUP NLRI as an opaque entry keyed on the whole NLRI and removePoolNLRIs deletes exactly the NLRI a withdrawal names (internal/component/bgp/plugins/rib/rib.go). The delete is one NLRI for one NLRI. Nothing reads the Type 1 ST route type to delete every route of the associated routing instance, and ze models no such instance
`DRAFT-IETF-BESS-MUP-SAFI-3.1.1-1`	If the AFI is IPv4, then the maximum value of the Prefix Length is 32 bits otherwise it is considered as a malformed NLRI. If the AFI is IPv6, then the maximum value of of the Prefix length is 128 bits otherwise it is considered as a malformed NLRI. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" [RFC7606]. (§3.1.1)
	MUST	3.1.1	positive`unit/verifyTestMUPMalformedRouteTreatedAsWithdrawnAtIngress` negative`unit/verifyTestMUPWellFormedRouteKeptAtIngress`
`DRAFT-IETF-BESS-MUP-SAFI-3.1.1-2`	A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message. (Section 3.1.1)
	MUST	3.1.1	positive`unit/verifyTestMUPMalformedRouteTreatedAsWithdrawnAtIngress` negative`unit/verifyTestMUPWellFormedRouteKeptAtIngress`
`DRAFT-IETF-BESS-MUP-SAFI-3.1.2-1`	If the AFI is IPv4 then the address length is 4 octets otherwise it is considered as a malformed NLRI. If the AFI is IPv6 then the address length is 16 octets otherwise it is considered as a malformed NLRI. A BGP speaker MUST handle such a malformed NLRI as a "Treat- as-withdraw" [RFC7606]. (§3.1.2)
	MUST	3.1.2	positive`unit/verifyTestMUPMalformedRouteTreatedAsWithdrawnAtIngress` negative`unit/verifyTestMUPWellFormedRouteKeptAtIngress`
`DRAFT-IETF-BESS-MUP-SAFI-3.1.3-1`	If the AFI is IPv4, then the maximum value of the Prefix Length field is 32. If the AFI is IPv6, then the maximum value of the Prefix Length field is 128. Any other length field is considered a a malformed NLRI. A BGP speaker MUST handle such a malformed NLRI as a "Treat- as-withdraw" [RFC7606]. (§3.1.3)
	MUST	3.1.3	positive`unit/verifyTestMUPMalformedRouteTreatedAsWithdrawnAtIngress` negative`unit/verifyTestMUPWellFormedRouteKeptAtIngress`
`DRAFT-IETF-BESS-MUP-SAFI-3.1.3.1-1`	The TEID value of 0 is considered as an invalid and a malformed TEID. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" [RFC7606]. (§3.1.3.1)
	MUST	3.1.3.1	positive`unit/verifyTestMUPMalformedRouteTreatedAsWithdrawnAtIngress` negative`unit/verifyTestMUPWellFormedRouteKeptAtIngress`
`DRAFT-IETF-BESS-MUP-SAFI-3.1.3.1-2`	Endpoint Address field contains of an IPv4 address, then the value of the Endpoint Address Length field is 32. If the Endpoint Address field contains of an IPv6 Address, then the value of the Endpoint Address Length field is 128. Any other value is considered as an invalid and a malformed Endpoint Address. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" [RFC7606]. (§3.1.3.1)
	MUST	3.1.3.1	positive`unit/verifyTestMUPMalformedRouteTreatedAsWithdrawnAtIngress` positive`unit/verifyTestMUPT1STEndpointLengthIsTheOnlyFault` negative`unit/verifyTestMUPWellFormedRouteKeptAtIngress`
`DRAFT-IETF-BESS-MUP-SAFI-3.1.3.1-3`	Source Address Length is 0 bytes then the Source address is not carried within the NLRI. A BGP speaker MAY have a local configuration for using a Source address. The exact mechanism of local configuration is outside the scope of this document. Source Address field contains of an IPv4 address, then the value of the Source Address Length field is 32. If the Source Address field contains of an IPv6 Address, then the value of the Source Address Length field is 128. Any other value is considered as an invalid and a malformed Endpoint Address. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" [RFC7606]. (§3.1.3.1)
	MUST	3.1.3.1	positive`unit/verifyTestMUPMalformedRouteTreatedAsWithdrawnAtIngress` positive`unit/verifyTestMUPT1STSourceLengthIsTheOnlyFault` negative`unit/verifyTestMUPWellFormedRouteKeptAtIngress`
`DRAFT-IETF-BESS-MUP-SAFI-3.1.3.1-6`	- < 0: the mandatory fields exceed the declared Length; the NLRI is malformed; MUST be treated as Treat-as-withdraw. (§3.1.3.1)
	MUST	3.1.3.1	positive`unit/verifyTestMUPMalformedT1STTreatAsWithdraw` positive`unit/verifyTestMUPT1STMandatoryFieldsWithinLength` negative`unit/verifyTestMUPMalformedT1STTreatAsWithdraw` negative`unit/verifyTestMUPT1STMandatoryFieldsWithinLength`
`DRAFT-IETF-BESS-MUP-SAFI-3.1.3.1-7`	- 1: encoding is invalid (a valid TLV requires at minimum a Type byte and a Length byte); MUST be treated as Treat-as- withdraw. (Section 3.1.3.1)
	MUST	3.1.3.1	positive`unit/verifyTestMUPMalformedT1STTreatAsWithdraw` positive`unit/verifyTestMUPT1STTLVFraming` negative`unit/verifyTestMUPT1STTLVFraming`
`DRAFT-IETF-BESS-MUP-SAFI-3.1.3.1-9`	unknown TLV types MUST be ignored for local processing and MUST be propagated unchanged when re- advertising the route to other BGP peers (§3.1.3.1)
	MUST	3.1.3.1	positive`unit/verifyTestMUPT1STUnknownTLVIgnoredAndPropagated` positive`unit/verifyTestMUPUnknownTLVPropagatedUnchangedAtIngress` negative`unit/verifyTestMUPT1STUnknownTLVIgnoredAndPropagated` negative`unit/verifyTestMUPUnknownTLVNotStrippedAtIngress`
`DRAFT-IETF-BESS-MUP-SAFI-3.1.3.1-10`	any TLV parsing error MUST result in Treat-as-withdraw (§3.1.3.1)
	MUST	3.1.3.1	positive`unit/verifyTestMUPMalformedT1STTreatAsWithdraw` positive`unit/verifyTestMUPT1STTLVFraming` negative`unit/verifyTestMUPT1STTLVFraming`
`DRAFT-IETF-BESS-MUP-SAFI-3.1.4-1`	If the AFI is IPv4, then the maximum Endpoint length is 64 otherwise it is considered as a malformed NLRI. If the AFI is IPv6, then the maximum Endpoint length is 160 otherwise it is considered as a malformed NLRI. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" [RFC7606]. (§3.1.4)
	MUST	3.1.4	positive`unit/verifyTestMUPMalformedRouteTreatedAsWithdrawnAtIngress` negative`unit/verifyTestMUPWellFormedRouteKeptAtIngress`
`DRAFT-IETF-BESS-MUP-SAFI-3.1.4.1-1`	The TEID value of 0 is considered as an invalid and a malformed TEID. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" [RFC7606]. (§3.1.4.1)
	MUST	3.1.4.1	positive`unit/verifyTestMUPMalformedRouteTreatedAsWithdrawnAtIngress` negative`unit/verifyTestMUPWellFormedRouteKeptAtIngress`
`DRAFT-IETF-BESS-MUP-SAFI-3.1.4.1-3`	The Endpoint Length MUST NOT extend beyond the TEID field. (§3.1.4.1)
	MUST NOT	3.1.4.1	positive`unit/verifyTestMUPT2STEncoderKeepsEndpointLengthWithinTEID` positive`unit/verifyTestMUPT2STEndpointLengthBoundedByTEID` negative`unit/verifyTestMUPT2STEncoderRefusesEndpointLengthBeyondTEID` negative`unit/verifyTestMUPT2STEndpointLengthBoundedByTEID`
`DRAFT-IETF-BESS-MUP-SAFI-3.1.5-1`	A TLV received in a route type for which it is not applicable MUST be ignored (Section 3.1.5)
	MUST	3.1.5	positive`unit/verifyTestMUPST1IgnoresST2OnlyTLVs` negative`unit/verifyTestMUPST1DoesNotInterpretInapplicableAddressTLV`
`DRAFT-IETF-BESS-MUP-SAFI-3.1.3.1-4`	The NLRI architecture field MUST be encoded as shown above if a BGP speaker receives 3gpp-5g specific BGP Type 1 ST route. Otherwise the NLRI is considered as a malformed. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" [RFC7606]. (Section 3.1.3.1)
	MUST	3.1.3.1	positive`no test`no positive test negative`no test`no negative test {gap}: writeMUPNLRI always writes architecture type 1 (internal/component/bgp/plugins/nlri/mup/encode.go), but the ingress recognizer answers a received NLRI whose architecture is not 3gpp-5g as an unimplemented type and discards it (internal/component/bgp/plugins/nlri/mup/rfc7606.go, RecognizeNLRI), so a T1ST NLRI encoded for another architecture is not treated as withdraw and an earlier route of its key is not removed
`DRAFT-IETF-BESS-MUP-SAFI-3.1.4.1-2`	The NLRI architecture field MUST be encoded as shown above if a BGP speaker receives 3gpp-5g specific BGP Type 2 ST route. Otherwise the NLRI is considered as a malformed. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" [RFC7606]. (Section 3.1.4.1)
	MUST	3.1.4.1	positive`no test`no positive test negative`no test`no negative test {gap}: writeMUPNLRI always writes architecture type 1 (internal/component/bgp/plugins/nlri/mup/encode.go), but the ingress recognizer answers a received NLRI whose architecture is not 3gpp-5g as an unimplemented type and discards it (internal/component/bgp/plugins/nlri/mup/rfc7606.go, RecognizeNLRI), so a T2ST NLRI encoded for another architecture is not treated as withdraw and an earlier route of its key is not removed
`DRAFT-IETF-BESS-MUP-SAFI-3.3.3-3`	When a BGP speaker receives the Interwork Segment Dicovery routes with a MP_REACH_NLRI attribute without a prefix SID attribute, then it MUST be treated as if it contained a malformed prefix SID attribute and the "Treat-as-withdraw procedure of [RFC7606] is applied. (Section 3.3.3)
	MUST	3.3.3	positive`no test`no positive test negative`no test`no negative test {gap}: DecodeNLRIHex surfaces only route type, architecture type and RD from a received MUP NLRI (internal/component/bgp/plugins/nlri/mup/mup.go:56-73) without consulting the UPDATE path attributes, so an ISD route arriving without a Prefix-SID attribute is not treated as withdrawn
`DRAFT-IETF-BESS-MUP-SAFI-3.3.3-4`	If the result of the match is not identical then the receiving BGP speaker MUST consider it as a malformed NLRI and the "Treat-as-withdraw procedure of [RFC7606] is applied. (§3.3.3)
	MUST	3.3.3	positive`no test`no positive test negative`no test`no negative test {gap}: DecodeNLRIHex surfaces only route type, architecture type and RD from a received MUP NLRI (internal/component/bgp/plugins/nlri/mup/mup.go:56-73) and ze reads no prefix SID locator anywhere in internal/component/bgp, so a mismatch between the nexthop and the locator originator is never detected on ISD or DSD routes
`DRAFT-IETF-BESS-MUP-SAFI-3.3.6-4`	If the result of the match is not identical then the receiving BGP speaker MUST consider it as a malformed NLRI and the "Treat-as-withdraw procedure of [RFC7606] is applied. (§3.3.6)
	MUST	3.3.6	positive`no test`no positive test negative`no test`no negative test {gap}: the Direct Segment Discovery form of the nexthop and locator check. The ingress recognizer reads the architecture and route type alone (internal/component/bgp/plugins/nlri/mup/rfc7606.go, RecognizeNLRI) and ze reads no prefix SID locator anywhere in internal/component/bgp, so a DSD route whose MP_REACH_NLRI nexthop differs from the locator originator is stored rather than treated as withdrawn
`DRAFT-IETF-BESS-MUP-SAFI-3.3.6-5`	When a BGP speaker receives a MP_REACH_NLRI attribute update message with a Direct Segment Discovery route without a prefix SID attribute, than it MUST be treated as if it contained a malformed prefix SID attribute and the "Treat-as-withdraw procedure of [RFC7606] is applied. (§3.3.6)
	MUST	3.3.6	positive`unit/verifyTestMUPDSDWithoutPrefixSIDWithdrawnOnReceive` negative`unit/verifyTestMUPDSDWithPrefixSIDKeptOnReceive`
`DRAFT-IETF-BESS-MUP-SAFI-3.3.1-4`	In 3GPP 5G specific case, if the BGP AFI is IPv4, the function MUST be GTP4.E [I-D.ietf-dmm-srv6-mobile-uplane], or MUST be GTP6.E [I-D.ietf-dmm-srv6-mobile-uplane] if the BGP AFI is IPv6. (Section 3.3.1)
	MUST	3.3.1	positive`no test`no positive test negative`no test`no negative test {gap}: parseConfigRoute adds the Prefix-SID attribute only when the config supplies one (internal/component/bgp/plugins/nlri/mup/config.go:71) and passes its bytes through unchanged, and ze decodes no SRv6 endpoint function, so the GTP4.E/GTP6.E function is never tied to the BGP AFI
`DRAFT-IETF-BESS-MUP-SAFI-3.3.5-2`	When withdrawing the Direct Segment Discovery route, a BGP speaker MUST attach a BGP MUP Extended community of the associated routing instance. (Section 3.3.5)
	MUST	3.3.5	positive`no test`no positive test negative`no test`no negative test {gap}: a MUP withdrawal is built as a bare MP_UNREACH_NLRI with no path attributes (internal/component/bgp/reactor/peer_rib_routes.go:182-197), so a DSD withdrawal carries no BGP MUP Extended Community
`DRAFT-IETF-BESS-MUP-SAFI-3.3.8-1`	The controller MUST advertise the withdraws of the Type 1 ST route. (Section 3.3.8)
	MUST	3.3.8	positive`no test`no positive test negative`no test`no negative test {gap}: no MUP NLRI can reach the family-generic MP_UNREACH encoder (internal/component/bgp/reactor/peer_rib_routes.go:170). Its only callers take the NLRI from a PeerOpWithdraw queue entry (internal/component/bgp/reactor/peer_initial_sync.go:237, :377) filled by QueueWithdraw (internal/component/bgp/reactor/peer.go:886-893), and the two withdrawal entry points that feed it parse no SAFI 85: text mode rejects the family in isSupportedFamily, whose list stops at SAFI 73 (internal/component/bgp/plugins/cmd/update/update_text_nlri.go:375-403), and the announce/withdraw registry builds only unicast and FlowSpec NLRIs (internal/component/bgp/plugins/cmd/announce/announce.go:257, :304, :415). NewMUP and NewMUPFull (internal/component/bgp/plugins/nlri/mup/types.go:93, :103) have no non-test caller, and nlrisplit registers no SAFI 85 splitter (internal/core/bgp/nlri/nlrisplit/register.go:9-24) so no received MUP route is stored to be withdrawn either
`DRAFT-IETF-BESS-MUP-SAFI-3.3.9-2`	In an event where the received Type 1 ST route in MP_UNREACH_NLRI attribute does not have a Source address a receiving PE MUST delete all the matching Type 1 ST Routes with different Source addresses. (§3.3.9)
	MUST	3.3.9	positive`no test`no positive test negative`no test`no negative test {gap}: nlrisplit now registers SplitMUP for SAFI 85 (internal/core/bgp/nlri/nlrisplit/register.go), so insertPoolNLRIs stores a received MUP NLRI as an opaque entry keyed on the whole NLRI and removePoolNLRIs deletes exactly the NLRI a withdrawal names (internal/component/bgp/plugins/rib/rib.go). The opaque key is the whole NLRI, Source address included, so a Source-less Type 1 ST withdrawal matches no stored entry. No wildcard delete over differing Source addresses exists
`DRAFT-IETF-BESS-MUP-SAFI-3.3.11-1`	The controller MUST advertise the withdraws of the Type 2 ST route. (Section 3.3.11)
	MUST	3.3.11	positive`no test`no positive test negative`no test`no negative test {gap}: the same missing path as DRAFT-IETF-BESS-MUP-SAFI-3.3.8-1 -- the family-generic MP_UNREACH encoder (internal/component/bgp/reactor/peer_rib_routes.go:170) is reachable only through PeerOpWithdraw (internal/component/bgp/reactor/peer.go:886-893, internal/component/bgp/reactor/peer_initial_sync.go:237, :377), and neither withdrawal entry point produces a SAFI 85 NLRI: isSupportedFamily omits it (internal/component/bgp/plugins/cmd/update/update_text_nlri.go:375-403) and the announce registry builds only unicast and FlowSpec NLRIs (internal/component/bgp/plugins/cmd/announce/announce.go:257, :304, :415)
`DRAFT-IETF-BESS-MUP-SAFI-3.3.3-5`	The BGP speaker receiving the Interwork Segment Discovery routes SHOULD ignore the nexthop in the MP_REACH_NLRI attribute. (§3.3.3)
	SHOULD	3.3.3	positive`no test`no positive test negative`no test`no negative test
`DRAFT-IETF-BESS-MUP-SAFI-3.3.7-4`	When advertising the Type 1 ST route, the controller SHOULD attach a Route Target Extended community which the PEs are importing into the routing instance for the corresponding Direct segment. (§3.3.7)
	SHOULD	3.3.7	positive`no test`no positive test negative`no test`no negative test
`DRAFT-IETF-BESS-MUP-SAFI-3.3.9-3`	In case of a BGP speaker receiving a Type 1 ST routes is a PE, the PE SHOULD use the received Tunnel Endpoint Address in this NLRI as a key to lookup the associated Interwork Segment Discovery route and extract the locator and the function in the prefix SID attribute of the Interwork route. (§3.3.9)
	SHOULD	3.3.9	positive`no test`no positive test negative`no test`no negative test
`DRAFT-IETF-BESS-MUP-SAFI-3.3.6-3`	The BGP speaker receiving the Direct Segment Discovery routes SHOULD ignore the nexthop in the MP_REACH_NLRI attribute. (§3.3.6)
	SHOULD	3.3.6	positive`no test`no positive test negative`no test`no negative test
`DRAFT-IETF-BESS-MUP-SAFI-3.3.9-4`	The PE receiving Type 1 ST routes SHOULD ignore the received nexthop in the MP_REACH_NLRI attribute. (§3.3.9)
	SHOULD	3.3.9	positive`no test`no positive test negative`no test`no negative test
`DRAFT-IETF-BESS-MUP-SAFI-3.3.9-5`	The PE SHOULD generate the forwarding SID for GTP4/6.E based on the procedures mentioned in the [I-D.ietf-dmm-srv6-mobile-uplane]. (§3.3.9)
	SHOULD	3.3.9	positive`no test`no positive test negative`no test`no negative test
`DRAFT-IETF-BESS-MUP-SAFI-3.3.9-6`	If the PE cannot generate the prefix SID, then it SHOULD mark the received Type 1 ST route as an invalid route. (§3.3.9)
	SHOULD	3.3.9	positive`no test`no positive test negative`no test`no negative test
`DRAFT-IETF-BESS-MUP-SAFI-3.3.12-2`	The BGP speaker receiving the Type 2 ST routes SHOULD ignore the received nexthop in the MP_REACH_NLRI attribute. (§3.3.12)
	SHOULD	3.3.12	positive`no test`no positive test negative`no test`no negative test
`DRAFT-IETF-BESS-MUP-SAFI-3.3.12-4`	A PE receiving a Type 2 ST route with a Direct Segment type BGP MUP Extended Community MUST resolve the route using the DSD routes matching that community (Section 3.3.12)
	MUST	3.3.12	positive`no test`no positive test negative`no test`no negative test {gap}: ze resolves no received Type 2 ST route against DSD or ISD routes; the MUP plugin only encodes, decodes and originates MUP NLRIs; internal/component/bgp/plugins/nlri/mup/mup.go
`DRAFT-IETF-BESS-MUP-SAFI-3.3.12-5`	DSD routes MUST NOT be used to resolve Type 2 ST routes that do not carry a Direct Segment type BGP MUP Extended Community (Section 3.3.12)
	MUST NOT	3.3.12	positive`no test`no positive test negative`no test`no negative test {gap}: ze resolves no received Type 2 ST route against DSD or ISD routes; the MUP plugin only encodes, decodes and originates MUP NLRIs; internal/component/bgp/plugins/nlri/mup/mup.go
`DRAFT-IETF-BESS-MUP-SAFI-3.3.12-6`	A PE receiving a Type 2 ST route with an Interwork Segment type BGP MUP Extended Community MUST resolve the route using ISD routes that carry a matching Interwork Segment type BGP MUP Extended Community (Section 3.3.12)
	MUST	3.3.12	positive`no test`no positive test negative`no test`no negative test {gap}: ze resolves no received Type 2 ST route against DSD or ISD routes; the MUP plugin only encodes, decodes and originates MUP NLRIs; internal/component/bgp/plugins/nlri/mup/mup.go
`DRAFT-IETF-BESS-MUP-SAFI-3.3.12-7`	A PE receiving a Type 2 ST route without a BGP MUP Extended Community MUST resolve the route using ISD routes for the default Interwork Segment, i.e., ISD routes that carry no BGP MUP Extended Community. (Section 3.3.12)
	MUST	3.3.12	positive`no test`no positive test negative`no test`no negative test {gap}: ze resolves no received Type 2 ST route against DSD or ISD routes; the MUP plugin only encodes, decodes and originates MUP NLRIs; internal/component/bgp/plugins/nlri/mup/mup.go
`DRAFT-IETF-BESS-MUP-SAFI-3.3.8-2`	When withdrawing the Type 1 ST route, the controller SHOULD attach the Route Target Extended community which the PEs are importing into the routing instance accomodating the corresponding Direct segment to the Route Target Extended community. (§3.3.8)
	SHOULD	3.3.8	positive`no test`no positive test negative`no test`no negative test
`DRAFT-IETF-BESS-MUP-SAFI-3.3.10-3`	When advertising the Type 2 ST route for a Direct Segment, the controller SHOULD attach a Direct Segment type BGP MUP Extended Community. (§3.3.10)
	SHOULD	3.3.10	positive`no test`no positive test negative`no test`no negative test
`DRAFT-IETF-BESS-MUP-SAFI-3.3.11-2`	When withdrawing the Type 2 ST route, the controller SHOULD attach the same BGP MUP Extended Community that was attached when the route was advertised, together with the Route Target Extended Community of the corresponding routing instance. (§3.3.11)
	SHOULD	3.3.11	positive`no test`no positive test negative`no test`no negative test
`DRAFT-IETF-BESS-MUP-SAFI-4-1`	The method defined in [RFC5925] SHOULD be used where authentication of BGP control packets is needed. (§4)
	SHOULD	4	positive`no test`no positive test negative`no test`no negative test
`DRAFT-IETF-BESS-MUP-SAFI-4-2`	The PEs and MUP Controller SHOULD NOT establish BGP sessions with other BGP speakers in the domains which are not trusted without any explicit configuration or an operator intervention. (§4)
	SHOULD NOT	4	positive`no test`no positive test negative`no test`no negative test
`DRAFT-IETF-BESS-MUP-SAFI-4-3`	Usage of procedures defined in [RFC5925] SHOULD be enforced at such boundaries to ensure the proper authentication of BGP control packets. (§4)
	SHOULD	4	positive`no test`no positive test negative`no test`no negative test
`DRAFT-IETF-BESS-MUP-SAFI-4-4`	To protect the BGP messages exchanged between BGP speakers from eavesdrop, establishing BGP sessions over encrypted paths SHOULD be considered. (§4)
	SHOULD	4	positive`no test`no positive test negative`no test`no negative test
`DRAFT-IETF-BESS-MUP-SAFI-4-5`	PEs SHOULD impose an upper bound on number of routes they should store to protect their control plane load. (§4)
	SHOULD	4	positive`no test`no positive test negative`no test`no negative test
`DRAFT-IETF-BESS-MUP-SAFI-3.1-2`	An implementation MAY log an error when such Route Types are ignored. (§3.1)
	MAY	3.1	positive`no test`no positive test negative`no test`no negative test
`DRAFT-IETF-BESS-MUP-SAFI-3.1.3.1-5`	Source Address Length is 0 bytes then the Source address is not carried within the NLRI. A BGP speaker MAY have a local configuration for using a Source address. (§3.1.3.1)
	MAY	3.1.3.1	positive`no test`no positive test negative`no test`no negative test
`DRAFT-IETF-BESS-MUP-SAFI-3.3.1-5`	The IP prefix MAY include a gNodeB address which is connecting to the PE. (§3.3.1)
	MAY	3.3.1	positive`no test`no positive test negative`no test`no negative test
`DRAFT-IETF-BESS-MUP-SAFI-3.3.4-5`	The function MAY be End.DT4/6 or End.DX4/6. (§3.3.4)
	MAY	3.3.4	positive`no test`no positive test negative`no test`no negative test

Gaps and untested MUSTs

Requirement	State	Reason
`DRAFT-IETF-BESS-MUP-SAFI-3.3.1-1` When advertising the Interwork Segment Discovery route, a PE MUST attach the export BGP Route Target Extended Community of the associated routing instance. (Section 3.3.1)	{gap}, no test	parseConfigRoute attaches only the extended communities the operator configures (internal/component/bgp/plugins/nlri/mup/config.go:66) and ze models no routing instance with export route targets, so no export route target is derived for an ISD advertisement
`DRAFT-IETF-BESS-MUP-SAFI-3.3.1-2` When advertising the Interwork Segment Discovery route, a PE MUST use the IPv6 address of the PE as the nexthop address in the MP_REACH_NLRI attribute. (Section 3.3.1)	{gap}, no test	EncodeRoute takes the next-hop verbatim from the route command (internal/component/bgp/plugins/nlri/mup/encode.go:173-191) and accepts an IPv4 next-hop for an ISD route, so nothing requires the IPv6 address of the PE
`DRAFT-IETF-BESS-MUP-SAFI-3.3.1-3` The Interwork Segment Discovery route update MUST have a prefix SID attribute which the SID consists of the PE locater followed by a function. (Section 3.3.1)	{gap}, no test	parseConfigRoute adds the Prefix-SID attribute only when the config supplies one (internal/component/bgp/plugins/nlri/mup/config.go:71), so an ISD route configured without a prefix SID is advertised without one
`DRAFT-IETF-BESS-MUP-SAFI-3.3.2-1` When withdrawing the Interwork Segment Discovery route, a PE MUST attach the export BGP Route Target Extended Community of the associated routing instance. (Section 3.3.2)	{gap}, no test	a MUP withdrawal is built as a bare MP_UNREACH_NLRI with no path attributes (internal/component/bgp/reactor/peer_rib_routes.go:182-197), so an ISD withdrawal carries no export route target
`DRAFT-IETF-BESS-MUP-SAFI-3.3.4-1` The address in the BGP-MUP NLRI MUST be a unique PE identifier. (Section 3.3.4)	{gap}, no test	parseDSDFields accepts any parsable address as the DSD NLRI address (internal/component/bgp/plugins/nlri/mup/encode.go:301-310) and never checks that it identifies the PE uniquely
`DRAFT-IETF-BESS-MUP-SAFI-3.3.4-2` When announcing the Direct Segment Discovery route, a PE MUST attach a BGP MUP Extended community of the associated routing instance. (Section 3.3.4)	{gap}, no test	parseConfigRoute attaches only the extended communities the operator configures (internal/component/bgp/plugins/nlri/mup/config.go:66), so a DSD advertisement carries a BGP MUP Extended Community only when the operator writes one into the route
`DRAFT-IETF-BESS-MUP-SAFI-3.3.4-3` When advertising the Direct Segment Discovery route, a PE MUST use the IPv6 address of the PE as the nexthop address in the MP_REACH_NLRI attribute. (Section 3.3.4)	{gap}, no test	EncodeRoute takes the next-hop verbatim from the route command (internal/component/bgp/plugins/nlri/mup/encode.go:173-191) and accepts an IPv4 next-hop for a DSD route, so nothing requires the IPv6 address of the PE
`DRAFT-IETF-BESS-MUP-SAFI-3.3.4-4` The Direct Segment Discovery route update MUST have a prefix SID attribute which the SID consists of the PE locator followed by a function. (Section 3.3.4)	{gap}, no test	parseConfigRoute adds the Prefix-SID attribute only when the config supplies one (internal/component/bgp/plugins/nlri/mup/config.go:71), so a DSD route configured without a prefix SID is advertised without one
`DRAFT-IETF-BESS-MUP-SAFI-3.3.7-1` The MUP Controller MUST set the nexthop of the route to the address of the controller. (§3.3.7)	{gap}, no test	EncodeRoute takes the next-hop verbatim from the route command (internal/component/bgp/plugins/nlri/mup/encode.go:173-191) for a Type 1 ST route and ze runs no MUP Controller function that substitutes the controller address
`DRAFT-IETF-BESS-MUP-SAFI-3.3.10-1` The controller MUST attach a Route Target Extended Community of the routing instances in the PE accommodating the corresponding Interwork Segment. (§3.3.10)	{gap}, no test	parseConfigRoute attaches only the extended communities the operator configures (internal/component/bgp/plugins/nlri/mup/config.go:66) and ze models no routing instance with export route targets, so a Type 2 ST advertisement carries a route target only when the operator writes one into the route
`DRAFT-IETF-BESS-MUP-SAFI-3.3.10-2` The controller MUST set the nexthop of the route to the address of the MUP Controller. (§3.3.10)	{gap}, no test	EncodeRoute takes the next-hop verbatim from the route command (internal/component/bgp/plugins/nlri/mup/encode.go:173-191) for a Type 2 ST route and ze runs no MUP Controller function that substitutes the controller address
`DRAFT-IETF-BESS-MUP-SAFI-3.3.3-1` However, the receiving BGP speaker MUST ensure that the value of Address filed in the NLRI is an address of the originator of the locator value in the prefix SID attribute. (Section 3.3.3)	{gap}, no test	DecodeNLRIHex surfaces only route type, architecture type and RD from a received MUP NLRI (internal/component/bgp/plugins/nlri/mup/mup.go:56-73) and ze reads no prefix SID locator anywhere in internal/component/bgp, so the ISD Address field is never checked against the originator of the prefix SID locator
`DRAFT-IETF-BESS-MUP-SAFI-3.3.3-2` When a BGP speaker receives an MP_UNREACH_NLRI attribute update message it MUST delete the withdrawn Interwork Segment Discovery route from the routing instance table where it was created. (Section 3.3.3)	{gap}, no test	nlrisplit now registers SplitMUP for SAFI 85 (internal/core/bgp/nlri/nlrisplit/register.go), so insertPoolNLRIs stores a received MUP NLRI as an opaque entry keyed on the whole NLRI and removePoolNLRIs deletes exactly the NLRI a withdrawal names (internal/component/bgp/plugins/rib/rib.go). What remains is that ze models no MUP routing instance: the entry lives in the peer's Adj-RIB-In alone, and no RFC requirement tagged test drives an ISD withdrawal through it
`DRAFT-IETF-BESS-MUP-SAFI-3.3.6-1` However, the receiving BGP speaker MUST ensure that the received nexthop value in the MP_REACH_NLRI attribute is identical to the originator of the locator value in the prefix SID attribute. (Section 3.3.6)	{gap}, no test	DecodeNLRIHex surfaces only route type, architecture type and RD from a received MUP NLRI (internal/component/bgp/plugins/nlri/mup/mup.go:56-73) and ze reads no prefix SID locator anywhere in internal/component/bgp, so the DSD nexthop is never compared with the originator of the prefix SID locator
`DRAFT-IETF-BESS-MUP-SAFI-3.3.6-2` When a BGP speaker receives an MP_UNREACH_NLRI attribute update message it MUST delete the withdrawn Direct Segment Discovery route from the routing instance table where it was created. (Section 3.3.6)	{gap}, no test	nlrisplit now registers SplitMUP for SAFI 85 (internal/core/bgp/nlri/nlrisplit/register.go), so insertPoolNLRIs stores a received MUP NLRI as an opaque entry keyed on the whole NLRI and removePoolNLRIs deletes exactly the NLRI a withdrawal names (internal/component/bgp/plugins/rib/rib.go). What remains is that ze models no MUP routing instance: the entry lives in the peer's Adj-RIB-In alone, and no RFC requirement tagged test drives a DSD withdrawal through it
`DRAFT-IETF-BESS-MUP-SAFI-3.3.9-1` The PE receiving Type 1 ST routes in MP_UNREACH_NLRI attribute MUST delete all the routes from the associated routing instance. (Section 3.3.9)	{gap}, no test	nlrisplit now registers SplitMUP for SAFI 85 (internal/core/bgp/nlri/nlrisplit/register.go), so insertPoolNLRIs stores a received MUP NLRI as an opaque entry keyed on the whole NLRI and removePoolNLRIs deletes exactly the NLRI a withdrawal names (internal/component/bgp/plugins/rib/rib.go). The delete is one NLRI for one NLRI. Nothing reads the Type 1 ST route type to delete every route of the associated routing instance, and ze models no such instance
`DRAFT-IETF-BESS-MUP-SAFI-3.1.3.1-4` The NLRI architecture field MUST be encoded as shown above if a BGP speaker receives 3gpp-5g specific BGP Type 1 ST route. Otherwise the NLRI is considered as a malformed. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" [RFC7606]. (Section 3.1.3.1)	{gap}, no test	writeMUPNLRI always writes architecture type 1 (internal/component/bgp/plugins/nlri/mup/encode.go), but the ingress recognizer answers a received NLRI whose architecture is not 3gpp-5g as an unimplemented type and discards it (internal/component/bgp/plugins/nlri/mup/rfc7606.go, RecognizeNLRI), so a T1ST NLRI encoded for another architecture is not treated as withdraw and an earlier route of its key is not removed
`DRAFT-IETF-BESS-MUP-SAFI-3.1.4.1-2` The NLRI architecture field MUST be encoded as shown above if a BGP speaker receives 3gpp-5g specific BGP Type 2 ST route. Otherwise the NLRI is considered as a malformed. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" [RFC7606]. (Section 3.1.4.1)	{gap}, no test	writeMUPNLRI always writes architecture type 1 (internal/component/bgp/plugins/nlri/mup/encode.go), but the ingress recognizer answers a received NLRI whose architecture is not 3gpp-5g as an unimplemented type and discards it (internal/component/bgp/plugins/nlri/mup/rfc7606.go, RecognizeNLRI), so a T2ST NLRI encoded for another architecture is not treated as withdraw and an earlier route of its key is not removed
`DRAFT-IETF-BESS-MUP-SAFI-3.3.3-3` When a BGP speaker receives the Interwork Segment Dicovery routes with a MP_REACH_NLRI attribute without a prefix SID attribute, then it MUST be treated as if it contained a malformed prefix SID attribute and the "Treat-as-withdraw procedure of [RFC7606] is applied. (Section 3.3.3)	{gap}, no test	DecodeNLRIHex surfaces only route type, architecture type and RD from a received MUP NLRI (internal/component/bgp/plugins/nlri/mup/mup.go:56-73) without consulting the UPDATE path attributes, so an ISD route arriving without a Prefix-SID attribute is not treated as withdrawn
`DRAFT-IETF-BESS-MUP-SAFI-3.3.3-4` If the result of the match is not identical then the receiving BGP speaker MUST consider it as a malformed NLRI and the "Treat-as-withdraw procedure of [RFC7606] is applied. (§3.3.3)	{gap}, no test	DecodeNLRIHex surfaces only route type, architecture type and RD from a received MUP NLRI (internal/component/bgp/plugins/nlri/mup/mup.go:56-73) and ze reads no prefix SID locator anywhere in internal/component/bgp, so a mismatch between the nexthop and the locator originator is never detected on ISD or DSD routes
`DRAFT-IETF-BESS-MUP-SAFI-3.3.6-4` If the result of the match is not identical then the receiving BGP speaker MUST consider it as a malformed NLRI and the "Treat-as-withdraw procedure of [RFC7606] is applied. (§3.3.6)	{gap}, no test	the Direct Segment Discovery form of the nexthop and locator check. The ingress recognizer reads the architecture and route type alone (internal/component/bgp/plugins/nlri/mup/rfc7606.go, RecognizeNLRI) and ze reads no prefix SID locator anywhere in internal/component/bgp, so a DSD route whose MP_REACH_NLRI nexthop differs from the locator originator is stored rather than treated as withdrawn
`DRAFT-IETF-BESS-MUP-SAFI-3.3.1-4` In 3GPP 5G specific case, if the BGP AFI is IPv4, the function MUST be GTP4.E [I-D.ietf-dmm-srv6-mobile-uplane], or MUST be GTP6.E [I-D.ietf-dmm-srv6-mobile-uplane] if the BGP AFI is IPv6. (Section 3.3.1)	{gap}, no test	parseConfigRoute adds the Prefix-SID attribute only when the config supplies one (internal/component/bgp/plugins/nlri/mup/config.go:71) and passes its bytes through unchanged, and ze decodes no SRv6 endpoint function, so the GTP4.E/GTP6.E function is never tied to the BGP AFI
`DRAFT-IETF-BESS-MUP-SAFI-3.3.5-2` When withdrawing the Direct Segment Discovery route, a BGP speaker MUST attach a BGP MUP Extended community of the associated routing instance. (Section 3.3.5)	{gap}, no test	a MUP withdrawal is built as a bare MP_UNREACH_NLRI with no path attributes (internal/component/bgp/reactor/peer_rib_routes.go:182-197), so a DSD withdrawal carries no BGP MUP Extended Community
`DRAFT-IETF-BESS-MUP-SAFI-3.3.8-1` The controller MUST advertise the withdraws of the Type 1 ST route. (Section 3.3.8)	{gap}, no test	no MUP NLRI can reach the family-generic MP_UNREACH encoder (internal/component/bgp/reactor/peer_rib_routes.go:170). Its only callers take the NLRI from a PeerOpWithdraw queue entry (internal/component/bgp/reactor/peer_initial_sync.go:237, :377) filled by QueueWithdraw (internal/component/bgp/reactor/peer.go:886-893), and the two withdrawal entry points that feed it parse no SAFI 85: text mode rejects the family in isSupportedFamily, whose list stops at SAFI 73 (internal/component/bgp/plugins/cmd/update/update_text_nlri.go:375-403), and the announce/withdraw registry builds only unicast and FlowSpec NLRIs (internal/component/bgp/plugins/cmd/announce/announce.go:257, :304, :415). NewMUP and NewMUPFull (internal/component/bgp/plugins/nlri/mup/types.go:93, :103) have no non-test caller, and nlrisplit registers no SAFI 85 splitter (internal/core/bgp/nlri/nlrisplit/register.go:9-24) so no received MUP route is stored to be withdrawn either
`DRAFT-IETF-BESS-MUP-SAFI-3.3.9-2` In an event where the received Type 1 ST route in MP_UNREACH_NLRI attribute does not have a Source address a receiving PE MUST delete all the matching Type 1 ST Routes with different Source addresses. (§3.3.9)	{gap}, no test	nlrisplit now registers SplitMUP for SAFI 85 (internal/core/bgp/nlri/nlrisplit/register.go), so insertPoolNLRIs stores a received MUP NLRI as an opaque entry keyed on the whole NLRI and removePoolNLRIs deletes exactly the NLRI a withdrawal names (internal/component/bgp/plugins/rib/rib.go). The opaque key is the whole NLRI, Source address included, so a Source-less Type 1 ST withdrawal matches no stored entry. No wildcard delete over differing Source addresses exists
`DRAFT-IETF-BESS-MUP-SAFI-3.3.11-1` The controller MUST advertise the withdraws of the Type 2 ST route. (Section 3.3.11)	{gap}, no test	the same missing path as DRAFT-IETF-BESS-MUP-SAFI-3.3.8-1 -- the family-generic MP_UNREACH encoder (internal/component/bgp/reactor/peer_rib_routes.go:170) is reachable only through PeerOpWithdraw (internal/component/bgp/reactor/peer.go:886-893, internal/component/bgp/reactor/peer_initial_sync.go:237, :377), and neither withdrawal entry point produces a SAFI 85 NLRI: isSupportedFamily omits it (internal/component/bgp/plugins/cmd/update/update_text_nlri.go:375-403) and the announce registry builds only unicast and FlowSpec NLRIs (internal/component/bgp/plugins/cmd/announce/announce.go:257, :304, :415)
`DRAFT-IETF-BESS-MUP-SAFI-3.3.12-4` A PE receiving a Type 2 ST route with a Direct Segment type BGP MUP Extended Community MUST resolve the route using the DSD routes matching that community (Section 3.3.12)	{gap}, no test	ze resolves no received Type 2 ST route against DSD or ISD routes; the MUP plugin only encodes, decodes and originates MUP NLRIs; internal/component/bgp/plugins/nlri/mup/mup.go
`DRAFT-IETF-BESS-MUP-SAFI-3.3.12-5` DSD routes MUST NOT be used to resolve Type 2 ST routes that do not carry a Direct Segment type BGP MUP Extended Community (Section 3.3.12)	{gap}, no test	ze resolves no received Type 2 ST route against DSD or ISD routes; the MUP plugin only encodes, decodes and originates MUP NLRIs; internal/component/bgp/plugins/nlri/mup/mup.go
`DRAFT-IETF-BESS-MUP-SAFI-3.3.12-6` A PE receiving a Type 2 ST route with an Interwork Segment type BGP MUP Extended Community MUST resolve the route using ISD routes that carry a matching Interwork Segment type BGP MUP Extended Community (Section 3.3.12)	{gap}, no test	ze resolves no received Type 2 ST route against DSD or ISD routes; the MUP plugin only encodes, decodes and originates MUP NLRIs; internal/component/bgp/plugins/nlri/mup/mup.go
`DRAFT-IETF-BESS-MUP-SAFI-3.3.12-7` A PE receiving a Type 2 ST route without a BGP MUP Extended Community MUST resolve the route using ISD routes for the default Interwork Segment, i.e., ISD routes that carry no BGP MUP Extended Community. (Section 3.3.12)	{gap}, no test	ze resolves no received Type 2 ST route against DSD or ISD routes; the MUP plugin only encodes, decodes and originates MUP NLRIs; internal/component/bgp/plugins/nlri/mup/mup.go

Proof state

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

`DRAFT-IETF-BESS-MUP-SAFI-3.3.1-1`

When advertising the Interwork Segment Discovery route, a PE MUST attach the export BGP Route Target Extended Community of the associated routing instance. (Section 3.3.1)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.1-1, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.3.1-2`

When advertising the Interwork Segment Discovery route, a PE MUST use the IPv6 address of the PE as the nexthop address in the MP_REACH_NLRI attribute. (Section 3.3.1)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.1-2, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.3.1-3`

The Interwork Segment Discovery route update MUST have a prefix SID attribute which the SID consists of the PE locater followed by a function. (Section 3.3.1)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.1-3, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.3.2-1`

When withdrawing the Interwork Segment Discovery route, a PE MUST attach the export BGP Route Target Extended Community of the associated routing instance. (Section 3.3.2)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.2-1, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.3.4-1`

The address in the BGP-MUP NLRI MUST be a unique PE identifier. (Section 3.3.4)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.4-1, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.3.4-2`

When announcing the Direct Segment Discovery route, a PE MUST attach a BGP MUP Extended community of the associated routing instance. (Section 3.3.4)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.4-2, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.3.4-3`

When advertising the Direct Segment Discovery route, a PE MUST use the IPv6 address of the PE as the nexthop address in the MP_REACH_NLRI attribute. (Section 3.3.4)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.4-3, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.3.4-4`

The Direct Segment Discovery route update MUST have a prefix SID attribute which the SID consists of the PE locator followed by a function. (Section 3.3.4)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.4-4, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.3.7-1`

The MUP Controller MUST set the nexthop of the route to the address of the controller. (§3.3.7)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.7-1, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.3.10-1`

The controller MUST attach a Route Target Extended Community of the routing instances in the PE accommodating the corresponding Interwork Segment. (§3.3.10)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.10-1, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.3.10-2`

The controller MUST set the nexthop of the route to the address of the MUP Controller. (§3.3.10)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.10-2, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.1-1`

Any other Route Types MUST be silently ignored upon a receipt if a BGP speaker supports only 3gpp-5G architecture type. (Section 3.1)

Audit verdict: weak (the tests pass over code that does not enforce the requirement), fresh. Re-judged 2026-10-15 (subagent, after ba1200a2af). Draft Section 3.1: "Any other Route Types MUST be silently ignored upon a receipt if a BGP speaker supports only 3gpp-5G architecture type." TestMUPDefinedRouteTypesSurviveIngress changed only by inlining the local cat helper into concatNLRI: the four route-type NLRIs are byte-identical and its assertions unchanged; its RecognizeNLRI revert record was re-observed red today. The weak finding on the positive stands unchanged: Re-judged 2026-10-14 (independent auditor). Draft Section 3.1: "Any other Route Types MUST be silently ignored upon a receipt if a BGP speaker supports only 3gpp-5G architecture type." The retainMUP helper changed with the three-way Recognizer and now returns r.Discarded + r.WithdrawnCount as dropped. keyMUP keys an unknown route type on its whole wire NLRI, so a recognizer that answered Withdraw for route types 0, 5, 99 and 0xFFFF would put each in Withdrawn and TestMUPOtherRouteTypesSilentlyIgnoredAtIngress would still see dropped == 4 and the ISD kept: the positive no longer tells a silent ignore from a treat-as-withdraw, which emits a withdrawal. Asserting r.Discarded == 4 and r.WithdrawnCount == 0 would restore it. TestRFCMUPUnknownRouteTypeIsNotRejected pins only that ParseMUP skips the unknown NLRI by its Length; the negative TestMUPDefinedRouteTypesSurviveIngress (types 1..4 well-formed, kept whole, dropped zero) is sound. The exact Discard answer is asserted, but only under RFC7606-5.4-1's tags (mup TestRecognizeNLRIRejectsUnimplementedTypes).

Polarity	Test	Kind and tier	Proof state
negative	`TestMUPDefinedRouteTypesSurviveIngress`	unit/verify	revert, verified
positive	`TestMUPOtherRouteTypesSilentlyIgnoredAtIngress`	unit/verify	revert, verified
positive	`TestRFCMUPUnknownRouteTypeIsNotRejected`	unit/verify	revert, verified

`DRAFT-IETF-BESS-MUP-SAFI-3.3.3-1`

However, the receiving BGP speaker MUST ensure that the value of Address filed in the NLRI is an address of the originator of the locator value in the prefix SID attribute. (Section 3.3.3)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.3-1, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.3.3-2`

When a BGP speaker receives an MP_UNREACH_NLRI attribute update message it MUST delete the withdrawn Interwork Segment Discovery route from the routing instance table where it was created. (Section 3.3.3)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.3-2, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.3.6-1`

However, the receiving BGP speaker MUST ensure that the received nexthop value in the MP_REACH_NLRI attribute is identical to the originator of the locator value in the prefix SID attribute. (Section 3.3.6)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.6-1, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.3.6-2`

When a BGP speaker receives an MP_UNREACH_NLRI attribute update message it MUST delete the withdrawn Direct Segment Discovery route from the routing instance table where it was created. (Section 3.3.6)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.6-2, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.3.9-1`

The PE receiving Type 1 ST routes in MP_UNREACH_NLRI attribute MUST delete all the routes from the associated routing instance. (Section 3.3.9)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.9-1, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.1.1-1`

If the AFI is IPv4, then the maximum value of the Prefix Length is 32 bits otherwise it is considered as a malformed NLRI. If the AFI is IPv6, then the maximum value of of the Prefix length is 128 bits otherwise it is considered as a malformed NLRI. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" [RFC7606]. (§3.1.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Judged 2026-10-14 (independent auditor, spec-bgp-update-propagation-rfc-defects Q-1 (a)). Both units drive nlritype.Get(fam), the recognizer the mup plugin's init registers (recognizerFor: RecognizeNLRI then ValidateNLRI), through nlritype.Retain, the call typedNLRIEdit makes at ingress, with the route between two well-formed ISD siblings. Positive TestMUPMalformedRouteTreatedAsWithdrawnAtIngress: ISD prefix length 33 under IPv4 (5 prefix octets, so only the bound is wrong) is withdrawn exactly, WithdrawnCount 1, Discarded 0, siblings kept in order; removing parsePrefixField's AFI bound would parse it cleanly and go red. ISD prefix length 129 under IPv6 is unkeyable and lands in Unkeyable, discarded: no earlier generation can exist under a key that cannot form, so the stack outcome matches treat-as-withdraw, though that half is decided by keyMUP's 128 bound, not the parser. Negative TestMUPWellFormedRouteKeptAtIngress: 32 under IPv4 and 128 under IPv6 kept whole.

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

`DRAFT-IETF-BESS-MUP-SAFI-3.1.1-2`

A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message. (Section 3.1.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Judged 2026-10-14 (independent auditor, spec-bgp-update-propagation-rfc-defects Q-1 (a)). Both units drive nlritype.Get(fam), the recognizer the mup plugin's init registers (recognizerFor: RecognizeNLRI then ValidateNLRI), through nlritype.Retain, the call typedNLRIEdit makes at ingress, with the route between two well-formed ISD siblings. Draft Section 3.1.1: "A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message." Positive TestMUPMalformedRouteTreatedAsWithdrawnAtIngress: for each of the 13 malformed shapes Kept equals exactly the sibling before and the sibling after, in order, so processing continued past the malformed route; red on a pass that stops at the first malformed NLRI or drops the section. Negative TestMUPWellFormedRouteKeptAtIngress: every legal boundary shape between siblings leaves the section whole with nothing withdrawn, unkeyable or discarded.

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

`DRAFT-IETF-BESS-MUP-SAFI-3.1.2-1`

If the AFI is IPv4 then the address length is 4 octets otherwise it is considered as a malformed NLRI. If the AFI is IPv6 then the address length is 16 octets otherwise it is considered as a malformed NLRI. A BGP speaker MUST handle such a malformed NLRI as a "Treat- as-withdraw" [RFC7606]. (§3.1.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Judged 2026-10-14 (independent auditor, spec-bgp-update-propagation-rfc-defects Q-1 (a)). Both units drive nlritype.Get(fam), the recognizer the mup plugin's init registers (recognizerFor: RecognizeNLRI then ValidateNLRI), through nlritype.Retain, the call typedNLRIEdit makes at ingress, with the route between two well-formed ISD siblings. Positive TestMUPMalformedRouteTreatedAsWithdrawnAtIngress: a DSD route with a 16-octet address under IPv4 and with a 4-octet address under IPv6 are each withdrawn exactly; parseBodyDSD's length check is the only rule those buffers trip (keyMUP keys both 12- and 24-octet bodies), so removing it goes red. Negative TestMUPWellFormedRouteKeptAtIngress: 4 octets under IPv4 and 16 under IPv6 kept.

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

`DRAFT-IETF-BESS-MUP-SAFI-3.1.3-1`

If the AFI is IPv4, then the maximum value of the Prefix Length field is 32. If the AFI is IPv6, then the maximum value of the Prefix Length field is 128. Any other length field is considered a a malformed NLRI. A BGP speaker MUST handle such a malformed NLRI as a "Treat- as-withdraw" [RFC7606]. (§3.1.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Judged 2026-10-14 (independent auditor, spec-bgp-update-propagation-rfc-defects Q-1 (a)). Both units drive nlritype.Get(fam), the recognizer the mup plugin's init registers (recognizerFor: RecognizeNLRI then ValidateNLRI), through nlritype.Retain, the call typedNLRIEdit makes at ingress, with the route between two well-formed ISD siblings. Positive TestMUPMalformedRouteTreatedAsWithdrawnAtIngress: a Type 1 ST route with prefix length 33 under IPv4 and five prefix octets is withdrawn exactly and keyable; without parsePrefixField's bound the rest parses cleanly, so the case discriminates. Negative TestMUPWellFormedRouteKeptAtIngress: prefix length 32 under IPv4 kept. The IPv6 clause (128) has no T1ST case in the tagged units: it rests on the same AFI-indexed parsePrefixField bound, which the ISD IPv6 128 negative pins from below, and an IPv6 T1ST above 128 is unkeyable (keyMUP), which the untagged TestMUPRecognizerVerdicts and AC-10a cover.

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

`DRAFT-IETF-BESS-MUP-SAFI-3.1.3.1-1`

The TEID value of 0 is considered as an invalid and a malformed TEID. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" [RFC7606]. (§3.1.3.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Judged 2026-10-14 (independent auditor, spec-bgp-update-propagation-rfc-defects Q-1 (a)). Both units drive nlritype.Get(fam), the recognizer the mup plugin's init registers (recognizerFor: RecognizeNLRI then ValidateNLRI), through nlritype.Retain, the call typedNLRIEdit makes at ingress, with the route between two well-formed ISD siblings. Draft Section 3.1.3.1: "The TEID value of 0 is considered as an invalid and a malformed TEID." Positive TestMUPMalformedRouteTreatedAsWithdrawnAtIngress: a Type 1 ST route otherwise identical to the kept one but with TEID 0 is withdrawn exactly; parseBodyT1ST's ErrMUPTEIDZero check is the only rule it trips, so removing it goes red. Negative TestMUPWellFormedRouteKeptAtIngress: TEID 1 kept.

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

`DRAFT-IETF-BESS-MUP-SAFI-3.1.3.1-2`

Endpoint Address field contains of an IPv4 address, then the value of the Endpoint Address Length field is 32. If the Endpoint Address field contains of an IPv6 Address, then the value of the Endpoint Address Length field is 128. Any other value is considered as an invalid and a malformed Endpoint Address. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" [RFC7606]. (§3.1.3.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after 7414ef24cc). Section 3.1.3.1: "Any other value is considered as an invalid and a malformed Endpoint Address. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" [RFC7606]." The earlier finding (question 3, the 24-length case was withdrawn by a later field check with the rule gone) is answered by the new unit TestMUPT1STEndpointLengthIsTheOnlyFault, which drives the registered recognizer through nlritype.Retain between two well-formed ISD siblings and asserts the exact Kept, Withdrawn, WithdrawnCount 1 and zero Discarded. Its two buffers each parse as a valid route under one wrong reading: length 24 then Source Address Length 0 is well formed if addressBitsOctets accepts 24 as zero octets, and length 24 then three address octets then Source Address Length 0 is well formed if it rounds up to (24+7)/8, so removing the check in parseBodyT1ST or either mutant of addressBitsOctets keeps one case and goes red. Negative TestMUPWellFormedRouteKeptAtIngress keeps 32 with an IPv4 endpoint and 128 with an IPv6 endpoint, sound. Residual: only 24 is sampled as an other value, and only under ipv4/mup.

Polarity	Test	Kind and tier	Proof state
negative	`TestMUPWellFormedRouteKeptAtIngress`	unit/verify	revert, verified
positive	`TestMUPMalformedRouteTreatedAsWithdrawnAtIngress`	unit/verify	revert, verified
positive	`TestMUPT1STEndpointLengthIsTheOnlyFault`	unit/verify	revert, verified

`DRAFT-IETF-BESS-MUP-SAFI-3.1.3.1-3`

Source Address Length is 0 bytes then the Source address is not carried within the NLRI. A BGP speaker MAY have a local configuration for using a Source address. The exact mechanism of local configuration is outside the scope of this document. Source Address field contains of an IPv4 address, then the value of the Source Address Length field is 32. If the Source Address field contains of an IPv6 Address, then the value of the Source Address Length field is 128. Any other value is considered as an invalid and a malformed Endpoint Address. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" [RFC7606]. (§3.1.3.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-18 (independent auditor, after 7414ef24cc). Section 3.1.3.1 gives the Source Address Length 0, 32 or 128 and "Any other value is considered as an invalid and a malformed Endpoint Address. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" [RFC7606]." The earlier finding (the 16-length case was withdrawn by validateTLVs with the rule gone) is answered by TestMUPT1STSourceLengthIsTheOnlyFault: a valid IPv4 endpoint then Source Address Length 16 followed by nothing, or by one valid TLV (0xf0, length 1), each parses as a well-formed route when the length reads as zero octets, so dropping the !sourceOK check in parseBodyT1ST keeps both and the exact Kept/Withdrawn/WithdrawnCount assertions go red; the older 16, 10, 1 case still catches a mutant that rounds 16 up to two octets. Negative TestMUPWellFormedRouteKeptAtIngress keeps 0, 32 with an IPv4 source and 128 with an IPv6 source, sound. The MAY clause on local source configuration binds nothing testable.

Polarity	Test	Kind and tier	Proof state
negative	`TestMUPWellFormedRouteKeptAtIngress`	unit/verify	revert, verified
positive	`TestMUPMalformedRouteTreatedAsWithdrawnAtIngress`	unit/verify	revert, verified
positive	`TestMUPT1STSourceLengthIsTheOnlyFault`	unit/verify	revert, verified

`DRAFT-IETF-BESS-MUP-SAFI-3.1.3.1-6`

- < 0: the mandatory fields exceed the declared Length; the NLRI is malformed; MUST be treated as Treat-as-withdraw. (§3.1.3.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-14 (independent auditor, D3). Draft Section 3.1.3.1: "< 0: the mandatory fields exceed the declared Length; the NLRI is malformed; MUST be treated as Treat-as-withdraw." TestMUPMalformedT1STTreatAsWithdraw runs classifyRFC7606 and applyRFC7606 with the real registered ipv4/mup recognizer (the reactor test binary links the mup plugin) over L, K, L2 where K's Length ends inside the Endpoint Address: ActionNone, MP_REACH keeps exactly L then L2, MP_UNREACH carries exactly K; red if K is kept, dropped without a withdrawal, or the session resets. Its negative subtest returns an UPDATE of well-formed L and L2 (L2 with unknown TLV 0xF0) byte for byte. TestMUPT1STMandatoryFieldsWithinLength pins ParseMUP's ErrMUPTruncated, the answer ValidateNLRI turns into Withdraw. The earlier finding (decode path only, ingress stored the route) is closed by recognizerFor.

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

`DRAFT-IETF-BESS-MUP-SAFI-3.1.3.1-7`

- 1: encoding is invalid (a valid TLV requires at minimum a Type byte and a Length byte); MUST be treated as Treat-as- withdraw. (Section 3.1.3.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-14 (independent auditor, D3). Draft Section 3.1.3.1: "1: encoding is invalid (a valid TLV requires at minimum a Type byte and a Length byte); MUST be treated as Treat-as- withdraw." TestMUPMalformedT1STTreatAsWithdraw subtest one octet of TLV area: K carries Source Address Length 0 then the single octet 0xF0, so the remaining count after the end of the Source Address is exactly 1; over applyRFC7606 with the real recognizer K leaves MP_REACH, siblings kept byte for byte, K withdrawn in MP_UNREACH, ActionNone. TestMUPT1STTLVFraming pins validateTLVs' ErrMUPTLV for the leftover octet and accepts the well-formed framings. The earlier finding (ingress never validated TLVs) is closed by recognizerFor.

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

`DRAFT-IETF-BESS-MUP-SAFI-3.1.3.1-9`

unknown TLV types MUST be ignored for local processing and MUST be propagated unchanged when re- advertising the route to other BGP peers (§3.1.3.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Propagate clause: TestMUPUnknownTLVPropagatedUnchangedAtIngress asserts the section kept by nlritype.Retain with the registered recognizer (the section typedNLRIEdit relays) equals the received T1ST with unknown TLV 0xF0, both unchanged and when a sibling unknown route type forces the rebuild; red on any re-encode that strips or rewrites the TLV. Local-processing clause: ParseMUP of the kept route yields the TEID and endpoint of the TLV-less route (and TestMUPT1STUnknownTLVIgnoredAndPropagated pins prefix, bits, TEID, QFI, endpoint, and that only a framing error refuses). Negatives: TestMUPUnknownTLVNotStrippedAtIngress pins length +5, Length octet +5, trailing TLV octets; the tlv_mup_test negative pins Bytes() is not the TLV-less form. The negatives are the complement of the positives' byte equality rather than an independent input, acceptable for a propagate-unchanged obligation. Records observed red for every unit (Retain, validateTLVs, ParseMUP)

Polarity	Test	Kind and tier	Proof state
negative	`TestMUPUnknownTLVNotStrippedAtIngress`	unit/verify	revert, verified
negative	`TestMUPT1STUnknownTLVIgnoredAndPropagated`	unit/verify	revert, verified
positive	`TestMUPUnknownTLVPropagatedUnchangedAtIngress`	unit/verify	revert, verified
positive	`TestMUPT1STUnknownTLVIgnoredAndPropagated`	unit/verify	revert, verified

`DRAFT-IETF-BESS-MUP-SAFI-3.1.3.1-10`

any TLV parsing error MUST result in Treat-as-withdraw (§3.1.3.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-14 (independent auditor, D3). Draft Section 3.1.3.1: "any TLV parsing error MUST result in Treat-as-withdraw". TestMUPMalformedT1STTreatAsWithdraw subtest TLV overruns the NLRI: TLV 0xF0 declaring Length 5 over one octet; K leaves MP_REACH and is withdrawn in MP_UNREACH, siblings kept, ActionNone; a validateTLVs that stopped checking the overrun would return Keep and go red. TestMUPT1STTLVFraming pins ErrMUPTLV for the overrun and the well-formed framings as its negative.

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

`DRAFT-IETF-BESS-MUP-SAFI-3.1.4-1`

If the AFI is IPv4, then the maximum Endpoint length is 64 otherwise it is considered as a malformed NLRI. If the AFI is IPv6, then the maximum Endpoint length is 160 otherwise it is considered as a malformed NLRI. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" [RFC7606]. (§3.1.4)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Judged 2026-10-14 (independent auditor, spec-bgp-update-propagation-rfc-defects Q-1 (a)). Both units drive nlritype.Get(fam), the recognizer the mup plugin's init registers (recognizerFor: RecognizeNLRI then ValidateNLRI), through nlritype.Retain, the call typedNLRIEdit makes at ingress, with the route between two well-formed ISD siblings. Positive TestMUPMalformedRouteTreatedAsWithdrawnAtIngress: a Type 2 ST route with Endpoint Length 65 under IPv4 and five octets after the address is withdrawn exactly; without parseBodyT2ST's teidBits > 32 check it parses as a 5-octet TEID and is kept, so the case discriminates. Endpoint Length 161 under IPv6 is unkeyable (keyMUP's 160 bound) and discarded, the stack outcome matching treat-as-withdraw. Negative TestMUPWellFormedRouteKeptAtIngress: 64 under IPv4 and 160 under IPv6 kept.

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

`DRAFT-IETF-BESS-MUP-SAFI-3.1.4.1-1`

The TEID value of 0 is considered as an invalid and a malformed TEID. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" [RFC7606]. (§3.1.4.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Judged 2026-10-14 (independent auditor, spec-bgp-update-propagation-rfc-defects Q-1 (a)). Both units drive nlritype.Get(fam), the recognizer the mup plugin's init registers (recognizerFor: RecognizeNLRI then ValidateNLRI), through nlritype.Retain, the call typedNLRIEdit makes at ingress, with the route between two well-formed ISD siblings. Draft Section 3.1.4.1: "The TEID value of 0 is considered as an invalid and a malformed TEID." Positive TestMUPMalformedRouteTreatedAsWithdrawnAtIngress: a Type 2 ST route with Endpoint Length 64 and a 4-octet TEID of 0 is withdrawn exactly; ErrMUPTEIDZero is the only rule it trips, so removing it goes red. Negative TestMUPWellFormedRouteKeptAtIngress: TEID 1 kept, and a route with Endpoint Length 32 and no TEID kept (the check binds only a carried TEID).

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

`DRAFT-IETF-BESS-MUP-SAFI-3.1.4.1-3`

The Endpoint Length MUST NOT extend beyond the TEID field. (§3.1.4.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Encoder (the sender side the MUST NOT binds): TestMUPT2STEncoderKeepsEndpointLengthWithinTEID asserts EncodeNLRIHex writes Endpoint Length address bits + 0/16/32 (32 default) for IPv4 and IPv6; TestMUPT2STEncoderRefusesEndpointLengthBeyondTEID asserts teid bits 33 and 40 (v4, v6), -8 and unreadable are refused with errTeidBits. Author observed all five negatives red on HEAD's parseTEIDWithBits (D-8 defect fixed in encode.go, re-checked at the producer: both callers propagate the error). Decode path: TestMUPT2STEndpointLengthBoundedByTEID, 64 parses, 72 refused ErrMUPEndpointTooLong. Not covered here: ingress (RecognizeNLRI) does not refuse an over-long Endpoint Length from a peer, so such a route is stored and relayed; that receive handling is the Section 3.1.4 malformed rule (3.1.4-1, a disclosed {gap}), not this sentence

Polarity	Test	Kind and tier	Proof state
negative	`TestMUPT2STEncoderRefusesEndpointLengthBeyondTEID`	unit/verify	revert, verified
negative	`TestMUPT2STEndpointLengthBoundedByTEID`	unit/verify	revert, verified
positive	`TestMUPT2STEncoderKeepsEndpointLengthWithinTEID`	unit/verify	revert, verified
positive	`TestMUPT2STEndpointLengthBoundedByTEID`	unit/verify	revert, verified

`DRAFT-IETF-BESS-MUP-SAFI-3.1.5-1`

A TLV received in a route type for which it is not applicable MUST be ignored (Section 3.1.5)

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

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

`DRAFT-IETF-BESS-MUP-SAFI-3.1.3.1-4`

The NLRI architecture field MUST be encoded as shown above if a BGP speaker receives 3gpp-5g specific BGP Type 1 ST route. Otherwise the NLRI is considered as a malformed. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" [RFC7606]. (Section 3.1.3.1)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.1.3.1-4, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.1.4.1-2`

The NLRI architecture field MUST be encoded as shown above if a BGP speaker receives 3gpp-5g specific BGP Type 2 ST route. Otherwise the NLRI is considered as a malformed. A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" [RFC7606]. (Section 3.1.4.1)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.1.4.1-2, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.3.3-3`

When a BGP speaker receives the Interwork Segment Dicovery routes with a MP_REACH_NLRI attribute without a prefix SID attribute, then it MUST be treated as if it contained a malformed prefix SID attribute and the "Treat-as-withdraw procedure of [RFC7606] is applied. (Section 3.3.3)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.3-3, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.3.3-4`

If the result of the match is not identical then the receiving BGP speaker MUST consider it as a malformed NLRI and the "Treat-as-withdraw procedure of [RFC7606] is applied. (§3.3.3)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.3-4, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.3.6-4`

If the result of the match is not identical then the receiving BGP speaker MUST consider it as a malformed NLRI and the "Treat-as-withdraw procedure of [RFC7606] is applied. (§3.3.6)

Audit verdict: unimplemented (no code path enforces the requirement), fresh. Re-judged 2026-10-14 (independent auditor) after the receive recognizer changed. recognizerFor (mup/rfc7606.go) now runs RecognizeNLRI then ValidateNLRI, which checks the NLRI body alone: Retain hands it one NLRI and no path attributes, and no code in internal/component/bgp reads a Prefix-SID SRv6 locator or compares it with a DSD MP_REACH next hop, so a DSD route whose next hop and locator differ is still stored rather than treated as withdrawn. The {gap} annotation's phrase "reads the architecture and route type alone" is now out of date (the body is also validated), but its conclusion holds.

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.6-4, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.3.6-5`

When a BGP speaker receives a MP_REACH_NLRI attribute update message with a Direct Segment Discovery route without a prefix SID attribute, than it MUST be treated as if it contained a malformed prefix SID attribute and the "Treat-as-withdraw procedure of [RFC7606] is applied. (§3.3.6)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-19 (independent auditor, after 691bd048e9). draft-ietf-bess-mup-safi Section 3.3.6: "When a BGP speaker receives a MP_REACH_NLRI attribute update message with a Direct Segment Discovery route without a prefix SID attribute, than it MUST be treated as if it contained a malformed prefix SID attribute and the "Treat-as-withdraw procedure of [RFC7606] is applied. A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message." The earlier unimplemented verdict is superseded: mup/rfc7606.go::CheckDSDPrefixSID is registered by mup/register.go for both ipv4/mup and ipv6/mup through nlritype.RegisterUpdateCheck, and the receive path (Session.applyRFC7606 -> applyTypedNLRIDiscard -> typedNLRIEdit -> nlritype.RetainUpdate) moves an announced DSD route with no Prefix-SID out of MP_REACH_NLRI into MP_UNREACH_NLRI per NLRI, keeping its siblings and the session; typedNLRIUpdateAttrs counts a Prefix-SID that RFC 7606 attribute-discard removes (the RFC 8669 Section 4 EBGP rule) as absent. Tests drive whole hex UPDATE bodies through Session.enforceRFC7606 and assert exact bytes: TestMUPDSDWithoutPrefixSIDWithdrawnOnReceive (kept MP_REACH NLRI equals the ISD sibling, MP_UNREACH NLRI equals the DSD route, no error, for both an absent and an EBGP-discarded Prefix-SID) and TestMUPDSDWithPrefixSIDKeptOnReceive (DSD with a Prefix-SID, and ISD plus Type 2 ST without one, return RFC7606ActionNone and the UPDATE byte for byte). The recorded discrimination breaks are panics, which prove reach only, so five overlay mutants were run (go test -overlay, tags ze_core ze_bgp): Keep instead of Withdraw when the Prefix-SID is absent (positive red, both cases); withdraw a DSD even with a Prefix-SID (negative DSD case red); drop the route-type test so every type is withdrawn (positive and negative ISD/T2ST case red); Discard instead of Withdraw (positive red, "withdrawn, not dropped"); ignore attribute-discard entries in typedNLRIUpdateAttrs (positive EBGP-discard case red). All five killed. Residual: only AFI 1 is exercised; the AFI 2 family is covered by the same registration loop, not by a test. test/plugin/mup-dsd-without-prefix-sid-withdraw.ci exists but is untagged and was not run here.

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

`DRAFT-IETF-BESS-MUP-SAFI-3.3.1-4`

In 3GPP 5G specific case, if the BGP AFI is IPv4, the function MUST be GTP4.E [I-D.ietf-dmm-srv6-mobile-uplane], or MUST be GTP6.E [I-D.ietf-dmm-srv6-mobile-uplane] if the BGP AFI is IPv6. (Section 3.3.1)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.1-4, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.3.5-2`

When withdrawing the Direct Segment Discovery route, a BGP speaker MUST attach a BGP MUP Extended community of the associated routing instance. (Section 3.3.5)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.5-2, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.3.8-1`

The controller MUST advertise the withdraws of the Type 1 ST route. (Section 3.3.8)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.8-1, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.3.9-2`

In an event where the received Type 1 ST route in MP_UNREACH_NLRI attribute does not have a Source address a receiving PE MUST delete all the matching Type 1 ST Routes with different Source addresses. (§3.3.9)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.9-2, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.3.11-1`

The controller MUST advertise the withdraws of the Type 2 ST route. (Section 3.3.11)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.11-1, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.3.12-4`

A PE receiving a Type 2 ST route with a Direct Segment type BGP MUP Extended Community MUST resolve the route using the DSD routes matching that community (Section 3.3.12)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.12-4, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.3.12-5`

DSD routes MUST NOT be used to resolve Type 2 ST routes that do not carry a Direct Segment type BGP MUP Extended Community (Section 3.3.12)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.12-5, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.3.12-6`

A PE receiving a Type 2 ST route with an Interwork Segment type BGP MUP Extended Community MUST resolve the route using ISD routes that carry a matching Interwork Segment type BGP MUP Extended Community (Section 3.3.12)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.12-6, so no unit is bound to it.

`DRAFT-IETF-BESS-MUP-SAFI-3.3.12-7`

A PE receiving a Type 2 ST route without a BGP MUP Extended Community MUST resolve the route using ISD routes for the default Interwork Segment, i.e., ISD routes that carry no BGP MUP Extended Community. (Section 3.3.12)

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

No test carries DRAFT-IETF-BESS-MUP-SAFI-3.3.12-7, so no unit is bound to it.

Extraction sign-off

Field	Value
Reviewer	claude
Signed off	2026-09-29
Register	rfc2119
Source	rfc/drafts/draft-ietf-bess-mup-safi.txt
Source fingerprint	cc8da36f0b20e05b
Record	rfc/extraction/draft-ietf-bess-mup-safi.json
Mapped sentences	46
Declined as scope	20
Relocated to a spec, which Ze OWES	0
Unclassified	0

Sections

Section	Name	Sites	Disposition	Reason
`front`	not stated	0	walked	not stated
`1`	not stated	0	walked	not stated
`1.1`	not stated	0	walked	not stated
`2`	not stated	0	walked	not stated
`3`	not stated	0	walked	not stated
`3.1`	not stated	1	walked	not stated
`3.1.1`	not stated	2	walked	not stated
`3.1.2`	not stated	2	walked	not stated
`3.1.3`	not stated	2	walked	not stated
`3.1.3.1`	not stated	12	walked	not stated
`3.1.4`	not stated	2	walked	not stated
`3.1.4.1`	not stated	9	walked	not stated
`3.1.5`	not stated	1	walked	not stated
`3.1.5.1`	not stated	0	walked	not stated
`3.1.5.2`	not stated	0	walked	not stated
`3.1.5.3`	not stated	0	walked	not stated
`3.2`	not stated	0	walked	not stated
`3.2.1`	not stated	0	walked	not stated
`3.2.2`	not stated	0	walked	not stated
`3.2.3`	not stated	0	walked	not stated
`3.3`	not stated	1	walked	not stated
`3.3.1`	not stated	4	walked	not stated
`3.3.2`	not stated	1	walked	not stated
`3.3.3`	not stated	6	walked	not stated
`3.3.4`	not stated	4	walked	not stated
`3.3.5`	not stated	1	walked	not stated
`3.3.6`	not stated	6	walked	not stated
`3.3.7`	not stated	2	walked	not stated
`3.3.8`	not stated	1	walked	not stated
`3.3.9`	not stated	2	walked	not stated
`3.3.10`	not stated	2	walked	not stated
`3.3.11`	not stated	1	walked	not stated
`3.3.12`	not stated	4	walked	not stated
`4`	not stated	0	walked	not stated
`5`	not stated	0	walked	not stated
`6`	not stated	0	walked	not stated
`7`	not stated	0	walked	not stated
`7.1`	not stated	0	walked	not stated
`7.2`	not stated	0	walked	not stated

Excluded sentences

Site	Excluded kind	Reason	Quote
`3.1.2:2`	`duplicate-of` never bound Ze the same obligation is already captured under another requirement id	The document repeats one sentence after every malformed-NLRI ruling: a BGP speaker MUST skip such NLRIs and continue processing of the rest of the Update message. The checklist carries it once, at Section 3.1.1.	A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message.
`3.1.3:2`	`duplicate-of` never bound Ze the same obligation is already captured under another requirement id	The document repeats one sentence after every malformed-NLRI ruling: a BGP speaker MUST skip such NLRIs and continue processing of the rest of the Update message. The checklist carries it once, at Section 3.1.1.	A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message.
`3.1.3.1:2`	`duplicate-of` never bound Ze the same obligation is already captured under another requirement id	The document repeats one sentence after every malformed-NLRI ruling: a BGP speaker MUST skip such NLRIs and continue processing of the rest of the Update message. The checklist carries it once, at Section 3.1.1.	A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message.
`3.1.3.1:4`	`duplicate-of` never bound Ze the same obligation is already captured under another requirement id	The document repeats one sentence after every malformed-NLRI ruling: a BGP speaker MUST skip such NLRIs and continue processing of the rest of the Update message. The checklist carries it once, at Section 3.1.1.	A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message.
`3.1.3.1:6`	`duplicate-of` never bound Ze the same obligation is already captured under another requirement id	The document repeats one sentence after every malformed-NLRI ruling: a BGP speaker MUST skip such NLRIs and continue processing of the rest of the Update message. The checklist carries it once, at Section 3.1.1.	A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message.
`3.1.3.1:11`	`duplicate-of` never bound Ze the same obligation is already captured under another requirement id	Restates the Treat-as-withdraw consequence of the Type 1 ST architecture encoding rule mapped at site 3.1.3.1:10, which the row already carries as its otherwise clause.	A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" [RFC7606].
`3.1.3.1:12`	`duplicate-of` never bound Ze the same obligation is already captured under another requirement id	The document repeats one sentence after every malformed-NLRI ruling: a BGP speaker MUST skip such NLRIs and continue processing of the rest of the Update message. The checklist carries it once, at Section 3.1.1.	A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message.
`3.1.4:2`	`duplicate-of` never bound Ze the same obligation is already captured under another requirement id	The document repeats one sentence after every malformed-NLRI ruling: a BGP speaker MUST skip such NLRIs and continue processing of the rest of the Update message. The checklist carries it once, at Section 3.1.1.	A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message.
`3.1.4.1:2`	`duplicate-of` never bound Ze the same obligation is already captured under another requirement id	The document repeats one sentence after every malformed-NLRI ruling: a BGP speaker MUST skip such NLRIs and continue processing of the rest of the Update message. The checklist carries it once, at Section 3.1.1.	A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message.
`3.1.4.1:4`	`duplicate-of` never bound Ze the same obligation is already captured under another requirement id	Section 3.1.4.1 repeats the Section 3.1.3.1 TLV length computation word for word; the negative-remainder rule is mapped at site 3.1.3.1:7.	- < 0: the mandatory fields exceed the declared Length; the NLRI is malformed; MUST be treated as Treat-as-withdraw.
`3.1.4.1:5`	`duplicate-of` never bound Ze the same obligation is already captured under another requirement id	Section 3.1.4.1 repeats the Section 3.1.3.1 TLV length computation word for word; the one-octet-remainder rule is mapped at site 3.1.3.1:8.	- 1: encoding is invalid (a valid TLV requires at minimum a Type byte and a Length byte); MUST be treated as Treat-as- withdraw.
`3.1.4.1:6`	`duplicate-of` never bound Ze the same obligation is already captured under another requirement id	Section 3.1.4.1 repeats the Section 3.1.3.1 TLV parsing sentence word for word; it is mapped at site 3.1.3.1:9.	Parse TLVs one by one per Section 3.1.5; unknown TLV types MUST be ignored for local processing and MUST be propagated unchanged when re- advertising the route to other BGP peers; any TLV parsing error MUST result in Treat-as-withdraw; TLVs are not part of the NLRI key for route processing.
`3.1.4.1:8`	`duplicate-of` never bound Ze the same obligation is already captured under another requirement id	Restates the Treat-as-withdraw consequence of the Type 2 ST architecture encoding rule mapped at site 3.1.4.1:7, which the row already carries as its otherwise clause.	A BGP speaker MUST handle such a malformed NLRI as a "Treat-as-withdraw" [RFC7606].
`3.1.4.1:9`	`duplicate-of` never bound Ze the same obligation is already captured under another requirement id	The document repeats one sentence after every malformed-NLRI ruling: a BGP speaker MUST skip such NLRIs and continue processing of the rest of the Update message. The checklist carries it once, at Section 3.1.1.	A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message.
`3.3:1`	`binds-another-role` never bound Ze the obligation is addressed to a role Ze never acts as Presumed wrong until justified: Ze rarely implements one side of a protocol, so the reason beside this row must name the role, show Ze never acts as it, and cite the producer that would.	the sentence addresses BGP speakers acting as a MUP PE and the MUP Controller (Section 3.3); ze fills neither role. The role has no producer in this tree: the nlri/mup plugin registers the ipv4/mup and ipv6/mup codecs and RecognizeNLRI, and no ze function originates, resolves or controls MUP state as a PE or a controller. Row DRAFT-IETF-BESS-MUP-SAFI-3.3-1 retired 2026-09-29 (rfc/corrections/draft-ietf-bess-mup-safi.md); its generic capability negotiation tags moved to RFC4760-8-2.	BGP speakers acting as a PE, and a MUP Controller MUST establish a BGP session to exchange BGP-MUP NLRIs for both, IPv4 and IPv6 AFIs.
`3.3.3:3`	`duplicate-of` never bound Ze the same obligation is already captured under another requirement id	The document repeats one sentence after every malformed-NLRI ruling: a BGP speaker MUST skip such NLRIs and continue processing of the rest of the Update message. The checklist carries it once, at Section 3.1.1.	A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message.
`3.3.3:5`	`duplicate-of` never bound Ze the same obligation is already captured under another requirement id	The document repeats one sentence after every malformed-NLRI ruling: a BGP speaker MUST skip such NLRIs and continue processing of the rest of the Update message. The checklist carries it once, at Section 3.1.1.	A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message.
`3.3.6:3`	`duplicate-of` never bound Ze the same obligation is already captured under another requirement id	The document repeats one sentence after every malformed-NLRI ruling: a BGP speaker MUST skip such NLRIs and continue processing of the rest of the Update message. The checklist carries it once, at Section 3.1.1.	A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message.
`3.3.6:5`	`duplicate-of` never bound Ze the same obligation is already captured under another requirement id	The document repeats one sentence after every malformed-NLRI ruling: a BGP speaker MUST skip such NLRIs and continue processing of the rest of the Update message. The checklist carries it once, at Section 3.1.1.	A BGP speaker MUST skip such NLRIs and continue processing of rest of the Update message.
`3.3.7:2`	`binds-another-role` never bound Ze the obligation is addressed to a role Ze never acts as Presumed wrong until justified: Ze rarely implements one side of a protocol, so the reason beside this row must name the role, show Ze never acts as it, and cite the producer that would.	the sentence addresses the MUP Controller that originates the Type 1 ST route (Section 3.3.7); ze fills no MUP Controller role. The role has no producer in this tree: EncodeRoute encodes the route the operator's command names, and no ze function derives Type 1 ST routes from session state or selects the speakers of an SRv6 domain. Row DRAFT-IETF-BESS-MUP-SAFI-3.3.7-2 retired 2026-09-29 (rfc/corrections/draft-ietf-bess-mup-safi.md); its tags were dropped.	The controller MUST announce this route using a AFI of the route and the SAFI of BGP-MUP to all other BGP speakers within the SRv6 domain.

Superseded

No document obsoletes DRAFT-IETF-BESS-MUP-SAFI, so its obligations are stated where they were written.