Segment routing

Overview

Segment routing enables an IGP to perform shortest path routing and source routing using segments. A segment can represent a local prefix of an NE, a specific adjacency of the NE, a service context, or a specific explicit path over the network. For each segment, the IGP advertises a segment identifier, or SID. The SID can be used to resolve forwarding in several contexts, such as BGP labelled routes, VPRN and EVPN auto-binding of tunnels, and remote loop-free alternate.

When segment routing is used together with MPLS, the segment identifier is a standard MPLS label. An NE forwarding a packet using segment routing pushes one or more MPLS labels. See To configure an MPLS instance for more information about how to configure the segment routing label range.

Each prefix SID represents a network global IP address. Therefore the SID index for a prefix must be unique in the network. All routers in the network are expected to configure and advertise the same prefix SID index range for an IGP instance. However, the label value used by each router to represent this prefix can be local to that router with the use of a start label.

Two mutually exclusive prefix SID types can be configured: global and local.

With the global prefix SID type, the IGP instance assumes the start label value is the lowest label value in the SRGB and the prefix SID index range size is equal to the range size of the SRGB. If the global option has been selected for one IGP instance, all IGP instances on the system will be restricted to do the same.

With the local prefix SID type, the user configures a subset of the SRGB by specifying the start label value and the prefix SID index range size. Note that all resulting net label values (start-label + index) must be within the SRGB or the configuration will fail. Also, the NFM-P checks for overlaps of the resulting net label value range across IGP instances and will strictly enforce that the ranges do not overlap.

You can use the NFM-P to configure segment routing and to assign an SID index or label to ISIS and OSPF instances; see To configure IS-IS segment routing and To configure OSPF segment routing.

Segment routing policy

A segment routing policy specifies a source-routed path from a head-end router to an end-point, and it specifies the traffic flows that should be steered into that source-routed path. An SR policy can be explicitly configured or learned from a protocol such as BGP or PCEP. For information about configuring a BGP site to learn segment routing policies, see To enable SR policy support on a BGP site, peer, or peer group. For information about creating a segment routing policy, see To create a segment routing policy.

Segment routing tree

A segment routing tree is an SID based multicast tree. It is very similar to a P2MP LSP.

An SR tree policy can be used in the same manner as a P2MP RSVP-TE or mLDP, for example, it can be used as a provider tunnel under an MVPN.

An SR tree policy represents a multicast tree from a root to a set of leaves. The SR tree policy can contain redundant trees, each with its own preference. This redundancy is presented via candidate paths. Each candidate path represents a P2MP tree with its own traffic engineering constraints. These candidate paths can be optimized based on link failures or IGP optimizations. As such each candidate path can contain multiple P2MP LSPs represented by path Instance IDs. The candidate path can perform make before break between these path instances. The candidate path with the highest preference becomes the active candidate path.

An SR tree policy is relevant only on the root node where the segment routing tree is instantiated. An SR tree policy does not have any forwarding information for the P2MP LSP. It only contains root and leaf information and the traffic engineering information for the tree to be set up from the root to the leaves. The forwarding information is part of the replication policy. Therefore the transit and leaf nodes only contain the replication policy.

For information about creating a segment routing tree, see To create a segment routing tree.

Replication segments

A replication segment is a forwarding instruction for a P2MP LSP. It contains the incoming replication SID and a set of outgoing interfaces and their corresponding set of outgoing labels. A replication policy consists of a treeID, rootID and path-instanceID (LSP-ID). If a replication segment is shared between multiple roots or P2MP LSPs, it does not have a rootID. A shared replication segment has a replication segment identifier denoted in the treeID. This type of replication segment can be used for FRR.

Segment Routing with IPv6

SR-IPv6 allows Segment Routing to be deployed over non-MPLS networks and/or in areas of the network where MPLS is not present. An IPv6 packet consists of an IPv6 header, extension headers, and payload. The Segment Routing header (SRH) is an extension header added to IPv6 packets to implement Segment Routing IPv6 (SRv6) based on the IPv6 forwarding plane. It specifies an IPv6 explicit path and stores IPv6 segment lists that function in the same way as segment lists in SR-MPLS.

The segment lists in an SRv6 SRH are processed from the bottom up, which is different from SR-MPLS processing. Another difference between SRv6 and SR-MPLS is that segments in SRv6 SRHs are not removed after being processed by nodes.

SRv6 segments are identified using segment identifiers (SIDs) encoded as IPv6 addresses. An SRv6 SID consists of two parts: Locator and Function. The Locator part provides the location function. The Function part identifies an instruction bound to the node that generates the SRv6 SID.

Each SRv6-capable node keeps a local SID table containing all SRv6 SIDs generated on the node. The destination SID identifies a destination node. It is similar to a node SID in SR-MPLS. In shortest path routing, the destination SID is encoded in the Destination Address (DA) field of the outer IPv6 header. Unlike usual segment routing, SID value is derived from the locator prefix configured and the end function.

SRv6 is supported from NFM-P Release, 22.2 R1 onwards.