Skip to main content

BGP Request for Candidate Paths of SR TE Policies
draft-li-ldr-bgp-request-cp-sr-te-policy-06

Document Type Active Internet-Draft (individual)
Authors Zhenbin Li , Qiangzhou Gao , Huaimo Chen , Yanhe Fan , Xufeng Liu , Lei Liu
Last updated 2023-10-22
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-li-ldr-bgp-request-cp-sr-te-policy-06
Network Working Group                                              Z. Li
Internet-Draft                                                    Q. Gao
Intended status: Standards Track                                  Huawei
Expires: 24 April 2024                                           H. Chen
                                                               Futurewei
                                                                  Y. Fan
                                                            Casa Systems
                                                                  X. Liu
                                                          Volta Networks
                                                                  L. Liu
                                                                 Fujitsu
                                                         22 October 2023

           BGP Request for Candidate Paths of SR TE Policies
              draft-li-ldr-bgp-request-cp-sr-te-policy-06

Abstract

   An SR Policy is a set of candidate paths.  The headend of an SR
   Policy may learn multiple candidate paths for an SR Policy via a
   number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP.
   This document defines extensions to BGP for the headend to request
   BGP speaker (controller) for advertising the candidate paths.

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 RFC 2119 [RFC2119].

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 24 April 2024.

Li, et al.                Expires 24 April 2024                 [Page 1]
Internet-Draft         BGP Trigger SR TE Policies           October 2023

Copyright Notice

   Copyright (c) 2023 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Overview of BGP Request for SR-TE Paths . . . . . . . . . . .   3
   4.  BGP Request UPDATE Message  . . . . . . . . . . . . . . . . .   4
     4.1.  Extention of SR Policy NLRI . . . . . . . . . . . . . . .   4
     4.2.  New SR Policy Sub-TLVs  . . . . . . . . . . . . . . . . .   5
       4.2.1.  SR Path Attributes Sub-TLV  . . . . . . . . . . . . .   5
       4.2.2.  Synchronization Sub-TLV . . . . . . . . . . . . . . .   7
       4.2.3.  Metric Sub-TLV  . . . . . . . . . . . . . . . . . . .   8
       4.2.4.  Include Route Sub-TLV . . . . . . . . . . . . . . . .   9
       4.2.5.  Load Balance Sub-TLV  . . . . . . . . . . . . . . . .  10
       4.2.6.  Request Parameter Sub-TLV . . . . . . . . . . . . . .  10
   5.  IANA  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   6.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  12
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   An SR Policy defined in [I-D.ietf-spring-segment-routing-policy] is a
   set of candidate paths.  The headend of an SR Policy may be informed
   by various means including: Configuration, PCEP [RFC8281] or BGP
   [I-D.ietf-idr-segment-routing-te-policy].  All these mechanisms are
   Controller initiated, but in some situations the headend may want to
   pull a set of candidate paths from Controller rather than receive all
   information passively.  Actually PCEP can use request and reply
   messages defined in [RFC5440] to match this requirement, but the
   mechanism is not clear when controller advertises candidate paths via
   BGP.

Li, et al.                Expires 24 April 2024                 [Page 2]
Internet-Draft         BGP Trigger SR TE Policies           October 2023

   This document defines a way to request controller (BGP speaker) to
   advertise candidate paths via BGP update messages.  This makes BGP
   have the mechanism with request and reply similar to PCEP.

2.  Terminology

   RP: Request Parameters

   LSPA: LSP Attributes

   SVEC: Synchronization VECtor

   IRO: Include Route Object

   ERO: Explicit Route Object

   MSD: Base MPLS Imposition Maximum SID Depth, as defined in [RFC8491]

   NAI: Node or Adjacency Identifier

   PCC: Path Computation Client

   PCE: Path Computation Element

   PCEP: Path Computation Element Communication Protocol

   SID: Segment Identifier

   SR: Segment Routing

   SR-TE: Segment Routing Traffic Engineering

