Summary

  • draft-ietf-lisp-site-external-connectivity-05 lets a LISP mapping system return a non-zero proxy-ETR locator set when the destination is external, unknown, or known but not registered. The reply chooses an exit; it does not discover the destination.
  • Registration, priority, weight, optional vendor metadata, Map-Notify and cache installation are separate control records. None proves that the pETR currently has usable external reachability, that the native path beyond it works, or that the application completed.
  • Operators should preserve the original query, classification, policy version, candidate and selected pETRs, metadata provenance, cache readback, encapsulation and decapsulation evidence, native next hop and application outcome. Otherwise a broad default can move traffic and accountability without leaving an explainable decision trail.

The destination was not in the map.

That sentence normally sounds like a reason to stop. In the experimental proposal LISP Site External Connectivity, it can instead trigger a positive forwarding decision. A Map-Server may classify the address as external, unknown, or known but unregistered, calculate the non-LISP “hole” that covers it, and return a non-empty set of proxy-ETR locators. The ingress tunnel router can cache that answer and encapsulate the packet toward one of those exits.

The mechanism addresses a real operating problem. An enterprise, VPN or AI backend may have several gateways capable of reaching destinations outside its LISP mapping domain. Configuring every ingress router by hand makes gateway changes slow and inconsistent. Registering those pETRs in the mapping system can centralize selection, publish updates and shorten convergence after an exit changes.

But the resulting reply is easy to overread. It resembles ordinary mapping data and can carry priority, weight, location, resource availability and performance claims. The packet then moves. A dashboard may call the destination “resolved”. In reality, only the next administrative decision has been resolved.

The hole remains a hole

RFC 9301 defines the LISP control plane. A normal positive Map-Reply associates an endpoint-identifier prefix with a locator set. A Negative Map-Reply contains no locators and tells the ingress router how to handle a missing registration—for example, to forward natively, drop, or ask again according to the defined action and lifetime.

Revision 05 uses those negative-resolution procedures to calculate a non-LISP hole, then changes the actionable result: the RLOC count must be non-zero and the locators identify pETRs. The mapping system has not converted the unknown destination into a registered endpoint. It has found a gateway policy that covers the class of traffic containing it.

That is a legitimate abstraction, similar in spirit to a default route. It becomes dangerous only when its name is promoted beyond its evidence. The proper statement is “for this IID and policy epoch, the mapping system selected this pETR set for traffic whose destination lacks a more specific LISP mapping.” It is not “the mapping system knows where the destination is.”

The difference matters during failure. If packets disappear after the pETR, the map may be working exactly as specified. The fault could be the pETR's native route, an upstream filter, a remote access policy, a stale external prefix, congestion, or a service that is not listening. Re-running the same successful map lookup will not distinguish them.

Five records, not one “resolved” state

The proposal creates at least five distinct records:

Record What it can establish What it cannot establish
pETR registration A principal supplied a locator set for an IID and distinguished coordination name Current external reachability or authority over every destination
Mapping decision The server selected candidates under one policy and metadata view Correct metadata, fair selection or a working data path
Map-cache state The ITR intended to use a hole/default entry and pETR set That hardware forwarding uses it or every packet matches it
pETR processing Encapsulated traffic reached and was decapsulated by the gateway Native delivery to the final destination
Application receipt A named service accepted or completed a request Why the mapping system selected that gateway

Collapsing the rows destroys useful blame boundaries. Authentication can protect the registration or notification. It cannot certify the external Internet. A successful decapsulation counter can prove work at the pETR. It cannot report what an upstream autonomous system did. A completed application request can prove an outcome. It does not validate the mapping policy for other traffic.

This is the practical meaning of Lu Heng's Reality Layers: a symbol, an authorized state change, a running packet path and a user outcome occupy different layers. The purpose of an evidence system is not to make them look uniform. It is to preserve the joins between them without pretending they are the same fact.

Registration is a claim of eligibility

The draft says pETRs with external or Internet connectivity may register per VPN Instance ID. The record uses existing Map-Register procedures, a configurable Distinguished Name in the EID-Prefix position, and the gateway RLOC set. Locator encoding may retain VPN context.

That registration is valuable. It creates a discoverable pool and gives the mapping system something more precise than a static default. Still, “having external connectivity” is a precondition asserted by the registering side and admitted by deployment policy. Revision 05 does not define an independent end-to-end test that proves the condition at decision time.

The control surface therefore needs an authorization contract. Which principal may register an exit for this IID? Which distinguished names may it use? Must it prove control of each RLOC? How fresh must its reachability evidence be? Can a gateway advertise itself for all unknown destinations, or only a constrained class? What removes it after external routing fails?

