[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                              Z. Li
Internet-Draft                                                        Li
Intended status: Standards Track                                  Huawei
Expires: January 9, 2020                                   July 08, 2019


    BGP Request for Advertising Candidate Path of Segment Routing TE
                                Policies
              draft-li-ldr-bgp-request-cp-sr-te-policy-00

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.
   BGP distribute candidate paths has been defined in
   [I-D.ietf-idr-segment-routing-te-policy].  This document defines an
   extension of BGP to request BGP speaker(controller) advertise the
   candidate paths.  The goal is to unify the protocol when the
   candidate path of SR Policy provision is via BGP to reduce the
   network complexity and potential bugs cause by different protocol
   interactions.

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 January 9, 2020.






Li & Li                  Expires January 9, 2020                [Page 1]


Internet-Draft         BGP Trigger SR TE Policies              July 2019


Copyright Notice

   Copyright (c) 2019 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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Overview of BGP UPDATE Message for Request SR TE policy
       candidate path advertising  . . . . . . . . . . . . . . . . .   3
   4.  BGP request UPDATE Message Encoding . . . . . . . . . . . . .   4
     4.1.  Extention of SR Policy NLRI . . . . . . . . . . . . . . .   4
     4.2.  New SR Policy and Tunnel Encapsulation Attribute  . . . .   5
     4.3.  New SR Policy Sub-TLVs  . . . . . . . . . . . . . . . . .   5
       4.3.1.  LSPA Sub-TLV  . . . . . . . . . . . . . . . . . . . .   5
       4.3.2.  SVEC Sub-TLV  . . . . . . . . . . . . . . . . . . . .   7
       4.3.3.  Metric Sub-TLV  . . . . . . . . . . . . . . . . . . .   8
       4.3.4.  Include Route Sub-TLV . . . . . . . . . . . . . . . .   9
       4.3.5.  Load-Balancing Sub-TLV  . . . . . . . . . . . . . . .  10
   5.  IANA  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   6.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  11
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

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 PCE/Controller initiated, but in some situations headend maybe
   want pull one or a set of candidate paths from PCE/Controller rather
   than get 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 advertise candidate path
   via BGP protocol.



Li & Li                  Expires January 9, 2020                [Page 2]


Internet-Draft         BGP Trigger SR TE Policies              July 2019


   This document wants to define a way to request controller(BGP
   speaker) advertise candidate path via BGP update message to let BGP
   protocol can also get the similar mechanism with request and reply
   like 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 UPDATE Message for Request SR TE policy candidate
    path advertising

   [I-D.ietf-idr-segment-routing-te-policy] defined the headend get
   candidate paths by BGP from controller(BGP speaker).  In some
   situations headend just want get these candidate paths when some
   special event occur (e.g receive a customer route (VPN route) with
   special color or special BGP attribute).  This document define the
   mechanism when this special situation occurred how the headend
   request controller to advertise the matched SR policy with the
   candidate paths.

   Step1.  The headend decide to get a new candidate path from
   controller based on some trigger event.  This trigger mechanism is
   out of scope of this document.



Li & Li                  Expires January 9, 2020                [Page 3]


Internet-Draft         BGP Trigger SR TE Policies              July 2019


   Step2.  The headend create a new BGP request UPDATE message (defined
   in this document) with constrains of TE, such as affinity, metric,
   SRLG, and so on.  This special request UPDATE message SHOULD NOT be
   used for BGP best path selection.

   Step3.  The controller will calculate one or a set of segment list
   based on the payload of BGP request message from headend.  How to
   calculate the path is out of scope of this document.

   Step4.  The controller advertise SR Policy with candidate path to
   headend.  How to advertise the policy is out of scope of this
   document and defined in [I-D.ietf-idr-segment-routing-te-policy]

4.  BGP request UPDATE Message Encoding

4.1.  Extention of SR Policy NLRI

   defined the SR Policy NLRI as follows:

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

   where:

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

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

   o  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]

   o  Endpoint: identifies the endpoint of a policy.  The Endpoint may
      represent a single node or a set of nodes (e.g., an anycast




Li & Li                  Expires January 9, 2020                [Page 4]


Internet-Draft         BGP Trigger SR TE Policies              July 2019


      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 signal the
   request to controller.

4.2.  New SR Policy and Tunnel Encapsulation Attribute

   The content of the SR Policy is encoded in the Tunnel Encapsulation
   Attribute originally defined in [I-D.ietf-idr-tunnel-encaps] using a
   new Tunnel-Type TLV (codepoint is 15, assigned by IANA.  The SR
   Policy Encoding structure is as follows:

   SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
   Attributes:
      Tunnel Encaps Attribute (23)
         Tunnel Type: 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 SR Policy advertise to
   headend.

   Additional 6 new Sub-TLVs are defined in this document section 3.3
   for request mechanism.

   1.  LSPA Sub-TLV

   2.  SVEC Sub-TLV

   3.  Metric Sub-TLV

   4.  Include Route Sub-TLV

   5.  Load-Balancing

4.3.  New SR Policy Sub-TLVs

4.3.1.  LSPA Sub-TLV

   The LSPA(LSP Attributes) Sub-TLV carries the same content as LSPA
   Object defined in [RFC5440] and [RFC3209].

   The LSPA Sub-TLV is optional and specifies various TE LSP attributes
   to be taken for path computation.  Most of the fields of the LSPA
   Sub-TLV are identical to the fields of the SESSION-ATTRIBUTE object



Li & Li                  Expires January 9, 2020                [Page 5]


Internet-Draft         BGP Trigger SR TE Policies              July 2019


   (C-Type = 7) defined in [RFC3209] . See Section 4.7.4 of [RFC3209]
   for a detailed description of the use of resource affinities.

   The LSPA 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     |     Flags   |L|   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Exclude-any sub-TLV                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Include-any sub-TLV                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Include-all sub-TLV                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                     Optional sub-TLVs                         ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

   o  Type: TBD1

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

   o  Flags (8 bits)

      *  L flag: Corresponds to the "Local Protection Desired" bit
         [RFC3209] of the SESSION-ATTRIBUTE Object.  When set, this
         means that the computed path must include links protected with
         Fast Reroute as defined in [RFC4090].

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

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

   o  Optional TLVs may be defined in the future to carry additional TE
      LSP attributes such as those defined in [RFC5420]

   o  Exclude-any, Include-any, Include-all sub-TLV's format is the same
      as subobjects defined in[RFC3209]







Li & Li                  Expires January 9, 2020                [Page 6]


Internet-Draft         BGP Trigger SR TE Policies              July 2019


4.3.2.  SVEC Sub-TLV

   The SVEC (Synchronization VECtor) Sub-TLV carries the same content as
   SVEC Object defined in [RFC5440].

   The SVEC Sub-TLV allows headend to request the synchronization of a
   set of dependent or independent segment list computation requests.
   It's optional be carried.

   The SVEC 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    |        Flags            |S|N|L|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

   o  Type: TBD2

   o  Length: the total length (not including the Type and Length
      fields) of the sub-TLVs encoded

   o  Flags (24 bits): Defines the potential dependency between a set of
      segment lists in one candidate path.

   o

      *  L (Link diverse) bit: when set, this indicates that the
         computed segment lists of the same candidate path MUST NOT have
         any link in common.

      *  N (Node diverse) bit: when set, this indicates that the
         computed segment lists of the same candidate path MUST NOT have
         any node in common.

      *  S (SRLG diverse) bit: when set, this indicates that the
         computed segment lists of the same candidate path MUST NOT
         share any SRLG (Shared Risk Link Group).

   In case of a set of segment lists synchronized independent path
   computation, the bits L, N, and S are cleared.

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





Li & Li                  Expires January 9, 2020                [Page 7]


Internet-Draft         BGP Trigger SR TE Policies              July 2019


4.3.3.  Metric Sub-TLV

   The Metric Sub-TLV carries the same content as Metric Object defined
   in[RFC5440] and [I-D.ietf-pce-segment-routing].  The Metric 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    |    Flags  |C|B|       T       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     metric-value (4 octets)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: TBD3

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

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

      *  B (Bound - 1 bit): When set in a BGP UPDATE message, 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 in a BGP UPDATE message,
         this indicates that the controller MUST provide the computed
         path metric value (should a path satisfying the constraints be
         found) in the advertise message for the corresponding metric.

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

   o  T (Type - 8 bits): Specifies the metric type

      *  Four values 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 & Li                  Expires January 9, 2020                [Page 8]


Internet-Draft         BGP Trigger SR TE Policies              July 2019


   o  Metric-value (32 bits): metric value encoded in 32 bits in IEEE
      floating point format (see [IEEE.754.1985]).

4.3.4.  Include Route Sub-TLV

   TheThe 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 defiend 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          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                          SID (optional)                       ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                   NAI (variable, optional)                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where:

   o  Type: TBD4

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

   o  NAI Type (NT): Indicates the type and format of the NAI contained
      in the Sub-TLV body, if any is present 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 & Li                  Expires January 9, 2020                [Page 9]


Internet-Draft         BGP Trigger SR TE Policies              July 2019


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

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

4.3.5.  Load-Balancing Sub-TLV

   The Load-Balancing Sub-TLV defined how many segment list should be
   included in one candidate path.  The Load-Balancing 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    |     Flag      |   Max-Slist   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                          Option TLV                           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where:

   o  Type: TBD5

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

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

   o  Max-Slist (8 bits): maximum number of S-Lists in the candidate
      path.

   o  Option TLV: No Option TLV currently defined.  If bandwidth can be
      reserved in SR-Policy candidate path or different load-balancing
      principle between segment lists for diferent weight here can
      define additional TLVs.

5.  IANA

   This document defines new Sub-TLVs in following existing registries:










Li & Li                  Expires January 9, 2020               [Page 10]


Internet-Draft         BGP Trigger SR TE Policies              July 2019


   +------------+-----------------------+---------------------------+
   | Type Value |        Sub-TLV        |       Description         |
   +----------------------------------------------------------------+
   |   TBD1     |      LSA-Sub-TLV      |      This document        |
   +----------------------------------------------------------------+
   |   TBD2     |     SVEC Sub-TLV      |      This document        |
   +----------------------------------------------------------------+
   |   TBD3     |    Metric Sub-TLV     |      This document        |
   +----------------------------------------------------------------+
   |   TBD4     | Include Route Sub-TLV |      This document        |
   +----------------------------------------------------------------+
   |   TBD5     |     Load-Balancing    |      This document        |
   +------------+-----------------------+---------------------------+

6.  Contributors

   TBD

7.  Acknowledgments

   TBD

8.  References

   [I-D.ietf-idr-segment-routing-te-policy]
              Previdi, S., Filsfils, C., Mattes, P., Rosen, E., Jain,
              D., and S. Lin, "Advertising Segment Routing Policies in
              BGP", draft-ietf-idr-segment-routing-te-policy-07 (work in
              progress), July 2019.

   [I-D.ietf-idr-tunnel-encaps]
              Patel, K., Velde, G., Ramachandra, S., and E. Rosen, "The
              BGP Tunnel Encapsulation Attribute", draft-ietf-idr-
              tunnel-encaps-12 (work in progress), May 2019.

   [I-D.ietf-pce-segment-routing]
              Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
              and J. Hardwick, "PCEP Extensions for Segment Routing",
              draft-ietf-pce-segment-routing-16 (work in progress),
              March 2019.

   [I-D.ietf-spring-segment-routing-policy]
              Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,
              bogdanov@google.com, b., and P. Mattes, "Segment Routing
              Policy Architecture", draft-ietf-spring-segment-routing-
              policy-03 (work in progress), May 2019.





Li & Li                  Expires January 9, 2020               [Page 11]


Internet-Draft         BGP Trigger SR TE Policies              July 2019


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

   [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.
              Ayyangarps, "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>.

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

Authors' Addresses

   Zhenbin Li
   Huawei
   156 Beiqing Road
   Beijing, 100095
   P.R. China

   Email: lizhenbin@huawei.com





Li & Li                  Expires January 9, 2020               [Page 12]


Internet-Draft         BGP Trigger SR TE Policies              July 2019


   Lei Li
   Huawei
   156 Beiqing Road
   Beijing, 100095
   P.R. China

   Email: lily.lilei@huawei.com












































Li & Li                  Expires January 9, 2020               [Page 13]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/