Network Working Group                                            J. Dong
Internet-Draft                                                   M. Chen
Intended status: Standards Track                                D. Dhody
Expires: December 26, 2016 April 30, 2017                              Huawei Technologies
                                                             J. Tantsura
                                                              Individual
                                                               K. Kumaki
                                                        KDDI Corporation
                                                                T. Murai
                                         Furukawa Network Solution Corp.
                                                           June 24,
                                                        October 27, 2016

      BGP Extensions for Path Computation Element (PCE) Discovery
                 draft-dong-pce-discovery-proto-bgp-05
                 draft-dong-pce-discovery-proto-bgp-06

Abstract

   In networks where a Path Computation Element (PCE) is used for
   centralized path
   computation, it is desirable for the Path Computation Clients (PCCs)
   to automatically discover dynamically and automatically a set of PCEs
   and select the suitable ones to establish the PCEP session. along with
   certain information relevant for PCE selection.  RFC 5088 and RFC
   5089 define the PCE discovery mechanisms based on Interior Gateway
   Protocols (IGP).  This document describes several scenarios
   in which the IGP based PCE discovery mechanisms cannot be used
   directly.  In such scenarios, BGP might be suitable, thus this
   document specifies the BGP defines extensions to BGP for the
   advertisement of PCE discovery. Discovery information.  The BGP based PCE
   discovery mechanism is complementary to the existing IGP based
   mechanisms.

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 http://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 December 26, 2016. April 30, 2017.

