About segment routing

Segment routing can perform shortest path routing or source routing using the concept of abstract segment. A segment can represent the local prefix of a node, a specific adjacency of the node (interface or next hop), a service context, or a specific explicit path over the network. Each segment is identified by a Segment ID (SID).

With segment routing, the source router can define the end-to-end path for packets to reach a destination using an ordered list of segments represented by their SIDs. Each SID represents actions that subsequent nodes in the network execute, such as forwarding a packet to a specific destination or interface.

Unlike a typical Multiprotocol Label Switching (MPLS) architecture, a segment routing network does not require Label Distribution Protocol (LDP) or Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to set up tunnels. Instead, segment routing extensions to the IGP (such as IS-IS) provide support for allocation and signaling of SID information.


When segment routing is instantiated over the MPLS data plane (referred to as SR-MPLS), a SID is represented by a standard MPLS label or an index that maps to an MPLS label. To route a packet to a destination, the source router pushes onto the packet one or more MPLS labels representing the required SIDs. Each subsequent node forwards the packet based on the outer label, removes the outer label, and forwards the packet to the next segment on the path.

The MPLS data plane requires no modifications to support SR-MPLS.

Node SID

A prefix SID is a segment type that represents the ECMP-aware shortest path to reach a particular IP prefix from any IGP topology location. A node SID is a type of prefix SID that identifies a specific node in the IGP topology using a loopback address as the prefix. When a node SID is included in an MPLS label stack, it instructs the receiving node to forward the packet to the destination along the ECMP-aware shortest path determined by the IGP.

You allocate the node SIDs to use in the network in a similar fashion as the loopback IP addresses. Like all prefix SIDs, node SIDs must be unique within the domain, and are allocated in the form of an MPLS label (or index). The range of labels available for prefix and node SIDs is defined in the SRGB.


The Segment Routing Global Block (SRGB) defines the range of MPLS labels available for global segments, such as prefix and node SIDs. The SRGB is defined as one contiguous block of MPLS labels. Nokia strongly recommends using identical SRGBs on all nodes within the SR domain. The use of identical SRGBs simplifies troubleshooting because the same MPLS label represents the same prefix or node SID on each node.

The SRGB configuration is supported on the default network-instance only.


While the SRGB defines a range of MPLS labels for global segments, the Segment Routing Label Block (SRLB) defines a range of MPLS labels for local segments, such as adjacency SIDs. An adjacency SID is a segment type that represents an instruction to forward packets over a specific (one-hop) adjacency between two nodes in the IGP.

The SRLB is configurable per IGP protocol instance (on the default network-instance only). It is defined as one contiguous block of MPLS labels per IGP instance. SR Linux currently supports only one dynamic label block for the SRLB.

Note: Adjacency SID functionality is not supported in the current release. However, to enable segment routing on the IS-IS instance, you must configure a dynamic label block SRLB to reserve labels for future allocation of dynamic adjacency SIDs. Allocation of dynamic adjacency SIDs from this block is targeted for a future release.

For more information about MPLS and MPLS labels, see the SR Linux MPLS Guide.

IS-IS extensions for segment routing

IS-IS provides extensions to advertise segment routing specific TLVs. These TLVs allow IS-IS to advertise the SIDs in the domain for each segment.

Segment routing with IS-IS is also known as SR-ISIS. SR-ISIS refers to the segment routing extensions of the IS-IS IGP protocol and the forwarding entries created by those extensions.

With segment routing enabled on the IS-IS instance, IS-IS extensions can support TLVs to advertise IPv4/IPv6 prefix SIDs. The following new sub-TLVs are defined in RFC 8667 and are supported in the implementation of SR-ISIS:

  • prefix SID sub-TLV
  • SR-Capabilities sub-TLV
  • SR-Algorithm sub-TLV

In the current release, SR Linux advertises each configured prefix SID as a node SID.

The following sections describes the behaviors and limitations of the SR-ISIS TLV and sub-TLVs.

Router capability advertisement

In SR Linux, advertisement of the router capability TLV (TLV 242) with the segment routing related sub-TLVs is automatically enabled when segment routing is configured on the IS-IS instance. There is no explicit configuration to enable or disable router capability advertisement. The scope of segment routing capabilities is the entire IS-IS domain.

Origination of SR-Algorithm sub-TLVs

When SR Linux originates the SR-Algorithm capability sub-TLV, the algorithm field is set to 0, indicating shortest path first (SPF) algorithm based on link metric.

Origination of IPv4 and IPv6 prefix SID sub-TLVs

SR Linux originates prefix SID sub-TLVs with the following processing rules and encoding of flags.

  • Both IPv4 and IPv6 prefix sub-TLVs originate within MT=0.
  • SR Linux originates a single prefix SID sub-TLV per IS-IS IP reachability TLV.
  • SR Linux encodes the 32-bit index in the prefix SID sub-TLV. The 24-bit label is not supported.
