BGP Flow Specification Extensions for Scheduling
Internet-Draft draft-zzd-idr-flowspec-scheduling-02
Li Zhang, Ed.
Huawei
Beiqing Road
Beijing
China
zhangli344@huawei.com
Tianran Zhou
Huawei
zhoutianran@huawei.com
Zhenqiang Li
China Mobile
lizhenqiang@chinamobile.com
Jie Dong
Huawei
jie.dong@huawei.com
03 November 2024
General
IDR
Internet-Draft
BGP Flow Specification allows conveying flow specifications and traffic Action/Rules associated to perform different actions based on the traffic features. One of the applications is to steer one specific flow into its specific path. However, in some scenarios, the traffic forwarding paths are not constant and change over time.
This document extends BGP Flow Specification with scheduling time information to identify the packets arrived at different time slot. Based on that, the headend can perform different actions at different time for the same traffic.
Introduction
[RFC8955] and [RFC8956] define the BGP [RFC4271] Flow Specification (FlowSpec) that allows conveying flow specifications and traffic Action/Rules associated. BGP Flow specifications are encoded within the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. Rules (Actions associated) are encoded in Extended Community attribute [RFC4360].
The existing traffic filter rules and actions in FlowSpec are always effective and will steer specific traffic into one path once been delivered to the headend. However, there are many scenarios that need to schedule routing paths in the network.
[RFC9657] introduces a set of use cases where the topology of the network changes predictably. 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. However, on a network with predictable topology changes, the ingress node 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 affected by topology changes.
This document extends BGP Flow Specification with scheduling time information to identify the packets arrived at different time slot. Based on that, the headend can perform different actions at different time for the same traffic.
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.
Motivation
[RFC9657] introduces the time variant network use cases, the tidal network is one of the typical time variant network scenarios. In the tidal network, the traffic volume varies greatly at different time. In order to reduce the power consumption, some of the links and nodes may be shut down when the traffic is at a low level.
In this scenario, the controller can generate a FlowSpec with scheduling time rule to identify the packets arriving time and corresponding paths. The headend doesn't need to wait for the advertisement of topology change and just steer traffic in to different paths based on the flowSpec with scheduling time information, the affection of topology change is minimized.
Scheduling Time Information in FlowSpecv1
[RFC8955] defines 12 Components to identify different traffics. Based on [RFC8955], this document defines a new Component to identify the arrival time of packets and perform different actions.
Encoding: <type (1 octet, TBD1), length (1 octet), scheduling time information (variable)+>
Defines the time information that matches the arrival time of packets. This component matches if the arrival time of an IP packet in the scope of scheduling time information.
Scheduling time information in FlowSpecv2
[I-D.ietf-idr-flowspec-v2] specifies BGP flow specification v2(FSv2) to address the issues detected during the deployment of BGP flow specification v1. It defines that the traffic filters are described in the format of sub-TLV and different traffic type have different filter sub-TLVs.
For the IP and VPN IP filters, FSv2 reused the components defined in [RFC8955], [RFC8956], and [I-D.ietf-idr-flowspec-srv6]. Therefore, the new component defined for FlowSpecv1 in Section 3 is also applicable for FlowSpecv2
For L2 Traffic, this document defines a new sub-TLV for L2 filters defined in Section 3 of [I-D.ietf-idr-flowspec-v2] to identify the arrival time of packets and perform different actions. The format of Scheduling Time sub-TLV is shown as follows:
Scheduling Time Sub-TLV

 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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                Scheduling Time Information                    /
|                                                               |

Type: TBD2
Length: the size of the value field in octets, variable.
Schedule Number: indicates the number of schedules.
Schedules Time information: one or more schedules, each schedule indicates when one or more time slots.
Scheduling Time Information
The format of Scheduling time information sub-TLV is shown as follows:
Schedule of SR Policy

 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  |    Priority   |    Reserved   |   Flags   |P|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          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 FlowSpec, this value is allocated by the FlowSpec generator.
Priority: 8-bit value, this field is used when there are multiple schedules valid at the same point. The higher value indicates higher priority and the default Preference value is 10.
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 FlowSpec 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 FlowSpec becomes ineffective. If the flag P=0, then it is the number of seconds since the Start Time, it indicates how long the FlowSpec take effect.
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.
Security Considerations
These extensions to BGP FlowSpec do not add any new security issues to the existing protocol.
IANA Considerations
IANA is requested to allocate a new type value for "Scheduling Time Information" Component in "Flow Spec Component Types" registry:
Value | Description | Reference
TBD1 | Scheduling Time Information | This document
IANA is requested to allocate a new type value for "Scheduling Time sub-TLV" in "L2 Flow Specification Component Types" registry[I-D.ietf-idr-flowspec-l2vpn]:
Value | Description | Reference
TBD2 | Scheduling Time sub-TLV | This document
References
Normative References
[RFC8955]

Dissemination of Flow Specification Rules
C. Loibl
S. Hares
R. Raszuk
D. McPherson
M. Bacher
December 2020
RFC 8955
DOI 10.17487/RFC8955
[RFC8956]

Dissemination of Flow Specification Rules for IPv6
C. Loibl, Ed.
R. Raszuk, Ed.
S. Hares, Ed.
December 2020
RFC 8956
DOI 10.17487/RFC8956
[RFC4760]

Multiprotocol Extensions for BGP-4
T. Bates
R. Chandra
D. Katz
Y. Rekhter
January 2007
RFC 4760
DOI 10.17487/RFC4760
[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
[RFC4271]

A Border Gateway Protocol 4 (BGP-4)
Y. Rekhter, Ed.
T. Li, Ed.
S. Hares, Ed.
January 2006
RFC 4271
DOI 10.17487/RFC4271
[RFC4360]

BGP Extended Communities Attribute
S. Sangli
D. Tappan
Y. Rekhter
February 2006
RFC 4360
DOI 10.17487/RFC4360
[RFC9657]

Time-Variant Routing (TVR) Use Cases
E. Birrane III
N. Kuhn
Y. Qu
R. Taylor
L. Zhang
October 2024
RFC 9657
DOI 10.17487/RFC9657
[I-D.ietf-idr-flowspec-v2]

BGP Flow Specification Version 2
Susan Hares
Hickory Hill Consulting
Donald E. Eastlake 3rd
Futurewei Technologies
Chaitanya Yadlapalli
ATT
Sven Maduschke
Verizon
28 April 2024
Internet-Draft draft-ietf-idr-flowspec-v2-04
[I-D.ietf-idr-flowspec-srv6]

BGP Flow Specification for SRv6
Zhenbin Li
Huawei
Huaimo Chen
Futurewei
Christoph Loibl
Next Layer Communications
Gyan Mishra
Verizon Inc.
Yanhe Fan
Casa Systems
Yongqing Zhu
China Telecom
Lei Liu
Fujitsu
Xufeng Liu
Volta Networks
Shunwan Zhuang
Huawei
16 October 2024
Internet-Draft draft-ietf-idr-flowspec-srv6-06
[I-D.ietf-idr-flowspec-l2vpn]

BGP Dissemination of L2 Flow Specification Rules
Hao Weiguo
Huawei Technologies
Donald E. Eastlake 3rd
Independent
Stephane Litkowski
Cisco Systems, Inc.
Shunwan Zhuang
Huawei Technologies
6 October 2024
Internet-Draft draft-ietf-idr-flowspec-l2vpn-24