Copyright Notice

   Copyright (c) 2016 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
   (http://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.  Carrying PCE Discovery Information in BGP . . . . . . . . . .   4   3
     2.1.  PCE Address Information NLRI  . . . . . . . . . . . . . . . . . . . . . . . .   3
       2.1.1.  PCE Descriptors . . . . . . . . . . . . . . . . . . .   4
     2.2.  PCE Discovery Attribute TLVs  . . . . . . . . . . . . . . . . . . .   5
       2.2.1.  PCE Domain TLV  . . . . . . . . . . . . . . . . . . .   6
       2.2.2.  Neighbor PCE Domain TLV . . . . . . . . . . . . . . .   6
   3.  Operational Considerations  . . . . . . . . . . . . . . . . .   6   7
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   In network scenarios networks where a Path Computation Element (PCE) is used for
   centralized path
   computation, it is desirable for the Path Computation Clients (PCCs)
   to automatically discover dynamically and automatically a set of PCEs
   and select the suitable ones to establish the PCEP session. along with
   certain information relevant for PCE selection.  [RFC5088] and
   [RFC5089] define the PCE discovery mechanisms based on Interior
   Gateway Protocols (IGP).

   The IGP based discovery mechanism requires the PCE participate  When PCCs are LSRs participating in the IGP network, which usually requires that
   (OSPF or IS-IS), and PCEs are either LSRs or servers also
   participating in the IGP, an effective mechanism for PCE is directly adjacent
   to at least one discovery
   within an IGP routing domain consists of the utilizing IGP routers in the network.  In some scenarios
   such requirement cannot be satisfied.  For example,
   advertisements.

   [RFC4674] presents a PCE may need to
   provide path computation service to some subsidiary networks set of an
   operator, which typically locate in different geographical region
   (and not IGP adjacent).  Also when PCE function is implemented in requirements for a
   central server running IGP on individual interfaces to each IGP area
   can be cumbersome.

   The requirement on PCE discovery, as described in [RFC4674], also
   include discovery
   mechanism.  This includes the automatic discovery by a PCC of the a set of one or
   more PCEs which may potentially be in some other domains, as it domains.  This is a
   desirable function in the case of inter-domain path computation.
   The IGP based discovery mechanisms cannot meet such requirement.  For
   example, Backward Recursive Path Computation (BRPC) [RFC5441] can be
   used by cooperating PCEs to compute an inter-AS path, in which case these cooperating PCEs should be known to each other in advance.
   In this case
   the PCEs belongs to different AS and do not participate
   in a common IGP, the IGP based discovery mechanisms are not
   applicable.

   Another example is the hierarchical PCE scenario [RFC6805], in which
   the child PCEs need to know the information of the parent PCEs.  This
   cannot be achieved via IGP based discovery, as the child PCEs and the
   parent PCE are usually in different domains.

   In some BGP IP-VPN networks, an end-to-end TE LSP between the CEs
   (Customer Edges) of a particular VPN is required [RFC5824].  In this
   case, CEs need as well as the domain information of the PCE which can perform the CE to
   CE path computation for that VPN.  Since the PCE may locate in a VPN
   site different from the site of the requesting CE, the IGP based
   discovery mechanism is not directly applicable, and some BGP based
   discovery mechanism is required to distribute the per-VPN PCE
   information to the VPN sites.

   Since useful.

   BGP has been extended for north-bound distribution of routing and Label Switched Path (LSP) TE
   information to PCE [RFC7752]
   [I-D.ietf-idr-te-lsp-distribution] and [I-D.ietf-idr-te-pm-bgp], PCEs
   can obtain the routing information without participating in IGP.  In [I-D.ietf-idr-te-pm-bgp].  Similary
   this scenario, a new document extends BGP based to also carry the PCE discovery mechanism is needed.
   information.

   This document proposes defines extensions to extend BGP for PCE discovery in the above
   scenarios.  In networks where BGP-LS is used for the north-bound
   routing information distribution to PCE, the BGP based allow a PCE discovery
   can make use of the existing BGP sessions and mechanisms to achieve
   automatic PCE discovery.  Further IGP may be used advertise
   its location, along with some information useful to redistribute
   remote PCE information, the detailed mechanism is out of the scope of
   this document.  Thus a PCC for the BGP based PCE discovery is complementary
   selection, so as to
   the existing IGP based mechanisms.

                           +-----------+
                           |    PCE    |
                           +-----------+
                                 |
                                 v
                           +-----------+
                           |    BGP    |               +-----------+
                           |  Speaker  |               |    PCE    |
                           +-----------+               +-----------+
                             |   |   |                       |
                             |   |   |                       |
             +---------------+   |   +-------------------+   |
             v                   v                       v   v
       +-----------+       +-----------+             +-----------+
       |    BGP    |       |    BGP    |             |    BGP    |
       |  Speaker  |       |  Speaker  |    . . .    |  Speaker  |
       |   & PCC   |       |   & PCC   |             |   & PCC   |
       +-----------+       +-----------+             +-----------+

                      Figure 1: BGP for satisfy dynamic PCE discovery

   As shown in the network architecture requirements set
   forth in Figure 1, BGP is used both
   for routing information distribution and for [RFC4674].

   This specification contains two parts: definition of a new BGP-LS
   NLRI [RFC7752] that describes PCE information
   discovery.  The routing information is collected from the network
   elements and distributed to PCE, while the PCE discovery information
   is advertised from definition of PCE to PCCs, or among different PCEs.  The PCCs
   maybe co-located with the BGP speakers
   Attribute TLVs as shown in Figure 1. part of BGP-LS attributes.

2.  Carrying PCE Discovery Information in BGP

2.1.  PCE Address Information NLRI

   The PCE discovery information is advertised in BGP UPDATE messages
   using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760].
   The AFI and SAFI "Link- State NLRI" defined in [RFC7752] are re-used.  For is extended to carry the PCEs in
   public network,
   PCE information.  BGP speakers that wish to exchange PCE discovery
   information MUST use the AFI / SAFI pair is 16388 / 71, while for BGP Multiprotocol Extensions Capability Code
   (1) to advertise the PCEs corresponding (AFI, SAFI) pair, as specified in
   [RFC4760].

   The format of a particular VPN, the AFI / SAFI pair "Link-State NLRI" is set to 16388 / 72. defined in [RFC7752].  A new NLRI Type "NLRI
   Type" is defined for PCE discovery information Information as below: following:

   o  Type = TBD: TBD1: PCE Discovery NLRI

   The format of PCE Discovery NLRI is shown in the following figure:

       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
      +-+-+-+-+-+-+-+-+
      |  Protocol-ID  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Identifier                          |
      |                            (64 bits)                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                  PCE-Address (4 or 16 octets)                  PCE Descriptors (variable)                   ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       Figure 2. 1. PCE Discovery NLRI

   The 'Protocol-ID' field SHOULD is defined in [RFC7752], to be set to the
   appropriate value which that indicates the source of the PCE discovery information.
   If BGP speaker and PCE are co-located, the Protocol-ID SHOULD be set
   to "Direct".  In other cases, it  If PCE information to advertise is RECOMMENDED that configured at the
   BGP speaker, the Protocol-ID
   value SHOULD be set to "Static configuration".

   As defined in [RFC7752], the 64-Bit 'Identifier' field is used to
   identify the "routing universe" where the PCE belongs.