3.  Overview of BGP Request for SR-TE Paths

   [I-D.ietf-idr-segment-routing-te-policy] defines the extensions to
   BGP for a headend to receive candidate paths in a BGP UPDATE message
   from a controller (BGP speaker).  In some situations a headend just
   wants to get these candidate paths when some special event occurs
   (for example, when it receives a customer route (VPN route) with a
   special color or special BGP attribute).  This document defines the
   mechanism in which the headend requests the controller to advertise
   the expected SR policy with the candidate paths when this special
   situation occurs.

   At first, the headend decides to get a new candidate path from the
   controller based on some trigger event.  This trigger mechanism is
   out of scope of this document.

Li, et al.                Expires 24 April 2024                 [Page 3]
Internet-Draft         BGP Trigger SR TE Policies           October 2023

   Then, the headend creates a new BGP request UPDATE message (defined
   below in this document) and sends it to the controller.  The message
   contains the constraints/attributes of SR-TE paths such as affinity,
   metric, SRLG, and so on.  This special request UPDATE message is
   called request message or request for short.  It SHOULD NOT be used
   for BGP best path selection.

   After receiving the request message, the controller will calculate
   one or a set of paths (i.e., segment lists) according to the request
   from the headend and advertise the SR Policy with the paths computed
   to the headend using [I-D.ietf-idr-segment-routing-te-policy].  How
   to calculate the paths is out of scope of this document.

4.  BGP Request UPDATE Message

   A BGP request UPDATE message is based on the update message defined
   in [I-D.ietf-idr-segment-routing-te-policy] with some extensions
   described below.

4.1.  Extention of SR Policy NLRI

   The SR Policy NLRI defined in
   [I-D.ietf-idr-segment-routing-te-policy] has the following format:

    +------------------+
    |   NLRI Length    | 1 octet
    +------------------+
    |  Distinguisher   | 4 octets
    +------------------+
    |   Policy Color   | 4 octets
    +------------------+
    |    Endpoint      | 4 or 16 octets
    +------------------+

   where:

   *  NLRI Length: 1 octet of length expressed in bits as defined in
      [RFC4760].

   *  Distinguisher: 4-octet value uniquely identifying the policy in
      the context of <color, endpoint> tuple.  The distinguisher has no
      semantic value and is solely used by the SR Policy originator to
      make unique (from an NLRI perspective) multiple occurrences of the
      same SR Policy.

Li, et al.                Expires 24 April 2024                 [Page 4]
Internet-Draft         BGP Trigger SR TE Policies           October 2023

   *  Policy Color: 4-octet value identifying (with the endpoint) the
      policy.  The color is used to match the color of the destination
      prefixes to steer traffic into the SR Policy
      [I-D.ietf-spring-segment-routing-policy]

   *  Endpoint: identifies the endpoint of a policy.  The Endpoint may
      represent a single node or a set of nodes (e.g., an anycast
      address).  The Endpoint is an IPv4 (4-octet) address or an IPv6
      (16-octet) address according to the AFI of the NLRI.

   NLRI Length, Policy Color, Endpoint field remains unchanged, while
   the Distinguisher field will be set to FF:FF:FF:FF to indicate that
   the UPDATE message with this NLRI is a request message to the
   controller.

4.2.  New SR Policy Sub-TLVs

   The content of the SR Policy is encoded in the Tunnel Encapsulation
   Attribute TLV of type 23 defined in [I-D.ietf-idr-tunnel-encaps]
   containing a new Tunnel Type TLV of type 15.  The SR Policy Encoding
   structure is as follows:

   SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
   Attributes:
      Tunnel Encaps Attribute (23)
         Tunnel Type (15): SR Policy
           <Sub-TLVs>

   Preference, Binding SID, Priority, Policy Name, ENLP, Segment List,
   Weight and Segment Sub-TLVs are all defined in
   [I-D.ietf-idr-segment-routing-te-policy] for a SR Policy to be
   advertised to a headend.

   Additional 6 new Sub-TLVs are defined below for the request
   mechanism.  They are SR Path Attributes, Synchronization, Metric,
   Include Route, Load Balance, and Request Parameters Sub-TLVs.

4.2.1.  SR Path Attributes Sub-TLV

   A SR Path Attributes Sub-TLV contains the attributes of the SR paths
   requested, which are similar to an LSP Attributes Object defined in
   [RFC5440] and [RFC3209].

   It is optional and specifies various attributes or constraints of the
   paths requested.  Its format is shown below.

