



Network Working Group                                              Z. Li
Internet-Draft                                              China Mobile
Intended status: Standards Track                                K. Zhang
Expires: 4 December 2026                                         J. Dong
                                                                  Huawei
                                                           K. Talaulikar
                                                           Cisco Systems
                                                                   R. Gu
                                                                  Huawei
                                                             2 June 2026


                  BGP SR Policy Extensions for Metric
                   draft-ietf-idr-sr-policy-metric-05

Abstract

   An SR Policy consists of one or more Candidate Paths (CPs), each
   comprising one or more segment lists.  BGP can be used to propogate
   SR Policy CPs to the SR Policy headend nodes in the network.  After
   an SR Policy CP is installed on the headend node, packets can be
   steered into the SR Policy.

   For a particular BGP destination, if there are multiple BGP routes
   with different next-hops, BGP best path selection is performed and
   the IGP metric to the next-hop node may be used for tie-breaking to
   select the best path.  When the path to the next-hop is resolved over
   an SR Policy, the IGP metric of the SR policy is needed for BGP path
   selection.

   This document defines the BGP extensions to carry the IGP metric of
   segment lists when BGP is used to propagate SR Policy CPs.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD 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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.






Li, et al.               Expires 4 December 2026                [Page 1]

Internet-Draft     BGP SR Policy Extensions for Metric         June 2026


   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 4 December 2026.

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

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  A Typical Scenario  . . . . . . . . . . . . . . . . . . . . .   3
   3.  SR Policy and Tunnel Encapsulation Attribute Update . . . . .   4
     3.1.  Metric sub-TLV  . . . . . . . . . . . . . . . . . . . . .   5
   4.  Metric Process of SR Policy Segment List  . . . . . . . . . .   5
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  New sub-TLV Registration: Metric Sub-TLV  . . . . . . . .   6
     6.2.  Registry of BGP SR Poicy Metric Type  . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8









Li, et al.               Expires 4 December 2026                [Page 2]

Internet-Draft     BGP SR Policy Extensions for Metric         June 2026


1.  Introduction

   An SR Policy [RFC9256] is associated with one or more Candidate Paths
   (CPs), each of which is expressed as a segment list or a set of
   segment lists.. BGP SR Policy [RFC9830] can be used to propogate SR
   Policy CPs to the SR Policy headend nodes in the network.  After an
   SR Policy CP is installed on the headend node, packets can be steered
   into the SR Policy.

   For a particular BGP destination, if there are multiple BGP routes
   with different next-hops, BGP best path selection [RFC4271] is
   performed and the IGP metric to the next-hop node may be used for
   tie-breaking to select the best path.  When the path to the next-hop
   is resolved over an SR Policy, the IGP metric of the SR policy is
   needed for BGP path selection.

   This document defines the BGP extensions to carry the IGP metric of
   segment lists when BGP is used to propagate SR Policy CPs.

2.  A Typical Scenario

   In network scenarios where there are multiple BGP routes to a
   particular destination prefix with different next-hops, and some of
   which are resolved via SR Policy, the metric of the SR Policy may be
   needed for BGP best path selection.

   The specific scenarios are as follows:



                            +--+         +--+         +---+
                   _ _ _ _ _|P1|_ _ _ _ _|P2|_ _ _ _ _|PE2|_ _ _ _
                  |         +--+         +--+         +---+       |
                  |                                               |
    +---+        +---+                                           +---+
    |CE1|_ _ _ _ |PE1|                                           |CE2|
    +---+        +---+                                           +---+
                  |         +--+         +--+         +---+       |
                  |_ _ _ _ _|P3|_ _ _ _ _|P4|_ _ _ _ _|PE3|_ _ _ _|
                            +--+         +--+         +---+


   On PE1, the BGP route to the prefix advertised by CE1 has two
   candidate next-hops: PE2 and PE3.  The BGP best path selection to the
   prefix of CE1 may be based on the IGP metric of the paths from PE1 to
   PE2 and from PE1 to PE3 respectively.  The path toward PE2 is
   resolved via SR Policy-1, whose endpoint is PE2; similarly, the path
   toward PE3 is resolved via SR Policy-2.  PE1 needs to know the the



Li, et al.               Expires 4 December 2026                [Page 3]

Internet-Draft     BGP SR Policy Extensions for Metric         June 2026


   IGP metrics of the SR Policies to select the SR Policy which best
   meet the requirement.  Thus the IGP metric of the Segment Lists which
   constitute the SR Policy CP needs to be conveyed to the headend node
   of SR Policy.

3.  SR Policy and Tunnel Encapsulation Attribute Update

   In order to carry the metric of an SR Policy CP, the tunnel
   encapsulation attribute of the BGP SR Policy is extended.

   The BGP SR Policy Encoding structure is as follows:

   SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>


         Attributes:

         Tunnel Encaps Attribute (23)

                 Tunnel Type: SR Policy

                    Binding SID

                    Preference

                    Priority

                    Policy Name

                    Policy Candidate Path Name

                    Explicit NULL Label Policy (ENLP)

                    Segment List

                        Weight

                        Metric

                        Segment

                        Segment

                        ....

                        ....

   Where the metric indicates the metric for the segment list.



Li, et al.               Expires 4 December 2026                [Page 4]

Internet-Draft     BGP SR Policy Extensions for Metric         June 2026


