Internet DRAFT - draft-zzd-idr-sr-policy-scheduling
draft-zzd-idr-sr-policy-scheduling
IDR L. Zhang, Ed.
Internet-Draft T. Zhou
Intended status: Standards Track J. Dong
Expires: 25 April 2024 Huawei
M. Wang
China Mobile
N. Nzima
MTN
23 October 2023
BGP SR Policy Extensions for Path Scheduling
draft-zzd-idr-sr-policy-scheduling-03
Abstract
Path scheduling is required in many network scenarios. For example,
some links or nodes will be shut down in the tidal network when the
traffic decreases, which may lead to the expiration of some routing
paths.
This document proposes extensions to BGP SR Policy to indicate the
enable time and disable time for routing paths to enable path
scheduling.
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 25 April 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhang, et al. Expires 25 April 2024 [Page 1]
Internet-Draft BGP SR Policy Scheduling October 2023
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. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Tidal network use case . . . . . . . . . . . . . . . . . 3
2.2. Resource utilization efficiency use case . . . . . . . . 4
3. Scheduling time information in SR Policy . . . . . . . . . . 4
4. Scheduling time information Sub-TLV . . . . . . . . . . . . . 6
4.1. ASTI sub-TLV . . . . . . . . . . . . . . . . . . . . . . 6
4.2. PSTI sub-TLV . . . . . . . . . . . . . . . . . . . . . . 7
5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. 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.
Zhang, et al. Expires 25 April 2024 [Page 2]
Internet-Draft BGP SR Policy Scheduling October 2023
[I-D.zzd-tvr-use-case-tidal-network] introduces the tidal network, in
which the topology of the network will change periodically over time.
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.
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. Therefore,
the SR policy originator can generate a policy with time-limited
paths and resources, the head node schedules these paths over time to
improve the utilization of resources.
This document proposes extensions to BGP SR Policy to indicate the
enable time and disable time of each candidate path/SR list. The
policy originator can deliver multiple paths with different valid
time. The ingress node determines the current valid paths based on
the arrival time of the packet and forwards along the path.
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. Motivation
This section describes the use cases that may benefit from scheduled
paths.
2.1. Tidal network use case
[I-D.zzd-tvr-use-case-tidal-network] introduces the time variant
routing scenario in the tidal network, in which 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.
Zhang, et al. Expires 25 April 2024 [Page 3]
Internet-Draft BGP SR Policy Scheduling October 2023
In this scenario, the SR policy originator can generate a policy with
several paths for different topology. 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.
2.2. Resource utilization efficiency use case
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. In
this scenario, the controller (originator of the SR policy) can
calculate a path with a valid time based on the flow duration. 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.
3. Scheduling time information in SR Policy
[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], this document extends the SR Policy to enable paths
scheduling.
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:
Zhang, et al. Expires 25 April 2024 [Page 4]
Internet-Draft BGP SR Policy Scheduling October 2023
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, so that all the segment list of each
condidate path have the same scheduling time. 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 Schduling time information also can be applied to each segment
list to indicate the valid time for each segment list, the new SR
Policy encoding structure is expressed as below:
Zhang, et al. Expires 25 April 2024 [Page 5]
Internet-Draft BGP SR Policy Scheduling October 2023
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
...
...
4. Scheduling time information Sub-TLV
The Scheduling time information sub-TLV has two formats according to
the change regularity of network topology. They are Aperiodic
Scheduling Time Information (ASTI) sub-TLV and Periodic Scheduling
Time Information (PSTI) sub-TLV.
4.1. ASTI sub-TLV
The ASTI sub-TLV indicates one or more valid time (each includes the
enable time and disable time) of one or more SR paths. The format of
ASTI 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 | Group Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Disable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Variable /
| |
Figure 1: ASTI sub-TLV
Zhang, et al. Expires 25 April 2024 [Page 6]
Internet-Draft BGP SR Policy Scheduling October 2023
Type: TBD1
Length: the size of the value field in octets.
Group Number: indicates the number of information groups, each
information group has fields of Index, Flags, Enable Time and Disable
time.
Index: the number used to identify specific information group. This
filed will be generated by the originate router.
Enable Time: the time in seconds indicates when the path(s) is(are)
enabled.
Disable Time: the time in seconds indicates when the path(s) is(are)
disabled
Variable: one or more groups of time information (A information group
is composed of Index, Flags, Enable Time and Disable time) may be
included in one ASTI sub-TLV.
4.2. PSTI sub-TLV
The PSTI sub-TLV indicates the enable time, disable time and period
of one or more paths. The format of PSTI 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 | Group Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Period |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Disable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Variable /
| |
Figure 2: PSTI sub-TLV
Type: TBD2
Zhang, et al. Expires 25 April 2024 [Page 7]
Internet-Draft BGP SR Policy Scheduling October 2023
Length: the size of the value field in octets.
Group Number: indicates the number of information groups, each
information group has fields of Index, Flags, Period, Enable Time and
Disable time.
Index: the number used to identify specific information group. This
filed will be generated by the originate router.
Period: the time in seconds between the enable time of one repetition
and the enable time of the next repetition.
Enable Time: the time in seconds indicates when the path(s) is(are)
enabled.
Disable Time: the time in seconds indicates when the path(s) is(are)
disabled
Variable: one or more groups of time information(A information group
is composed of Index, Flags, Period, Enable Time and Disable time)
may be included in one PSTI sub-TLV.
5. Procedures
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.
6. Security Considerations
These extensions to BGP SR Policy do not add any new security issues
to the existing protocol.
Zhang, et al. Expires 25 April 2024 [Page 8]
Internet-Draft BGP SR Policy Scheduling October 2023
7. IANA Considerations
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 | Aperiodic Scheduling Time | This |
| | Information (ASTI) sub-TLV | document |
+-------+----------------------------+-----------+
| TBD2 | Periodic Scheduling Time | This |
| | Information (PSTI) sub-TLV | document |
+-------+----------------------------+-----------+
Table 1
8. References
8.1. Normative References
[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/info/rfc9256>.
[I-D.ietf-idr-segment-routing-te-policy]
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-segment-
routing-te-policy-25, 26 September 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-
segment-routing-te-policy-25>.
[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/info/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/info/rfc8174>.
8.2. Informative References
[I-D.zzd-tvr-use-case-tidal-network]
Zhang, L., Zhou, T., Dong, J., and N. Nzima, "Use Case of
Tidal Network", Work in Progress, Internet-Draft, draft-
Zhang, et al. Expires 25 April 2024 [Page 9]
Internet-Draft BGP SR Policy Scheduling October 2023
zzd-tvr-use-case-tidal-network-02, 28 July 2023,
<https://datatracker.ietf.org/doc/html/draft-zzd-tvr-use-
case-tidal-network-02>.
[RFC8934] Chen, H., Ed., Zhuang, Y., Ed., Wu, Q., and D. Ceccarelli,
"PCE Communication Protocol (PCEP) Extensions for Label
Switched Path (LSP) Scheduling with Stateful PCE",
RFC 8934, DOI 10.17487/RFC8934, October 2020,
<https://www.rfc-editor.org/info/rfc8934>.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>.
Authors' Addresses
Li Zhang (editor)
Huawei
Beiqing Road
Beijing
China
Email: zhangli344@huawei.com
Tianran Zhou
Huawei
Email: zhoutianran@huawei.com
Jie Dong
Huawei
Email: jie.dong@huawei.com
Minxue Wang
China Mobile
Email: wangminxue@chinamobile.com
Nkosinathi Nzima
MTN
Email: Nkosinathi.Nzima@mtn.com
Zhang, et al. Expires 25 April 2024 [Page 10]
