Summary

  • RFC 5283 lets an LSR accept and re-advertise a specific LDP FEC when its IP RIB contains only a covering aggregate and the advertising neighbor is the next hop. The label remains specific; the route that justifies its next hop can be broad.
  • A label mapping therefore proves a local control-plane relation, not current egress life or delivered service. End-to-end capability, RIB-to-FEC rebinding, ordered withdrawal, LFIB installation and observed packets each require their own receipt.

The missing /32 was the design, not the fault

Classic LDP processing expected a Prefix FEC to match an IP routing entry exactly before the received label was used for forwarding. That rule is safe and simple, but it forces a multi-area provider to leak every PE loopback into every area if it wants a contiguous LSP to each PE.

The cost appears in the wrong tables. Area boundaries are meant to contain link-state and route detail. Leaking all the specific loopbacks expands the LSDB, RIB and FIB across routers that do not need individual IP routes. The label service gains reachability by surrendering part of the scaling benefit that areas were introduced to provide.

RFC 5283 changes the lookup rather than the identity. If an LSR receives a Label Mapping for a specific FEC, its RIB may satisfy the check with the longest matching route. A /32 FEC can therefore use a /24 that contains it, provided the label-advertising neighbor is also the next hop selected by that route.

The /32 does not turn into /24. LDP re-advertises the original specific FEC to its peers. Only the IP evidence used to select the next hop has been aggregated. That distinction is the protocol's power and its audit boundary.

A covering route is not a membership census

An aggregate says that traffic for a containing address range should move toward a next hop. It does not enumerate every specific member behind that boundary, nor certify that each member is currently available. The /24 can remain valid while one /32 egress fails.

Longest-match processing asks two local questions: does a RIB entry cover this FEC, and is the advertising LSR a next hop for that covered address? A positive answer supports a label action at that LSR. It is not a remote health check of the egress LER, an inventory proof for the aggregate, or an end-to-end data-plane test.

That is why a label can look more precise than the route evidence beneath it. The label names one egress FEC. The RIB names a larger region. Operations must not let the visual specificity of the label conceal the broader, weaker scope of the route that justified it.

Every aggregation boundary must understand the rule

RFC 5283 is optional. It should be configurable, disabled by default and may be activated per prefix. Backward compatibility means an older LSR does not corrupt unrelated forwarding; it does not mean an inter-area LSP silently crosses that LSR.

Where IP aggregation is used, every LSR in the affected area must implement the procedure for the specific LSP to remain contiguous. At a non-compliant node, the egress-originated LSP stops. The control plane can therefore be safe yet incomplete.

Capability must be measured along the relevant path and area, not inferred from one successful edge. A label at the ingress proves that the chain reached that ingress at that moment. During migration, a label missing upstream may identify the first unsupported or misconfigured boundary; a label present downstream does not erase that gap.

Cutover has a deliberate overlap period

The RFC permits incremental deployment, but it gives the migration an important ordering rule. If existing LSPs already depend on the specific IP routes, ABRs should keep advertising those specifics until every LSR in the area has been upgraded successfully. Only then should the specifics be withdrawn and the aggregate left alone.

This is not cosmetic configuration cleanup. Before cutover, exact-match LDP and longest-match LDP can both find sufficient RIB evidence. After cutover, only capable nodes can bind the specific FEC through the aggregate. Removing the specifics too early converts a capability inventory error into an LSP break.

A sound cutover receipt names the area, every in-scope LSR, software and feature state, per-prefix activation, last specific-route advertisement, aggregate activation, individual FEC mappings before and after, and packet tests. “All routers upgraded” is a plan; the simultaneous control-state observation is the evidence.

One route change can move many labels

Aggregation reduces IP entries, but it increases fan-out between a route event and label state. Many specific FECs can depend on one covering prefix. When that prefix appears, disappears or changes next hop, the LSR must reconsider every FEC that is its subset.

A new, more-specific RIB entry can become the best match for some FECs and not others. Their NHLFEs may move to another next hop while the FEC identifiers remain unchanged. A dashboard that watches only label creation and deletion will miss that rebinding.

