Summary

  • RFC 9736 gives BMP Peer Up information a distinct type-code registry and preserves the order of repeated String TLVs. It resolves extension ownership; it does not certify deployed sender or collector behaviour.
  • An operational claim needs a receipt chain from registry and sender version through serialized bytes, parser decisions and stored records to peer, route, forwarding and service evidence.

A standards defect with a clean repair

BMP uses different message types to report different parts of a router's control-plane state. RFC 7854 defined Initiation metadata for the monitored system and Peer Up information for an individual BGP session, yet both borrowed one Information TLV namespace. Later extensions exposed the cost. A type number could not evolve cleanly when its meaning depended on which message carried it.

RFC 9736 fixes that ownership problem. The old shared registry becomes BMP Initiation Information TLVs; a new BMP Peer Up Message TLVs registry receives the Peer Up assignments. In the Initiation registry, String remains Type 0, sysDescr Type 1 and sysName Type 2. In the Peer Up registry, String is Type 0, VRF/Table Name is Type 3 and Admin Label is Type 4. Types 1 and 2 are reserved on the Peer Up side, while 3 and 4 are reserved for Initiation. The separation creates room for future extensions without pretending that the two message contexts are interchangeable.

The RFC also removes small but consequential parsing ambiguities. A String TLV is UTF-8 whose byte length comes from the Length field; it is not null-terminated. Peer Up Information is optional, and the common-header Message Length reveals whether the field is present. String may repeat, and a receiver that reports multiple values must preserve their order.

Those are precise wire and registry rules. They are not a deployment report.

The compliant-on-paper trap

RFC 9736 says implementations compliant with RFCs 7854, 8671 and 9069 also comply with this specification. That statement protects the specifications' compatibility: the newly separated registry formalises meanings already assigned for Peer Up. It does not identify a product version, prove which parser table a collector loaded, or show whether a storage pipeline kept repeated strings in order.

Consider a collector that recognises Type 0 but stores only the last occurrence. Its dashboard may look tidy while losing administrative context carried by earlier strings. Another collector may label Type 3 correctly but attach it to the wrong emulated Loc-RIB peer because it failed to correlate the peer distinguisher, BGP identifier and OPEN capabilities. A third may silently discard an unknown future TLV. None of those failures is visible in the IANA registry itself.

The strongest receipt begins before decoding. Preserve the exact Peer Up bytes, BMP session identity, sender version and configuration. Record the common-header length and the ordered TLV sequence. Bind that capture to a collector build, parser schema and explicit policy for unknown or reserved types. Then compare the raw-ingest receipt with the decoded and persisted record. A normalized database row without the source bytes cannot prove that an omitted value was absent on the wire.

Peer Up is one checkpoint, not the route

RFC 7854 defines Peer Up as a report that a monitored BGP session entered Established. It carries the sent and received OPEN messages and TCP-session details. The same message is also emitted for already-established peers when a BMP session starts. That distinction matters: the arrival of Peer Up at a collector is not necessarily the moment the BGP session first became healthy.

Nor does Peer Up establish route-feed coverage. RFC 8671 states that Peer Up and Peer Down session state is independent of whether route monitoring or mirroring will be sent for Adj-RIB-In, Adj-RIB-Out or both. RFC 7854 separately sequences Initiation, Peer Up, the initial RIB dump, End-of-RIB and later incremental updates. A collector therefore needs continuity and completion evidence for the particular feed it claims to observe.

For Loc-RIB, RFC 9069 adds another identity challenge. Implementations use emulated peers, potentially more than one per table for different address families. VRF/Table Name is useful metadata, but a familiar label such as global is not globally unique. Correct attribution also depends on the per-peer header and OPEN capabilities.

The operating receipt chain

A defensible incident or assurance record should answer eleven questions in order. Which registry snapshot governed the message? Which sender build emitted it? Which BMP session and peer epoch carried it? What exact bytes arrived? Which collector build parsed them? What did it do with unknown fields? What raw and decoded records were persisted? Which BGP session facts corroborate the peer? Which route stream was complete for the claim? What RIB, FIB or active observation supports the network conclusion? What authorised action occurred, and what independent evidence shows its outcome?

The chain can stop honestly. A valid Peer Up can prove a reported session transition while leaving route acceptance unknown. A complete route feed can still leave hardware forwarding unknown. A forwarding observation can still leave business effect uncertain. RFC 9736 improves the first links by making schema ownership explicit. Operational credibility comes from refusing to let that improvement impersonate the links that follow.