idnits 2.17.00 (12 Aug 2021) /tmp/idnits9072/draft-lopez-pce-hpce-ted-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 : ---------------------------------------------------------------------------- ** 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 (February 11, 2014) is 3021 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 378, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-dugeon-pce-ted-reqs-02 == 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-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: August 15, 2014 D. King 6 Old Dog Consulting 7 S. Previdi 8 Cisco Systems, Inc. 9 February 11, 2014 11 Traffic Engineering Database dissemination for Hierarchical PCE 12 scenarios 13 draft-lopez-pce-hpce-ted-01 15 Abstract 17 The PCE architecture is well-defined and may be used to compute the 18 optimal path for LSPS across domains in MPLS-TE and GMPLS networks. 19 The Hierarchical Path Computation Element (H-PCE) [RFC6805] was 20 developed to provide an optimal path when the sequence of domains is 21 not known in advance. The procedure and mechanism for populating the 22 Traffic Engineering Database (TED) with domain topology and link 23 information used in H-PCE-based path computations is open to 24 interpretation. This informational document describes how topology 25 dissemination mechanisms may be used to provide TE information 26 between Parent and Child PCEs (within the H-PCE context). In 27 particular, it describes how BGP-LS might be used to provide inter- 28 domain connectivity. This document is not intended to define new 29 extensions, it demonstrates how existing procedures and mechanisms 30 may be used. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 15, 2014. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Parent PCE Domain Topology . . . . . . . . . . . . . . . 3 68 1.2. Parent PCE TED requirements . . . . . . . . . . . . . . . 4 69 2. H-PCE Domain Topology Dissemination and Construction Methods 4 70 3. H-PCE architecture using BGP-LS . . . . . . . . . . . . . . . 5 71 4. Including Inter-domain connectivity in BGP-LS . . . . . . . . 8 72 4.1. Mapping from OSPF-TE . . . . . . . . . . . . . . . . . . 8 73 4.2. Mapping from ISIS-TE . . . . . . . . . . . . . . . . . . 8 74 5. BGP considerations . . . . . . . . . . . . . . . . . . . . . 9 75 6. Manageability Considerations . . . . . . . . . . . . . . . . 9 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 79 8.2. Informative References . . . . . . . . . . . . . . . . . 9 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 82 1. Introduction 84 In scenarios with multiple domains in both MPLS-TE and GMPLS 85 networks, the hierarchical Path Computation Element (H-PCE) 86 Architecture, defined in [RFC6805], allows to obtain the optimum end- 87 to-end path. The architecture exploits a hierarchical relation among 88 domains. 90 [RFC6805] defines the architecture and requirements for the end-to- 91 end path computation across domains. The solution draft for the 92 H-PCE [I-D.draft-zhang-pce-hierarchy-extensions-04] is focused on the 93 PCEP protocol extensions to support such H-PCE procedures, including 94 negotiation of capabilities and errors. However, neither the 95 architecture nor the solution draft specify which mechanism must to 96 be used to build and populate the parent PCE (pPCE) Traffic 97 Engineering Database (TED). 99 The H-PCE architecture documents define the minimum content needed in 100 the traffic engineering database required to compute paths. The 101 information required by parent TEDB are identified in [RFC6805] and 102 further elaborated in 103 [I-D.draft-ietf-pce-inter-area-as-applicability-03]. For instance, 104 [RFC6805] and [I-D.draft-ietf-pce-inter-area-as-applicability-03] 105 suggest that BGP-LS could be used as a "northbound" TE advertisement. 106 This means that a PCE does not need to listen IGP in its domain, but 107 its TED is populated by messages received (for example) from a Route 108 Reflector. [I-D.draft-ietf-idr-te-pm-bgp-00] extends BGP-LS to 109 disseminate traffic engineering information. The parameters 110 considered are: delay, packet loss and bandwidth. 112 This document highlights the applicability of BGP-LS to the 113 dissemination of domain topology within the H-PCE architecture. In 114 particular, it describes how can BGP-LS be used to send the inter- 115 domain connectivity. It also shows how can OSPF-TE and ISIS-TE 116 updates be mapped into BGP-LS. 118 Note that this document is not intended to define new protocol 119 extensions, it is an informational document and where required it 120 highlights where existing mechanisms and protocols may be applied. 122 1.1. Parent PCE Domain Topology 124 The pPCE maintains a domain topology map of the child domains and 125 their interconnectivity. This map does not include any visibility 126 into the child domains. Where inter-domain connectivity is provided 127 by TE links, the capabilities of those links may also be known to the 128 pPCE. The pPCE maintains a TED for the parent domain, the nodes in 129 the parent domain are abstractions of the cPCE domains (connected by 130 real or virtual TE links), but the pPCE domain may also include real 131 nodes and links. 133 The procedure and protocol mechanism for disseminating and 134 construction of the pPCE TED may be provided using a number of 135 mechanisms, including manually configuring the necessary information 136 or automated using a separate instance of a routing protocol to 137 advertise the domain interconnectivity. Since inter-domain TE links 138 can be advertised by the IGPs operating in the child domains, this 139 information could then be exported to the parent PCE either by the 140 child PCEs or using north-bound export mechanisms. 142 1.2. Parent PCE TED requirements 144 The information that would be exchanged includes: 146 o Identifier of advertising child PCE. 148 o Identifier of PCE's domain. 150 o Identifier of the link. 152 o TE properties of the link (metrics, bandwidth). 154 o Other properties of the link (technology-specific). 156 o Identifier of link endpoints. 158 o Identifier of adjacent domain. 160 2. H-PCE Domain Topology Dissemination and Construction Methods 162 A variety of methods exist to provide are different alternatives so 163 the parent PCE can get the topological information from the child 164 PCEs (cPCEs): 166 o Statically configure all inter-domain link and topology 167 information. 169 o Membership of an IGP instance. The necessary topological 170 information could be disseminated by joining the IGP instance of 171 each child PCE domain. However, by doing so, it would break the 172 domain confidentiality principles and is subject to scalability 173 issues. 175 o PCEP Notification Messages. Another solution is to send the 176 interconnection information between domains using PCEP 177 Notifications (see section 4.8.4 of [RFC6805]). One approach, 178 followed in research work, is embedding in PCEP Notifications the 179 Inter-AS OSPF-TE Link State Advertisements (LSA) to send the 180 Inter-Domain Link information from child PCEs to the parent PCE 181 and to send reachability information (list of end-points in each 182 domain). However, it is argued that the utilization of PCEP to 183 disseminate topology is beyond scope of the protocol. 185 o Separate IGP instance. [RFC6805] points out that in models such 186 as ASON it is possible to consider a separate instance of an IGP 187 running within the parent domain where the participating protocol 188 speakers are the nodes directly present in that domain and the 189 PCEs (parent and child PCEs). 191 o Use north-bound distribution of TE information. The North-Bound 192 Distribution of Link-State and TE Information using BGP has been 193 recently propose in the IEFT 194 [I-D.draft-ietf-idr-ls-distribution-04]. This approach is known 195 as BGP-LS and defines a mechanism by which links state and traffic 196 engineering information can be collected from networks and 197 exported to external elements using the BGP routing protocol. By 198 using BGP-LS as northbound distribution mechanism, there would be 199 a BGP speaker in each domains that sends the necessary information 200 to a BGP speaker in the parent domain. This architecture is 201 further elaborated in this document. 203 3. H-PCE architecture using BGP-LS 205 As mentioned in [I-D.draft-dugeon-pce-ted-reqs-02] PCE has to 206 retrieve Traffic Engineering (TE) information to carry out its path 207 computation. This is required not only for intra-domain information, 208 which can be got using IGP (like OSPF-TE or ISIS-TE), but also for 209 inter-domain information in the Hierarchical PCE (H-PCE) 210 architecture. 212 Figure 1 shows an example of a H-PCE architecture. In this example, 213 there is a parent PCE and three child PCEs, and they are organized in 214 multiple domains. The parent PCE does not have information of the 215 whole network, but is only aware of the connectivity among the 216 domains and provides coordination to the child PCEs. Figure 2 shows 217 which is the visibility that parent PCE has from the network 218 according to the definition in [RFC6805]. 220 Thanks to this topological information, when there is a request to a 221 child PCE with the destination in another domain, this path request 222 is sent to the parent PCE, which selects a set of candidate domain 223 paths and sends requests to the child PCEs responsible for these 224 domains. Then, the parent PCE selects the best solution and it is 225 transmitted to the source PCE. 227 ----------------------------------------------------------------- 228 | Parent PCE Domain | 229 | ----- | 230 | |pPCE | | 231 | ----- | 232 | | 233 | ---------------- ---------------- ---------------- | 234 | | Domain 1 | | Domain 2 | | Domain 3 | | 235 | | | | | | | | 236 | | ------ | | ------ | | ------ | | 237 | | |cPCE 1| | | |cPCE 2| | | |cPCE 3| | | 238 | | ------ | | ------ | | ------ | | 239 | | | | | | | | 240 | | ----| |---- ----| |---- | | 241 | | |BN11+---+BN21| |BN23+---+BN31| | | 242 | | ----| |---- ----| |---- | | 243 | | | | | | | | 244 | | ----| |---- ----| |---- | | 245 | | |BN12+---+BN22| |BN24+---+BN32| | | 246 | | ----| |---- ----| |---- | | 247 | | | | | | | | 248 | ---------------- ---------------- ---------------- | 249 ----------------------------------------------------------------- 251 Figure 1: Example of Hierarchical PCE architecture 253 ---------------------------- 254 | Parent PCE view | 255 | ---- | 256 | |pPCE| | 257 | ---- | 258 | | 259 | ---- ---- ---- | 260 | | |---| |---| | | 261 | | D1 | | D2 | | D3 | | 262 | | |---| |---| | | 263 | ---- ---- ---- | 264 ---------------------------- 266 Figure 2: Parent PCE topology information 268 Thanks to the dissemination of inter-domain adjacency information 269 from each cPCE to the pPCE, the pPCE can have a view of reachability 270 between the domains. The H-PCE architecture with BGP-LS is shown in 271 Figure 3. Each domain has a cPCE that is able to compute paths in 272 the domain. This child PCE has access to a domain TED, which is 273 built using IGP information. In each domain, a BGP speaker has 274 access to such domain TED and acts as BGP-LS Route Reflector to 275 provide network topology to the pPCE. Next to the pPCE, there is a 276 BGP speaker that maintains a BGP session with each of the BGP 277 speakers in the domains to receive the topology and build the parent 278 TED. A policy can be applied to the BGP-LS speakers to decide which 279 information is sent to its peer speaker. The minimum amount of 280 information that needs to be exchanged is the inter-domain 281 connectivity, including the details of the Traffic Engineering Inter- 282 domain Links [RFC6805]. With this information, the parent PCE is 283 able to have access to a domain topology map and its connectivity. 284 Additionally, the BGP-LS speaker can be configured to send some 285 intra-domain information for virtual or candidate paths with some TE 286 information. In this case, the parent PCE has access to an extended 287 database, with visibility of both intra-domain and inter-domain 288 information and can compute the sequence of domains with better 289 accuracy. 291 BGP-LS [I-D.draft-ietf-idr-ls-distribution-04] extends the BGP Update 292 messages to advertise link-state topology thanks to new BGP Network 293 Layer Reachability Information (NLRI). The Link State information is 294 sent in two BGP attributes, the MP_REACH (defined in [RFC4670]) and a 295 LINK_STATE attribute (defined in 296 [I-D.draft-ietf-idr-ls-distribution-04]). To describe the inter 297 domain links, in the MP_REACH attribute, a Link NLRI can be used with 298 the local node descriptors the address of the source, and in the 299 remote descriptors, the address of the destination of the link. The 300 Link Descriptors field has a TLV (Link Local/Remote Identifiers), 301 which carries the prefix of the Unnumbered or Numbered Interface. In 302 case of the message informs about an intra-domain link, the standard 303 traffic engineering information is included in the LINK_STATE 304 attribute. 306 ---------------------------------------------------------------------- 307 | Parent PCE Domain | 308 | ------- ----- ----- | 309 | -------+BGP-LS +---+ TED +--+pPCE | | 310 | / |Speaker| ----- ----- | 311 | / --+---+ | 312 | / | \_________________ 313 | / | \ 314 | ------------/-------- ----+------------ ------+------------ | 315 | | Domain 1 / | | | Domain 2 | | | Domain 3 | | 316 | | / | | | | | | | | 317 | | ------+ | | -+----- | | ---+--- | | 318 | | |BGP-LS | | | |BGP-LS | | | |BGP-LS | | | 319 | | |Speaker| | | |Speaker| | | |Speaker| | | 320 | | ---+--- | | ---+--- | | ---+--- | | 321 | | | | | | | | | | | 322 | | ---+--- ------ | | ---+-- ------ | | ---+--- ------ | | 323 | | | TED +-+cPCE 1| | | | TED +-+cPCE| | | | TED +-+cPCE 1| | | 324 | | ---+--- ------ | | ---+-- ------ | | ---+--- ------ | | 325 | | | | | | | | | | | 326 | | ---+--- | | ---+--- | | ---+--- | | 327 | | | IGP | | | | IGP | | | | IGP | | | 328 | | | Peer | | | | Peer | | | | Peer | | | 329 | | ------- | | ------- | | ------- | | 330 | | | | | | | | | | | 331 | ------+--------------- -----+----------- ------+------------ | 332 | | | | | 333 | ------------------- ---------------- ------------------- | 334 | | Domain 1 | | Domain 2 | | Domain 3 | | 335 | ------------------- ---------------- ------------------- | 336 ---------------------------------------------------------------------- 338 Figure 3: Example of Hierarchical PCE architecture with BGP-LS 340 4. Including Inter-domain connectivity in BGP-LS 342 TBD 344 4.1. Mapping from OSPF-TE 346 TBD 348 4.2. Mapping from ISIS-TE 350 TBD 352 5. BGP considerations 354 TBD 356 o Supporting BGP-4 358 o BGP Speakers 360 o Graceful Restart 362 o SRLGs 364 o Multiprotocol extensions 366 6. Manageability Considerations 368 TBD 370 7. Security Considerations 372 TBD 374 8. References 376 8.1. Normative References 378 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 379 Requirement Levels", BCP 14, RFC 2119, March 1997. 381 [RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC 382 4670, August 2006. 384 [RFC6805] King, D. and A. Farrel, "The Application of the Path 385 Computation Element Architecture to the Determination of a 386 Sequence of Domains in MPLS and GMPLS", RFC 6805, November 387 2012. 389 8.2. Informative References 391 [I-D.draft-dugeon-pce-ted-reqs-02] 392 Dugeon, O., Meuric, J., Douville, R., Casellas, R., and O. 393 Gonzalez de Dios, "Path Computation Element (PCE) Traffic 394 Engineering Database (TED) Requirements", July 2013. 396 [I-D.draft-ietf-idr-ls-distribution-04] 397 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 398 Ray, "North-Bound Distribution of Link-State and TE 399 Information using BGP", November 2013. 401 [I-D.draft-ietf-idr-te-pm-bgp-00] 402 Wu, Q., Wang, D., Previdi, S., Gredler, H., and S. Ray, 403 "BGP attribute for North-Bound Distribution of Traffic 404 Engineering (TE) performance Metrics", January 2014. 406 [I-D.draft-ietf-pce-inter-area-as-applicability-03] 407 King, D., Meuric, J., Dugeon, O., Zhao, Q., and O. 408 Gonzalez de Dios, "Applicability of the Path Computation 409 Element to Inter-Area and Inter-AS MPLS and GMPLS Traffic 410 Engineering", February 2013. 412 [I-D.draft-zhang-pce-hierarchy-extensions-04] 413 Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R., 414 and D. King, "Extensions to Path Computation Element 415 Communication Protocol (PCEP) for Hierarchical Path 416 Computation Elements (PCE)", July 2013. 418 Authors' Addresses 420 Victor Lopez 421 Telefonica I+D 422 Don Ramon de la Cruz 82-84 423 Madrid 28045 424 Spain 426 Phone: +34913128872 427 Email: vlopez@tid.es 429 Oscar Gonzalez de Dios 430 Telefonica I+D 431 Don Ramon de la Cruz 82-84 432 Madrid 28045 433 Spain 435 Phone: +34913128832 436 Email: ogondio@tid.es 438 Daniel King 439 Old Dog Consulting 440 UK 442 Email: daniel@olddog.co.uk 443 Stefano Previdi 444 Cisco Systems, Inc. 445 Via Del Serafico 200 446 Rome 00144 447 IT 449 Email: sprevidi@cisco.com