Internet-Draft BGP SR Policy Scheduling July 2023
Zhang, et al. Expires 11 January 2024 [Page]
Workgroup:
IDR
Internet-Draft:
draft-zzd-idr-sr-policy-scheduling-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
L. Zhang, Ed.
Huawei
T. Zhou
Huawei
J. Dong
Huawei
M. Wang
China Mobile

BGP SR Policy Extensions for Path Scheduling

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 effective time and expiration 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 11 January 2024.

Table of Contents

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.

[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 effective time and expiration 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.

In this scenario, the SR policy originator can generate a policy with several paths for topology1 and topology2. 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 flow just lasts for a short period of time, but the TE path resources for the flow 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:

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:

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

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

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.

7. IANA Considerations

This document defines two new sub-TLV in the registry "BGP Tunnel Encapsulation Attribute sub-TLVs" to be assigned by IANA:

Table 1
Value Description Reference
TBD1 Aperiodic Scheduling Time Information (ASTI) sub-TLV This document
TBD2 Periodic Scheduling Time Information (PSTI) sub-TLV This document

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, , <https://www.rfc-editor.org/info/rfc9256>.
[I-D.ietf-idr-segment-routing-te-policy]
Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., Jain, D., and S. Lin, "Advertising Segment Routing Policies in BGP", Work in Progress, Internet-Draft, draft-ietf-idr-segment-routing-te-policy-20, , <https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-20>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <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, , <https://www.rfc-editor.org/info/rfc8174>.

8.2. Informative References

[I-D.zzd-tvr-use-case-tidal-network]
Zhang, L., Zhou, T., and J. Dong, "Use Case of Tidal Network", Work in Progress, Internet-Draft, draft-zzd-tvr-use-case-tidal-network-00, , <https://datatracker.ietf.org/doc/html/draft-zzd-tvr-use-case-tidal-network-00>.
[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, , <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, , <https://www.rfc-editor.org/info/rfc9012>.

Authors' Addresses

Li Zhang (editor)
Huawei
Beiqing Road
Beijing
China
Tianran Zhou
Huawei
Jie Dong
Huawei
Minxue Wang
China Mobile