Summary

  • RFC 5152 computes an inter-domain TE LSP section by section when the head end lacks a complete cross-domain path.
  • Every boundary node uses the traffic-engineering visibility, reachability information, capabilities and policy available in its own domain.
  • An ERO can mix strict and loose hops, so some sections are prescribed while others are expanded locally during setup.
  • Boundary exits may be configured or discovered from IGP, BGP or policy information; absent exit knowledge can make computation fail.
  • A downstream constraint failure returns PathErr; crankback may try another exit, while the head end may retry, change loose hops or relax constraints.
  • None of those responses proves that the global search space was exhausted.
  • RFC 5152 explicitly says per-domain computation cannot guarantee the optimal inter-domain path.
  • Its trapping example shows a feasible first path can prevent discovery of a diverse second path although a diverse pair exists.
  • “No second path found” is therefore conditional on the first choice, computation order, visible topology, exclusions and algorithm.
  • Reoptimization can improve a path inside domains while preserving the same boundary sequence and missing a better inter-domain composition.
  • A provider may choose another computation method for LSPs requiring optimality or diversity, but the RFC does not make any alternative a universal guarantee.
  • Assurance must preserve receipts for the pairwise objective, method, topology version, ordered exits, resources consumed, exclusions, retries and observed service.

The failed second path was an artefact of the first decision

The topology in RFC 5152 is deliberately small. Four points, A through D, have enough connectivity for two paths that do not share the middle links: A-C-D and A-B-D. A serialized computation can instead choose A-B-C-D as its first LSP. Once that path becomes the reference to avoid, no diverse second path is available.

Nothing in the first result was necessarily invalid. Each hop existed. Each local constraint could be satisfied. The path reached D. The failure appears only when the objective changes from “find one feasible route” to “find a feasible pair with a defined diversity property.”

That distinction changes the meaning of the second failure. It does not prove that the topology lacks a diverse pair. It proves that no path diverse from the already selected A-B-C-D was found by that computation. The first route consumed the combinatorial freedom needed by the pair.

A distributed answer is assembled while the request is moving

Per-domain computation exists for the common case in which the head-end LSR cannot see or does not signal a complete end-to-end path. Visibility usually stops at an IGP-area or AS boundary. The RSVP-TE Path message carries the destination and the route known up to a boundary; it may also carry later boundaries or domain identifiers.

The boundary node computes the next section. It is not a remote adviser sitting outside the route: RFC 5152's responsible computation nodes are themselves on the resulting LSP. The same procedure can apply recursively when an AS contains areas, sub-ASes or other nested computational domains.

This architecture preserves local control and topology confidentiality. It also means the path becomes committed in an order. An early exit choice changes the state in which a later domain receives the request. A correct local answer is therefore an input to the next problem, not an independent proof about the end-to-end optimum.

Loose hops delegate choices; strict hops spend them early

An ERO can describe the complete strict route, the strict route through the source domain followed by boundary nodes, a list of domain boundaries, or only the present boundary and the final destination. Strict and loose hops can be mixed.

A strict next node invokes ordinary RSVP-TE processing. A loose hop or a multi-node abstract hop requires boundary procedures and local expansion. This gives the operator a spectrum: exert precise control where information is available, then delegate the unresolved sections to the domains that own them.

The ERO that eventually succeeds is evidence of the route description that survived this sequence. It is not a search transcript. It does not say which exits were considered, which were pruned, whether the algorithm optimized the first path or the pair, or whether an unseen alternative would have preserved diversity.

Exit discovery is a source of authority and uncertainty

The next boundary can be statically configured. It can also be auto-discovered from IGP, BGP or policy-routing information as the LSP is signaled. If a next hop is outside the local TE database, the boundary checks that it lies outside the domain and that the packet-switching and in-band-control assumptions apply. It then checks IP reachability.

Reachability to the next boundary is necessary for continuing the request. It is not a TE reservation receipt for the downstream domain. If the hop is unreachable, the boundary returns a Routing Problem PathErr. If neither discovery nor another scheme provides a domain exit, computation fails.

