Network Working Group J. Dong Internet-Draft M. Chen Intended status: Standards TrackHuawei TechnologiesD. Dhody Expires:January 1,April 28, 2015June 30,Huawei Technologies J. Tantsura Ericsson October 25, 2014 BGP Extensions for Path Computation Element (PCE) Discoverydraft-dong-pce-discovery-proto-bgp-00draft-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 discoverthea set of PCEs. As BGPhas been extendedcan be used for north-bound distribution of routing andLSP pathLabel 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 onJanuary 1,April 28, 2015. 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 . . . . . . . . . .34 2.1. PCE Address Information . . . . . . . . . . . . . . . . .34 2.2. PCE DiscoveryAttributeTLVs . . . . . . . . . . . . . . . . .4. . 5 3. Operational Considerations . . . . . . . . . . . . . . . . .56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . .57 5. Security Considerations . . . . . . . . . . . . . . . . . . .57 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .57 7. References . . . . . . . . . . . . . . . . . . . . . . . . .57 7.1. Normative References . . . . . . . . . . . . . . . . . .57 7.2. Informative References . . . . . . . . . . . . . . . . .68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .68 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 discoverthea 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 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 BGPwillcould be used for north-bound distribution of routing and Label Switched Path (LSP) information toPCE[I-D.ietf-idr-ls-distribution]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],thePCEsmay not participate in Interior Gateway Protocol (IGP) for collectingcan obtain the routinginformation, thus the IGP basedinformation without participating in IGP. In this scenario, some other PCE disovery mechanism is also needed. A detailed set of requirements for a PCE discoverymechanisms definedmechanism are provided in[RFC5088] [RFC5089] cannot be used directly.[RFC4674]. This document proposes to extend BGP for PCE discoveryin suchfor the above scenarios.WhileIn 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, ineachIGP domain, the IGP based PCE discovery mechanism may be used in conjunction with the BGP based PCE discovery. Thus the BGP based PCE discovery iscomplementalcomplementary to the existing IGP based mechanisms.+---------++-----------+ | PCE |+---------+ ^ |+-----------+ | v +-----------+ || V +---------+ +--------->|BGP|<---------+ | +----| Speaker |----+ | | | +---------+ || +-----------+ | Speaker |^| PCE | +-----------+ +-----------+ | | | | | | | |V+---------------+ |V V+-------------------+ |+---------+ +---------+ +---------+v v v v +-----------+ +-----------+ +-----------+ | BGP | | BGP | | BGP | | Speaker | | Speaker | . . . | Speaker |+---------+ +---------+ +---------+ ^ ^ ^ IGP(optional) || & PCC |V V V +---------+ +---------+ +---------+| & PCC | |PCC| +-----------+ +-----------+ +-----------+ | | via | IGP v +-----------+ | PCC |+---------+ +---------+ +---------++-----------+ Figure1.1: BGP forrouting collection andPCE 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 isdistributedcollected from the network elementsupand distributed to PCE, while the PCE discovery information is advertised from PCEdowntoPCCs.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 ineachIGP 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].AThe AFI and SAFI defined in [I-D.ietf-idr-ls-distribution] are re- used, and a new NLRIcalled PCE_ADDR NLRIType is defined forcarrying thePCEaddressdiscovery informationwhich can be used to reach the PCE. The AFI/SAFI value for the PCE_ADDRas below: o Type = TBD: PCE Discovery NLRIis TBD. In order for two BGP speakers to exchange PCE_ADDR NLRI, they MUST use BGP Capabilities Advertisement [RFC4760] to ensure that both are capable of properly processing such NLRI. This is done by using Capability Code 1 (which indicates Multiprotocol Extensions capabilities), with the AFI/SAFI pair for the PCE_ADDR NLRI.The format ofPCE_ADDRPCE Discovery NLRI is shownas below: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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TypeIdentifier |Length| (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ PCE-Address (4 or 16 octets) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2.PCE_ADDRPCE Discovery NLRIFor PCEs identified by IPv4 address, the TypeThe 'Protocol-ID' fieldSHOULD be setdo not apply to1, andtheLength fieldPCE Discovery NLRI and SHOULD be set to4. For PCEs identified by IPv6 address, the Type field SHOULD0 on transmission and besetignored upon receipt. The 'Identifier' field is used to2,identify the "routing universe" where the PCE belongs, and theLength field SHOULD be set to 16.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 DiscoveryAttributeTLVs The detailed PCE discovery information is carried in BGP-LS attribute [I-D.ietf-idr-ls-distribution] with a newoptional non-transitive BGP attribute called PCE_DISC Attribute,"PCE Discovery TLV", whichconsists ofcontains aseriesset ofPCE Discovery TLVssub-TLVs for specific PCE discovery information. ThePCE_DISC attributePCE Discovery TLV and sub-TLVs SHOULD only be used withPCE_ADDRthe PCE Discovery NLRI. The format of the PCE Discovery TLV is shown as below: 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 DiscoveryTLVsSub-TLVs (variable) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. PCE DiscoveryTLVsTLV The PCE Discovery Sub-TLVs are listed as below. TheType code andformat of the PCE DiscoveryTLVssub-TLVs are consistent with the IGP PCEDSub-TLVssub-TLVs defined in [RFC5088] and [RFC5089].Type 1 is reserved, which is used in IGP based PCE discovery mechanisms to carry PCE Address . TLV-Type Length Name 2 3 PATH-SCOPE TLV 3 variable PCE-DOMAIN TLV 4 variable NEIG-PCE-DOMAIN TLV 5 variable PCE-CAP-FLAGS TLVThe PATH-SCOPE TLV MUST always be carried in thePCE_DISC Attribute.BGP-LS Attribute if the NLRI is PCE Discovery NLRI. Other PCE Discovery TLVs are optional and may facilitate the PCEselection.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 DiscoveryTLVssub-TLVs may be defined infuture.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.SuchThis 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. 4. IANA Considerations IANA needs to assign a newAFI and SAFI codes for PCE_ADDRNLRI Type for 'PCE Discovery NLRI' from"Address Family Numbers" and "Subsequent Address Family Identifiers"the "BGP-LS NLRI- Types" registry. IANA needs to assign a newtypeTLV code point for"PCE_DISC" attribute'PCE Discovery TLV' from"BGP Path Attributes"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] fordetails.analysis of security issues for BGP. 6. Acknowledgements The authors would like to thank Zhenbin Li and Hannes Gredler forthetheir 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. [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.[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.7.2. Informative 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-05 (work in progress), May 2014.[I-D.ietf-idr-te-lsp-distribution] Dong, J., Chen, M., Gredler, H.,and S.Previdi, S., and J. Tantsura, "Distribution of MPLS Traffic Engineering (TE) LSP State using BGP",draft-ietf-idr-te-lsp-distribution-00draft-ietf-idr-te-lsp- distribution-01 (work in progress),JanuaryJuly 2014. [I-D.ietf-idr-te-pm-bgp] Wu, Q.,Danhua, W.,Previdi, S., Gredler, H.,and S.Ray, S., and J. Tantsura, "BGP attribute for North-Bound Distribution of Traffic Engineering (TE) performance Metrics",draft-ietf-idr-te- pm-bgp-00draft-ietf- idr-te-pm-bgp-01 (work in progress),JanuaryJuly 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 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