<?xml version="1.0" encoding="utf-8"?>
<rfc
  xmlns:xi="http://www.w3.org/2001/XInclude"
  category="std"
  docName="draft-li-idr-sr-policy-metric-01"
  ipr="trust200902"
  obsoletes=""
  updates="4271"
  sortRefs="true"
  consensus="true"
  submissionType="IETF"
  xml:lang="en"
  version="3">
  <front>
    <title abbrev="SR Policy Extensions for Path Selection">BGP SR Policy
      Extensions for Performance-Aware Path Selection</title>
    <seriesInfo name="Internet-Draft" value="draft-li-idr-sr-policy-metric-01" />
    <author fullname="Zhenqiang Li" initials="Z" role="editor" surname="Li">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <country>CN</country>
        </postal>
        <email>lizhenqiang@chinamobile.com</email>
      </address>
    </author>
    <author fullname="Liyan Song" initials="L" role="editor" surname="Song">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <country>CN</country>
        </postal>
        <email>songliyan@chinamobile.com</email>
      </address>
    </author>
    <date year="2025" />
    <area>Routing</area>
    <workgroup>Inter-Domain Routing</workgroup>
    <keyword>SR Policy</keyword>
    <keyword>Metric Sub-TLV</keyword>
    <abstract>
      <t>To enable the headend node to do performance-aware path selection, 
	    this document proposes an extension to the BGP SR Policy protocol by
        defining a new optional Metric Sub-TLV within the BGP Tunnel
        Encapsulation Attribute <xref target="RFC9012" />. The introduced Metric Sub-TLV encodes performance
        parameters (such as latency, bandwidth, reliability, etc.) for SR Policy paths.</t> 
	  <t>This specification also updates the BGP route selection procedures in <xref target="RFC4271" />, modifying the
        Breaking Ties (Phase 2) logic to prioritize the metrics for SR Policy paths.</t>
	  
      <t>Key contributions include:</t>
	  <ul>
        <li>Introduce Metric Sub-TLV in BGP SR Policy</li>
		<li>Update the tie-breaking procedure for BGP route selection</li>
      </ul>
      
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>Segment Routing (SR) <xref target="RFC8402" /> allows a headend node to steer a
		packet flow along a specific path. <xref target="RFC9256" /> further details the concepts of SR Policy and steering into
		an SR Policy. <xref target="I-D.ietf-idr-sr-policy-safi" /> specifies the use of BGP to distribute one or more of
		the candidate paths of an SR Policy to the headend of that policy.Currently <xref target="I-D.ietf-idr-sr-policy-safi" /> 
		lacks the capability to propagate performance metrics such as path latency,
        bandwidth, or reliability. This limitation prevents headends from implementing
        policy selection based on path metrics when there are multiple paths reaching the same destination.
		Consequently, the headends cannot dynamically elect performance-optimal path among multiple
        SR Policies. To address this limitation, this document extends the BGP SR Policy protocol to
        carry performance metrics in SR Policy advertisements.</t>
      
	  <section numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>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 <xref target="RFC2119" /> <xref target="RFC8174" />
          when, and only when, they appear in all capitals, as shown here.</t>
      </section>
	  
    </section>
    <section numbered="true" toc="default">
      <name>Use Case</name>
      <t>As shown in Figure 1,the SR Policy Computation and Provisioning System, such as a SDN controller, collects real-time
        network state information (e.g., topology, link utilization) and performance metrics (e.g.,
        link latency, jitter, packet loss rate). Based on service or customer requirements (e.g.,
        minimum latency), it computes SR Policy paths between designated endpoints and distributes
        them to headend nodes via the BGP SR Policy protocol <xref target="I-D.ietf-idr-sr-policy-safi" />. </t>
      
	  <t>For example:</t>
      <t>The system provisions two low-latency policies to headend node PE3:</t>

      <t>Policy1: Path via P1-->PE1, with a measured latency of 20 ms.</t>
      <t>Policy2: Path via P2-->PE2, with a measured latency of 12 ms.</t>

      <t>However, the current BGP SR Policy protocol <xref target="I-D.ietf-idr-sr-policy-safi" /> only propagates path
        definitions (e.g., segment lists) without embedding performance metrics. This forces headend
        nodes to select paths based solely on static criteria (e.g., administrative preferences),
        potentially leading to suboptimal traffic engineering decisions. </t>
      
	  <t>To address this limitation, this proposal extends the BGP SR Policy protocol by introducing
        a new Performance Metrics Sub-TLV within the BGP Tunnel Encapsulation Attribute <xref
          target="RFC9012" />. This Sub-TLV encodes key performance indicators (KPIs) such as
        latency, bandwidth, and reliability (see Section 3 for details). With this extension: The SR
        Policy Computation and Provisioning System can advertise SR Policies alongside their
        associated KPIs. Headend nodes leverage the enhanced BGP route selection logic (Section 6)
        to prioritize paths that meet dynamic performance requirements.</t>
		
      <figure>
        <name>Use Case for Performance-Aware SR Policy Selection</name>
        <artwork align="center"><![CDATA[
       +---------------------------------------------+                
       |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         +---+                                            
        ]]></artwork>
      </figure>
    </section>
	
    <section numbered="true" toc="default">
      <name>Metric Sub-TLV</name>
      <t>This document extends the BGP SR Policy protocol by introducing a new sub-TLV, Metric Sub-TLV,
        within the BGP Tunnel Encapsulation Attribute. The Extended BGP SR Policy Encoding structure is as follows:</t>

      <figure>
        <name>Extended BGP SR Policy Encoding</name>
        <artwork align="center"><![CDATA[       
      	SR Policy SAFI NLRl: <Distinguisher, Policy-Color, Endpoint>
      	Attributes:
      	  Tunnel Encapsulation Attribute(23)
            Tunnel Type: SR Policy(15)              
              Binding SID
              SRv6 Binding SID
              Preference
              Priority
              Metric
              Policy Name
              Policy Candidate Path Name
              Explicit NULL Label Policy (ENLP)
              Segment List
                Weight
                Segment
                Segment
                ...                   
              ...
           ]]></artwork>
      </figure>

      <t>Metric Sub-TLV is used to carry performance metrics such as latency, bandwidth, and
        reliability. The format of Metric Sub-TLV is as follows: </t>

      <figure>
        <name>Metric Sub-TLV</name>
        <artwork align="center"><![CDATA[                                                                         
 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     |     Flags     |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Delay(8 octets,optinal)                       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Bandwidth(4 octets,optional)                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Reliability(4 octets,optional)                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ]]></artwork>
      </figure>
	  
	  <t>Where:</t>
      <t>Type (1 octet): Indicates this sub-TLV is Metric, Specific values need to be assigned by IANA.</t>
      <t>Length (1 octet): Indicates the length of the Metric sub-TLV in bytes.</t>
      <t>Flags (1 octet): Indicates the presence of specific performance metrics. Its definition is shown in Figure 4.</t>
      <t>Reserved (1 octet): Reserved for future use. This field MUST be set to 0 when sending and ignored when receiving.</t>
      
	  <t>Delay(8 octets): Carries delay information. Its format depends on the D flag in Flags Field:</t>
		<ul>
          <li>If D = 01: NTPv4 format delay</li>
		  <li>If D = 10: IEEE 1588v2 PTP format delay</li>
        </ul>

      <t>Bandwidth (4 octets): Carries bandwidth information in Mbps.</t>
      
	  <t>Reliability (4 octets): Carries reliability information, such as the maximum number of
        failures that have occurred on all links in the SR policy path within the past month.</t>
      
	  <figure>
        <name>Flag Field for Metric Sub-TLV</name>
        <artwork align="center"><![CDATA[
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| D |B|R|Reserved|
+-+-+-+-+-+-+-+-+
           ]]></artwork>
      </figure>
	  
      <t>Where, D Flag is for delay, B Flag is for Bandwidth and R Flag is for reliability, all the other bits are reserved.
		The detailed encodings of the three flags defined in this document are as follows: ‌</t>
		
	  <figure>
        <name>Flags for Metric Sub-TLV</name>
        <artwork align="center"><![CDATA[          
+------+-------+-------------------------------+
| Flag | Bits  | Description                   |
+------+-------+-------------------------------+
| D    | 0-1   | 00: No delay                  |
|      |       | 01: NTPv4 delay               |
|      |       | 10: PTP delay                 |
|      |       | 11: Reserved                  |
+------+-------+-------------------------------+
| B    | 2     | 0: No bandwidth               |
|      |       | 1: Bandwidth                  |
+------+-------+-------------------------------+
| R    | 3     | 0: No reliability             |
|      |       | 1: Reliability                |
+------+-------+-------------------------------+
            ]]></artwork>
      </figure>

	  <t>Implementations SHOULD set only one flag (D, B, or R) at a time, as these metrics are typically not directly comparable. 
      	Network operators MAY configure which metric to prioritize based on service requirements.</t>
    </section>
	
    <section numbered="true" toc="default">
      <name>Policy Computation and Provisioning System Behavior</name>
      <t>The Policy Computation and Provisioning System is responsible for calculating Segment
        Routing (SR) policies based on network state and business requirements, and provisioning
        them to headend nodes. When provisioning SR policies that include performance metrics, the
        system should follow these steps:</t>
      <t>Collect Network State Information: Gather real-time network topology, link utilization,
        and other relevant data.</t>
      <t>Compute SR Policies: Calculate SR policy paths that meet performance requirements based
        on service needs and network state.</t>
      <t>Encapsulate Performance Metrics: Embed performance metrics such as latency, bandwidth,
        and reliability within the Metric Sub-TLV of the BGP Tunnel Encapsulation Attribute.</t>
      <t>Provision BGP Update Messages: Include the SR policies with performance metrics in BGP
        update messages and send them to the appropriate headend nodes.</t>
    </section>
	
    <section numbered="true" toc="default">
      <name>Headend Behavior</name>
      <t>Upon receiving SR policies with performance metrics, headend nodes should process them as
        follows:</t>
      <t>Parse BGP Update Messages: Extract SR policies and their associated performance metrics
        from the received BGP update messages.</t>
      <t>Store Performance Metrics: Save the performance metrics in a local database for
        subsequent path selection.</t>
      <t>Path Selection: Prioritize paths that meet dynamic performance requirements when
        multiple paths are available.</t>
      <t>Update Routing Tables: Modify routing tables based on the selected paths to ensure
        traffic is forwarded along optimized routes.</t>
    </section>
	
    <section numbered="true" toc="default">
      <name>Updated Tie-Breaking Procedure for BGP</name>
      <t>Support for SR policy metric introduced in this document involves several modifications to the tie-breaking procedures of the BGP "phase 2" decision described in <xref target="RFC4271"/>, Section 9.1.2.2.</t>	  
	  <t>A new step, step e0, is inserted before step e of the tie-breaking (Phase 2) logic in <xref target="RFC4271"/>.</t>
	  <t>e0) If any routes have the Color extended community attribute with an identical value, remove from consideration all routes lacking the Color extended community attribute.</t>
	  <t>Compare the SR policies corresponding to the remaining routes. If any SR policies have the metric sub-TLV, remove from consideration all routes whose corresponding SR policies do not have the metric sub-TLV.</t>
	  <t>Remove from consideration all routes whose metric sub-TLV are not the best. For the latency metric, the smallest value is considered the best; for the bandwidth metric, the largest value is the best; and for reliability, the smallest value is the best.</t>
    </section>
	
    <section anchor="IANA">
      <!-- All drafts are required to have an IANA considerations section. See RFC 8126 for a
      guide.-->
      <name>IANA Considerations</name>
      <t>IANA is requested to assign the following code point from the "BGP Tunnel Encapsulation Attribute Sub-TLVs" Registry:</t>
	  <table align="center">
		<name>Code Point for Metric Sub-TLV</name>
        <thead>
        <!-- [REPLACE/DELETE] a table header is optional -->
          <tr>
			<th align="left" colspan="1" rowspan="1">Code Point</th>
            <th align="left" colspan="1" rowspan="1">Description</th>
            <th align="left" colspan="1" rowspan="1">Reference</th>
		  </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">TBD</td>
            <td align="left" colspan="1" rowspan="1">Metric Sub-TLV</td>
            <td align="left" colspan="1" rowspan="1">This document</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="Security">
      <!-- All drafts are required to have a security considerations section. See RFC 3552 for a
      guide. -->
      <name>Security Considerations</name>
      <t>TBD</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml" />
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml" />
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml" />
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9012.xml" />
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-sr-policy-safi.xml" />
        <!--?rfc include='reference.I-D.ietf-idr-flowspec-redirect-ip'?-->
		<!-- The recommended and simplest way to include a well known reference -->
      </references>
	  <references>
        <name>Informative References</name>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml" />
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml" />
        <!-- The recommended and simplest way to include a well known reference -->
      </references>
    </references>
	
    <section anchor="Acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>The authors would like to acknowledge the supports from Cheng Chang and Bo Liu.</t>
	  <t>Yao Liu and Changwang Lin review this document and provide valuable comments.</t>
    </section>
  </back>
</rfc>