RFC 8667

IS-IS Extensions for Segment Routing

📅 published December 2019, from ietf

RFC 8667: IS-IS Extensions for Segment Routing 🎀

okay so this is an official IETF Standards Track spec 💅 It's authored by S. Previdi (Ed., Huawei Technologies), L. Ginsberg (Ed.), C. Filsfils (Cisco Systems, Inc.), A. Bashandy (Arrcus), H. Gredler (RtBrick Inc.), and B. Decraene (Orange). It was published in December 2019 with ISSN 2070-1721, and the header doesn't list anything it obsoletes or updates, so it stands on its own 🦋

Abstract ✨

okay so Segment Routing (SR) lets you define end-to-end paths through IGP topologies by describing each path as a chain of smaller topological sub-paths, called "segments" 🧚 The link-state routing protocols (IS-IS and OSPF) advertise these segments.

This document is the one that covers the IS-IS extensions you need for Segment Routing running on an MPLS data plane 💖

Status of This Memo ✨

this is an Internet Standards Track document 🔥

it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check out Section 2 of RFC 7841 📚

for the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8667 💜

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. please actually read those, bestie, because they spell out your rights and restrictions for this document 🙈

any Code Components pulled out of this document have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as described in the Simplified BSD License 🫶

Table of Contents

1.  Introduction
  1.1.  Requirements Language
2.  Segment Routing Identifiers
  2.1.  Prefix Segment Identifier (Prefix-SID) Sub-TLV
    2.1.1.  Flags
    2.1.2.  Prefix-SID Propagation
  2.2.  Adjacency Segment Identifier
    2.2.1.  Adjacency Segment Identifier (Adj-SID) Sub-TLV
    2.2.2.  Adjacency Segment Identifier (LAN-Adj-SID) Sub-TLV
  2.3.  SID/Label Sub-TLV
  2.4.  SID/Label Binding TLV
    2.4.1.  Flags
    2.4.2.  Range
    2.4.3.  Prefix Length, Prefix
    2.4.4.  Mapping Server Prefix-SID
    2.4.5.  SID/Label Sub-TLV
    2.4.6.  Example Encodings
  2.5.  Multi-Topology SID/Label Binding TLV
3.  Router Capabilities
  3.1.  SR-Capabilities Sub-TLV
  3.2.  SR-Algorithm Sub-TLV
  3.3.  SR Local Block Sub-TLV
  3.4.  SRMS Preference Sub-TLV
4.  IANA Considerations
  4.1.  Sub-TLVs for Types 22, 23, 25, 141, 222, and 223
  4.2.  Sub-TLVs for Types 135, 235, 236, and 237
  4.3.  Sub-TLVs for Type 242
  4.4.  New TLV Codepoint and Sub-TLV Registry
5.  Security Considerations
6.  References
  6.1.  Normative References
  6.2.  Informative References
Acknowledgements
Contributors
Authors' Addresses

1. Introduction ✨

okay the vibe here is: SR lets you build flexible end-to-end paths inside IGP topologies by stacking up "segments," and those segments get advertised by IS-IS and OSPF 🦋

prefix segments are ECMP-aware shortest paths to a prefix (or a node), based on the current state of the IGP topology. adjacency segments are a single hop over one specific adjacency between two nodes in the IGP. a prefix segment is usually a multi-hop path, while an adjacency segment is, in most cases, a one-hop path 💅

the SR control plane works for both IPv6 and MPLS data planes, and it doesn't need any extra signaling beyond the regular IGP. so in MPLS networks, SR paths don't need LDP or RSVP-TE signaling. and SR can still play nice with Label Switched Paths (LSPs) that were set up with RSVP or LDP 🫶

there are other segment types too, like the Binding SID from [RFC8402]. this document also defines an advertisement for one kind of Binding SID: the Mirror Context segment 🌈

the big picture is the same as before: this doc describes the IS-IS extensions needed for Segment Routing on an MPLS data plane ✨

the SR architecture lives in [RFC8402], and SR use cases are in [RFC7855] 📚

1.1. Requirements Language

okay so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document get read as described in BCP 14 [RFC2119] [RFC8174], but only when they're written in all capitals, exactly like that 🎀

2. Segment Routing Identifiers 🧚

the SR architecture in [RFC8402] defines a bunch of different Segment Identifiers (SIDs) 💖 this doc gives you the IS-IS encodings for the IGP-Prefix Segment, the IGP-Adjacency Segment, the IGP-LAN-Adjacency Segment, and the Binding Segment 🌸

2.1. Prefix Segment Identifier (Prefix-SID) Sub-TLV

we're introducing a brand new IS-IS sub-TLV here: the Prefix Segment Identifier (Prefix-SID) sub-TLV 🎀

this sub-TLV carries the Segment Routing IGP-Prefix-SID from [RFC8402]. the 'Prefix-SID' MUST be unique within a given IGP domain (when the L-Flag is not set) 👑

a Prefix-SID sub-TLV is tied to a prefix that a node advertises, and it MAY show up in any of these TLVs:

  • TLV-135 (Extended IPv4 reachability) defined in [RFC5305].
  • TLV-235 (Multi-topology IPv4 Reachability) defined in [RFC5120].
  • TLV-236 (IPv6 IP Reachability) defined in [RFC5308].
  • TLV-237 (Multi-topology IPv6 IP Reachability) defined in [RFC5120].

the Binding TLV and the Multi-Topology Binding TLV get their own sections: 2.4 and 2.5, respectively 🦋

here's the Prefix-SID sub-TLV format, so you can see the whole layout at once 💅

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type        |     Length    |     Flags     |   Algorithm   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         SID/Index/Label (variable)            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

