RFC 9256: Segment Routing Policy Architecture

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2.1. Identification of an SR Policy

An SR Policy MUST be identified through the tuple <Headend, Color, Endpoint>. In the context of a specific headend, an SR Policy MUST be identified by the <Color, Endpoint> tuple.¶

The headend is the node where the policy is instantiated/implemented. The headend is specified as an IPv4 or IPv6 address and MUST resolve to a unique node in the SR domain [RFC8402].¶

The endpoint indicates the destination of the policy. The endpoint is specified as an IPv4 or IPv6 address and SHOULD resolve to a unique node in the domain. In a specific case (refer to Section 8.8.1), the endpoint can be the unspecified address (0.0.0.0 for IPv4, :: for IPv6) and in this case, the destination of the policy is indicated by the last segment in the segment list(s).¶

The color is an unsigned non-zero 32-bit integer value that associates the SR Policy with an intent or objective (e.g., low latency).¶

The endpoint and the color are used to automate the steering of service or transport routes on SR Policies (refer to Section 8).¶

An implementation MAY allow the assignment of a symbolic name comprising printable ASCII [RFC0020] characters (i.e., 0x20 to 0x7E) to an SR Policy to serve as a user-friendly attribute for debugging and troubleshooting purposes. Such symbolic names may identify an SR Policy when the naming scheme ensures uniqueness. The SR Policy name MAY also be signaled along with a candidate path of the SR Policy (refer to Section 2.2). An SR Policy MAY have multiple names associated with it in the scenario where the headend receives different SR Policy names along with different candidate paths for the same SR Policy via the same or different sources.¶

2.2. Candidate Path and Segment List

An SR Policy is associated with one or more candidate paths. A candidate path is the unit for signaling of an SR Policy to a headend via protocol extensions like the Path Computation Element Communication Protocol (PCEP) [RFC8664] [PCEP-SR-POLICY-CP] or BGP SR Policy [BGP-SR-POLICY].¶

A segment list represents a specific source-routed path to send traffic from the headend to the endpoint of the corresponding SR Policy.¶

A candidate path is either dynamic, explicit, or composite.¶

An explicit candidate path is expressed as a segment list or a set of segment lists.¶

A dynamic candidate path expresses an optimization objective and a set of constraints for a specific data plane (i.e., SR-MPLS or SRv6). The headend (potentially with the help of a PCE) computes a solution segment list (or set of segment lists) that solves the optimization problem.¶

If a candidate path is associated with a set of segment lists, each segment list is associated with weight for weighted load balancing (refer to Section 2.11 for details). The default weight is 1.¶

A composite candidate path acts as a container for grouping SR Policies. The composite candidate path construct enables the combination of SR Policies, each with explicit candidate paths and/or dynamic candidate paths with potentially different optimization objectives and constraints, for load-balanced steering of packet flows over its constituent SR Policies. The following criteria apply for inclusion of constituent SR Policies using a composite candidate path under a parent SR Policy:¶

Each constituent SR Policy of a composite candidate path is associated with weight for load-balancing purposes (refer to Section 2.11 for details). The default weight is 1.¶

Section 2.13 illustrates an information model for hierarchical relationships between the SR Policy constructs described in this section.¶

2.3. Protocol-Origin of a Candidate Path

A headend may be informed about a candidate path for an SR Policy <Color, Endpoint> by various means including: via configuration, PCEP [RFC8664] [PCEP-SR-POLICY-CP], or BGP [BGP-SR-POLICY].¶

Protocol-Origin of a candidate path is an 8-bit value associated with the mechanism or protocol used for signaling/provisioning the SR Policy. It helps identify the protocol/mechanism that provides or signals the candidate path and indicates its preference relative to other protocols/mechanisms.¶

The headend assigns different Protocol-Origin values to each source of SR Policy information. The Protocol-Origin value is used as a tiebreaker between candidate paths of equal Preference, as described in Section 2.9. The table below specifies the RECOMMENDED default values of Protocol-Origin:¶

