idnits 2.17.00 (12 Aug 2021) /tmp/idnits20569/draft-dong-pce-discovery-proto-bgp-04.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 9, 2016) is 2264 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-ls-distribution has been published as RFC 7752 == 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 (~~), 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 10, 2016 Huawei Technologies 6 J. Tantsura 7 Ericsson 8 March 9, 2016 10 BGP Extensions for Path Computation Element (PCE) Discovery 11 draft-dong-pce-discovery-proto-bgp-04 13 Abstract 15 In networks where Path Computation Element (PCE) is used for 16 centralized path computation, it is desirable for the Path 17 Computation Clients (PCCs) to automatically discover a set of PCEs 18 and select the suitable ones to establish the PCEP session. RFC 5088 19 and RFC 5089 define the PCE discovery mechanisms based on Interior 20 Gateway Protocols (IGP). This document describes several scenarios 21 in which the IGP based PCE discovery mechanisms cannot be used 22 directly. In such scenarios, BGP might be suitable, thus this 23 document specifies the BGP extensions for PCE discovery. The BGP 24 based PCE discovery mechanism is complementary to the existing IGP 25 based mechanisms. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 10, 2016. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Carrying PCE Discovery Information in BGP . . . . . . . . . . 4 69 2.1. PCE Address Information . . . . . . . . . . . . . . . . . 4 70 2.2. PCE Discovery TLVs . . . . . . . . . . . . . . . . . . . 5 71 3. Operational Considerations . . . . . . . . . . . . . . . . . 6 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 77 7.2. Informative References . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Introduction 82 In network scenarios where Path Computation Element (PCE) is used for 83 centralized path computation, it is desirable for the Path 84 Computation Clients (PCCs) to automatically discover a set of PCEs 85 and select the suitable ones to establish the PCEP session. 86 [RFC5088] and [RFC5089] define the PCE discovery mechanisms based on 87 Interior Gateway Protocols (IGP). 89 The IGP based discovery mechanism requires the PCE participate in the 90 IGP network, which usually requires that the PCE is directly adjacent 91 to at least one of the IGP routers in the network. In some scenarios 92 such requirement cannot be satisfied. For example, a PCE may need to 93 provide path computation service to some subsidiary networks of an 94 operator, which typically locate in different geographical region 95 (and not IGP adjacent). Also when PCE function is implemented in a 96 central server running IGP on individual interfaces to each IGP area 97 can be cumbersome. 99 The requirement on PCE discovery, as described in [RFC4674], also 100 include the automatic discovery of the PCEs in other domains, as it 101 is a desirable function in the case of inter-domain path computation. 102 The IGP based discovery mechanisms cannot meet such requirement. 104 For example, Backward Recursive Path Computation (BRPC) [RFC5441] can 105 be used by cooperating PCEs to compute an inter-AS path, in which 106 case these cooperating PCEs should be known to each other in advance. 107 In this case the PCEs belongs to different AS and do not participate 108 in a common IGP, the IGP based discovery mechanisms are not 109 applicable. 111 Another example is the hierarchical PCE scenario [RFC6805], in which 112 the child PCEs need to know the information of the parent PCEs. This 113 cannot be achieved via IGP based discovery, as the child PCEs and the 114 parent PCE are usually in different domains. 116 Since BGP has been extended for north-bound distribution of routing 117 and Label Switched Path (LSP) information to PCE 118 [I-D.ietf-idr-ls-distribution] [I-D.ietf-idr-te-lsp-distribution] and 119 [I-D.ietf-idr-te-pm-bgp], PCEs can obtain the routing information 120 without participating in IGP. In this scenario, a new BGP based PCE 121 discovery mechanism is needed. 123 This document proposes to extend BGP for PCE discovery in the above 124 scenarios. In networks where BGP-LS is used for the north-bound 125 routing information distribution to PCE, the BGP based PCE discovery 126 can make use of the existing BGP sessions and mechanisms to achieve 127 automatic PCE discovery. Further IGP may be used to redistribute 128 remote PCE information, the detailed mechanism is out of the scope of 129 this document. Thus the BGP based PCE discovery is complementary to 130 the existing IGP based mechanisms. 132 +-----------+ 133 | PCE | 134 +-----------+ 135 | 136 v 137 +-----------+ 138 | BGP | +-----------+ 139 | Speaker | | PCE | 140 +-----------+ +-----------+ 141 | | | | 142 | | | | 143 +---------------+ | +-------------------+ | 144 v v v v 145 +-----------+ +-----------+ +-----------+ 146 | BGP | | BGP | | BGP | 147 | Speaker | | Speaker | . . . | Speaker | 148 | & PCC | | & PCC | | & PCC | 149 +-----------+ +-----------+ +-----------+ 151 Figure 1: BGP for PCE discovery 153 As shown in the network architecture in Figure 1, BGP is used both 154 for routing information distribution and for PCE information 155 discovery. The routing information is collected from the network 156 elements and distributed to PCE, while the PCE discovery information 157 is advertised from PCE to PCCs, or among different PCEs. The PCCs 158 maybe co-located with the BGP speakers as shown in Figure 1. 160 2. Carrying PCE Discovery Information in BGP 162 2.1. PCE Address Information 164 The PCE discovery information is advertised in BGP UPDATE messages 165 using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. 166 The AFI and SAFI defined in [I-D.ietf-idr-ls-distribution] are re- 167 used, and a new NLRI Type is defined for PCE discovery information as 168 below: 170 o Type = TBD: PCE Discovery NLRI 172 The format of PCE Discovery NLRI is shown in the following figure: 174 0 1 2 3 175 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 176 +-+-+-+-+-+-+-+-+ 177 | Protocol-ID | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Identifier | 180 | (64 bits) | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | | 183 ~ PCE-Address (4 or 16 octets) ~ 184 | | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 Figure 2. PCE Discovery NLRI 188 The 'Protocol-ID' field SHOULD be set to the appropriate value which 189 indicates the source of the PCE discovery information. If BGP 190 speaker and PCE are co-located, the Protocol-ID SHOULD be set to 191 "Direct". In other cases, it is RECOMMENDED that the Protocol-ID 192 value be set to "Static configuration". 194 As defined in [I-D.ietf-idr-ls-distribution], the 64-Bit 'Identifier' 195 field is used to identify the "routing universe" where the PCE 196 belongs. 198 2.2. PCE Discovery TLVs 200 The detailed PCE discovery information is carried in the BGP-LS 201 attribute [I-D.ietf-idr-ls-distribution] with a new "PCE Discovery 202 TLV", which contains a set of sub-TLVs for specific PCE discovery 203 information. The PCE Discovery TLV and sub-TLVs SHOULD only be used 204 with the PCE Discovery NLRI. 206 The format of the PCE Discovery TLV is shown as below: 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Type | Length | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | | 214 ~ PCE Discovery Sub-TLVs (variable) ~ 215 | | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Figure 3. PCE Discovery TLV 219 The PCE Discovery sub-TLVs are listed as below. The format of the 220 PCE Discovery sub-TLVs are consistent with the IGP PCED sub-TLVs as 221 defined in [RFC5088] and [RFC5089]. The PATH-SCOPE sub-TLV MUST 222 always be carried in the PCE Discovery TLV. Other PCE Discovery sub- 223 TLVs are optional and may facilitate the PCE selection process on the 224 PCCs. 226 Type | Length | Name 227 ------+------------+-------------------------------- 228 1 | 3 | PATH-SCOPE sub-TLV 229 2 | variable | PCE-CAP-FLAGS sub-TLV 230 3 | variable | OSPF-PCE-DOMAIN sub-TLV 231 4 | variable | IS-IS-PCE-DOMAIN sub-TLV 232 5 | variable | OSPF-NEIG-PCE-DOMAIN sub-TLV 233 6 | variable | IS-IS-NEIG-PCE-DOMAIN sub-TLV 235 More PCE Discovery sub-TLVs may be defined in future. The format and 236 semantic of new PCE Discovery sub-TLVs SHOULD be consistent in BGP 237 and IGP based PCE discovery. 239 3. Operational Considerations 241 Existing BGP operational procedures apply to the advertisement of PCE 242 discovery information. This information is treated as pure 243 application level data which has no immediate impact on forwarding 244 states. Normal BGP path selection can be applied to PCE Discovery 245 NLRI only for the information propagation in the network, while on 246 PCCs the PCE selection is based on the information carried in the PCE 247 Discovery TLV. The PCE discovery information SHOULD be advertised 248 only to the domains where such information is allowed to be used. 249 This can be achieved by policy control on the ASBRs. 251 The PCE discovery information is considered relatively stable and 252 does 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, Hannes Gredler, Jan 278 Medved, Adrian Farrel and Julien Meuric for the valuable discussion 279 and comments. 281 7. References 283 7.1. Normative References 285 [I-D.ietf-idr-ls-distribution] 286 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 287 Ray, "North-Bound Distribution of Link-State and TE 288 Information using BGP", draft-ietf-idr-ls-distribution-13 289 (work in progress), October 2015. 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, 293 DOI 10.17487/RFC2119, March 1997, 294 . 296 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 297 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 298 DOI 10.17487/RFC4271, January 2006, 299 . 301 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 302 "Multiprotocol Extensions for BGP-4", RFC 4760, 303 DOI 10.17487/RFC4760, January 2007, 304 . 306 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 307 Zhang, "OSPF Protocol Extensions for Path Computation 308 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 309 January 2008, . 311 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 312 Zhang, "IS-IS Protocol Extensions for Path Computation 313 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 314 January 2008, . 316 7.2. Informative References 318 [I-D.ietf-idr-te-lsp-distribution] 319 Dong, J., Chen, M., Gredler, H., Previdi, S., and J. 320 Tantsura, "Distribution of MPLS Traffic Engineering (TE) 321 LSP State using BGP", draft-ietf-idr-te-lsp- 322 distribution-04 (work in progress), December 2015. 324 [I-D.ietf-idr-te-pm-bgp] 325 Wu, Q., Previdi, S., Gredler, H., Ray, S., and J. 326 Tantsura, "BGP attribute for North-Bound Distribution of 327 Traffic Engineering (TE) performance Metrics", draft-ietf- 328 idr-te-pm-bgp-02 (work in progress), January 2015. 330 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 331 RFC 4272, DOI 10.17487/RFC4272, January 2006, 332 . 334 [RFC4674] Le Roux, J., Ed., "Requirements for Path Computation 335 Element (PCE) Discovery", RFC 4674, DOI 10.17487/RFC4674, 336 October 2006, . 338 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 339 "A Backward-Recursive PCE-Based Computation (BRPC) 340 Procedure to Compute Shortest Constrained Inter-Domain 341 Traffic Engineering Label Switched Paths", RFC 5441, 342 DOI 10.17487/RFC5441, April 2009, 343 . 345 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 346 Path Computation Element Architecture to the Determination 347 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 348 DOI 10.17487/RFC6805, November 2012, 349 . 351 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 352 BGP, LDP, PCEP, and MSDP Issues According to the Keying 353 and Authentication for Routing Protocols (KARP) Design 354 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 355 . 357 Authors' Addresses 358 Jie Dong 359 Huawei Technologies 360 Huawei Campus, No. 156 Beiqing Rd. 361 Beijing 100095 362 China 364 Email: jie.dong@huawei.com 366 Mach(Guoyi) Chen 367 Huawei Technologies 368 Huawei Campus, No. 156 Beiqing Rd. 369 Beijing 100095 370 China 372 Email: mach.chen@huawei.com 374 Dhruv Dhody 375 Huawei Technologies 376 Divyashree Techno Park, Whitefield 377 Bangalore, Karnataka 560066 378 India 380 Email: dhruv.ietf@gmail.com 382 Jeff Tantsura 383 Ericsson 384 300 Holger Way 385 San Jose, CA 95134 386 US 388 Email: jeff.tantsura@ericsson.com