here's what each field means:

  • Type: 3
  • Length: 5 or 6, depending on the size of the SID (more on that below) 🌈
  • Flags: a 1-octet field of flags, laid out like this:
                 0 1 2 3 4 5 6 7
                +-+-+-+-+-+-+-+-+
                |R|N|P|E|V|L|   |
                +-+-+-+-+-+-+-+-+
  • R-Flag (Re-advertisement Flag): if set, the prefix this Prefix-SID is attached to was propagated by the router from another level (Level-1 to Level-2 or the reverse), or it came from redistribution (e.g., from another protocol) 🔥
  • N-Flag (Node-SID Flag): if set, the Prefix-SID points at the router identified by the prefix. usually the N-Flag is set on Prefix-SIDs attached to a router loopback address, and it's set when the Prefix-SID is a Node-SID as described in [RFC8402] 💖
  • P-Flag (No-PHP, No Penultimate Hop-Popping): if set, the penultimate hop MUST NOT pop the Prefix-SID before it delivers the packet to the node that advertised the Prefix-SID 🙈
  • E-Flag (Explicit NULL Flag): if set, any upstream neighbor of the Prefix-SID originator MUST replace the Prefix-SID with a Prefix-SID that has an Explicit NULL value (0 for IPv4 and 2 for IPv6) before forwarding the packet ✨
  • V-Flag (Value Flag): if set, the Prefix-SID carries a value instead of an index. by default this flag is UNSET 🧚
  • L-Flag (Local Flag): if set, the value/index carried by the Prefix-SID has local significance. by default this flag is UNSET 🌸
  • Other bits: MUST be zero when originated and ignored when received 🎀
  • Algorithm: routers can use different algorithms when they calculate reachability to other nodes or to the prefixes attached to those nodes. the algorithm identifiers are defined in Section 3.2. examples include metric-based Shortest Path First (SPF), various flavors of Constrained SPF, and so on. the Algorithm field of the Prefix-SID holds the identifier of the algorithm the router uses to compute reachability to the prefix that the Prefix-SID is associated with 👑

at origination, the Prefix-SID Algorithm field MUST be set to 0 or to any value advertised in the SR-Algorithm sub-TLV (see Section 3.2) 💅

if a router gets a Prefix-SID from a remote node, and the algorithm value is one that remote node never advertised in the SR-Algorithm sub-TLV (see Section 3.2), the router MUST ignore the Prefix-SID sub-TLV 😭

  • SID/Index/Label: as defined in Section 2.1.1.1. 🦋
the Prefix-SID section is kind of the core of the whole thing, so if you only read one part, make it this one 💜

when the Prefix-SID is an index (and the V-Flag is not set), the value gets used to figure out the actual label value inside the set of all advertised label ranges of a given router. that's how a receiving router builds the forwarding state toward a particular destination router 🫶

in lots of use cases, a "stable transport" address gets overloaded as the identifier for a node. since prefixes can be re-advertised into other levels, it can get ambiguous which node a particular IP prefix is the identifier for (like the originating router vs. the L1L2 router). the Prefix-SID sub-TLV has the flags it needs to clear up Prefix-to-node mappings. and if one node has several "stable transport" addresses, there are flags to tell them apart from other Prefixes advertised by that same node 🌈

2.1.1. Flags

2.1.1.1. V-Flag and L-Flag 💖

okay so the V-Flag tells you if the SID/Index/Label field is a value or an index 🎀

The L-Flag tells you if the value/index in that field has local or global significance 🌸

here are the valid combos, no cap 👑

  • The V-Flag and L-Flag are 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 using the encodings defined in Section 3.1.
  • The V-Flag and L-Flag are 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.

literally every other combo is invalid 🙈 so any SID advertisement that comes in with an invalid V-Flag and L-Flag setting MUST be ignored. no exceptions, bestie 💅

2.1.1.2. R-Flag and N-Flag 🦋

the R-Flag MUST be set for prefixes that are not local to the router and got advertised because of:

  • propagation (Level-1 into Level-2);
  • leaking (Level-2 into Level-1); or
  • redistribution (e.g., from another protocol).

ok plot twist 🍓 if a Level-1-2 router has local interface addresses configured in one level, it may also push those addresses into the other level. in that case, the Level-1-2 router MUST NOT set the R bit. slay the restraint 👑

the N-Flag is used to define a Node-SID 🧚 a router MAY set the N-Flag only if all of these are true:

  • The prefix the Prefix-SID is attached to is local to the router (i.e., the prefix is configured on one of the local interfaces, e.g., a 'stable transport' loopback).
  • The prefix the Prefix-SID is attached to has a Prefix length of either /32 (IPv4) or /128 (IPv6).

and if a router gets a Prefix-SID where the prefix length is NOT /32 (IPv4) or /128 (IPv6), the router MUST ignore the N-Flag on that Prefix-SID 🙅‍♀️

the Prefix Attribute Flags sub-TLV [RFC7794] also defines the N-Flag and R-Flag, with the same semantics as the equivalent flags in this document. whenever the Prefix Attribute Flags sub-TLV is present for a given prefix, the N-Flag and R-Flag values advertised in that sub-TLV MUST be used, and the values in a corresponding Prefix-SID sub-TLV (if present) MUST be ignored. that sub-TLV is the main character here 🌟

2.1.1.3. E-Flag and P-Flag 💜

the E-Flag and P-Flag decide what happens next, and it's giving pure drama 🎭 here's how it goes:

  • If the P-Flag is not set, then any upstream neighbor of the Prefix-SID originator MUST pop the Prefix-SID. This is equivalent to the "penultimate hop-popping" mechanism used in the MPLS data plane, which improves performance of the ultimate hop. MPLS EXP bits of the Prefix-SID are not preserved to the ultimate hop (the Prefix-SID being removed). If the P-Flag is unset, the received E-Flag is ignored.
  • If the P-Flag is set, then:
    • If the E-Flag is not set, then any upstream neighbor of the Prefix-SID originator MUST keep the Prefix-SID on top of the stack. This is useful when, e.g., the originator of the Prefix-SID must stitch the incoming packet into a continuing MPLS LSP to the final destination. This could occur at an inter-area border router (prefix propagation from one area to another) or at an interdomain border router (prefix propagation from one domain to another).
    • If the E-Flag is set, then any upstream neighbor of the Prefix-SID originator MUST replace the Prefix-SID with a Prefix-SID having an Explicit NULL value. This is useful, e.g., when the originator of the Prefix-SID is the final destination for the related prefix and the originator wishes to receive the packet with the original EXP bits. the originator gets to keep its EXP bits, iconic 🦋