Note that the above order is to satisfy the need for having a clear ordering, and implementations MAY allow modifications of these default values assigned to protocols on the headend along similar lines as a routing administrative distance. Its application in the candidate path selection is described in Section 2.9.¶

2.4. Originator of a Candidate Path

The Originator identifies the node that provisioned or signaled the candidate path on the headend. The Originator is expressed in the form of a 160-bit numerical value formed by the concatenation of the fields of the tuple <Autonomous System Number (ASN), node-address> as below:¶

Autonomous System Number (ASN):

represented as a 4-byte number. If 2-byte ASNs are in use, the low-order 16 bits MUST be used, and the high-order bits MUST be set to 0.¶

Node Address:

represented as a 128-bit value. IPv4 addresses MUST be encoded in the lowest 32 bits, and the high-order bits MUST be set to 0.¶

Its application in the candidate path selection is described in Section 2.9.¶

When provisioning is via configuration, the ASN and node address MAY be set to either the headend or the provisioning controller/node ASN and address. The default value is 0 for both AS and node address.¶

When signaling is via PCEP, it is the IPv4 or IPv6 address of the PCE, and the AS number is expected to be set to 0 by default when not available or known.¶

When signaling is via BGP SR Policy, the ASN and node address are provided by BGP (refer to [BGP-SR-POLICY]) on the headend.¶

2.5. Discriminator of a Candidate Path

The Discriminator is a 32-bit value associated with a candidate path that uniquely identifies it within the context of an SR Policy from a specific Protocol-Origin as specified below:¶

Its application in the candidate path selection is described in Section 2.9.¶

2.6. Identification of a Candidate Path

A candidate path is identified in the context of a single SR Policy.¶

A candidate path is not shared across SR Policies.¶

A candidate path is not identified by its segment list(s).¶

The identity of a candidate path MUST be uniquely established in the context of an SR Policy <Headend, Color, Endpoint> to handle add, delete, or modify operations on them in an unambiguous manner regardless of their source(s).¶

The tuple <Protocol-Origin, Originator, Discriminator> uniquely identifies a candidate path.¶

Candidate paths MAY also be assigned or signaled with a symbolic name comprising printable ASCII [RFC0020] characters (i.e., 0x20 to 0x7E) to serve as a user-friendly attribute for debugging and troubleshooting purposes. Such symbolic names MUST NOT be considered as identifiers for a candidate path. The signaling of the candidate path name via BGP and PCEP is described in [BGP-SR-POLICY] and [PCEP-SR-POLICY-CP], respectively.¶

2.7. Preference of a Candidate Path

The Preference of the candidate path is used to select the best candidate path for an SR Policy. It is a 32-bit value where a higher value indicates higher preference and the default Preference value is 100.¶

It is RECOMMENDED that each candidate path of a given SR Policy has a different Preference.¶

The signaling of the candidate path Preference via BGP and PCEP is described in [BGP-SR-POLICY] and [PCEP-SR-POLICY-CP], respectively.¶

2.8. Validity of a Candidate Path

A candidate path is usable when it is valid. The RECOMMENDED candidate path validity criterion is the validity of at least one of its constituent segment lists. The validation rules are specified in Section 5.¶

2.9. Active Candidate Path

A candidate path is selected when it is valid and it is determined to be the best path of the SR Policy. The selected path is referred to as the "active path" of the SR Policy in this document.¶

Whenever a new path is learned or an active path is deleted, the validity of an existing path changes, or an existing path is changed, the selection process MUST be re-executed.¶

The candidate path selection process operates primarily on the candidate path Preference. A candidate path is selected when it is valid and it has the highest Preference value among all the valid candidate paths of the SR Policy.¶

In the case of multiple valid candidate paths of the same Preference, the tie-breaking rules are evaluated on the identification tuple in the following order until only one valid best path is selected:¶

The rules are framed with multiple protocols and sources in mind and hence may not follow the logic of a single protocol (e.g., BGP best path selection). The motivation behind these rules are as follows:¶

[SR-POLICY-CONSID] provides a set of examples to illustrate the active candidate path selection rules.¶

2.10. Validity of an SR Policy