An exit was reachable and an exit was globally wise are different propositions. The first can be answered from current routing information. The second depends on paths and objectives that may span authorities and may not be visible to the node making the choice.

Crankback explores alternatives without becoming an exhaustive proof

Suppose a downstream ASBR cannot find a section obeying the constraints. It returns PathErr to the previous boundary. If crankback is allowed and configured, that upstream boundary can choose another egress. Without crankback, it stops and sends the error toward the head end.

The head end may have another loose-hop sequence configured. It may retry the same sequence when an outdated downstream IGP-TE database is suspected. It may relax one or more constraints. Those are useful recovery choices, but they answer different questions.

A retry asks whether time or state freshness changed the answer. Another exit asks whether a different local branch works. Relaxation asks whether a different service can be built. None, by itself, establishes that every globally feasible composition was examined under the original objective. A defensible record must preserve which question each attempt actually asked.

One-path feasibility is not a pairwise objective

Path diversity is not an attribute that can always be attached after selecting the primary route. It is a relationship between routes and a named set of things they must not share: links, nodes, facilities, shared-risk groups or administrative boundaries.

The trapping example is a warning against commissioning the routes independently. If the business requirement is a diverse pair, the objective belongs to the pair before either path is fixed. Computing “best path one” and then “anything disjoint from path one” can be structurally weaker than computing two paths together.

RFC 5152 permits a provider to choose the computation method per LSP. It points to PCE-based approaches when end-to-end constraint-based shortest paths or diverse sets are required. That is a method-selection boundary, not an endorsement that any PCE deployment sees complete, current topology or guarantees a solution. The receipt still needs to name the algorithm, information scope, risk definition and result.

Reoptimization can improve every segment without changing the wrong borders

For a contiguous LSP, a downstream domain can notify the head end that a better route exists. The head end controls make-before-break. For nested or stitched service, a domain can reoptimize its local H-LSP or S-LSP, potentially without extra inter-domain signaling and transparently to the head end.

Frequency, metric and bandwidth criteria can differ by domain. If an operator rejects transparent local reoptimization for particular LSPs, RFC 4736 reporting makes the event visible to the head end under configurable policy.

But when boundary LSRs remain loose-hop anchors, reoptimization can improve the route inside each domain while keeping the same sequence of borders. The result may be locally better and still globally trapped. An action receipt should therefore say whether it changed internal routing, boundary selection or the full pairwise composition.

Confidentiality is preserved by limiting the shared search surface

RFC 5152 says the method does not increase topology information exchanged between ASes. That is a material advantage: each domain computes with private detail rather than exporting its graph. The price is not automatically failure; the price is that no single participant necessarily possesses the search space needed to prove a global claim.

Boundary computation is also an attack surface. Operators need policy to reject unauthorized ERO expansion, contractual filters for bandwidth and priority, setup and error rate limits, outbound-message controls and coordinated RSVP authentication. Fast-Reroute protection of borders can add key synchronization among the point of local repair and merge point.

These controls authenticate and constrain the work a domain performs. They do not turn a reachable exit into an optimal exit, a completed LSP into a diverse pair or a failed second computation into proof of topological impossibility.

Sources

  1. RFC 5152, HTML
  2. RFC 5152, text
  3. RFC Editor record
  4. IETF Datatracker record
  5. RFC 5152 history
  6. RFC 5152 references
  7. RFC 5152 errata
  8. RFC 3209
  9. RFC 3473
  10. RFC 5151
  11. RFC 5150
  12. RFC 4920
  13. RFC 4655
  14. RFC 4726
  15. RFC 4105
  16. RFC 4216
  17. RFC 4736
  18. RFC 2747
  19. RFC 3097
  20. RFC 3630
  21. RFC 4203
  22. RFC 4205
  23. RFC 6805
  24. RFC 8694
  25. Minimum Initial Specification
  26. On Reality Layers
  27. Running-Code Primacy