when a router propagates a reachability advertisement from another IS-IS speaker (either Level-1 to Level-2 or Level-2 to Level-1), it MUST set the P-Flag and MUST clear the E-Flag of the related Prefix-SIDs 🫶

2.1.2. Prefix-SID Propagation 🌈

the Prefix-SID sub-TLV MUST be included when the associated Prefix Reachability TLV gets propagated across level boundaries 🚀

the Level-1-2 router that passes the Prefix-SID sub-TLV between levels keeps the content (flags and SID) the same, except as noted in Sections 2.1.1.2 and 2.1.1.3. so chill, it's consistent 🌸

2.2. Adjacency Segment Identifier 🔥

a new IS-IS sub-TLV is defined: the Adjacency Segment Identifier (Adj-SID) sub-TLV. it's the new it-girl 👑

the Adj-SID sub-TLV is an optional sub-TLV that carries the Segment Routing IGP-Adjacency-SID as defined in [RFC8402]. it also has flags and fields that future Segment Routing extensions might use to carry other types of SIDs 🧚

IS-IS adjacencies get advertised using one of these IS Neighbor TLVs:

  • TLV-22 (Extended IS reachability) [RFC5305]
  • TLV-222 (MT-ISN) [RFC5120]
  • TLV-23 (IS Neighbor Attribute) [RFC5311]
  • TLV-223 (MT IS Neighbor Attribute) [RFC5311]
  • TLV-141 (inter-AS reachability information) [RFC5316]

multiple Adj-SID sub-TLVs MAY be associated with a single IS Neighbor. the more the merrier 💖

2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV 🎀

the Adj-SID sub-TLV is laid out like this 🦋

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type        |     Length    |     Flags     |     Weight    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SID/Label/Index (variable)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:

  • Type: 31
  • Length: 5 or 6 depending on size of the SID
  • Flags: 1-octet field of the following flags:
                      0 1 2 3 4 5 6 7
                     +-+-+-+-+-+-+-+-+
                     |F|B|V|L|S|P|   |
                     +-+-+-+-+-+-+-+-+

where:

  • F-Flag: Address-Family Flag. If unset, then the Adj-SID is used when forwarding IPv4-encapsulated traffic to the neighbor. If set, then the Adj-SID is used when forwarding IPv6-encapsulated traffic to the neighbor.
  • B-Flag: Backup Flag. If set, the Adj-SID is eligible for protection (e.g., using IP Fast Reroute (IPFRR) or MPLS Fast Reroute (MPLS-FRR)) as described in [RFC8402].
  • V-Flag: Value Flag. If set, then the Adj-SID carries a value. By default, the flag is SET.
  • L-Flag: Local Flag. If set, then the value/index carried by the Adj-SID has local significance. By default, the flag is SET.
  • S-Flag: Set Flag. When set, the S-Flag indicates that the Adj-SID refers to a set of adjacencies (and therefore MAY be assigned to other adjacencies as well).
  • P-Flag: Persistent Flag. When set, the P-Flag indicates that the Adj-SID is persistently allocated, i.e., the Adj-SID value remains consistent across router restart and/or interface flap.
  • Other bits: MUST be zero when originated and ignored when received.
  • Weight: 1 octet. The value represents the weight of the Adj-SID for the purpose of load balancing. The use of the weight is defined in [RFC8402].
  • SID/Index/Label: as defined in Section 2.1.1.1.

ok the vibes for allocation 💅

  • An SR-capable router MAY allocate an Adj-SID for each of its adjacencies.
  • An SR-capable router MAY allocate more than one Adj-SID to an adjacency.
  • An SR-capable router MAY allocate the same Adj-SID to different adjacencies.

when the P-Flag is not set, the Adj-SID MAY be persistent. when the P-Flag is set, the Adj-SID MUST be persistent 🔒 no ghosting allowed 👻

examples of Adj-SID sub-TLV use are in [RFC8402], go binge them 🍿

the F-Flag is used so the router can advertise the outgoing encapsulation of the adjacency the Adj-SID is attached to 🫶

2.2.2. Adjacency Segment Identifier (LAN-Adj-SID) Sub-TLV 🌸

okay LAN era 🌊 on LAN subnetworks, the Designated Intermediate System (DIS) gets elected, and it originates the Pseudonode LSP (PN LSP) that includes all neighbors of the DIS 👑

