Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Jie Dong , Mach Chen , Dhruv Dhody , Jeff Tantsura
Last updated 2014-10-26
RFC stream (None)
Formats
Additional resources
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-dong-pce-discovery-proto-bgp-01
Network Working Group                                            J. Dong
Internet-Draft                                                   M. Chen
Intended status: Standards Track                                D. Dhody
Expires: April 28, 2015                              Huawei Technologies
                                                             J. Tantsura
                                                                Ericsson
                                                        October 25, 2014

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

Abstract

   In network scenarios where Path Computation Element (PCE) is used for
   centralized path computation, it is desirable for Path Computation
   Clients (PCCs) to automatically discover a set of PCEs.  As BGP can
   be used for north-bound distribution of routing and Label Switched
   Path (LSP) information to PCE, the PCEs may not participate in
   Interior Gateway Protocol (IGP) for collecting the routing
   information, thus the IGP based PCE discovery cannot be used directly
   in these scenarios.  This document specifies the BGP extensions for
   PCE discovery.

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 April 28, 2015.

Dong, et al.             Expires April 28, 2015                 [Page 1]
Internet-Draft      BGP Extensions for PCE Discovery        October 2014

Copyright Notice

   Copyright (c) 2014 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
     2.1.  PCE Address Information . . . . . . . . . . . . . . . . .   4
     2.2.  PCE Discovery TLVs  . . . . . . . . . . . . . . . . . . .   5
   3.  Operational Considerations  . . . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   In network scenarios where Path Computation Element (PCE) is used for
   centralized path computation, it is desirable for Path Computation
   Clients (PCCs) to automatically discover a set of PCEs.  [RFC5088]
   and [RFC5089] define PCE discovery mechanism based on Interior
   Gateway Protocol (IGP).  The IGP based mechanisms may not work well
   in scenarios where the PCEs do not participate in the IGP, and it is
   difficult for PCE to participate in IGP of multiple domains where PCE
   discovery is needed.

   For example, Backward Recursive Path Computation (BRPC) [RFC5441] may
   be used by cooperating PCEs to compute inter-domain path, in which
   case these cooperating PCEs should be known to other PCEs.  In case
   of inter-AS network where the PCEs do not participate in a common
   IGP, the existing IGP discovery mechanism cannot be used to discover
   the PCEs in other domains.  Also in the Hierarchical PCE scenario,
   the child PCEs need to know the address of the parent PCE.  This

Dong, et al.             Expires April 28, 2015                 [Page 2]
Internet-Draft      BGP Extensions for PCE Discovery        October 2014

   cannot be achieved through IGP based discovery, as normally the child
   PCEs and the parent PCE are under different administration and reside
   in different domains.

   As BGP could be used for north-bound distribution of routing and
   Label Switched Path (LSP) information to PCE as described in
   [I-D.ietf-idr-ls-distribution] [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 this scenario, some other PCE
   disovery mechanism is also needed.

   A detailed set of requirements for a PCE discovery mechanism are
   provided in [RFC4674].

   This document proposes to extend BGP for PCE discovery for the above
   scenarios.  In networks where BGP-LS is already used for the north-
   bound routing information distribution to PCE, BGP based PCE
   discovery can reuse the existing BGP sessions and mechanisms to
   achieve PCE discovery.  It should be noted that, in IGP domain, the
   IGP based PCE discovery mechanism may be used in conjunction with the
   BGP based PCE discovery.  Thus the BGP based PCE discovery is
   complementary to the existing IGP based mechanisms.

Dong, et al.             Expires April 28, 2015                 [Page 3]
Internet-Draft      BGP Extensions for PCE Discovery        October 2014

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

                      Figure 1: BGP for PCE discovery

   As shown in the network architecture in Figure 1, BGP is used for
   both routing information distribution and PCE information discovery.
   The routing information is collected from the network elements and
   distributed to PCE, while the PCE discovery information is advertised
   from PCE to PCCs, or between different PCEs.  The PCCs maybe co-
   located with the BGP speakers as shown in Figure 1.  The IGP based
   PCE discovery mechanism may be used for the distribution of PCE
   discovery information in IGP domain.

2.  Carrying PCE Discovery Information in BGP

2.1.  PCE Address Information

   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 defined in [I-D.ietf-idr-ls-distribution] are re-
   used, and a new NLRI Type is defined for PCE discovery information as
   below:

Dong, et al.             Expires April 28, 2015                 [Page 4]
Internet-Draft      BGP Extensions for PCE Discovery        October 2014

   o  Type = TBD: 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)                 ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       Figure 2. PCE Discovery NLRI

   The 'Protocol-ID' field do not apply to the PCE Discovery NLRI and
   SHOULD be set to 0 on transmission and be ignored upon receipt.

   The 'Identifier' field is used to identify the "routing universe"
   where the PCE belongs, and the identifier values as below defined in
   [I-D.ietf-idr-ls-distribution] apply.

                     +------------+---------------------+
                     | Identifier | Routing Universe    |
                     +------------+---------------------+
                     |     0      | L3 packet topology  |
                     |     1      | L1 optical topology |
                     +------------+---------------------+

