Internet DRAFT - draft-liu-spring-sr-policy-flexible-path-selection
draft-liu-spring-sr-policy-flexible-path-selection
SPRING Working Group Y. Liu
Internet Draft China Mobile
Intended status: Standards Track C. Lin
Expires: September 11, 2023 New H3C Technologies
S. Peng
Huawei Technologies
Y. Qiu
New H3C Technologies
March 10, 2023
Flexible Candidate Path Selection of SR Policy
draft-liu-spring-sr-policy-flexible-path-selection-01
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 11 2023.
Copyright Notice
Copyright (c) 2021 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
(http://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 Simplified BSD License text as described in
XXX, et al. Expire September, 2023 [Page 1]
Internet-Draft SR Policy Flexible Path Selection March 2023
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract
This document proposes a flexible SR policy candidate path selection
method. Based on the real-time resource usage and forwarding quality
of candidate paths, the head node can perform dynamic path switching
among multiple candidate paths in the SR policy.
Table of Contents
1. Introduction ................................................ 2
2. Terminology ................................................. 3
3. Background of requirements .................................. 3
4. Flexible Candidate Path Selection Method .................... 4
4.1. Threshold Parameters of Candidate Paths ................ 5
4.2. Rules for Selecting the Best Path ...................... 6
4.3. Flexible Candidate Path Selection Process .............. 7
5. Examples of Flexible Candidate Path Selection ............... 8
6. IANA Considerations ......................................... 9
7. Security Considerations ..................................... 9
8. References .................................................. 9
8.1. Normative References ................................... 9
8.2. Informative References ................................. 9
9. Acknowledgments ............................................ 10
Authors' Addresses ............................................ 11
1. Introduction
Segment routing (SR) [RFC8402] is a source routing paradigm that
explicitly indicates the forwarding path for packets at the ingress
node. The ingress node steers packets into a specific path according
to the Segment Routing Policy (SR Policy) as defined in [RFC9256].
An SR Policy may have multiple candidate paths that are provisioned
or signaled [I-D.ietf-idr-segment-routing-te-policy] [RFC8664] from
one of more sources. The tie-breaking rules defined in [RFC9256]
result in determination of a single "active path" in a formal
definition.
Refer to [RFC9256] only the active candidate path MUST be used for
forwarding traffic that is being steered onto that policy except for
certain scenarios such as fast reroute where a backup candidate path
may be used. A candidate path can be represented as a segment list
or a set of segment lists. If a set of segment lists is associated
with the active path of the policy, then the steering is per flow
XXX, et al. Expires September, 2023 [Page 2]
Internet-Draft SR Policy Flexible Path Selection March 2023
and weighted-ECMP (W-ECMP) based according to the relative weight of
each valid segment list.
According to the criteria for the validity of candidate paths
described in Section 5 of [RFC9256], as long as there is a valid
segment list in the active candidate path, the active candidate path
is still valid. When some segment lists of the active candidate
path are invalid, the active candidate path may still be valid, but
it may not continue to meet the actual forwarding requirements.
This document proposes a flexible SR policy candidate path selection
method. Based on the real-time resource usage and forwarding quality
of candidate paths, the head node can perform dynamic path switching
among multiple candidate paths in the SR policy.
2. Terminology
The definitions of the basic terms are identical to those found in
Segment Routing Policy Architecture [RFC9256].
3. Background of requirements
When some segment lists of the active candidate path are invalid,
according to [RFC9256], as long as there is a valid segment list in
the active candidate path, the active candidate path is still valid.
But the paths of remaining segment lists may not meet the SR policy
forwarding performance requirements, such as insufficient path
bandwidth. Even if there are other candidate paths with lower
preference that can meet the forwarding performance requirements in
the SR policy, the traffic will continue to be forwarded along the
original active candidate path.
Take the following SR Policy as an example to explain in detail the
problems existing in the current candidate path selection process.
SR Policy POL1
Candidate Path CP1
Preference 200
Segment List 1 <SID11...SID1i>, Weight 1
Segment List 2 <SID21...SID2j>, Weight 1
Segment List 3 <SID31...SID3k>, Weight 1
Candidate Path CP2
Preference 100
Segment List 4 <SID41...SID4i>, Weight 1
Segment List 5 <SID51...SID5j>, Weight 1
Segment List 6 <SID61...SID6k>, Weight 1
XXX, et al. Expires September, 2023 [Page 3]
Internet-Draft SR Policy Flexible Path Selection March 2023
There are two candidate paths CP1 and CP2 in SR policy POL1. CP1 has
a higher preference. Both candidate paths are composed of three
segment lists with the same weight. The path indicated by each
segment list can carry traffic of 100M bandwidth. When the Segment
Lists are valid, the candidate path can carry traffic with bandwidth
less than 300M.
The bandwidth of the actual traffic forwarded by the SR policy is
between 100M and 150M. Because the traffic forwarded on the
candidate path will share the load on the three segment list paths
according to the weight value. Therefore, normally, the candidate
path can meet the forwarding requirements. The traffic is forwarded
on the three segment lists of the high preference candidate paths of
the SR policy.
When the segment list 1 and 2 in the high-preference candidate path
CP1 are invalid, according to the candidate path validity criteria
described in [RFC9256] Section 5, because the segment list 3 in CP1
is still valid, the active candidate path CP1 is still valid. All
traffic of SR policy POL1 will continue to be forwarded based on the
path of CP1. However, because segment list 3 can only forward 100M
traffic, over-bandwidth traffic will be discarded.
Of course, when the Segment List path fault is detected, the network
device can report the detected fault information to the controller.
The controller optimizes the forwarding path after receiving the
message. However, this interaction process is relatively long, and
it is difficult to meet the requirement for fast switching.
To solve this problem, this document proposes a new candidate path
selection rule, which sets resource thresholds and forwarding
quality requirements for candidate path. This candidate path can
only be selected if the current path can meet the preset
requirements.
4. Flexible Candidate Path Selection Method
As described in [RFC9256], the candidate path selection process
operates primarily on the candidate path Preference. A candidate
path is selected when it is valid and it has the highest Preference
value among all the valid candidate paths of the SR Policy.
In the case of multiple valid candidate paths of the same Preference,
the tie-breaking rules are evaluated on the identification tuple in
the following order until only one valid best path is selected:
1. The higher value of Protocol-Origin is selected.
XXX, et al. Expires September, 2023 [Page 4]
Internet-Draft SR Policy Flexible Path Selection March 2023
2. If specified by configuration, prefer the existing installed
path.
3. The lower value of the Originator is selected.
4. Finally, the higher value of the Discriminator is selected.
This document proposes to take the forwarding quality requirements
and resource requirements of candidate paths as the selection
criteria of candidate paths.
Set the threshold parameters of forwarding quality and resources for
candidate paths. First, find the paths that meet the threshold from
the candidate paths of SR policy, and then select the best path as
the active path according to the rules in the above standards.
4.1. Threshold Parameters of Candidate Paths
The threshold parameters of candidate paths can include but are not
limited to the following:
Jitter
Latency
Packet loss
If there are multiple segment lists in the candidate path, as long
as the delay, jitter or packet loss rate parameters of any valid
segment list in the candidate path fail to meet the specified
threshold requirements, it is considered that the candidate path
does not meet the threshold requirements.
Available bandwidth
If there are multiple segment lists in the candidate path, the
available bandwidth is the sum of all valid segment lists in the
candidate path, or the cumulative value calculated based on the
weight and bandwidth of each segment list.
Bandwidth utilization
Current flow rate
Ratio of valid segment lists in candidate path
This parameter reflects the failure ratio of the segment list in
the candidate path.
XXX, et al. Expires September, 2023 [Page 5]
Internet-Draft SR Policy Flexible Path Selection March 2023
The higher ratio of valid segment lists, the candidate path is
more robust.
If the weight of the segment list is different, a threshold for each
segment list separately can be specified. The threshold of the
candidate path is the sum of the thresholds of the segment list
calculated based on the weight.
When multiple threshold parameters are specified on the candidate
path at the same time, the candidate path is considered to meet the
threshold requirements only if all the threshold requirements are
met.
If the candidate path does not specify any threshold parameters,
select the primary candidate path according to the selection method
defined in RFC9256.
By default, there is no threshold parameter specified on the
candidate path.
4.2. Rules for Selecting the Best Path
When the current forwarding quality and hardware resources of a
candidate path meet the specified threshold requirements, it only
means that this candidate path has the ability to forward traffic.
If there are multiple candidate paths in the SR policy that meet the
forwarding requirements at the same time, the candidate paths need
to be sorted to select the best one.
Under the condition that multiple valid candidate paths meet the
threshold requirements, evaluate the tie-breaking rules in the following
order until only one valid best path is selected:
1. If the quality requirements of the candidate path are specified,
it is necessary to check whether the path meets the quality
requirements. Only the valid path that meets the quality
requirements can be selected as the active path.
If only one path in the SR policy meets the quality requirements,
the path is selected.
If multiple candidate paths meet the quality requirements at the
same time, or if all candidate paths fail to meet the
requirements, then select the following second step according to
the Preference.
2. The higher value of the Preference is selected.
XXX, et al. Expires September, 2023 [Page 6]
Internet-Draft SR Policy Flexible Path Selection March 2023
3. The higher value of Protocol-Origin is selected.
4. If specified by configuration, prefer the existing installed
path.
5. The lower value of the Originator is selected.
6. Finally, the higher value of the Discriminator is selected.
4.3. Flexible Candidate Path Selection Process
The process of selecting the best path for SR policy through the
threshold parameter of the path is as follows.
1. Configure the threshold parameters on the candidate path of the
head node through static manual configuration or controlled
distribution.
2. The head node monitors whether the available resources and
forwarding quality of the SR policy candidate path exceed the
thresholds.
The forwarding quality of path can be obtained through active or
passive performance measurement methods, such as iOAM, STAMP,
TWAMP, etc. The real-time quality data can be calculated by the
controller and distributed to the head node, or calculated by the
head node according to the network measurement data. The
measurement method and quality data acquisition method are beyond
the scope of this document.
3. According to the rules described in Section 4.2, when the
available resources are less than the threshold, or the
forwarding quality cannot meet the threshold requirements, select
a new active candidate path.
4. After the old active candidate path eliminates the fault or
improves the forwarding quality, whether to recover can be
specified by the configuration. If fault recovery is required,
start a wait timer for delay recovery. If the timer expires and
the old candidate path still meets the threshold requirements,
the traffic will be switched to the old higher preference
candidate path.
For avoiding path switching frequently, both over-threshold
switching and fault recovery should be delayed. The interval of
delay waiting can be adjusted by configuration.
XXX, et al. Expires September, 2023 [Page 7]
Internet-Draft SR Policy Flexible Path Selection March 2023
In order to distribute the threshold parameters of SR Policy to the
head node, it may be necessary to extend the control plane, such as
NetConf, PCEP and BGP. This document does not limit the specific
distribution method. The specific control plane extension will be
described in other documents.
5. Examples of Flexible Candidate Path Selection
The SR policy in Section 3 is still used to illustrate how the
flexible candidate path selection method switches candidate paths.
SR policy POL1 has two candidate paths CP1 and CP2. The Preference
of CP1 is 200, and the Preference of CP2 is 100. Both candidate
paths are composed of three segment lists with the same weight.
The path indicated by each segment list can carry traffic of 100M
bandwidth. When the Segment Lists are valid, the candidate path can
carry traffic with bandwidth less than 300M. The bandwidth of the
actual traffic forwarded by the SR policy is between 100M and 150M.
SR Policy POL1
Candidate Path CP1
Preference 200
Available bandwidth ratio 50
Segment List 1 <SID11...SID1i>, Weight 1
Segment List 2 <SID21...SID2j>, Weight 1
Segment List 3 <SID31...SID3k>, Weight 1
Candidate Path CP2
Preference 100
Available bandwidth ratio 50
Segment List 4 <SID41...SID4i>, Weight 1
Segment List 5 <SID51...SID5j>, Weight 1
Segment List 6 <SID61...SID6k>, Weight 1
First, take the available bandwidth as the threshold parameter of
POL1. The threshold for configuring the ratio of available bandwidth
is 50%. When the available bandwidth of the candidate path is less
than 50%, path switching is performed.
Normally, the three segment lists of CP1 and CP2 are valid. The
available bandwidth of CP1 is 300M, and the ratio of available
bandwidth is 100%, which can meet the threshold requirements of the
path. So CP1 is selected as the active candidate path according to
the Preference.
If the paths indicated by Segment 1 and 2 fail, Segment List 1 and 2
become invalid, and the available bandwidth of CP1 becomes 100M. The
ratio of available bandwidth becomes 33.3% (i.e. 100/300). Because
XXX, et al. Expires September, 2023 [Page 8]
Internet-Draft SR Policy Flexible Path Selection March 2023
the ratio of available bandwidth of CP1 is lower than the specified
threshold, CP1 has failed to meet the forwarding quality
requirements. Need to reselect the active candidate path for POL1.
The three segment lists of the low-preference candidate path CP2 of
POL1 are valid, and the available bandwidth can meet the threshold
requirements. CP2 is selected as the new active candidate path of
POL1. The traffic forwarded by POL1 is switched to the path of CP2
for forwarding.
6. IANA Considerations
This document has no IANA actions.
7. Security Considerations
This document does not introduce any security considerations.
8. References
8.1. Normative References
[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", draft-ietf-
idr-segment-routing-te-policy-20 (work in progress), July
2022.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
Hardwick, J., "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC8664,
DOI 10.17487/RFC8664, December 2019, <https://www.rfc-
editor.org/info/rfc8664>.
[RFC9256] Filsfils, C., Talaulikar, K., 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>.
8.2. Informative References
TBD
XXX, et al. Expires September, 2023 [Page 9]
Internet-Draft SR Policy Flexible Path Selection March 2023
9. Acknowledgments
The authors would like to thank the following for their valuable
contributions of this document:
TBD
XXX, et al. Expires September, 2023 [Page 10]
Internet-Draft SR Policy Flexible Path Selection March 2023
Authors' Addresses
Yisong Liu
China Mobile
Beijing
China
Email: liuyisong@chinamobile.com
Changwang Lin
New H3C Technologies
Beijing
China
Email: linchangwang.04414@h3c.com
Shuping Peng
Huawei Technologies
Beijing
China
Email: pengshuping@huawei.com
Yuanxiang Qiu
New H3C Technologies
Beijing
China
Email: qiuyuanxiang@h3c.com
XXX, et al. Expires September, 2023 [Page 11]