when Segment Routing is used, each router in the LAN MAY advertise the Adj-SID of each of its neighbors. since routers on LANs only advertise one adjacency to the DIS (and don't advertise any other adjacency), each router puts its set of Adj-SIDs (one for each neighbor) inside a newly defined sub-TLV. that sub-TLV lives inside the TLV that advertises the adjacency to the DIS (e.g., TLV-22) 🧚

the new sub-TLV is the LAN Adjacency Segment Identifier (LAN-Adj-SID), which holds the set of Adj-SIDs the router assigned to each of its LAN neighbors 🦋

the LAN-Adj-SID sub-TLV is formatted like this:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type        |     Length    |      Flags    |    Weight     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Neighbor System-ID (ID length octets)        |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   SID/Label/Index (variable)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:

  • Type: 32
  • Length: Variable
  • Flags: 1-octet field of the following flags:
                      0 1 2 3 4 5 6 7
                     +-+-+-+-+-+-+-+-+
                     |F|B|V|L|S|P|   |
                     +-+-+-+-+-+-+-+-+

where the F-Flag, B-Flag, V-Flag, L-Flag, S-Flag, and P-Flag are defined in Section 2.2.1.

  • Other bits: MUST be zero when originated and ignored when received.
  • Weight: 1 octet. The value represents the weight of the Adj-SID for the purpose of load balancing. The use of the weight is defined in [RFC8402].
  • Neighbor System-ID: IS-IS System-ID of length "ID Length" as defined in [ISO10589].
  • SID/Index/Label: As defined in Section 2.1.1.1.

multiple LAN-Adj-SID sub-TLVs MAY be encoded 🌈

note that this sub-TLV MUST NOT appear in TLV 141. not in my house 🙅‍♀️

if TLV-22, TLV-23, TLV-222, or TLV-223 (the ones reporting the adjacency to the DIS) can't hold the whole set of LAN-Adj-SID sub-TLVs, then multiple advertisements of the adjacency to the DIS MUST be used, and all of those advertisements MUST have the same metric. consistency is everything 💜

each router in the level can rebuild the LAN topology 🗺️ by receiving the DIS PN LSP and the non-PN LSP of each router in the LAN. that means it can also work out the set of Adj-SIDs each router uses for each of its neighbors. big brain energy 🧠✨

2.3. SID/Label Sub-TLV 🎀

Okay so the SID/Label sub-TLV can show up in these spots in this doc 💅:

  • SR-Capabilities sub-TLV (Section 3.1)
  • SR Local Block sub-TLV (Section 3.3)
  • SID/Label Binding TLV (Section 2.4)
  • Multi-Topology SID/Label Binding TLV (Section 2.5)

Bestie, the codepoint in all four cases is the SID/Label sub-TLV codepoint from the brand-new "sub-TLVs for TLV 149 and 150" registry this doc creates 🦋.

The SID/Label sub-TLV holds either a SID or an MPLS label ✨. Here's the layout:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type        |     Length    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          SID/Label (variable)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where:

  • Type: 1
  • Length: 3 or 4. If the length is set to 3, then the 20 rightmost bits represent an MPLS label. If the length is set to 4, then the value is a 32-bit index. 🍓

2.4. SID/Label Binding TLV 💖

The SID/Label Binding TLV MAY be originated by any router in an IS-IS domain, and it has a few different jobs 🌈.

The first one: it can advertise prefix-to-SID mappings. That functionality is called the Segment Routing Mapping Server (SRMS) 👑, and its behaviour is defined in [RFC8661].

The second one: it can also advertise a Mirror SID. That signals a node's ability to process traffic that was originally destined to another IGP node 🙈. This behaviour is defined in [RFC8402].

Here's the format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Type     |     Length    |     Flags     |     RESERVED  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Range              | Prefix Length |     Prefix    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //               Prefix (continued, variable)                  //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Sub-TLVs (variable)                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where:

  • Type: 149
  • Length: Variable
  • Flags: 1 octet
  • RESERVED: 1 octet (SHOULD be transmitted as 0 and MUST be ignored on receipt)
  • Range: 2 octets
  • Prefix Length: 1 octet
  • Prefix: 0-16 octets
  • sub-TLVs, where each sub-TLV consists of a sequence of:
    • 1 octet of sub-TLV type
    • 1 octet of length of the value field of the sub-TLV
    • 0-243 octets of value

2.4.1. Flags 🦋

Flags is a 1-octet field with these flags:

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |F|M|S|D|A|     |
   +-+-+-+-+-+-+-+-+

Where:

  • F-Flag: Address-Family Flag. If unset, then the prefix carries an IPv4 prefix. If set, then the prefix carries an IPv6 prefix. 🌸
  • M-Flag: Mirror Context Flag. Set if the advertised SID corresponds to a mirrored context. The use of a mirrored context is described in [RFC8402].
  • S-Flag: If set, the SID/Label Binding TLV SHOULD be flooded across the entire routing domain. If the S-Flag is not set, the SID/Label Binding TLV MUST NOT be leaked between levels. This bit MUST NOT be altered during the TLV leaking. 🔥
  • D-Flag: When the SID/Label Binding TLV is leaked from Level-2 to Level-1, the D-Flag MUST be set. Otherwise, this flag MUST be clear. SID/Label Binding TLVs with the D-Flag set MUST NOT be leaked from Level-1 to Level-2. This is to prevent TLV looping across levels. 🌀
  • A-Flag: Attached Flag. The originator of the SID/Label Binding TLV MAY set the A bit in order to signal that the prefixes and SIDs advertised in the SID/Label Binding TLV are directly connected to their originators. The mechanisms through which the originator of the SID/Label Binding TLV can figure out if a prefix is attached or not are outside the scope of this document (e.g., through explicit configuration). If the Binding TLV is leaked to other areas/levels, the A-Flag MUST be cleared. ✨

An implementation may decide not to honor the S-Flag in order to not leak Binding TLVs between levels (for policy reasons). That's totally its call 💅.

Other bits: MUST be zero when originated and ignored when received.

2.4.2. Range 🌈

The Range field gives you the ability to specify a range of addresses and their associated Prefix-SIDs. This advertisement supports the SRMS functionality. It's basically a compression scheme 🗜️: it distributes a continuous prefix and its continuous, corresponding SID/Label Block in one go, which is so efficient it's giving main character energy ⭐.

If a single SID is advertised, then the Range field MUST be set to one. For range advertisements greater than 1, the Range field MUST be set to the number of addresses that need to be mapped into a Prefix-SID. In either case, the prefix is the first address to which a SID is to be assigned.

2.4.3. Prefix Length, Prefix 🧚

The Prefix represents the Forwarding Equivalence Class at the tail end of the advertised path. The Prefix does not need to correspond to a routable prefix of the originating node. Not every prefix has to be routable, bestie 🫶.

The Prefix Length field contains the length of the prefix in bits. Only the most significant octets of the prefix are encoded (i.e., 1 octet for prefix length 1 up to 8, 2 octets for prefix length 9 to up 16, 3 octets for prefix length 17 up to 24, 4 octets for prefix length 25 up to 32, ...., and 16 octets for prefix length 113 up to 128).

2.4.4. Mapping Server Prefix-SID 🎀

The Prefix-SID sub-TLV is defined in Section 2.1 and contains the SID/Index/Label value associated with the prefix and range. The Prefix-SID sub-TLV MUST be present in the SID/Label Binding TLV when the M-Flag is clear. The Prefix-SID sub-TLV MUST NOT be present when the M-Flag is set.

2.4.4.1. Prefix-SID Flags 💜

The Prefix-SID Flags are defined in Section 2.1. The Mapping Server MAY advertise a mapping with the N-Flag set when the prefix being mapped is known in the link-state topology with a mask length of 32 (IPv4) or 128 (IPv6) and when the prefix represents a node. The mechanisms through which the operator defines that a prefix represents a node are outside the scope of this document (typically it will be through configuration) 🛠️.

The other flags defined in Section 2.1 are not used by the Mapping Server and MUST be ignored at reception.

2.4.4.2. PHP Behavior when Using Mapping Server Advertisements 🦋

As the Mapping Server does not specify the originator of a prefix advertisement, it is not possible to determine PHP behaviour solely based on the Mapping Server Advertisement. However, if additional information is available, PHP behaviour may safely be done. The required information consists of:

  • A prefix reachability advertisement for the prefix has been received, which includes the Prefix Attribute Flags sub-TLV [RFC7794].
  • X-Flag and R-Flag are both set to 0 in the Prefix Attribute Flags sub-TLV.

In the absence of a Prefix Attribute Flags sub-TLV [RFC7794], the A-Flag in the Binding TLV indicates that the originator of a prefix reachability advertisement is directly connected to the prefix; thus, PHP MUST be done by the neighbors of the router originating the prefix reachability advertisement. Note that the A-Flag is only valid in the original area in which the Binding TLV is advertised. 🙈

2.4.4.3. Prefix-SID Algorithm 🌸

The Algorithm field contains the identifier of the algorithm associated with the SIDs for the prefix(es) in the range. Use of the Algorithm field is described in Section 2.1.

2.4.5. SID/Label Sub-TLV 🍓

The SID/Label sub-TLV (Type: 1) contains the SID/Label value as defined in Section 2.3. It MUST be present in the SID/Label Binding TLV when the M-Flag is set in the Flags field of the parent TLV. 🫶

2.4.6. Example Encodings ✨

okay bestie, time for the examples 🧚 these are the ones that make it all click, I promise 💖

Example 1 🍓: say we want these IPv4 router addresses (loopback addresses) mapped to the matching Prefix-SID indexes:

Router-A: 192.0.2.1/32, Prefix-SID: Index 1

Router-B: 192.0.2.2/32, Prefix-SID: Index 2

Router-C: 192.0.2.3/32, Prefix-SID: Index 3

Router-D: 192.0.2.4/32, Prefix-SID: Index 4

and the encoding looks like this 👀

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      Type     |     Length    |0|0|0|0|0|     |     RESERVED  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Range = 4          |        32     |      192      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        0      |         2     |        1      |Prefix-SID Type|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Sub-TLV Length|     Flags     |   Algorithm   |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                             1 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Example 2 🌸: this time we're mapping these IPv4 prefixes to their Prefix-SID indexes:

10.1.1/24, Prefix-SID: Index 51

10.1.2/24, Prefix-SID: Index 52

10.1.3/24, Prefix-SID: Index 53

10.1.4/24, Prefix-SID: Index 54

10.1.5/24, Prefix-SID: Index 55

10.1.6/24, Prefix-SID: Index 56

10.1.7/24, Prefix-SID: Index 57

and the encoding 🦋

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      Type     |     Length    |0|0|0|0|0|     |     RESERVED  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Range = 7          |        24     |      10       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        1      |         1     |Prefix-SID Type| Sub-TLV Length|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    Flags      | Algorithm     |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                           51  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Example 3 💜: now IPv6 prefixes, mapped to indexes 151 through 154:

2001:db8:1/48, Prefix-SID: Index 151

2001:db8:2/48, Prefix-SID: Index 152

2001:db8:3/48, Prefix-SID: Index 153

2001:db8:4/48, Prefix-SID: Index 154

and the encoding 🌈

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      Type     |     Length    |1|0|0|0|0|     |     RESERVED  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Range = 4          |        48     |     0x20      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |       0x01    |       0x0d    |       0xb8    |     0x00      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    0x01       |Prefix-SID Type| Sub-TLV Length|  Flags        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Algorithm     |                 0                             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |       151     |
  +-+-+-+-+-+-+-+-+

Real networks are messy 🙈, so a network operator won't be able to keep every Prefix/SID/Index mapping perfectly continuous. To support noncontinuous mapping ranges, an implementation MAY generate several instances of Binding TLVs.

For example, if a router wants to advertise these ranges:

Range 16:   { 192.0.2.1-15, Index 1-15 }

Range 6:    { 192.0.2.22-27, Index 22-27 }

Range 41:   { 192.0.2.44-84, Index 80-120 }

then a router would need to advertise three instances of the Binding TLV. three TLVs, bestie 🫶

2.5. Multi-Topology SID/Label Binding TLV ✨

the Multi-Topology SID/Label Binding TLV is what lets you support Multi-Topology IS-IS (M-ISIS) as defined in [RFC5120] 🦋 it has the same format as the SID/Label Binding TLV from Section 2.4, with one difference: a Multi-topology Identifier (MT ID), defined below 👇

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |     Length    |             MT ID             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Flags     |     RESERVED  |            Range              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |            Prefix (variable)                 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Sub-TLVs (variable)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:

  • Type is 150 🎀
  • Length is Variable
  • MT ID is the Multi-topology Identifier, which is laid out like this:
 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESVD |         MT ID         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • RESVD is the reserved bits. They MUST be reset on transmission and ignored on receive.
  • MT ID is a 12-bit field holding the non-zero ID of the topology being announced. The TLV MUST be ignored if the ID is zero. This is there to keep the view of the standard unicast topology consistent 🌸

The other fields and sub-TLVs are defined in Section 2.4 ✨

3. Router Capabilities ✨

this section defines sub-TLVs that get inserted into the IS-IS Router Capability, which is defined in [RFC7981] 💅

3.1. SR-Capabilities Sub-TLV

Segment Routing needs each router to advertise its SR data plane capability, plus the range of MPLS label values it uses for Segment Routing when global SIDs are allocated (aka global indexes) 🔥 the data plane capabilities and label ranges get advertised using the newly defined SR-Capabilities sub-TLV.

The Router Capability TLV has flags that control how it gets advertised. The SR-Capabilities sub-TLV MUST be propagated throughout the level and MUST NOT be advertised across level boundaries. so the Router Capability TLV distribution flags are set to match, i.e., the S-Flag in the Router Capability TLV [RFC7981] MUST be unset 🙅‍♀️

the SR-Capabilities sub-TLV looks like this:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Type        |     Length    |    Flags      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     Range                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 //                SID/Label Sub-TLV (variable)                 //
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:

  • Type is 2 🌷
  • Length is Variable
  • Flags is 1 octet of flags. The following are defined:
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|I|V|           |
+-+-+-+-+-+-+-+-+
  • I-Flag is the MPLS IPv4 Flag. If set, then the router is capable of processing SR-MPLS-encapsulated IPv4 packets on all interfaces.
  • V-Flag is the MPLS IPv6 Flag. If set, then the router is capable of processing SR-MPLS-encapsulated IPv6 packets on all interfaces.

One or more Segment Routing Global Block (SRGB) Descriptor entries show up too, and each one has this format:

  • Range is 3 octets
  • SID/Label sub-TLV is the MPLS label as defined in Section 2.3

The SID/Label sub-TLV holds the first value of the SRGB, while the range holds the number of SRGB elements. The range value MUST be higher than 0 🧁

The SR-Capabilities sub-TLV MAY be advertised in an LSP of any number, but a router MUST NOT advertise more than one SR-Capabilities sub-TLV. A router receiving multiple SR-Capabilities sub-TLVs from the same originator SHOULD select the first advertisement in the lowest-numbered LSP.

When multiple SRGB Descriptors are advertised, the entries define an ordered set of ranges that a SID index gets applied to. For this reason, changing the order the descriptors are advertised in will have a disruptive effect on forwarding. this part is so important ⚠️

When a router adds a new SRGB Descriptor to an existing SR-Capabilities sub-TLV, the new descriptor SHOULD add the newly configured block at the end of the sub-TLV and SHOULD NOT change the order of previously advertised blocks. Changing the order of the advertised descriptors will create label churn in the FIB and black hole / misdirect some traffic during the IGP convergence. In particular, if a range that is not the last is extended, it's preferable to add a new range rather than extending the previously advertised range. 💀

The originating router MUST ensure the order is unchanged after a graceful restart (using checkpointing, non-volatile storage, or any other mechanism). 🔒

The originating router MUST NOT advertise overlapping ranges.

When a router receives multiple overlapping ranges, it MUST conform to the procedures defined in [RFC8660] 📜

Here's an example of advertising multiple ranges 👀 the originating router advertises these ranges:

SR-Cap: range: 100, SID value: 100

SR-Cap: range: 100, SID value: 1000

SR-Cap: range: 100, SID value: 500

the receiving routers concatenate the ranges in the order they were received and build the SRGB like so:

SRGB = [100, 199]
       [1000, 1099]
       [500, 599]

and the indexes span multiple ranges:

   index 0   means label 100
   ...
   index 99  means label 199
   index 100 means label 1000
   index 199 means label 1099
   ...
   index 200 means label 500
   ...

3.2. SR-Algorithm Sub-TLV ✨

okay so routers can use different algorithms to figure out how to reach other nodes or the prefixes hanging off those nodes 🗺️ 💖 Some examples are metric-based SPF, different flavours of Constrained SPF, etc. The SR-Algorithm sub-TLV lets a router announce which algorithms it's currently using 📣 Algorithm values live in the "IGP Algorithm Type" registry defined in [RFC8665]. Right now, these values are defined:

  • 0: SPF algorithm based on link metric 🛣️ This is the classic shortest path algorithm, computed by the IS-IS Decision Process. Matching what link-state protocols already do in the real world, algorithm 0 lets any node overwrite the SPF path with a different one based on local policy 🫶
  • 1: Strict SPF algorithm based on link metric 🔒 It's basically identical to algorithm 0, but algorithm 1 requires that every node along the path honors the SPF routing decision. Local policy MUST NOT alter the forwarding decision computed by algorithm 1 at a node that claims to support algorithm 1 🙅‍♀️ very strict, very iconic

The Router Capability TLV carries flags that control how it gets advertised 💅 The SR-Algorithm MUST be propagated throughout the level and MUST NOT be advertised across level boundaries. So the Router Capability TLV distribution flags get set to match, meaning the S-Flag MUST be unset 🚧

The SR-Algorithm sub-TLV is optional 🌸 It MUST NOT be advertised more than once at a given level. If a router gets multiple SR-Algorithm sub-TLVs from the same originator, it SHOULD select the first advertisement in the lowest-numbered LSP 🎀

If the originating router doesn't advertise the SR-Algorithm sub-TLV, that implies algorithm 0 is the only algorithm supported by routers that support the extensions in this document 💜

When the originating router does advertise the SR-Algorithm sub-TLV, algorithm 0 MUST be present, while non-zero algorithms MAY be present 🦋

The SR-Algorithm sub-TLV looks like this:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type        |     Length    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Algorithm 1   |  Algorithm 2  | Algorithm ... |  Algorithm n  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:

  • Type: 19
  • Length: Variable
  • Algorithm: 1 octet of algorithm

3.3. SR Local Block Sub-TLV 🧚

The SR Local Block (SRLB) sub-TLV holds the range of labels the node has reserved for Local SIDs 🎀 Local SIDs get used for things like Adj-SIDs, and they can also be allocated by components other than IS-IS. For example, an application or a controller might tell the router to allocate a specific Local SID 🫢 So for those apps and controllers to know which Local SIDs are free on the router, it's required that the router advertises its SRLB 🔍

The SRLB sub-TLV does exactly that and looks like this:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type        |     Length    |    Flags      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Range                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                SID/Label Sub-TLV (variable)                 //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:

  • Type: 22
  • Length: Variable
  • Flags: 1 octet of flags. None are defined at this stage 🙃
  • One or more SRLB Descriptor entries, each with the following format:
    • Range: 3 octets
    • SID/Label sub-TLV: MPLS label as defined in Section 2.3

The SID/Label sub-TLV holds the first value of the SRLB, while the range holds the number of SRLB elements 💕 The range value MUST be higher than 0.

The SRLB sub-TLV MAY be advertised in an LSP of any number, but a router MUST NOT advertise more than one SRLB sub-TLV 🌈 If a router gets multiple SRLB sub-TLVs from the same originator, it SHOULD select the first advertisement in the lowest-numbered LSP.

The originating router MUST NOT advertise overlapping ranges 🚫

When a router receives multiple overlapping ranges, it MUST conform to the procedures defined in [RFC8660] 📜

It's super important that each time a SID from the SRLB gets allocated, it should also be reported to all the components (like a controller or applications). That way they all have an up-to-date view of the current SRLB allocation and don't accidentally step on each other's toes 💅

In the context of IS-IS, Local SIDs get reported through IS-IS sub-TLVs such as the Adj-SID 🦋 Allocated Local SIDs can also be reported through other means and protocols, which are outside the scope of this document 🌸

A router advertising the SRLB sub-TLV may also have other label ranges, outside the SRLB, for its own local allocation purposes. Those ranges are NOT advertised in the SRLB 🙈 For example, an Adj-SID can be allocated using a local label that isn't part of the SRLB 💜

3.4. SRMS Preference Sub-TLV 👑

The SRMS Preference sub-TLV associates a preference with SRMS advertisements coming from a particular source 🍓

The SRMS Preference sub-TLV looks like this:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type        |    Length     | Preference    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:

  • Type: 24
  • Length: 1
  • Preference: 1 octet and unsigned 8-bit SRMS preference

The SRMS Preference sub-TLV MAY be advertised in an LSP of any number, but a router MUST NOT advertise more than one SRMS Preference sub-TLV 🌷 If a router gets multiple SRMS Preference sub-TLVs from the same originator, it SHOULD select the first advertisement in the lowest-numbered LSP.

How the SRMS preference gets used during the SID selection process is described in [RFC8661] ✨

4. IANA Considerations 📋

Per this document, IANA has allocated the following TLVs and sub-TLVs 💖

4.1. Sub-TLVs for Types 22, 23, 25, 141, 222, and 223 🎀

This document makes the following registrations in the "Sub-TLVs for TLV 22, 23, 25, 141, 222, and 223" registry:

+------+--------------------+----+----+----+-----+-----+-----+
| Type | Description        | 22 | 23 | 25 | 141 | 222 | 223 |
+======+====================+====+====+====+=====+=====+=====+
|  31  | Adjacency Segment  | y  | y  | n  |  y  |  y  |  y  |
|      | Identifier         |    |    |    |     |     |     |
+------+--------------------+----+----+----+-----+-----+-----+
|  32  | LAN Adjacency      | y  | y  | n  |  y  |  y  |  y  |
|      | Segment Identifier |    |    |    |     |     |     |
+------+--------------------+----+----+----+-----+-----+-----+

                              Table 1

4.2. Sub-TLVs for Types 135, 235, 236, and 237 🦋

This document makes the following registrations in the "Sub-TLVs for TLV 135, 235, 236, and 237" registry:

+------+---------------------------+-----+-----+-----+-----+
| Type | Description               | 135 | 235 | 236 | 237 |
+======+===========================+=====+=====+=====+=====+
|  3   | Prefix Segment Identifier |  y  |  y  |  y  |  y  |
+------+---------------------------+-----+-----+-----+-----+

                             Table 2

4.3. Sub-TLVs for Type 242 🌈

This document makes the following registrations in the "Sub-TLVs for TLV 242" registry:

+------+------------------------------------+
| Type | Description                        |
+======+====================================+
|  2   | Segment Routing Capability         |
+------+------------------------------------+
|  19  | Segment Routing Algorithm          |
+------+------------------------------------+
|  22  | Segment Routing Local Block (SRLB) |
+------+------------------------------------+
|  24  | Segment Routing Mapping Server     |
|      | Preference (SRMS Preference)       |
+------+------------------------------------+

                      Table 3

4.4. New TLV Codepoint and Sub-TLV Registry 🧁

This document registers the following TLV:

+-------+----------------------------+-----+-----+-----+-------+
| Value | Name                       | IIH | LSP | SNP | Purge |
+=======+============================+=====+=====+=====+=======+
|  149  | Segment Identifier / Label |  n  |  y  |  n  |   n   |
|       | Binding                    |     |     |     |       |
+-------+----------------------------+-----+-----+-----+-------+
|  150  | Multi-Topology Segment     |  n  |  y  |  n  |   n   |
|       | Identifier / Label Binding |     |     |     |       |
+-------+----------------------------+-----+-----+-----+-------+

                               Table 4

This document creates the following sub-TLV Registry:

  • Name: Sub-TLVs for TLVs 149 and 150
  • Registration Procedure: Expert Review [RFC8126]
+-------+---------------------------+
|  Type |        Description        |
+=======+===========================+
|   0   | Reserved                  |
+-------+---------------------------+
|   1   | SID/Label                 |
+-------+---------------------------+
|   2   | Unassigned                |
+-------+---------------------------+
|   3   | Prefix Segment Identifier |
+-------+---------------------------+
| 4-255 | Unassigned                |
+-------+---------------------------+

                  Table 5

5. Security Considerations 🔐

With the extensions in this document, IS-IS carries information that gets used to program the MPLS data plane [RFC3031] 💻 In general, the same kinds of attacks that can be run against the IP/IPv6 control plane can also be run against the MPLS control plane, which ends up misrouting traffic in the respective data planes 😭 The MPLS side can be trickier to detect and isolate, so this is serious business, bestie 💀

Existing security extensions described in [RFC5304] and [RFC5310] apply to these Segment Routing extensions 🛡️

6. References 📚

6.1. Normative References 📚

okay so these are the docs you need to have open before RFC 8667 makes any sense 💅 each one is a required read for the IS-IS and segment routing stuff, and the whole thing kinda falls apart without them 😭

[ISO10589] International Organization for Standardization,
           "Information technology -- Telecommunications and
           information exchange between systems -- Intermediate
           system to Intermediate system intra-domain routeing
           information exchange protocol for use in conjunction with
           the protocol for providing the connectionless-mode network
           service (ISO 8473)", ISO/IEC 10589:2002, Second Edition,
           November 2002.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
           Label Switching Architecture", RFC 3031,
           DOI 10.17487/RFC3031, January 2001,
           <https://www.rfc-editor.org/info/rfc3031>.

[RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
           Topology (MT) Routing in Intermediate System to
           Intermediate Systems (IS-ISs)", RFC 5120,
           DOI 10.17487/RFC5120, February 2008,
           <https://www.rfc-editor.org/info/rfc5120>.

[RFC5304]  Li, T. and R. Atkinson, "IS-IS Cryptographic
           Authentication", RFC 5304, DOI 10.17487/RFC5304, October
           2008, <https://www.rfc-editor.org/info/rfc5304>.

[RFC5310]  Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
           and M. Fanto, "IS-IS Generic Cryptographic
           Authentication", RFC 5310, DOI 10.17487/RFC5310, February
           2009, <https://www.rfc-editor.org/info/rfc5310>.

[RFC7794]  Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and
           U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4
           and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794,
           March 2016, <https://www.rfc-editor.org/info/rfc7794>.

[RFC7981]  Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
           for Advertising Router Information", RFC 7981,
           DOI 10.17487/RFC7981, October 2016,
           <https://www.rfc-editor.org/info/rfc7981>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[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>.

[RFC8660]  Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
           Decraene, B., Litkowski, S., and R. Shakir, "Segment
           Routing with the MPLS Data Plane", RFC 8660,
           DOI 10.17487/RFC8660, December 2019,
           <https://www.rfc-editor.org/info/rfc8660>.

[RFC8661]  Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
           Decraene, B., and S. Litkowski, "Segment Routing MPLS
           Interworking with LDP", RFC 8661, DOI 10.17487/RFC8661,
           December 2019, <https://www.rfc-editor.org/info/rfc8661>.

[RFC8665]  Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler,
           H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
           Extensions for Segment Routing", RFC 8665,
           DOI 10.17487/RFC8665, December 2019,
           <https://www.rfc-editor.org/info/rfc8665>.

6.2. Informative References 🦋

these ones are the bonus reading, the "ooh, tell me more" stuff 🌸 not strictly required, but lowkey super helpful for getting the full picture ✨

[RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
           Engineering", RFC 5305, DOI 10.17487/RFC5305, October
           2008, <https://www.rfc-editor.org/info/rfc5305>.

[RFC5308]  Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
           DOI 10.17487/RFC5308, October 2008,
           <https://www.rfc-editor.org/info/rfc5308>.

[RFC5311]  McPherson, D., Ed., Ginsberg, L., Previdi, S., and M.
           Shand, "Simplified Extension of Link State PDU (LSP) Space
           for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009,
           <https://www.rfc-editor.org/info/rfc5311>.

[RFC5316]  Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
           Support of Inter-Autonomous System (AS) MPLS and GMPLS
           Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316,
           December 2008, <https://www.rfc-editor.org/info/rfc5316>.

[RFC7855]  Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
           Litkowski, S., Horneffer, M., and R. Shakir, "Source
           Packet Routing in Networking (SPRING) Problem Statement
           and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
           2016, <https://www.rfc-editor.org/info/rfc7855>.

[RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
           Writing an IANA Considerations Section in RFCs", BCP 26,
           RFC 8126, DOI 10.17487/RFC8126, June 2017,
           <https://www.rfc-editor.org/info/rfc8126>.

Acknowledgements 🫶

huge thank yous to Dave Ward, Dan Frost, Stewart Bryant, Pierre Francois, and Jesper Skrivers for their help shaping what's in this doc 💖 literally couldn't have done it without you all ✨

Contributors 💜

these people put in so much work on the content that they count as coauthors 🙌 the absolute MVPs 👑

Stephane Litkowski
Orange
France
Email: stephane.litkowski@orange.com

Jeff Tantsura
Apstra, Inc.
Email: jefftant@gmail.com

Peter Psenak
Cisco Systems Inc.
United States of America
Email: ppsenak@cisco.com

Martin Horneffer
Deutsche Telekom
Germany
Email: Martin.Horneffer@telekom.de

Wim Henderickx
Nokia
Belgium
Email: wim.henderickx@nokia.com

Edward Crabbe
Oracle
United States of America
Email: edward.crabbe@oracle.com

Rob Shakir
Google
United Kingdom
Email: robjs@google.com

Igor Milojevic
Individual
Serbia
Email: milojevicigor@gmail.com

Saku Ytti
TDC
Finland
Email: saku@ytti.fi

Authors' Addresses 🦋

and finally, the people who actually wrote this thing 🌈 here's how to reach each of them 💅

Stefano Previdi (editor)
Huawei Technologies
Italy

Email: stefano@previdi.net


Les Ginsberg (editor)
Cisco Systems, Inc.
United States of America

Email: ginsberg@cisco.com


Clarence Filsfils
Cisco Systems, Inc.
Brussels
Belgium

Email: cfilsfil@cisco.com


Ahmed Bashandy
Arrcus

Email: abashandy.ietf@gmail.com


Hannes Gredler
RtBrick Inc.

Email: hannes@rtbrick.com


Bruno Decraene
Orange
France

Email: bruno.decraene@orange.com
📦 where this page comes from