Segment Routing Policy For Traffic Engineering

Segment Routing policy is used when Automatic Traffic Steering is required. Doesn't matter that traffic steering in specific network slice or based on some constraints. Below is the excerpt from Segment Routing Policy for Traffic Engineering IETF draft.

Segment Routing Policy: Segment Routing (SR) allows a headend node to steer a packet flow along any path. The headend node steers a flow into an Segment Routing Policy aka SR Policy.

How to Identify SR Policy: An SR Policy is identified through the tuple . The headend is the node where the policy is instantiated/implemented. The headend is specified as an IPv4 or IPv6 address.

What is Candidate Path: An SR Policy is associated with one or more candidate paths. A candidate path can either be explicit or dynamic.

What is explicit path: An explicit candidate path is associated with a SID-List or a set of SID-Lists or loopback addresses of nodes also.

What is dynamic path: A dynamic candidate path expresses an optimization objective and a set of constraints. The headend with PCE computes the solution SID-List that solves the optimization problem.

How and when candidate path becomes valid and invalid?
Explicit Path:
A SID-List of an explicit candidate path MUST be declared invalid when:
a. It is empty.
b. Its weight is 0.
c. The headend is unable to resolve the first SID into one or more outgoing interface(s) and next-hop(s).
d. The headend is unable to resolve any non-first SID of type 3-to-11 into an MPLS label or an SRv6 SID. (Type3-11 will be covering in my upcoming post)

Dynamic Path:
The headend of the policy leverages its SRTE-DB to compute a SID-List that solves this optimization problem. When local computation is not possible or not desired, the head-end MAY send path computation request to a PCE supporting PCEP. If no solution is found to the optimization objective and constraints, then the dynamic candidate path is declared invalid.