Theoretical foundations and architecture

Segment Routing defines two primary operational IGP segment types: 1. Prefix SID: a globally significant segment mapped to a router prefix (typically the /32 loopback), designated as a Node SID. A Node SID is globally unique across the domain (e.g., PE1 has Node SID Index 1 -> Label 16001; PE2 has Node SID Index 2 -> Label 16002). Every transit LSR calculates the shortest ECMP SPF path towards that prefix and forwards packets along that vector. PHP applies at the penultimate hop by default. 2. Adjacency SID: a locally significant segment representing a specific directional point-to-point link between adjacent LSRs. Allocated dynamically from the local dynamic label pool (outside the SRGB), an Adj-SID instructs the line-card: 'forward this packet out egress interface X immediately without routing lookup'. By combining Prefix SIDs and Adjacency SIDs within a single label stack, operators engineer deterministic traffic steering along any arbitrary topological path.

Two base IGP segments

RFC 8402 introduces several segment types, but almost everything is built on two: the Prefix-SID (the instruction "deliver the packet to the prefix along the IGP shortest path") and the Adjacency-SID (the instruction "send the packet over this particular link"). The first has global meaning and is bound to an index in the SRGB; the second has local meaning and is bound to an adjacency on one node. A stack of them describes any route: Prefix-SIDs move the packet across the network, Adjacency-SIDs pin the required link where the shortest path is unsuitable.

Prefix-SID and Node-SID

A Prefix-SID is attached to a prefix: most often a /32 loopback, and then it is called a Node-SID (the N flag is set in the sub-TLV). The advertisement carries an index (or an absolute value when the V/L flags are set), an algorithm and flags. Algorithm 0 is the ordinary IGP SPF, algorithm 1 is Strict SPF (the path is not changed by local policies, for example TI-LFA does not divert traffic from it), and the values 128-255 are used by Flex-Algo (RFC 9350). IS-IS flags (RFC 8667): R (re-advertisement), N (Node-SID), P (no-PHP), E (explicit-null), V (a value rather than an index), L (a local value). In OSPFv2 (RFC 8665) the Prefix-SID sits in the Extended Prefix Opaque LSA (Opaque type 7), sub-TLV type 2, with the flags NP, M (mapping server), E, V, L; the same mechanism is used for Anycast.

Every router runs its own SPF and for a prefix SID takes all equal-cost shortest next hops: a Prefix-SID naturally supports ECMP, with balancing by header hash or by an entropy label (RFC 8662). No per-segment state is created.

Anycast SID

If several nodes advertise the same prefix with the same SID (the N flag cleared), the result is an Anycast-SID: the packet goes to the nearest node of the group by metric, and when the nearest one fails, to the next. Uses: a pair of ABRs or gateways, balancing between data centres. Conditions: all participants have the same index and algorithm, and the service state behind the group is consistent (otherwise the packet reaches a node without the required data). TI-LFA protection of such SIDs depends on the implementation: check whether the platform builds a backup for an anycast prefix.

PHP or explicit-null

By default a Prefix-SID is advertised without the P/NP and E flags: the penultimate node pops the label (PHP), and the last node receives the packet without the segment. The P flag (IS-IS) or NP flag (OSPF) means "do not perform PHP": the penultimate node keeps the label and the final node sees its own SID. The E flag means explicit-null: the penultimate node replaces the label with 0 (IPv4) or 2 (IPv6). Why it is needed: with PHP the TC field of the top label disappears before the tunnel exits (pipe model), while explicit-null preserves it for the QoS policy on the final PE; no-PHP is required when the final node must process the segment itself. The choice is made by the owner of the prefix, not by transit, and applies to all senders.

RFC 8660 operations

RFC 8660 describes three operations: PUSH (put a segment onto the stack), CONTINUE (the active segment is not finished, transit replaces the label with the value for the next hop, a swap) and NEXT (the active segment is finished, the label is popped and the next one becomes active). For a Prefix-SID the transit nodes perform CONTINUE and the owner node performs NEXT. For an Adjacency-SID the node performs NEXT and sends the packet out of the interface without a FIB lookup.

Adjacency-SID

For every neighbour a node assigns a label from the local space (the dynamic pool or the SRLB) and advertises it in the IGP: in IS-IS this is the Adj-SID sub-TLV (type 31) inside the neighbour reachability TLV (22, 222, 23, 223, 141), and for a LAN the LAN-Adj-SID sub-TLV (type 32) is used; in OSPF it is the Adj-SID sub-TLV (type 2) in the Extended Link Opaque LSA (type 8) and the LAN Adj-SID (type 3). IS-IS flags: F (address family), B (backup-protected, usually by TI-LFA), V (a value rather than an index), L (a local value), S (a set of Adj-SIDs for several adjacencies), P (persistent value, kept across restarts). With an S set, one SID forwards traffic evenly over parallel links. Many platforms allocate two labels per adjacency: a protected one (with a backup) and an unprotected one.

An Adjacency-SID does not need SPF: a packet with this label simply leaves through the link on the node. The value is known only to the owner, and the other nodes learn it through the IGP. If it is allocated dynamically, it may change after a reload or an adjacency loss: stacks hard-coded into policies with a dynamic Adj-SID will stop working. The way out is a SID from the SRLB (persistent values), a controller that reads the values from the IGP/BGP-LS, or the use of Node-SIDs.