| Internet-Draft | Eligibility Concept in Segment Routing P | February 2025 |
| Karboubi, et al. | Expires 25 August 2025 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 25 August 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [RFC9256] 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 Section 3.¶
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.¶
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¶
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¶
+-----+ +-----+
+--------+ +--------+ +------+ +-------+
| | B | | | | E | |
| +--+--+ | | +-----+ |
| | | | |
+--+--+ +--+--+ +-+-+-+ +--+--+
| A | | | | | | |
| +-----+ G +------+ D | | Z |
+--+--+ +-----+ +-+-+-+ +---+-+
| | | |
| +-----+ | | +-----+ |
| | | | | | | |
+---------+ C +-------+ +-------+ F +-------+
+-----+ +-----+
SR Policy A-Z:
Candidate path1
SIDList1 [B,E,Z]
Candidate path2
SIDList2 [C,F,Z]
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.¶
+-----+ +-----+
+--------+ +---xxx--+ +------+ +-------+
| | B | | | | E | |
| +--+--+ | | +-----+ |
| | | | |
+--+--+ +--+--+ +-+-+-+ +--+--+
| A | | | | | | |
| +-----+ G +------+ D | | Z |
+--+--+ +-----+ +-+-+-+ +---+-+
| | | |
| +-----+ | | +-----+ |
| | | | | | | |
+---------+ C +-------+ +-------+ F +-------+
+-----+ +-----+
SR Policy A-Z:
Candidate path1
SIDList1 [B,E,Z] --> 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 [RFC9256] 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.¶
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 [I-D.ietf-spring-sidlist-optimized-cs-sr]. 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.¶
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 [RFC9256]; 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 [I-D.ietf-spring-sidlist-optimized-cs-sr].¶
As described in Section 4, this proposal introduces a new criteria to the active CP selection process described in section 2.9 of [RFC9256].¶
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.¶
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 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 [I-D.ietf-idr-sr-policy-safi] and advertised/published/discovered via BGPLS [I-D.ietf-idr-bgp-ls-sr-policy].¶
This document includes no request to IANA.¶
TO BE ADDED¶