An SR Policy is valid when it has at least one valid candidate path.¶

2.11. Instantiation of an SR Policy in the Forwarding Plane

Generally, only valid SR policies are instantiated in the forwarding plane.¶

Only the active candidate path MUST be used for forwarding traffic that is being steered onto that policy except for certain scenarios such as fast reroute where a backup candidate path may be used as described in Section 9.3.¶

If a set of segment lists is associated with the active path of the policy, then the steering is per flow and weighted-ECMP (W-ECMP) based according to the relative weight of each segment list.¶

The fraction of the flows associated with a given segment list is w/⁠Sw, where w is the weight of the segment list and Sw is the sum of the weights of the segment lists of the selected path of the SR Policy.¶

When a composite candidate path is active, the fraction of flows steered into each constituent SR Policy is equal to the relative weight of each constituent SR Policy. Further load-balancing of flows steered into a constituent SR Policy is performed based on the weights of the segment list of the active candidate path of that constituent SR Policy.¶

The accuracy of the weighted load-balancing depends on the platform implementation.¶

2.12. Priority of an SR Policy

Upon topological change, many policies could be re-computed or revalidated. An implementation MAY provide a per-policy priority configuration. The operator may set this field to indicate the order in which the policies should be re-computed. Such a priority is represented by an integer in the range (0, 255) where the lowest value is the highest priority. The default value of priority is 128.¶

An SR Policy may comprise multiple candidate paths received from the same or different sources. A candidate path MAY be signaled with a priority value. When an SR Policy has multiple candidate paths with distinct signaled non-default priority values and the SR Policy itself does not have a priority value configured, the SR Policy as a whole takes the lowest value (i.e., the highest priority) amongst these signaled priority values.¶

2.13. Summary

In summary, the information model is the following:¶

SR Policy POL1

<Headend = H1, Color = 1, Endpoint = E1>¶

Candidate Path CP1

<Protocol-Origin = 20, Originator = 64511:192.0.2.1, Discriminator = 1>¶

Preference

200¶

Priority

10¶

Segment List 1

<SID11...SID1i>, Weight W1¶

Segment List 2

<SID21...SID2j>, Weight W2¶

Candidate Path CP2

<Protocol-Origin = 20, Originator = 64511:192.0.2.2, Discriminator = 2>¶

Preference

100¶

Priority

10¶

Segment List 3

<SID31...SID3i>, Weight W3¶

Segment List 4

<SID41...SID4j>, Weight W4¶

The SR Policy POL1 is identified by the tuple <Headend, Color, Endpoint>. It has two candidate paths: CP1 and CP2. Each is identified by a tuple <Protocol-Origin, Originator, Discriminator> within the scope of POL1. CP1 is the active candidate path (it is valid and has the highest Preference). The two segment lists of CP1 are installed as the forwarding instantiation of SR Policy POL1. Traffic steered on POL1 is flow-based hashed on segment list <SID11...SID1i> with a ratio W1/(W1+W2).¶

The information model of SR Policy POL100 having a composite candidate path is the following:¶

SR Policy POL100 <Headend = H1, Color = 100, Endpoint = E1>

Candidate Path CP1 <Protocol-Origin = 20, Originator = 64511:192.0.2.1, Discriminator = 1>

Preference 200

SR Policy <Color = 1>, Weight W1

SR Policy <Color = 2>, Weight W2

The constituent SR Policies POL1 and POL2 have an information model as described at the start of this section. They are referenced only by color in the composite candidate path since their headend and endpoint are identical to the POL100. The valid segment lists of the active candidate path of POL1 and POL2 are installed in the forwarding. Traffic steered on POL100 is hashed on a per-flow basis on POL1 with a proportion W1/(W1+W2). Within the POL1, the flow-based hashing over its segment lists are performed as described earlier in this section.¶

4.1. Explicit Null

A Type A SID MAY be any MPLS label, including special purpose labels.¶

