]> Ciena

akarboub@ciena.com

Ciena

cengiz@ciena.com

Ciena

hshah@ciena.com

Ciena

ssivabal@ciena.com

Ciena

todd@ciena.com

Airtel India

Praveen.Maheshwari@airtel.com

General SPRING Working Group keyword1 keyword2 Service providers require delivery of circuit-style transport services in a segment routing based IP network. This document introduces a solution that supports circuit style segment routing policies that allows usage of optimized SID lists (i.e. SID List that may contain non-contiguous node SIDs as instructions) and describes mechanisms that would allow such encoding to still honor all the requirements of the circuit style policies notably traffic engineering and bandwidth requirements.

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 mandates using 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 uses the proposed extension to active path selection algorithm introduced in draft which allows a system to render the candidate path 1 ineligible for selection at the head-end node. Making a path eligible again would be 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 We use the eligibility concept introduced in . the head-end node is responsible for detecting failures , setting the eligibility to false and switching to the next candidate path within 50 milliseconds. 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 attribute that controls this new automated behavior of setting eligibility. An operator who plans to implement circuit style policies would enable this behavior, 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 attribute is set immediately to false. As per , 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. The recovery scheme for such policies is same as described in CS-SR draft , where such policies can be unprotected, use 1:N protection or protection combined with restoration. Note that this implies that head end node needs to detect end-to-end failures before any local repair (TI-LFA) or IP convergence occurs. There are various implementation ways to achieve this:

• Configure the CCV protocol (e.g. S-BFD or STAMP) for these SR Policies at a lower interval than the IP link BFD. This will not impact non-CS SR policies which will continue to benefit from TI-LFA local repairs with same detection/repair time as before. Note that CCV is mandatory for CS SR policies, so the only new addition imposed here is regarding its detection timer (i.e. inverted hierarchical fault detection where e2e fault is detected before 1-hop fault).
• Another implementation solution to circumvent the TI-LFA, is to disable TI-LFA for CS-SR based traffic. This can be achieved by using only flexAlgo Node SIDs that have TILFA disabled, so when computing SID List for a CS-SR Policies, only Nodes SIDs from flexAlgo with disabled TI LFA would be used. This will not require separate loopback for nodes, but simply defining a flexAlgo with TI-LFA disabled on all Nodes pertaining to CS-SR domain. So, in the case a link fails, (before the e2e failure could be detected) the PLR will perform the usual TI LFA post convergence path for standard SID and will not initiate TI-LFA for traffic destined to CS-SR SIDs. With this approach we only need to ensure that e2e detection is lower than IGP convergence time only.

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 attribute 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 once a better preferred path becomes available for selection, 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 reversion 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 attribute to true or false. The node is only allowed to set it to false for our use case.

Eligibility control attribute The second configuration is at the SR policy level and is used by head end node to determine whether the behavior described in is desirable or not (notably the head end disabling the eligibility of a path). This attribute is called eligibilityControl and when set to false (default) the head end node will not alter the eligibility setting of a CP.

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. Most of these changes, with the exception of restoration of down links, are typically done in maintenance-windows and under the supervision of an SDN controller. By performing these operations under the supervision of a controller, operator can work around their impacts on paths before making them. Such coordination would be necessary for existing MPLS-TP based solutions or CS-SR solution, as changes to these properties e.g. affinity or delay may cause an intent violation with original path, which needs to be reassessed. Such controller role providing automation and coordination between different layers and workflows is not uncommon and is beneficial for self-optimizing networks. Hence these kinds of changes are not the focus of this solution. Our focus is 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. Note that in absence of such algorithm (SID List being resilient to repairs), the paths could still be corrected by controller where upon link repair it would assess CS-SR policies and check if the newly repair link have caused any deviation from their intended paths and when such deviation is detected, a new SID List, that is expressing the intended path, is updated on head end. The drawback though is that deviation will be momentarily observed and traffic may be going on the repaired link until controller corrects the SID List.

Protocol and model changes

Active candidate path selection This is already covered in .

PCEP extensions The extensions defined in regarding the strict path enforcement (using strict adjacency SIDs) becomes optional. PCEP shall be extended to signal the new eligibility control and eligibility attributes defined above.

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

IANA considerations This document includes no request to IANA.

Security considerations TO BE ADDED

References Normative References Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Cisco Cisco Airtel India Ciena Nokia Cisco Cisco Airtel India Ciena Nokia Verizon Huwaei Technologies Juniper Bell Canada Ciena Ciena Ciena Nokia Cisco Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy.

Acknowledgements The authors would like to thank for his input and support.