Summary

  • In a 27 October IETF draft's worked example, four VPN routes advertise the same prefix. PE1 selects the one from RD22 into VPN11, then exports a BMP Loc-RIB record that identifies VPN11 while losing RD22. The monitor can see where the route landed without seeing which source instance supplied it.
  • A proposed Remote VRF Information field restores that source label, including for an EVPN Type-5 route in revision 02. Both sending and reading the field remain optional. The operator must decide whether route provenance is essential to its own cross-instance controls.

Four claimants for one prefix

Four routes bearing prefix P1 arrive at PE1 in the 27 October draft. Three come from different VPN instances on PE2, marked RD21, RD22 and RD23. A fourth comes from RD31 on PE3. Each carries the route target that lets PE1's VPN11 consider it. PE1 chooses one; the draft picks RD22 for the example. A BMP monitoring server then receives the local selected route in VPN11. The record says P1, a next hop, and RD11, the receiving instance. It does not say RD22.

That omission is more interesting than a missing decorative label. The monitoring server can report a selected route in VPN11 and still be unable to identify the remote VPN instance that supplied it. A route admitted from RD21 and a route admitted from RD22 can produce the same narrow answer to the question “What is in VPN11?” The answer to “Where did this one come from?” lives across a boundary the exported record did not carry.

This is the draft's constructed network, not a reported leak at an operator. The draft, listed by the IETF Datatracker as an individual Internet-Draft, proposes to repair an information gap in an existing monitoring format. Its argument reaches a governance question before it reaches any deployment statistic: who decides that a monitoring system may call a cross-instance route accounted for when it can name only the destination instance?

The receipt for arrival is not the route's family tree

RFC 9069 lets a BGP Monitoring Protocol speaker expose its Loc-RIB, the routes selected by the local BGP decision process. That is a useful view. An operator need not reconstruct every selection from every inbound candidate merely to see the selected table. But the Loc-RIB BMP peer header identifies the local instance: for VPN route information, the peer address is zero-filled, while the peer distinguisher uses that instance's route distinguisher or locally defined identifier. In the draft's PE1 example the export points at RD11. The selected source RD22 falls out of this view.

PE1 had the candidates in its own control plane. The gap concerns what the BMP server receives. This matters when a monitoring team, rather than the router itself, must explain why a route crossed a policy boundary. A route target may make import possible; a configured policy decides whether it should be possible here; the monitoring record ought to let an investigator find the specific source instance whose route was selected. A dashboard that only counts an arrival can turn a cross-instance decision into an anonymous fact of presence.

The draft proposes a Remote VRF Information TLV: an address-family pair, a remote BGP identifier and the remote route distinguisher. In its example, a record about P1 in VPN11 can carry RD22 alongside RD11. These identifiers do different jobs. RD11 names the table now holding P1; RD22 names the instance from which the selected remote VPN route came. The proposed VPN Label and VPN SRv6 SID TLVs can additionally carry the remote route's forwarding label or segment identifier when needed. They are optional companions, not substitutes for the source instance.

The separation is precise enough to expose a common reporting habit. If an audit asks “Which VPN had P1?” the RD11 answer may suffice. If it asks “Which VPN fed P1 across the boundary?” RD11 is the wrong name. Presenting one as the other would make an apparently complete report from incomplete provenance. That is a control failure in the reporting chain even when the route itself was selected exactly as configured.

The amendment reaches EVPN, too

Revision 02 adds an EVPN Type-5 case absent from revision 01. A route for P1 begins in EVI21 on PE2 and is imported into EVI11 on PE1 through integrated routing and bridging. With the proposed field, the Loc-RIB report can carry EVPN AFI 25 / SAFI 70, the remote BGP identifier and RD21. Without it, the server sees P1 in EVI11 with PE2 as next hop, yet cannot name EVI21 as the remote source instance. The change is modest in wire format and large in what a human can ask of the record.

The draft also points to a separate EVPN BMP statistics proposal. Per-EVI counters may reveal how many routes were leaked into an EVI. A count cannot tell the investigator which remote EVI supplied this selected P1. A high number could focus attention; the identity field is what lets the inquiry cross from a population to one route's source. Counts and provenance can work together, but they answer different questions.

None of this field design claims that a route reached a forwarding table, a packet crossed the network, or a customer service changed. The BMP Loc-RIB is a control-plane observation. The monitoring record can improve attribution for a selected route; forwarding and effect need their own observations. Inflating a source label into a delivery verdict would simply move the ambiguity one layer downstream.

The optional field and the optional reader

The proposal contains a second hinge. A BMP speaker supporting the extension may attach the Remote VRF Information TLV. A collector may ignore it without losing compatibility with ordinary RFC 9069 processing. The information type remains TBD1 in the draft's IANA section; the optional label and SID types are also unassigned there. Publication of a draft does not make a router send the field, a collector retain it, or an operator put it in an alert.

That leaves a clear procurement and operating decision. If cross-VRF or cross-EVI import is part of the system's risk surface, the operator can require the source field on relevant BMP exports, verify collector support, retain the identity with the route and test what happens when it is absent. A collector that silently drops a source TLV may still display a healthy Loc-RIB table. Its green status says the monitoring channel is alive; it says little about the provenance question the team needed answered.

The draft's security section repeats the need for authorized, trusted monitoring devices. That protects a BMP session boundary. It does not by itself define which monitoring consumers must keep the remote RD, how long they retain it, or which policy team can treat its absence as acceptable. Those are local decisions with operational owners, not bits that appear automatically when a standards document is filed.

Sources