Summary

  • RFC 7570 defines generic ERO and RRO Hop Attributes subobjects for attributes associated with a specific hop.
  • The ERO container is type 35, variable in length, and carries one or more Hop Attributes TLVs. Its scope is the immediately preceding identifying ERO subobject, or the label subobjects associated with that hop.
  • Placement establishes scope. The R bit imports RFC 5420 required or optional processing; it does not define what the attribute means.

The practical mechanism is an adjacency rule. The ingress places the type 35 ERO Hop Attributes subobject after the ERO object naming the intended route step, or after that hop's associated label subobjects. The addressed node examines the TLVs. Other hops are not thereby instructed to apply the same attribute. The generic mechanism is a container, not a universal permission slip.

Every defining attribute document must say which preceding ERO subobject types are valid, whether ordering matters, how ordering is interpreted, and what modification rules apply. Those documents also decide whether an attribute is optional, required, reportable or modifiable. The R bit only changes processing policy: set means the node examines the TLVs under RFC 5420's required rules; clear means optional rules apply. It does not change the substantive meaning of a TLV.

Unsupported or malformed content has operational consequences. A node that encounters an unsupported ERO Hop Attributes subobject returns a Routing Error / Bad EXPLICIT_ROUTE PathErr, with the ERO truncated at the offending subobject. RFC 3209 separately says that an unrecognized ERO subobject encountered during normal processing produces a Bad Explicit Route Object error, while one not yet encountered is passed forward. For flags, only flags defined as valid in this context apply: invalid flags are silently ignored, whereas unknown flags should cause an Unknown Attributes Bit PathErr.

Local policy or admission control can still reject a request, and a node may modify it where the defining TLV procedure permits. Thus ingress power is request authority, bounded by the defining RFC and node authorization—not guaranteed execution.

Reporting has two different lanes. RFC 5420 governs whole-LSP attributes carried in LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES and ordinarily reported in RRO Attributes. An attribute signaled only in ERO Hop Attributes is ordinarily reported in RRO Hop Attributes, the optional type 35 RRO container. A node may report that it considered a hop attribute or report an additional attribute, but compliance reporting must be required by the attribute document. Without that definition, successful setup is not proof that an optional behavior occurred.

RRO Hop Attributes are evidence, not immutable proof. Transit nodes normally forward them unmodified, yet a domain edge may prune or modify them for confidentiality or size policy. Older ingress nodes can also drop unknown RRO information. RFC 3209 presents RRO as collected route information useful for loop detection and diagnostics, not as an authorization channel. RFC 7571 offers one bounded application: an OAM loopback request can target a particular node and return loopback state. That example does not make loopback the generic meaning of RFC 7570.

The beneficiary is a service that needs behavior at one transit step. The costs are compatibility dependencies, ERO/RRO message space, failure risk for unsupported or malformed required content, ordering complexity and possible disclosure of hop state. The source set establishes no vendors, deployments, prevalence, failure rates, message-growth measurements or customer outcomes.

Packet-level verification fixtures

  1. Construct an ERO naming hop A, then type 35 ERO Hop Attributes containing a valid TLV with R clear. Verify that hop A is the addressed scope, not hop B, and that successful setup alone does not establish optional execution.
  2. Repeat with R set on an unsupported or malformed subobject. Verify a Bad EXPLICIT_ROUTE PathErr and truncation at the offending subobject; do not infer a vendor behavior.
  3. Place the subobject before the identifying ERO object, or attach it to the wrong label sequence. Verify against the defining attribute document's placement rules rather than assuming generic validity.
  4. Send an invalid flag and an unknown flag separately. Verify silent ignore for the invalid flag and the specified Unknown Attributes Bit behavior for the unknown flag.
  5. Compare LSP_ATTRIBUTES/RFC 5420 RRO Attributes with ERO-only/RRO Hop Attributes. Then test a domain boundary that prunes RRO information and record that absent evidence is not evidence of non-processing.

Operator decision path

First identify the exact preceding ERO object and the attribute document. Next confirm placement, ordering, valid flags and modification rules. Decide whether optional processing is acceptable; set R only when rejection is preferable to silent non-support. Check node policy and admission control, then budget message size and disclosure. Finally define what RRO report is required and how its absence, pruning or modification will be treated. If the beneficiary needs proof at a specific hop, do not substitute whole-LSP reporting or an unqualified successful Path setup.

Sources