For example, assuming that the desired traffic-engineered path from a headend 1 to an endpoint 4 can be expressed by the segment list <16002, 16003, 16004> where 16002, 16003, and 16004, respectively, refer to the IPv4 Prefix SIDs bound to nodes 2, 3, and 4, then IPv6 traffic can be traffic-engineered from nodes 1 to 4 via the previously described path using an SR Policy with segment list <16002, 16003, 16004, 2> where the MPLS label value of 2 represents the "IPv6 Explicit NULL Label".¶

The penultimate node before node 4 will pop 16004 and will forward the frame on its directly connected interface to node 4.¶

The endpoint receives the traffic with the top label "2", which indicates that the payload is an IPv6 packet.¶

When steering unlabeled IPv6 BGP destination traffic using an SR Policy composed of segment list(s) based on IPv4 SIDs, the Explicit Null Label Policy is processed as specified in [BGP-SR-POLICY]. When an "IPv6 Explicit NULL label" is not present as the bottom label, the headend SHOULD automatically impose one. Refer to Section 8 for more details.¶

5.1. Explicit Candidate Path

An explicit candidate path is associated with a segment list or a set of segment lists.¶

An explicit candidate path is provisioned by the operator directly or via a controller.¶

The computation/logic that leads to the choice of the segment list is external to the SR Policy headend. The SR Policy headend does not compute the segment list. The SR Policy headend only confirms its validity.¶

An explicit candidate path MAY consist of a single explicit segment list containing only an implicit-null label to indicate pop-and-forward behavior. The Binding SID (BSID) is popped and the traffic is forwarded based on the inner label or an IP lookup in the case of unlabeled IP packets. Such an explicit path can serve as a fallback or path of last resort for traffic being steered into an SR Policy using its BSID (refer to Section 8.3).¶

A segment list of an explicit candidate path MUST be declared invalid when any of the following is true:¶

"Unable to perform path resolution" means that the headend has no path to the SID in its SR database.¶

SID verification is performed when the headend is explicitly requested to verify SID(s) by the controller via the signaling protocol used. Implementations MAY provide a local configuration option to enable verification on a global or per-policy or per-candidate path basis.¶

"Verification fails" for a SID means any of the following:¶

In multi-domain deployments, it is expected that the headend may be unable to verify the reachability of the SIDs in remote domains. Types A or B MUST be used for the SIDs for which the reachability cannot be verified. Note that the first SID MUST always be reachable regardless of its type.¶

Additionally, a segment list MAY be declared invalid when both of the conditions below are met :¶

An explicit candidate path is invalid as soon as it has no valid segment list.¶

Additionally, an explicit candidate path MAY be declared invalid when its constituent segment lists (valid or invalid) are using segment types of different SR data planes.¶

5.2. Dynamic Candidate Path

A dynamic candidate path is specified as an optimization objective and a set of constraints.¶

The headend of the policy leverages its SR database to compute a segment list ("solution segment list") that solves this optimization problem for either the SR-MPLS or the SRv6 data plane as specified.¶

The headend re-computes the solution segment list any time the inputs to the problem change (e.g., topology changes).¶

