SR-TE: ODN, Color, Binding SID and PCE

Theoretical foundations and architecture

This lesson continues the Segment Routing module: you can already build an SR Policy with an explicit label list and protect links with TI-LFA. Here you move from a single policy to a managed system of paths. A policy is identified by a color and an endpoint pair, it holds several candidate paths with preferences, and the best valid one becomes active. On-Demand Next-hop creates the policy automatically when a BGP route with the needed color arrives, and Automated Steering puts traffic into it without manual routes. A Binding SID turns a policy into a single label that can be used for stack compression and domain stitching. For complex computations a PCE is added: PCEP carries delegated paths and BGP-LS supplies the topology. You will see when the headend computes a path, when the PCE does, and what happens when the PCE is unavailable.

The SR Policy model: what the headend stores

You built a basic SR Policy in the SR Policy and TI-LFA lesson: one explicit label list and steering by color. This lesson covers the full RFC 9256 model. A policy is uniquely identified by the triple (headend, color, endpoint). Color is a 32-bit number whose meaning the operator defines (for example 100 - low delay, 200 - critical VRF, 300 - bulk); endpoint is the address of the egress node. A policy holds one or more candidate paths. Each path has a preference (higher is better), a protocol-origin (PCEP 10, BGP SR Policy 20, local configuration 30), an originator and a discriminator. The active path is the valid one selected by comparing preference first; ties are broken by protocol-origin (higher wins), then originator (lower wins) and discriminator (higher wins). A path is valid when the first SID of its list resolves; the policy is valid while at least one path is valid. A path may contain several segment lists with weights, which gives ECMP or UCMP between the lists.

Explicit and dynamic paths

An explicit path is a SID list written by hand or pushed by a controller; the headend only checks that the first segment resolves. A dynamic path is described by an objective and constraints, and the SID list is computed by the headend (or by a PCE). The objective is the lowest IGP metric, the lowest TE metric or the lowest delay (if the IGP advertises measured link delay). Constraints are affinity (exclude-any, include-any, include-all over admin-group bits), SRLG, the maximum number of labels and disjointness from another policy (group-id, type link, node or SRLG). The computation is a constrained SPF on the TED, which the IGP fills with SR and TE extensions (TE metric, affinity, delay, MSD). The result is a strict path that is compressed into a SID list: a Node-SID where the shortest path matches the wanted one, and an Adj-SID where a link must be chosen explicitly. The list length is limited by the MSD (maximum SID depth) of the ingress node, which it advertises in the IGP and in PCEP.

Color + endpoint, ODN and Automated Steering

A BGP route carries the Color extended community (RFC 9012). Automated Steering (AS) works like this: if the headend has a valid policy (color, endpoint) that matches the route's color and next hop, the route resolves through the policy; otherwise it keeps resolving through the IGP. ODN (On-Demand Next-hop) removes the need to create a policy for every PE by hand: the operator defines an on-demand template for color 200 (computation method and constraints), and the policy (200, next hop) is created when the first route with that color and next hop appears. When no routes remain, the policy is removed after a timer. Details that matter: the color must match exactly (unless color-only steering from RFC 9256 is used), the template does not create paths for routes without a color, and the number of created policies grows with the number of PEs, so ODN is planned together with platform limits. Per-destination steering selects the policy by the BGP route; per-flow steering classifies traffic on ingress (DSCP or ACL) into a forwarding class and each class gets its own policy; its implementation and limits depend on the platform. Traffic to IGP prefixes is pushed into a policy by a separate mechanism (autoroute or static), which is not AS.

Binding SID

A Binding SID (BSID) is a local label of the headend; when the node receives it, it pushes the SID stack of the policy. It is used in three cases. First, stack compression: a node with a small MSD pushes one BSID and an intermediate node adds the long stack. Second, domain and ASBR stitching: the part of the path between domains is hidden behind one label and the internal topology is not revealed. Third, a stable interface for a controller and services: internal SIDs can change while the BSID stays the same. A BSID is taken from the SRLB (Cisco default 15000-15999) or allocated dynamically; a dynamic value changes when the policy is recreated, so for external use it is pinned. Typical mistakes: two policies with the same BSID on a node, a BSID outside the SRLB, and a BSID left in a controller after the policy was deleted.

PCE, PCEP and BGP-LS

A PCE (Path Computation Element) computes a path for a PCC (Path Computation Client, usually the headend). PCEP (RFC 5440) runs over TCP 4189: Open, Keepalive, PCReq, PCRep, PCNtf, PCErr, Close. The stateful extension (RFC 8231) adds PCRpt (the PCC reports path state) and PCUpd (the PCE changes a path), RFC 8281 adds PCInitiate (the PCE creates a path itself). SR extensions are in RFC 8664: SR-ERO with SID types, SR capability and MSD in Open. A passive PCE computes on request; an active stateful PCE receives delegation and can re-optimize a path after a topology change. The PCE learns the topology over BGP-LS (RFC 7752, updated by RFC 9552): IGP nodes, links and prefixes are packed into NLRI AFI 16388 SAFI 71, and SR attributes are carried by the RFC 9085 extensions. Usually one or two IGP nodes per domain export the TED into BGP-LS to a route reflector or directly to the PCE.