| Internet-Draft | BGP SR Policy Scheduling | October 2024 |
| Zhang, et al. | Expires 24 April 2025 | [Page] |
Segment Routing (SR) policy enables instantiation of an ordered list of segments with a specific intent for traffic steering. However, more and more cases require path scheduling to improve the network availability and resource utilization.¶
This document proposes extensions to BGP SR Policy to indicate the scheduling time of each candidate path(segment list) and its associated attributes.¶
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 24 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.¶
In tidal network, the topology of the network will change periodically over time to reduce energy consumption[RFC9657]. The topology change may cause some of the paths invalid, and lead to path reselection or even recalculation. However, the reselection or recalculation takes a period of time, which will affect packet forwarding and cause problems such as packet disorder and packet loss. Therefor, some actions should be token to requece the impact of predicted topology changes.¶
[RFC8934] extends the stateful PCE Communication Protocol (PCEP) to enable Label Switched Path (LSP) path computation, activation, setup, and deletion based on scheduled time intervals for the LSP and the actual network resource usage in a centralized network environment so as to improve the resource utilization efficiency. Similar with [RFC8934], 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 can not be used by other services.¶
In order to solve these problesm, this document proposes extensions to BGP SR Policy to indicate the scheduling time of each candidate path(segment list) and its associated attributes. The policy originator can deliver multiple paths with different valid time to the headend. The headend determines the current valid paths based on the arrival time of the packet and forwards along the path.¶
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.¶
This section describes the use cases that may benefit from scheduled paths.¶
[RFC9657] introduces the time variant network use cases, the tidal network is one of the typical time variant network scenarios. In the tidal network, in which the traffic volume varies greatly at different time.¶
In the tidal network, some links and nodes are shutdown when the traffic at a low level. In this case, the availability of nodes and links will affect the forwarding path of traffic, the packet loss will occur if the headend can’t react to these changes in time. Therefore, the scheduling time information of each candidate path or segment list can be added to the SR Policy to describe the valid period. The ingress node doesn’t need to wait for the advertisement of topology change and just changes the forwarding path based on the valid time of each path, the affection of topology change is minimized.¶
Traditionally, the usage and allocation of network resources, especially bandwidth, can be supported by a Network Management System (NMS) operation such as path pre-establishment. However, this may not provide efficient usage of network resources. The established paths may reserve the resources for a long time. During this period, the resources cannot be used by other services even when they are not used for transporting any service.¶
In the scenario of SR-policy-based TE path, the resource allocation efficiency is also a problem. Some flows just last for a short period of 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 scheduling time information of each candidate path or segment list can be added to the SR Policy to describe the valid(invalid) period. When the TE path is invalid, the ingress node does not steer any packets to the path and releases the resources. Furthermore, the controller can use the resource released by the flow to plan TE paths for other flows that do not have overlap time, which can effectively improve the utilization of network resources.¶
The NLRI defined in [I-D.ietf-idr-segment-routing-te-policy] contains the SR Policy candidate path. The content of the SR Policy Candidate Path is encoded in the Tunnel Encapsulation Attribute defined in [RFC9012] using a new Tunnel-Type called SR Policy Type with codepoint 15. The SR Policy encoding structure is as follows:¶
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 (ENLP)
Segment List
Weight
Segment
Segment
...
...
¶
A candidate path includes multiple SR paths, each of which is specified by a segment list. The Scheduling time information can be applied to the candidate path, to indicate the valid time for each candidate path and its associated attributes. The new SR Policy encoding structure is expressed as below:¶
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 (ENLP)
Scheduling Time Information
Segment List
Weight
Segment
Segment
...
...
¶
The Scheduling time information also can be applied to each segment list to indicate the valid time for each segment list and its associated attributes. The new SR Policy encoding structure is expressed as below:¶
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 (ENLP)
Segment List
Scheduling Time Information
Weight
Segment
Segment
...
...
¶
The Scheduling time information sub-TLV indicates one or more valid time slot for one or more SR paths. The format of Scheduling time information sub-TLV is shown as follows:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved |Schedule Number| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Schedules / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD1¶
Length: the size of the value field in octets.¶
Schedule Number: indicates the number of schedules.¶
Schedules: one or more schedules, each schedule indicates the duration when the candidate path(segment list) is active. The format of each schedule is shown as follows:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Schedule-id | Flags |P|S| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End Time (Duration) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End Time (Duration) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frequency (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Recurrence count(Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Schedule-id: 8-bit value, the unique identifier to distinguish each schedule within a SR Policy, this value is allocated by the SR Policy generator.¶
Flags: 8 bits, currently only 2 bits are used, the other bits are reserved.¶
P (Period format): one-bit flag to indicate the format of a period. if P=1, then the period is described by a start time filed and an end time field; If P =0, then the period is described by a start time field and a duration time field.¶
S (Schedule type): one-bit flag to indicate the type of a schedule. If S=0, it indicates the schedule only has one instance, the Frequency and Recurrence count field should not be included in the sub-TLV; If S=1, it indicates the schedule has multiple instances, the Frequency and Recurrence count field should be included.¶
Start Time: 64-bit value, the number of seconds since the epoch, it indicates when the candidate path (segment list) and its associated attributes start to take effect.¶
End Time (Duration): 64-bit value, if the flag P=1, then it is the number of seconds since the epoch, it indicates when the candidate path (segment list) and its associated attributes becomes ineffective. If the flag P=0, then it is the number of seconds since the Start Time, it indicates how long the candidate path (segment list) and its associated attributes are effective.¶
Frequency(optional): 32-bit value, it is the numbers of seconds since the Start Time of an instance to the Start Time of next instance. This field indicates the recurrence frequency for all the instance of this schedule. This field should not be included if S=0.¶
Recurrence Count(optional): 32-bit value, it indicates the number of occurrences. For example, if it is set to 2, then the schedule will repeat twice with the specified Frequency. This field should not be included if P=0.¶
When a SR Policy head node receives a SR Policy with scheduling time information, the head node will parse the SR Policy and save the scheduling time information locally. When a data packet arrives, the head node will steer it to a specific SR Policy by color or other means.¶
Within a specific SR Policy, there are two ways for the head node to determine the final forwarding SR path:¶
Option 1: A valid SR path is dynamically determined based on the packet arrival time whenever a packet arrives.¶
Option 2: One or more valid paths are selected for the SR policy and one or more timers are set based on the path disable time. When the timer expires, packets steered to this SR policy are switched to another path.¶
These extensions to BGP SR Policy do not add any new security issues to the existing protocol.¶
This document defines two new sub-TLV in the registry "BGP Tunnel Encapsulation Attribute sub-TLVs" to be assigned by IANA:¶
| Value | Description | Reference |
|---|---|---|
| TBD1 | Scheduling Time Information (STI) sub-TLV | This document |