Schedule for Segment Routing Policy
Internet-Draft draft-zzd-spring-schedule-sr-policy-00
Li Zhang, Ed.
Huawei
Beiqing Road
Beijing
China
zhangli344@huawei.com
Jie Dong
Huawei
jie.dong@huawei.com
Tianran Zhou
Huawei
zhoutianran@huawei.com
29 September 2024
General
SPRING
Internet-Draft
This document defines the Segment Routing (SR) Policy extension for schedule (called SR-Schedule). It applies to both Segment Routing over IPv6 (SRv6) and SR-MPLS. This document specifies the framework of SR policy schedule including the SR-Schedule definition, acquisition, computation, enforcement, and the handling behaviors on the headend.
Introduction
Segment Routing (SR) policy [RFC9256] is a set of candidate SR paths consisting of one or more segment lists and necessary path attributes. It enables instantiation of an ordered list of segments with a specific intent for traffic steering. [I-D.ietf-idr-segment-routing-te-policy] specifies how BGP may be used to distribute SR Policy candidate paths. It introduces a BGP SAFI with new NLRI to advertise a candidate path of a Segment Routing (SR) Policy.
[I-D.ietf-tvr-use-cases] introduces a set of use cases where the topology or attributes of the network changes predictably. The topology changes may influence tha validity of some paths, and lead to path reselection or even recalculation. However, the reselection or recalculation takes a period of time, which will influence packet forwarding and cause problems such as packet disorder and packet loss. However, on a network with predictable topology changes, the headend knows future topology changes, it can schedule the forwarding paths in advance, and steer flows to different set of paths based on time to prevent packet forwarding from being influenced by topology changes.
In the scenario of SR-policy-based TE paths, the resource allocation efficiency is a big challenge. Some flows just last for a short time, but the TE paths resources for the flows are usually reserved for a long time and cannot be used by other services. Therefore, the SR policy originator can generate a policy with time-limited paths and resources, the headend schedules these paths over time to improve the utilization of resources.
This document extends SR Policy to include the schedule time of candidate paths/SR lists and applies to both SRv6 and SR-MPLS.
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.
SR-Schedule Definition for SR Policy
The Segment Routing policy architecture is specified in [RFC9256]. An SR Policy is associated with one or more candidate paths. A candidate path is either dynamic, explicit, or composite. The related concepts with the SR-Schedule definition in this document are listed as follows.
An explicit/dynamic candidate path is expressed as a Segment-List or a set of Segment-Lists directly or by computation. If a candidate path is associated with a set of Segment-Lists, each Segment-List is associated with weight for weighted load balancing. The default weight is 1.
A composite candidate path is defined in [RFC9256].
SR-Schedule of a Segment List
A segment list represents a specific source-routed path to send traffic from the headend to the endpoint of the corresponding SR policy [RFC9256]. The SR-Schedule of a segment list is defined as the valid period of the path between a source node and a destination node.
SR-Schedule of a Candidate Path
In the case of an explicit/dynamic candidate path, if it is expressed as a single Segment-List, then the SR-Schedule of the candidate path is the same as that of the SR-Schedule of the segment list as described in Section 2.1.
In the case of an explicit/dynamic candidate path, if it is expressed as a set of Segment-Lists (for load-balancing), then the SR-Schedule of the candidate path is defined as the valid period of all the Segment-Lists in the set.
The Framework of SR-Schedule for SR Policy
Framework of SR-Schedule for SR Policy

The framework of SR-Schedule for SR Policy includes schedule information acquisition, SR-Schedule computation, SR-Schedule enforcement, and handling behaviors on the headend.

                           +------------------+
                           | Network Manager  |
                           +------------------+
                                     |
                         Schedule information acquisition
                                     |
                           +--------\|/-------+
              +------------|Network Controller| SR-Schedule computation
              |            +--------/|\-------+
              |                      |
SR-Schedule enforcement   Schedule information acquisition
              |                      |
           +-\|/-+       +-----------|-----------+   +-----+
 Handling  |Head |-------|    Segment Routing    |---|End  |
 behaviors |end  |       |    Network Domain     |   |Point|
           +-----+       +-----------------------+   +-----+

