idnits 2.17.1 draft-dong-pce-discovery-proto-bgp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2015) is 3337 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-13) exists of draft-ietf-idr-ls-distribution-10 == Outdated reference: A later version (-19) exists of draft-ietf-idr-te-lsp-distribution-02 == Outdated reference: A later version (-18) exists of draft-ietf-idr-te-pm-bgp-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Dong 3 Internet-Draft M. Chen 4 Intended status: Standards Track D. Dhody 5 Expires: September 6, 2015 Huawei Technologies 6 J. Tantsura 7 Ericsson 8 March 5, 2015 10 BGP Extensions for Path Computation Element (PCE) Discovery 11 draft-dong-pce-discovery-proto-bgp-02 13 Abstract 15 In networks where Path Computation Element (PCE) is used for 16 centralized path computation, it is desirable for Path Computation 17 Clients (PCCs) to automatically discover a set of PCEs and select the 18 suitable ones to establish the PCEP session. RFC 5088 and RFC 5089 19 define the PCE discovery mechanisms based on Interior Gateway 20 Protocols (IGP). This document describes several scenarios in which 21 the IGP based PCE discovery mechanisms cannot be used directly. This 22 document specifies the BGP extensions for PCE discovery in these 23 scenarios. The BGP based PCE discovery mechanism is complementary to 24 the existing IGP based mechanisms. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 6, 2015. 49 Copyright Notice 51 Copyright (c) 2015 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Carrying PCE Discovery Information in BGP . . . . . . . . . . 4 68 2.1. PCE Address Information . . . . . . . . . . . . . . . . . 4 69 2.2. PCE Discovery TLVs . . . . . . . . . . . . . . . . . . . 5 70 3. Operational Considerations . . . . . . . . . . . . . . . . . 6 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 76 7.2. Informative References . . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 In network scenarios where Path Computation Element (PCE) is used for 82 centralized path computation, it is desirable for Path Computation 83 Clients (PCCs) to automatically discover a set of PCEs and select the 84 suitable ones to establish the PCEP session. [RFC5088] and [RFC5089] 85 define PCE discovery mechanism based on Interior Gateway Protocol 86 (IGP). Those IGP based mechanisms may not work in scenarios where 87 the PCEs do not participate in the IGP, and it is difficult for PCEs 88 to participate in IGP of multiple domains where PCE discovery is 89 needed. 91 In some other scenarios, Backward Recursive Path Computation (BRPC) 92 [RFC5441] can be used by cooperating PCEs to compute inter-domain 93 path, in which case these cooperating PCEs should be known to each 94 other. In case of inter-AS network where the PCEs do not participate 95 in a common IGP, the existing IGP discovery mechanism cannot be used 96 to discover the PCEs in other domains. 98 In the Hierarchical PCE scenario [RFC6805], the child PCEs need to 99 know the address of the parent PCEs. This cannot be achieved through 100 IGP based discovery, as normally the child PCEs and the parent PCE 101 are under different administration and reside in different domains. 103 Besides, as BGP could be used for north-bound distribution of routing 104 and Label Switched Path (LSP) information to PCE as described in 105 [I-D.ietf-idr-ls-distribution] [I-D.ietf-idr-te-lsp-distribution] and 106 [I-D.ietf-idr-te-pm-bgp], PCEs can obtain the routing information 107 without participating in IGP. In this scenario, some other PCE 108 discovery mechanism is also needed. 110 A detailed set of requirements for a PCE discovery mechanism are 111 provided in [RFC4674]. 113 This document proposes to extend BGP for PCE discovery for the above 114 scenarios. In networks where BGP-LS is already used for the north- 115 bound routing information distribution to PCE, BGP based PCE 116 discovery can reuse the existing BGP sessions and mechanisms to 117 achieve PCE discovery. It should be noted that, in IGP domain, the 118 IGP based PCE discovery mechanism may be used in conjunction with the 119 BGP based PCE discovery. Thus the BGP based PCE discovery is 120 complementary to the existing IGP based mechanisms. 122 +-----------+ 123 | PCE | 124 +-----------+ 125 | 126 v 127 +-----------+ 128 | BGP | +-----------+ 129 | Speaker | | PCE | 130 +-----------+ +-----------+ 131 | | | | 132 | | | | 133 +---------------+ | +-------------------+ | 134 v v v v 135 +-----------+ +-----------+ +-----------+ 136 | BGP | | BGP | | BGP | 137 | Speaker | | Speaker | . . . | Speaker | 138 | & PCC | | & PCC | | | 139 +-----------+ +-----------+ +-----------+ 140 | 141 | via 142 | IGP 143 v 144 +-----------+ 145 | PCC | 146 +-----------+ 148 Figure 1: BGP for PCE discovery 150 As shown in the network architecture in Figure 1, BGP is used for 151 both routing information distribution and PCE information discovery. 152 The routing information is collected from the network elements and 153 distributed to PCE, while the PCE discovery information is advertised 154 from PCE to PCCs, or between different PCEs. The PCCs maybe co- 155 located with the BGP speakers as shown in Figure 1. The IGP based 156 PCE discovery mechanism may be used for the distribution of PCE 157 discovery information in IGP domain. 159 2. Carrying PCE Discovery Information in BGP 161 2.1. PCE Address Information 163 The PCE discovery information is advertised in BGP UPDATE messages 164 using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. 165 The AFI and SAFI defined in [I-D.ietf-idr-ls-distribution] are re- 166 used, and a new NLRI Type is defined for PCE discovery information as 167 below: 169 o Type = TBD: PCE Discovery NLRI 171 The format of PCE Discovery NLRI is shown in the following figure: 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+ 176 | Protocol-ID | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Identifier | 179 | (64 bits) | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | | 182 ~ PCE-Address (4 or 16 octets) ~ 183 | | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Figure 2. PCE Discovery NLRI 187 The 'Protocol-ID' field do not apply to the PCE Discovery NLRI and 188 SHOULD be set to 0 on transmission and be ignored upon receipt. 190 The 'Identifier' field is used to identify the "routing universe" 191 where the PCE belongs, and the identifier values as below defined in 192 [I-D.ietf-idr-ls-distribution] apply. 194 +------------+---------------------+ 195 | Identifier | Routing Universe | 196 +------------+---------------------+ 197 | 0 | L3 packet topology | 198 | 1 | L1 optical topology | 199 +------------+---------------------+ 201 2.2. PCE Discovery TLVs 203 The detailed PCE discovery information is carried in BGP-LS attribute 204 [I-D.ietf-idr-ls-distribution] with a new "PCE Discovery TLV", which 205 contains a set of sub-TLVs for specific PCE discovery information. 206 The PCE Discovery TLV and sub-TLVs SHOULD only be used with the PCE 207 Discovery NLRI. 209 The format of the PCE Discovery TLV is shown as below: 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Type | Length | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | | 217 ~ PCE Discovery Sub-TLVs (variable) ~ 218 | | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Figure 3. PCE Discovery TLV 222 The PCE Discovery Sub-TLVs are listed as below. The format of the 223 PCE Discovery sub-TLVs are consistent with the IGP PCED sub-TLVs 224 defined in [RFC5088] and [RFC5089]. The PATH-SCOPE TLV MUST always 225 be carried in the BGP-LS Attribute if the NLRI is PCE Discovery NLRI. 226 Other PCE Discovery TLVs are optional and may facilitate the PCE 227 selection process. 229 Type Length Name 230 TBD 3 PATH-SCOPE sub-TLV 231 TBD variable PCE-CAP-FLAGS sub-TLV 232 TBD variable OSPF-PCE-DOMAIN sub-TLV 233 TBD variable IS-IS-PCE-DOMAIN sub-TLV 234 TBD variable OSPF-NEIG-PCE-DOMAIN sub-TLV 235 TBD variable IS-IS-NEIG-PCE-DOMAIN sub-TLV 237 More PCE Discovery sub-TLVs may be defined in future and the format 238 SHOULD be in line with the new sub-TLVs defined for IGP based PCE 239 discovery. 241 3. Operational Considerations 243 Existing BGP operational procedures apply to the advertisement of PCE 244 discovery information. This information is treated as pure 245 application level data which has no immediate impact on forwarding 246 states. Normal BGP path selection can be applied to PCE Discovery 247 NLRI only for the information propagation in the network, while the 248 PCE selection on the PCCs would be performed based on the information 249 carried in the PCE Discovery TLV. 251 PCE discovery information is considered relatively stable and does 252 not change frequently, thus this information will not bring 253 significant impact on the amount of BGP updates in the network. 255 4. IANA Considerations 257 IANA needs to assign a new NLRI Type for 'PCE Discovery NLRI' from 258 the "BGP-LS NLRI- Types" registry. 260 IANA needs to assign a new TLV code point for 'PCE Discovery TLV' 261 from the "node anchor, link descriptor and link attribute TLVs" 262 registry. 264 IANA needs to create a new registry for "PCE Discovery Sub-TLVs". 265 The registry will be initialized as shown in section 2.2 of this 266 document. 268 5. Security Considerations 270 Procedures and protocol extensions defined in this document do not 271 affect the BGP security model. See the 'Security Considerations' 272 section of [RFC4271] for a discussion of BGP security. Also refer to 273 [RFC4272] and [RFC6952] for analysis of security issues for BGP. 275 6. Acknowledgements 277 The authors would like to thank Zhenbin Li and Hannes Gredler for 278 their discussion and comments. 280 7. References 282 7.1. Normative References 284 [I-D.ietf-idr-ls-distribution] 285 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 286 Ray, "North-Bound Distribution of Link-State and TE 287 Information using BGP", draft-ietf-idr-ls-distribution-10 288 (work in progress), January 2015. 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, March 1997. 293 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 294 Protocol 4 (BGP-4)", RFC 4271, January 2006. 296 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 297 "Multiprotocol Extensions for BGP-4", RFC 4760, January 298 2007. 300 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 301 "OSPF Protocol Extensions for Path Computation Element 302 (PCE) Discovery", RFC 5088, January 2008. 304 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 305 "IS-IS Protocol Extensions for Path Computation Element 306 (PCE) Discovery", RFC 5089, January 2008. 308 7.2. Informative References 310 [I-D.ietf-idr-te-lsp-distribution] 311 Dong, J., Chen, M., Gredler, H., Previdi, S., and J. 312 Tantsura, "Distribution of MPLS Traffic Engineering (TE) 313 LSP State using BGP", draft-ietf-idr-te-lsp- 314 distribution-02 (work in progress), January 2015. 316 [I-D.ietf-idr-te-pm-bgp] 317 Wu, Q., Previdi, S., Gredler, H., Ray, S., and J. 318 Tantsura, "BGP attribute for North-Bound Distribution of 319 Traffic Engineering (TE) performance Metrics", draft-ietf- 320 idr-te-pm-bgp-02 (work in progress), January 2015. 322 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 323 4272, January 2006. 325 [RFC4674] Le Roux, J., "Requirements for Path Computation Element 326 (PCE) Discovery", RFC 4674, October 2006. 328 [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A 329 Backward-Recursive PCE-Based Computation (BRPC) Procedure 330 to Compute Shortest Constrained Inter-Domain Traffic 331 Engineering Label Switched Paths", RFC 5441, April 2009. 333 [RFC6805] King, D. and A. Farrel, "The Application of the Path 334 Computation Element Architecture to the Determination of a 335 Sequence of Domains in MPLS and GMPLS", RFC 6805, November 336 2012. 338 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 339 BGP, LDP, PCEP, and MSDP Issues According to the Keying 340 and Authentication for Routing Protocols (KARP) Design 341 Guide", RFC 6952, May 2013. 343 Authors' Addresses 345 Jie Dong 346 Huawei Technologies 347 Huawei Campus, No. 156 Beiqing Rd. 348 Beijing 100095 349 China 351 Email: jie.dong@huawei.com 352 Mach(Guoyi) Chen 353 Huawei Technologies 354 Huawei Campus, No. 156 Beiqing Rd. 355 Beijing 100095 356 China 358 Email: mach.chen@huawei.com 360 Dhruv Dhody 361 Huawei Technologies 362 Leela Palace 363 Bangalore, Karnataka 560008 364 India 366 Email: dhruv.ietf@gmail.com 368 Jeff Tantsura 369 Ericsson 370 300 Holger Way 371 San Jose, CA 95134 372 US 374 Email: jeff.tantsura@ericsson.com