SPRING Working Group A. Karboubi, Ed.
Internet-Draft H. Shah
Intended status: Informational S. Sivalaban
Expires: 1 September 2025 Ciena
A. Stone
Nokia
C. Schmutz
Cisco
28 February 2025
Eligibility Concept in Segment Routing Policies
draft-karboubi-spring-sr-policy-eligibility-01
Abstract
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.
Status of This Memo
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 1 September 2025.
Karboubi, et al. Expires 1 September 2025 [Page 1]
Internet-Draft Eligibility Concept in Segment Routing P February 2025
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem statement and illustrative examples: . . . . . . . . 4
3.1. Example 1 : Deviation from intent due to failures: . . . 4
3.2. Example 2 : Delay sensitive paths: . . . . . . . . . . . 6
4. The eligibility concept . . . . . . . . . . . . . . . . . . . 7
5. Protocol and model changes . . . . . . . . . . . . . . . . . 7
5.1. Active candidate path selection algorithm . . . . . . . . 7
5.2. PCEP extensions . . . . . . . . . . . . . . . . . . . . . 7
5.3. SR policy Yang changes . . . . . . . . . . . . . . . . . 7
5.4. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. 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.
Karboubi, et al. Expires 1 September 2025 [Page 2]
Internet-Draft Eligibility Concept in Segment Routing P February 2025
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.
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. 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
Karboubi, et al. Expires 1 September 2025 [Page 3]
Internet-Draft Eligibility Concept in Segment Routing P February 2025
3. Problem statement and illustrative examples:
3.1. 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
Karboubi, et al. Expires 1 September 2025 [Page 4]
Internet-Draft Eligibility Concept in Segment Routing P February 2025
+-----+ +-----+
+--------+ +--------+ +------+ +-------+
| | B | | | | E | |
| +--+--+ | | +-----+ |
| | | | |
+--+--+ +--+--+ +-+-+-+ +--+--+
| A | | | | | | |
| +-----+ G +------+ D | | Z |
+--+--+ +-----+ +-+-+-+ +---+-+
| | | |
| +-----+ | | +-----+ |
| | | | | | | |
+---------+ C +-------+ +-------+ F +-------+
+-----+ +-----+
SR Policy A-Z:
Candidate path1
SIDList1 [B,E,Z]
Candidate path2
SIDList2 [C,F,Z]
Figure 1: 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.
Karboubi, et al. Expires 1 September 2025 [Page 5]
Internet-Draft Eligibility Concept in Segment Routing P February 2025
+-----+ +-----+
+--------+ +---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]
Figure 2: SR policy CP1 deviation after link failure and IGP
convergence
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.
3.2. 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
Karboubi, et al. Expires 1 September 2025 [Page 6]
Internet-Draft Eligibility Concept in Segment Routing P February 2025
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.karboubi-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.
4. 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 [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.karboubi-spring-sidlist-optimized-cs-sr].
5. Protocol and model changes
5.1. Active candidate path selection algorithm
As described in Section 4, this proposal introduces a new criteria to
the active CP selection process described in section 2.9 of
[RFC9256].
5.2. 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.
5.3. 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.
Karboubi, et al. Expires 1 September 2025 [Page 7]
Internet-Draft Eligibility Concept in Segment Routing P February 2025
5.4. 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 [I-D.ietf-idr-sr-policy-safi] and
advertised/published/discovered via BGPLS
[I-D.ietf-idr-bgp-ls-sr-policy].
6. IANA considerations
This document includes no request to IANA.
7. Security considerations
TO BE ADDED
8. References
8.1. Normative References
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/rfc/rfc8402>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
8.2. Informative References
[I-D.karboubi-spring-sidlist-optimized-cs-sr]
Karboubi, A., Alaettinoglu, C., Shah, H., Sivalaban, S.,
and T. Defillipi, "Circuit Style Segment Routing Policies
with Optimized SID List Depth, Work in Progress, Internet-
Draft,draft-karboubi-spring-sidlist-optimized-cs-sr", 21
February 2025, <https://datatracker.ietf.org/doc/html/
draft-karboubi-spring-sidlist-optimized-cs-sr>.
Karboubi, et al. Expires 1 September 2025 [Page 8]
Internet-Draft Eligibility Concept in Segment Routing P February 2025
[I-D.ietf-idr-sr-policy-safi]
Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., and
D. Jain, "Advertising Segment Routing Policies in BGP,
Work in Progress, Internet-Draft,draft-ietf-idr-sr-policy-
safi-10", 7 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-
policy-safi>.
[I-D.ietf-idr-bgp-ls-sr-policy]
Previdi, S., Talaulikar, K., Dong, J., Gredler, H., and J.
Tantsura, "Advertisement of Segment Routing Policies using
BGP Link-State, Work in Progress, Internet-Draft, draft-
ietf-idr-bgp-ls-sr-policy-10", 9 December 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-
ls-sr-policy-10>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/rfc/rfc9256>.
Acknowledgements
The authors would like to thank Ketan Talaulikar for his review,
comments, and suggestions.
Contributors
Cengiz Alaettinoglu
Ciena
Email: cengiz@ciena.com
Todd Defillipi
Ciena
Email: todd@ciena.com
Ali Zafar
Cisco
Email: zali@cisco.com
Authors' Addresses
Amal Karboubi (editor)
Ciena
Email: akarboub@ciena.com
Karboubi, et al. Expires 1 September 2025 [Page 9]
Internet-Draft Eligibility Concept in Segment Routing P February 2025
Himanshu Shah
Ciena
Email: hshah@ciena.com
Siva Sivabalan
Ciena
Email: ssivabal@ciena.com
Andrew Stone
Nokia
Email: andrew.stone@nokia.com
Christian Schmutz
Cisco
Email: cschmutz@cisco.com
Karboubi, et al. Expires 1 September 2025 [Page 10]