2.2.

2.1.1.  PCE Discovery TLVs Descriptors

   The detailed PCE discovery information Descriptor field is carried in the BGP-LS
   attribute [RFC7752] with a new "PCE Discovery TLV", which contains a set of sub-TLVs for specific Type/Length/Value (TLV)
   triplets.  The format of each TLV is as per Section 3.1 of [RFC7752].
   The PCE discovery information. Descriptor TLVs uniquely identify a PCE.  The following PCE
   Discovery
   descriptor are defined -

      +-----------+-----------------------+----------+
      | Codepoint |       Descriptor TLV and sub-TLVs SHOULD only  | Length   |
      +-----------+-----------------------+----------+
      |  TBD2     | IPv4 PCE Address      |   4      |
      |  TBD3     | IPv6 PCE Address      |   16     |
      +-----------+-----------------------+----------+
                     Table 1: PCE Descriptors

   The PCE address TLVs specifies an IP address that can be used with to
   reach the PCE Discovery
   NLRI. PCE.  The PCE-ADDRESS Sub-TLV defined in [RFC5088] and
   [RFC5089] is used in the OSPF and IS-IS respectively.  The format of
   the PCE Discovery address TLV is shown as below: are -
       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              Type=TBD2        |             Length             Length=4          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         IPv4 PCE Address                      |
     ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       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=TBD3        |             Length=16         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                         IPv6 PCE Discovery Sub-TLVs (variable)             ~ Address                      |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          Figure 3. 2. PCE Discovery TLV

   The Address TLVs

   When the PCE Discovery sub-TLVs has both an IPv4 and IPv6 address, both the TLVs MAY be
   included.

2.2.  PCE Attribute TLVs

   PCE Attribute TLVs are listed TLVs that may be encoded in the BGP-LS
   attribute [RFC7752] with a PCE NLRI.  The format of each TLV is as below.
   per Section 3.1 of [RFC7752].  The format and semantics of the Value
   fields in some PCE Discovery sub-TLVs are consistent with Attribute TLVs correspond to the IGP format and
   semantics of the Value fields in IS-IS PCED sub-TLVs as Sub-TLV, defined in [RFC5088] and
   [RFC5089].  Other PCE Attribute TLVs are defined in this document.

   The PATH-SCOPE sub-TLV MUST
   always be carried following PCE Attribute TLVs are valid in the BGP-LS attribute
   with a PCE Discovery TLV.  Other NLRI:

   +-----------+---------------------+--------------+------------------+
   |  TLV Code | Description         |  IS-IS TLV   | Reference        |
   |   Point   |                     |   /Sub-TLV   | (RFC/Section)    |
   +-----------+---------------------+--------------+------------------+
   |    TBD4   | Path Scope          |       5/2    | [RFC5089]/4.2    |
   |    TBD5   | PCE Discovery sub- Domain          |       -      |       -          |
   |    TBD6   | Neighbor PCE        |       -      |       -          |
   |           | Domain              |              |                  |
   |    TBD7   | PCE Capability      |       5/5    | [RFC5089]/4.5    |
   +-----------+---------------------+--------------+------------------+
                        Table 2: PCE Attribute TLVs are optional

   The format and may facilitate semantics of Path Scope and PCE capability is as per
   [RFC5089].  The Path Scope TLV is mandatory.

