Summary

  • RFC 5195 distributes PE membership and customer/provider port mappings so later signaling can complete a Layer-1 VPN connection. The advertisement is a discovery input, not evidence that the connection, resource reservation or data path exists.
  • Authentication can establish the identity of an immediate BGP peer while leaving the authority behind a particular relayed mapping unresolved. A defensible service record must separate receipt, import, PIT installation, origin authority, signaling, cross-connect and forwarding.

A useful table with a dangerous promotion

RFC 5195 solves a real provisioning problem. A provider edge should not need every remote customer port configured by hand. It can advertise its own address and local private/provider address tuples; other PEs can learn which members they share and use those mappings for address resolution during signaling. The result is the Port Information Table, or PIT.

The table contains <CPI,PPI> pairs. A Customer Port Identifier is unique inside the L1VPN. A Provider Port Identifier is unique inside the provider network. Some entries are local, learned from attached CE ports or local configuration. Others are remote, learned through BGP auto-discovery. That provenance distinction matters because the row does not become more authoritative merely by entering the same table.

The first error is temporal. RFC 5195 says the information is necessary for completing the signaling phase. Necessary is not completed. A PIT row can exist before a signaling request, before admission control, before resource reservation, before a device cross-connect, and before any continuity test. Reporting discovered as connected removes all of those missing acts.

The peer is not the principal

The second error is about authority. RFC 5195 is unusually direct: a PE must not be discovered as attached to an L1VPN unless it really is attached and properly authorized. Otherwise an arbitrary node could add a site to a VPN.

For a directly peered remote PE, the RFC recommends the BGP authentication procedure then specified by RFC 2385. Modern deployments may use other protection, including the TCP Authentication Option in RFC 5925. The conceptual limit remains. Session authentication answers who controls the adjacent session. It does not answer whether that actor was entitled to originate every CPI/PPI mapping carried over it.

The gap widens when the origin is not the neighbor. RFC 5195 permits advertisements to arrive through intermediate BGP speakers. The local PE must then trust that each peer accepted information only from another trusted peer. Trust becomes transitive. The RFC states that BGP provides no way to determine that a particular received item originated with a speaker authorized to advertise that particular item.

That is not a defect that a green session badge can cure. It is the stated deployment boundary. The mechanism belongs only where adequate trust relationships exist, with a single-provider network offered as an example. Even there, “same provider” is a trust perimeter, not evidence that the entitlement database, Route Target, attachment and device state agree.

Route Targets prove selection, not entitlement

RFC 5195 uses Route Target extended communities to control distribution. Export Route Targets tag local information. Import Route Targets decide which advertisements may enter a PIT. This is an efficient scoping mechanism. It can also lend policy configuration an authority it does not possess.

A matching Route Target proves that a local rule selected the route. It does not prove that the rule names the right customer, that the origin had authority over the port, or that the physical attachment still exists. A mistaken import target can make a wrong membership claim look mechanically perfect.

The same distinction appears during change. A PE without a matching import target must discard the L1VPN information. If an operator later adds the target in a VPN Join, the PE must reacquire what it previously discarded; RFC 5195 requires Route Refresh for that case. The configuration change, refresh exchange, received route set and rebuilt PIT are four events. A successful commit proves only the first.

VPN Prune runs in the other direction. Removing the last relevant import target permits routes to be discarded. The BGP connection need not reset. That is operationally valuable, but session continuity tells an auditor nothing about whether every stale tuple disappeared from the PIT and its downstream inventories.

A bandwidth number is not a reservation

Auto-discovery may also carry traffic-engineering information such as switching capability and maximum LSP bandwidth. RFC 5195 describes this as an input to egress selection. A controller can use it to choose where to attempt a connection.

The number has three separate limitations. It was asserted by a remote system. It describes a maximum, not necessarily current free capacity. And it does not record that any capacity was reserved for this request. Converting it into available, then into reserved, performs two silent promotions. The remedy is not to reject TE advertisements; it is to retain their source and observation time beside later measurement, admission and reservation receipts.

Partition is a feature and an evidence boundary

The distribution system deliberately avoids requiring one component to hold every L1VPN route. Route reflectors can be partitioned among VPNs, and RFC 5195 notes that any number of independent BGP systems may carry VPN information. That is an important scalability property.

It also means no local view should be advertised as universal without evidence of its scope. Two partitions can each be internally coherent and still expose different membership sets. A completeness claim needs a declared universe, expected producers, policy version, refresh state and reconciliation point. Counting the rows visible to one reflector proves only what that partition carried.

The minimum L1VPN receipt

A useful receipt can remain smaller than a full telemetry archive. For every mapping, retain the VPN, CPI and PPI; whether the tuple is local or remote; the immediate peer and observed origin; the Route Targets; the import decision; and the authority record binding the originating PE and port to the VPN. Record receipt and PIT-install time separately.

Then begin a new chain. Record the signaling request and response, resource admission, reservation identifier, device cross-connect state, path-continuity result and forwarding test. Join and Prune need their policy change, Route Refresh and reconciliation events. Withdrawals need downstream acknowledgement so a control-plane removal cannot leave an authoritative-looking cache.

This schema is an operational inference, not RFC 5195 wire syntax. Its purpose is to prevent one subsystem from speaking for another. BGP witnesses advertisement transport. Import policy witnesses selection. The PIT witnesses a projection. Signaling witnesses a request. The optical device witnesses the cross-connect. A data-plane test witnesses passage.

Heng Lu's reality-layer discipline supplies the governing rule. Symbols remain useful while they stay subordinate to the running system they summarize. Discovered should make provisioning possible, not make connection reality by decree. The minimum specification is a portable receipt chain; providers can innovate around it without surrendering the ability to prove who claimed what, under whose authority, and what the network actually did.

Sources

  1. RFC 5195 HTML
  2. RFC 5195 text
  3. RFC 5195 information page
  4. IETF Datatracker: RFC 5195
  5. RFC 5195 history
  6. RFC 5195 references
  7. RFC 5195 errata
  8. RFC 4847
  9. RFC 5251
  10. RFC 4760
  11. RFC 4360
  12. RFC 4684
  13. RFC 2918
  14. RFC 5291
  15. RFC 2385
  16. RFC 4271
  17. RFC 5925
  18. Heng Lu — reality layers and symbolic power
  19. Heng Lu — minimum initial specification
  20. Heng Lu — running-code primacy