An authenticated registration from the wrong role remains wrong. A correctly signed locator belonging to another tenant remains dangerous. The audit record should preserve registrar identity, credential and admission-policy version separately from the locator data itself.

Performance metadata is not performance

Both registration and request may carry vendor-specific LCAF data. The examples include location, resource availability, performance information and requirements. The mapping system may use those fields to prefer one gateway.

This is deliberately extensible, but the extension moves important semantics outside the common draft. RFC 9306 allocates a vendor-specific LCAF format and makes vendors responsible for assessing the security implications of what they define. It does not create a shared measurement method, clock, unit, confidence model or validation authority.

A value labelled “available” may come from configuration, a local counter, a controller estimate or an old observation. A location may mean chassis position, service region, jurisdiction or a marketing label. A performance score may combine latency, loss and capacity in an unpublished formula. Two gateways can truthfully emit incomparable values.

So the mapping system should retain the schema identifier, producer, collection time, units, method, validity interval and confidence—not merely the normalized score. If those fields are absent, the safe interpretation is a policy hint. It can influence a reversible choice; it should not support a claim that one path was objectively best.

Priority and weight distribute authority

RFC 9300 gives each unicast locator a priority and weight. Lower priority is preferred. Locators at the same best priority can share traffic according to relative weights.

Those fields do useful work, but they answer a narrow question: how should an ingress choose among the locators the mapping system returned? They do not say why a priority is justified, whether a weight reflects capacity, or whether the external paths remain disjoint. Two pETR addresses may converge on one router, one provider or one power domain.

Treat every change as a policy change with an owner. Preserve the candidate set before filtering, selected set, priority, weight, metadata view, tie-break, policy version and effective time. Then compare the intended distribution with per-pETR encapsulation, decapsulation and native-forward counters. A configured 70/30 split is not evidence of a 70/30 outcome.

Publication acknowledges control traffic, not packet fate

RFC 9437 allows subscribers to receive mapping changes through Map-Notify. It defines nonces, security associations, authentication and Map-Notify-Ack. Revision 05 reuses that machinery so pETR changes can reach ITRs without waiting for ordinary cache expiry. Where publish/subscribe is unavailable, it suggests shorter TTLs.

These are convergence tools. Their receipts need careful names. A Map-Notify-Ack acknowledges a control message. It does not prove that the intended entry was programmed into every forwarding structure, that already queued traffic moved, or that the pETR served the next packet. A shorter TTL bounds permissible cache age; it does not guarantee a successful refresh.

The correct automation chain is explicit: authenticated update received; syntax and scope accepted; candidate state built; write attempted; readback matches; data-plane canary reaches the pETR; external canary reaches the target class; application canary succeeds. Each stage may fail while the previous one remains true.

The default entry is the largest blast radius

Revision 05 allows an ITR to install either a hole prefix or a default map-cache entry. It also recommends that known EID blocks remain more-specific entries that always generate Map-Requests. That exception is not a detail. It prevents a broad external rule from swallowing destinations that deserve ordinary endpoint resolution.

The default entry is operationally attractive because it removes configuration. It also concentrates risk. A single registration or preference change can move traffic for many unrelated destinations. The change can alter observation, cost, jurisdiction, policy enforcement and exposure to compromise even when every application continues to see the same destination address.

Rollout should therefore begin with narrow IIDs and destination classes, explicit more-specific protections, canary ingress routers and bounded TTLs. Rollback should remove or demote only the affected pETR mapping. Flushing unrelated map-caches turns a local selection error into a wider outage.

What leaders should ask before calling it dynamic routing

The Datatracker record identifies revision 05 as Experimental work in progress, submitted on 30 September 2026. The document does not demonstrate implementation, interoperability, field adoption or measured convergence. Its AI-infrastructure example is a use case, not evidence that a named backend uses the mechanism.

That limitation does not weaken the idea. It clarifies the next work. An implementation test should withdraw one pETR, delay a Map-Notify, inject stale metadata, change equal-priority weights, shadow a known EID with a broad hole, lose acknowledgements and break native forwarding beyond an otherwise healthy gateway. The results should show which receipt fails first and how quickly traffic returns to a proven path.

Lu Heng's Minimum Initial Specification offers the right governance posture: standardize the small interoperable coordination object, keep later choices local and visible, and do not let the specification acquire authority over facts it cannot observe.

The draft can make external exit selection dynamic. It should not make destination ignorance invisible. The mapping system may truthfully say, “I do not know this endpoint, but under this policy I know which gateway should try.” That is enough—provided the system records the try and waits for the data path to report what happened.

Sources