Table 1. Flag encoding for prefix SID sub-TLV
Flag Encoding
R-flag Set if the prefix SID sub-TLV and its corresponding IP reachability TLV are propagated between levels; see below for more details about prefix propagation
N-flag Always set because SR Linux supports a prefix SID type that is node SID only
P-flag (no-PHP flag) Always set, meaning the label for the prefix SID is pushed by the PHP router when forwarding to this router. When the SR Linux PHP router (with P-flag set to 1), processes a received prefix SID with the P-flag set to zero, it uses implicit-null for the outgoing label toward the router that advertised it.
E-flag (Explicit-Null flag) Always set to 0. However, the SR Linux PHP router processes a received prefix SID with the E-flag set to 1, and if the P-flag is also set to 1, it pushes explicit-null for the outgoing label toward the router which advertised it. The system ignores the value of the E-flag if the P-flag is not set.
V-flag Always set to 0 to indicate an index value for the SID
L-flag Always set to 0 to indicate that the SID index value is not locally significant
algorithm field Always set to 0 to indicate shortest path first (SPF) algorithm based on link metric and is not checked on a received prefix SID sub-TLV

Receiving IPv4 and IPv6 prefix SID sub-TLVs

SR Linux processes a prefix SID sub-TLV using the following rules.

  • Decodes prefix SID sub-TLVs that are received in TLVs 135, 235, 236 and 237 for representation in the YANG state model of the LSDB
  • Ignores prefix SID sub-TLVs received in TLVs 235 and 237 for further processing. They do not appear in the state representation of the local SID database (only in the LSDB).
  • If the local flag is set or the algorithm is not 0, deems a prefix SID sub-TLV in a received TLV 135 or TLV 236 invalid and makes it inactive.
    • If the MPLS label value implied by the received prefix SID sub-TLV falls outside the range of the SRGB block, deems the node SID invalid and makes it inactive (reason = sid-index-out-of-range). No forwarding state is created for invalid entries.
  • Resolves a prefix SID sub-TLV received without the N-flag set but with the prefix length equal to 32 (for IPv4) or 128 (for IPv6).
  • Does not resolve a prefix SID sub-TLV received with the N-flag set and a prefix length different than 32 (for IPv4) or 128 (for IPv6).
  • Resolves a prefix SID received within an IP reachability TLV based on the following route preference:
    • SID received via L1 in a prefix SID sub-TLV part of the IP reachability TLV
    • SID received via L2 in a prefix SID sub-TLV part of the IP reachability TLV
  • Processes the first prefix SID sub-TLV only if multiple are received within the same IS-IS IP reachability TLV.
  • An L1L2 router propagates a prefix received in an IP reachability TLV, along with the prefix SID sub-TLV, from L1 to L2. A router in L2 sets up an SR tunnel to the L1 router via the L1L2 router, which acts as an LSR.
  • By default, an L1L2 router does not propagate from L2 to L1 a prefix received in an IP reachability TLV, along with the prefix SID sub-TLV.
  • If an ABR summarizes a prefix, the prefix SID sub-TLV is not propagated with the summarized route between levels. To propagate the node SID for a /32 prefix, you must disable route summarization.

Origination of IPv4 and IPv6 adjacency SID sub-TLVs

The current release does not support origination of adjacency SID sub-TLVs in TLVs 22 and 222.

Receiving IPv4 and IPv6 adjacency SID sub-TLVs

  • Adjacency SID sub-TLVs received in TLVs 22 and 222 are decoded for representation in the YANG state model of the LSDB.
  • The current release does not validate received adjacency SID sub-TLVs or use them to program any datapath objects.

Supported functionality

SR-MPLS-IPV4 dataplane on 7250 IXR-6/10

  • Maximum of one label pushed per packet (corresponding to a remote node SID)
  • Maximum of one label popped per packet (corresponding to a local node SID)
  • Transit and egress LSR ECMP hashing
  • Ingress LSR ECMP hashing
  • Prefix/Node SID (IPv4/IPv6)

MPLS label management

  • Configurable SRGB for the default network-instance:
    • SRGB is a reference to a static shared label range
    • SRGB must be one contiguous block
  • Configurable SRLB for the IS-IS instance of the default network-instance:
    • SRLB is a reference to a dedicated, dynamic label range
    • Each SRLB must be one contiguous block

IS-IS segment routing extensions

  • IPv4/IPv6 node/prefix SID
  • SID collision handling (no event generated when collision detected)

BGP shortcuts over segment routing tunnels

SR-ISIS-IPv4 tunnels in TTM can resolve BGP IPv4 routes.


  • ICMP tunneling
  • RFC 4950 extensions

ICMP tunneling

SR Linux supports ICMP extensions for MPLS to support debugging and tracing in MPLS networks, including SR-MPLS networks. With ICMP tunneling enabled, ICMP messages can be tunneled to the endpoint of the tunnel and then returned through IP routing. For more information, see the SR Linux MPLS Guide.