When the local computation is not possible (e.g., a policy's tail end is outside the topology known to the headend) or not desired, the headend may rely on an external entity. For example, a path computation request may be sent to a PCE supporting PCEP extensions specified in [RFC8664].¶

If no solution is found to the optimization objective and constraints, then the dynamic candidate path MUST be declared invalid.¶

[SR-POLICY-CONSID] discusses some of the optimization objectives and constraints that may be considered by a dynamic candidate path. It illustrates some of the desirable properties of the computation of the solution segment list.¶

5.3. Composite Candidate Path

A composite candidate path is specified as a group of its constituent SR Policies.¶

A composite candidate path is valid when it has at least one valid constituent SR Policy.¶

6.1. BSID of a Candidate Path

Each candidate path MAY be defined with a BSID.¶

Candidate paths of the same SR Policy SHOULD have the same BSID.¶

Candidate paths of different SR Policies MUST NOT have the same BSID.¶

6.2. BSID of an SR Policy

The BSID of an SR Policy is the BSID of its active candidate path.¶

When the active candidate path has a specified BSID, the SR Policy uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is available. A BSID is available when its value is not associated with any other usage, e.g., a label used by some other MPLS forwarding entry or an SRv6 SID used in some other context (such as to another segment, to another SR Policy, or that it is outside the range of SRv6 Locators).¶

In the case of SR-MPLS, SRv6 BSIDs (e.g., with the behavior End.BM [RFC8986]) MAY be associated with the SR Policy in addition to the MPLS BSID. In the case of SRv6, multiple SRv6 BSIDs (e.g., with different behaviors like End.B6.Encaps and End.B6.Encaps.Red [RFC8986]) MAY be associated with the SR Policy.¶

Optionally, instead of only checking that the BSID of the active path is available, a headend MAY check that it is available within the given SID range i.e., Segment Routing Local Block (SRLB) as specified in [RFC8402].¶

When the specified BSID is not available (optionally is not in the SRLB), an alert message MUST be generated via mechanisms like syslog.¶

In the cases (as described above) where SR Policy does not have a BSID available, the SR Policy MAY dynamically bind a BSID to itself. Dynamically bound BSIDs SHOULD use an available SID outside the SRLB.¶

Assuming that at time t the BSID of the SR Policy is B1, if at time t+dt a different candidate path becomes active and this new active path does not have a specified BSID or its BSID is specified but is not available (e.g., it is in use by something else), then the SR Policy MAY keep the previous BSID B1.¶

The association of an SR Policy with a BSID thus MAY change over the life of the SR Policy (e.g., upon active path change). Hence, the BSID SHOULD NOT be used as an identification of an SR Policy.¶

6.3. Forwarding Plane

A valid SR Policy results in the installation of a BSID-keyed entry in the forwarding plane with the action of steering the packets matching this entry to the selected path of the SR Policy.¶

If the Specified-BSID-only restrictive behavior is enabled and the BSID of the active path is not available (optionally not in the SRLB), then the SR Policy does not install any entry indexed by a BSID in the forwarding plane.¶

6.4. Non-SR Usage of Binding SID

An implementation MAY choose to associate a Binding SID with any type of interface (e.g., a layer 3 termination of an Optical Circuit) or a tunnel (e.g., IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE tunnel, etc). This enables the use of other non-SR-enabled interfaces and tunnels as segments in an SR Policy segment list without the need of forming routing protocol adjacencies over them.¶

The details of this kind of usage are beyond the scope of this document. A specific packet-optical integration use case is described in [POI-SR].¶

8.1. Validity of an SR Policy

An SR Policy is invalid when all its candidate paths are invalid as described in Sections 2.10 and 5.¶

By default, upon transitioning to the invalid state,¶

8.2. Drop-upon-Invalid SR Policy

An SR Policy MAY be enabled for the Drop-Upon-Invalid behavior. This would entail the following:¶

The Drop-Upon-Invalid behavior has been deployed in use cases where the operator wants some PW to only be transported on a path with specific constraints. When these constraints are no longer met, the operator wants the PW traffic to be dropped. Specifically, the operator does not want the PW to be routed according to the IGP shortest path to the PW endpoint.¶

8.3. Incoming Active SID is a BSID

Let us assume that headend H has a valid SR Policy P of segment list <S1, S2, S3> and BSID B.¶

In the case of SR-MPLS, when H receives a packet K with label stack <B, L2, L3>, H pops B and pushes <S1, S2, S3> and forwards the resulting packet according to SID S1.¶

In the case of SRv6, the processing is similar and follows the SR Policy headend behaviors as specified in Section 5 of [RFC8986].¶

H has steered the packet into the SR Policy P.¶

H did not have to classify the packet. The classification was done by a node upstream of H (e.g., the source of the packet or an intermediate ingress edge node of the SR domain) and the result of this classification was efficiently encoded in the packet header as a BSID.¶

This is another key benefit of the segment routing in general and the binding SID in particular: the ability to encode a classification and the resulting steering in the packet header to better scale and simplify intermediate aggregation nodes.¶

When Drop-Upon-Invalid (refer to Section 8.2) is not in use, for an invalid SR Policy P, its BSID B is not in the forwarding plane and hence, the packet K is dropped by H.¶

8.4. Per-Destination Steering

This section describes how a headend applies steering of flows corresponding to BGP routes over SR Policy using the Color Extended community [RFC9012].¶

In the case of SR-MPLS, let us assume that headend H:¶

If all these conditions are met, H installs R/r in RIB/FIB with next-hop = SR Policy P of BSID B instead of via N.¶

Indeed, H's local BGP policy and the received BGP route indicate that the headend should associate R/r with an SR Policy path to endpoint N with the SLA associated with color C. The headend, therefore, installs the BGP route on that policy.¶

This can be implemented by using the BSID as a generalized next-hop and installing the BGP route on that generalized next-hop.¶

When H receives a packet K with a destination matching R/r, H pushes the label stack <S1, S2, S3, V> and sends the resulting packet along the path to S1.¶

Note that any SID associated with the BGP route is inserted after the segment list of the SR Policy (i.e., <S1, S2, S3, V>).¶

In the case of SRv6, the processing is similar and follows the SR Policy headend behaviors as specified in Section 5 of [RFC8986].¶

The same behavior applies to any type of service route: any AFI/SAFI of BGP [RFC4760] or the Locator/ID Separation Protocol (LISP) [RFC6830] for both IPv4/IPv6.¶

In a BGP multi-path scenario, the BGP route MAY be resolved over a mix of paths that include those that are steered over SR Policies and others resolved via the normal BGP next-hop resolution. Implementations MAY provide options to prefer one type over the other or other forms of local policy to determine the paths that are selected.¶

8.5. Recursion on an On-Demand Dynamic BSID

In the previous section, it was assumed that H had a pre-established "explicit" SR Policy (color C, endpoint N).¶

In this section, independent of the a priori existence of any explicit candidate path of the SR Policy (C, N), it is to be noted that the BGP process at headend node H triggers the instantiation of a dynamic candidate path for the SR Policy (C, N) as soon as:¶

8.6. Per-Flow Steering

This section provides an example of how a headend might apply per-flow steering in practice.¶

Let us assume that headend H:¶

If all these conditions are met, H installs in RIB/FIB:¶

H receives three packets K, K1, and K2 on its incoming interface. These three packets either longest match on N or more likely on a BGP/service route that recurses on N. H colors these 3 packets respectively with forwarding-class 0, 1, and 2.¶

As a result, for SR-MPLS:¶

For SRv6, the processing is similar and the segment lists of the individual SR Policies P1 and P2 are enforced for packets K1 and K2 using the SR Policy headend behaviors as specified in Section 5 of [RFC8986].¶

If the local configuration does not specify any explicit forwarding information for an entry of the array, then this entry is filled with the same information as entry 0 (i.e., the IGP shortest path).¶

If the SR Policy mapped to an entry of the array becomes invalid, then this entry is filled with the same information as entry 0. When all the array entries have the same information as entry 0, the forwarding entry for N is updated to bypass the array and point directly to its outgoing interface and next-hop.¶

The array index values (e.g., 0, 1, and 2) and the notion of forwarding class are implementation specific and only meant to describe the desired behavior. The same can be realized by other mechanisms.¶

This realizes per-flow steering: different flows bound to the same BGP endpoint are steered on different IGP or SR Policy paths.¶

A headend MAY support options to apply per-flow steering only for traffic matching specific prefixes (e.g., specific IGP or BGP prefixes).¶

8.7. Policy-Based Routing

Finally, headend H MAY be configured with a local routing policy that overrides any BGP/IGP path and steers a specified packet on an SR Policy. This includes the use of mechanisms like IGP Shortcut for automatic routing of IGP prefixes over SR Policies intended for such purpose.¶

8.8. Optional Steering Modes for BGP Destinations

   IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6
           endpoint address and C is a color;
       Steer into SR Policy (N, C);
   ELSE;
       Steer on the IGP path to the next-hop N.

   IF there is a valid SR Policy (N, C) where N is the IPv4 or IPv6
           endpoint address and C is a color;
       Steer into SR Policy (N, C);
   ELSE IF there is a valid SR Policy (null endpoint, C) of the
           same address-family of N;
       Steer into SR Policy (null endpoint, C);
   ELSE IF there is any valid SR Policy
           (any address-family null endpoint, C);
       Steer into SR Policy (any null endpoint, C);
   ELSE;
       Steer on the IGP path to the next-hop N.

   IF there is a valid SR Policy (N, C) where N is an IPv4 or IPv6
           endpoint address and C is a color;
       Steer into SR Policy (N, C);
   ELSE IF there is a valid SR Policy (null endpoint, C)
           of the same address-family of N;
       Steer into SR Policy (null endpoint, C);
   ELSE IF there is any valid SR Policy
           (any address-family null endpoint, C);
       Steer into SR Policy (any null endpoint, C);
   ELSE IF there is any valid SR Policy (any endpoint, C)
           of the same address-family of N;
       Steer into SR Policy (any endpoint, C);
   ELSE IF there is any valid SR Policy
           (any address-family endpoint, C);
       Steer into SR Policy (any address-family endpoint, C);
   ELSE;
       Steer on the IGP path to the next-hop N.

9.1. Leveraging TI-LFA Local Protection of the Constituent IGP Segments

In any topology, Topology-Independent Loop-Free Alternate (TI-LFA) [SR-TI-LFA] provides a 50 msec local protection technique for IGP SIDs. The backup path is computed on a per-IGP-SID basis along the post-convergence path.¶

In a network that has deployed TI-LFA, an SR Policy built on the basis of TI-LFA protected IGP segments leverages the local protection of the constituent segments. Since TI-LFA protection is based on IGP computation, there are cases where the path used during the fast-reroute time window may not meet the exact constraints of the SR Policy.¶

In a network that has deployed TI-LFA, an SR Policy instantiated only with non-protected Adj SIDs does not benefit from any local protection.¶

9.2. Using an SR Policy to Locally Protect a Link

     1----2-----6----7
     |    |     |    |
     4----3-----9----8

An SR Policy can be instantiated at node 2 to protect link 2-to-6. A typical explicit segment list would be <3, 9, 6>.¶

A typical use case occurs for links outside an IGP domain: e.g., 1, 2, 3, and 4 are part of IGP/SR sub-domain 1 while 6, 7, 8, and 9 are part of IGP/SR sub-domain 2. In such a case, links 2-to-6 and 3to9 cannot benefit from TI-LFA automated local protection. The SR Policy with segment list <3, 9, 6> on node 2 can be locally configured to be a fast-reroute backup path for the link 2-to-6.¶

9.3. Using a Candidate Path for Path Protection

An SR Policy allows for multiple candidate paths, of which at any point in time there is a single active candidate path that is provisioned in the forwarding plane and used for traffic steering. However, another (lower preference) candidate path MAY be designated as the backup for a specific or all (active) candidate path(s). The following options are possible:¶

The headend MAY compute a priori and validate such backup candidate paths as well as provision them into the forwarding plane as a backup for the active path. The backup candidate path may be dynamically computed or explicitly provisioned in such a way that they provide the most appropriate alternative for the active candidate path. A fast-reroute mechanism MAY then be used to trigger sub-50 msec switchover from the active to the backup candidate path in the forwarding plane. Mechanisms like Bidirectional Forwarding Detection (BFD) MAY be used for fast detection of such failures.¶

12.1. Guidance for Designated Experts

The Designated Expert (DE) is expected to ascertain the existence of suitable documentation (a specification) as described in [RFC8126] and to verify that the document is permanently and publicly available. The DE is also expected to check the clarity of purpose and use of the requested assignment. Additionally, the DE must verify that any request for one of these assignments has been made available for review and comment within the IETF: the DE will post the request to the SPRING Working Group mailing list (or a successor mailing list designated by the IESG). If the request comes from within the IETF, it should be documented in an Internet-Draft. Lastly, the DE must ensure that any other request for a code point does not conflict with work that is active or already published within the IETF.¶