2.2.1.  PCE Domain TLV

   The PCE Domain TLV specifies a PCE-Domain (IGP area and/or AS) where
   the PCE selection process on has topology visibility and through which the
   PCCs.

     Type PCE can compute
   paths.

    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=TBD5        |             Length            |      Name
    ------+------------+--------------------------------
     1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     3                                                               |  PATH-SCOPE sub-TLV
     2
   //                       Domain Sub-TLVs (variable)            //
   |  variable                                                               |  PCE-CAP-FLAGS sub-TLV
     3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The length of this TLV is variable.  The value contains one or more
   domain sub-TLVs as listed below -

          +--------------------+-------------------+----------+
          | Sub-TLV Code Point | Description       |  variable   Length |
          +--------------------+-------------------+----------+
          |        512         | Autonomous System |  OSPF-PCE-DOMAIN sub-TLV        4 |  variable
          |  IS-IS-PCE-DOMAIN sub-TLV
     5        514         |  variable OSPF Area-ID      |  OSPF-NEIG-PCE-DOMAIN sub-TLV
     6        4 |  variable
          |  IS-IS-NEIG-PCE-DOMAIN sub-TLV

   More PCE Discovery        1027        | IS-IS Area        | Variable |
          |                    | Identifier        |          |
          +--------------------+-------------------+----------+

   Multiple sub-TLVs may MAY be defined in future. included, when the PCE has visibility into
   multiple PCE-Domains.

2.2.2.  Neighbor PCE Domain TLV

   The format and
   semantic of new Neighbor PCE Discovery Domain TLV specifies a neighbor PCE-Domain (IGP area
   and/or AS) toward which a PCE can compute paths.

    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=TBD6        |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                       Domain Sub-TLVs (variable)            //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   The length of this TLV is variable.  The value contains one or more
   domain sub-TLVs SHOULD as listed above.  Multiple sub-TLVs MAY be consistent in BGP
   and IGP based included,
   when the PCE discovery. can compute paths towards several neighbor PCE-Domains.

3.  Operational Considerations

   Existing BGP BGP-LS operational procedures apply to the advertisement of
   PCE
   discovery information. information as per [RFC7752].  This information is treated as
   pure application level data which has no immediate impact on
   forwarding states.  Normal BGP path selection can be applied to PCE Discovery
   NLRI only for the information propagation in the network, while on
   PCCs the PCE selection is based on the information carried in the PCE
   Discovery TLV.  The PCE discovery information SHOULD be advertised only to
   the domains where such information is allowed to be used.  This can
   be achieved by policy control on the ASBRs.

   The PCE discovery information is considered relatively stable and does not
   change frequently, thus this information will not bring significant
   impact on the amount of BGP updates in the network.

