Summary

  • RFC 9902 is an IETF Standards Track specification defining the ietf-isis-sr-mpls YANG module for IS-IS Segment Routing over the MPLS data plane.
  • It augments the IS-IS model from RFC 9130 and depends on the protocol-independent SR model in RFC 9020.
  • The model separates activation, mapping-server advertisement, mapping-server reception, optional protection features, configuration, and operational state instead of treating them as one generic switch.

The operational contract begins with enable. Setting that leaf to true activates IS-IS SR-MPLS and causes IS-IS to advertise the relevant extensions using parameters configured in the base SR model. The leaf is therefore not a label allocator, path calculator, or forwarding function. Before changing it, an operator must check that the SRGB, SRLB, algorithms, and other protocol-independent resources beneath the RFC 9020 model are present and internally consistent with the intended IS-IS state.

RFC 9902 augments RFC 9130, while RFC 9020 supplies the common SR foundation. That division matters for review: an IS-IS-specific change can depend on resources that are not configured in the IS-IS subtree. A valid preflight should inspect both layers, the advertised capabilities, and the expected operational state.

Mapping-server exchange has two distinct controls. bindings/advertise/policies selects policies whose bindings may be advertised. bindings/receive governs reception and processing. IS-IS neither advertises nor processes mapping-server entries by default. Enabling one direction does not silently enable the other, and neither direction should be inferred from the presence of SR resources.

The model also augments interface Fast Reroute. TI-LFA can be enabled where supported, and Remote LFA can use an SR path instead of an LDP path where the relevant option is supported and Remote LFA itself is enabled. These are optional feature declarations and configuration choices, not universal requirements. TI-LFA selection can expose tie-breakers such as node protection and SRLG disjointness; their priorities are configurable, with a lower value more preferred.

The observable surface includes SR capability flags, algorithms, SRGB and SRLB information, SR Mapping Server preference, Prefix-SIDs, adjacency SIDs, and SID/Label Binding TLVs. Configuration and LSDB operational-state augmentations make these items reviewable, but they do not guarantee that an implementation will forward traffic, compute paths, assign labels, or interoperate safely merely because the model is standardized.

Concrete conformance checks

  1. Confirm that the implementation advertises support for ietf-isis-sr-mpls and the intended optional features before writing their controls.
  2. Read the RFC 9020 SR resources and compare SRGB, SRLB, algorithm, Prefix-SID, Adj-SID, and binding expectations with the planned IS-IS state.
  3. Verify that enable is false during preparation, then activate it only after the comparison is approved.
  4. Confirm that mapping-server advertisement has no selected policy unless sending is explicitly authorized, and that reception remains off unless processing incoming bindings is intended.
  5. Check operational state for capabilities, algorithms, ranges, SIDs, bindings, and LSDB results after activation.
  6. Validate that TI-LFA or SR-based Remote LFA controls are written only when their features are supported; for SR-based Remote LFA, verify that Remote LFA is enabled.
  7. Use NETCONF or RESTCONF over secure transport with mutual authentication, and apply NACM so read and write permissions match operational roles.

RFC 9902 identifies two security classes. Unauthorized changes to SR, mapping-server binding, or TI-LFA configuration can drop or misroute traffic and can create denial of service. Read access can disclose router capabilities, algorithms, SRGB, SRLB, Mapping Server preference, and LSDB augmentations. Operational visibility is therefore not harmless visibility.

In this briefing, Theo March’s analysis is that controllers should validate both the protocol-specific and base-model layers, detect drift in ranges and advertised state, use staged rollout, and separate authorization roles for writes, policy exchange, and sensitive reads. That is analysis, not an RFC mandate. The RFC does not establish a particular vendor, controller, deployment default, migration cost, performance result, adoption level, incident history, or rollback threshold.

Operator decision path: if capabilities, resources, authorization, and intended policy all match, stage the model on a non-forwarding or maintenance-controlled scope, record the pre-change state, activate, and compare operational state with the expected inventory. If a mismatch, unexpected advertisement, binding change, or protection-state deviation appears, withdraw the new configuration in the reverse order, restore the recorded values, disable enable if appropriate, and verify the resulting LSDB and traffic-control state. This is a local operating procedure, not a guarantee of zero downtime or safety.

Sources