]> Ciena

akarboub@ciena.com

Ciena

hshah@ciena.com

Ciena

ssivabal@ciena.com

Nokia

andrew.stone@nokia.com

Cisco

cschmutz@cisco.com

Airtel India

Praveen.Maheshwari@airtel.com

General SPRING Working Group keyword1 keyword2 Segment Routing (SR) introduces new challenges for pinning candidate paths on their intended paths (the path the PCE computed based on provided intent and may have made bandwidth reservations on). The actual path through a network can change or no longer meet the required constraints if a SID list of an SR Policy candidate path is not fully expressed as a list of adjacency SIDs or when a change in the topology does happen. The introduction of the new candidate path eligibility concept permits a path to be signaled and established as operationally up, but controls whether the path is eligible to carry traffic, thus influencing its active state.
The eligibility concept allows a system (operator, pce, headend, etc.) to set eligibility as false when path deviations may have occurred, or path constraints are no longer met for one or more SID lists of a candidate path and clear it when candidate path deviations are removed or constraints are met again.

Introduction Service providers require that services are delivered on traffic engineered transport such as SR enabled network. This requires path computations carried out by PCE or ingress PE based on operator defined constraints that reflect the service level agreements (SLAs) provided to client. The examples of such constraints are guaranteed bandwidth, end-to-end delay or other topology constraints. This document introduces a concept of an eligibility attribute at the candidate path level, not only at the time of the computation but also through topology and network changes to ensure that user intentions are preserved while carrying service traffic. The eligibility attribute of the candidate path is then used as an additional mandatory criteria by the head-end during the selection process of active CP in addition to rules specified in section 2.9. For example, there could exist a candidate path with highest preference, with validated SID list that is operationally up, and OAM monitored but not eligible for selection as active path based on eligibility attribute set to false. Note that this document focuses on introduction of eligibility concept, and not necessarily the in-depth use cases description or the criteria that should alter the eligibility of a candidate path; these shall be described in their appropriate use case document to detail the behavior for setting and clearing the path eligibility. It also worth noting that eligibility of a path may be set/unset by various actors and various conditions. (e.g. ingress PE setting path as ineligible based on S-BFD and PCE setting it as eligible based on link recovery or other condition). We present some examples and use cases in .

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 and illustrative examples:

Example 1 : Deviation from intent due to failures: 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. 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 may cause the intended path and this path expansion to deviate resulting in a service 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. Note that BW is given here as a constraint example only, the deviation could be causing longer delays or violating other service based constraints. 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 SID List:

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

SR policy with 2 diverse candidate paths

In Figure 2, link B-D fails. The expected 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] ]]>

This document proposes a simple extension to the active candidate path selection algorithm defined in which renders the candidate path 1 ineligible for selection at the head-end node when system determines that traffic shall not be using this path even if it seems valid. In the example above, a system could set the CP1 eligibility as false when it detects path failure via some CCV mechanism (e.g. S-BFD, STAMP, etc.) rendering path ineligible for selection, the path may become operationally up after IGP convergence, but it will remain unavailable for selection until the eligibility is cleared.

Example 2 : Delay sensitive paths: Using same policy example illustrated in figure 1, the policy could have a constraint to not use a path when its end-end delay exceeds a given value D1. A link B-D for example while still up, could have its delay value increased so that overall policy delay now exceeds D1. The expected behavior is to start using the second candidate path as its delay is meeting the original constraint. In this case, a system could set the eligibility as false when it detects that path delay exceeds D1 (e.g. using STAMP) rendering path ineligible for selection, and because the path is still operationally up and monitored by STAMP, when the delay condition clears, the system could clear the eligibility for the monitored path. Note that the above examples are for illustration purposes only, The entities acting on the eligibility and its conditions are outside the scope of this document and would be covered under separate use case documents such as . Note that it is important to keep the path operationally up and under the purview of any OAM/CCV as we may rely on OAM protocol (e.g. STAMP measuring e2e delay) to determine the eligibility of the CP.

The eligibility concept We introduce a new attribute at the candidate path level called eligibility. Candidate path selection logic is modified so that eligibility must be considered as part of the active candidate path selection defined in ; that is, only candidate paths with eligibility as true, must be considered for carrying traffic. The eligibility of a path can be controlled by head end, a PCE or user, this is outside the scope of this document, but one such use case is defined under . Usually marking a path as ineligible can be triggered by a distinct set of conditions (e.g. delay OR path deviation) and the responsibility for setting ineligibility can be split amongst different components, but it is advisable that the clearing of eligibility is ideally performed by a single component having visibility of all conditions (user intent) and not split it amongst distinct components as all conditions need to be met prior to marking path as eligible again. In case an implementation or use case requires the clearing of eligibility to be also split between distinct components care needs to be taken when clearing eligibility to make sure all conditions controlled by all components are met prior to clearing the path to carry traffic. The current proposal does not introduce a preference between the components acting on this attribute, nor the protocol used to set it. If multiple components are permitted to reset the eligibility flag, the interworking communication between those components to determine if or when eligibility can be restored is out of scope of this document and would be be covered on use case document itself.

Protocol and model changes

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

PCEP extensions PCEP shall be extended to signal the new attribute representing the eligibility of an SR Policy candidate path. A PCE shall be able to change the eligibility status of a delegated LSP and be notified of changes on the eligibility.

SR policy Yang changes The eligibility attribute will need to be added to the SR policy candidate path YANG models.
NetConf RPC calls can be used to set eligibility of candidate paths to true or false.

BGP BGP extensions shall be required to signal and discover the new attribute representing the eligibility of an SR Policy candidate path. SR Policy CP are sent down via and advertised/published/discovered via BGPLS .

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 Ciena Ciena Ciena Ciena Ciena Huawei Technologies Cisco Systems Cisco Systems Microsoft Google Individual Cisco Systems Huawei Technologies RtBrick Inc. Nvidia 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 review, comments, and suggestions.

Contributors Ciena

cengiz@ciena.com

Ciena

todd@ciena.com

Cisco

zali@cisco.com