Li, et al.                Expires 24 April 2024                 [Page 5]
Internet-Draft         BGP Trigger SR TE Policies           October 2023

    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    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Exclude-any                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Include-any                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Include-all                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                        Optional sub-TLVs                      ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

   *  Type: TBD1

   *  Length: specifies the length of the value field not including Type
      and Length fields.

   *  Flags (8 bits): No flag is currently defined.  Undefined flags
      MUST be set to zero on transmission and be ignored on receipt.

   *  Reserved (8 bits): This field MUST be set to zero on transmission
      and be ignored on receipt.

   *  Exclude-any: A 32-bit vector representing a set of attribute
      filters associated with a path any of which renders a link
      unacceptable.

   *  Include-any: A 32-bit vector representing a set of attribute
      filters associated with a path any of which renders a link
      acceptable (with respect to this test).  A null set (all bits set
      to zero) automatically passes.

   *  Include-all: A 32-bit vector representing a set of attribute
      filters associated with a path all of which must be present for a
      link to be acceptable (with respect to this test).  A null set
      (all bits set to zero) automatically passes.

   *  Optional sub-TLVs: No optional sub-TLV is currently defined.

Li, et al.                Expires 24 April 2024                 [Page 6]
Internet-Draft         BGP Trigger SR TE Policies           October 2023

4.2.2.  Synchronization Sub-TLV

   A Synchronization Sub-TLV allows a headend to request the
   synchronization of a set of M dependent or independent SR path
   requests.  This TLV is similar to the SVEC Object defined in
   [RFC5440].  It is optional and has the following format.

    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            |S|N|L|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Request-ID No1                        |
   :                                                               :
   |                         Request-ID NoM                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

   *  Type: TBD2

   *  Length: specifies the length of the value field not including Type
      and Length fields.

   *  Flags (16 bits): Defines the potential dependency among a set of
      SR paths (i.e., segment lists).  Three flags are defined as
      follows:

      -  L (Link diverse) bit: when set, it indicates that the computed
         SR paths (i.e., segment lists) MUST NOT have any link in
         common.

      -  N (Node diverse) bit: when set, it indicates that the computed
         SR paths (i.e., segment lists) MUST NOT have any node in
         common.

      -  S (SRLG diverse) bit: when set, it indicates that the computed
         SR paths (i.e., segment lists) MUST NOT share any SRLG (Shared
         Risk Link Group).

   *  Request-ID No1, ..., NoM: each of which uniquely identifies one of
      M SR path requests.

   In case of M synchronized independent path requests, the bits L, N,
   and S are set to zero.

   Unassigned flags MUST be set to zero on transmission and MUST be
   ignored on receipt.

Li, et al.                Expires 24 April 2024                 [Page 7]
Internet-Draft         BGP Trigger SR TE Policies           October 2023

4.2.3.  Metric Sub-TLV

   A Metric Sub-TLV carries the same content as a Metric Object defined
   in [RFC5440] and [I-D.ietf-pce-segment-routing].  It has following
   format:

    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  |C|B|       T       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Metric-Value (4 octets)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   *  Type: TBD3.

   *  Length: specifies the length of the value field not including Type
      and Length fields.

   *  Flags (8 bits): Two flags are currently defined:

      -  B (Bound - 1 bit): When set, the metric-value indicates a bound
         (a maximum) for the path metric that must not be exceeded for
         the headend to consider the computed path as acceptable.  The
         path metric must be less than or equal to the value specified
         in the metric-value field.  When the B flag is cleared, the
         metric-value field is not used to reflect a bound constraint.

      -  C (Computed Metric - 1 bit): When set, it indicates that the
         controller MUST provide the computed path metric value (should
         a path satisfying the constraints be found) in the
         advertisement message for the corresponding metric.

      -  Unassigned flags MUST be set to zero on transmission and MUST
         be ignored on receipt.

   *  T (Type - 8 bits): Specifies the metric type.  Four metric types
      are currently defined:

      -  T=1: IGP metric

      -  T=2: TE metric

      -  T=3: Hop Counts

      -  T=11: Maximum SID Depth of the requested path