3.1.  Metric sub-TLV

   A new sub-TLV called Metric Sub-TLV is defined.  Metric sub-TLV
   specifies the metric of an SR policy Segment List.  Each sub-TLV is
   encoded as shown in Figure 1.  More than one metric Sub-TLVs may be
   present in one Segment List to refer to the metric values of
   different metric types.


     0               1               2               3
     0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Type     |    Length     |   Metric Type    |   Flags   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Metric Value                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 1: Metric Sub-TLV

   * Type: Metric, 1 octet, TBD.

   * Length: 6 octets.

   * Metric Type: 1-octet field which identifies the type of the metric
   being used.  The metric-type code points are listed in Section 7.2.

   * Flags: None are defined at this stage.  Flags MUST be set to zero
   on transmission and MUST be ignored on receipt.

   * Metric Value: 4-octet value which indicates the metric of the
   computed path.

4.  Metric Process of SR Policy Segment List

   When an SR Policy headend node receives the SR Policy segment list
   with the metric field, the metric may be of any of the defined types:
   (IGP metric, Min Unidirection Link delay, TE metric, Hop Count, or
   SID List length).

   The rules for processing SR Policy metrics are as follows:
   1. The type of metric to use is determined by the local policy,
   which can be user-configured. For example, the user specifies
   the IGP metric as local policy.
   2. The metric of the Active Candidate Path is used as the metric
   of the SR Policy.
   3. The metric of the Active Candidate Path uses the maximum
   metric value of the specified metric type in all segment lists.




Li, et al.               Expires 4 December 2026                [Page 5]

Internet-Draft     BGP SR Policy Extensions for Metric         June 2026


   Example:
   SR Policy: (Headend:1::1, Color: 2, EndPoint: 2::2)
   Candidate path preference: 200
   Segment list 1: (IGP metric: 20)
   Segment list 2: (IGP metric: 30)
   Candidate Path preference: 100
   Segment list 1: (IGP metric: 40)
   Segment list 2: (IGP metric: 30)
   Local policy: IGP metric
   Active candidate path: preference 200
   Active candidate path metric: 30, which is the maximum IGP metric
   of all segment lists in the candidate path.


   Taking the scenario in Figure 1 as an example, according to the rules
   above, the metric of SR Policy 1 is 30, and the metric of SR Policy 2
   is 40, then according to the BGP path selection tie-breaking rule,
   the BGP route with next-hop PE2 is selected as the metric of SR
   Policy 1 is smaller than that of SR Policy 2.

5.  Acknowledgements

   The authors would like to thank Liyan Song for the review and
   discussion.

6.  IANA Considerations

6.1.  New sub-TLV Registration: Metric Sub-TLV

   IANA is requested to assign a new code point for Metric Sub-TLV in
   the "SR Policy Segment List Sub-TLVs" registry of the "BGP Tunnel
   Encapsulation" registry group.

    Value                  Description                  Reference
    ---------------------- ---------------------------- --------------
    TBD                    Metric                       This document

                          Figure 2: Metric sub-TLV

6.2.  Registry of BGP SR Poicy Metric Type

   The semantics of the Metric Type field in the Metric sub-TLV defined
   in this document is identifical to the metric types in the "BGP-LS SR
   Policy Metric Types" registry in the "BGP-LS Parameters" registry
   group.  IANA is requested to rename the existing registry to "BGP/
   BGP-LS SR Policy Metric Types" registry.  This is to allow the
   sharing of this registry for metric types in both BGP SR Policy and
   BGP-LS SR Policy.  There is no change to the code points in this



Li, et al.               Expires 4 December 2026                [Page 6]

Internet-Draft     BGP SR Policy Extensions for Metric         June 2026


   registry.

7.  Security Considerations

   The BGP extensions defined in this document do not affect the base
   BGP security model.  The BGP SR policy extension specified in this
   document is based on [RFC9830].  The security requirements and
   mechanisms described in [RFC9830] also apply to this document.  SR
   operates within a trusted SR domain [RFC8402] and its security
   considerations also apply to BGP sessions which are used for
   distributing SR Policy information.

   The distribution of SR Policy with metric information may pose
   additional mission-critical or commercially sensitive information
   about the network.  The BGP sessions used for SR Policy distribution
   not automatic established and require configuration, network operator
   needs to ensure that only trusted nodes (that include both routers
   and controller applications) within the SR domain are configured to
   receive such information.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <https://www.rfc-editor.org/info/rfc4271>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC9256]  Filsfils, C., Talaulikar, K., Ed., 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>.

   [RFC9830]  Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes,
              P., and D. Jain, "Advertising Segment Routing Policies in
              BGP", RFC 9830, DOI 10.17487/RFC9830, September 2025,
              <https://www.rfc-editor.org/info/rfc9830>.




Li, et al.               Expires 4 December 2026                [Page 7]

Internet-Draft     BGP SR Policy Extensions for Metric         June 2026


8.2.  Informative References

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [RFC9857]  Previdi, S., Talaulikar, K., Ed., Dong, J., Gredler, H.,
              and J. Tantsura, "Advertisement of Segment Routing
              Policies Using BGP - Link State", RFC 9857,
              DOI 10.17487/RFC9857, October 2025,
              <https://www.rfc-editor.org/info/rfc9857>.

Authors' Addresses

   Zhenqiang Li
   China Mobile
   China
   Email: lizhenqiang@chinamobile.com


   Ka Zhang
   Huawei
   Huawei Bld., No.156 Beiqing Rd.
   Beijing
   100095
   China
   Email: zhangka@huawei.com


   Jie Dong
   Huawei
   Huawei Bld., No.156 Beiqing Rd.
   Beijing
   100095
   China
   Email: jie.dong@huawei.com


   Ketan Talaulikar
   Cisco Systems
   India
   Email: ketant.ietf@gmail.com


   Rui Gu
   Huawei
   Huawei Bld., No.156 Beiqing Rd.



Li, et al.               Expires 4 December 2026                [Page 8]

Internet-Draft     BGP SR Policy Extensions for Metric         June 2026


   Beijing
   100095
   China
   Email: gurui12@huawei.com















































Li, et al.               Expires 4 December 2026                [Page 9]