4.  IANA Considerations

   IANA needs to assign a new NLRI Type for 'PCE Discovery NLRI' from the "BGP-LS
   NLRI-Types" registry.

   IANA needs to assign a new TLV code point for 'PCE Discovery TLV' as per Table 1 and 2 from the "node anchor, link descriptor
   "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and link attribute
   Attribute TLVs" registry.

   [Editor's Note - Check if name of the registry should be changes with
   following instructions - Further IANA needs is requested to create a new registry for "PCE Discovery Sub-TLVs".
   The rename the
   registry will be initialized as shown in section 2.2 of this
   document. "BGP-LS Node Descriptor, Link Descriptor, Prefix
   Descriptor, PCE Descriptor, and Attribute TLVs".]

5.  Security Considerations

   Procedures and protocol extensions defined in this document do not
   affect the BGP security model.  See the 'Security Considerations'
   section of [RFC4271] for a discussion of BGP security.  Also refer to
   [RFC4272] and [RFC6952] for analysis of security issues for BGP.

   Existing BGP-LS security considerations as per [RFC7752] continue to
   apply.

6.  Contributors

   The following individuals gave significant contributions to this
   document:

   Takuya Miyasaka
   KDDI Corporation
   ta-miyasaka@kddi.com

7.  Acknowledgements

   The authors would like to thank Zhenbin Li, Hannes Gredler, Jan
   Medved, Adrian Farrel, Julien Meuric and Jonathan Hardwick for the
   valuable discussion and comments.

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,
              <http://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,
              <http://www.rfc-editor.org/info/rfc4271>.

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

   [RFC5088]  Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
              Zhang, "OSPF Protocol Extensions for Path Computation
              Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088,
              January 2008, <http://www.rfc-editor.org/info/rfc5088>.

   [RFC5089]  Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
              Zhang, "IS-IS Protocol Extensions for Path Computation
              Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089,
              January 2008, <http://www.rfc-editor.org/info/rfc5089>.

   [RFC7752]  Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
              S. Ray, "North-Bound Distribution of Link-State and
              Traffic Engineering (TE) Information Using BGP", RFC 7752,
              DOI 10.17487/RFC7752, March 2016,
              <http://www.rfc-editor.org/info/rfc7752>.

8.2.  Informative References

   [I-D.ietf-idr-te-lsp-distribution]
              Dong, J., Chen, M., Gredler, H., Previdi, S., and J.
              Tantsura, "Distribution of MPLS Traffic Engineering (TE)
              LSP State using BGP", draft-ietf-idr-te-lsp-
              distribution-04 (work in progress), December 2015.

   [I-D.ietf-idr-te-pm-bgp]
              Previdi, S., Wu, Q., Gredler, H., Ray, S.,
              Tantsura,
              jefftant@gmail.com, j., Filsfils, C., and L. Ginsberg,
              "BGP-LS Advertisement of IGP Traffic Engineering
              Performance Metric Extensions", draft-ietf-idr-te-pm-
              bgp-03 (work in progress), May 2016.

   [RFC4272]  Murphy, S., "BGP Security Vulnerabilities Analysis",
              RFC 4272, DOI 10.17487/RFC4272, January 2006,
              <http://www.rfc-editor.org/info/rfc4272>.

   [RFC4674]  Le Roux, J., Ed., "Requirements for Path Computation
              Element (PCE) Discovery", RFC 4674, DOI 10.17487/RFC4674,
              October 2006, <http://www.rfc-editor.org/info/rfc4674>.

   [RFC5441]  Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
              "A Backward-Recursive PCE-Based Computation (BRPC)
              Procedure to Compute Shortest Constrained Inter-Domain
              Traffic Engineering Label Switched Paths", RFC 5441,
              DOI 10.17487/RFC5441, April 2009,
              <http://www.rfc-editor.org/info/rfc5441>.

   [RFC5824]  Kumaki, K., Ed., Zhang, R., and Y. Kamite, "Requirements
              for Supporting Customer Resource ReSerVation Protocol
              (RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/
              MPLS IP-VPN", RFC 5824, DOI 10.17487/RFC5824, April 2010,
              <http://www.rfc-editor.org/info/rfc5824>.

   [RFC6805]  King, D., Ed. and A. Farrel, Ed., "The Application of the
              Path Computation Element Architecture to the Determination
              of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
              DOI 10.17487/RFC6805, November 2012,
              <http://www.rfc-editor.org/info/rfc6805>.

   [RFC6952]  Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
              BGP, LDP, PCEP, and MSDP Issues According to the Keying
              and Authentication for Routing Protocols (KARP) Design
              Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
              <http://www.rfc-editor.org/info/rfc6952>.

Authors' Addresses

   Jie Dong
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing  100095
   China

   Email: jie.dong@huawei.com

   Mach(Guoyi) Chen
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing  100095
   China

   Email: mach.chen@huawei.com
   Dhruv Dhody
   Huawei Technologies
   Divyashree Techno Park, Whitefield
   Bangalore, Karnataka  560066
   India

   Email: dhruv.ietf@gmail.com

   Jeff Tantsura
   Individual
   US

   Email: jefftant.ietf@gmail.com

   Kenji Kumaki
   KDDI Corporation
   Garden Air Tower, Iidabashi, Chiyoda-ku
   Tokyo  102-8460
   Japan

   Email: ke-kumaki@kddi.com

   Tomoki Murai
   Furukawa Network Solution Corp.
   5-1-9, Higashi-Yawata, Hiratsuka
   Kanagawa  254-0016
   Japan

   Email: murai@fnsc.co.jp