idnits 2.17.00 (12 Aug 2021) /tmp/idnits61988/draft-lopez-pce-hpce-ted-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC6805]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 1, 2014) is 2874 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 434, but no explicit reference was found in the text == Outdated reference: draft-ietf-idr-ls-distribution has been published as RFC 7752 == Outdated reference: draft-ietf-idr-te-pm-bgp has been published as RFC 8571 == Outdated reference: draft-ietf-pce-hierarchy-extensions has been published as RFC 8685 == Outdated reference: draft-ietf-pce-inter-area-as-applicability has been published as RFC 8694 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Lopez 3 Internet-Draft O. Gonzalez de Dios 4 Intended status: Informational Telefonica I+D 5 Expires: January 2, 2015 D. King 6 Old Dog Consulting 7 S. Previdi 8 Cisco Systems, Inc. 9 J. Tantsura 10 Ericsson 11 July 1, 2014 13 Traffic Engineering Database dissemination for Hierarchical PCE 14 scenarios 15 draft-lopez-pce-hpce-ted-02 17 Abstract 19 The PCE architecture is well-defined and may be used to compute the 20 optimal path for LSPS across domains in MPLS-TE and GMPLS networks. 21 The Hierarchical Path Computation Element (H-PCE) [RFC6805] was 22 developed to provide an optimal path when the sequence of domains is 23 not known in advance. The procedure and mechanism for populating the 24 Traffic Engineering Database (TED) with domain topology and link 25 information used in H-PCE-based path computations is open to 26 interpretation. This informational document describes how topology 27 dissemination mechanisms may be used to provide TE information 28 between Parent and Child PCEs (within the H-PCE context). In 29 particular, it describes how BGP-LS might be used to provide inter- 30 domain connectivity. This document is not intended to define new 31 extensions, it demonstrates how existing procedures and mechanisms 32 may be used. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 2, 2015. 50 Copyright Notice 52 Copyright (c) 2014 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 1.1. Parent PCE Domain Topology . . . . . . . . . . . . . . . 3 69 1.2. Parent PCE TED requirements . . . . . . . . . . . . . . . 4 70 2. H-PCE Domain Topology Dissemination and Construction Methods 4 71 3. H-PCE architecture using BGP-LS . . . . . . . . . . . . . . . 5 72 4. Including inter-domain connectivity in BGP-LS . . . . . . . . 8 73 4.1. Mapping from OSPF-TE . . . . . . . . . . . . . . . . . . 9 74 4.1.1. Node Descriptors . . . . . . . . . . . . . . . . . . 9 75 4.1.2. Link Descriptors . . . . . . . . . . . . . . . . . . 9 76 4.1.3. Mapping OSPF TE parameters into BGP-LS attribute . . 10 77 4.2. Mapping from ISIS-TE . . . . . . . . . . . . . . . . . . 10 78 5. Manageability Considerations . . . . . . . . . . . . . . . . 10 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 82 7.2. Informative References . . . . . . . . . . . . . . . . . 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 85 1. Introduction 87 In scenarios with multiple domains in both MPLS-TE and GMPLS 88 networks, the hierarchical Path Computation Element (H-PCE) 89 Architecture, defined in [RFC6805], allows to obtain the optimum end- 90 to-end path. The architecture exploits a hierarchical relation among 91 domains. 93 [RFC6805] defines the architecture and requirements for the end-to- 94 end path computation across domains. The solution draft for the 95 H-PCE [I-D.draft-ietf-pce-hierarchy-extensions] is focused on the 96 PCEP protocol extensions to support such H-PCE procedures, including 97 negotiation of capabilities and errors. However, neither the 98 architecture nor the solution draft specify which mechanism must to 99 be used to build and populate the parent PCE (pPCE) Traffic 100 Engineering Database (TED). 102 The H-PCE architecture documents define the minimum content needed in 103 the traffic engineering database required to compute paths. The 104 information required by parent TEDB are identified in [RFC6805] and 105 further elaborated in 106 [I-D.draft-ietf-pce-inter-area-as-applicability]. For instance, 107 [RFC6805] and [I-D.draft-ietf-pce-inter-area-as-applicability] 108 suggest that BGP-LS could be used as a "northbound" TE advertisement. 109 This means that a PCE does not need to listen IGP in its domain, but 110 its TED is populated by messages received (for example) from a Route 111 Reflector. [I-D.draft-ietf-idr-te-pm-bgp] extends BGP-LS to 112 disseminate traffic engineering information. The parameters 113 considered are: delay, packet loss and bandwidth. 115 This document highlights the applicability of BGP-LS to the 116 dissemination of domain topology within the H-PCE architecture. In 117 particular, it describes how can BGP-LS be used to send the inter- 118 domain connectivity. It also shows how can OSPF-TE and ISIS-TE 119 updates be mapped into BGP-LS. 121 Note that this document is not intended to define new protocol 122 extensions, it is an informational document and where required it 123 highlights where existing mechanisms and protocols may be applied. 125 1.1. Parent PCE Domain Topology 127 The pPCE maintains a domain topology map of the child domains and 128 their interconnectivity. This map does not include any visibility 129 into the child domains. Where inter-domain connectivity is provided 130 by TE links, the capabilities of those links may also be known to the 131 pPCE. The pPCE maintains a TED for the parent domain, the nodes in 132 the parent domain are abstractions of the cPCE domains (connected by 133 real or virtual TE links), but the pPCE domain may also include real 134 nodes and links. 136 The procedure and protocol mechanism for disseminating and 137 construction of the pPCE TED may be provided using a number of 138 mechanisms, including manually configuring the necessary information 139 or automated using a separate instance of a routing protocol to 140 advertise the domain interconnectivity. Since inter-domain TE links 141 can be advertised by the IGPs operating in the child domains, this 142 information could then be exported to the parent PCE either by the 143 child PCEs or using north-bound export mechanisms. 145 1.2. Parent PCE TED requirements 147 The information that would be exchanged includes: 149 o Identifier of advertising child PCE. 151 o Identifier of PCE's domain. 153 o Identifier of the link. 155 o TE properties of the link (metrics, bandwidth). 157 o Other properties of the link (technology-specific). 159 o Identifier of link endpoints. 161 o Identifier of adjacent domain. 163 2. H-PCE Domain Topology Dissemination and Construction Methods 165 A variety of methods exist to provide are different alternatives so 166 the parent PCE can get the topological information from the child 167 PCEs (cPCEs): 169 o Statically configure all inter-domain link and topology 170 information. 172 o Membership of an IGP instance. The necessary topological 173 information could be disseminated by joining the IGP instance of 174 each child PCE domain. However, by doing so, it would break the 175 domain confidentiality principles and is subject to scalability 176 issues. 178 o PCEP Notification Messages. Another solution is to send the 179 interconnection information between domains using PCEP 180 Notifications (see section 4.8.4 of [RFC6805]). One approach, 181 followed in research work, is embedding in PCEP Notifications the 182 Inter-AS OSPF-TE Link State Advertisements (LSA) to send the 183 Inter-Domain Link information from child PCEs to the parent PCE 184 and to send reachability information (list of end-points in each 185 domain). However, it is argued that the utilization of PCEP to 186 disseminate topology is beyond scope of the protocol. 188 o Separate IGP instance. [RFC6805] points out that in models such 189 as ASON it is possible to consider a separate instance of an IGP 190 running within the parent domain where the participating protocol 191 speakers are the nodes directly present in that domain and the 192 PCEs (parent and child PCEs). 194 o Use north-bound distribution of TE information. The North-Bound 195 Distribution of Link-State and TE Information using BGP has been 196 recently propose in the IEFT [I-D.draft-ietf-idr-ls-distribution]. 197 This approach is known as BGP-LS and defines a mechanism by which 198 links state and traffic engineering information can be collected 199 from networks and exported to external elements using the BGP 200 routing protocol. By using BGP-LS as northbound distribution 201 mechanism, there would be a BGP speaker in each domains that sends 202 the necessary information to a BGP speaker in the parent domain. 203 This architecture is further elaborated in this document. 205 3. H-PCE architecture using BGP-LS 207 As mentioned in [I-D.draft-dugeon-pce-ted-reqs] PCE has to retrieve 208 Traffic Engineering (TE) information to carry out its path 209 computation. This is required not only for intra-domain information, 210 which can be got using IGP (like OSPF-TE or ISIS-TE), but also for 211 inter-domain information in the Hierarchical PCE (H-PCE) 212 architecture. 214 Figure 1 shows an example of a H-PCE architecture. In this example, 215 there is a parent PCE and three child PCEs, and they are organized in 216 multiple domains. The parent PCE does not have information of the 217 whole network, but is only aware of the connectivity among the 218 domains and provides coordination to the child PCEs. Figure 2 shows 219 which is the visibility that parent PCE has from the network 220 according to the definition in [RFC6805]. 222 Thanks to this topological information, when there is a request to a 223 child PCE with the destination in another domain, this path request 224 is sent to the parent PCE, which selects a set of candidate domain 225 paths and sends requests to the child PCEs responsible for these 226 domains. Then, the parent PCE selects the best solution and it is 227 transmitted to the source PCE. 229 ----------------------------------------------------------------- 230 | Parent PCE Domain | 231 | ----- | 232 | |pPCE | | 233 | ----- | 234 | | 235 | ---------------- ---------------- ---------------- | 236 | | Domain 1 | | Domain 2 | | Domain 3 | | 237 | | | | | | | | 238 | | ------ | | ------ | | ------ | | 239 | | |cPCE 1| | | |cPCE 2| | | |cPCE 3| | | 240 | | ------ | | ------ | | ------ | | 241 | | | | | | | | 242 | | ----| |---- ----| |---- | | 243 | | |BN11+---+BN21| |BN23+---+BN31| | | 244 | | ----| |---- ----| |---- | | 245 | | | | | | | | 246 | | ----| |---- ----| |---- | | 247 | | |BN12+---+BN22| |BN24+---+BN32| | | 248 | | ----| |---- ----| |---- | | 249 | | | | | | | | 250 | ---------------- ---------------- ---------------- | 251 ----------------------------------------------------------------- 253 Figure 1: Example of Hierarchical PCE architecture 255 ---------------------------- 256 | Parent PCE view | 257 | ---- | 258 | |pPCE| | 259 | ---- | 260 | | 261 | ---- ---- ---- | 262 | | |---| |---| | | 263 | | D1 | | D2 | | D3 | | 264 | | |---| |---| | | 265 | ---- ---- ---- | 266 ---------------------------- 268 Figure 2: Parent PCE topology information 270 Thanks to the dissemination of inter-domain adjacency information 271 from each cPCE to the pPCE, the pPCE can have a view of reachability 272 between the domains. The H-PCE architecture with BGP-LS is shown in 273 Figure 3. Each domain has a cPCE that is able to compute paths in 274 the domain. This child PCE has access to a domain TED, which is 275 built using IGP information. In each domain, a BGP speaker has 276 access to such domain TED and acts as BGP-LS Route Reflector to 277 provide network topology to the pPCE. Next to the pPCE, there is a 278 BGP speaker that maintains a BGP session with each of the BGP 279 speakers in the domains to receive the topology and build the parent 280 TED. A policy can be applied to the BGP-LS speakers to decide which 281 information is sent to its peer speaker. The minimum amount of 282 information that needs to be exchanged is the inter-domain 283 connectivity, including the details of the Traffic Engineering Inter- 284 domain Links [RFC6805]. With this information, the parent PCE is 285 able to have access to a domain topology map and its connectivity. 286 Additionally, the BGP-LS speaker can be configured to send some 287 intra-domain information for virtual or candidate paths with some TE 288 information. In this case, the parent PCE has access to an extended 289 database, with visibility of both intra-domain and inter-domain 290 information and can compute the sequence of domains with better 291 accuracy. 293 BGP-LS [I-D.draft-ietf-idr-ls-distribution] extends the BGP Update 294 messages to advertise link-state topology thanks to new BGP Network 295 Layer Reachability Information (NLRI). The Link State information is 296 sent in two BGP attributes, the MP_REACH (defined in [RFC4670]) and a 297 LINK_STATE attribute (defined in 298 [I-D.draft-ietf-idr-ls-distribution]). To describe the inter domain 299 links, in the MP_REACH attribute, a Link NLRI can be used with the 300 local node descriptors the address of the source, and in the remote 301 descriptors, the address of the destination of the link. The Link 302 Descriptors field has a TLV (Link Local/Remote Identifiers), which 303 carries the prefix of the Unnumbered or Numbered Interface. In case 304 of the message informs about an intra-domain link, the standard 305 traffic engineering information is included in the LINK_STATE 306 attribute. 308 ---------------------------------------------------------------------- 309 | Parent PCE Domain | 310 | ------- ----- ----- | 311 | -------+BGP-LS +---+ TED +--+pPCE | | 312 | / |Speaker| ----- ----- | 313 | / --+---+ | 314 | / | \_________________ 315 | / | \ 316 | ------------/-------- ----+------------ ------+------------ | 317 | | Domain 1 / | | | Domain 2 | | | Domain 3 | | 318 | | / | | | | | | | | 319 | | ------+ | | -+----- | | ---+--- | | 320 | | |BGP-LS | | | |BGP-LS | | | |BGP-LS | | | 321 | | |Speaker| | | |Speaker| | | |Speaker| | | 322 | | ---+--- | | ---+--- | | ---+--- | | 323 | | | | | | | | | | | 324 | | ---+--- ------ | | ---+-- ------ | | ---+--- ------ | | 325 | | | TED +-+cPCE 1| | | | TED +-+cPCE| | | | TED +-+cPCE 1| | | 326 | | ---+--- ------ | | ---+-- ------ | | ---+--- ------ | | 327 | | | | | | | | | | | 328 | | ---+--- | | ---+--- | | ---+--- | | 329 | | | IGP | | | | IGP | | | | IGP | | | 330 | | | Peer | | | | Peer | | | | Peer | | | 331 | | ------- | | ------- | | ------- | | 332 | | | | | | | | | | | 333 | ------+--------------- -----+----------- ------+------------ | 334 | | | | | 335 | ------------------- ---------------- ------------------- | 336 | | Domain 1 | | Domain 2 | | Domain 3 | | 337 | ------------------- ---------------- ------------------- | 338 ---------------------------------------------------------------------- 340 Figure 3: Example of Hierarchical PCE architecture with BGP-LS 342 4. Including inter-domain connectivity in BGP-LS 344 In order for the parent PCE to carry out the path computation tasks 345 it needs the inter-domain topology between the child domain 346 scenarios. This topology is learnt through IGP by each BGP-LS 347 speaker. The Traffic Engineering extensions (OSPF-TE or ISIS-TE) 348 allow IGP to carry link state information that can be used in 349 optimizing technics such as the PCE algorithms. However, the parent 350 PCE does not require such TE information, but just connectivity 351 between the domains. However, TE information within the domain could 352 be disseminated to the parent PCE to reduce the queries to the child 353 PCEs. 355 4.1. Mapping from OSPF-TE 357 Carrying TE information in OSPF is a well-known standardized feature 358 [RFC3630]. This section explains how this information can be 359 exported outside one IGP domain using BGP-LS. BGP-LS extends the BGP 360 Update messages to advertise link-state topology thanks to the new 361 BGP Network Layer Reachability Information (NLRI) and BGP-LS 362 attribute. 364 The BGP NLRI carries the descriptors used to define the element in 365 question (e.g. link or node) and the BGP-LS attribute carries the 366 chosen parameters to characterize the described element. Information 367 is codified using multiple TLV triplets just as the ones used in 368 OSPF-TE making it easy to integrate. For the purpose of this 369 document, we consider a scenario where there is an origin (router) 370 with the correspondent IPv4, a destination with its IPv4 and a link 371 having the following TE parameters: maximum BW, maximum reservable BW 372 and unreserved BW. 374 4.1.1. Node Descriptors 376 In the OSPF packet, there are two fields that tell us the origin and 377 destination node IDs. The origin IP is the Source OSPF Router ID in 378 the OSPF header and this is mapped into the IGP Router ID subTLV 379 inside the Local Node Descriptors field 380 [I-D.draft-ietf-idr-ls-distribution]. The destination IP is found as 381 the Link ID field in the MPLS LSA in OSPF. This is mapped into the 382 correspondent IGP Router ID in the Remote Node Descriptors field 383 [I-D.draft-ietf-idr-ls-distribution]. 385 There are other subTLVs inside the Local/Remote Node Descriptors but 386 they are not relevant for this document. 388 4.1.2. Link Descriptors 390 The only two TLVs in the Link Descriptors field to map from OSPF are 391 the local and remote interface addresses. This information is mapped 392 directly from the Local/Remote Interface address TLV carried in the 393 MPLS LSA of OSPF into the Local/Remote Interface address subTLV of 394 the Link Descriptors field. 396 The same procedure must be applied for unnumbered interfaces but 397 utilizing the Link Local/Remote Identifiers TLV. 399 4.1.3. Mapping OSPF TE parameters into BGP-LS attribute 401 As mentioned before, these parameters are not required in the H-PCE 402 scenario. They are just required to reduce the number of queries to 403 the children PCEs. The parent PCE can use bandwidth information 404 between two domains to request for some possible connections instead 405 of all. 407 The BGP-LS attribute will be a set of TLV triplets carrying the 408 desired TE parameters learnt by OSPF. Bandwidth parameters are used 409 to illustrate the example but they are many more (like, available 410 labels). 412 The BGP-LS attribute is mapped in the following way. The TLVs 413 carried in the MPLS-TE LSA in OSPF are directly translated into the 414 equivalent TLVs in BGP-LS. As such, the Unreserved BW TLV in OSPF is 415 mapped into the Unreserved BW TLV in BGP-LS. The same happens with 416 the Maximum BW TLV and the Maximum Reservable BW TLV. 418 4.2. Mapping from ISIS-TE 420 TBD 422 5. Manageability Considerations 424 TBD 426 6. Security Considerations 428 TBD 430 7. References 432 7.1. Normative References 434 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 435 Requirement Levels", BCP 14, RFC 2119, March 1997. 437 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 438 (TE) Extensions to OSPF Version 2", RFC 3630, September 439 2003. 441 [RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC 442 4670, August 2006. 444 [RFC6805] King, D. and A. Farrel, "The Application of the Path 445 Computation Element Architecture to the Determination of a 446 Sequence of Domains in MPLS and GMPLS", RFC 6805, November 447 2012. 449 7.2. Informative References 451 [I-D.draft-dugeon-pce-ted-reqs] 452 Dugeon, O., Meuric, J., Douville, R., Casellas, R., and O. 453 Gonzalez de Dios, "Path Computation Element (PCE) Traffic 454 Engineering Database (TED) Requirements", February 2014. 456 [I-D.draft-ietf-idr-ls-distribution] 457 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 458 Ray, "North-Bound Distribution of Link-State and TE 459 Information using BGP", November 2013. 461 [I-D.draft-ietf-idr-te-pm-bgp] 462 Wu, Q., Wang, D., Previdi, S., Gredler, H., and S. Ray, 463 "BGP attribute for North-Bound Distribution of Traffic 464 Engineering (TE) performance Metrics", January 2014. 466 [I-D.draft-ietf-pce-hierarchy-extensions] 467 Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R., 468 and D. King, "Extensions to Path Computation Element 469 Communication Protocol (PCEP) for Hierarchical Path 470 Computation Elements (PCE)", July 2013. 472 [I-D.draft-ietf-pce-inter-area-as-applicability] 473 King, D., Meuric, J., Dugeon, O., Zhao, Q., and O. 474 Gonzalez de Dios, "Applicability of the Path Computation 475 Element to Inter-Area and Inter-AS MPLS and GMPLS Traffic 476 Engineering", February 2013. 478 Authors' Addresses 480 Victor Lopez 481 Telefonica I+D 482 Don Ramon de la Cruz 82-84 483 Madrid 28045 484 Spain 486 Phone: +34913128872 487 Email: vlopez@tid.es 488 Oscar Gonzalez de Dios 489 Telefonica I+D 490 Don Ramon de la Cruz 82-84 491 Madrid 28045 492 Spain 494 Phone: +34913128832 495 Email: ogondio@tid.es 497 Daniel King 498 Old Dog Consulting 499 UK 501 Email: daniel@olddog.co.uk 503 Stefano Previdi 504 Cisco Systems, Inc. 505 Via Del Serafico 200 506 Rome 00144 507 IT 509 Email: sprevidi@cisco.com 511 Jeff Tantsura 512 Ericsson 513 USA 515 Email: jeff.tantsura@ericsson.com