Summary

  • RFC 9903 is an IETF Standards Track specification defining the ietf-ospf-sr-mpls YANG module for OSPFv2 and OSPFv3 Segment Routing over MPLS.
  • The module augments the OSPF model from RFC 9129 and relies on RFC 9020 for protocol-independent SR resources. It presents one configuration surface, but operational readback remains version-aware.
  • OSPFv2 state uses Extended Prefix Opaque LSAs and Router Information Opaque LSAs. OSPFv3 state uses extended prefix LSAs/TLVs, Router-Link TLVs and Router Information LSAs.

The mechanism is best understood as a boundary between intent and evidence. RFC 9903 augments the RFC 9129 OSPF model. Its SR resources use RFC 9020 groupings for instance-level mapping-server bindings, per-protocol Segment Routing Global Blocks (SRGBs) and interface Adj-SIDs. The YANG model does not forward traffic, compute paths or assign labels; it represents configuration and operational state.

At area scope, SR-MPLS activation applies to every interface in the area and causes SR-MPLS information to be advertised in LSAs. It is therefore not an interface-local switch. At interface scope, the model represents Adj-SIDs for particular neighbors on broadcast or NBMA multi-access interfaces and represents TI-LFA over MPLS. TI-LFA and SR-based Remote LFA are optional: remote-lfa-sr applies only when Remote LFA is enabled. Mapping Server use is not mandatory.

The read path must follow the running OSPF version. For OSPFv2, Prefix Range and Prefix-SID information maps into Extended Prefix Opaque LSAs; algorithm, SID/Label Range, SR Local Block and SRMS Preference map into Router Information Opaque LSAs. For OSPFv3, prefix information is carried across extended prefix LSAs and TLVs; Adj-SID and LAN Adj-SID appear in Router-Link TLVs; algorithm, range, local block and SRMS preference appear in Router Information LSAs. A common schema does not make those wire families interchangeable.

A safe preflight starts with four concrete checks: identify whether the instance is OSPFv2 or OSPFv3; confirm the intended area set and its all-interface effect; compare the configured per-protocol SRGB and mapping-server bindings with the approved change; and list every neighbor-specific Adj-SID plus any proposed TI-LFA or Remote LFA dependency. Read back the matching LSDB family before and after activation. Treat a mismatch between configuration and protocol-specific state as a stop condition, not as evidence that the other version's encoding can substitute.

Management is part of the control boundary. NETCONF or RESTCONF must use secure transport and mutual authentication, while NACM can limit users to authorized operations and content. Unauthorized changes to SR enablement, bindings, an SRGB, Adj-SIDs or TI-LFA can disrupt, redirect or deny traffic. Readable OSPFv2 and OSPFv3 LSDB augmentations can disclose prefixes, algorithms, ranges, local blocks, SRMS information and topology useful to an attacker. Access controls must therefore cover both write and read paths.

Theo March analysis: the durable operational distinction is not “one model versus two models.” It is one intent surface with two evidence grammars. That distinction matters for software-lifecycle-and-lock-in decisions because a management abstraction can simplify authoring while still requiring protocol-specific validation, authorization and rollback evidence. Current vendor or controller support, adoption, performance, incidents, migration cost and deployment defaults are not established by this source set.

Operator decision path

  1. Inventory: record OSPF version, areas, interfaces, neighbors, existing SRGBs, bindings and current feature state.
  2. Authorize: separate instance, area and interface permissions in NACM and change review.
  3. Preflight: validate the version-specific LSA/TLV expectations and capture baseline operational state.
  4. Stage: select the smallest approved area scope; do not assume one interface limits an area-level change.
  5. Verify: confirm the correct OSPFv2 Opaque or OSPFv3 Extended-LSA/TLV family, then inspect Adj-SIDs and optional protection state.
  6. Rollback: use a version-aware reversal of enablement, bindings, SRGB, Adj-SIDs and optional TI-LFA settings, with separate evidence that each affected state family has returned to the approved baseline.

Sources