idnits 2.17.00 (12 Aug 2021) /tmp/idnits19939/draft-dong-pce-discovery-proto-bgp-05.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 (June 24, 2016) is 2157 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 (-17) exists of draft-ietf-idr-te-lsp-distribution-04 == Outdated reference: draft-ietf-idr-te-pm-bgp has been published as RFC 8571 Summary: 0 errors (**), 0 flaws (~~), 3 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: December 26, 2016 Huawei Technologies 6 J. Tantsura 7 Individual 8 K. Kumaki 9 KDDI Corporation 10 T. Murai 11 Furukawa Network Solution Corp. 12 June 24, 2016 14 BGP Extensions for Path Computation Element (PCE) Discovery 15 draft-dong-pce-discovery-proto-bgp-05 17 Abstract 19 In networks where Path Computation Element (PCE) is used for 20 centralized path computation, it is desirable for the Path 21 Computation Clients (PCCs) to automatically discover a set of PCEs 22 and select the suitable ones to establish the PCEP session. RFC 5088 23 and RFC 5089 define the PCE discovery mechanisms based on Interior 24 Gateway Protocols (IGP). This document describes several scenarios 25 in which the IGP based PCE discovery mechanisms cannot be used 26 directly. In such scenarios, BGP might be suitable, thus this 27 document specifies the BGP extensions for PCE discovery. The BGP 28 based PCE discovery mechanism is complementary to the existing IGP 29 based mechanisms. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on December 26, 2016. 54 Copyright Notice 56 Copyright (c) 2016 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Carrying PCE Discovery Information in BGP . . . . . . . . . . 4 73 2.1. PCE Address Information . . . . . . . . . . . . . . . . . 4 74 2.2. PCE Discovery TLVs . . . . . . . . . . . . . . . . . . . 5 75 3. Operational Considerations . . . . . . . . . . . . . . . . . 6 76 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 78 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 82 8.2. Informative References . . . . . . . . . . . . . . . . . 8 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 85 1. Introduction 87 In network scenarios where Path Computation Element (PCE) is used for 88 centralized path computation, it is desirable for the Path 89 Computation Clients (PCCs) to automatically discover a set of PCEs 90 and select the suitable ones to establish the PCEP session. 91 [RFC5088] and [RFC5089] define the PCE discovery mechanisms based on 92 Interior Gateway Protocols (IGP). 94 The IGP based discovery mechanism requires the PCE participate in the 95 IGP network, which usually requires that the PCE is directly adjacent 96 to at least one of the IGP routers in the network. In some scenarios 97 such requirement cannot be satisfied. For example, a PCE may need to 98 provide path computation service to some subsidiary networks of an 99 operator, which typically locate in different geographical region 100 (and not IGP adjacent). Also when PCE function is implemented in a 101 central server running IGP on individual interfaces to each IGP area 102 can be cumbersome. 104 The requirement on PCE discovery, as described in [RFC4674], also 105 include the automatic discovery of the PCEs in other domains, as it 106 is a desirable function in the case of inter-domain path computation. 107 The IGP based discovery mechanisms cannot meet such requirement. 109 For example, Backward Recursive Path Computation (BRPC) [RFC5441] can 110 be used by cooperating PCEs to compute an inter-AS path, in which 111 case these cooperating PCEs should be known to each other in advance. 112 In this case the PCEs belongs to different AS and do not participate 113 in a common IGP, the IGP based discovery mechanisms are not 114 applicable. 116 Another example is the hierarchical PCE scenario [RFC6805], in which 117 the child PCEs need to know the information of the parent PCEs. This 118 cannot be achieved via IGP based discovery, as the child PCEs and the 119 parent PCE are usually in different domains. 121 In some BGP IP-VPN networks, an end-to-end TE LSP between the CEs 122 (Customer Edges) of a particular VPN is required [RFC5824]. In this 123 case, CEs need the information of the PCE which can perform the CE to 124 CE path computation for that VPN. Since the PCE may locate in a VPN 125 site different from the site of the requesting CE, the IGP based 126 discovery mechanism is not directly applicable, and some BGP based 127 discovery mechanism is required to distribute the per-VPN PCE 128 information to the VPN sites. 130 Since BGP has been extended for north-bound distribution of routing 131 and Label Switched Path (LSP) information to PCE [RFC7752] 132 [I-D.ietf-idr-te-lsp-distribution] and [I-D.ietf-idr-te-pm-bgp], PCEs 133 can obtain the routing information without participating in IGP. In 134 this scenario, a new BGP based PCE discovery mechanism is needed. 136 This document proposes to extend BGP for PCE discovery in the above 137 scenarios. In networks where BGP-LS is used for the north-bound 138 routing information distribution to PCE, the BGP based PCE discovery 139 can make use of the existing BGP sessions and mechanisms to achieve 140 automatic PCE discovery. Further IGP may be used to redistribute 141 remote PCE information, the detailed mechanism is out of the scope of 142 this document. Thus the BGP based PCE discovery is complementary to 143 the existing IGP based mechanisms. 145 +-----------+ 146 | PCE | 147 +-----------+ 148 | 149 v 150 +-----------+ 151 | BGP | +-----------+ 152 | Speaker | | PCE | 153 +-----------+ +-----------+ 154 | | | | 155 | | | | 156 +---------------+ | +-------------------+ | 157 v v v v 158 +-----------+ +-----------+ +-----------+ 159 | BGP | | BGP | | BGP | 160 | Speaker | | Speaker | . . . | Speaker | 161 | & PCC | | & PCC | | & PCC | 162 +-----------+ +-----------+ +-----------+ 164 Figure 1: BGP for PCE discovery 166 As shown in the network architecture in Figure 1, BGP is used both 167 for routing information distribution and for PCE information 168 discovery. The routing information is collected from the network 169 elements and distributed to PCE, while the PCE discovery information 170 is advertised from PCE to PCCs, or among different PCEs. The PCCs 171 maybe co-located with the BGP speakers as shown in Figure 1. 173 2. Carrying PCE Discovery Information in BGP 175 2.1. PCE Address Information 177 The PCE discovery information is advertised in BGP UPDATE messages 178 using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. 179 The AFI and SAFI defined in [RFC7752] are re-used. For the PCEs in 180 public network, the AFI / SAFI pair is 16388 / 71, while for the PCEs 181 of a particular VPN, the AFI / SAFI pair is set to 16388 / 72. 183 A new NLRI Type is defined for PCE discovery information as below: 185 o Type = TBD: PCE Discovery NLRI 187 The format of PCE Discovery NLRI is shown in the following figure: 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+ 192 | Protocol-ID | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Identifier | 195 | (64 bits) | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | | 198 ~ PCE-Address (4 or 16 octets) ~ 199 | | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 Figure 2. PCE Discovery NLRI 203 The 'Protocol-ID' field SHOULD be set to the appropriate value which 204 indicates the source of the PCE discovery information. If BGP 205 speaker and PCE are co-located, the Protocol-ID SHOULD be set to 206 "Direct". In other cases, it is RECOMMENDED that the Protocol-ID 207 value be set to "Static configuration". 209 As defined in [RFC7752], the 64-Bit 'Identifier' field is used to 210 identify the "routing universe" where the PCE belongs. 212 2.2. PCE Discovery TLVs 214 The detailed PCE discovery information is carried in the BGP-LS 215 attribute [RFC7752] with a new "PCE Discovery TLV", which contains a 216 set of sub-TLVs for specific PCE discovery information. The PCE 217 Discovery TLV and sub-TLVs SHOULD only be used with the PCE Discovery 218 NLRI. 220 The format of the PCE Discovery TLV is shown as below: 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Type | Length | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | | 228 ~ PCE Discovery Sub-TLVs (variable) ~ 229 | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Figure 3. PCE Discovery TLV 233 The PCE Discovery sub-TLVs are listed as below. The format of the 234 PCE Discovery sub-TLVs are consistent with the IGP PCED sub-TLVs as 235 defined in [RFC5088] and [RFC5089]. The PATH-SCOPE sub-TLV MUST 236 always be carried in the PCE Discovery TLV. Other PCE Discovery sub- 237 TLVs are optional and may facilitate the PCE selection process on the 238 PCCs. 240 Type | Length | Name 241 ------+------------+-------------------------------- 242 1 | 3 | PATH-SCOPE sub-TLV 243 2 | variable | PCE-CAP-FLAGS sub-TLV 244 3 | variable | OSPF-PCE-DOMAIN sub-TLV 245 4 | variable | IS-IS-PCE-DOMAIN sub-TLV 246 5 | variable | OSPF-NEIG-PCE-DOMAIN sub-TLV 247 6 | variable | IS-IS-NEIG-PCE-DOMAIN sub-TLV 249 More PCE Discovery sub-TLVs may be defined in future. The format and 250 semantic of new PCE Discovery sub-TLVs SHOULD be consistent in BGP 251 and IGP based PCE discovery. 253 3. Operational Considerations 255 Existing BGP operational procedures apply to the advertisement of PCE 256 discovery information. This information is treated as pure 257 application level data which has no immediate impact on forwarding 258 states. Normal BGP path selection can be applied to PCE Discovery 259 NLRI only for the information propagation in the network, while on 260 PCCs the PCE selection is based on the information carried in the PCE 261 Discovery TLV. The PCE discovery information SHOULD be advertised 262 only to the domains where such information is allowed to be used. 263 This can be achieved by policy control on the ASBRs. 265 The PCE discovery information is considered relatively stable and 266 does not change frequently, thus this information will not bring 267 significant impact on the amount of BGP updates in the network. 269 4. IANA Considerations 271 IANA needs to assign a new NLRI Type for 'PCE Discovery NLRI' from 272 the "BGP-LS NLRI-Types" registry. 274 IANA needs to assign a new TLV code point for 'PCE Discovery TLV' 275 from the "node anchor, link descriptor and link attribute TLVs" 276 registry. 278 IANA needs to create a new registry for "PCE Discovery Sub-TLVs". 279 The registry will be initialized as shown in section 2.2 of this 280 document. 282 5. Security Considerations 284 Procedures and protocol extensions defined in this document do not 285 affect the BGP security model. See the 'Security Considerations' 286 section of [RFC4271] for a discussion of BGP security. Also refer to 287 [RFC4272] and [RFC6952] for analysis of security issues for BGP. 289 6. Contributors 291 The following individuals gave significant contributions to this 292 document: 294 Takuya Miyasaka 295 KDDI Corporation 296 ta-miyasaka@kddi.com 298 7. Acknowledgements 300 The authors would like to thank Zhenbin Li, Hannes Gredler, Jan 301 Medved, Adrian Farrel, Julien Meuric and Jonathan Hardwick for the 302 valuable discussion and comments. 304 8. References 306 8.1. Normative References 308 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 309 Requirement Levels", BCP 14, RFC 2119, 310 DOI 10.17487/RFC2119, March 1997, 311 . 313 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 314 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 315 DOI 10.17487/RFC4271, January 2006, 316 . 318 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 319 "Multiprotocol Extensions for BGP-4", RFC 4760, 320 DOI 10.17487/RFC4760, January 2007, 321 . 323 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 324 Zhang, "OSPF Protocol Extensions for Path Computation 325 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 326 January 2008, . 328 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 329 Zhang, "IS-IS Protocol Extensions for Path Computation 330 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 331 January 2008, . 333 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 334 S. Ray, "North-Bound Distribution of Link-State and 335 Traffic Engineering (TE) Information Using BGP", RFC 7752, 336 DOI 10.17487/RFC7752, March 2016, 337 . 339 8.2. Informative References 341 [I-D.ietf-idr-te-lsp-distribution] 342 Dong, J., Chen, M., Gredler, H., Previdi, S., and J. 343 Tantsura, "Distribution of MPLS Traffic Engineering (TE) 344 LSP State using BGP", draft-ietf-idr-te-lsp- 345 distribution-04 (work in progress), December 2015. 347 [I-D.ietf-idr-te-pm-bgp] 348 Previdi, S., Wu, Q., Gredler, H., Ray, S., 349 Tantsura, j., Filsfils, C., and L. Ginsberg, 350 "BGP-LS Advertisement of IGP Traffic Engineering 351 Performance Metric Extensions", draft-ietf-idr-te-pm- 352 bgp-03 (work in progress), May 2016. 354 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 355 RFC 4272, DOI 10.17487/RFC4272, January 2006, 356 . 358 [RFC4674] Le Roux, J., Ed., "Requirements for Path Computation 359 Element (PCE) Discovery", RFC 4674, DOI 10.17487/RFC4674, 360 October 2006, . 362 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 363 "A Backward-Recursive PCE-Based Computation (BRPC) 364 Procedure to Compute Shortest Constrained Inter-Domain 365 Traffic Engineering Label Switched Paths", RFC 5441, 366 DOI 10.17487/RFC5441, April 2009, 367 . 369 [RFC5824] Kumaki, K., Ed., Zhang, R., and Y. Kamite, "Requirements 370 for Supporting Customer Resource ReSerVation Protocol 371 (RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/ 372 MPLS IP-VPN", RFC 5824, DOI 10.17487/RFC5824, April 2010, 373 . 375 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 376 Path Computation Element Architecture to the Determination 377 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 378 DOI 10.17487/RFC6805, November 2012, 379 . 381 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 382 BGP, LDP, PCEP, and MSDP Issues According to the Keying 383 and Authentication for Routing Protocols (KARP) Design 384 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 385 . 387 Authors' Addresses 389 Jie Dong 390 Huawei Technologies 391 Huawei Campus, No. 156 Beiqing Rd. 392 Beijing 100095 393 China 395 Email: jie.dong@huawei.com 397 Mach(Guoyi) Chen 398 Huawei Technologies 399 Huawei Campus, No. 156 Beiqing Rd. 400 Beijing 100095 401 China 403 Email: mach.chen@huawei.com 405 Dhruv Dhody 406 Huawei Technologies 407 Divyashree Techno Park, Whitefield 408 Bangalore, Karnataka 560066 409 India 411 Email: dhruv.ietf@gmail.com 413 Jeff Tantsura 414 Individual 415 US 417 Email: jefftant.ietf@gmail.com 418 Kenji Kumaki 419 KDDI Corporation 420 Garden Air Tower, Iidabashi, Chiyoda-ku 421 Tokyo 102-8460 422 Japan 424 Email: ke-kumaki@kddi.com 426 Tomoki Murai 427 Furukawa Network Solution Corp. 428 5-1-9, Higashi-Yawata, Hiratsuka 429 Kanagawa 254-0016 430 Japan 432 Email: murai@fnsc.co.jp