Summary

  • In L1VPN Basic Mode, a customer can request which permitted CEs should be connected, but the provider retains control of the PE-to-PE path, resources, admission policy and internal topology.
  • The provider can hide its core while necessarily learning at least the customer's CE addresses and locations; service-contract identification, signaling authentication, established optical state and delivered payload remain separate receipts.

A request entered with two endpoints and no right to the road

The customer message could say where the connection should begin and end. It could select a customer-facing traffic-engineering link, or leave the egress-side choice to the provider. It could ask for setup, modification or deletion. What it could not do was enter the provider's network with a route of its own choosing.

RFC 5253 is unusually clear about that line. The provider network is completely under provider control. The customer controls the topology of its L1VPN in the bounded sense that it can request connections among customer edges. The PE-to-PE segment is computed and controlled by the provider. If a CE sends an Explicit Route Object that tries to prescribe the route inside the provider network, the ingress PE rejects it.

Both controls are real. Neither is a polite fiction. Yet they act on different surfaces. The customer's power is intent over eligible endpoints. The provider's power is execution over internal paths, resources and policy. A dashboard that labels both simply as “customer-controlled VPN” erases the most consequential fact in the service contract.

Basic Mode removes route exchange, not dependence

Basic Mode has no routing exchange between CE and PE. The customer therefore does not learn the provider's internal routing view through the service. Remote Customer Port Indices must arrive through configuration, a directory or another L1VPN-specific process. Provider edges may still exchange membership information among themselves, and routing still operates inside the provider domain.

This makes the boundary easier to see. The customer supplies a target CPI or target CE and a service request. The provider resolves that request through its Port Information Table, local policy and internal path computation. It may compute a path on demand, use a pre-computed path, or map the request to a segment that was already established. The computation may occur on the PE, in a Path Computation Element or in a management system.

None of those choices is visible merely because the request succeeds. The customer receives a service outcome, not a copy of the provider's decision graph. The provider receives a request, not authority to reinterpret every customer objective. The interface is valuable precisely because it lets those two systems cooperate without merging their control planes.

The dependence remains. The customer's topology exists only within the provider's eligible port set, resource policy and admission rules. The provider's revenue and operational load depend on customer requests. Separation of routing knowledge limits exposure; it does not make the parties independent.

The provider sells a possibility set, not a particular path

RFC 5253 allows policy per L1VPN and per connection. Those policies may reflect the customer contract. The provider can partition resources, pre-compute several segments between the same provider edges and decide which VPN or connection may use which segment. A Path Key ID can let a customer request a provider-supplied confidential segment without revealing the route behind the identifier.

This is a powerful commercial abstraction. The customer can buy a set of permitted outcomes—connect A to B with stated attributes—while the provider retains the flexibility to engineer its core. But the abstraction changes what can be proved.

A successful RSVP-TE exchange does not show which policy revision admitted the request. A segment identifier does not disclose the physical or logical route it names. A pre-established segment does not prove that its reserved resources were still present when the customer's traffic arrived. A protected service flag does not prove that a failover occurred within the promised time. An invoice line does not reconstruct any of those states.

The operational receipt must therefore cross the abstraction boundary without destroying it. The provider need not reveal every internal node to prove performance. It does need a durable internal record that connects customer request, policy decision, selected segment, reservation, cross-connect state and measured result. The customer needs an external receipt that is specific enough to test the purchased outcome without demanding the provider's full topology.

Confidentiality runs in two different directions

Basic Mode can keep provider topology away from the customer. There is no PE-to-CE routing distribution. Record Route information can be filtered. A provider edge can replace an internal address in a Notify message with its own address. A confidential pre-computed segment can be represented by a path key.

The reverse is not symmetric. RFC 5253 says the provider will know at least the addresses and locations of the customer edges. Other customer topology can remain hidden, but the provider must know enough to bind ports to a VPN, enforce connectivity restrictions and establish the service.

That asymmetry is not necessarily abuse. It is part of the architecture. It does, however, allocate information power. The party that knows its own core plus the customer's attachment points can infer concentration, failover geography and sometimes business-critical locations. The customer may know only that an accepted request produced a connection.

The right governance response is not to demand total symmetry. A provider cannot operate an optical service while remaining ignorant of where its ports terminate. The response is purpose limitation, access control, retention limits and auditable use. Customer-edge location should be treated as service data with a named operational purpose, not as a free by-product available to every internal system.

Likewise, the provider's ability to hide its core should not become permission to make every assurance untestable. Confidential topology and verifiable service can coexist. Disclose the outcome and the evidence class, not necessarily every hop.

A contract can name a CE without authenticating a message