Li, et al.                Expires 24 April 2024                 [Page 8]
Internet-Draft         BGP Trigger SR TE Policies           October 2023

   *  Metric-Value (32 bits): It is a metric value encoded in 32 bits
      IEEE floating point format (see [IEEE.754.1985]).

4.2.4.  Include Route Sub-TLV

   The Include Route Sub-TLV is optional and can be used to specify that
   the computed candidate path MUST traverse a set of specified network
   elements.  The Include Route Sub-TLV carries the same content as IRO
   Object defined in[RFC5440], [RFC3209] and SR-ERO defined in
   [I-D.ietf-pce-segment-routing]

   The Include Route Sub-TLV has following format:

    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     |   NT  |        Flags  |F|S|C|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                          SID (optional)                       ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                   NAI (variable, optional)                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where:

   *  Type: TBD4.

   *  Length: It specifies the length of the value field not including
      Type and Length fields.

   *  NAI Type (NT): It indicates the type and format of the NAI
      contained, if any is present.  If the F bit is set to zero, then
      the NT field has no meaning and MUST be ignored by the receiver.
      This document describes the following NT values:

      -  NT=0: The NAI is absent.

      -  NT=1: The NAI is an IPv4 node ID.

      -  NT=2: The NAI is an IPv6 node ID.

      -  NT=3: The NAI is an IPv4 adjacency.

      -  NT=4: The NAI is an IPv6 adjacency with global IPv6 addresses.

      -  NT=5: The NAI is an unnumbered adjacency with IPv4 node IDs.

Li, et al.                Expires 24 April 2024                 [Page 9]
Internet-Draft         BGP Trigger SR TE Policies           October 2023

      -  NT=6: The NAI is an IPv6 adjacency with link-local IPv6
         addresses.

   *  SID and NAI are the same as SR-ERO defined in
      [I-D.ietf-pce-segment-routing]

4.2.5.  Load Balance Sub-TLV

   A Load Balance Sub-TLV specifies how many SR paths (i.e., segment
   lists) should be computed for a path request.  It has following
   format:

   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    |     Flag      |   Max-Slist   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                       Optional sub-TLVs                       ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where:

   *  Type: TBD5.

   *  Length: It specifies the length of the value field not including
      Type and Length fields.

   *  Flags (8 bits): No flag is currently defined.  The Flags field
      MUST be set to zero on transmission and MUST be ignored on
      receipt.

   *  Max-Slist (8 bits): It indicates the maximum number of SR paths
      (i.e., segment lists) to be computed for the request.  The load is
      distributed among these SR paths.

   *  Optional sub-TLVs: No Optional sub-TLV is currently defined.

4.2.6.  Request Parameter Sub-TLV

   A Request Parameter (RP) Sub-TLV specifies the request identifier and
   other parameters for a path request.  It has the format below.

Li, et al.                Expires 24 April 2024                [Page 10]
Internet-Draft         BGP Trigger SR TE Policies           October 2023

   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               |O|B|R|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Request-ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                       Optional sub-TLVs                       ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where:

   *  Type: TBD6.

   *  Length: It specifies the length of the value field not including
      Type and Length fields.

   *  Flags (16 bits): Three flag bits are currently defined as follows:

      -  R (Reoptimization - 1 bit): when set, it indicates that the SR
         path request message is for the reoptimization of an existing
         SR path, which is represented by a segment list Sub-TLV in the
         message.

      -  B (Bi-directional - 1 bit): when set, it indicates that the SR
         path request relates to bi-directional paths that has the same
         traffic engineering requirements including fate sharing, TE
         links, and other requirements (such as latency and jitter) in
         each direction.

      -  O (strict/loose - 1 bit): when set, it indicates that a loose
         path is acceptable.  Otherwise (i.e., when cleared), it
         indicates that a path exclusively made of strict hops is
         required.

5.  IANA

   Under Existing Registry Name: "BGP Tunnel Encapsulation Attribute
   Sub-TLVs", IANA is requested to assign new Sub-TLV values for SR Path
   Request as follows:

Li, et al.                Expires 24 April 2024                [Page 11]
Internet-Draft         BGP Trigger SR TE Policies           October 2023

   +------------+-----------------------------+-------------------+
   | Type Value |       Sub-TLV Name          |    Reference      |
   +------------+-----------------------------+-------------------+
   |   TBD1     | SR Path Attributes Sub-TLV  |   This document   |
   +------------+-----------------------------+-------------------+
   |   TBD2     | Synchronization Sub-TLV     |   This document   |
   +------------+-----------------------------+-------------------+
   |   TBD3     | Metric Sub-TLV              |   This document   |
   +------------+-----------------------------+-------------------+
   |   TBD4     | Include Route Sub-TLV       |   This document   |
   +------------+-----------------------------+-------------------+
   |   TBD5     | Load Balance Sub-TLV        |   This document   |
   +------------+-----------------------------+-------------------+
   |   TBD6     | Request Parameters Sub-TLV  |   This document   |
   +------------+-----------------------------+-------------------+

6.  Contributors

   TBD

7.  Acknowledgments

   TBD

8.  References

8.1.  Normative References

   [I-D.ietf-idr-segment-routing-te-policy]
              Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., and
              D. Jain, "Advertising Segment Routing Policies in BGP",
              Work in Progress, Internet-Draft, draft-ietf-idr-segment-
              routing-te-policy-25, 26 September 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-idr-
              segment-routing-te-policy-25>.

   [I-D.ietf-spring-segment-routing-policy]
              Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
              P. Mattes, "Segment Routing Policy Architecture", Work in
              Progress, Internet-Draft, draft-ietf-spring-segment-
              routing-policy-22, 22 March 2022,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              segment-routing-policy-22>.

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

Li, et al.                Expires 24 April 2024                [Page 12]
Internet-Draft         BGP Trigger SR TE Policies           October 2023

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <https://www.rfc-editor.org/info/rfc5440>.

   [RFC8281]  Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for PCE-Initiated LSP Setup in a Stateful PCE
              Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
              <https://www.rfc-editor.org/info/rfc8281>.

8.2.  Informative References

   [I-D.ietf-idr-tunnel-encaps]
              Patel, K., Van de Velde, G., Sangli, S. R., and J.
              Scudder, "The BGP Tunnel Encapsulation Attribute", Work in
              Progress, Internet-Draft, draft-ietf-idr-tunnel-encaps-22,
              7 January 2021, <https://datatracker.ietf.org/doc/html/
              draft-ietf-idr-tunnel-encaps-22>.

   [I-D.ietf-pce-segment-routing]
              Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
              and J. Hardwick, "Path Computation Element Communication
              Protocol (PCEP) Extensions for Segment Routing", Work in
              Progress, Internet-Draft, draft-ietf-pce-segment-routing-
              16, 4 March 2019, <https://datatracker.ietf.org/doc/html/
              draft-ietf-pce-segment-routing-16>.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
              <https://www.rfc-editor.org/info/rfc3209>.

   [RFC4090]  Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
              Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
              DOI 10.17487/RFC4090, May 2005,
              <https://www.rfc-editor.org/info/rfc4090>.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              DOI 10.17487/RFC4760, January 2007,
              <https://www.rfc-editor.org/info/rfc4760>.

   [RFC5420]  Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A.
              Ayyangar, "Encoding of Attributes for MPLS LSP
              Establishment Using Resource Reservation Protocol Traffic
              Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420,
              February 2009, <https://www.rfc-editor.org/info/rfc5420>.

Li, et al.                Expires 24 April 2024                [Page 13]
Internet-Draft         BGP Trigger SR TE Policies           October 2023

Authors' Addresses

   Zhenbin Li
   Huawei
   156 Beiqing Road
   Beijing, 100095
   P.R. China
   Email: lizhenbin@huawei.com

   Qiangzhou Gao
   Huawei
   156 Beiqing Road
   Beijing, 100095
   P.R. China
   Email: gaoqiangzhou@huawei.com

   Huaimo Chen
   Futurewei
   Boston, MA,
   United States of America
   Email: Huaimo.chen@futurewei.com

   Yanhe Fan
   Casa Systems
   United States of America
   Email: yfan@casa-systems.com

   Xufeng Liu
   Volta Networks
   McLean, VA
   United States of America
   Email: xufeng.liu.ietf@gmail.com

   Lei Liu
   Fujitsu
   United States of America
   Email: liulei.kddi@gmail.com

Li, et al.                Expires 24 April 2024                [Page 14]