Summary

  • An XRO constrains the whole path; an EXRS is carried inside an ERO and applies to a bounded segment while that ERO is expanded.
  • With the L bit clear, the identified resource MUST be excluded. With the L bit set, it SHOULD be avoided, but local policy may still use it.
  • Diversity is a result to verify, not a promise carried by a flag or an identifier.

What the mechanism authorizes

The originator supplies negative constraints. A path-computing node applies them while choosing a next hop or expanding a loose route. RFC 3209 provides the ERO model for including abstract nodes; RFC 4874 adds explicit exclusion signaling where the ingress need not compute the complete route. An XRO can name IPv4 or IPv6 prefixes, unnumbered interfaces, autonomous systems and SRLGs, with prefix and interface forms distinguishing relevant interface, node and risk attributes.

The distinction is operationally decisive. An XRO is whole-path: its exclusions govern the path being computed. An Explicit Exclusion Route Subobject (EXRS) sits in an ERO and is segment-bounded by that explicit route context. A clear L bit is a hard exclusion: the node MUST NOT introduce the named resource. A set L bit expresses avoidance: the node SHOULD minimize use, yet may traverse it under local path-selection policy. An exclusion is therefore a veto over named resources, not authorship of the remaining path.

A mandatory exclusion contradicting an ERO inclusion wins. The implementation must reject the Path message and return the defined Routing Problem error. If all forwarding choices are removed, the node should return a PathErr stating that the route was blocked by the Exclude Route. An XRO too complex for implementation or policy may likewise be rejected with its specified PathErr. A node that does not support XRO may forward the object without inspection; unsupported subobjects or attributes may be ignored. That compatibility limit makes verification essential, not optional.

Verification fixtures

Use a test Path whose XRO marks, with L clear, one interface, one node prefix, one autonomous system and one SRLG as forbidden. The expected fixture is removal of each from the feasible set before the next-hop decision, without prescribing the next hop. Add an XRO reference-path exclusion and verify that the complete computed path does not use that reference. Repeat with L set: traversal remains possible and must be treated as advisory, not as a failure of a MUST.

Add an ERO that includes a resource also marked mandatory in the XRO. The expected result is rejection with Routing Problem, not silent preference for the ERO. Construct a topology in which every next hop is excluded; expect PathErr for a route blocked by the Exclude Route. Send an XRO beyond implementation or policy complexity; expect the specified XRO-too-complex PathErr.

Send the object through a node that lacks XRO support, and send an unsupported subobject or attribute; record that forwarding or ignoring may occur, then inspect Record Route to detect a traversed forbidden resource and attempt rerouting where the implementation supports it.

Finally, record a first path and construct a second-path request excluding its nodes or SRLGs. Verify the resulting Record Route rather than infer diversity from the request. Test a boundary where ordinary ERO detail is removed, while an RFC 8390 diversity subobject must be retained. Use client-, PCE- or network-allocated reference-path identifiers, and test inconsistent and unsupported identifiers for their specified errors. These fixtures are protocol checks; the frozen sources provide no live topology, measured path quality or proof of physical separation.

Multi-layer and reference-path extensions

RFC 6001 updates the exclusion model for multi-layer and multi-region GMPLS. Switching-capability and label subobjects can exclude a layer capability or label range while preserving the hard-versus-advisory distinction. The feasible set can therefore shrink across layers, not merely across links. RFC 8390 adds diversity XRO and EXRS subobjects for a client-, PCE- or network-allocated identifier referring to a reference LSP or path whose detailed resources may not be known to the requester.

Mandatory and advisory diversity remain different authorities; specified diversity information is retained across a boundary even when ordinary explicit-route information is removed for security policy. Correctness consequently depends on the authority that resolves and verifies the reference.

What is known, and what is not

Facts above are drawn from the frozen RFC Editor texts and the RFC 4874 errata record. Elias Ward analysis: mandatory exclusions benefit services that need separation, but reduce the feasible set and can turn setup into failure; advisory avoidance preserves more availability while weakening separation. Unknowns remain live topology, support by any particular implementation, deployments, setup latency, failure rates, measured diversity and customer impact. No allegation is made. A diversity signal is not evidence that live paths are physically diverse.

Sources