Circuit Style Segment Routing Policies with Optimized SID List Depth

Introduction Service providers require delivery of circuit-style transport services in a segment routing based IP network. introduces a solution that supports circuit style SR policies. However, the solution uses a fully specified SID list where the path is encoded using persistent or manually configured adjacency SIDs. Using a fully specified SID list causes a very large segment stack that may not be feasible for low-end edge devices often found in access networks. This document presents a solution that removes the fully specified SID list requirement while still maintaining the key features presented in . It enables use of compressed SID list (i.e. allows the use of node SIDs) in circuit-style SR policies. defines circuit-style SR as an SR policy with the following characteristics:

Persistent end-to-end traffic engineered paths that provide predictable and identical latency in both directions
Strict bandwidth commitment per path to ensure no impact on the Service Level Agreement (SLA) due to changing network load from other services
End-to-end protection (<50msec protection switching) and restoration mechanisms
Monitoring and maintenance of path integrity
Data plane remaining up while control plane is down

Note that for some service providers the bidirectional co-routed paths may not be necessary.

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 when, and only when, they appear in all capitals, as shown here.

Terminology SID : Segment Identifier SLA : Service Level Agreement SR : Segment Routing CS-SR : Circuit-Style Segment Routing PCE : Path Computation Element PCEP : Path Computation Element Communication Protocol

Problem statement: Issues with SID list compression A PCE computes a path for the service according to the network state and available capacity at that time. These paths are referred to as intended paths. It then compresses the intended path into SIDs using a combination of node and adjacency SIDs as defined in SR architecture . Nodes in the network forward packet to node SID N by using their IGP (or flex-algo) shortest paths to N. This is referred to as path expansion. At the time of installing the compressed SID list, this expansion and the intended path are identical. However, network changes, particularly link and/or node failures and repairs may cause the intended path and this path expansion to deviate resulting in a service's traffic to use resources on a path that the PCE did not reserve any bandwidth on, causing service degradation for both this service and the other services on that path. Both the failure and repair cases are illustrated using the example network topology of figure 1. An SR policy from node A to node Z with two diverse traffic engineered candidate paths was computed by PCE and signaled to head end node A resulting in the following intended paths and their respective compressed SID List:

Candidate path 1: intended path A-B, B-D, D-E, E-Z links and compressed as SID list B, E, Z
Candidate path 2: intended path A-C, C-D, D-F, F-Z links and compressed as SID list C, F, Z

SR policy with 2 diverse candidate paths

Deviation due to failures In Figure 2, link B-D fails. The expected circuit-style behavior is to start using the second candidate path. Though this path may be used initially, once the IGP converges, the candidate path 1 becomes valid as node B regains a shortest path to the next node SID E. Once the headend switches to the candidate path 1, the intended path and the expansion of the SID list which now becomes (A-B, B-G, G-D, D-E, E-Z) deviate. The service starts to use resources on B-G and G-D links where the PCE has not made a bandwidth reservation.

SR policy CP1 deviation after link failure and IGP convergence deviation from intended path due to failure Candidate path2 SIDList2 [C,F,Z] ]]> A possible solution to this is for PCE to monitor these deviations and correct the compressed SID lists. However, the PCE is not as real-time as the IGP (e.g. many BGP-LS implementations use periodic injection of IGP events into BGP) and PCE is burdened by many more services going over this link not just by the services originating at node A. As a result, relying on PCE to correct this behavior is not desired. This document proposes a simple extension to the active candidate path selection logic defined in which renders the candidate path 1 ineligible for selection at the head-end node. Making a path eligible again is the responsibility of the PCE. This is elaborated in .

Deviation due to repairs Figure 3 shows an example where a link B-E that was down at the time PCE computed the above two candidate paths is now repaired. When the link B-E repairs, the compressed SID list expands now to (A-B, B-E, E-Z) which is a deviation from the intended path. Though this path looks attractive, it may not have the bandwidth the service needs.

SR policy CP1 deviation after link repair and IGP convergence deviation from intended path due to repair Candidate path2 SIDList2 [C,F,Z] ]]> This document presents a SID compression algorithm that is resilient to such repairs. This is elaborated in .

