| Internet-Draft | SR Policy Flexible CP Selection | October 2026 |
| Liu, et al. | Expires 16 April 2027 | [Page] |
This document describes a flexible method for selecting candidate Segment Routing (SR) policy paths. 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.¶
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 16 April 2027.¶
Copyright (c) 2026 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) [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 [RFC9830] [RFC8664] from one or more sources. The tie-breaking rules defined in [RFC9256] result in determination of a single "active path" in a formal definition.¶
According to [RFC9256] the head node must use only the active candidate path for forwarding traffic that is being steered onto a specific 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 a policy, then the steering of traffic onto the different segment lists is per flow and is based on weighted-ECMP (W-ECMP) according to the relative weight of each segment list.¶
According to the criteria for the validity of candidate paths described in Section 5 of [RFC9256], if there is a valid segment list in the active candidate path, the active candidate path is valid. When some segment lists of the active candidate path are not valid, the active candidate path may still be valid, but it might not continue to meet the actual forwarding requirements.¶
[I-D.ietf-spring-sr-policy-eligibility] introduces the concept of an eligibility attribute at the candidate path level, not only at the time of the path computation, but also through topology and network changes to ensure that user intentions are preserved while carrying service traffic.¶
This document specifies a comprehensive quality-driven candidate path switching mechanism. It primarily focuses on defining the precise conditions, operational rules, and dynamic procedures required for performance-driven management. The framework enables autonomous system behavior based on real-time quality assessments, ensuring reliable and adaptive network operations in response to fluctuating performance conditions.¶
Based on real-time resource usage and the forwarding quality of candidate paths, the head node can dynamically adjust the eligibility attribute value, enabling it to dynamically switch traffic onto different paths among multiple candidate paths within the SR policy.¶
[RFC2386] provides valuable background on QoS-based routing, details some issues and requirements associated with QoS-based routing, and describes a framework for employing QoS-based routing within the Internet. This document describes an SR Policy mechanism where the traffic is switched between paths based on the resource status of the traversed path. However, it does not address the challenges related to dynamic distributed scheduling or resource reservation along intermediate paths. The document specifies the capability to switch to alternative paths within a strategy when the current path fails to satisfy designated link quality criteria, such as bandwidth, delay, or packet loss. In instances where a controller issues an SR Policy encompassing multiple paths, should a path's link quality not meet the established requirements, a switch to a backup path for forwarding is executed.¶
The definitions of the basic terms are identical to those found in Segment Routing Policy Architecture [RFC9256].¶
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.¶
When some segment lists of the active candidate path are not valid, according to [RFC9256], if 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.¶
As an example, consider the following SR Policy to illustrate the issues present in the current candidate path selection process in detail.¶
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
¶
There are two static candidate paths CP1 and CP2 in SR policy POL1. CP1 has a higher preference. Both candidate paths are composed of three static segment lists with the same weight. The path indicated by each segment list can carry traffic of 100Mbps bandwidth. When all Segment Lists in CP1 are valid, the effective bandwidth of the candidate path is 300Mbps.¶
Suppose the bandwidth of the actual traffic forwarded by the SR policy is between 100Mbps and 150Mbps. Because the traffic forwarded on the candidate path will share the load on the three segment list paths according to the weight value, the candidate path can meet the forwarding requirements. The traffic is forwarded on the three segment lists of the higher preference candidate paths of the SR policy.¶
When segment lists 1 and 2 in the high-preference candidate path CP1 are not valid, according to the candidate path validity criteria described in [RFC9256] Section 5, because 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 through the path of CP1. However, because segment list 3 can only forward 100Mbps 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 switch-over.¶
When the quality of the high-preference candidate paths deteriorates, due to issues such as insufficient available bandwidth, increased end-to-end transmission delay, or segment lists that fail to meet service requirements, the same need arises. The goal is to switch traffic to other lower preference candidate paths within the SR policy that better satisfy the forwarding quality requirements.¶
To address this issue, this document proposes a new candidate path selection rule that defines resource thresholds and forwarding quality requirements for candidate paths.¶
During the active candidate path (CP) selection process, the head node uses the eligibility attribute as an additional mandatory criterion, in conjunction with the rules defined in [RFC9256], Section 2.9: a candidate path whose eligibility attribute is false is not considered for active CP selection. The rules for setting the eligibility attribute are specified in Section 4.3.¶
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.¶
[I-D.ietf-spring-sr-policy-eligibility] introduces a new attribute at the candidate path level called Eligibility. Only candidate paths with Eligibility as true are considered as part of the active candidate path selection defined in [RFC9256].¶
This document describes using forwarding quality requirements and resource requirements of candidate paths as eligibility criteria for path selection.¶
A headend may be informed about the forwarding quality requirements of a candidate path for an SR Policy <Color, Endpoint> through various means, including configuration, PCEP, or BGP. The extensions of BGP and PCEP are described in [I-D.liu-idr-bgp-sr-policy-cp-threshold] and [I-D.liu-pce-sr-policy-cp-threshold].¶
When a candidate path fails to meet forwarding quality requirements, its Eligibility attribute is set to false, thereby excluding it from active candidate path selection. The rules for setting the Eligibility attribute, including the handling of candidate paths containing multiple segment lists, are specified in Section 4.3.¶
The threshold parameters of candidate paths can include, but are not limited to, the following:¶
Jitter¶
Latency¶
Packet loss¶
When the jitter, delay, or packet loss of a valid segment list does not meet the specified threshold requirements, the segment list will be deemed not valid and will no longer participate in load sharing traffic.¶
Available bandwidth¶
The Available Bandwidth of a Candidate Path refers to the bandwidth allocated to the Candidate Path during SR Policy path computation based on user requirements.¶
CP available bandwidth = CP preset bandwidth * (Sum of weights of Segment Lists in Up state / Sum of all Segment List weights)¶
This formula assumes that the weight of each Segment List is configured proportionally to its forwarding capacity, so that the preset bandwidth of the Candidate Path is shared across the Segment Lists in proportion to their weights. It should be noted that weight is primarily used for the load-balancing ratio and is logically decoupled from the actual capacity of each Segment List. When this proportionality assumption does not hold, the value computed by the formula may not accurately reflect the true available capacity of the Candidate Path. In deployment scenarios where the capacities of Segment Lists are heterogeneous or cannot be inferred from their weights, an explicit per-Segment-List bandwidth attribute may be needed instead, in which case the available bandwidth of the Candidate Path can be derived as the sum of the available bandwidth of the Segment Lists in Up state; see also the definition of actual bandwidth below.¶
Actual bandwidth¶
The actual bandwidth refers to the sum of the actual available remaining bandwidth of each valid segment list in the candidate path.¶
In this document, the remaining bandwidth of a segment list refers to the bandwidth obtained by subtracting the real-time measured traffic on the forwarding interfaces along the path from the physical link capacity of those interfaces, i.e., remaining bandwidth = physical link capacity - measured real-time traffic. When TE is deployed and bandwidth reservation is enforced along the path, the TE reservable bandwidth minus the currently reserved (allocated) bandwidth may be used as the reference instead, according to the deployment.¶
Due to the different congestion conditions of each node on the forwarding path, the actual bandwidth that can forward service packets may differ from the preset bandwidth. By utilizing some measurement mechanisms, the actual minimum available bandwidth and actual minimum remaining bandwidth of all nodes along the path can be obtained. The specific measurement mechanism is not within the scope of this document.¶
Precision Availability Metrics (PAM)¶
Consider a candidate path of SR policy as a Service Level Objective (SLO) [RFC9543], based on the Precision Availability Metrics (PAM) defined in [RFC9544], determine whether the candidate path meets the forwarding requirements.¶
If one or more segment lists in the candidate path fail to meet the thresholds, this indicates that these segment lists cannot provide forwarding capabilities that meet the Service Level Agreement (SLA) requirements. These segment lists will be marked as unavailable and will no longer participate in packet forwarding, and the candidate path is then re-verified to determine whether it still meets the forwarding quality requirements. The processing of a candidate path containing multiple segment lists, including a worked example, is described in Section 4.4.¶
By default, no threshold parameters are specified on a candidate path. In this case, the candidate path remains eligible and the primary candidate path is selected according to the selection method defined in [RFC9256], as described in Section 4.3.¶
This document defines a quality-driven information model for Segment Routing (SR) Policy. Specifically, it introduces threshold-based performance parameters for forwarding quality under each Candidate Path, as described in Section 4.3: when a Candidate Path fails to meet the specified quality thresholds, its Eligibility attribute is set to false, thereby excluding it from being selected as the active path.¶
In summary, the information model enables dynamic and performance-aware SR Policy enforcement, ensuring that only qualified paths are used based on real-time forwarding quality.¶
SR Policy POL1: <Headend = H1, Color = 1, Endpoint = E1>
Candidate Path CP1 <Protocol-Origin, Originator, Discriminator>
Binding SID
Preference
Priority
Threshold parameters of forwarding quality
Jitter 1
Latency 1
Available Bandwidth 1
Actual Bandwidth 1
Segment List 1
Weight W1
Segments <SID11...SID1i>
Segment List 2
Weight W2
Segments <SID21...SID2i>
Candidate Path CP2 <Protocol-Origin, Originator, Discriminator>
Binding SID
Preference
Priority
Threshold parameters of forwarding quality
Jitter 2
Latency 2
Available Bandwidth 2
Actual Bandwidth 2
Segment List 3
Weight W3
Segments <SID31...SID3i>
Segment List 4
Weight W4
Segments <SID41...SID4i>
...
When a candidate path's current forwarding quality meets the specified threshold requirements, its Eligibility attribute MUST be set to true, indicating this path is valid for:¶
Conversely, when a candidate path fails to meet quality requirements, its eligibility attribute MUST be set to false.¶
For candidate paths containing multiple segment lists:¶
For candidate paths without defined threshold parameters:¶
When multiple eligible candidate paths coexist in an SR policy:¶
When one or more segment lists in the candidate path fail to meet the threshold parameters of the candidate path, it indicates that these segment lists cannot provide forwarding capabilities that meet the Service Level Agreement (SLA) requirements. These segment lists will be marked as unavailable and will no longer participate in packet forwarding. After excluding these segment lists, it should be verified whether the candidate path still meets the forwarding quality requirements. If it does, traffic can continue to be forwarded along that candidate path.¶
These actions are performed locally by the head node of the SR Policy: the head node monitors the forwarding quality of each segment list, excludes the segment lists that fail to meet the thresholds, recomputes the available bandwidth of the candidate path, and updates its Eligibility attribute, as part of the selection process described in Section 4.6. A controller may assist by distributing the threshold parameters or by computing and distributing real-time quality data, but the evaluation and the resulting Eligibility update are performed on the head node, consistent with the candidate path selection model defined in [RFC9256].¶
For example, two threshold parameters, delay and available bandwidth, are specified simultaneously for the candidate path with multiple segment lists. When the head node detects that the delay of a segment list exceeds the threshold, it performs the following processing:¶
Check whether the current available bandwidth of the CP still meets the bandwidth threshold requirements.¶
A comprehensive SR Performance Measurement toolset is an essential requirement for measuring network performance to provide Service Level Agreements (SLAs). The following lists several measurement methods for reference; detailed measurement methods are beyond the scope of this document.¶
jitter, delay, or packet loss¶
To measure jitter, delay, or packet loss of an SR policy candidate path, the Simple Two-Way Active Measurement Protocol (STAMP) can be employed. [I-D.ietf-spring-stamp-srpm-mpls] and [I-D.ietf-spring-stamp-srpm-srv6] describe the performance measurement procedures in SR networks using STAMP as defined in [RFC8762], along with its optional extensions from [RFC8972] and [RFC9503]. Notably, [RFC9503] defines an extended TLV capability which can carry SR path information, ensuring that both the forward and return probe packets follow the same SR path for measurement. To guarantee path symmetry, a return-path SID identifying the path segment can be included within Sub-TLVs. The reflector then uses this return-path SID to construct the SID List for the return probe packet. Specifically, [RFC9503] specifies that the Return Path SRv6 Segment List Sub-TLV may include an identifier for the return path Segment List of an SRv6 Path Segment. Other mechanisms, such as In-situ OAM (iOAM) [RFC9378] and TWAMP [RFC5357], can also be used to measure the forwarding quality of candidate paths.¶
Available bandwidth¶
The Available Bandwidth of the Candidate Path is computed using the formula specified in Section 4.1. When the weights of Segment Lists are only used as load-balancing ratios and are decoupled from the per-Segment-List capacity, the per-Segment-List actual bandwidth measurement described below can be used to determine the available capacity of the Candidate Path. If the Available Bandwidth of the currently active Candidate Path cannot meet the service traffic requirements, the SR Policy can switchover to a backup Candidate Path that satisfies the bandwidth requirements.¶
Actual bandwidth¶
By utilizing some measurement mechanisms, the actual minimum available bandwidth and actual minimum remaining bandwidth of all nodes along the SR Policy path can be obtained. One possible implementation for obtaining the actual minimum available and remaining bandwidth along a path (encompassing both the active path and the backup path) is specified in [I-D.liu-ippm-srv6-bandwidth-measurement], and is summarized as follows:¶
The remaining bandwidth measured by this process refers to the physical link capacity of the egress interface at each hop minus the real-time measured traffic on that interface. Where TE bandwidth reservation is enforced, the TE reservable bandwidth minus the currently reserved bandwidth may be used as the reference instead.¶
It is noted that the specific measurement mechanism itself is outside the scope of this document.¶
Operational considerations related to the use of these measurement mechanisms, such as measurement consistency across nodes and mitigation of spurious path switchovers, are described in Section 6.¶
The process of selecting the best candidate path for SR policy through the threshold parameter of the candidate path is as follows.¶
To avoid frequent path switching (flapping), both over-threshold switching and fault recovery should be delayed. The delay interval can be adjusted through configuration.¶
When the quality of service (QoS) of a candidate-path degrades and fails to meet the threshold requirement, the candidate-path will be marked as invalid and will not carry traffic.¶
When the QoS of a candidate-path recovers and meets the threshold requirement, it will wait for the Wait-to-Restore (WTR) period. If the QoS does not degrade during this time, the candidate-path will resume carrying traffic. Otherwise, it will be marked as invalid again.¶
Taking the WTR of 30 seconds as an example, the explanation is as follows:¶
0(x)10(WTR)35(x)40(WTR)70(Recovery) 90(x) 95(WTR) 125(Recovery) | | | | | | | | ------------------------------------------------------------------>¶
At 0 seconds, the candidate-path degraded and was set to invalid.
At 10 seconds, the candidate-path recovered, and the WTR timer was started, waiting for 30 seconds.
At 35 seconds, the candidate-path degraded again, and the waiting timer was canceled.
At 40 seconds, the candidate-path recovered, and the WTR waiting timer was started, waiting for 30 seconds.
At 70 seconds, during the wait-to-restore period, the candidate-path did not degrade; thus, the WTR wait ended and it was restored to valid.
At 90 seconds, the candidate-path degraded again and was set to invalid.
At 95 seconds, the candidate-path recovered, and the WTR waiting timer was started, waiting for 30 seconds.
At 125 seconds, during the wait-to-restore period, the candidate-path did not degrade; thus, the WTR wait ended and it was restored to valid.¶
The example SR policy described in Section 3 is used in the sections that follow to illustrate how the flexible candidate path selection method switches between 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 quality requirement for the services carried on the SR policy is that the transmission delay must be less than 200ms. The bandwidth of the actual traffic forwarded by the SR policy is between 100Mbps and 150Mbps.¶
When the delay of Segment List 1 does not meet the requirements, the head node continues to check the available bandwidth of CP1. Due to segment list 2 only having 100Mbps bandwidth, it cannot meet the actual traffic forwarding requirements. CP1's Eligibility attribute is set to false, triggering the selection of CP2 as POL1's new active candidate path. The traffic forwarded by POL1 is switched to the path of CP2 for forwarding.¶
SR Policy POL1
Candidate Path CP1
Preference 200
Delay threshold 200ms //Delay<=200ms
Segment List 1 <SID11...SID1i>, Weight 1 //100M, Delay>1s
Segment List 2 <SID21...SID2i>, Weight 1 //100M, Delay<100ms
Candidate Path CP2
Preference 100
Delay threshold 200ms //Delay<=200ms
Segment List 3 <SID31...SID3i>, Weight 1 //100M, Delay<100ms
Segment List 4 <SID41...SID4i>, Weight 1 //100M, Delay<100ms
¶
The preset bandwidth for both CP1 and CP2 is 300Mbps. Each segment list can carry a maximum of 100Mbps traffic. The quality requirement for service traffic is that the available bandwidth of the forwarding path must not be less than 150Mbps.¶
SR Policy POL1
Candidate Path CP1
Preference 200
Preset bandwidth 300Mbps
Available bandwidth threshold 150Mbps
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
Preset bandwidth 300Mbps
Available bandwidth threshold 150Mbps
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 available bandwidth is 150Mbps. When the available bandwidth of the candidate path is less than 150Mbps, perform path switching.¶
Normally, the three segment lists of CP1 and CP2 are valid. The available bandwidth of CP1 is 300Mbps, and the available bandwidth can meet the threshold requirements. CP1's Eligibility attribute is set to true, CP1 is selected as the active candidate path according to the Preference.¶
If the paths indicated by Segment List 1 and 2 fail, Segment List 1 and 2 become not valid, and the available bandwidth of CP1 becomes 100Mbps. Because the available bandwidth of CP1 is lower than the specified threshold, CP1 has failed to meet the forwarding quality requirements. CP1's Eligibility attribute is set to false. There is a 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's Eligibility attribute is set to true. CP2 is selected as the new active candidate path of POL1. The traffic forwarded by POL1 will be switched to the path of CP2 for forwarding.¶
In scenarios involving the actual available bandwidth measurement method for SRv6, the quality requirement for the services carried on the SR policy mandates that the actual available bandwidth of the forwarding path must exceed 80 Mbps. If traffic congestion occurs on a node in Segment List 1, resulting in a maximum forwarding capacity of only 50 Mbps for service traffic, and if Segment List 2 is either in a down state or has exceeded the delay threshold, Segment List 2 will not participate in load sharing traffic.¶
When the aggregate available bandwidth of CP1 falls below 80 Mbps:¶
SR Policy POL1
Candidate Path CP1
Preference 200
Preset bandwidth 200Mbps
Actual available bandwidth threshold 80Mbps
Segment List 1 <SID11...SID1i>, Weight 1
(Actual available bandwidth is only 50Mbps.)
Segment List 2 <SID21...SID2j>, Weight 1
(In Down state, or the delay has exceeded the
threshold.)
Candidate Path CP2
Preference 100
Preset bandwidth 300Mbps
Actual available bandwidth threshold 80Mbps
Segment List 3 <SID41...SID4i>, Weight 1 (100Mbps)
Segment List 4 <SID51...SID5j>, Weight 1 (100Mbps)
Segment List 5 <SID61...SID6k>, Weight 1 (100Mbps)
¶
The traffic forwarded by POL1 will switch to the path of CP2 for forwarding.¶
This section describes operational aspects of deploying the flexible candidate path selection mechanism defined in this document.¶
In operational deployments, it is important that the measurement mechanism used to assess forwarding quality be consistent across all nodes participating in the same SR Policy. For example, if STAMP-based delay measurement is used to evaluate candidate paths, the same measurement method and threshold interpretation should be applied consistently by the head node for all candidate paths within that SR Policy. This ensures that the Eligibility attribute reflects comparable quality assessments and that path selection decisions are stable and predictable. When a controller distributes threshold parameters to multiple head nodes for the same SR Policy (e.g., in redundant head node scenarios), the controller should also ensure that the underlying measurement mechanisms and sampling intervals are aligned across those nodes to avoid inconsistent path selection outcomes.¶
In operational deployments, real-time bandwidth may exhibit continuous fluctuations. To mitigate CP switchovers resulting from such variability, it is advisable to define a measurement interval for bandwidth monitoring. During this interval, multiple samples can be collected and averaged to smooth transient anomalies and prevent spurious CP transitions.¶
To avoid frequent path switching (flapping), both over-threshold switching and fault recovery are delayed, as described in Section 4.7.¶
This document has no IANA actions.¶
[RFC8754] defines the notion of an SR domain and use of SRH within the SR domain. Procedures for securing an SR domain are defined in Section 5.1 and Section 7 of [RFC8754]. This document does not impose any additional security challenges to be considered beyond security threats described in [RFC8754], [RFC8679] and [RFC8986].¶
The traffic switchover mechanism defined in this document, such as the ability to forcibly switch traffic from one control plane to another, may redirect traffic to an attacker's preset path. Additionally, switching traffic to another CP could overload network resources, leading to service unavailability or operational failures. Similarly, frequent flapping during switchovers may compromise network stability. Therefore, it is essential to ensure that this SR network operates within a trusted security domain while implementing safeguards like proper configuration and delayed switchback mechanisms to maintain secure SR Policy operation.¶
The authors would like to thank Alvaro Retana, Joel Halpern, Jie Dong, Zhenqiang Li, and Guanming Zeng for their valuable contributions of this document.¶