idnits 2.17.00 (12 Aug 2021) /tmp/idnits20567/draft-dong-pce-discovery-proto-bgp-06.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 (October 27, 2016) is 2032 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: draft-ietf-idr-te-pm-bgp has been published as RFC 8571 Summary: 0 errors (**), 0 flaws (~~), 2 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: April 30, 2017 Huawei Technologies 6 J. Tantsura 7 Individual 8 K. Kumaki 9 KDDI Corporation 10 T. Murai 11 Furukawa Network Solution Corp. 12 October 27, 2016 14 BGP Extensions for Path Computation Element (PCE) Discovery 15 draft-dong-pce-discovery-proto-bgp-06 17 Abstract 19 In networks where a Path Computation Element (PCE) is used for path 20 computation, it is desirable for the Path Computation Clients (PCCs) 21 to discover dynamically and automatically a set of PCEs along with 22 certain information relevant for PCE selection. RFC 5088 and RFC 23 5089 define the PCE discovery mechanisms based on Interior Gateway 24 Protocols (IGP). This document defines extensions to BGP for the 25 advertisement of PCE Discovery information. The BGP based PCE 26 discovery mechanism is complementary to the existing IGP based 27 mechanisms. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on April 30, 2017. 51 Copyright Notice 53 Copyright (c) 2016 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Carrying PCE Discovery Information in BGP . . . . . . . . . . 3 70 2.1. PCE NLRI . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2.1.1. PCE Descriptors . . . . . . . . . . . . . . . . . . . 4 72 2.2. PCE Attribute TLVs . . . . . . . . . . . . . . . . . . . 5 73 2.2.1. PCE Domain TLV . . . . . . . . . . . . . . . . . . . 6 74 2.2.2. Neighbor PCE Domain TLV . . . . . . . . . . . . . . . 6 75 3. Operational Considerations . . . . . . . . . . . . . . . . . 7 76 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 78 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 82 8.2. Informative References . . . . . . . . . . . . . . . . . 9 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 85 1. Introduction 87 In networks where a Path Computation Element (PCE) is used for path 88 computation, it is desirable for the Path Computation Clients (PCCs) 89 to discover dynamically and automatically a set of PCEs along with 90 certain information relevant for PCE selection. [RFC5088] and 91 [RFC5089] define the PCE discovery mechanisms based on Interior 92 Gateway Protocols (IGP). When PCCs are LSRs participating in the IGP 93 (OSPF or IS-IS), and PCEs are either LSRs or servers also 94 participating in the IGP, an effective mechanism for PCE discovery 95 within an IGP routing domain consists of utilizing IGP 96 advertisements. 98 [RFC4674] presents a set of requirements for a PCE discovery 99 mechanism. This includes the discovery by a PCC of a set of one or 100 more PCEs which may potentially be in some other domains. This is a 101 desirable function in the case of inter-domain path computation. For 102 example, Backward Recursive Path Computation (BRPC) [RFC5441] can be 103 used by cooperating PCEs to compute an inter-AS path, in which case 104 the discovery of PCE as well as the domain information is useful. 106 BGP has been extended for north-bound distribution of routing and TE 107 information to PCE [RFC7752] and [I-D.ietf-idr-te-pm-bgp]. Similary 108 this document extends BGP to also carry the PCE discovery 109 information. 111 This document defines extensions to BGP to allow a PCE to advertise 112 its location, along with some information useful to a PCC for the PCE 113 selection, so as to satisfy dynamic PCE discovery requirements set 114 forth in [RFC4674]. 116 This specification contains two parts: definition of a new BGP-LS 117 NLRI [RFC7752] that describes PCE information and definition of PCE 118 Attribute TLVs as part of BGP-LS attributes. 120 2. Carrying PCE Discovery Information in BGP 122 2.1. PCE NLRI 124 The PCE discovery information is advertised in BGP UPDATE messages 125 using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. 126 The "Link- State NLRI" defined in [RFC7752] is extended to carry the 127 PCE information. BGP speakers that wish to exchange PCE discovery 128 information MUST use the BGP Multiprotocol Extensions Capability Code 129 (1) to advertise the corresponding (AFI, SAFI) pair, as specified in 130 [RFC4760]. 132 The format of "Link-State NLRI" is defined in [RFC7752]. A new "NLRI 133 Type" is defined for PCE Information as following: 135 o Type = TBD1: PCE NLRI 137 The format of PCE NLRI is shown in the following figure: 139 0 1 2 3 140 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 141 +-+-+-+-+-+-+-+-+ 142 | Protocol-ID | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Identifier | 145 | (64 bits) | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | | 148 ~ PCE Descriptors (variable) ~ 149 | | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 Figure 1. PCE NLRI 153 The 'Protocol-ID' field is defined in [RFC7752], to be set to the 154 appropriate value that indicates the source of the PCE information. 155 If BGP speaker and PCE are co-located, the Protocol-ID SHOULD be set 156 to "Direct". If PCE information to advertise is configured at the 157 BGP speaker, the Protocol-ID SHOULD be set to "Static configuration". 159 As defined in [RFC7752], the 64-Bit 'Identifier' field is used to 160 identify the "routing universe" where the PCE belongs. 162 2.1.1. PCE Descriptors 164 The PCE Descriptor field is a set of Type/Length/Value (TLV) 165 triplets. The format of each TLV is as per Section 3.1 of [RFC7752]. 166 The PCE Descriptor TLVs uniquely identify a PCE. The following PCE 167 descriptor are defined - 169 +-----------+-----------------------+----------+ 170 | Codepoint | Descriptor TLV | Length | 171 +-----------+-----------------------+----------+ 172 | TBD2 | IPv4 PCE Address | 4 | 173 | TBD3 | IPv6 PCE Address | 16 | 174 +-----------+-----------------------+----------+ 175 Table 1: PCE Descriptors 177 The PCE address TLVs specifies an IP address that can be used to 178 reach the PCE. The PCE-ADDRESS Sub-TLV defined in [RFC5088] and 179 [RFC5089] is used in the OSPF and IS-IS respectively. The format of 180 the PCE address TLV are - 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Type=TBD2 | Length=4 | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | IPv4 PCE Address | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 | Type=TBD3 | Length=16 | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | | 195 | IPv6 PCE Address | 196 | | 197 | | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 2. PCE Address TLVs 201 When the PCE has both an IPv4 and IPv6 address, both the TLVs MAY be 202 included. 204 2.2. PCE Attribute TLVs 206 PCE Attribute TLVs are TLVs that may be encoded in the BGP-LS 207 attribute [RFC7752] with a PCE NLRI. The format of each TLV is as 208 per Section 3.1 of [RFC7752]. The format and semantics of the Value 209 fields in some PCE Attribute TLVs correspond to the format and 210 semantics of the Value fields in IS-IS PCED Sub-TLV, defined in 211 [RFC5089]. Other PCE Attribute TLVs are defined in this document. 213 The following PCE Attribute TLVs are valid in the BGP-LS attribute 214 with a PCE NLRI: 216 +-----------+---------------------+--------------+------------------+ 217 | TLV Code | Description | IS-IS TLV | Reference | 218 | Point | | /Sub-TLV | (RFC/Section) | 219 +-----------+---------------------+--------------+------------------+ 220 | TBD4 | Path Scope | 5/2 | [RFC5089]/4.2 | 221 | TBD5 | PCE Domain | - | - | 222 | TBD6 | Neighbor PCE | - | - | 223 | | Domain | | | 224 | TBD7 | PCE Capability | 5/5 | [RFC5089]/4.5 | 225 +-----------+---------------------+--------------+------------------+ 226 Table 2: PCE Attribute TLVs 228 The format and semantics of Path Scope and PCE capability is as per 229 [RFC5089]. The Path Scope TLV is mandatory. 231 2.2.1. PCE Domain TLV 233 The PCE Domain TLV specifies a PCE-Domain (IGP area and/or AS) where 234 the PCE has topology visibility and through which the PCE can compute 235 paths. 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Type=TBD5 | Length | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | | 243 // Domain Sub-TLVs (variable) // 244 | | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 The length of this TLV is variable. The value contains one or more 248 domain sub-TLVs as listed below - 250 +--------------------+-------------------+----------+ 251 | Sub-TLV Code Point | Description | Length | 252 +--------------------+-------------------+----------+ 253 | 512 | Autonomous System | 4 | 254 | 514 | OSPF Area-ID | 4 | 255 | 1027 | IS-IS Area | Variable | 256 | | Identifier | | 257 +--------------------+-------------------+----------+ 259 Multiple sub-TLVs MAY be included, when the PCE has visibility into 260 multiple PCE-Domains. 262 2.2.2. Neighbor PCE Domain TLV 264 The Neighbor PCE Domain TLV specifies a neighbor PCE-Domain (IGP area 265 and/or AS) toward which a PCE can compute paths. 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Type=TBD6 | Length | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | | 273 // Domain Sub-TLVs (variable) // 274 | | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 The length of this TLV is variable. The value contains one or more 277 domain sub-TLVs as listed above. Multiple sub-TLVs MAY be included, 278 when the PCE can compute paths towards several neighbor PCE-Domains. 280 3. Operational Considerations 282 Existing BGP-LS operational procedures apply to the advertisement of 283 PCE information as per [RFC7752]. This information is treated as 284 pure application level data which has no immediate impact on 285 forwarding states. The PCE information SHOULD be advertised only to 286 the domains where such information is allowed to be used. This can 287 be achieved by policy control on the ASBRs. 289 The PCE information is considered relatively stable and does not 290 change frequently, thus this information will not bring significant 291 impact on the amount of BGP updates in the network. 293 4. IANA Considerations 295 IANA needs to assign a new NLRI Type for 'PCE NLRI' from the "BGP-LS 296 NLRI-Types" registry. 298 IANA needs to assign new TLV code point as per Table 1 and 2 from the 299 "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and 300 Attribute TLVs" registry. 302 [Editor's Note - Check if name of the registry should be changes with 303 following instructions - Further IANA is requested to rename the 304 registry as "BGP-LS Node Descriptor, Link Descriptor, Prefix 305 Descriptor, PCE Descriptor, and Attribute TLVs".] 307 5. Security Considerations 309 Procedures and protocol extensions defined in this document do not 310 affect the BGP security model. See the 'Security Considerations' 311 section of [RFC4271] for a discussion of BGP security. Also refer to 312 [RFC4272] and [RFC6952] for analysis of security issues for BGP. 314 Existing BGP-LS security considerations as per [RFC7752] continue to 315 apply. 317 6. Contributors 319 The following individuals gave significant contributions to this 320 document: 322 Takuya Miyasaka 323 KDDI Corporation 324 ta-miyasaka@kddi.com 326 7. Acknowledgements 328 The authors would like to thank Zhenbin Li, Hannes Gredler, Jan 329 Medved, Adrian Farrel, Julien Meuric and Jonathan Hardwick for the 330 valuable discussion and comments. 332 8. References 334 8.1. Normative References 336 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 337 Requirement Levels", BCP 14, RFC 2119, 338 DOI 10.17487/RFC2119, March 1997, 339 . 341 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 342 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 343 DOI 10.17487/RFC4271, January 2006, 344 . 346 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 347 "Multiprotocol Extensions for BGP-4", RFC 4760, 348 DOI 10.17487/RFC4760, January 2007, 349 . 351 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 352 Zhang, "OSPF Protocol Extensions for Path Computation 353 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 354 January 2008, . 356 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 357 Zhang, "IS-IS Protocol Extensions for Path Computation 358 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 359 January 2008, . 361 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 362 S. Ray, "North-Bound Distribution of Link-State and 363 Traffic Engineering (TE) Information Using BGP", RFC 7752, 364 DOI 10.17487/RFC7752, March 2016, 365 . 367 8.2. Informative References 369 [I-D.ietf-idr-te-pm-bgp] 370 Previdi, S., Wu, Q., Gredler, H., Ray, S., 371 jefftant@gmail.com, j., Filsfils, C., and L. Ginsberg, 372 "BGP-LS Advertisement of IGP Traffic Engineering 373 Performance Metric Extensions", draft-ietf-idr-te-pm- 374 bgp-03 (work in progress), May 2016. 376 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 377 RFC 4272, DOI 10.17487/RFC4272, January 2006, 378 . 380 [RFC4674] Le Roux, J., Ed., "Requirements for Path Computation 381 Element (PCE) Discovery", RFC 4674, DOI 10.17487/RFC4674, 382 October 2006, . 384 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 385 "A Backward-Recursive PCE-Based Computation (BRPC) 386 Procedure to Compute Shortest Constrained Inter-Domain 387 Traffic Engineering Label Switched Paths", RFC 5441, 388 DOI 10.17487/RFC5441, April 2009, 389 . 391 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 392 BGP, LDP, PCEP, and MSDP Issues According to the Keying 393 and Authentication for Routing Protocols (KARP) Design 394 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 395 . 397 Authors' Addresses 399 Jie Dong 400 Huawei Technologies 401 Huawei Campus, No. 156 Beiqing Rd. 402 Beijing 100095 403 China 405 Email: jie.dong@huawei.com 407 Mach(Guoyi) Chen 408 Huawei Technologies 409 Huawei Campus, No. 156 Beiqing Rd. 410 Beijing 100095 411 China 413 Email: mach.chen@huawei.com 414 Dhruv Dhody 415 Huawei Technologies 416 Divyashree Techno Park, Whitefield 417 Bangalore, Karnataka 560066 418 India 420 Email: dhruv.ietf@gmail.com 422 Jeff Tantsura 423 Individual 424 US 426 Email: jefftant.ietf@gmail.com 428 Kenji Kumaki 429 KDDI Corporation 430 Garden Air Tower, Iidabashi, Chiyoda-ku 431 Tokyo 102-8460 432 Japan 434 Email: ke-kumaki@kddi.com 436 Tomoki Murai 437 Furukawa Network Solution Corp. 438 5-1-9, Higashi-Yawata, Hiratsuka 439 Kanagawa 254-0016 440 Japan 442 Email: murai@fnsc.co.jp