| Internet-Draft | Schedule SR Policy | September 2024 |
| Zhang, et al. | Expires 2 April 2025 | [Page] |
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.¶
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 2 April 2025.¶
Copyright (c) 2024 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.¶
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.¶
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.¶
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].¶
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.¶
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 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|
+-----+ +-----------------------+ +-----+
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.¶
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.¶
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.¶
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.¶
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 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 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 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
...
...
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.¶
[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.¶