2.2.  PCE Discovery TLVs

   The detailed PCE discovery information is carried in BGP-LS attribute
   [I-D.ietf-idr-ls-distribution] with a new "PCE Discovery TLV", which
   contains a set of sub-TLVs for specific PCE discovery information.
   The PCE Discovery TLV and sub-TLVs SHOULD only be used with the PCE
   Discovery NLRI.

   The format of the PCE Discovery TLV is shown as below:

Dong, et al.             Expires April 28, 2015                 [Page 5]
Internet-Draft      BGP Extensions for PCE Discovery        October 2014

      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            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                 PCE Discovery Sub-TLVs (variable)             ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       Figure 3. PCE Discovery TLV

   The PCE Discovery Sub-TLVs are listed as below.  The format of the
   PCE Discovery sub-TLVs are consistent with the IGP PCED sub-TLVs
   defined in [RFC5088] and [RFC5089].  The PATH-SCOPE TLV MUST always
   be carried in the BGP-LS Attribute if the NLRI is PCE Discovery NLRI.
   Other PCE Discovery TLVs are optional and may facilitate the PCE
   selection process.

     Type    Length           Name
     TBD         3         PATH-SCOPE sub-TLV
     TBD     variable     PCE-CAP-FLAGS sub-TLV
     TBD     variable     OSPF-PCE-DOMAIN sub-TLV
     TBD     variable     IS-IS-PCE-DOMAIN sub-TLV
     TBD     variable     OSPF-NEIG-PCE-DOMAIN sub-TLV
     TBD     variable     IS-IS-NEIG-PCE-DOMAIN sub-TLV

   More PCE Discovery sub-TLVs may be defined in future and the format
   SHOULD be in line with the new sub-TLVs defined for IGP based PCE
   discovery.

3.  Operational Considerations

   Existing BGP operational procedures apply to the advertisement of PCE
   discovery information.  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 the
   PCE selection on the PCCs would be peformed based on the information
   carried in the PCE Discovery TLV.

   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.

Dong, et al.             Expires April 28, 2015                 [Page 6]
Internet-Draft      BGP Extensions for PCE Discovery        October 2014

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'
   from the "node anchor, link descriptor and link attribute TLVs"
   registry.

   IANA needs to create a new registry for "PCE Discovery Sub-TLVs".
   The registry will be initialized as shown in section 2.2 of this
   document.

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.

6.  Acknowledgements

   The authors would like to thank Zhenbin Li and Hannes Gredler for
   their discussion and comments.

7.  References

7.1.  Normative References

   [I-D.ietf-idr-ls-distribution]
              Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
              Ray, "North-Bound Distribution of Link-State and TE
              Information using BGP", draft-ietf-idr-ls-distribution-06
              (work in progress), September 2014.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760, January
              2007.

   [RFC5088]  Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
              "OSPF Protocol Extensions for Path Computation Element
              (PCE) Discovery", RFC 5088, January 2008.

Dong, et al.             Expires April 28, 2015                 [Page 7]
Internet-Draft      BGP Extensions for PCE Discovery        October 2014

   [RFC5089]  Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
              "IS-IS Protocol Extensions for Path Computation Element
              (PCE) Discovery", RFC 5089, January 2008.

7.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-01 (work in progress), July 2014.

   [I-D.ietf-idr-te-pm-bgp]
              Wu, Q., Previdi, S., Gredler, H., Ray, S., and J.
              Tantsura, "BGP attribute for North-Bound Distribution of
              Traffic Engineering (TE) performance Metrics", draft-ietf-
              idr-te-pm-bgp-01 (work in progress), July 2014.

   [RFC4272]  Murphy, S., "BGP Security Vulnerabilities Analysis", RFC
              4272, January 2006.

   [RFC4674]  Le Roux, J., "Requirements for Path Computation Element
              (PCE) Discovery", RFC 4674, October 2006.

   [RFC5441]  Vasseur, JP., 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, April 2009.

   [RFC6805]  King, D. and A. Farrel, "The Application of the Path
              Computation Element Architecture to the Determination of a
              Sequence of Domains in MPLS and GMPLS", RFC 6805, November
              2012.

   [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, May 2013.

Authors' Addresses

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

   Email: jie.dong@huawei.com

Dong, et al.             Expires April 28, 2015                 [Page 8]
Internet-Draft      BGP Extensions for PCE Discovery        October 2014

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

   Email: mach.chen@huawei.com

   Dhruv Dhody
   Huawei Technologies
   Leela Palace
   Bangalore, Karnataka  560008
   India

   Email: dhruv.ietf@gmail.com

   Jeff Tantsura
   Ericsson
   300 Holger Way
   San Jose, CA  95134
   US

   Email: jeff.tantsura@ericsson.com

Dong, et al.             Expires April 28, 2015                 [Page 9]