China Mobile

CN lizhenqiang@chinamobile.com

China Mobile

CN songliyan@chinamobile.com

Routing Inter-Domain Routing SR Policy Metric BGP Best Path When multiple BGP routes are available for a destination, the interior cost used by the BGP best-path selection procedure may not reflect the metric of the SR Policy associated with the actual forwarding path. This can result in the selection of a BGP route that does not match the intended transport performance. This document updates the BGP Phase 2 tie-breaking procedure to enable locally configured SR Policy metric-aware best-path selection using metrics specified in the BGP SR Policy metric extensions.This document replaces , retaining and refining its use case and BGP best-path selection enhancements. The BGP SR Policy extensions for carrying SR Policy metrics are merged in .

Introduction Segment Routing (SR) allows a headend node to steer a packet flow along a specific path. further details the concepts of SR Policy and steering into an SR Policy. specifies the use of BGP to distribute one or more Candidate Paths of an SR Policy to its headend node. In networks using SR Policies, based on the BGP tie-breaking procedures defined in , the BGP route selected for a destination may not be associated with the SR Policy that best meets the intended performance requirements. Consequently, traffic may not be steered along the more suitable transport path. One use case is illustrated in . The BGP SR Policy metric extensions specified in provide metric information for SR Policy Segment Lists and specify how the metric of an SR Policy is determined from its Active Candidate Path. However, merely making SR Policy metrics available cannot resolve the BGP best-path selection issue. For a destination with multiple BGP routes, the tie-breaking procedure defined in may use the interior cost to the BGP NEXT_HOP when selecting the best route. This cost does not necessarily reflect the metric of the SR Policy associated with the forwarding path. Once a BGP route is selected, traffic may be steered into the SR Policy associated with that route, while a more suitable SR Policy associated with another BGP route remains unused. To address this limitation, this document updates the BGP route tie-breaking procedure specified in by introducing a locally enabled step that considers the validity and metrics of SR Policies associated with the remaining BGP routes. The SR Policy metrics are obtained according to . The existing SR Policy Candidate Path selection and steering and fallback procedures specified in are unchanged.

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 when, and only when, they appear in all capitals, as shown here.

Use Case As illustrated in Figure 1, the SR Policy Computation and Provisioning System, such as an SDN controller, collects network state information (e.g., topology and link bandwidth) and performance measurements (e.g., link delay, jitter, and packet loss rate) using mechanisms such as BGP-LS , TWAMP /Micro TWAMP , and Telemetry . Based on service or customer requirements (e.g., minimum delay), the system computes SR Policy paths between designated endpoints and distributes the Candidate Paths to headend nodes via BGP SR Policy as specified in . The metric information used in this example is the Min Unidirectional Link Delay Metric Type specified in . In this example, traffic between CE2 and CE1 may be carried through PE3 or PE4 toward PE1 or PE2. PE3 is an SR Policy headend, while PE1 and PE2 are the endpoints of the two SR Policies used for the illustrated BGP route selection. The service traffic originates from or is destined for a CE; the SR Policies provide transport between PE nodes. The system provisions two low-latency policies to headend node PE3: Policy1: Path via P1-->PE1, with a measured latency of 20 ms. Policy2: Path via P2-->PE2, with a measured latency of 12 ms.

Use Case for SR Policy Metric-Aware BGP Best-Path Selection +---------------------------------------------+ |SR Policy Computation and Provisioning System| +---------------------------------------------+ * * * * * * * *Extended BGP * * * *SR Policy * * * * +---+ 15ms* +---+ 5ms * +---+ /|PE1| ----*----| P1|-------------*-----|PE3|\ / +---+ * +---+----\ /--*----+---+ \ / | * | \ / * | \ +---+/ | * | ----\ * | \+---+ |CE1|0.5ms| * |0.5ms / \ * |0.5ms |CE2| +---+\ | * | ---- ---\ * | /+---+ \ | * | /1ms 5ms\ * | / \ +---+ +---+ --+---+ / \|PE2|----------|P2 |-------------------|PE4|/ +---+ 11ms +---+ 1ms +---+

For the BGP route selection example, PE3 receives two BGP routes to a destination reachable through CE1, with NEXT_HOP PE1 and PE2, respectively. Policy1 and Policy2 provide available metrics of the same locally configured delay Metric Type. The stated 20 ms and 12 ms values are SR Policy metrics, not the BGP NEXT_HOP interior costs. When the enhanced selection procedure in Section 3 is enabled, PE3 selects the BGP route via PE2 because Policy2 has the lower Metric Value of the selected Metric Type (12 ms rather than 20 ms).

Updated Tie-Breaking Procedure for BGP This document supplements and optimizes the BGP route tie-breaking procedure defined in Phase 2 to support performance-aware path selection for SR Policy. A new tie-breaking sub-step (e0) is inserted before the original step e of the Phase 2 decision process, forming a complete and ordered path selection logic that takes SR Policy performance metrics as a core preferential condition. The optimized procedure ensures that performance-optimal SR Policy paths can be prioritized in BGP route selection, rather than being limited by traditional tie-breaking rules and fixed next-hop preferences. The updated BGP route tie-breaking procedures are as follows. d) If at least one of the candidate routes was received via EBGP, remove from consideration all routes that were received via IBGP. e0) If any routes have a Color Extended Community associated with a valid SR Policy, remove from consideration all routes that are not associated with valid SR Policies. Compare the SR Policies corresponding to the remaining routes. According to locally configured Metric Type Preferences, select the highest-preference available Metric Type and remove from consideration all routes whose corresponding SR Policies do not have an available metric of the selected Metric Type. If no metric of any locally configured Metric Type is available, continue with step e. Different Metric Types participating in the comparison MUST have distinct locally configured preference values. Remove from consideration all routes whose corresponding SR Policies do not have the most preferred Metric Value of the selected Metric Type. e) Remove from consideration any routes with less-preferred interior cost. When a change in the validity or metric of an SR Policy affects the selection criteria defined in step e0, the BGP speaker SHOULD re-evaluate the best-path selection for the affected BGP routes.

IANA Considerations This document requires no IANA actions.

Security Considerations The security considerations of , , and apply. This document does not define new BGP attributes or metric signaling. It changes local BGP route selection when the mechanism is enabled. Incorrect or misleading SR Policy metric information, or inappropriate local Metric Type Preferences, can influence which BGP route is selected. Changes in SR Policy validity or metrics can cause repeated best-path evaluation and potentially increase route-selection churn. Operators should take account of the trustworthiness and stability of the metric information and the effects of the local configuration.

References Normative References Informative References

Acknowledgements The authors would like to acknowledge the support from Cheng Chang and Bo Liu. Yao Liu from ZTE, Changwang Lin from H3C, Jie Dong from Huawei reviewed this document and provided valuable comments.