The relevant evidence graph therefore joins the RIB prefix and generation, selected next hop, dependent FEC set, received label, local label, NHLFE and LFIB programming event. Without that join, an operator can see all expected FEC names yet fail to notice that a subset now leaves through a different neighbor.

Fewer FIB entries do not mean fewer label entries

RFC 5283 is candid about the scaling boundary. Aggregation reduces link-state database size and IP FIB entries. It does not reduce the number of LFIB entries required for the specific LSPs. The per-egress labels remain specific because that is how the end-to-end LSP identity is preserved.

This matters to capacity claims. An IP routing optimization may relieve one table while leaving label memory, programming work and failure fan-out unchanged. Calling the change “state reduction” without naming the table creates a false total.

The same discipline applies to convergence. SPF work depends on topology scale; FIB and LFIB update work depends on changed entries. The protocol can improve one term without eliminating another. Operators need separate budgets and telemetry for LSDB, RIB, FIB, LIB and LFIB rather than a single route-count proxy.

Egress failure is the exceptional case

For link, provider-router and ABR failures, RFC 5283 says notification and convergence are unchanged relative to ordinary LDP behavior. Egress LER failure is different. Because the IGP carries only an aggregate, the specific egress disappearance need not remove that aggregate route.

The specific truth must travel back through LDP ordered control. The egress-originated FEC is withdrawn hop by hop. Applications such as MP-BGP or L3VPN may use that signal, but how they do so is outside RFC 5283. The RFC expects propagation time comparable to IGP convergence while explicitly allowing implementation dependence.

This creates a valid interval in which the aggregate route is still present and an upstream label may not yet have been withdrawn, although the named egress is gone. That is not proof that the protocol violated its contract. It is proof that aggregate reachability and specific availability have different clocks.

Applications that require current egress life can rely on ordered LDP withdrawal or advertise specific reachability for control-plane consumption without installing it in the IP FIB. BFD can separately accelerate local connectivity detection in the static-edge example. None of these signals should be collapsed into the aggregate route itself.

A label path is still not a service receipt

Even after every node supports longest-match processing and the ordered chain is present, several boundaries remain. The label must be programmed into the LFIB, packets must enter the intended NHLFE, the downstream path must forward them, the egress must impose or remove the expected labels, the VPN or service context must accept them, and the application must produce the claimed outcome.

Control-plane presence is necessary evidence for an LDP LSP. It is not packet proof. A synthetic probe is useful only if its class, path, entropy, service context and return observation correspond to the claim. A successful ping to an infrastructure address does not automatically prove a customer VPN or mission-critical flow.

The receipt must be allowed to say: aggregate route present; specific FEC mapping present locally; capability unknown in a remote area; withdrawal in progress; LFIB not yet confirmed; probe failed; service unobserved. Precision makes failure diagnosable without asking one green label icon to represent six systems.

Build the inter-area receipt from both granularities

For a consequential LSP claim, preserve:

  • the specific FEC, address family and egress LER identity;
  • every covering RIB prefix considered and the chosen longest match;
  • RIB generation, metric, next hop and advertising LSR;
  • per-prefix RFC 5283 activation and node capability;
  • received and advertised label mappings, peers and timestamps;
  • the dependent FEC set for each aggregate route;
  • NHLFE and LFIB programming with hardware acknowledgement;
  • area and ABR boundaries crossed by the intended LSP;
  • exact-route-to-aggregate migration state and cutover order;
  • ordered withdraw origin, propagation and release state;
  • optional BFD or control-only specific reachability evidence;
  • MP-BGP, L3VPN or other application reaction;
  • cache-bypassed packet observations in both directions; and
  • the service outcome actually named by the operator.

The record should distinguish absence from delay. A stopped mapping at an unsupported LSR differs from a withdrawal still propagating. A present aggregate with a dark egress differs from a broken ABR. A programmed label with no returning packet differs from a missing label. These are separate operational owners and repair actions.

Sources