Schedule Information Acquisition
The SR-Schedule of a segment list is defined as the valid period of the path, see Section 2.1. The valid period of a path can be limited by a variety of factors, for example the flow’s predicted variation, the predicted availability of nodes and links. The schedule information could be acquired from the Network Manager or network devices by YANG data model or routing protocol advertisement.
SR-Schedule Computation
The schedule information is sent to the network controller or the headend where the SR-Schedule is computed. Depending upon the source of time constraint, the computation methods are different, which are described in the following subsections.
SR-Schedule Computation with Flow Constraint
When the flow with predictable time limit requests a SR path and the topology is stable, the SR-Schedule calculation only needs to consider the time limit of the flow. During calculation, the controller needs to calculate the optimal path that meets flow requirements, and then generate the SR-Schedule based on the flow variation regularity.
SR-Schedule Computation with Topology Constraint
When the flow is constant but the network topology changes predictably, the SR-Schedule calculation only needs to consider the topology change. During calculation, multiple paths need to be calculated based on flow requirements. The valid time of each path is the intersection of the available time of all nodes and links in the path. There must be no gap between two paths adjacent in time to ensure the transmission will not be interrupted.
SR-Schedule Computation with Mixed Constraint
When the requested flow has a predicable time limit and the topology also changes predictably, the SR-Schedule calculation needs to consider both the flow and topology time constraints. During calculation, the controller first obtains the period that needs to be covered according to the flow time constraint. Then, the controller calculates multiple paths that meet the flow's requirements. The valid time of each path is the intersection of the available time of all nodes and links in the path. There must be no gap between two paths adjacent in time to ensure the transmission will not be interrupted.
SR-Schedule Enforcement
SR Policy as per [RFC9256] does not include SR-Schedule in the SR Policy encoding structure. As specified in [I-D.zzd-idr-sr-policy-scheduling], the SR-Schedule is encoded in the SR policy structure as shown in Figure 2 and Figure 3. After the SR-Schedule computation, the SR-Schedule is enforced along with the SR Policy to the headend of the corresponding path.
SR Policy Structure with SR-Schedule at Candidate Path Level

SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
      Attributes:
         Tunnel Encapsulation Attribute (23)
            Tunnel Type: SR Policy (15)
                Binding SID
                SRv6 Binding SID
                Preference
                Priority
                Policy Name
                Policy Candidate Path Name
                Explicit NULL Label Policy
         -----> Scheduling Time Information (SR-Schedule)
                Segment List
                    Weight
                    Segment
                    Segment
                    ...
                ...

SR Policy Structure with SR-Schedule at Segment List Level

SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
      Attributes:
         Tunnel Encapsulation Attribute (23)
            Tunnel Type: SR Policy (15)
                Binding SID
                SRv6 Binding SID
                Preference
                Priority
                Policy Name
                Policy Candidate Path Name
                Explicit NULL Label Policy
                Segment List
          --------> Scheduling Time Information (SR-Schedule)
                    Weight
                    Segment
                    Segment
                    ...
                ...

Handling Behaviors on the Headend
After the SR Policy with SR-Schedule is computed, the headend performs the handling behaviors.
After obtaining the SR Policy with SR-Schedule, the headend needs to select the available paths at this moment according to the effective time of the candidate path and the segment list.
When a packet arrives, the headend encapsulates the segment list of the forwarding path in the packet header based on the available paths.
If no path is available at a certain time point, the SR Policy is considered malformed and should be logged with error.
Security Considerations
[RFC9256] specifies in detail the SR Policy construct (introduced in [RFC8402]) and its security considerations. The additional SR-Schedule attribute information can be sensitive in some deployments and could influence SR path setup, selection and switching with adverse effect. The protocol extensions that include SR-Schedule need to take this into consideration. This document does not define any new protocol extensions and thus does not introduce any further security considerations.
IANA Considerations
Acknowledgement
References
Normative References
[RFC9256]

Segment Routing Policy Architecture
C. Filsfils
K. Talaulikar, Ed.
D. Voyer
A. Bogdanov
P. Mattes
July 2022
RFC 9256
DOI 10.17487/RFC9256
[I-D.ietf-idr-segment-routing-te-policy]

Advertising Segment Routing Policies in BGP
Stefano Previdi
Huawei Technologies
Clarence Filsfils
Cisco Systems
Ketan Talaulikar
Cisco Systems
Paul Mattes
Microsoft
Dhanendra Jain
Google
23 October 2023
Internet-Draft draft-ietf-idr-segment-routing-te-policy-26
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
Informative References
[I-D.ietf-tvr-use-cases]

TVR (Time-Variant Routing) Use Cases
Edward J. Birrane
JHU/APL
Nicolas Kuhn
Thales Alenia Space
Yingzhen Qu
Futurewei Technologies
Rick Taylor
Ori Industries
Li Zhang
Huawei
29 February 2024
Internet-Draft draft-ietf-tvr-use-cases-09
[I-D.zzd-idr-sr-policy-scheduling]

BGP SR Policy Extensions for Path Scheduling
Li Zhang
Huawei
Tianran Zhou
Huawei
Jie Dong
Huawei
Minxue Wang
China Mobile
Nkosinathi Nzima
MTN
29 August 2024
Internet-Draft draft-zzd-idr-sr-policy-scheduling-05
[RFC8402]

Segment Routing Architecture
C. Filsfils, Ed.
S. Previdi, Ed.
L. Ginsberg
B. Decraene
S. Litkowski
R. Shakir
July 2018
RFC 8402
DOI 10.17487/RFC8402