RFC 9902
A YANG Data Model for IS-IS Segment Routing over the MPLS Data Plane
RFC 9902: A YANG Data Model for IS-IS Segment Routing over the MPLS Data Plane 🦋
okay bestie, let's do the vibe check first ✨ This is RFC 9902, titled A YANG Data Model for IS-IS Segment Routing over the MPLS Data Plane. It's a Standards Track document (ISSN 2070-1721) from the Internet Engineering Task Force (IETF), dated December 2025. The authors are S. Litkowski (Cisco Systems), Y. Qu (Futurewei Technologies), A. Lindem (LabN Consulting, L.L.C.), I. Chen (Red Hat, Inc.), and J. Tantsura (Nvidia). The header doesn't list anything it obsoletes or updates, so there's no older RFC being replaced or patched here 🌸
Abstract
okay so the whole point is this: it defines a YANG data model you can use to manage IS-IS extensions for Segment Routing (SR) over the MPLS data plane 💜
Status of This Memo
this one is giving very official vibes 💅
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9902.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. 🫶
Table of Contents 🍓
1. Overview
1.1. Tree Diagrams
2. Design of the YANG Module for IS-IS MPLS Segment Routing
2.1. Segment Routing Activation
2.2. Advertising Mapping Server Policy
2.3. IP Fast Reroute
3. IS-IS Segment Routing over MPLS YANG Module
4. Security Considerations
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Appendix A. A Configuration Example
Appendix B. IS-IS MPLS Segment Routing Module Tree
Acknowledgements
Authors' Addresses1. Overview 🌈
okay so this document defines a device YANG data model [RFC7950] that manages IS-IS extensions for Segment Routing (SR) [RFC8667] over the MPLS data plane. it's an augmentation to the IS-IS YANG data model [RFC9130] ✨
1.1. Tree Diagrams
this section explains how the tree diagrams work. the document uses the graphical representation of a data model as defined in [RFC8340] 🌸
2. Design of the YANG Module for IS-IS MPLS Segment Routing 💅
the IS-IS SR MPLS YANG module needs support for the base SR module [RFC9020]. that base module handles the global SR management that doesn't depend on any specific routing protocol configuration. it also needs support for the IS-IS base model [RFC9130], which covers the basic IS-IS configuration and state 🦋
the ietf-isis-sr-mpls data model defines two things: the data nodes you use to configure IS-IS SR MPLS extensions, and the additions to the IS-IS Link State Protocol Data Units (LSPs) that are needed to support MPLS SR 🧚
2.1. Segment Routing Activation
turning it on is simple bestie. you activate IS-IS SR MPLS by setting the enable leaf to true 🔥 once that's done, advertisement of SR MPLS extensions starts, based on the configuration parameters you've already set up using the base SR module 💖
2.2. Advertising Mapping Server Policy
the base SR module defines mapping server policies. by default, IS-IS will not advertise or process any mapping server entry 🙈 the IS-IS SR MPLS module lets you advertise one or multiple mapping server policies through the bindings/advertise/policies leaf-list. the bindings/receive leaf controls whether mapping server entries get received and processed 👑
2.3. IP Fast Reroute
the IS-IS SR MPLS module augments the Fast Reroute (FRR) container under interface. it brings the ability to activate Topology Independent Loop-Free Alternate (TI-LFA), and it also enhances Remote LFA (RLFA) so it uses SR tunneling instead of LDP ✨
3. IS-IS Segment Routing over MPLS YANG Module 🎀
the YANG module references [RFC6991], [RFC8102], [RFC8294], [RFC8349], [RFC8402], [RFC8667], [RFC9020], [RFC9130], and [RFC9855]. here's the whole module, exactly as written:
<CODE BEGINS> file "ietf-isis-sr-mpls@2025-12-09.yang"
module ietf-isis-sr-mpls {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-isis-sr-mpls";
prefix isis-sr-mpls;
import ietf-routing {
prefix rt;
reference
"RFC 8349: A YANG Data Model for Routing
Management (NMDA Version)";
}
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-segment-routing-common {
prefix sr-cmn;
reference
"RFC 9020: YANG Data Model for Segment Routing";
}
import ietf-segment-routing-mpls {
prefix sr-mpls;
reference
"RFC 9020: YANG Data Model for Segment Routing";
}
import ietf-isis {
prefix isis;
reference
"RFC 9130: YANG Data Model for IS-IS Protocol";
}
import iana-routing-types {
prefix iana-rt-types;
reference
"RFC 8294: Common YANG Data Types for the Routing Area";
}
import ietf-routing-types {
prefix rt-types;
reference
"RFC 8294: Common YANG Data Types for the Routing Area";
}
organization
"IETF LSR - Link State Routing Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/lsr/>
WG List: <mailto:lsr@ietf.org>
Author: Stephane Litkowski
<mailto:slitkows.ietf@gmail.com>
Author: Yingzhen Qu
<mailto:yingzhen.ietf@gmail.com>
Author: Acee Lindem
<mailto:acee.ietf@gmail.com>
Author: Ing-Wher Chen
<mailto:ichen@redhat.com>
Author: Jeff Tantsura
<mailto:jefftant.ietf@gmail.com>
";
description
"This YANG module defines the generic configuration and
operational state for SR IS-IS extensions for the
MPLS data plane.
Copyright (c) 2025 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9902;
see the RFC itself for full legal notices.";
revision 2025-12-09 {
description
"Initial revision.";
reference
"RFC 9902: A YANG Data Model for IS-IS Segment Routing over
the MPLS Data Plane";
}
/* Features */
feature remote-lfa-sr {
description
"Enhance RLFA to use SR path.";
reference
"RFC 8102: Remote-LFA Node Protection and Manageability";
}
feature ti-lfa {
description
"Topology Independent Loop-Free Alternate (TI-LFA)
computation using SR.";
reference
"RFC 9855: Topology Independent Fast Reroute Using Segment
Routing";
}
/* Identities */
identity sr-capability {
description
"Base identity for IS-IS SR-Capabilities sub-TLV flags.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing";
}
identity mpls-ipv4 {
base sr-capability;
description
"If set, then the router is capable of
processing SR-MPLS-encapsulated IPv4 packets
on all interfaces.";
}
identity mpls-ipv6 {
base sr-capability;
description
"If set, then the router is capable of
processing SR-MPLS-encapsulated IPv6 packets
on all interfaces.";
}
identity prefix-sid-flag {
description
"Base identity for Prefix Segment Identifier (Prefix-SID)
sub-TLV flags.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 2.1";
}
identity r-flag {
base prefix-sid-flag;
description
"Re-advertisement Flag.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 2.1";
}
identity n-flag {
base prefix-sid-flag;
description
"Node-SID Flag.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 2.1";
}
identity p-flag {
base prefix-sid-flag;
description
"No-PHP (No Penultimate Hop-Popping) Flag.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 2.1";
}
identity e-flag {
base prefix-sid-flag;
description
"Explicit NULL Flag.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 2.1";
}
identity v-flag {
base prefix-sid-flag;
description
"Value Flag.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 2.1";
}
identity l-flag {
base prefix-sid-flag;
description
"Local Flag.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 2.1";
}
identity adj-sid-flag {
description
"Base identity for Adjacency Segment Identifier (Adj-SID)
sub-TLV flags.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 2.2";
}
identity f-flag {
base adj-sid-flag;
description
"Address-Family Flag.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 2.2";
}
identity b-flag {
base adj-sid-flag;
description
"Backup Flag.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 2.2";
}
identity vi-flag {
base adj-sid-flag;
description
"Value/Index Flag - corresponds to V-Flag in reference.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 2.2";
}
identity lg-flag {
base adj-sid-flag;
description
"Local/Global Flag - corresponds to L-Flag in reference.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 2.2";
}
identity s-flag {
base adj-sid-flag;
description
"Set Flag - corresponds to S-Flag in reference.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 2.2";
}
identity pe-flag {
base adj-sid-flag;
description
"Persistent Flag - corresponds to P-Flag in reference.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 2.2";
}part 1 is done bestie, but we are NOT at the end yet 😭🫶 the module keeps going into part 2 with more features, groupings, and data nodes, so stay right here 🎀💜
identity sid-binding-flag {
description
"Base identity for SID Binding TLV flags.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 2.4";
}
identity af-flag {
base sid-binding-flag;
description
"Address-Family Flag - corresponds to F-Flag in reference.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 2.4";
}
identity m-flag {
base sid-binding-flag;
description
"Mirror Context Flag.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 2.4";
}
identity sf-flag {
base sid-binding-flag;
description
"S-Flag. If set, the Label Binding TLV should be flooded
across the entire routing domain - corresponds to S-Flag in
reference.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 2.4";
}
identity d-flag {
base sid-binding-flag;
description
"Leaking Flag.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 2.4";
}
identity a-flag {
base sid-binding-flag;
description
"Attached Flag.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 2.4";
}okay so these six identities are all the SID Binding TLV flags 🦋 they all hang off the sid-binding-flag base, and every single one points back to RFC 8667 Section 2.4 💜 the af-flag is the F-Flag, the m-flag is the Mirror Context one, the sf-flag is the S-Flag (if it's set, the Label Binding TLV should get flooded across the whole routing domain 🌍), d-flag is Leaking, and a-flag is Attached. iconic lineup ✨
/* Groupings */
grouping sid-tlv-encoding {
description
"SID TLV Encoding - 20-bit label or 32-bit SID index whose
interpretation is dependent on the TLV length (3 for an
MPLS label or 4 for a 32-bit value) or the TLV V-Flag and
L-Flag settings:
If the V-Flag is set to 0 and L-Flag is set to 0:
The SID/Index/Label field is a 4-octet index defining
the offset in the SID/Label space advertised by this
router.
If the V-Flag is set to 1 and L-Flag is set to 1:
The SID/Index/Label field is a 3-octet local label where the
20 rightmost bits are used for encoding the label value.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing,
Section 2.1.1.1";
choice sid {
case sid-label {
leaf label-value {
type uint32 {
range "0 .. 1048575";
}
description
"A 20-bit MPLS label.";
}
}
case sid-index {
leaf index-value {
type uint32;
description
"Index into a label space advertised by this router.";
}
}
description
"Choice of either a 20-bit MPLS label or 32-bit index into
an advertised label space.";
}
}this one is the big SID TLV encoding grouping 🧠 the SID field can be either a 20-bit MPLS label or a 32-bit index, and which one you get depends on the TLV length (3 for a label, 4 for a 32-bit value) or on the V-Flag and L-Flag combo. two combos are spelled out: V-Flag 0 with L-Flag 0 means a 4-octet index giving the offset in the SID/Label space this router advertises 🌸 and V-Flag 1 with L-Flag 1 means a 3-octet local label where the 20 rightmost bits hold the label value 💅 the YANG choice then gives you label-value or index-value, which is honestly so clean
grouping sr-capability {
description
"SR-Capability grouping.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 3.1";
container sr-capability {
description
"SR-Capability flags.";
leaf-list sr-capability-flag {
type identityref {
base sr-capability;
}
description
"SR-Capability sub-TLV flags.";
}
container global-blocks {
description
"Segment Routing Global Blocks (SRGBs).";
list global-block {
description
"Segment Routing Global Block.";
leaf range-size {
type rt-types:uint24;
description
"The SID range.";
}
uses sid-tlv-encoding;
}
}
}
}
grouping sr-algorithm {
description
"SR algorithm grouping.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 3.2";
container sr-algorithms {
description
"All SR algorithms.";
leaf-list sr-algorithm {
type identityref {
base sr-cmn:prefix-sid-algorithm;
}
description
"The SR algorithms that the router is
currently using.";
}
}
}
grouping srlb {
description
"SR Local Block grouping.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 3.3";
container local-blocks {
description
"List of Segment Routing Local Blocks (SRLBs).";
list local-block {
description
"Segment Routing Local Block.";
leaf range-size {
type rt-types:uint24;
description
"The SID range.";
}
uses sid-tlv-encoding;
}
}
}next up is the SR-Capability grouping, which holds the capability flags plus the Global Blocks (SRGBs) 🌈 each SRGB is a range-size plus the same SID encoding we just looked at. then sr-algorithm covers the algorithms the router is currently using ⭐ and srlb is the SR Local Block list, which has the exact same shape as the global blocks, so it's giving déjà vu 🫶 all three cite the matching sections of RFC 8667 (3.1, 3.2 and 3.3)
grouping srms-preference {
description
"The SR Mapping Server (SRMS) Preference TLV is used to
advertise a preference associated with the node that acts as
an SRMS.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 3.4";
container srms-preference {
description
"SRMS Preference TLV.";
leaf preference {
type uint8;
description
"SRMS Preference TLV, value from 0 to 255 with
255 being the most preferred.";
}
}
}
grouping adjacency-state {
description
"This grouping extends adjacency state.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 2.2";
list adjacency-sid {
config false;
description
"List of Adj-SIDs.";
leaf value {
type uint32;
description
"Value of the Adj-SID.";
}
leaf address-family {
type iana-rt-types:address-family;
description
"Address-family associated with the
segment ID.";
}
leaf weight {
type uint8;
description
"Weight associated with
the Adj-SID.";
}
leaf protection-requested {
type boolean;
description
"Describe if the Adj-SID
must be protected.";
}
}
}the SRMS Preference grouping is a single preference leaf, a uint8 from 0 to 255 where 255 is the most preferred 👑 and adjacency-state extends the adjacency state with an Adj-SID list. the config false on that list just means it's operational state, not something you configure 🙈 each entry has a value, an address-family, a weight and a protection-requested boolean, and yes the description literally says "must be protected" lowercase, which is the YANG description, not a keyword, so we're moving on 😭
grouping prefix-sid-sub-tlv {
description
"This grouping defines the SR Prefix Segment
Identifier (Prefix-SID) sub-TLV.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 2.1";
container prefix-sid-sub-tlvs {
description
"Prefix-SID sub-TLVs.";
list prefix-sid-sub-tlv {
description
"List of Prefix-SID sub-TLVs.";
container prefix-sid-flags {
description
"Describes flags associated with the
segment ID.";
leaf-list flag {
type identityref {
base prefix-sid-flag;
}
description
"Prefix-SID sub-TLV flags.";
}
}
leaf algorithm {
type identityref {
base sr-cmn:prefix-sid-algorithm;
}
description
"Algorithm to be used for path computation.";
}
uses sid-tlv-encoding;
}
}
}
grouping adjacency-segment-id {
description
"This grouping defines SR extensions
for adjacencies.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing, Section 2.2";
container adj-sid-sub-tlvs {
description
"Adj-SID optional sub-TLVs.";
list adj-sid-sub-tlv {
description
"List of segments.";
container adj-sid-flags {
description
"Adj-SID sub-TLV flags.";
leaf-list flag {
type identityref {
base adj-sid-flag;
}
description
"Adj-SID sub-TLV flags list.";
}
}
leaf weight {
type uint8;
description
"The value represents the weight of the Adj-SID
for the purpose of load balancing.";
}
leaf neighbor-id {
type isis:system-id;
description
"Describes the system ID of the neighbor
associated with the SID value. This is only
used on LAN adjacencies.";
}
uses sid-tlv-encoding;
}
}
}the Prefix-SID sub-TLV grouping is where the flags, the algorithm (used for path computation) and the SID encoding all come together 🍓 the Adj-SID grouping does the same job for adjacencies, with a weight that's there for load balancing 💜 the neighbor-id leaf is the system ID of the neighbor tied to the SID, and the description says it's only used on LAN adjacencies, so keep that in mind, bestie 👀
grouping sid-binding-tlv {
description
"SID/Label Binding TLV, type 149.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing,
Section 2.4";
leaf prefix {
type inet:ip-prefix;
description
"The prefix represents the Forwarding Equivalence
Class (FEC) at the tail end of the advertised path.";
}
leaf range {
type uint16;
description
"Provides the ability to specify a range of addresses
and their associated Prefix-SIDs.";
}
container sid-binding-flags {
description
"Binding TLV flags.";
leaf-list flag {
type identityref {
base sid-binding-flag;
}
description
"SID Binding TLV flags.";
}
}
list prefix-sid-sub-tlvs {
description
"List of Prefix-SID sub-TLVs.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing,
Section 2.4.4";
uses prefix-sid-sub-tlv;
}
list sid-sub-tlv {
description
"List of Prefix-SID sub-TLVs.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing,
Section 2.4.5";
uses sid-tlv-encoding;
}
uses isis:unknown-tlvs;
}now the main event, the SID/Label Binding TLV, type 149 🎀 this is where the prefix (an inet:ip-prefix) represents the FEC at the tail end of the advertised path, and range lets you cover a range of addresses and their Prefix-SIDs 🦋 it pulls in the binding flags from earlier, plus two sub-TLV lists (one for Prefix-SID sub-TLVs in Section 2.4.4 and one for SID sub-TLVs in Section 2.4.5), and then uses isis:unknown-tlvs so unknown TLVs can ride along too ✨ the whole thing is giving complete
/* Configuration */
augment "/rt:routing/"
+ "rt:control-plane-protocols/rt:control-plane-protocol"
+ "/isis:isis" {
when "derived-from-or-self(../rt:type, 'isis:isis')" {
description
"This augments the IS-IS routing protocol when used.";
}
description
"This augments the IS-IS protocol configuration
with SR for the MPLS data plane.";
uses sr-mpls:sr-control-plane;
container protocol-srgb {
if-feature "sr-mpls:protocol-srgb";
description
"Per-protocol SRGB.";
reference
"RFC 8402: Segment Routing Architecture, Section 2";
uses sr-cmn:srgb;
}
}
augment "/rt:routing/"
+ "rt:control-plane-protocols/rt:control-plane-protocol"
+ "/isis:isis/isis:interfaces/isis:interface" {
when "derived-from-or-self(../../../rt:type, 'isis:isis')" {
description
"This augments the IS-IS routing protocol when used.";
}
description
"This augments the IS-IS protocol configuration
with SR.";
uses sr-mpls:igp-interface {
augment "segment-routing/adjacency-sid/adj-sids" {
when "../../../isis:interface-type = 'broadcast'" {
description
"This augments the broadcast interface.";
}
description
"This augments the LAN interface adj-sid with system-id.";
leaf neighbor-system-id {
type isis:system-id;
mandatory true;
description
"Neighbor system ID.";
}
}
}
}last bit of this chunk is the configuration side 💅 the first augment hangs SR-MPLS control plane stuff onto the IS-IS protocol instance, plus an optional per-protocol SRGB behind the sr-mpls:protocol-srgb feature (that one points at RFC 8402 Section 2). the second augment goes onto each IS-IS interface and adds a neighbor-system-id leaf to the LAN adj-sids, and that leaf is mandatory true 🌸 it's only applied when the interface type is broadcast, so it's super targeted, no cap
Okay bestie, this part is all YANG augments 💅 They bolt TI-LFA settings onto IS-IS interfaces, add the remote-LFA SR switch, and then hang the operational state and SID/Label Binding TLVs off the LSDB. Iconic plumbing 🦋
augment "/rt:routing/"
+ "rt:control-plane-protocols/rt:control-plane-protocol"
+ "/isis:isis/isis:interfaces/isis:interface"
+ "/isis:fast-reroute/isis:lfa" {
when "derived-from-or-self(../../../../../rt:type,"
+ "'isis:isis')" {
description
"This augments the IS-IS routing protocol when used.";
}
description
"This augments the IS-IS interface IP Fast Reroute (IP-FRR)
with TI-LFA.";
container ti-lfa {
if-feature "ti-lfa";
description
"Topology Independent Loop-Free Alternate
(TI-LFA) support.";
leaf enabled {
type boolean;
default "false";
description
"Enables TI-LFA computation.";
}
container selection-tie-breakers {
description
"Configure path selection tie-breakers and their
respective priorities for the TI-LFA computation.";
container node-protection {
presence "Presence of container enables the node
protection tie-breaker.";
description
"Enable node protection as a TI-LFA path
selection tie-breaker. A path providing node
protection will be selected over one that
doesn't provide node protection.";
leaf priority {
type uint8;
default "128";
description
"Priority for node protection tie-breaker with
a lower priority being more preferred.";
}
}
container srlg-disjoint {
presence "Presence of container enables the SRLG
disjoint tie-breaker.";
description
"Enable Shared Risk Link Group (SRLG)
disjoint as a TI-LFA path selection tie-breaker.
A path providing a node with a disjoint path for SRLG
links from the primary path will be selected over
a path that doesn't provide an SRLG disjoint path.";
leaf priority {
type uint8;
default "128";
description
"Priority for SRLG disjoint tie-breaker with
a lower priority being more preferred.";
}
}
}
}
}
augment "/rt:routing/"
+ "rt:control-plane-protocols/rt:control-plane-protocol"
+ "/isis:isis/isis:interfaces/isis:interface"
+ "/isis:fast-reroute/isis:lfa/isis:level-1" {
when "derived-from-or-self(../../../../../../rt:type,"
+ "'isis:isis')" {
description
"This augments the IS-IS routing protocol when used.";
}
description
"This augments the IS-IS interface level-1 IP FRR with
TI-LFA.";
container ti-lfa {
if-feature "ti-lfa";
description
"TI-LFA configuration.";
leaf enabled {
type boolean;
default "false";
description
"Enables TI-LFA computation.";
}
}
}
augment "/rt:routing/"
+ "rt:control-plane-protocols/rt:control-plane-protocol"
+ "/isis:isis/isis:interfaces/isis:interface"
+ "/isis:fast-reroute/isis:lfa/isis:level-2" {
when "derived-from-or-self(../../../../../../rt:type,"
+ "'isis:isis')" {
description
"This augments the IS-IS routing protocol when used.";
}
description
"This augments the IS-IS interface level-2 IP FRR with
TI-LFA.";
container ti-lfa {
if-feature "ti-lfa";
description
"TI-LFA configuration.";
leaf enabled {
type boolean;
default "false";
description
"Enables TI-LFA computation.";
}
}
}
augment "/rt:routing/"
+ "rt:control-plane-protocols/rt:control-plane-protocol"
+ "/isis:isis/isis:interfaces/isis:interface"
+ "/isis:fast-reroute/isis:lfa/isis:remote-lfa" {
when "derived-from-or-self(../../../../../../rt:type,"
+ "'isis:isis')" {
description
"This augments the IS-IS routing protocol when used.";
}
description
"This augments the IS-IS RLFA configuration with
use of the SR path.";
leaf use-segment-routing-path {
if-feature "remote-lfa-sr";
type boolean;
default "false";
description
"Force RLFA to use the SR path instead of
LDP path. The value of this leaf is in effect only when
remote-lfa is enabled.";
}
}
/* Operational states */
augment "/rt:routing/"
+ "rt:control-plane-protocols/rt:control-plane-protocol"
+ "/isis:isis/isis:interfaces/isis:interface"
+ "/isis:adjacencies/isis:adjacency" {
when "derived-from-or-self(../../../../../rt:type,"
+ "'isis:isis')" {
description
"This augments the IS-IS routing protocol when used.";
}
description
"This augments the IS-IS protocol configuration
with SR.";
uses adjacency-state;
}
augment "/rt:routing/"
+ "rt:control-plane-protocols/rt:control-plane-protocol"
+ "/isis:isis/isis:database/isis:levels/isis:lsp"
+ "/isis:router-capabilities/isis:router-capability" {
when "derived-from-or-self(../../../../../../rt:type,"
+ "'isis:isis')" {
description
"This augments the IS-IS routing protocol when used.";
}
description
"This augments the IS-IS protocol Link State Database (LSDB)
router capability.";
uses sr-capability;
uses sr-algorithm;
uses srlb;
uses srms-preference;
}
augment "/rt:routing/"
+ "rt:control-plane-protocols/rt:control-plane-protocol"
+ "/isis:isis/isis:database/isis:levels/isis:lsp"
+ "/isis:extended-is-neighbor/isis:neighbor/isis:instances"
+ "/isis:instance" {
when "derived-from-or-self(../../../../../../../../rt:type,"
+ "'isis:isis')" {
description
"This augments the IS-IS routing protocol when used.";
}
description
"This augments the IS-IS protocol LSDB neighbor.";
uses adjacency-segment-id;
}
augment "/rt:routing/"
+ "rt:control-plane-protocols/rt:control-plane-protocol"
+ "/isis:isis/isis:database/isis:levels/isis:lsp"
+ "/isis:mt-is-neighbor/isis:neighbor/isis:instances"
+ "/isis:instance" {
when "derived-from-or-self(../../../../../../../../rt:type,"
+ "'isis:isis')" {
description
"This augments the IS-IS routing protocol when used.";
}
description
"This augments the IS-IS protocol LSDB neighbor.";
uses adjacency-segment-id;
}
augment "/rt:routing/"
+ "rt:control-plane-protocols/rt:control-plane-protocol"
+ "/isis:isis/isis:database/isis:levels/isis:lsp"
+ "/isis:extended-ipv4-reachability/isis:prefixes" {
when "derived-from-or-self(../../../../../../rt:type,"
+ "'isis:isis')" {
description
"This augments the IS-IS routing protocol when used.";
}
description
"This augments the IS-IS protocol LSDB prefix.";
uses prefix-sid-sub-tlv;
}
augment "/rt:routing/"
+ "rt:control-plane-protocols/rt:control-plane-protocol"
+ "/isis:isis/isis:database/isis:levels/isis:lsp"
+ "/isis:mt-extended-ipv4-reachability/isis:prefixes" {
when "derived-from-or-self(../../../../../../rt:type,"
+ "'isis:isis')" {
description
"This augments the IS-IS routing protocol when used.";
}
description
"This augments the IS-IS protocol LSDB prefix.";
uses prefix-sid-sub-tlv;
}
augment "/rt:routing/"
+ "rt:control-plane-protocols/rt:control-plane-protocol"
+ "/isis:isis/isis:database/isis:levels/isis:lsp"
+ "/isis:ipv6-reachability/isis:prefixes" {
when "derived-from-or-self(../../../../../../rt:type,"
+ "'isis:isis')" {
description
"This augments the IS-IS routing protocol when used.";
}
description
"This augments the IS-IS protocol LSDB prefix.";
uses prefix-sid-sub-tlv;
}
augment "/rt:routing/"
+ "rt:control-plane-protocols/rt:control-plane-protocol"
+ "/isis:isis/isis:database/isis:levels/isis:lsp"
+ "/isis:mt-ipv6-reachability/isis:prefixes" {
when "derived-from-or-self(../../../../../../rt:type,"
+ "'isis:isis')" {
description
"This augments the IS-IS routing protocol when used.";
}
description
"This augments the IS-IS protocol LSDB prefix.";
uses prefix-sid-sub-tlv;
}
augment "/rt:routing/"
+ "rt:control-plane-protocols/rt:control-plane-protocol"
+ "/isis:isis/isis:database/isis:levels/isis:lsp" {
when "derived-from-or-self(../../../../rt:type,"
+ "'isis:isis')" {
description
"This augments the IS-IS routing protocol when used.";
}
description
"This augments the IS-IS protocol LSDB.";
container sid-binding-tlvs {
description
"List of SID/Label Binding TLVs.";
list sid-binding-tlv {
key "prefix";
description
"SID/Label Binding TLV, type 149.";
uses sid-binding-tlv;
}
}
container mt-sid-binding-tlvs {
description
"List of Multi-Topology SID/Label Binding TLVs.";
list mt-sid-binding-tlv {
key "prefix mt-id";
description
"Multi-Topology SID/Label Binding TLV, type 150.";
reference
"RFC 8667: IS-IS Extensions for Segment Routing,
Section 2.5";
uses sid-binding-tlv;
leaf mt-id {
type uint16;
description
"A 12-bit field containing the non-zero ID
of the topology.";
}
}
}
}
}<CODE ENDS>
Figure 1
4. Security Considerations 🔒✨
Okay bestie, this part is SERIOUS, so pay attention 💅 This section is modeled after the template described in Section 3.7 of [YANG-GUIDE].
The "ietf-isis-sr-mpls" YANG module is a data model built to be accessed through YANG-based management protocols like NETCONF [RFC6241] and RESTCONF [RFC8040]. These protocols (1) have to use a secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) have to use mutual authentication 🫶
The Network Configuration Access Control Model (NACM) [RFC8341] is the bouncer 🚪 It lets you restrict particular NETCONF or RESTCONF users to a preconfigured subset of all the available protocol operations and content. Main character energy for your access rules 👑
Now the scary part 😭 There are a bunch of data nodes in this module that are writable, creatable, and deletable (that's config true, which is the default). All writable data nodes are likely to be sensitive or vulnerable in some network environments. Write operations (like edit-config) and delete operations on these nodes without proper protection or authentication can seriously mess with network operations. The following subtrees and data nodes are the most sensitive or vulnerable:
/isis:isis/segment-routing/isis:isis/protocol-srgb/isis:isis/isis:interfaces/isis:interface/segment-routing/isis:isis/isis:interfaces/isis:interface/isis:fast-reroute/ti-lfa
The ability to disable or enable IS-IS SR support and/or change SR configurations can cause a Denial-of-Service (DoS) attack, since it may drop or misroute traffic. 💀 Please refer to Section 5 of [RFC8667] for more information on SR extensions 📖
Some of the readable data nodes in this module may be considered sensitive or vulnerable in some network environments, so it's really important to control read access to them (for example, via get, get-config, or notification). The following subtrees and data nodes are the ones to watch:
/isis:router-capabilities/sr-capability/isis:router-capabilities/sr-algorithms/isis:router-capabilities/local-blocks/isis:router-capabilities/srms-preference- and the augmentations to the IS-IS LSDB.
Unauthorized access to any data node in these subtrees can disclose the operational state information of the IS-IS protocol on a device. Nobody gets to snoop 🙈
There are no particularly sensitive RPC or action operations. Phew, a little break 🦋
5. IANA Considerations 🌈
The IANA has assigned one new URI in the "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-isis-sr-mpls
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespaceThis document also registers one new YANG module name in the "YANG Module Names" registry [RFC6020]:
Name: ietf-isis-sr-mpls
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-isis-sr-mpls
Prefix: isis-sr-mpls
Reference: RFC 99026. References 📚
6.1. Normative References
Okay these are the must-read ones 🧚 Here they are, verbatim:
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8102] Sarkar, P., Ed., Hegde, S., Bowers, C., Gredler, H., and
S. Litkowski, "Remote-LFA Node Protection and
Manageability", RFC 8102, DOI 10.17487/RFC8102, March
2017, <https://www.rfc-editor.org/info/rfc8102>.
[RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger,
"Common YANG Data Types for the Routing Area", RFC 8294,
DOI 10.17487/RFC8294, December 2017,
<https://www.rfc-editor.org/info/rfc8294>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", RFC 8349,
DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/info/rfc8349>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C.,
Bashandy, A., Gredler, H., and B. Decraene, "IS-IS
Extensions for Segment Routing", RFC 8667,
DOI 10.17487/RFC8667, December 2019,
<https://www.rfc-editor.org/info/rfc8667>.
[RFC9020] Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J.
Tantsura, "YANG Data Model for Segment Routing", RFC 9020,
DOI 10.17487/RFC9020, May 2021,
<https://www.rfc-editor.org/info/rfc9020>.
[RFC9130] Litkowski, S., Ed., Yeung, D., Lindem, A., Zhang, J., and
L. Lhotka, "YANG Data Model for the IS-IS Protocol",
RFC 9130, DOI 10.17487/RFC9130, October 2022,
<https://www.rfc-editor.org/info/rfc9130>.
[RFC9855] Bashandy, A., Litkowski, S., Filsfils, C., Francois, P.,
Decraene, B., and D. Voyer, "Topology Independent Fast
Reroute Using Segment Routing", RFC 9855,
DOI 10.17487/RFC9855, October 2025,
<https://www.rfc-editor.org/info/rfc9855>.6.2. Informative References
And these are the extra-credit reads 🍓
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
January 2006, <https://www.rfc-editor.org/info/rfc4252>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[YANG-GUIDE]
Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for
Authors and Reviewers of Documents Containing YANG Data
Models", Work in Progress, Internet-Draft, draft-ietf-
netmod-rfc8407bis-28, 5 June 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
rfc8407bis-28>.Appendix A. A Configuration Example ✨
Okay bestie, time for the fun part 🎀 Here's an XML example using the IS-IS SR MPLS YANG module we just defined 💅
Note: '' line wrapping per [RFC8792].
<?xml version='1.0' encoding='UTF-8'?>
<interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
<interface>
<name>eth0</name>
<admin-status>up</admin-status>
<oper-status>up</oper-status>
<if-index>1</if-index>
<statistics>
<discontinuity-time>2024-10-27T14:30:00Z</discontinuity-time>
</statistics>
</interface>
</interfaces>
<routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
<router-id>1.1.1.1</router-id>
<control-plane-protocols>
<control-plane-protocol>
<type xmlns:isis="urn:ietf:params:xml:ns:yang:ietf-isis">\
isis:isis</type>
<name>isis</name>
<isis xmlns="urn:ietf:params:xml:ns:yang:ietf-isis">
<system-id>1111.2222.3333</system-id>
<area-address>49.0001.0000.0000.0001</area-address>
<interfaces>
<interface>
<name>eth0</name>
<segment-routing xmlns="urn:ietf:params:xml:ns:yang:\
ietf-isis-sr-mpls">
<adjacency-sid>
<adj-sids>
<value>38888</value>
<neighbor-system-id>4444.5555.6666\
</neighbor-system-id>
</adj-sids>
</adjacency-sid>
</segment-routing>
</interface>
</interfaces>
<segment-routing xmlns="urn:ietf:params:xml:ns:yang:\
ietf-isis-sr-mpls">
<enabled>true</enabled>
</segment-routing>
<protocol-srgb xmlns="urn:ietf:params:xml:ns:yang:\
ietf-isis-sr-mpls">
<srgb>
<lower-bound>4000</lower-bound>
<upper-bound>5000</upper-bound>
</srgb>
</protocol-srgb>
</isis>
</control-plane-protocol>
</control-plane-protocols>
</routing>Now the same example, but for my JSON fans 🧚 It's the exact same config, just in JSON clothes 🌸
{
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "eth0",
"admin-status": "up",
"oper-status": "up",
"if-index": 1,
"statistics": {
"discontinuity-time": "2024-10-27T07:30:00-07:00"
}
}
]
},
"ietf-routing:routing": {
"router-id": "1.1.1.1",
"control-plane-protocols": {
"control-plane-protocol": [
{
"type": "ietf-isis:isis",
"name": "isis",
"ietf-isis:isis": {
"system-id": "1111.2222.3333",
"area-address": [
"49.0001.0000.0000.0001"
],
"interfaces": {
"interface": [
{
"name": "eth0",
"ietf-isis-sr-mpls:segment-routing": {
"adjacency-sid": {
"adj-sids": [
{
"value": 38888,
"neighbor-system-id": "4444.5555.6666"
}
]
}
}
}
]
},
"ietf-isis-sr-mpls:segment-routing": {
"enabled": true
},
"ietf-isis-sr-mpls:protocol-srgb": {
"srgb": [
{
"lower-bound": 4000,
"upper-bound": 5000
}
]
}
}
}
]
}
}
}Appendix B. IS-IS MPLS Segment Routing Module Tree ✨
okay so this is the big family tree of the "ietf-isis-sr-mpls" YANG module 🌳 it shows how everything nests together, from the segment routing container at the top all the way down to the little sid-binding stuff at the bottom 💜
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/isis:isis:
+--rw segment-routing
| +--rw enabled? boolean
| +--rw bindings {mapping-server}?
| +--rw advertise
| | +--rw policies* leafref
| +--rw receive? boolean
+--rw protocol-srgb {sr-mpls:protocol-srgb}?
+--rw srgb* [lower-bound upper-bound]
+--rw lower-bound uint32
+--rw upper-bound uint32
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/isis:isis/isis:interfaces
/isis:interface:
+--rw segment-routing
+--rw adjacency-sid
+--rw adj-sids* [value]
| +--rw value-type? enumeration
| +--rw value uint32
| +--rw protected? boolean
| +--rw weight? uint8
| +--rw neighbor-system-id isis:system-id
+--rw advertise-adj-group-sid* [group-id]
| +--rw group-id uint32
+--rw advertise-protection? enumeration
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/isis:isis/isis:interfaces
/isis:interface/isis:fast-reroute/isis:lfa:
+--rw ti-lfa {ti-lfa}?
+--rw enabled? boolean
+--rw selection-tie-breakers
+--rw node-protection!
| +--rw priority? uint8
+--rw srlg-disjoint!
+--rw priority? uint8
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/isis:isis/isis:interfaces
/isis:interface/isis:fast-reroute/isis:lfa/isis:level-1:
+--rw ti-lfa {ti-lfa}?
+--rw enabled? boolean
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/isis:isis/isis:interfaces
/isis:interface/isis:fast-reroute/isis:lfa/isis:level-2:
+--rw ti-lfa {ti-lfa}?
+--rw enabled? boolean
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/isis:isis/isis:interfaces
/isis:interface/isis:fast-reroute/isis:lfa
/isis:remote-lfa:
+--rw use-segment-routing-path? boolean {remote-lfa-sr}?
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/isis:isis/isis:interfaces
/isis:interface/isis:adjacencies/isis:adjacency:
+--ro adjacency-sid* []
+--ro value? uint32
+--ro address-family? iana-rt-types:address-family
+--ro weight? uint8
+--ro protection-requested? boolean
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/isis:isis/isis:database
/isis:levels/isis:lsp/isis:router-capabilities
/isis:router-capability:
+--ro sr-capability
| +--ro sr-capability-flag* identityref
| +--ro global-blocks
| +--ro global-block* []
| +--ro range-size? rt-types:uint24
| +--ro (sid)?
| +--:(sid-label)
| | +--ro label-value? uint32
| +--:(sid-index)
| +--ro index-value? uint32
+--ro sr-algorithms
| +--ro sr-algorithm* identityref
+--ro local-blocks
| +--ro local-block* []
| +--ro range-size? rt-types:uint24
| +--ro (sid)?
| +--:(sid-label)
| | +--ro label-value? uint32
| +--:(sid-index)
| +--ro index-value? uint32
+--ro srms-preference
+--ro preference? uint8
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/isis:isis/isis:database
/isis:levels/isis:lsp/isis:extended-is-neighbor
/isis:neighbor/isis:instances/isis:instance:
+--ro adj-sid-sub-tlvs
+--ro adj-sid-sub-tlv* []
+--ro adj-sid-flags
| +--ro flag* identityref
+--ro weight? uint8
+--ro neighbor-id? isis:system-id
+--ro (sid)?
+--:(sid-label)
| +--ro label-value? uint32
+--:(sid-index)
+--ro index-value? uint32
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/isis:isis/isis:database
/isis:levels/isis:lsp/isis:mt-is-neighbor/isis:neighbor
/isis:instances/isis:instance:
+--ro adj-sid-sub-tlvs
+--ro adj-sid-sub-tlv* []
+--ro adj-sid-flags
| +--ro flag* identityref
+--ro weight? uint8
+--ro neighbor-id? isis:system-id
+--ro (sid)?
+--:(sid-label)
| +--ro label-value? uint32
+--:(sid-index)
+--ro index-value? uint32
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/isis:isis/isis:database
/isis:levels/isis:lsp/isis:extended-ipv4-reachability
/isis:prefixes:
+--ro prefix-sid-sub-tlvs
+--ro prefix-sid-sub-tlv* []
+--ro prefix-sid-flags
| +--ro flag* identityref
+--ro algorithm? identityref
+--ro (sid)?
+--:(sid-label)
| +--ro label-value? uint32
+--:(sid-index)
+--ro index-value? uint32
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/isis:isis/isis:database
/isis:levels/isis:lsp/isis:mt-extended-ipv4-reachability
/isis:prefixes:
+--ro prefix-sid-sub-tlvs
+--ro prefix-sid-sub-tlv* []
+--ro prefix-sid-flags
| +--ro flag* identityref
+--ro algorithm? identityref
+--ro (sid)?
+--:(sid-label)
| +--ro label-value? uint32
+--:(sid-index)
+--ro index-value? uint32
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/isis:isis/isis:database
/isis:levels/isis:lsp/isis:ipv6-reachability
/isis:prefixes:
+--ro prefix-sid-sub-tlvs
+--ro prefix-sid-sub-tlv* []
+--ro prefix-sid-flags
| +--ro flag* identityref
+--ro algorithm? identityref
+--ro (sid)?
+--:(sid-label)
| +--ro label-value? uint32
+--:(sid-index)
+--ro index-value? uint32
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/isis:isis/isis:database
/isis:levels/isis:lsp/isis:mt-ipv6-reachability
/isis:prefixes:
+--ro prefix-sid-sub-tlvs
+--ro prefix-sid-sub-tlv* []
+--ro prefix-sid-flags
| +--ro flag* identityref
+--ro algorithm? identityref
+--ro (sid)?
+--:(sid-label)
| +--ro label-value? uint32
+--:(sid-index)
+--ro index-value? uint32
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/isis:isis/isis:database
/isis:levels/isis:lsp:
+--ro sid-binding-tlvs
| +--ro sid-binding-tlv* [prefix]
| +--ro prefix inet:ip-prefix
| +--ro range? uint16
| +--ro sid-binding-flags
| | +--ro flag* identityref
| +--ro prefix-sid-sub-tlvs* []
| | +--ro prefix-sid-sub-tlvs
| | +--ro prefix-sid-sub-tlv* []
| | +--ro prefix-sid-flags
| | | +--ro flag* identityref
| | +--ro algorithm? identityref
| | +--ro (sid)?
| | +--:(sid-label)
| | | +--ro label-value? uint32
| | +--:(sid-index)
| | +--ro index-value? uint32
| +--ro sid-sub-tlv* []
| | +--ro (sid)?
| | +--:(sid-label)
| | | +--ro label-value? uint32
| | +--:(sid-index)
| | +--ro index-value? uint32
| +--ro unknown-tlvs
| +--ro unknown-tlv* []
| +--ro type? uint16
| +--ro length? uint16
| +--ro value? yang:hex-string
+--ro mt-sid-binding-tlvs
+--ro mt-sid-binding-tlv* [prefix mt-id]
+--ro prefix inet:ip-prefix
+--ro range? uint16
+--ro sid-binding-flags
| +--ro flag* identityref
+--ro prefix-sid-sub-tlvs* []
| +--ro prefix-sid-sub-tlvs
| +--ro prefix-sid-sub-tlv* []
| +--ro prefix-sid-flags
| | +--ro flag* identityref
| +--ro algorithm? identityref
| +--ro (sid)?
| +--:(sid-label)
| | +--ro label-value? uint32
| +--:(sid-index)
| +--ro index-value? uint32
+--ro sid-sub-tlv* []
| +--ro (sid)?
| +--:(sid-label)
| | +--ro label-value? uint32
| +--:(sid-index)
| +--ro index-value? uint32
+--ro unknown-tlvs
| +--ro unknown-tlv* []
| +--ro type? uint16
| +--ro length? uint16
| +--ro value? yang:hex-string
+--ro mt-id uint16Acknowledgements 🫶
bestie, the authors gave a huge shoutout to Pushpasis Sarkar, Derek Yeung, and Yi Yang 💖 for their major contributions to the document ✨
Big thanks also to Reshad Rahman, Tom Petch, and Renato Westphal 🎀 for their thorough reviews and helpful comments 💅
The authors also wanted to thank Mohamed Boucadair and Ketan Talaulikar 👑 for their extensive AD reviews for the IESG Telechat 🌸 and a thank you to Éric Vyncke and Mahesh Jethanandani 🦋 for their review comments 🥹
Authors' Addresses 💌
Stephane Litkowski Cisco Systems Email: slitkows.ietf@gmail.com
Yingzhen Qu Futurewei Technologies Email: yingzhen.ietf@gmail.com
Acee Lindem LabN Consulting, L.L.C. Email: acee.ietf@gmail.com
Ing-Wher Chen Red Hat, Inc. Email: ichen@redhat.com
Jeff Tantsura Nvidia Email: jefftant.ietf@gmail.com
📦 where this page comes from
- ietf: rfc9902 2025-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms