idnits 2.17.00 (12 Aug 2021) /tmp/idnits18691/draft-dong-pce-discovery-proto-bgp-01.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 25, 2014) is 2765 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) == Unused Reference: 'RFC6805' is defined on line 330, but no explicit reference was found in the text == 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-01 == Outdated reference: draft-ietf-idr-te-pm-bgp has been published as RFC 8571 Summary: 0 errors (**), 0 flaws (~~), 5 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 28, 2015 Huawei Technologies 6 J. Tantsura 7 Ericsson 8 October 25, 2014 10 BGP Extensions for Path Computation Element (PCE) Discovery 11 draft-dong-pce-discovery-proto-bgp-01 13 Abstract 15 In network scenarios 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. As BGP can 18 be used for north-bound distribution of routing and Label Switched 19 Path (LSP) information to PCE, the PCEs may not participate in 20 Interior Gateway Protocol (IGP) for collecting the routing 21 information, thus the IGP based PCE discovery cannot be used directly 22 in these scenarios. This document specifies the BGP extensions for 23 PCE discovery. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 28, 2015. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Carrying PCE Discovery Information in BGP . . . . . . . . . . 4 67 2.1. PCE Address Information . . . . . . . . . . . . . . . . . 4 68 2.2. PCE Discovery TLVs . . . . . . . . . . . . . . . . . . . 5 69 3. Operational Considerations . . . . . . . . . . . . . . . . . 6 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 7.2. Informative References . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 In network scenarios where Path Computation Element (PCE) is used for 81 centralized path computation, it is desirable for Path Computation 82 Clients (PCCs) to automatically discover a set of PCEs. [RFC5088] 83 and [RFC5089] define PCE discovery mechanism based on Interior 84 Gateway Protocol (IGP). The IGP based mechanisms may not work well 85 in scenarios where the PCEs do not participate in the IGP, and it is 86 difficult for PCE to participate in IGP of multiple domains where PCE 87 discovery is needed. 89 For example, Backward Recursive Path Computation (BRPC) [RFC5441] may 90 be used by cooperating PCEs to compute inter-domain path, in which 91 case these cooperating PCEs should be known to other PCEs. In case 92 of inter-AS network where the PCEs do not participate in a common 93 IGP, the existing IGP discovery mechanism cannot be used to discover 94 the PCEs in other domains. Also in the Hierarchical PCE scenario, 95 the child PCEs need to know the address of the parent PCE. This 96 cannot be achieved through IGP based discovery, as normally the child 97 PCEs and the parent PCE are under different administration and reside 98 in different domains. 100 As BGP could be used for north-bound distribution of routing and 101 Label Switched Path (LSP) information to PCE as described in 102 [I-D.ietf-idr-ls-distribution] [I-D.ietf-idr-te-lsp-distribution] and 103 [I-D.ietf-idr-te-pm-bgp], PCEs can obtain the routing information 104 without participating in IGP. In this scenario, some other PCE 105 disovery mechanism is also needed. 107 A detailed set of requirements for a PCE discovery mechanism are 108 provided in [RFC4674]. 110 This document proposes to extend BGP for PCE discovery for the above 111 scenarios. In networks where BGP-LS is already used for the north- 112 bound routing information distribution to PCE, BGP based PCE 113 discovery can reuse the existing BGP sessions and mechanisms to 114 achieve PCE discovery. It should be noted that, in IGP domain, the 115 IGP based PCE discovery mechanism may be used in conjunction with the 116 BGP based PCE discovery. Thus the BGP based PCE discovery is 117 complementary to the existing IGP based mechanisms. 119 +-----------+ 120 | PCE | 121 +-----------+ 122 | 123 v 124 +-----------+ 125 | BGP | +-----------+ 126 | Speaker | | PCE | 127 +-----------+ +-----------+ 128 | | | | 129 | | | | 130 +---------------+ | +-------------------+ | 131 v v v v 132 +-----------+ +-----------+ +-----------+ 133 | BGP | | BGP | | BGP | 134 | Speaker | | Speaker | . . . | Speaker | 135 | & PCC | | & PCC | | | 136 +-----------+ +-----------+ +-----------+ 137 | 138 | via 139 | IGP 140 v 141 +-----------+ 142 | PCC | 143 +-----------+ 145 Figure 1: BGP for PCE discovery 147 As shown in the network architecture in Figure 1, BGP is used for 148 both routing information distribution and PCE information discovery. 149 The routing information is collected from the network elements and 150 distributed to PCE, while the PCE discovery information is advertised 151 from PCE to PCCs, or between different PCEs. The PCCs maybe co- 152 located with the BGP speakers as shown in Figure 1. The IGP based 153 PCE discovery mechanism may be used for the distribution of PCE 154 discovery information in IGP domain. 156 2. Carrying PCE Discovery Information in BGP 158 2.1. PCE Address Information 160 The PCE discovery information is advertised in BGP UPDATE messages 161 using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. 162 The AFI and SAFI defined in [I-D.ietf-idr-ls-distribution] are re- 163 used, and a new NLRI Type is defined for PCE discovery information as 164 below: 166 o Type = TBD: PCE Discovery NLRI 168 The format of PCE Discovery NLRI is shown in the following figure: 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+ 173 | Protocol-ID | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Identifier | 176 | (64 bits) | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | | 179 ~ PCE-Address (4 or 16 octets) ~ 180 | | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 Figure 2. PCE Discovery NLRI 184 The 'Protocol-ID' field do not apply to the PCE Discovery NLRI and 185 SHOULD be set to 0 on transmission and be ignored upon receipt. 187 The 'Identifier' field is used to identify the "routing universe" 188 where the PCE belongs, and the identifier values as below defined in 189 [I-D.ietf-idr-ls-distribution] apply. 191 +------------+---------------------+ 192 | Identifier | Routing Universe | 193 +------------+---------------------+ 194 | 0 | L3 packet topology | 195 | 1 | L1 optical topology | 196 +------------+---------------------+ 198 2.2. PCE Discovery TLVs 200 The detailed PCE discovery information is carried in BGP-LS attribute 201 [I-D.ietf-idr-ls-distribution] with a new "PCE Discovery TLV", which 202 contains a set of sub-TLVs for specific PCE discovery information. 203 The PCE Discovery TLV and sub-TLVs SHOULD only be used with the PCE 204 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 221 defined in [RFC5088] and [RFC5089]. The PATH-SCOPE TLV MUST always 222 be carried in the BGP-LS Attribute if the NLRI is PCE Discovery NLRI. 223 Other PCE Discovery TLVs are optional and may facilitate the PCE 224 selection process. 226 Type Length Name 227 TBD 3 PATH-SCOPE sub-TLV 228 TBD variable PCE-CAP-FLAGS sub-TLV 229 TBD variable OSPF-PCE-DOMAIN sub-TLV 230 TBD variable IS-IS-PCE-DOMAIN sub-TLV 231 TBD variable OSPF-NEIG-PCE-DOMAIN sub-TLV 232 TBD variable IS-IS-NEIG-PCE-DOMAIN sub-TLV 234 More PCE Discovery sub-TLVs may be defined in future and the format 235 SHOULD be in line with the new sub-TLVs defined for IGP based PCE 236 discovery. 238 3. Operational Considerations 240 Existing BGP operational procedures apply to the advertisement of PCE 241 discovery information. This information is treated as pure 242 application level data which has no immediate impact on forwarding 243 states. Normal BGP path selection can be applied to PCE Discovery 244 NLRI only for the information propagation in the network, while the 245 PCE selection on the PCCs would be peformed based on the information 246 carried in the PCE Discovery TLV. 248 PCE discovery information is considered relatively stable and does 249 not change frequently, thus this information will not bring 250 significant impact on the amount of BGP updates in the network. 252 4. IANA Considerations 254 IANA needs to assign a new NLRI Type for 'PCE Discovery NLRI' from 255 the "BGP-LS NLRI- Types" registry. 257 IANA needs to assign a new TLV code point for 'PCE Discovery TLV' 258 from the "node anchor, link descriptor and link attribute TLVs" 259 registry. 261 IANA needs to create a new registry for "PCE Discovery Sub-TLVs". 262 The registry will be initialized as shown in section 2.2 of this 263 document. 265 5. Security Considerations 267 Procedures and protocol extensions defined in this document do not 268 affect the BGP security model. See the 'Security Considerations' 269 section of [RFC4271] for a discussion of BGP security. Also refer to 270 [RFC4272] and [RFC6952] for analysis of security issues for BGP. 272 6. Acknowledgements 274 The authors would like to thank Zhenbin Li and Hannes Gredler for 275 their discussion and comments. 277 7. References 279 7.1. Normative References 281 [I-D.ietf-idr-ls-distribution] 282 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 283 Ray, "North-Bound Distribution of Link-State and TE 284 Information using BGP", draft-ietf-idr-ls-distribution-06 285 (work in progress), September 2014. 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, March 1997. 290 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 291 Protocol 4 (BGP-4)", RFC 4271, January 2006. 293 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 294 "Multiprotocol Extensions for BGP-4", RFC 4760, January 295 2007. 297 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 298 "OSPF Protocol Extensions for Path Computation Element 299 (PCE) Discovery", RFC 5088, January 2008. 301 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 302 "IS-IS Protocol Extensions for Path Computation Element 303 (PCE) Discovery", RFC 5089, January 2008. 305 7.2. Informative References 307 [I-D.ietf-idr-te-lsp-distribution] 308 Dong, J., Chen, M., Gredler, H., Previdi, S., and J. 309 Tantsura, "Distribution of MPLS Traffic Engineering (TE) 310 LSP State using BGP", draft-ietf-idr-te-lsp- 311 distribution-01 (work in progress), July 2014. 313 [I-D.ietf-idr-te-pm-bgp] 314 Wu, Q., Previdi, S., Gredler, H., Ray, S., and J. 315 Tantsura, "BGP attribute for North-Bound Distribution of 316 Traffic Engineering (TE) performance Metrics", draft-ietf- 317 idr-te-pm-bgp-01 (work in progress), July 2014. 319 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 320 4272, January 2006. 322 [RFC4674] Le Roux, J., "Requirements for Path Computation Element 323 (PCE) Discovery", RFC 4674, October 2006. 325 [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A 326 Backward-Recursive PCE-Based Computation (BRPC) Procedure 327 to Compute Shortest Constrained Inter-Domain Traffic 328 Engineering Label Switched Paths", RFC 5441, April 2009. 330 [RFC6805] King, D. and A. Farrel, "The Application of the Path 331 Computation Element Architecture to the Determination of a 332 Sequence of Domains in MPLS and GMPLS", RFC 6805, November 333 2012. 335 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 336 BGP, LDP, PCEP, and MSDP Issues According to the Keying 337 and Authentication for Routing Protocols (KARP) Design 338 Guide", RFC 6952, May 2013. 340 Authors' Addresses 342 Jie Dong 343 Huawei Technologies 344 Huawei Campus, No. 156 Beiqing Rd. 345 Beijing 100095 346 China 348 Email: jie.dong@huawei.com 349 Mach(Guoyi) Chen 350 Huawei Technologies 351 Huawei Campus, No. 156 Beiqing Rd. 352 Beijing 100095 353 China 355 Email: mach.chen@huawei.com 357 Dhruv Dhody 358 Huawei Technologies 359 Leela Palace 360 Bangalore, Karnataka 560008 361 India 363 Email: dhruv.ietf@gmail.com 365 Jeff Tantsura 366 Ericsson 367 300 Holger Way 368 San Jose, CA 95134 369 US 371 Email: jeff.tantsura@ericsson.com