SR Policy Metric-Aware BGP Best Path Selection

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 6 May 2027.¶

Copyright Notice

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.¶

Table of Contents

2. 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 [RFC7752], TWAMP [RFC5357]/Micro TWAMP [RFC9533], and Telemetry [RFC9232]. 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 [RFC9830]. The metric information used in this example is the Min Unidirectional Link Delay Metric Type specified in [I-D.ietf-idr-sr-policy-metric].¶

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.¶

       +---------------------------------------------+
       |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).¶

3. Updated Tie-Breaking Procedure for BGP

This document supplements and optimizes the BGP route tie-breaking procedure defined in [RFC4271] 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.¶

4. IANA Considerations

This document requires no IANA actions.¶

5. Security Considerations

The security considerations of [RFC4271], [RFC9256], and [RFC9830] 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.¶

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.¶

Authors' Addresses