The security section separates two ideas that procurement systems often collapse. A new CE is identified when it is added under the service contract and its control channel is established. The signaling entity is not thereby authenticated on every exchange. RSVP-TE authentication procedures must actually be used for that result.

This distinction matters because a database row and a live peer answer different questions. The contract says which legal or operational party should be connected. The configuration says which address or channel represents it. Authentication says what credential protected a particular signaling exchange. Integrity says whether the message was altered. Policy says whether the authenticated request was allowed.

One green “trusted customer” status cannot faithfully represent all five. A stale credential can authenticate a party whose service authority was revoked. A correct contract can coexist with an unauthenticated control channel. An authenticated request can still ask for a forbidden peer. A permitted request can still be misconnected in the data plane.

RFC 5253 also resists the idea that physical separation ends the analysis. A per-customer control channel may be considered secure, but customers may still want IPsec or another security mechanism, and such mechanisms must be available. Shared channels require security mechanisms to be available and enforced. The word “private” describes an arrangement; it is not a packet-level proof.

Rejection location is an economic decision

Connectivity policy can be applied at ingress or egress. Both locations can prevent the final forbidden connection. They do not have the same cost.

An ingress decision stops the request before it consumes signaling work across the provider network. An egress decision can reject with equal policy correctness after intermediate systems have already parsed, forwarded and held state for an attempt that never had permission to finish. RFC 5253 explicitly notes that egress enforcement may waste signaling effort.

This is a small sentence with a broad operational lesson. A negative outcome does not prove that the control was efficient. Security dashboards often count blocked attempts and call the control successful. Leadership also needs to know how far each denied request traveled, what temporary state it created, whether it competed with legitimate work and how quickly that state disappeared.

The location of enforcement determines who pays for bad input. Move a known, stable eligibility decision toward ingress. Preserve egress checks as defense in depth, not as an excuse to let every impossible request traverse the core.

Protection language has scope limits

Basic Mode can use GMPLS recovery tools for the PE-to-PE segment, for links, and for control-channel failures. The catalogue sounds broad until the combinations are examined. One link-protection request applies across the links used by the LSP; it cannot independently protect only the CE-to-PE part or only the PE-to-PE part. The architecture cannot simultaneously ask for link recovery on the edge portion and segment recovery on the core portion through that model. Dual-homed CE-to-CE recovery is outside Basic Mode.

Those limits are not flaws hidden in fine print. They are the service boundary. A customer who buys “protected L1VPN” needs the protection scope expressed in the same units as the failure it cares about: edge link, provider segment, device, site, shared-risk group or full dual-homed service. A flag that means one supported combination must not be marketed as universal resilience.

The same discipline applies after a recovery event. A request for protection is not proof that backup resources were disjoint. A successful control-plane transition is not proof that the optical cross-connect switched. A restored lightpath is not proof that the application session recovered. Each is a separate clock and a separate receipt.

Layer 1 isolation does not eliminate misdelivery

Optical connections are difficult to intercept compared with shared packet media, and a connection dedicated to one L1VPN creates useful isolation. RFC 5253 still names misconnection as a security vulnerability. The wrong cross-connect can deliver the customer's data to the wrong destination while every higher-level belief about dedicated capacity remains intact.

Membership policy reduces that risk by restricting each connection to CEs within the same L1VPN. It does not observe the final photons. Customers with sensitive payloads are told to apply protection in their own layer, such as IPsec for IP traffic. This is not a rejection of Layer 1 security. It is a recognition that the provider controls the path while the customer owns the meaning of the payload.

The strongest evidence stack therefore combines both views. The provider reads back its cross-connects and resource state. The customer probes the remote endpoint and verifies the cryptographic peer or application result. Neither party should certify the other's domain from a control-plane acknowledgment alone.

A useful receipt preserves the split

For each request, record the customer-visible intent and provider-internal execution as linked but distinct records:

  1. service-contract revision and eligible CE set;
  2. authenticated control-channel peer and credential state;
  3. requested source, destination, attributes and selected customer-facing link;
  4. ingress eligibility and connectivity-policy decision;
  5. chosen PE-to-PE segment and path-computation revision;
  6. reservation and admission result;
  7. cross-connect readback at both boundaries;
  8. declared protection scope and tested recovery result;
  9. topology information disclosed, filtered or substituted;
  10. customer-side payload protection and observed delivery.

The record should allow the customer to challenge an outcome without requiring the provider to publish its core. It should allow the provider to prove that a customer's request never gained route authority. And it should preserve uncertainty: if only signaling succeeded, the status is signaling succeeded—not “service delivered.”

RFC 5253 did not dissolve control into one shared plane. It drew a deliberate seam. Leadership earns trust by making that seam inspectable, assigning an owner on both sides and refusing to let either endpoint choice or provider secrecy masquerade as end-to-end proof.

Sources