Dealing with deviation due to failures In , the head-end node is responsible for detecting failures and switching to the next candidate path within 50 milliseconds. We introduce a new flag at the candidate path level called eligibility. When the head-end detects the path failure, it sets eligibility flag to false. Candidate path selection logic is modified so that eligibility flag must be considered as part of the candidate path validity check defined in ; that is only candidate paths with eligibility flag true must be considered valid. The eligibility of a path is also controlled by the PCE. The PCE may set it to true or false depending on whether the expanded SID list matches the intended path. When the link B-D in Figure 2 repairs, it is the responsibility of the PCE to set the eligibility of the candidate path 1 to true. This allows eligibility mechanism to work across IGP areas and BGP autonomous systems. We introduce a second property that controls this new behavior. An operator who plans to implement circuit style policies would enable this property, see

Head end node procedure The head-end node shall run a connectivity verification protocol as specified in section 7.1 of to determine path failure. When the head end detects a failure of a candidate path, the eligibility flag is set immediately to false. Head end node will no longer consider this candidate path in its active path selection logic no matter what other link/node failures and repairs and IP convergence may happen in the network. If another candidate path exists, the head end will switch to the next eligible candidate path per the active candidate path selection algorithm.

Controller/PCE component procedure The PCE also maintains an accurate view of the network topology in all IGP areas and BGP autonomous systems in the network. After the failures have been repaired, the candidate paths that have been set as not eligible by head-end nodes may now be eligible again. In this case, PCE will set the eligibility flag of these candidate paths to true. It is up to the SR policy head-end node to reselect the active candidate path after PCE changes eligibility of the candidate paths. The head end may either implement a standard revertive behavior whereby it can revert immediately or wait for a period of time or implement a non-revertive behavior whereby traffic is not switched back automatically until there is a failure on the currently active candidate path. This behavior may be controlled by a SP provider policy and is outside the scope of this document. A PCE may also set a candidate path as ineligible if it detects that the SID list when expanded is different from the intended path. This step is not mandatory when head-end is able to monitor all candidate paths for failures. But, this step is necessary for implementations that do not monitor the inactive candidate paths. This is an implementation detail. We allow PCE to set eligibility flag to true or false. The node is only allowed to set it to false.

Eligibility control flag The second configuration flag at the SR policy level is used by head end node to determine whether the behavior described in is desirable or not. This flag is called eligibilityControl and when set to false (default) the SR policy has the same original behavior as defined in .

Dealing with deviation due to repairs/changes Network improvements and node and/or link repairs can also result in segment list expansions and intended paths to deviate. Network improvement may include addition of brand new links or changes of link attributes such as metric, SRLG values, affinity values, etc. We assume these changes are done during maintenance-windows and under the supervision of an SDN controller and can be coordinated with the PCE directly. Hence, we focus on node and/or link repairs (not necessarily limited to the links used by the candidate paths). For repairs, we propose a segment compaction algorithm whose compaction is resilient to nodes and/or links repairs; that is the segment list expands to the same path before or after any of these down links in any combination repairs. Any algorithm that is resilient to repairs would work. We highlight one such algorithm in the next paragraph. While the PCE computes the intended path on current state of the network, the proposed segment compaction algorithm uses a network view where all down links are restored to produce the SID list for the intended path. This compaction may not be as short as the compaction with the restored links as down but has the property that it is resilient to repairs. That is, the SID list will always expand to the intended path. This property is independent of the order at which the links are repaired

Protocol and model changes

Active candidate path selection As described in , this proposal introduces a new criteria to the active CP selection criteria described in section 2.9 of .

PCEP extensions The extensions defined in regarding the strict path enforcement (using strict adjacency SIDs) becomes optional. PCEP shall be extended to signal the 2 new properties that are the eligibility flag and eligibility control flag of the SR policy candidate paths.

SR policy Yang changes The eligibility control and eligibility flags shall be added for the SR policy and candidate path YANG models respectively. NetConf RPC calls can be used to set eligibility flag of candidate paths to true or false.

IANA considerations This document includes no request to IANA.

Security considerations TO BE ADDED