idnits 2.17.1 draft-ietf-teas-yang-path-computation-18.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 : ---------------------------------------------------------------------------- ** There are 58 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 3 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1440 has weird spacing: '...ic-type ide...' == Line 1448 has weird spacing: '...- usage ide...' == Line 1459 has weird spacing: '...k-tp-id te-...' == Line 1464 has weird spacing: '...k-tp-id te-...' == Line 1470 has weird spacing: '...-number ine...' == (53 more instances...) -- The document date (21 March 2022) is 765 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) == Missing Reference: 'RFCYYYY' is mentioned on line 237, but not defined == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-29 == Outdated reference: A later version (-18) exists of draft-ietf-ccamp-otn-topo-yang-14 Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group I. Busi, Ed. 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track S. Belotti, Ed. 5 Expires: 22 September 2022 Nokia 6 O. Gonzalez de Dios 7 Telefonica 8 A. Sharma 9 Google 10 D. Ceccarelli 11 Ericsson 12 21 March 2022 14 A YANG Data Model for requesting path computation 15 draft-ietf-teas-yang-path-computation-18 17 Abstract 19 There are scenarios, typically in a hierarchical Software-Defined 20 Networking (SDN) context, where the topology information provided by 21 a Traffic Engineering (TE) network provider may be insufficient for 22 its client to perform multi-domain path computation. In these cases 23 the client would need to request the TE network provider to compute 24 some intra-domain paths. 26 This document defines a YANG data model which contains Remote 27 Procedure Calls (RPCs) to request path computation. This model 28 complements the solution, defined in RFC YYYY, to configure a TE 29 tunnel path in "compute-only" mode. 31 [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of 32 draft-ietf-teas-yang-te once it has been published. 34 Moreover, this document describes some use cases where the path 35 computation request, via YANG-based protocols (e.g., NETCONF or 36 RESTCONF), can be needed. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on 22 September 2022. 55 Copyright Notice 57 Copyright (c) 2022 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 62 license-info) in effect on the date of publication of this document. 63 Please review these documents carefully, as they describe your rights 64 and restrictions with respect to this document. Code Components 65 extracted from this document must include Revised BSD License text as 66 described in Section 4.e of the Trust Legal Provisions and are 67 provided without warranty as described in the Revised BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 5 74 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5 75 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 2.1. Packet/Optical Integration . . . . . . . . . . . . . . . 6 77 2.2. Multi-domain TE networks . . . . . . . . . . . . . . . . 10 78 2.3. Data Center Interconnections . . . . . . . . . . . . . . 12 79 2.4. Backward Recursive Path Computation scenario . . . . . . 14 80 2.5. Hierarchical PCE scenario . . . . . . . . . . . . . . . . 15 81 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 3.1. Motivation for a YANG Model . . . . . . . . . . . . . . . 17 83 3.1.1. Benefits of common data models . . . . . . . . . . . 17 84 3.1.2. Benefits of a single interface . . . . . . . . . . . 18 85 3.1.3. Extensibility . . . . . . . . . . . . . . . . . . . . 18 86 3.2. Interactions with TE topology . . . . . . . . . . . . . . 19 87 3.2.1. TE topology aggregation . . . . . . . . . . . . . . . 20 88 3.2.2. TE topology abstraction . . . . . . . . . . . . . . . 23 89 3.2.3. Complementary use of the TE topology . . . . . . . . 24 90 3.3. Path Computation RPC . . . . . . . . . . . . . . . . . . 26 91 3.3.1. Temporary reporting of the computed path state . . . 28 92 4. Path computation and optimization for multiple paths . . . . 30 93 5. YANG data model for requesting Path Computation . . . . . . . 31 94 5.1. Synchronization of multiple path computation requests . . 32 95 5.2. Returned metric values . . . . . . . . . . . . . . . . . 34 96 5.3. Multiple Paths Requests for the same TE tunnel . . . . . 35 97 5.3.1. Tunnel attributes specified by value . . . . . . . . 38 98 5.3.2. Tunnel attributes specified by reference . . . . . . 38 99 5.4. Multi-Layer Path Computation . . . . . . . . . . . . . . 41 100 6. YANG data model for TE path computation . . . . . . . . . . . 42 101 6.1. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 42 102 6.2. YANG module . . . . . . . . . . . . . . . . . . . . . . . 53 103 7. Security Considerations . . . . . . . . . . . . . . . . . . . 72 104 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 105 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 74 106 9.1. Normative References . . . . . . . . . . . . . . . . . . 74 107 9.2. Informative References . . . . . . . . . . . . . . . . . 75 108 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 77 109 A.1. Basic Path Computation . . . . . . . . . . . . . . . . . 77 110 A.2. Path Computation with transient state . . . . . . . . . . 77 111 A.3. Path Computation with Global Path Constraint . . . . . . 78 112 A.4. Path Computation with Per-tunnel Path Constraint . . . . 79 113 A.5. Path Computation result . . . . . . . . . . . . . . . . . 80 114 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 81 115 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 82 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 83 118 1. Introduction 120 There are scenarios, typically in a hierarchical Software-Defined 121 Networking (SDN) context, where the topology information provided by 122 a Traffic Engineering (TE) network provider may be insufficient for 123 its client to perform multi-domain path computation. In these cases 124 the client would need to request the TE network provider to compute 125 some intra-domain paths that could be used together with its topology 126 information to compute the multi-domain path. 128 These types of scenarios can be applied to different interfaces in 129 different reference architectures: 131 * Application-Based Network Operations (ABNO) control interface 132 [RFC7491], in which an Application Service Coordinator can request 133 the ABNO controller to take in charge path calculation (see 134 Figure 1 in [RFC7491]). 136 * Abstraction and Control of TE Networks (ACTN) [RFC8453], where a 137 controller hierarchy is defined. In the ACTN context, path 138 computation is needed on the interface between Customer Network 139 Controller (CNC) and Multi-Domain Service Coordinator (MDSC), 140 called CNC-MDSC Interface (CMI), and on the interface between MSDC 141 and Provisioning Network Controller (PNC), called MDSC-PNC 142 Interface (MPI). [RFC8454] describes an information model for the 143 Path Computation request. 145 Multiple protocol solutions can be used for communication between 146 different controller hierarchical levels. This document assumes 147 that the controllers are communicating using YANG-based protocols 148 (e.g., NETCONF [RFC6241] or RESTCONF [RFC8040]). 150 Path Computation Elements (PCEs), controllers and orchestrators 151 perform their operations based on Traffic Engineering Databases 152 (TED). Such TEDs can be described, in a technology agnostic way, 153 with the YANG data model for TE Topologies [RFC8795]. 154 Furthermore, the technology specific details of the TED are 155 modelled in the technology specific topology models, e.g., the 156 [I-D.ietf-ccamp-otn-topo-yang] for Optical Transport Network (OTN) 157 Optical Data Unit (ODU) technologies, which augment the common TE 158 topology model in [RFC8795]. 160 The availability of such topology models allows the provisioning 161 of the TED using YANG-based protocols (e.g., NETCONF or RESTCONF). 162 Furthermore, it enables a PCE/controller performing the necessary 163 abstractions or modifications and offering this customized 164 topology to another PCE/controller or high level orchestrator. 166 The tunnels that can be provided over the networks described with 167 the topology models can be also set-up, deleted and modified via 168 YANG- based protocols (e.g., NETCONF or RESTCONF) using the TE 169 tunnel YANG data model [I-D.ietf-teas-yang-te]. 171 This document defines a YANG data model [RFC7950] for an RPC to 172 request path computation, which complements the solution defined 173 in [I-D.ietf-teas-yang-te], to configure a TE tunnel path in 174 "compute-only" mode. 176 The YANG data model definition does not make any assumption about 177 whether that the client or the server implement a "PCE" 178 functionality, as defined in [RFC4655], and the Path Computation 179 Element Communication Protocol (PCEP) protocol, as defined in 180 [RFC5440]. 182 Moreover, this document describes some use cases where a path 183 computation request, via YANG-based protocols (e.g., NETCONF or 184 RESTCONF), can be needed. 186 The YANG data model defined in this document conforms to the 187 Network Management Datastore Architecture [RFC8342]. 189 1.1. Terminology 191 TED: 193 The traffic engineering database is a collection of all TE 194 information about all TE nodes and TE links in a given network. 196 PCE: 198 A Path Computation Element (PCE) is an entity that is capable of 199 computing a network path or route based on a network graph, and of 200 applying computational constraints during the computation. The 201 PCE entity is an application that can be located within a network 202 node or component, on an out-of-network server, etc. For example, 203 a PCE would be able to compute the path of a TE Label Switched 204 Path (LSP) by operating on the TED and considering bandwidth and 205 other constraints applicable to the TE LSP service request. 206 [RFC4655]. 208 Domain: 210 TE information is the data relating to nodes and TE links that is 211 used in the process of selecting a TE path. TE information is 212 usually only available within a network. We call such a zone of 213 visibility of TE information a domain. An example of a domain may 214 be an IGP area or an Autonomous System. [RFC7926] 216 The terminology for describing YANG data models is found in 217 [RFC7950]. 219 1.2. Tree Diagram 221 Tree diagrams used in this document follow the notation defined in 222 [RFC8340]. 224 1.3. Prefixes in Data Node Names 226 In this document, names of data nodes and other data model objects 227 are prefixed using the standard prefix associated with the 228 corresponding YANG imported modules, as shown in Table 1. 230 +==========+==========================+===========+ 231 | Prefix | YANG module | Reference | 232 +==========+==========================+===========+ 233 | inet | ietf-inet-types | [RFC6991] | 234 +----------+--------------------------+-----------+ 235 | te-types | ietf-te-types | [RFC8776] | 236 +----------+--------------------------+-----------+ 237 | te | ietf-te | [RFCYYYY] | 238 +----------+--------------------------+-----------+ 239 | te-pc | ietf-te-path-computation | RFCXXXX | 240 +----------+--------------------------+-----------+ 242 Table 1: Prefixes and corresponding YANG modules 244 RFC Editor Note: Please replace XXXX with the RFC number assigned to 245 this document. Please replace RFC YYYY with the RFC number of 246 [I-D.ietf-teas-yang-te] once it has been published. Please remove 247 this note. 249 2. Use Cases 251 This section presents some use cases, where a client needs to request 252 underlying SDN controllers for path computation. 254 The use of the YANG data model defined in this document is not 255 restricted to these use cases but can be used in any other use case 256 when deemed useful. 258 The presented uses cases have been grouped, depending on the 259 different underlying topologies: a) Packet/Optical Integration; b) 260 multi-domain Traffic Engineered (TE) Networks; and c) Data Center 261 Interconnections. Use cases d) and e) respectively present how to 262 apply this YANG data model for standard multi-domain PCE i.e. 263 Backward Recursive Path Computation [RFC5441] and Hierarchical PCE 264 [RFC6805]. 266 2.1. Packet/Optical Integration 268 In this use case, an optical domain is used to provide connectivity 269 to some nodes of a packet domain (see Figure 1). 271 +----------------+ 272 | | 273 | Packet/Optical | 274 | Coordinator | 275 | | 276 +---+------+-----+ 277 | | 278 +------------+ | 279 | +-----------+ 280 +------V-----+ | 281 | | +------V-----+ 282 | Packet | | | 283 | Domain | | Optical | 284 | Controller | | Domain | 285 | | | Controller | 286 +------+-----+ +-------+----+ 287 | | 288 .........V......................... | 289 : packet domain : | 290 +----+ +----+ | 291 | R1 |= = = = = = = = = = = = = = = =| R2 | | 292 +-+--+ +--+-+ | 293 | : : | | 294 | :................................ : | | 295 | | | 296 | +-----+ | | 297 | ...........| Opt |........... | | 298 | : | C | : | | 299 | : /+--+--+\ : | | 300 | : / | \ : | | 301 | : / | \ : | | 302 | +-----+ / +--+--+ \ +-----+ | | 303 | | Opt |/ | Opt | \| Opt | | | 304 +---| A | | D | | B |---+ | 305 +-----+\ +--+--+ /+-----+ | 306 : \ | / : | 307 : \ | / : | 308 : \ +--+--+ / optical<---------+ 309 : \| Opt |/ domain : 310 :..........| E |..........: 311 +-----+ 313 Figure 1: Packet/Optical Integration use case 315 Figure 1 as well as Figure 2 below only show a partial view of the 316 packet network connectivity, before additional packet connectivity is 317 provided by the optical network. 319 It is assumed that the Optical Domain Controller provides to the 320 Packet/Optical Coordinator an abstracted view of the optical network. 321 A possible abstraction could be to represent the whole optical 322 network as one "virtual node" with "virtual ports" connected to the 323 access links, as shown in Figure 2. 325 It is also assumed that Packet Domain Controller can provide the 326 Packet/Optical Coordinator the information it needs to set up 327 connectivity between packet nodes through the optical network (e.g., 328 the access links). 330 The path computation request helps the Packet/Optical Coordinator to 331 know the real connections that can be provided by the optical 332 network. 334 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,. 335 , Packet/Optical Coordinator view , 336 , +----+ , . 337 , | | , 338 , | R2 | , . 339 , +----+ +------------ + /+----+ , 340 , | | | |/-----/ / / , . 341 , | R1 |--O VP1 VP4 O / / , 342 , | |\ | | /----/ / , . 343 , +----+ \| |/ / , 344 , / O VP2 VP5 O / , . 345 , / | | +----+ , 346 , / | | | | , . 347 , / O VP3 VP6 O--| R4 | , 348 , +----+ /-----/|_____________| +----+ , . 349 , | |/ +------------ + , 350 , | R3 | , . 351 , +----+ ,,,,,,,,,,,,,,,,, 352 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,. 353 . Packet Domain Controller view +----+ , 354 only packet nodes and packet links | | , . 355 . with access links to the optical network | R2 | , 356 , +----+ /+----+ , . 357 . , | | /-----/ / / , 358 , | R1 |--- / / , . 359 . , +----+\ /----/ / , 360 , / \ / / , . 361 . , / / , 362 , / +----+ , . 363 . , / | | , 364 , / ---| R4 | , . 365 . , +----+ /-----/ +----+ , 366 , | |/ , . 368 . , | R3 | , 369 , +----+ ,,,,,,,,,,,,,,,,,. 370 .,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, , 371 Optical Domain Controller view , . 372 . only optical nodes, +--+ , 373 optical links and /|OF| , . 374 . access links from the +--++--+ / , 375 packet network |OA| \ /-----/ / , . 376 . , ---+--+--\ +--+/ / , 377 , \ | \ \-|OE|-------/ , . 378 . , \ | \ /-+--+ , 379 , \+--+ X | , . 380 . , |OB|-/ \ | , 381 , +--+-\ \+--+ , . 382 . , / \ \--|OD|--- , 383 , /-----/ +--+ +--+ , . 384 . , / |OC|/ , 385 , +--+ , . 386 ., ,,,,,,,,,,,,,,,,,, 387 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, , 388 . Actual Physical View +----+ , 389 , +--+ | | , 390 . , /|OF| | R2 | , 391 , +----+ +--++--+ /+----+ , 392 . , | | |OA| \ /-----/ / / , 393 , | R1 |---+--+--\ +--+/ / / , 394 . , +----+\ | \ \-|OE|-------/ / , 395 , / \ | \ /-+--+ / , 396 . , / \+--+ X | / , 397 , / |OB|-/ \ | +----+ , 398 . , / +--+-\ \+--+ | | , 399 , / / \ \--|OD|---| R4 | , 400 . , +----+ /-----/ +--+ +--+ +----+ , 401 , | |/ |OC|/ , 402 . , | R3 | +--+ , 403 , +----+ , 404 .,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 406 Figure 2: Packet and Optical Topology Abstractions 408 In this use case, the Packet/Optical Coordinator needs to set up an 409 optimal underlying path for an IP link between R1 and R2. 411 As depicted in Figure 2, the Packet/Optical Coordinator has only an 412 "abstracted view" of the physical network, and it does not know the 413 feasibility or the cost of the possible optical paths (e.g., VP1-VP4 414 and VP2-VP5), which depend on the current status of the physical 415 resources within the optical network and on vendor-specific optical 416 attributes. 418 The Packet/Optical Coordinator can request the underlying Optical 419 Domain Controller to compute a set of potential optimal paths, taking 420 into account optical constraints. Then, based on its own 421 constraints, policy and knowledge (e.g. cost of the access links), it 422 can choose which one of these potential paths to use to set up the 423 optimal end- to-end path crossing optical network. 425 ............................ 426 : : 427 O VP1 VP4 O 428 cost=10 /:\ /:\ cost=10 429 / : \----------------------/ : \ 430 +----+ / : cost=50 : \ +----+ 431 | |/ : : \| | 432 | R1 | : : | R2 | 433 | |\ : : /| | 434 +----+ \ : /--------------------\ : / +----+ 435 \ : / cost=55 \ : / 436 cost=5 \:/ \:/ cost=5 437 O VP2 VP5 O 438 : : 439 :..........................: 441 Figure 3: Packet/Optical Integration path computation example 443 For example, in Figure 3, the Packet/Optical Coordinator can request 444 the Optical Domain Controller to compute the paths between VP1-VP4 445 and VP2-VP5 and then decide to set up the optimal end-to-end path 446 using the VP2-VP5 optical path even if this is not the optimal path 447 from the optical domain perspective. 449 Considering the dynamicity of the connectivity constraints of an 450 optical domain, it is possible that a path computed by the Optical 451 Domain Controller when requested by the Packet/Optical Coordinator is 452 no longer valid/available when the Packet/Optical Coordinator 453 requests it to be set up. This is further discussed in Section 3.3. 455 2.2. Multi-domain TE networks 457 In this use case there are two TE domains which are interconnected 458 together by multiple inter-domains links. 460 A possible example could be a multi-domain optical network. 462 +--------------+ 463 | Multi-Domain | 464 | Controller | 465 +---+------+---+ 466 | | 467 +------------+ | 468 | +-----------+ 469 +------V-----+ | 470 | | | 471 | TE Domain | +------V-----+ 472 | Controller | | | 473 | 1 | | TE Domain | 474 +------+-----+ | Controller | 475 | | 2 | 476 | +------+-----+ 477 .........V.......... | 478 : : | 479 +-----+ : | 480 | | : .........V.......... 481 | X | : : : 482 | | +-----+ +-----+ : 483 +-----+ | | | | : 484 : | C |------| E | : 485 +-----+ +-----+ /| | | |\ +-----+ +-----+ 486 | | | |/ +-----+ +-----+ \| | | | 487 | A |----| B | : : | G |----| H | 488 | | | |\ : : /| | | | 489 +-----+ +-----+ \+-----+ +-----+/ +-----+ +-----+ 490 : | | | | : 491 : | D |------| F | : 492 : | | | | +-----+ 493 : +-----+ +-----+ | | 494 : : : | Y | 495 : : : | | 496 : TE domain 1 : : TE domain 2 +-----+ 497 :..................: :.................: 499 Figure 4: Multi-domain multi-link interconnection 501 In order to set up an end-to-end multi-domain TE path (e.g., between 502 nodes A and H), the Multi-Domain Controller needs to know the 503 feasibility or the cost of the possible TE paths within the two TE 504 domains, which depend on the current status of the physical resources 505 within each TE domain. This is more challenging in case of optical 506 networks because the optimal paths depend also on vendor-specific 507 optical attributes (which may be different in the two domains if they 508 are provided by different vendors). 510 In order to set up a multi-domain TE path (e.g., between nodes A and 511 H), the Multi-Domain Controller can request the TE Domain Controllers 512 to compute a set of intra-domain optimal paths and take decisions 513 based on the information received. For example: 515 * The Multi-Domain Controller asks TE Domain Controllers to provide 516 set of paths between A-C, A-D, E-H and F-H 518 * TE Domain Controllers return a set of feasible paths with the 519 associated costs: the path A-C is not part of this set (in optical 520 networks, it is typical to have some paths not being feasible due 521 to optical constraints that are known only by the Optical Domain 522 Controller) 524 * The Multi-Domain Controller will select the path A-D-F-H since it 525 is the only feasible multi-domain path and then request the TE 526 Domain Controllers to set up the A-D and F-H intra-domain paths 528 * If there are multiple feasible paths, the Multi-Domain Controller 529 can select the optimal path knowing the cost of the intra-domain 530 paths (provided by the TE domain controllers) and the cost of the 531 inter-domain links (known by the Multi-Domain Controller) 533 This approach may have some scalability issues when the number of 534 TE domains is quite big (e.g. 20). 536 In this case, it would be worthwhile using the abstract TE 537 topology information provided by the TE Domain Controllers to 538 limit the number of potential optimal end-to-end paths and then 539 request path computation from fewer TE Domain Controllers in order 540 to decide what the optimal path within this limited set is. 542 For more details, see Section 3.2.3. 544 2.3. Data Center Interconnections 546 In these use case, there is a TE domain which is used to provide 547 connectivity between Data Centers which are connected with the TE 548 domain using access links. 550 +--------------+ 551 | Cloud Network| 552 | Orchestrator | 553 +--------------+ 554 | | | | 555 +-------------+ | | +------------------------+ 556 | | +------------------+ | 557 | +--------V---+ | | 558 | | | | | 559 | | TE Network | | | 560 +------V-----+ | Controller | +------V-----+ | 561 | DC | +------------+ | DC | | 562 | Controller | | | Controller | | 563 +------------+ | +-----+ +------------+ | 564 | ....V...| |........ | | 565 | : | P | : | | 566 .....V..... : /+-----+\ : .....V..... | 567 : : +-----+ / | \ +-----+ : : | 568 : DC1 || : | |/ | \| | : DC2 || : | 569 : ||||----| PE1 | | | PE2 |---- |||| : | 570 : _|||||| : | |\ | /| | : _|||||| : | 571 : : +-----+ \ +-----+ / +-----+ : : | 572 :.........: : \| |/ : :.........: | 573 :.......| PE3 |.......: | 574 | | | 575 +-----+ +---------V--+ 576 .....|..... | DC | 577 : : | Controller | 578 : DC3 || : +------------+ 579 : |||| : | 580 : _|||||| <------------------+ 581 : : 582 :.........: 584 Figure 5: Data Center Interconnection use case 586 In this use case, there is the need to transfer data from Data Center 587 1 (DC1) to either DC2 or DC3 (e.g. workload migration). 589 The optimal decision depends both on the cost of the TE path (DC1-DC2 590 or DC1-DC3) and of the Data Center resources within DC2 or DC3. 592 The Cloud Network Orchestrator needs to make a decision for optimal 593 connection based on TE network constraints and Data Center resources. 595 It may not be able to make this decision because it has only an 596 abstract view of the TE network (as in Section 2.1). 598 The Cloud Network Orchestrator can request to the TE Network 599 Controller to compute the cost of the possible TE paths (e.g., DC1- 600 DC2 and DC1-DC3) and to the DC Controller to provide the information 601 it needs about the required Data Center resources within DC2 and DC3 602 and then it can take the decision about the optimal solution based on 603 this information and its policy. 605 2.4. Backward Recursive Path Computation scenario 607 [RFC5441] has defined the Virtual Source Path Tree (VSPT) TLV within 608 PCE Reply Object in order to compute inter-domain paths following a 609 "Backward Recursive Path Computation" (BRPC) method. The main 610 principle is to forward the PCE request message up to the destination 611 domain. Then, each PCE involved in the computation will compute its 612 part of the path and send it back to the requester through PCE 613 Response message. The resulting computation is spread from 614 destination PCE to source PCE. Each PCE is in charge of merging the 615 path it received with the one it calculated. At the end, the source 616 PCE merges its local part of the path with the received one to 617 achieve the end-to-end path. 619 Figure 6 below show a typical BRPC scenario where 3 PCEs cooperate to 620 compute inter-domain paths. 622 +----------------+ +----------------+ 623 | Domain (B) | | Domain (C) | 624 | | | | 625 | /-------|---PCEP---|--------\ | 626 | / | | \ | 627 | (PCE) | | - (PCE) | 628 | / <----------> |D| | 629 | / | Inter | - | 630 +---|----^-------+ Domain +----------------+ 631 | | Link 632 PCEP | 633 | | Inter-domain Link 634 | | 635 +---|----v-------+ 636 | | | 637 | | Domain (A) | 638 | \ | 639 | (PCE) - | 640 | |S| | 641 | - | 642 +----------------+ 644 Figure 6: BRPC Scenario 646 In this use case, a client can use the YANG data model defined in 647 this document to request path computation from the PCE that controls 648 the source of the tunnel. For example, a client can request to the 649 PCE of domain A to compute a path from a source S, within domain A, 650 to a destination D, within domain C. Then PCE of domain A will use 651 PCEP protocol, as per [RFC5441], to compute the path from S to D and 652 in turn gives the final answer to the requester. 654 2.5. Hierarchical PCE scenario 656 [RFC6805] has defined an architecture and extensions to the PCE 657 standard to compute inter-domain path following a hierarchical 658 method. Two new roles have been defined: parent PCE and child PCE. 659 The parent PCE is in charge to coordinate the end-to-end path 660 computation. For that purpose it sends to each child PCE involved in 661 the multi-domain path computation a PCE Request message to obtain the 662 local part of the path. Once received all answer through PCE 663 Response message, the parent PCE will merge the different local parts 664 of the path to achieve the end-to-end path. 666 Figure 7 below shows a typical hierarchical scenario where a parent 667 PCE request end-to-end path to the different child PCE. Note that a 668 PCE could take independently the role of child or parent PCE 669 depending of which PCE will request the path. 671 ----------------------------------------------------------------- 672 | Domain 5 | 673 | ----- | 674 | |PCE 5| | 675 | ----- | 676 | | 677 | ---------------- ---------------- ---------------- | 678 | | Domain 1 | | Domain 2 | | Domain 3 | | 679 | | | | | | | | 680 | | ----- | | ----- | | ----- | | 681 | | |PCE 1| | | |PCE 2| | | |PCE 3| | | 682 | | ----- | | ----- | | ----- | | 683 | | | | | | | | 684 | | ----| |---- ----| |---- | | 685 | | |BN11+---+BN21| |BN23+---+BN31| | | 686 | | - ----| |---- ----| |---- - | | 687 | | |S| | | | | |D| | | 688 | | - ----| |---- ----| |---- - | | 689 | | |BN12+---+BN22| |BN24+---+BN32| | | 690 | | ----| |---- ----| |---- | | 691 | | | | | | | | 692 | | ---- | | | | ---- | | 693 | | |BN13| | | | | |BN33| | | 694 | -----------+---- ---------------- ----+----------- | 695 | \ / | 696 | \ ---------------- / | 697 | \ | | / | 698 | \ |---- ----| / | 699 | ----+BN41| |BN42+---- | 700 | |---- ----| | 701 | | | | 702 | | ----- | | 703 | | |PCE 4| | | 704 | | ----- | | 705 | | | | 706 | | Domain 4 | | 707 | ---------------- | 708 | | 709 ----------------------------------------------------------------- 711 Figure 7: Hierarchical domain topology from RFC6805 713 In this use case, a client can use the YANG data model defined in 714 this document to request to the parent PCE a path from a source S to 715 a destination D. The parent PCE will in turn contact the child PCEs 716 through PCEP protocol to compute the end-to-end path and then return 717 the computed path to the client, using the YANG data model defined in 718 this document. For example the YANG data model can be used to 719 request to PCE5 acting as parent PCE to compute a path from source S, 720 within domain 1, to destination D, within domain 3. PCE5 will 721 contact child PCEs of domain 1, 2 and 3 to obtain local part of the 722 end-to-end path through the PCEP protocol. Once received the PCE 723 Response message, it merges the answers to compute the end-to-end 724 path and send it back to the client. 726 3. Motivations 728 This section provides the motivation for the YANG data model defined 729 in this document. 731 Section 3.1 describes the motivation for a YANG data model to request 732 path computation. 734 Section 3.2 describes the motivation for a YANG data model which 735 complements the TE topology YANG data model defined in [RFC8795]. 737 Section 3.3 describes the motivation for a YANG RPC which complements 738 the TE tunnel YANG data model defined in [I-D.ietf-teas-yang-te]. 740 3.1. Motivation for a YANG Model 742 3.1.1. Benefits of common data models 744 The YANG data model for requesting path computation is closely 745 aligned with the YANG data models that provide (abstract) TE topology 746 information, i.e., [RFC8795] as well as that are used to configure 747 and manage TE tunnels, i.e., [I-D.ietf-teas-yang-te]. 749 There are many benefits in aligning the data model used for path 750 computation requests with the YANG data models used for TE topology 751 information and for TE tunnels configuration and management: 753 * There is no need for an error-prone mapping or correlation of 754 information. 756 * It is possible to use the same endpoint identifiers in path 757 computation requests and in the topology modeling. 759 * The attributes used for path computation constraints are the same 760 as those used when setting up a TE tunnel. 762 3.1.2. Benefits of a single interface 764 The system integration effort is typically lower if a single, 765 consistent interface is used by controllers, i.e., one data modeling 766 language (i.e., YANG) and a common protocol (e.g., NETCONF or 767 RESTCONF). 769 Practical benefits of using a single, consistent interface include: 771 1. Simple authentication and authorization: The interface between 772 different components has to be secured. If different protocols 773 have different security mechanisms, ensuring a common access 774 control model may result in overhead. For instance, there may be 775 a need to deal with different security mechanisms, e.g., 776 different credentials or keys. This can result in increased 777 integration effort. 779 2. Consistency: Keeping data consistent over multiple different 780 interfaces or protocols is not trivial. For instance, the 781 sequence of actions can matter in certain use cases, or 782 transaction semantics could be desired. While ensuring 783 consistency within one protocol can already be challenging, it is 784 typically cumbersome to achieve that across different protocols. 786 3. Testing: System integration requires comprehensive testing, 787 including corner cases. The more different technologies are 788 involved, the more difficult it is to run comprehensive test 789 cases and ensure proper integration. 791 4. Middle-box friendliness: Provider and consumer of path 792 computation requests may be located in different networks, and 793 middle-boxes such as firewalls, NATs, or load balancers may be 794 deployed. In such environments it is simpler to deploy a single 795 protocol. Also, it may be easier to debug connectivity problems. 797 5. Tooling reuse: Implementers may want to implement path 798 computation requests with tools and libraries that already exist 799 in controllers and/or orchestrators, e.g., leveraging the rapidly 800 growing eco-system for YANG tooling. 802 3.1.3. Extensibility 804 Path computation is only a subset of the typical functionality of a 805 controller. In many use cases, issuing path computation requests 806 comes along with the need to access other functionality on the same 807 system. In addition to obtaining TE topology, for instance also 808 configuration of services (set-up/modification/deletion) may be 809 required, as well as: 811 1. Receiving notifications for topology changes as well as 812 integration with fault management 814 2. Performance management such as retrieving monitoring and 815 telemetry data 817 3. Service assurance, e.g., by triggering OAM functionality 819 4. Other fulfilment and provisioning actions beyond tunnels and 820 services, such as changing QoS configurations 822 YANG is a very extensible and flexible data modeling language 823 that can be used for all these use cases. 825 3.2. Interactions with TE topology 827 The use cases described in Section 2 have been described assuming 828 that the topology view exported by each underlying controller to its 829 client is aggregated using the "virtual node model", defined in 830 [RFC7926]. 832 TE topology information, e.g., as provided by [RFC8795], could in 833 theory be used by an underlying controller to provide TE information 834 to its client thus allowing a PCE available within its client to 835 perform multi-domain path computation on its own, without requesting 836 path computations to the underlying controllers. 838 In case the client does not implement a PCE function, as discussed in 839 Section 1, it could not perform path computation based on TE topology 840 information and would instead need to request path computation from 841 the underlying controllers to get the information it needs to find 842 the optimal end-to-end path. 844 In case the client implements a PCE function, as discussed in 845 Section 1, the TE topology information needs to be complete and 846 accurate, which would bring to scalability issues. 848 Using TE topology to provide a "virtual link model" aggregation, as 849 described in [RFC7926], may be insufficient, unless the aggregation 850 provides complete and accurate information, which would still cause 851 scalability issues, as described in Section 3.2.1 below. 853 Using TE topology abstraction, as described in [RFC7926], may lead to 854 compute an unfeasible path, as described in [RFC7926] in 855 Section 3.2.2 below. 857 Therefore when computing an optimal multi-domain path, there is a 858 scalability trade-off between providing complete and accurate TE 859 information and the number of path computation requests to the 860 underlying controllers. 862 The TE topology information used, in a complimentary way, to reduce 863 the number for path computation requests to the underlying 864 controllers, are described in Section 3.2.3 below. 866 3.2.1. TE topology aggregation 868 Using the TE topology model, as defined in [RFC8795], the underlying 869 controller can export the whole TE domain as a single TE node with a 870 "detailed connectivity matrix" (which provides specific TE 871 attributes, such as delay, Shared Risk Link Groups (SRLGs) and other 872 TE metrics, between each ingress and egress links). 874 The information provided by the "detailed connectivity matrix" would 875 be equivalent to the information that should be provided by "virtual 876 link model" as defined in [RFC7926]. 878 For example, in the Packet/Optical Integration use case, described in 879 Section 2.1, the Optical Domain Controller can make the information 880 shown in Figure 3 available to the Packet/Optical Coordinator as part 881 of the TE topology information and the Packet/Optical Coordinator 882 could use this information to calculate on its own the optimal path 883 between R1 and R2, without requesting any additional information to 884 the Optical Domain Controller. 886 However, when designing the amount of information to provide within 887 the "detailed connectivity matrix", there is a tradeoff to be 888 considered between accuracy (i.e., providing "all" the information 889 that might be needed by the PCE available within the client) and 890 scalability. 892 Figure 8 below shows another example, similar to Figure 3, where 893 there are two possible Optical paths between VP1 and VP4 with 894 different properties (e.g., available bandwidth and cost). 896 ............................ 897 : /--------------------\ : 898 : / cost=65 \ : 899 :/ available-bw=10G \: 900 O VP1 VP4 O 901 cost=10 /:\ /:\ cost=10 902 / : \----------------------/ : \ 903 +----+ / : cost=50 : \ +----+ 904 | |/ : available-bw=2G : \| | 905 | R1 | : : | R2 | 906 | |\ : : /| | 907 +----+ \ : /--------------------\ : / +----+ 908 \ : / cost=55 \ : / 909 cost=5 \:/ available-bw=3G \:/ cost=5 910 O VP2 VP5 O 911 : : 912 :..........................: 914 Figure 8: Packet/Optical Integration path computation Example 915 with multiple choices 917 If the information in the "detailed connectivity matrix" is not 918 complete/accurate, we can have the following drawbacks: 920 * If only the VP1-VP4 path with available bandwidth of 2 Gb/s and 921 cost 50 is reported, the client's PCE will fail to compute a 5 Gb/ 922 s path between routers R1 and R2, although this would be feasible; 924 * If only the VP1-VP4 path with available bandwidth of 10 Gb/s and 925 cost 60 is reported, the client's PCE will compute, as optimal, 926 the 1 Gb/s path between R1 and R2 going through the VP2-VP5 path 927 within the optical domain while the optimal path would actually be 928 the one going thought the VP1-VP4 sub-path (with cost 50) within 929 the optical domain. 931 Reporting all the information, as in Figure 8, using the "detailed 932 connectivity matrix", is quite challenging from a scalability 933 perspective. The amount of this information is not just based on 934 number of end points (which would scale as N-square), but also on 935 many other parameters, including client rate, user constraints/ 936 policies for the service, e.g. max latency < N ms, max cost, etc., 937 exclusion policies to route around busy links, min Optical Signal 938 to Noise Ratio (OSNR) margin, max pre-Forward Error Correction 939 (FEC) Bit Error Rate (BER) etc. All these constraints could be 940 different based on connectivity requirements. 942 It is also worth noting that the "connectivity matrix" has been 943 originally defined in Wavelength Switched Optical Networks (WSON), 944 [RFC7446], to report the connectivity constrains of a physical 945 node within the Wavelength Division Multiplexing (WDM) network: 946 the information it contains is pretty "static" and therefore, once 947 taken and stored in the TE data base, it can be always being 948 considered valid and up-to-date in path computation request. 950 The "connectivity matrix" is sometimes confused with "optical 951 reach table" that contain multiple (e.g. k-shortest) regen-free 952 reachable paths for every A-Z node combination in the network. 953 Optical reach tables can be calculated offline, utilizing vendor 954 optical design and planning tools, and periodically uploaded to 955 the Controller: these optical path reach tables are fairly static. 956 However, to get the connectivity matrix, between any two sites, 957 either a regen free path can be used, if one is available, or 958 multiple regen free paths are concatenated to get from the source 959 to the destination, which can be a very large combination. 960 Additionally, when the optical path within optical domain needs to 961 be computed, it can result in different paths based on input 962 objective, constraints, and network conditions. In summary, even 963 though "optical reach table" is fairly static, which regen free 964 paths to build the connectivity matrix between any source and 965 destination is very dynamic, and is done using very sophisticated 966 routing algorithms. 968 Using the "basic connectivity matrix" with an abstract node to 969 abstract the information regarding the connectivity constraints of 970 an Optical domain, would make this information more "dynamic" 971 since the connectivity constraints of an optical domain can change 972 over time because some optical paths that are feasible at a given 973 time may become unfeasible at a later time when e.g., another 974 optical path is established. 976 The information in the "detailed connectivity matrix" is even more 977 dynamic since the establishment of another optical path may change 978 some of the parameters (e.g., delay or available bandwidth) in the 979 "detailed connectivity matrix" while not changing the feasibility 980 of the path. 982 There is therefore the need to keep the information in the 983 "detailed connectivity matrix" updated which means that there 984 another tradeoff between the accuracy (i.e., providing "all" the 985 information that might be needed by the client's PCE) and having 986 up-to-date information. The more the information is provided and 987 the longer it takes to keep it up-to-date which increases the 988 likelihood that the client's PCE computes paths using not updated 989 information. 991 It seems therefore quite challenging to have a "detailed 992 connectivity matrix" that provides accurate, scalable and updated 993 information to allow the client's PCE to take optimal decisions by 994 its own. 996 Considering the example in Figure 8 with the approach defined in 997 this document, the client, when it needs to set up an end-to-end 998 path, it can request the Optical Domain Controller to compute a 999 set of optimal paths (e.g., for VP1-VP4 and VP2-VP5) and take 1000 decisions based on the information received: 1002 * When setting up a 5 Gb/s path between routers R1 and R2, the 1003 Optical Domain Controller may report only the VP1-VP4 path as the 1004 only feasible path: the Packet/Optical Coordinator can 1005 successfully set up the end-to-end path passing though this 1006 optical path; 1008 * When setting up a 1 Gb/s path between routers R1 and R2, the 1009 Optical Domain Controller (knowing that the path requires only 1 1010 Gb/s) can report both the VP1-VP4 path, with cost 50, and the VP2- 1011 VP5 path, with cost 65. The Packet/Optical Coordinator can then 1012 compute the optimal path which is passing thought the VP1-VP4 sub- 1013 path (with cost 50) within the optical domain. 1015 3.2.2. TE topology abstraction 1017 Using the TE topology model, as defined in [RFC8795], the underlying 1018 controller can export to its client an abstract TE topology, composed 1019 by a set of TE nodes and TE links, representing the abstract view of 1020 the topology under its control. 1022 For example, in the multi-domain TE network use case, described in 1023 Section 2.2, the TE Domain Controller 1 can export a TE topology 1024 encompassing the TE nodes A, B, C and D and the TE links 1025 interconnecting them. In a similar way, the TE Domain Controller 2 1026 can export a TE topology encompassing the TE nodes E, F, G and H and 1027 the TE links interconnecting them. 1029 In this example, for simplicity reasons, each abstract TE node maps 1030 with each physical node, but this is not necessary. 1032 In order to set up a multi-domain TE path (e.g., between nodes A and 1033 H), the Multi-Domain Controller can compute by its own an optimal 1034 end-to-end path based on the abstract TE topology information 1035 provided by the domain controllers. For example: 1037 * Multi-Domain Controller can compute, based on its own TED data, 1038 the optimal multi-domain path being A-B-C-E-G-H, and then request 1039 the TE Domain Controllers to set up the A-B-C and E-G-H intra- 1040 domain paths 1042 * But, during path set-up, the TE Domain Controller may find out 1043 that A-B-C intra-domain path is not feasible (as discussed in 1044 Section 2.2, in optical networks it is typical to have some paths 1045 not being feasible due to optical constraints that are known only 1046 by the Optical Domain Controller), while only the path A-B-D is 1047 feasible 1049 * So what the Multi-Domain Controller has computed is not good and 1050 it needs to re-start the path computation from scratch 1052 As discussed in Section 3.2.1, providing more extensive abstract 1053 information from the TE Domain Controllers to the Multi-Domain 1054 Controller may lead to scalability problems. 1056 In a sense this is similar to the problem of routing and 1057 wavelength assignment within an optical domain. It is possible to 1058 do first routing (step 1) and then wavelength assignment (step 2), 1059 but the chances of ending up with a good path is low. 1060 Alternatively, it is possible to do combined routing and 1061 wavelength assignment, which is known to be a more optimal and 1062 effective way for optical path set-up. Similarly, it is possible 1063 to first compute an abstract end-to-end path within the Multi- 1064 Domain Controller (step 1) and then compute an intra-domain path 1065 within each optical domain (step 2), but there are more chances 1066 not to find a path or to get a suboptimal path than by performing 1067 multiple per-domain path computations and then stitching them 1068 together. 1070 3.2.3. Complementary use of the TE topology 1072 As discussed in Section 2.2, there are some scalability issues with 1073 path computation requests in a multi-domain TE network with many TE 1074 domains, in terms of the number of requests to send to the TE Domain 1075 Controllers. It would therefore be worthwhile using the abstract TE 1076 topology information provided by the TE Domain Controllers to limit 1077 the number of requests. 1079 An example can be described considering the multi-domain abstract TE 1080 topology shown in Figure 9. In this example, an end-to-end TE path 1081 between domains A and F needs to be set up. The transit TE domain 1082 should be selected between domains B, C, D and E. 1084 .........B......... 1085 : _ _ _ _ _ _ _ _ : 1086 :/ \: 1087 +---O NOT FEASIBLE O---+ 1088 cost=5| : : | 1089 ......A...... | :.................: | ......F...... 1090 : : | | : : 1091 : O-----+ .........C......... +-----O : 1092 : : : /-------------\ : : : 1093 : : :/ \: : : 1094 : cost<=20 O---------O cost <= 30 O---------O cost<=20 : 1095 : /: cost=5 : : cost=5 :\ : 1096 : /------/ : :.................: : \------\ : 1097 : / : : \ : 1098 :/ cost<=25 : .........D......... : cost<=25 \: 1099 O-----------O-------+ : /-------------\ : +-------O-----------O 1100 :\ : cost=5| :/ \: |cost=5 : /: 1101 : \ : +-O cost <= 30 O-+ : / : 1102 : \------\ : : : : /------/ : 1103 : cost>=30 \: :.................: :/ cost>=30 : 1104 : O-----+ +-----O : 1105 :...........: | .........E......... | :...........: 1106 | : /-------------\ : | 1107 cost=5| :/ \: |cost=5 1108 +---O cost >= 30 O---+ 1109 : : 1110 :.................: 1112 Figure 9: Multi-domain with many domains (Topology information) 1114 The actual cost of each intra-domain path is not known a priori from 1115 the abstract topology information. The Multi-Domain Controller only 1116 knows, from the TE topology provided by the underlying domain 1117 controllers, the feasibility of some intra-domain paths and some 1118 upper-bound and/or lower-bound cost information. With this 1119 information, together with the cost of inter-domain links, the Multi- 1120 Domain Controller can understand by its own that: 1122 * Domain B cannot be selected as the path connecting domains A and F 1123 is not feasible; 1125 * Domain E cannot be selected as a transit domain since it is known 1126 from the abstract topology information provided by domain 1127 controllers that the cost of the multi-domain path A-E-F (which is 1128 100, in the best case) will be always be higher than the cost of 1129 the multi-domain paths A-D-F (which is 90, in the worst case) and 1130 A-C-F (which is 80, in the worst case). 1132 Therefore, the Multi-Domain Controller can understand by its own 1133 that the optimal multi-domain path could be either A-D-F or A-C-F 1134 but it cannot know which one of the two possible option actually 1135 provides the optimal end-to-end path. 1137 The Multi-Domain Controller can therefore request path computation 1138 only to the TE Domain Controllers A, D, C and F (and not to all 1139 the possible TE Domain Controllers). 1141 .........B......... 1142 : : 1143 +---O O---+ 1144 ......A...... | :.................: | ......F...... 1145 : : | | : : 1146 : O-----+ .........C......... +-----O : 1147 : : : /-------------\ : : : 1148 : : :/ \: : : 1149 : cost=15 O---------O cost = 25 O---------O cost=10 : 1150 : /: cost=5 : : cost=5 :\ : 1151 : /------/ : :.................: : \------\ : 1152 : / : : \ : 1153 :/ cost=10 : .........D......... : cost=15 \: 1154 O-----------O-------+ : /-------------\ : +-------O-----------O 1155 : : cost=5| :/ \: |cost=5 : : 1156 : : +-O cost = 15 O-+ : : 1157 : : : : : : 1158 : : :.................: : : 1159 : O-----+ +-----O : 1160 :...........: | .........E......... | :...........: 1161 | : : | 1162 +---O O---+ 1163 :.................: 1165 Figure 10: Multi-domain with many domains (Path Computation 1166 information) 1168 Based on these requests, the Multi-Domain Controller can know the 1169 actual cost of each intra-domain paths which belongs to potential 1170 optimal end-to-end paths, as shown in Figure 10, and then compute the 1171 optimal end-to-end path (e.g., A-D-F, having total cost of 50, 1172 instead of A-C-F having a total cost of 70). 1174 3.3. Path Computation RPC 1176 The TE tunnel YANG data model, defined in [I-D.ietf-teas-yang-te], 1177 can support the need to request path computation, as described in 1178 section 5.1.2 of [I-D.ietf-teas-yang-te]. 1180 This solution is stateful since the state of each created "compute- 1181 only" TE tunnel path needs to be maintained, in the YANG datastores 1182 (at least in the running datastore and operational datastore), and 1183 updated, when underlying network conditions change. 1185 The RPC mechanism allows requesting path computation using a simple 1186 atomic operation, without creating any state in the YANG datastores, 1187 and it is the natural option/choice, especially with stateless PCE. 1189 It is very useful to provide both the options of using an RPC as well 1190 as of setting up TE tunnel paths in "compute-only" mode. It is 1191 suggested to use the RPC as much as possible and to rely on "compute- 1192 only" TE tunnel paths, when really needed. 1194 Using the RPC solution would imply that the underlying controller 1195 (e.g., a PNC) computes a path twice during the process to set up an 1196 LSP: at time T1, when its client (e.g., an MDSC) sends a path 1197 computation RPC request to it, and later, at time T2, when the same 1198 client (MDSC) creates a TE tunnel requesting the set-up of the LSP. 1199 The underlying assumption is that, if network conditions have not 1200 changed, the same path that has been computed at time T1 is also 1201 computed at time T2 by the underlying controller (e.g. PNC) and 1202 therefore the path that is set up at time T2 is exactly the same path 1203 that has been computed at time T1. 1205 However, since the operation is stateless, there is no guarantee that 1206 the returned path would still be available when path set-up is 1207 requested: this does not cause major issues when the time between 1208 path computation and path set-up is short (especially if compared 1209 with the time that would be needed to update the information of a 1210 very detailed connectivity matrix). 1212 In most of the cases, there is even no need to guarantee that the 1213 path that has been set up is the exactly same as the path that has 1214 been returned by path computation, especially if it has the same or 1215 even better metrics. Depending on the abstraction level applied by 1216 the server, the client may also not know the actual computed path. 1218 The most important requirement is that the required global objectives 1219 (e.g., multi-domain path metrics and constraints) are met. For this 1220 reason a path verification phase is always necessary to verify that 1221 the actual path that has been set up meets the global objectives (for 1222 example in a multi-domain network, the resulting end-to-end path 1223 meets the required end-to-end metrics and constraints). 1225 In most of the cases, even if the path being set up is not exactly 1226 the same as the path returned by path computation, its metrics and 1227 constraints are "good enough" and the path verification passes 1228 successfully. In the few corner cases where the path verification 1229 fails, it is possible repeat the whole process (path computation, 1230 path set-up and path verification). 1232 In case it is required to set up at T2 exactly the same path computed 1233 at T1, the RPC solution should not be used and, instead, a "compute- 1234 only" TE tunnel path should be set up, allowing also notifications in 1235 case the computed path has been changed. 1237 In this case, at time T1, the client (MDSC) creates a TE tunnel in a 1238 compute-only mode in the running datastore and later, at time T2, 1239 changes the configuration of that TE tunnel (not to be any more in a 1240 compute-only mode) to trigger the set-up of the LSP over the path 1241 which have been computed at time T1 and reported in the operational 1242 datastore. 1244 It is worth noting that also using the "compute-only" TE tunnel path, 1245 although increasing the likelihood that the computed path is 1246 available at path set-up, does not guarantee that because 1247 notifications may not be reliable or delivered on time. Path 1248 verification is needed also in this case. 1250 The solution based on "compute-only" TE tunnel path has also the 1251 following drawbacks: 1253 * Several messages required for any path computation 1255 * Requires persistent storage in the underlying controller 1257 * Need for garbage collection for stranded paths 1259 * Process burden to detect changes on the computed paths in order to 1260 provide notifications update 1262 3.3.1. Temporary reporting of the computed path state 1264 This section describes an optional extension to the stateless 1265 behavior of the path computation RPC, where the underlying 1266 controller, after having received a path computation RPC request, 1267 maintains some "transient state" associated with the computed path, 1268 allowing the client to request the set-up of exactly that path, if 1269 still available. 1271 This is similar to the "compute-only" TE tunnel path solution but, to 1272 avoid the drawbacks of the stateful approach, is leveraging the path 1273 computation RPC and the separation between configuration and 1274 operational datastore, as defined in the NMDA architecture [RFC8342]. 1276 The underlying controller, after having computed a path, as requested 1277 by a path computation RPC, also creates a TE tunnel instance within 1278 the operational datastore, to store that computed path. This would 1279 be similar to a "compute-only" TE tunnel path, with the only 1280 difference that there is no associated TE tunnel instance within the 1281 running datastore. 1283 Since the underlying controller stores in the operational datastore 1284 the computed path based on an abstract topology it exposes, it also 1285 remembers, internally, which is the actual native path (physical 1286 path), within its native topology (physical topology), associated 1287 with that compute-only TE tunnel instance. 1289 Afterwards, the client (e.g., MDSC) can request the set-up of that 1290 specific path by creating a TE tunnel instance (not in compute-only 1291 mode) in the running datastore using the same tunnel-name of the 1292 existing TE tunnel in the operational datastore: this will trigger 1293 the underlying controller to set up that path, if still available. 1295 There are still cases where the path being set up is not exactly the 1296 same as the path that has been computed: 1298 * When the tunnel is configured with path constraints which are not 1299 compatible with the computed path; 1301 * When the tunnel set-up is requested after the resources of the 1302 computed path are no longer available; 1304 * When the tunnel set-up is requested after the computed path is no 1305 longer known (e.g. due to a server reboot) by the underlying 1306 controller. 1308 In all these cases, the underlying controller should compute and 1309 set up a new path. 1311 Therefore the "path verification" phase, as described in 1312 Section 3.3 above, is always needed to check that the path that 1313 has been set up is still "good enough". 1315 Since this new approach is not completely stateless, garbage 1316 collection is implemented using a timeout that, when it expires, 1317 triggers the removal of the computed path from the operational 1318 datastore. This operation is fully controlled by the underlying 1319 controller without the need for any action to be taken by the 1320 client that is not able to act on the operational datastore. The 1321 default value of this timeout is 10 minutes but a different value 1322 may be configured by the client. 1324 In addition, it is possible for the client to tag each path 1325 computation request with a transaction-id allowing for a faster 1326 removal of all the paths associated with a transaction-id, without 1327 waiting for their timers to expire. 1329 The underlying controller can remove from the operational 1330 datastore all the paths computed with a given transaction-id which 1331 have not been set up either when it receives a Path Delete RPC 1332 request for that transaction-id or, automatically, right after the 1333 set-up up of a path that has been previously computed with that 1334 transaction-id. 1336 This possibility is useful when multiple paths are computed but, 1337 at most, only one is set up (e.g., in multi-domain path 1338 computation scenario scenarios). After the selected path has been 1339 set up (e.g, in one domain during multi-domain path set-up), all 1340 the other alternative computed paths can be automatically deleted 1341 by the underlying controller (since no longer needed). The client 1342 can also request, using the Path Delete RPC request, the 1343 underlying controller to remove all the computed paths, if none of 1344 them is going to be set up (e.g., in a transit domain not being 1345 selected by multi-domain path computation and so not being 1346 automatically deleted). 1348 This approach is complimentary and not alternative to the timer 1349 which is always needed to avoid stranded computed paths being 1350 stored in the operational datastore when no path is set up and no 1351 explicit Path Delete RPC request is received. 1353 4. Path computation and optimization for multiple paths 1355 There are use cases, where it is advantageous to request path 1356 computation for a set of paths, through a network or through a 1357 network domain, using a single request [RFC5440]. 1359 In this case, sending a single request for multiple path 1360 computations, instead of sending multiple requests for each path 1361 computation, would reduce the protocol overhead and it would consume 1362 less resources (e.g., threads in the client and server). 1364 In the context of a typical multi-domain TE network, there could 1365 multiple choices for the ingress/egress points of a domain and the 1366 Multi-Domain Controller needs to request path computation between all 1367 the ingress/egress pairs to select the best pair. For example, in 1368 the example of Section 2.2, the Multi-Domain Controller needs to 1369 request the TE Network Controller 1 to compute the A-C and the A-D 1370 paths and to the TE Network Controller 2 to compute the E-H and the 1371 F-H paths. 1373 It is also possible that the Multi-Domain Controller receives a 1374 request to set up a group of multiple end to end connections. The 1375 Multi-Domain Controller needs to request each TE domain Controller to 1376 compute multiple paths, one (or more) for each end to end connection. 1378 There are also scenarios where it can be needed to request path 1379 computation for a set of paths in a synchronized fashion. 1381 One example could be computing multiple diverse paths. Computing a 1382 set of diverse paths in an unsynchronized fashion, leads to the 1383 possibility of not being able to satisfy the diversity requirement. 1384 In this case, it is preferable to compute a sub-optimal primary path 1385 for which a diversely routed secondary path exists. 1387 There are also scenarios where it is needed to request optimizing a 1388 set of paths using objective functions that apply to the whole set of 1389 paths, see [RFC5541], e.g. to minimize the sum of the costs of all 1390 the computed paths in the set. 1392 5. YANG data model for requesting Path Computation 1394 This document define a YANG RPC to request path computation as an 1395 "augmentation" of tunnel-rpc, defined in [I-D.ietf-teas-yang-te]. 1396 This model provides the RPC input attributes that are needed to 1397 request path computation and the RPC output attributes that are 1398 needed to report the computed paths. 1400 augment /te:tunnels-path-compute/te:input/te:path-compute-info: 1401 +-- path-request* [request-id] 1402 | +-- request-id uint32 1403 | ........... 1405 augment /te:tunnels-path-compute/te:output/te:path-compute-result: 1406 +--ro response* [response-id] 1407 +--ro response-id uint32 1408 +--ro computed-paths-properties 1409 | +--ro computed-path-properties* [k-index] 1410 | +--ro k-index uint8 1411 | +--ro path-properties 1412 | ........... 1414 This model extensively re-uses the grouping defined in 1415 [I-D.ietf-teas-yang-te] and [RFC8776] to ensure maximal syntax and 1416 semantics commonality. 1418 This YANG data model allows one RPC to include multiple path 1419 requests, each path request being identified by a request-id. 1420 Therefore, one RPC can return multiple responses, one for each path 1421 request, being identified by a response-id equal to the corresponding 1422 request-id. Each response reports one or more computed paths, as 1423 requested by the k-requested-paths attribute. By default, each 1424 response reports one computed path. 1426 5.1. Synchronization of multiple path computation requests 1428 The YANG data model permits the synchronization of a set of multiple 1429 path requests (identified by specific request-id) all related to a 1430 "svec" container emulating the syntax of the Synchronization VECtor 1431 (SVEC) PCEP object, defined in [RFC5440]. 1433 +-- synchronization* [] 1434 +-- svec 1435 | +-- relaxable? boolean 1436 | +-- disjointness? te-path-disjointness 1437 | +-- request-id-number* uint32 1438 +-- svec-constraints 1439 | +-- path-metric-bound* [metric-type] 1440 | +-- metric-type identityref 1441 | +-- upper-bound? uint64 1442 +-- path-srlgs-lists 1443 | +-- path-srlgs-list* [usage] 1444 | +-- usage identityref 1445 | +-- values* srlg 1446 +-- path-srlgs-names 1447 | +-- path-srlgs-name* [usage] 1448 | +-- usage identityref 1449 | +-- names* string 1450 +-- exclude-objects 1451 | +-- excludes* [] 1452 | +-- (type)? 1453 | +--:(numbered-node-hop) 1454 | | +-- numbered-node-hop 1455 | | +-- node-id te-node-id 1456 | | +-- hop-type? te-hop-type 1457 | +--:(numbered-link-hop) 1458 | | +-- numbered-link-hop 1459 | | +-- link-tp-id te-tp-id 1460 | | +-- hop-type? te-hop-type 1461 | | +-- direction? te-link-direction 1462 | +--:(unnumbered-link-hop) 1463 | | +-- unnumbered-link-hop 1464 | | +-- link-tp-id te-tp-id 1465 | | +-- node-id te-node-id 1466 | | +-- hop-type? te-hop-type 1467 | | +-- direction? te-link-direction 1468 | +--:(as-number) 1469 | | +-- as-number-hop 1470 | | +-- as-number inet:as-number 1471 | | +-- hop-type? te-hop-type 1472 | +--:(label) 1473 | +-- label-hop 1474 | +-- te-label 1475 | +-- (technology)? 1476 | | +--:(generic) 1477 | | +-- generic? 1478 | | rt-types:generalized-label 1479 | +-- direction? te-label-direction 1480 +-- optimizations 1481 +-- (algorithm)? 1482 +--:(metric) {te-types:path-optimization-metric}? 1483 | +-- optimization-metric* [metric-type] 1484 | +-- metric-type identityref 1485 | +-- weight? uint8 1486 +--:(objective-function) 1487 {te-types:path-optimization-objective- 1488 function}? 1489 +-- objective-function 1490 +-- objective-function-type? identityref 1492 The model, in addition to the metric types, defined in [RFC8776], 1493 which can be applied to each individual path request, supports also 1494 additional metric types, which apply to a set of synchronized 1495 requests, as referenced in [RFC5541]. These additional metric types 1496 are defined by the following YANG identities: 1498 * svec-metric-type: base YANG identity from which cumulative metric 1499 types identities are derived. 1501 * svec-metric-cumul-te: cumulative TE cost metric type, as defined 1502 in [RFC5541]. 1504 * svec-metric-cumul-igp: cumulative IGP cost metric type, as defined 1505 in [RFC5541]. 1507 * svec-metric-cumul-hop: cumulative Hop metric type, representing 1508 the cumulative version of the Hop metric type defined in 1509 [RFC8776]. 1511 * svec-metric-aggregate-bandwidth-consumption: aggregate bandwidth 1512 consumption metric type, as defined in [RFC5541]. 1514 * svec-metric-load-of-the-most-loaded-link: load of the most loaded 1515 link metric type, as defined in [RFC5541]. 1517 5.2. Returned metric values 1519 This YANG data model provides a way to return the values of the 1520 metrics computed by the path computation in the output of RPC, 1521 together with other important information (e.g. srlg, affinities, 1522 explicit route), emulating the syntax of the "C" flag of the "METRIC" 1523 PCEP object [RFC5440]: 1525 | +--ro path-properties 1526 | +--ro path-metric* [metric-type] 1527 | | +--ro metric-type identityref 1528 | | +--ro accumulative-value? uint64 1529 | +--ro path-affinities-values 1530 | | +--ro path-affinities-value* [usage] 1531 | | +--ro usage identityref 1532 | | +--ro value? admin-groups 1533 | +--ro path-affinity-names 1534 | | +--ro path-affinity-name* [usage] 1535 | | +--ro usage identityref 1536 | | +--ro affinity-name* [name] 1537 | | +--ro name string 1538 | +--ro path-srlgs-lists 1539 | | +--ro path-srlgs-list* [usage] 1540 | | +--ro usage identityref 1541 | | +--ro values* srlg 1542 | +--ro path-srlgs-names 1543 | | +--ro path-srlgs-name* [usage] 1544 | | +--ro usage identityref 1545 | | +--ro names* string 1546 | +--ro path-route-objects 1547 | ........... 1548 | +--ro te-bandwidth 1549 | | +--ro (technology)? 1550 | | +--:(generic) 1551 | | +--ro generic? te-bandwidth 1552 | +--ro disjointness-type? 1553 | te-types:te-path-disjointness 1555 It also allows the client to request which information (metrics, srlg 1556 and/or affinities) should be returned: 1558 | +-- request-id uint32 1559 | ........... 1560 | +-- requested-metrics* [metric-type] 1561 | | +-- metric-type identityref 1562 | +-- return-srlgs? boolean 1563 | +-- return-affinities? boolean 1564 | ........... 1566 This feature is essential for path computation in a multi-domain TE 1567 network as described in Section 2.2. In this case, the metrics 1568 returned by a path computation requested to a given underlying 1569 controller must be used by the client to compute the best end-to-end 1570 path. If they are missing, the client cannot compare different paths 1571 calculated by the underlying controllers and choose the best one for 1572 the optimal end-to-end (e2e) path. 1574 5.3. Multiple Paths Requests for the same TE tunnel 1576 The YANG data model allows including multiple requests for different 1577 paths intended to be used within the same tunnel or within different 1578 tunnels. 1580 When multiple requested paths are intended to be used within the same 1581 tunnel (e.g., requesting path computation for the primary and 1582 secondary paths of a protected tunnel), the set of attributes that 1583 are intended to be configured on per-tunnel basis rather than on per- 1584 path basis are common to all these path requests. These attributes 1585 includes both attributes which can be configured only a per-tunnel 1586 basis (e.g., tunnel-name, source/destination TTP, encoding and 1587 switching-type) as well attributes which can be configured both on a 1588 per-tunnel and on a per-path basis (e.g., the te-bandwidth or the 1589 associations). 1591 Therefore, a tunnel-attributes list is defined, within the path 1592 computation request RPC: 1594 +-- tunnel-attributes* [tunnel-name] 1595 | +-- tunnel-name string 1596 | +-- encoding? identityref 1597 | +-- switching-type? identityref 1598 | +-- source? te-types:te-node-id 1599 | +-- destination? te-types:te-node-id 1600 | +-- src-tunnel-tp-id? binary 1601 | +-- dst-tunnel-tp-id? binary 1602 | +-- bidirectional? boolean 1603 | +-- association-objects 1604 | ........... 1605 | +-- protection-type? identityref 1606 | +-- restoration-type? identityref 1607 | +-- restoration-scheme? identityref 1608 | +-- te-topology-identifier 1609 | | +-- provider-id? te-global-id 1610 | | +-- client-id? te-global-id 1611 | | +-- topology-id? te-topology-id 1612 | +-- te-bandwidth 1613 | | +-- (technology)? 1614 | | +--:(generic) 1615 | | +-- generic? te-bandwidth 1616 | +-- link-protection? identityref 1617 | +-- setup-priority? uint8 1618 | +-- hold-priority? uint8 1619 | +-- signaling-type? identityref 1620 | +-- hierarchy 1621 | +-- dependency-tunnels 1622 | ............ 1623 | +-- hierarchical-link 1624 | ............ 1626 The path requests that are intended to be used within the same tunnel 1627 should reference the same entry in the tunnel-attributes list. This 1628 allows: 1630 * avoiding repeating the same set of per-tunnel parameters on 1631 multiple requested paths; 1633 * the server to understand what attributes are intended to be 1634 configured on a per-tunnel basis (e.g., the te-bandwidth 1635 configured in the tunnel-attributes) and what attributes are 1636 intended to be configured on a per-path basis(e.g., the te- 1637 bandwidth configured in the path-request). This could be useful 1638 especially when the server also creates a TE tunnel instance 1639 within the operational datastore to report the computed paths, as 1640 described in Section 3.3.1: in this case, the tunnel-name is also 1641 used as the suggested name for that TE tunnel instance. 1643 The YANG data model allows also including requests for paths 1644 intended to modify existing tunnels (e.g., adding a protection 1645 path for an existing un-protected tunnel). In this case, the per- 1646 tunnel attributes are already provided in an existing TE tunnel 1647 instance and do not need to be re-configured in the path 1648 computation request RPC. Therefore, these requests should 1649 reference an existing TE tunnel instance. 1651 It is also possible to request computing paths without indicating 1652 in which tunnel they are intended to be used (e.g., in case of an 1653 unprotected tunnel). In this case, the per-tunnel attributes 1654 could be provided together with the per-path attributes in the 1655 path request, without using the tunnel-attributes list. 1657 The choices below are defined to distinguish the cases above: 1659 * whether the per-tunnel attributes are configured by reference 1660 (providing a leafref), to: 1662 - either a TE tunnel instance, if it exists; 1664 - or to an entry of the tunnel-attributes list, if the TE tunnel 1665 instance does not exist; 1667 * or by value, providing the set of tunnel attributes within the 1668 path request: 1670 | +-- (tunnel-attributes)? 1671 | | +--:(reference) 1672 | | | +-- tunnel-reference 1673 | | | +-- (tunnel-exist)? 1674 | | | | +--:(tunnel-ref) 1675 | | | | | +-- tunnel-ref te:tunnel-ref 1676 | | | | +--:(tunnel-attributes-ref) 1677 | | | | +-- tunnel-attributes-ref leafref 1678 | | | +-- path-name? string 1679 | | | +-- (path-role) 1680 | | | +--:(primary-path) 1681 | | | ........... 1682 | | +--:(value) 1683 | | +-- tunnel-name? string 1684 | | ........... 1685 | | +-- encoding? identityref 1686 | | +-- switching-type? identityref 1687 | | ........... 1689 5.3.1. Tunnel attributes specified by value 1691 The (value) case provides the set of attributes that are configured 1692 only on per-tunnel basis (e.g., tunnel-name, source/destination TTP, 1693 encoding and switching-type). 1695 In this case, it is assumed that the requested path will be the only 1696 path within a tunnel. 1698 If the requested path is a transit segment of a multi-domain end-to- 1699 end path, it can be of any type (primary, secondary, reverse-primary 1700 or reverse-secondary), as specified by the (path-role) choice: 1702 | | +-- (path-role)? 1703 | | | +--:(primary-path) 1704 | | | +--:(secondary-path) 1705 | | | | +-- secondary-path! 1706 | | | | +-- primary-path-name? string 1707 | | | +--:(primary-reverse-path) 1708 | | | | +-- primary-reverse-path! 1709 | | | | +-- primary-path-name? string 1710 | | | +--:(secondary-reverse-path) 1711 | | | +-- secondary-reverse-path 1712 | | | +-- primary-path-name? string 1713 | | | +-- primary-reverse-path-name? string 1714 | | ........... 1716 In all the other cases, the requested path can only be a primary 1717 path. 1719 The secondary-path, the primary-reverse-path and the secondary- 1720 reverse-path are presence container used to indicate the role of the 1721 path: by default, the path is assumed to be a primary path. 1723 They optionally can contain the name of the primary-path under which 1724 the requested path could be associated within the YANG tree structure 1725 defined in [I-D.ietf-teas-yang-te], which could be useful when the 1726 server also creates a TE tunnel instance within the operational 1727 datastore to report the computed paths, as described in 1728 Section 3.3.1: in this case, the tunnel-name and the path names are 1729 also used as the suggested name for that TE tunnel and path 1730 instances. 1732 5.3.2. Tunnel attributes specified by reference 1734 The (reference) case provides the information needed to associate 1735 multiple path requests that are intended to be used within the same 1736 tunnel. 1738 In order to indicate the role of the path being requested within the 1739 intended tunnel (e.g., primary or secondary path), the (path-role) 1740 choice is defined: 1742 | | | +-- (path-role) 1743 | | | +--:(primary-path) 1744 | | | | +-- primary-path! 1745 | | | | ........... 1746 | | | +--:(secondary-path) 1747 | | | | +-- secondary-path 1748 | | | | ........... 1749 | | | +--:(primary-reverse-path) 1750 | | | | +-- primary-reverse-path 1751 | | | | ........... 1752 | | | +--:(secondary-reverse-path) 1753 | | | +-- secondary-reverse-path 1754 | | | +-- preference? uint8 1755 | | | +-- protection-type? identityref 1756 | | | +-- restoration-type? identityref 1757 | | | +-- restoration-scheme? identityref 1758 | | | +-- primary-reverse-path-ref* [] 1759 | | | +-- (primary-reverse-path-exist)? 1760 | | | +--:(path-ref) 1761 | | | | +-- primary-path-ref leafref 1762 | | | +--:(path-request-ref) 1763 | | | +-- path-request-ref leafref 1765 The primary-path is a presence container used to indicate that the 1766 requested path is intended to be used as a primary path. It can also 1767 contain some attributes which are configured only on primary paths 1768 (e.g., the k-requested-paths). 1770 The secondary-path container indicates that the requested path is 1771 intended to be used as a secondary path and it contains at least 1772 references to one or more primary paths which can use it as a 1773 candidate secondary path: 1775 | | | | +-- secondary-path 1776 | | | | ........... 1777 | | | | +-- primary-path-ref* [] 1778 | | | | +-- (primary-path-exist)? 1779 | | | | +--:(path-ref) 1780 | | | | | +-- primary-path-ref leafref 1781 | | | | +--:(path-request-ref) 1782 | | | | +-- path-request-ref leafref 1784 A requested secondary path can reference any requested primary paths, 1785 and, in case they are intended to be used within an existing TE 1786 tunnel, it could also reference any existing primary-paths. 1788 The secondary-path container can also contain some attributes which 1789 are configured only on secondary paths (e.g., the protection-type). 1791 The primary-reverse-path container indicates that the requested path 1792 is intended to be used as a primary reverse path and it contains only 1793 the reference to the primary path which is intended to use it as a 1794 reverse path: 1796 | | | | +-- primary-reverse-path 1797 | | | | +-- (primary-path-exist)? 1798 | | | | +--:(path-ref) 1799 | | | | | +-- primary-path-ref leafref 1800 | | | | +--:(path-request-ref) 1801 | | | | +-- path-request-ref leafref 1803 A requested primary reverse path can reference either a requested 1804 primary path, or, in case it is intended to be used within an 1805 existing TE tunnel, an existing primary-path. 1807 The secondary-reverse-path container indicates that the requested 1808 path is intended to be used as a secondary reverse path and it 1809 contains at least references to one or more primary paths, whose 1810 primary reverse path can use it as a candidate secondary reverse 1811 path: 1813 | | | +-- secondary-reverse-path 1814 | | | ........... 1815 | | | +-- primary-reverse-path-ref* [] 1816 | | | +-- (primary-reverse-path-exist)? 1817 | | | +--:(path-ref) 1818 | | | | +-- primary-path-ref leafref 1819 | | | +--:(path-request-ref) 1820 | | | +-- path-request-ref leafref 1822 A requested secondary reverse path can reference any requested 1823 primary paths, and, in case they are intended to be used within an 1824 existing TE tunnel, it could reference also existing primary-paths. 1826 The secondary-reverse-path container can also contain some attributes 1827 which are configured only on secondary reverse paths (e.g., the 1828 protection-type). 1830 In case the requested path is a transit segment of a multi-domain 1831 end-to-end path, the primary-path may not be needed to be setup/ 1832 computed. However, the request for path computation of a secondary- 1833 path or a primary-reverse or of a secondary-reverse-path requires 1834 that the primary-path exists or it is requested within the same RPC 1835 request. In the latter case, the path request for the primary-path 1836 should have an empty ERO to indicate to the server that path 1837 computation is not requested and no path properties will therefore be 1838 returned in the RPC response. 1840 5.4. Multi-Layer Path Computation 1842 The models supports requesting multi-layer path computation following 1843 the same approach based on dependency tunnels, as defined in 1844 [I-D.ietf-teas-yang-te]. 1846 The tunnel-attributes of a given client-layer path request can 1847 reference server-layer TE tunnels which can already exist in the YANG 1848 datastore or be specified in the tunnel-attributes list, within the 1849 same RPC request: 1851 | +-- dependency-tunnels 1852 | | +-- dependency-tunnel* [name] 1853 | | | +-- name -> /te:te/tunnels/tunnel/name 1854 | | | +-- encoding? identityref 1855 | | | +-- switching-type? identityref 1856 | | +-- dependency-tunnel-attributes* [name] 1857 | | +-- name leafref 1858 | | +-- encoding? identityref 1859 | | +-- switching-type? identityref 1861 In a similar way as in [I-D.ietf-teas-yang-te], the server-layer 1862 tunnel attributes should provide the information of what would be the 1863 dynamic link in the client layer topology supported by that tunnel, 1864 if instantiated: 1866 | +-- hierarchical-link 1867 | +-- local-te-node-id? te-types:te-node-id 1868 | +-- local-te-link-tp-id? te-types:te-tp-id 1869 | +-- remote-te-node-id? te-types:te-node-id 1870 | +-- te-topology-identifier 1871 | +-- provider-id? te-global-id 1872 | +-- client-id? te-global-id 1873 | +-- topology-id? te-topology-id 1875 It is worth noting that since path computation RPC is stateless, the 1876 dynamic hierarchical links configured for the server-layer tunnel 1877 attributes cannot be used for path computation of any client-layer 1878 path unless explicitly referenced in the dependency-tunnel-attributes 1879 list within the same RPC request. 1881 6. YANG data model for TE path computation 1883 6.1. Tree diagram 1885 Figure 11 below shows the tree diagram of the YANG data model defined 1886 in module ietf-te-path-computation.yang, defined in Section 6.2. 1888 module: ietf-te-path-computation 1890 augment /te:tunnels-path-compute/te:input/te:path-compute-info: 1891 +-- path-request* [request-id] 1892 | +-- request-id uint32 1893 | +-- (tunnel-attributes)? 1894 | | +--:(reference) 1895 | | | +-- tunnel-reference 1896 | | | +-- (tunnel-exist)? 1897 | | | | +--:(tunnel-ref) 1898 | | | | | +-- tunnel-ref te:tunnel-ref 1899 | | | | +--:(tunnel-attributes-ref) 1900 | | | | +-- tunnel-attributes-ref leafref 1901 | | | +-- path-name? string 1902 | | | +-- (path-role) 1903 | | | +--:(primary-path) 1904 | | | | +-- primary-path! 1905 | | | | +-- preference? uint8 1906 | | | | +-- k-requested-paths? uint8 1907 | | | +--:(secondary-path) 1908 | | | | +-- secondary-path 1909 | | | | +-- preference? uint8 1910 | | | | +-- protection-type? identityref 1911 | | | | +-- restoration-type? identityref 1912 | | | | +-- restoration-scheme? identityref 1913 | | | | +-- primary-path-ref* [] 1914 | | | | +-- (primary-path-exist)? 1915 | | | | +--:(path-ref) 1916 | | | | | +-- primary-path-ref leafref 1917 | | | | +--:(path-request-ref) 1918 | | | | +-- path-request-ref leafref 1919 | | | +--:(primary-reverse-path) 1920 | | | | +-- primary-reverse-path 1921 | | | | +-- (primary-path-exist)? 1922 | | | | +--:(path-ref) 1923 | | | | | +-- primary-path-ref leafref 1924 | | | | +--:(path-request-ref) 1925 | | | | +-- path-request-ref leafref 1926 | | | +--:(secondary-reverse-path) 1927 | | | +-- secondary-reverse-path 1928 | | | +-- preference? uint8 1929 | | | +-- protection-type? identityref 1930 | | | +-- restoration-type? identityref 1931 | | | +-- restoration-scheme? identityref 1932 | | | +-- primary-reverse-path-ref* [] 1933 | | | +-- (primary-reverse-path-exist)? 1934 | | | +--:(path-ref) 1935 | | | | +-- primary-path-ref leafref 1936 | | | +--:(path-request-ref) 1937 | | | +-- path-request-ref leafref 1938 | | +--:(value) 1939 | | +-- tunnel-name? string 1940 | | +-- path-name? string 1941 | | +-- (path-role)? 1942 | | | +--:(primary-path) 1943 | | | +--:(secondary-path) 1944 | | | | +-- secondary-path! 1945 | | | | +-- primary-path-name? string 1946 | | | +--:(primary-reverse-path) 1947 | | | | +-- primary-reverse-path! 1948 | | | | +-- primary-path-name? string 1949 | | | +--:(secondary-reverse-path) 1950 | | | +-- secondary-reverse-path! 1951 | | | +-- primary-path-name? string 1952 | | | +-- primary-reverse-path-name? string 1953 | | +-- k-requested-paths? uint8 1954 | | +-- encoding? identityref 1955 | | +-- switching-type? identityref 1956 | | +-- source? te-types:te-node-id 1957 | | +-- destination? te-types:te-node-id 1958 | | +-- src-tunnel-tp-id? binary 1959 | | +-- dst-tunnel-tp-id? binary 1960 | | +-- bidirectional? boolean 1961 | | +-- te-topology-identifier 1962 | | +-- provider-id? te-global-id 1963 | | +-- client-id? te-global-id 1964 | | +-- topology-id? te-topology-id 1965 | +-- association-objects 1966 | | +-- association-object* [association-key] 1967 | | | +-- association-key string 1968 | | | +-- type? identityref 1969 | | | +-- id? uint16 1970 | | | +-- source 1971 | | | +-- id? te-gen-node-id 1972 | | | +-- type? enumeration 1973 | | +-- association-object-extended* [association-key] 1974 | | +-- association-key string 1975 | | +-- type? identityref 1976 | | +-- id? uint16 1977 | | +-- source 1978 | | | +-- id? te-gen-node-id 1979 | | | +-- type? enumeration 1980 | | +-- global-source? uint32 1981 | | +-- extended-id? yang:hex-string 1982 | +-- optimizations 1983 | | +-- (algorithm)? 1984 | | +--:(metric) {path-optimization-metric}? 1985 | | | +-- optimization-metric* [metric-type] 1986 | | | | +-- metric-type identityref 1987 | | | | +-- weight? uint8 1988 | | | | +-- explicit-route-exclude-objects 1989 | | | | | +-- route-object-exclude-object* [index] 1990 | | | | | +-- index uint32 1991 | | | | | +-- (type)? 1992 | | | | | +--:(numbered-node-hop) 1993 | | | | | | +-- numbered-node-hop 1994 | | | | | | +-- node-id te-node-id 1995 | | | | | | +-- hop-type? te-hop-type 1996 | | | | | +--:(numbered-link-hop) 1997 | | | | | | +-- numbered-link-hop 1998 | | | | | | +-- link-tp-id te-tp-id 1999 | | | | | | +-- hop-type? te-hop-type 2000 | | | | | | +-- direction? te-link-direction 2001 | | | | | +--:(unnumbered-link-hop) 2002 | | | | | | +-- unnumbered-link-hop 2003 | | | | | | +-- link-tp-id te-tp-id 2004 | | | | | | +-- node-id te-node-id 2005 | | | | | | +-- hop-type? te-hop-type 2006 | | | | | | +-- direction? te-link-direction 2007 | | | | | +--:(as-number) 2008 | | | | | | +-- as-number-hop 2009 | | | | | | +-- as-number inet:as-number 2010 | | | | | | +-- hop-type? te-hop-type 2011 | | | | | +--:(label) 2012 | | | | | | +-- label-hop 2013 | | | | | | +-- te-label 2014 | | | | | | +-- (technology)? 2015 | | | | | | | +--:(generic) 2016 | | | | | | | +-- generic? 2017 | | | | | | | rt-types:generalized-label 2018 | | | | | | +-- direction? 2019 | | | | | | te-label-direction 2020 | | | | | +--:(srlg) 2021 | | | | | +-- srlg 2022 | | | | | +-- srlg? uint32 2023 | | | | +-- explicit-route-include-objects 2024 | | | | +-- route-object-include-object* [index] 2025 | | | | +-- index uint32 2026 | | | | +-- (type)? 2027 | | | | +--:(numbered-node-hop) 2028 | | | | | +-- numbered-node-hop 2029 | | | | | +-- node-id te-node-id 2030 | | | | | +-- hop-type? te-hop-type 2031 | | | | +--:(numbered-link-hop) 2032 | | | | | +-- numbered-link-hop 2033 | | | | | +-- link-tp-id te-tp-id 2034 | | | | | +-- hop-type? te-hop-type 2035 | | | | | +-- direction? te-link-direction 2036 | | | | +--:(unnumbered-link-hop) 2037 | | | | | +-- unnumbered-link-hop 2038 | | | | | +-- link-tp-id te-tp-id 2039 | | | | | +-- node-id te-node-id 2040 | | | | | +-- hop-type? te-hop-type 2041 | | | | | +-- direction? te-link-direction 2042 | | | | +--:(as-number) 2043 | | | | | +-- as-number-hop 2044 | | | | | +-- as-number inet:as-number 2045 | | | | | +-- hop-type? te-hop-type 2046 | | | | +--:(label) 2047 | | | | +-- label-hop 2048 | | | | +-- te-label 2049 | | | | +-- (technology)? 2050 | | | | | +--:(generic) 2051 | | | | | +-- generic? 2052 | | | | | rt-types:generalized-label 2053 | | | | +-- direction? 2054 | | | | te-label-direction 2055 | | | +-- tiebreakers 2056 | | | +-- tiebreaker* [tiebreaker-type] 2057 | | | +-- tiebreaker-type identityref 2058 | | +--:(objective-function) 2059 | | {path-optimization-objective-function}? 2060 | | +-- objective-function 2061 | | +-- objective-function-type? identityref 2062 | +-- named-path-constraint? leafref 2063 | | {te-types:named-path-constraints}? 2064 | +-- te-bandwidth 2065 | | +-- (technology)? 2066 | | +--:(generic) 2067 | | +-- generic? te-bandwidth 2068 | +-- link-protection? identityref 2069 | +-- setup-priority? uint8 2070 | +-- hold-priority? uint8 2071 | +-- signaling-type? identityref 2072 | +-- path-metric-bounds 2073 | | +-- path-metric-bound* [metric-type] 2074 | | +-- metric-type identityref 2075 | | +-- upper-bound? uint64 2076 | +-- path-affinities-values 2077 | | +-- path-affinities-value* [usage] 2078 | | +-- usage identityref 2079 | | +-- value? admin-groups 2080 | +-- path-affinity-names 2081 | | +-- path-affinity-name* [usage] 2082 | | +-- usage identityref 2083 | | +-- affinity-name* [name] 2084 | | +-- name string 2085 | +-- path-srlgs-lists 2086 | | +-- path-srlgs-list* [usage] 2087 | | +-- usage identityref 2088 | | +-- values* srlg 2089 | +-- path-srlgs-names 2090 | | +-- path-srlgs-name* [usage] 2091 | | +-- usage identityref 2092 | | +-- names* string 2093 | +-- disjointness? te-path-disjointness 2094 | +-- explicit-route-objects-always 2095 | | +-- route-object-exclude-always* [index] 2096 | | | +-- index uint32 2097 | | | +-- (type)? 2098 | | | +--:(numbered-node-hop) 2099 | | | | +-- numbered-node-hop 2100 | | | | +-- node-id te-node-id 2101 | | | | +-- hop-type? te-hop-type 2102 | | | +--:(numbered-link-hop) 2103 | | | | +-- numbered-link-hop 2104 | | | | +-- link-tp-id te-tp-id 2105 | | | | +-- hop-type? te-hop-type 2106 | | | | +-- direction? te-link-direction 2107 | | | +--:(unnumbered-link-hop) 2108 | | | | +-- unnumbered-link-hop 2109 | | | | +-- link-tp-id te-tp-id 2110 | | | | +-- node-id te-node-id 2111 | | | | +-- hop-type? te-hop-type 2112 | | | | +-- direction? te-link-direction 2113 | | | +--:(as-number) 2114 | | | | +-- as-number-hop 2115 | | | | +-- as-number inet:as-number 2116 | | | | +-- hop-type? te-hop-type 2117 | | | +--:(label) 2118 | | | +-- label-hop 2119 | | | +-- te-label 2120 | | | +-- (technology)? 2121 | | | | +--:(generic) 2122 | | | | +-- generic? 2123 | | | | rt-types:generalized-label 2124 | | | +-- direction? te-label-direction 2125 | | +-- route-object-include-exclude* [index] 2126 | | +-- explicit-route-usage? identityref 2127 | | +-- index uint32 2128 | | +-- (type)? 2129 | | +--:(numbered-node-hop) 2130 | | | +-- numbered-node-hop 2131 | | | +-- node-id te-node-id 2132 | | | +-- hop-type? te-hop-type 2133 | | +--:(numbered-link-hop) 2134 | | | +-- numbered-link-hop 2135 | | | +-- link-tp-id te-tp-id 2136 | | | +-- hop-type? te-hop-type 2137 | | | +-- direction? te-link-direction 2138 | | +--:(unnumbered-link-hop) 2139 | | | +-- unnumbered-link-hop 2140 | | | +-- link-tp-id te-tp-id 2141 | | | +-- node-id te-node-id 2142 | | | +-- hop-type? te-hop-type 2143 | | | +-- direction? te-link-direction 2144 | | +--:(as-number) 2145 | | | +-- as-number-hop 2146 | | | +-- as-number inet:as-number 2147 | | | +-- hop-type? te-hop-type 2148 | | +--:(label) 2149 | | | +-- label-hop 2150 | | | +-- te-label 2151 | | | +-- (technology)? 2152 | | | | +--:(generic) 2153 | | | | +-- generic? 2154 | | | | rt-types:generalized-label 2155 | | | +-- direction? te-label-direction 2156 | | +--:(srlg) 2157 | | +-- srlg 2158 | | +-- srlg? uint32 2159 | +-- path-in-segment! 2160 | | +-- label-restrictions 2161 | | +-- label-restriction* [index] 2162 | | +-- restriction? enumeration 2163 | | +-- index uint32 2164 | | +-- label-start 2165 | | | +-- te-label 2166 | | | +-- (technology)? 2167 | | | | +--:(generic) 2168 | | | | +-- generic? rt-types:generalized-label 2169 | | | +-- direction? te-label-direction 2170 | | +-- label-end 2171 | | | +-- te-label 2172 | | | +-- (technology)? 2173 | | | | +--:(generic) 2174 | | | | +-- generic? rt-types:generalized-label 2175 | | | +-- direction? te-label-direction 2176 | | +-- label-step 2177 | | | +-- (technology)? 2178 | | | +--:(generic) 2179 | | | +-- generic? int32 2180 | | +-- range-bitmap? yang:hex-string 2181 | +-- path-out-segment! 2182 | | +-- label-restrictions 2183 | | +-- label-restriction* [index] 2184 | | +-- restriction? enumeration 2185 | | +-- index uint32 2186 | | +-- label-start 2187 | | | +-- te-label 2188 | | | +-- (technology)? 2189 | | | | +--:(generic) 2190 | | | | +-- generic? rt-types:generalized-label 2191 | | | +-- direction? te-label-direction 2192 | | +-- label-end 2193 | | | +-- te-label 2194 | | | +-- (technology)? 2195 | | | | +--:(generic) 2196 | | | | +-- generic? rt-types:generalized-label 2197 | | | +-- direction? te-label-direction 2198 | | +-- label-step 2199 | | | +-- (technology)? 2200 | | | +--:(generic) 2201 | | | +-- generic? int32 2202 | | +-- range-bitmap? yang:hex-string 2203 | +-- requested-metrics* [metric-type] 2204 | | +-- metric-type identityref 2205 | +-- return-srlgs? boolean 2206 | +-- return-affinities? boolean 2207 | +-- requested-state! 2208 | +-- timer? uint16 2209 | +-- transaction-id? string 2210 +-- tunnel-attributes* [tunnel-name] 2211 | +-- tunnel-name string 2212 | +-- encoding? identityref 2213 | +-- switching-type? identityref 2214 | +-- source? te-types:te-node-id 2215 | +-- destination? te-types:te-node-id 2216 | +-- src-tunnel-tp-id? binary 2217 | +-- dst-tunnel-tp-id? binary 2218 | +-- bidirectional? boolean 2219 | +-- association-objects 2220 | | +-- association-object* [association-key] 2221 | | | +-- association-key string 2222 | | | +-- type? identityref 2223 | | | +-- id? uint16 2224 | | | +-- source 2225 | | | +-- id? te-gen-node-id 2226 | | | +-- type? enumeration 2227 | | +-- association-object-extended* [association-key] 2228 | | +-- association-key string 2229 | | +-- type? identityref 2230 | | +-- id? uint16 2231 | | +-- source 2232 | | | +-- id? te-gen-node-id 2233 | | | +-- type? enumeration 2234 | | +-- global-source? uint32 2235 | | +-- extended-id? yang:hex-string 2236 | +-- protection-type? identityref 2237 | +-- restoration-type? identityref 2238 | +-- restoration-scheme? identityref 2239 | +-- te-topology-identifier 2240 | | +-- provider-id? te-global-id 2241 | | +-- client-id? te-global-id 2242 | | +-- topology-id? te-topology-id 2243 | +-- te-bandwidth 2244 | | +-- (technology)? 2245 | | +--:(generic) 2246 | | +-- generic? te-bandwidth 2247 | +-- link-protection? identityref 2248 | +-- setup-priority? uint8 2249 | +-- hold-priority? uint8 2250 | +-- signaling-type? identityref 2251 | +-- hierarchy 2252 | +-- dependency-tunnels 2253 | | +-- dependency-tunnel* [name] 2254 | | | +-- name -> /te:te/tunnels/tunnel/name 2255 | | | +-- encoding? identityref 2256 | | | +-- switching-type? identityref 2257 | | +-- dependency-tunnel-attributes* [name] 2258 | | +-- name leafref 2259 | | +-- encoding? identityref 2260 | | +-- switching-type? identityref 2261 | +-- hierarchical-link 2262 | +-- local-te-node-id? te-types:te-node-id 2263 | +-- local-te-link-tp-id? te-types:te-tp-id 2264 | +-- remote-te-node-id? te-types:te-node-id 2265 | +-- te-topology-identifier 2266 | +-- provider-id? te-global-id 2267 | +-- client-id? te-global-id 2268 | +-- topology-id? te-topology-id 2269 +-- synchronization* [] 2270 +-- svec 2271 | +-- relaxable? boolean 2272 | +-- disjointness? te-path-disjointness 2273 | +-- request-id-number* uint32 2274 +-- svec-constraints 2275 | +-- path-metric-bound* [metric-type] 2276 | +-- metric-type identityref 2277 | +-- upper-bound? uint64 2278 +-- path-srlgs-lists 2279 | +-- path-srlgs-list* [usage] 2280 | +-- usage identityref 2281 | +-- values* srlg 2282 +-- path-srlgs-names 2283 | +-- path-srlgs-name* [usage] 2284 | +-- usage identityref 2285 | +-- names* string 2286 +-- exclude-objects 2287 | +-- excludes* [] 2288 | +-- (type)? 2289 | +--:(numbered-node-hop) 2290 | | +-- numbered-node-hop 2291 | | +-- node-id te-node-id 2292 | | +-- hop-type? te-hop-type 2293 | +--:(numbered-link-hop) 2294 | | +-- numbered-link-hop 2295 | | +-- link-tp-id te-tp-id 2296 | | +-- hop-type? te-hop-type 2297 | | +-- direction? te-link-direction 2298 | +--:(unnumbered-link-hop) 2299 | | +-- unnumbered-link-hop 2300 | | +-- link-tp-id te-tp-id 2301 | | +-- node-id te-node-id 2302 | | +-- hop-type? te-hop-type 2303 | | +-- direction? te-link-direction 2304 | +--:(as-number) 2305 | | +-- as-number-hop 2306 | | +-- as-number inet:as-number 2307 | | +-- hop-type? te-hop-type 2308 | +--:(label) 2309 | +-- label-hop 2310 | +-- te-label 2311 | +-- (technology)? 2312 | | +--:(generic) 2313 | | +-- generic? 2314 | | rt-types:generalized-label 2315 | +-- direction? te-label-direction 2316 +-- optimizations 2317 +-- (algorithm)? 2318 +--:(metric) {te-types:path-optimization-metric}? 2319 | +-- optimization-metric* [metric-type] 2320 | +-- metric-type identityref 2321 | +-- weight? uint8 2322 +--:(objective-function) 2323 {te-types:path-optimization-objective-function}? 2324 +-- objective-function 2325 +-- objective-function-type? identityref 2326 augment /te:tunnels-path-compute/te:output/te:path-compute-result: 2327 +--ro response* [response-id] 2328 +--ro response-id uint32 2329 +--ro computed-paths-properties 2330 | +--ro computed-path-properties* [k-index] 2331 | +--ro k-index uint8 2332 | +--ro path-properties 2333 | +--ro path-metric* [metric-type] 2334 | | +--ro metric-type identityref 2335 | | +--ro accumulative-value? uint64 2336 | +--ro path-affinities-values 2337 | | +--ro path-affinities-value* [usage] 2338 | | +--ro usage identityref 2339 | | +--ro value? admin-groups 2340 | +--ro path-affinity-names 2341 | | +--ro path-affinity-name* [usage] 2342 | | +--ro usage identityref 2343 | | +--ro affinity-name* [name] 2344 | | +--ro name string 2345 | +--ro path-srlgs-lists 2346 | | +--ro path-srlgs-list* [usage] 2347 | | +--ro usage identityref 2348 | | +--ro values* srlg 2349 | +--ro path-srlgs-names 2350 | | +--ro path-srlgs-name* [usage] 2351 | | +--ro usage identityref 2352 | | +--ro names* string 2353 | +--ro path-route-objects 2354 | | +--ro path-route-object* [index] 2355 | | +--ro index uint32 2356 | | +--ro (type)? 2357 | | +--:(numbered-node-hop) 2358 | | | +--ro numbered-node-hop 2359 | | | +--ro node-id te-node-id 2360 | | | +--ro hop-type? te-hop-type 2361 | | +--:(numbered-link-hop) 2362 | | | +--ro numbered-link-hop 2363 | | | +--ro link-tp-id te-tp-id 2364 | | | +--ro hop-type? te-hop-type 2365 | | | +--ro direction? te-link-direction 2366 | | +--:(unnumbered-link-hop) 2367 | | | +--ro unnumbered-link-hop 2368 | | | +--ro link-tp-id te-tp-id 2369 | | | +--ro node-id te-node-id 2370 | | | +--ro hop-type? te-hop-type 2371 | | | +--ro direction? te-link-direction 2372 | | +--:(as-number) 2373 | | | +--ro as-number-hop 2374 | | | +--ro as-number inet:as-number 2375 | | | +--ro hop-type? te-hop-type 2376 | | +--:(label) 2377 | | +--ro label-hop 2378 | | +--ro te-label 2379 | | +--ro (technology)? 2380 | | | +--:(generic) 2381 | | | +--ro generic? 2382 | | | rt-types:generalized-label 2383 | | +--ro direction? 2384 | | te-label-direction 2385 | +--ro te-bandwidth 2386 | | +--ro (technology)? 2387 | | +--:(generic) 2388 | | +--ro generic? te-bandwidth 2389 | +--ro disjointness-type? 2390 | te-types:te-path-disjointness 2391 +--ro computed-path-error-infos 2392 | +--ro computed-path-error-info* [] 2393 | +--ro error-description? string 2394 | +--ro error-timestamp? yang:date-and-time 2395 | +--ro error-reason? identityref 2396 +--ro tunnel-ref? te:tunnel-ref 2397 +--ro (path-role)? 2398 +--:(primary) 2399 | +--ro primary-path-ref? leafref 2400 +--:(primary-reverse) 2401 | +--ro primary-reverse-path-ref? leafref 2402 +--:(secondary) 2403 | +--ro secondary-path-ref? leafref 2404 +--:(secondary-reverse) 2405 +--ro secondary-reverse-path-ref? leafref 2406 augment /te:tunnels-actions/te:input/te:tunnel-info/te:filter-type: 2407 +--:(path-compute-transactions) 2408 +-- path-compute-transaction-id* string 2409 augment /te:tunnels-actions/te:output: 2410 +--ro path-computed-delete-result 2411 +--ro path-compute-transaction-id* string 2413 Figure 11: TE path computation tree diagram 2415 6.2. YANG module 2417 file "ietf-te-path-computation@2022-01-24.yang" 2418 module ietf-te-path-computation { 2419 yang-version 1.1; 2420 namespace "urn:ietf:params:xml:ns:yang:ietf-te-path-computation"; 2421 prefix te-pc; 2423 import ietf-te { 2424 prefix te; 2425 reference 2426 "RFCYYYY: A YANG Data Model for Traffic Engineering Tunnels 2427 and Interfaces"; 2428 } 2430 /* Note: The RFC Editor will replace YYYY with the number assigned 2431 to the RFC once draft-ietf-teas-yang-te becomes an RFC.*/ 2433 import ietf-te-types { 2434 prefix te-types; 2435 reference 2436 "RFC8776: Common YANG Data Types for Traffic Engineering."; 2437 } 2439 organization 2440 "Traffic Engineering Architecture and Signaling (TEAS) 2441 Working Group"; 2442 contact 2443 "WG Web: 2444 WG List: 2446 Editor: Italo Busi 2447 2449 Editor: Sergio Belotti 2450 2452 Editor: Victor Lopez 2453 2455 Editor: Oscar Gonzalez de Dios 2456 2458 Editor: Anurag Sharma 2459 2461 Editor: Yan Shi 2462 2464 Editor: Ricard Vilalta 2465 2467 Editor: Karthik Sethuraman 2468 2470 Editor: Michael Scharf 2471 2473 Editor: Daniele Ceccarelli 2474 2476 "; 2477 description 2478 "This module defines a YANG data model for requesting Traffic 2479 Engineering (TE) path computation. The YANG model defined in 2480 this document is based on RPCs augmenting the RPCs defined in 2481 the generic TE module (ietf-te). 2482 The model fully conforms to the 2483 Network Management Datastore Architecture (NMDA). 2485 Copyright (c) 2022 IETF Trust and the persons 2486 identified as authors of the code. All rights reserved. 2488 Redistribution and use in source and binary forms, with or 2489 without modification, is permitted pursuant to, and subject 2490 to the license terms contained in, the Simplified BSD License 2491 set forth in Section 4.c of the IETF Trust's Legal Provisions 2493 Relating to IETF Documents 2494 (http://trustee.ietf.org/license-info). 2496 This version of this YANG module is part of RFC XXXX; see 2497 the RFC itself for full legal notices."; 2499 // RFC Ed.: replace XXXX with actual RFC number and remove 2500 // this note 2501 // replace the revision date with the module publication date 2502 // the format is (year-month-day) 2504 revision 2022-01-24 { 2505 description 2506 "Initial revision"; 2507 reference 2508 "RFC XXXX: A YANG Data Model for requesting path computation"; 2509 } 2511 // RFC Ed.: replace XXXX with actual RFC number and remove 2512 // this note 2514 /* 2515 * Identities 2516 */ 2518 identity svec-metric-type { 2519 description 2520 "Base identity for SVEC metric type."; 2521 reference 2522 "RFC5541: Encoding of Objective Functions in the Path 2523 Computation Element Communication Protocol (PCEP)."; 2524 } 2526 identity svec-metric-cumul-te { 2527 base svec-metric-type; 2528 description 2529 "Cumulative TE cost."; 2530 reference 2531 "RFC5541: Encoding of Objective Functions in the Path 2532 Computation Element Communication Protocol (PCEP)."; 2533 } 2535 identity svec-metric-cumul-igp { 2536 base svec-metric-type; 2537 description 2538 "Cumulative IGP cost."; 2539 reference 2540 "RFC5541: Encoding of Objective Functions in the Path 2541 Computation Element Communication Protocol (PCEP)."; 2542 } 2544 identity svec-metric-cumul-hop { 2545 base svec-metric-type; 2546 description 2547 "Cumulative Hop path metric."; 2549 reference 2550 "RFC8776: Common YANG Data Types for Traffic Engineering."; 2551 } 2553 identity svec-metric-aggregate-bandwidth-consumption { 2554 base svec-metric-type; 2555 description 2556 "Aggregate bandwidth consumption."; 2557 reference 2558 "RFC5541: Encoding of Objective Functions in the Path 2559 Computation Element Communication Protocol (PCEP)."; 2560 } 2562 identity svec-metric-load-of-the-most-loaded-link { 2563 base svec-metric-type; 2564 description 2565 "Load of the most loaded link."; 2566 reference 2567 "RFC5541: Encoding of Objective Functions in the Path 2568 Computation Element Communication Protocol (PCEP)."; 2569 } 2571 identity tunnel-action-path-compute-delete { 2572 base te:tunnel-actions-type; 2573 description 2574 "Action type to delete the transient states 2575 of computed paths, as described in section 3.3.1 of 2576 RFC XXXX."; 2577 reference 2578 "RFC XXXX: A YANG Data Model for requesting path computation"; 2579 } 2581 /* 2582 * Groupings 2583 */ 2585 grouping protection-restoration-properties { 2586 description 2587 "This grouping defines the restoration and protection types 2588 for a path in the path computation request."; 2589 leaf protection-type { 2590 type identityref { 2591 base te-types:lsp-protection-type; 2592 } 2593 default "te-types:lsp-protection-unprotected"; 2594 description 2595 "LSP protection type."; 2596 } 2597 leaf restoration-type { 2598 type identityref { 2599 base te-types:lsp-restoration-type; 2600 } 2601 default "te-types:lsp-restoration-restore-any"; 2602 description 2603 "LSP restoration type."; 2604 } 2605 leaf restoration-scheme { 2606 type identityref { 2607 base te-types:restoration-scheme-type; 2608 } 2609 default "te-types:restoration-scheme-preconfigured"; 2610 description 2611 "LSP restoration scheme."; 2612 } 2613 } // grouping protection-restoration-properties 2615 grouping requested-info { 2616 description 2617 "This grouping defines the information (e.g., metrics) 2618 which is requested, in the path computation request, to be 2619 returned in the path computation response."; 2620 list requested-metrics { 2621 key "metric-type"; 2622 description 2623 "The list of the requested metrics. 2624 The metrics listed here must be returned in the response. 2625 Returning other metrics in the response is optional."; 2626 leaf metric-type { 2627 type identityref { 2628 base te-types:path-metric-type; 2629 } 2630 description 2631 "The metric that must be returned in the response"; 2632 } 2633 } 2634 leaf return-srlgs { 2635 type boolean; 2636 default "false"; 2637 description 2638 "If true, path srlgs must be returned in the response. 2639 If false, returning path srlgs in the response optional."; 2640 } 2641 leaf return-affinities { 2642 type boolean; 2643 default "false"; 2644 description 2645 "If true, path affinities must be returned in the response. 2646 If false, returning path affinities in the response is 2647 optional."; 2648 } 2649 } // grouping requested-info 2651 grouping requested-state { 2652 description 2653 "Configuration for the transient state used 2654 to report the computed path"; 2655 container requested-state { 2656 presence 2657 "Request temporary reporting of the computed path state"; 2658 description 2659 "Configures attributes for the temporary reporting of the 2660 computed path state (e.g., expiration timer)."; 2661 leaf timer { 2662 type uint16; 2663 units "minutes"; 2664 default "10"; 2665 description 2666 "The timeout after which the transient state reporting 2667 the computed path should be removed."; 2668 } 2669 leaf transaction-id { 2670 type string; 2671 description 2672 "The transaction-id associated with this path computation 2673 to be used for fast deletion of the transient states 2674 associated with multiple path computations. 2676 This transaction-id can be used to explicitly delete all 2677 the transient states of all the computed paths associated 2678 with the same transaction-id. 2680 When one path associated with a transaction-id is setup, 2681 the transient states of all the other computed paths 2682 with the same transaction-id are automatically removed. 2684 If not specified, the transient state is removed only 2685 when the timer expires (when the timer is specified) 2686 or not created at all (stateless path computation, 2687 when the timer is not specified)."; 2688 } 2689 } 2690 } // grouping requested-state 2692 grouping reported-state { 2693 description 2694 "This grouping defines the information, returned in the path 2695 computation response, reporting the transient state related 2696 to the computed path"; 2697 leaf tunnel-ref { 2698 type te:tunnel-ref; 2699 description 2700 " 2701 Reference to the tunnel that reports the transient state 2702 of the computed path. 2704 If no transient state is created, this attribute is 2705 omitted. 2706 "; 2707 } 2708 choice path-role { 2709 description 2710 "The transient state of the computed path can be reported 2711 as a primary, primary-reverse, secondary or 2712 a secondary-reverse path of a te-tunnel"; 2713 case primary { 2714 leaf primary-path-ref { 2715 type leafref { 2716 path "/te:te/te:tunnels/" 2717 + "te:tunnel[te:name=current()/../tunnel-ref]/" 2718 + "te:primary-paths/te:primary-path/" 2719 + "te:name"; 2720 } 2721 must '../tunnel-ref' { 2722 description 2723 "The primary-path name can only be reported 2724 if also the tunnel name is reported."; 2725 } 2726 description 2727 " 2728 Reference to the primary-path that reports 2729 the transient state of the computed path. 2731 If no transient state is created, 2732 this attribute is omitted. 2733 "; 2734 } 2735 } // case primary 2736 case primary-reverse { 2737 leaf primary-reverse-path-ref { 2738 type leafref { 2739 path "/te:te/te:tunnels/" 2740 + "te:tunnel[te:name=current()/../tunnel-ref]/" 2741 + "te:primary-paths/te:primary-path/" 2742 + "te:name"; 2743 } 2744 must '../tunnel-ref' { 2745 description 2746 "The primary-reverse-path name can only be reported 2747 if also the tunnel name is reported."; 2748 } 2749 description 2750 " 2751 Reference to the primary-reverse-path that reports 2752 the transient state of the computed path. 2754 If no transient state is created, 2755 this attribute is omitted. 2756 "; 2757 } 2758 } // case primary-reverse 2759 case secondary { 2760 leaf secondary-path-ref { 2761 type leafref { 2762 path "/te:te/te:tunnels/" 2763 + "te:tunnel[te:name=current()/../tunnel-ref]/" 2764 + "te:secondary-paths/te:secondary-path/" 2765 + "te:name"; 2766 } 2767 must '../tunnel-ref' { 2768 description 2769 "The secondary-path name can only be reported 2770 if also the tunnel name is reported."; 2771 } 2772 description 2773 " 2774 Reference to the secondary-path that reports 2775 the transient state of the computed path. 2777 If no transient state is created, 2778 this attribute is omitted. 2779 "; 2780 } 2781 } // case secondary 2782 case secondary-reverse { 2783 leaf secondary-reverse-path-ref { 2784 type leafref { 2785 path "/te:te/te:tunnels/" 2786 + "te:tunnel[te:name=current()/../tunnel-ref]/" 2787 + "te:secondary-reverse-paths/" 2788 + "te:secondary-reverse-path/te:name"; 2790 } 2791 must '../tunnel-ref' { 2792 description 2793 "The secondary-reverse-path name can only be reported 2794 if also the tunnel name is reported."; 2795 } 2796 description 2797 " 2798 Reference to the secondary-reverse-path that reports 2799 the transient state of the computed path. 2801 If no transient state is created, 2802 this attribute is omitted. 2803 "; 2804 } 2805 } // case secondary 2806 } // choice path 2807 } // grouping reported-state 2809 grouping synchronization-constraints { 2810 description 2811 "Global constraints applicable to synchronized path 2812 computation requests."; 2813 container svec-constraints { 2814 description 2815 "global svec constraints"; 2816 list path-metric-bound { 2817 key "metric-type"; 2818 description 2819 "list of bound metrics"; 2820 leaf metric-type { 2821 type identityref { 2822 base svec-metric-type; 2823 } 2824 description 2825 "SVEC metric type."; 2826 reference 2827 "RFC5541: Encoding of Objective Functions in the Path 2828 Computation Element Communication Protocol (PCEP)."; 2829 } 2830 leaf upper-bound { 2831 type uint64; 2832 description 2833 "Upper bound on SVEC metric"; 2834 } 2835 } 2836 } 2837 uses te-types:generic-path-srlgs; 2838 container exclude-objects { 2839 description 2840 "Resources to be excluded"; 2841 list excludes { 2842 description 2843 "List of Explicit Route Objects to always exclude 2844 from synchronized path computation"; 2845 uses te-types:explicit-route-hop; 2846 } 2847 } 2848 } // grouping synchronization-constraints 2850 grouping synchronization-optimization { 2851 description 2852 "Optimizations applicable to synchronized path 2853 computation requests."; 2854 container optimizations { 2855 description 2856 "The objective function container that includes attributes 2857 to impose when computing a synchronized set of paths"; 2858 choice algorithm { 2859 description 2860 "Optimizations algorithm."; 2861 case metric { 2862 if-feature "te-types:path-optimization-metric"; 2863 list optimization-metric { 2864 key "metric-type"; 2865 description 2866 "svec path metric type"; 2867 leaf metric-type { 2868 type identityref { 2869 base svec-metric-type; 2870 } 2871 description 2872 "TE path metric type usable for computing a set of 2873 synchronized requests"; 2874 } 2875 leaf weight { 2876 type uint8; 2877 description 2878 "Metric normalization weight"; 2879 } 2880 } 2881 } 2882 case objective-function { 2883 if-feature 2884 "te-types:path-optimization-objective-function"; 2885 container objective-function { 2886 description 2887 "The objective function container that includes 2888 attributes to impose when computing a TE path"; 2889 leaf objective-function-type { 2890 type identityref { 2891 base te-types:objective-function-type; 2892 } 2893 default "te-types:of-minimize-cost-path"; 2894 description 2895 "Objective function entry"; 2896 } 2897 } 2898 } 2899 } 2900 } 2901 } // grouping synchronization-optimization 2903 grouping synchronization-info { 2904 description 2905 "Information for synchronized path computation requests."; 2906 list synchronization { 2907 description 2908 "List of Synchronization VECtors."; 2909 container svec { 2910 description 2911 "Synchronization VECtor"; 2912 leaf relaxable { 2913 type boolean; 2914 default "true"; 2915 description 2916 "If this leaf is true, path computation process is 2917 free to ignore svec content. 2918 Otherwise, it must take into account this svec."; 2919 } 2920 uses te-types:generic-path-disjointness; 2921 leaf-list request-id-number { 2922 type uint32; 2923 description 2924 "This list reports the set of path computation 2925 requests that must be synchronized."; 2926 } 2927 } 2928 uses synchronization-constraints; 2929 uses synchronization-optimization; 2930 } 2931 } // grouping synchronization-info 2933 /* 2934 * Augment TE RPCs 2935 */ 2937 augment "/te:tunnels-path-compute/te:input/te:path-compute-info" { 2938 description 2939 "Path Computation RPC input"; 2940 list path-request { 2941 key "request-id"; 2942 description 2943 "The list of the requested paths to be computed"; 2944 leaf request-id { 2945 type uint32; 2946 mandatory true; 2947 description 2948 "Each path computation request is uniquely identified 2949 within the RPC request by the request-id-number."; 2950 } 2951 choice tunnel-attributes { 2952 default "value"; 2953 description 2954 "Whether the tunnel attributes are specified by value 2955 within this path computation request or by reference. 2956 The reference could be either to an existing te-tunnel 2957 or to an entry in the tunnel-attributes list"; 2958 case reference { 2959 container tunnel-reference { 2960 description 2961 "Attributes for a requested path that belongs to 2962 either an exiting te-tunnel or to an entry in the 2963 tunnel-attributes list."; 2964 choice tunnel-exist { 2965 description 2966 "Whether the tunnel reference is to an existing 2967 te-tunnel or to an entry in the tunnel-attributes 2968 list"; 2969 case tunnel-ref { 2970 leaf tunnel-ref { 2971 type te:tunnel-ref; 2972 mandatory true; 2973 description 2974 "The referenced te-tunnel instance"; 2975 } 2976 } // case tunnel-ref 2977 case tunnel-attributes-ref { 2978 leaf tunnel-attributes-ref { 2979 type leafref { 2980 path "/te:tunnels-path-compute/" 2981 + "te:path-compute-info/" 2982 + "te-pc:tunnel-attributes/te-pc:tunnel-name"; 2983 } 2984 mandatory true; 2985 description 2986 "The referenced te-tunnel instance"; 2987 } 2988 } // case tunnel-attributes-ref 2989 } // choice tunnel-exist 2990 leaf path-name { 2991 type string; 2992 description 2993 "TE path name."; 2994 } 2995 choice path-role { 2996 mandatory true; 2997 description 2998 "Whether this path is a primary, or a reverse 2999 primary, or a secondary, or a reverse secondary 3000 path."; 3001 case primary-path { 3002 container primary-path { 3003 presence "Indicates that the requested path 3004 is a primary path"; 3005 description 3006 "TE primary path"; 3007 uses te:path-preference; 3008 uses te:k-requested-paths; 3009 } // container primary-path 3010 } // case primary-path 3011 case secondary-path { 3012 container secondary-path { 3013 description 3014 "TE secondary path"; 3015 uses te:path-preference; 3016 uses protection-restoration-properties; 3017 list primary-path-ref { 3018 min-elements 1; 3019 description 3020 "The list of primary paths that reference 3021 this path as a candidate secondary path"; 3022 choice primary-path-exist { 3023 description 3024 "Whether the path reference is to an existing 3025 te-tunnel path or to another path request"; 3026 case path-ref { 3027 leaf primary-path-ref { 3028 type leafref { 3029 path "/te:te/te:tunnels/te:tunnel" 3030 + "[te:name=current()/../../../" 3031 + "tunnel-ref]/te:primary-paths/" 3032 + "te:primary-path/te:name"; 3033 } 3034 must '../../../tunnel-ref' { 3035 description 3036 "The primary-path can be referenced 3037 if also the tunnel is referenced."; 3038 } 3039 mandatory true; 3040 description 3041 "The referenced primary path"; 3042 } 3043 } // case path-ref 3044 case path-request-ref { 3045 leaf path-request-ref { 3046 type leafref { 3047 path "/te:tunnels-path-compute/" 3048 + "te:path-compute-info/" 3049 + "te-pc:path-request/" 3050 + "te-pc:request-id"; 3051 } 3052 mandatory true; 3053 description 3054 "The referenced primary path request"; 3055 } 3056 } // case path-request-ref 3057 } // choice primary-path-exist 3058 } // list primary-path-ref 3059 } // container secondary-path 3060 } // case secondary-path 3061 case primary-reverse-path { 3062 container primary-reverse-path { 3063 description 3064 "TE primary reverse path"; 3065 choice primary-path-exist { 3066 description 3067 "Whether the path reference to the primary 3068 paths for which this path is the reverse-path 3069 is to an existing te-tunnel path or to 3070 another path request."; 3071 case path-ref { 3072 leaf primary-path-ref { 3073 type leafref { 3074 path "/te:te/te:tunnels/te:tunnel[te:name" 3075 + "=current()/../../tunnel-ref]/" 3076 + "te:primary-paths/te:primary-path/" 3077 + "te:name"; 3079 } 3080 must '../../tunnel-ref' { 3081 description 3082 "The primary-path can be referenced 3083 if also the tunnel is referenced."; 3084 } 3085 mandatory true; 3086 description 3087 "The referenced primary path"; 3088 } 3089 } // case path-ref 3090 case path-request-ref { 3091 leaf path-request-ref { 3092 type leafref { 3093 path "/te:tunnels-path-compute/" 3094 + "te:path-compute-info/" 3095 + "te-pc:path-request/" 3096 + "te-pc:request-id"; 3097 } 3098 mandatory true; 3099 description 3100 "The referenced primary path request"; 3101 } 3102 } // case path-request-ref 3103 } // choice primary-path-exist 3104 } // container primary-reverse-path 3105 } // case primary-reverse-path 3106 case secondary-reverse-path { 3107 container secondary-reverse-path { 3108 description 3109 "TE secondary reverse path"; 3110 uses te:path-preference; 3111 uses protection-restoration-properties; 3112 list primary-reverse-path-ref { 3113 min-elements 1; 3114 description 3115 "The list of primary reverse paths that 3116 reference this path as a candidate 3117 secondary reverse path"; 3118 choice primary-reverse-path-exist { 3119 description 3120 "Whether the path reference is to an existing 3121 te-tunnel path or to another path request"; 3122 case path-ref { 3123 leaf primary-path-ref { 3124 type leafref { 3125 path "/te:te/te:tunnels/te:tunnel" 3126 + "[te:name=current()/../../../" 3127 + "tunnel-ref]/te:primary-paths/" 3128 + "te:primary-path/te:name"; 3129 } 3130 must '../../../tunnel-ref' { 3131 description 3132 "The primary-path can be referenced 3133 if also the tunnel is referenced."; 3134 } 3135 mandatory true; 3136 description 3137 "The referenced primary path"; 3138 } 3139 } // case path-ref 3140 case path-request-ref { 3141 leaf path-request-ref { 3142 type leafref { 3143 path "/te:tunnels-path-compute/" 3144 + "te:path-compute-info/" 3145 + "te-pc:path-request/" 3146 + "te-pc:request-id"; 3147 } 3148 mandatory true; 3149 description 3150 "The referenced primary reverse path 3151 request"; 3152 } 3153 } // case path-request-ref 3154 } // choice primary-reverse-path-exist 3155 } // list primary-reverse-path-ref 3156 } // container secondary-reverse-path 3157 } // case secondary-reverse-path 3158 } // choice tunnel-path-role 3159 } 3160 } // case reference 3161 case value { 3162 leaf tunnel-name { 3163 type string; 3164 description 3165 "TE tunnel name."; 3166 } 3167 leaf path-name { 3168 type string; 3169 description 3170 "TE path name."; 3171 } 3172 choice path-role { 3173 when 'not (./source) and not (./destination) and 3174 not (./src-tunnel-tp-id) and 3175 not (./dst-tunnel-tp-id)' { 3176 description 3177 "When the tunnel attributes are specified by value 3178 within this path computation, it is assumed that the 3179 requested path will be the only path of a tunnel. 3181 If the requested path is a transit segment path, it 3182 could be of any type. Otherwise it could only be a 3183 primary path."; 3184 } 3185 default primary-path; 3186 description 3187 "Indicates whether the requested path is a primary 3188 path, a secondary path, a reverse primary path or a 3189 reverse secondary path."; 3190 case primary-path { 3191 description 3192 "The requested path is a primary path."; 3193 } 3194 container secondary-path { 3195 presence 3196 "Indicates that the requested path is a secondary 3197 path."; 3198 description 3199 "The name of the primary path which the requested 3200 primary reverse path belongs to."; 3201 leaf primary-path-name { 3202 type string; 3203 description 3204 "TE primary path name."; 3205 } 3206 } // container secondary-path 3207 container primary-reverse-path { 3208 presence 3209 "Indicates that the requested path is a primary 3210 reverse path."; 3211 description 3212 "The name of the primary path which the requested 3213 primary reverse path belongs to."; 3214 leaf primary-path-name { 3215 type string; 3216 description 3217 "TE primary path name."; 3218 } 3219 } // container primary-reverse-path 3220 container secondary-reverse-path { 3221 presence 3222 "Indicates that the requested path is a secondary 3223 reverse path."; 3224 description 3225 "The names of the primary path and of the primary 3226 reverse path which the requested secondary reverse 3227 path belongs to."; 3228 leaf primary-path-name { 3229 type string; 3230 description 3231 "TE primary path name."; 3232 } 3233 leaf primary-reverse-path-name { 3234 type string; 3235 description 3236 "TE primary reverse path name."; 3237 } 3238 } // container primary-reverse-path 3239 } // choice path-role 3240 uses te:k-requested-paths; 3241 uses te:encoding-and-switching-type; 3242 uses te:tunnel-common-attributes; 3243 uses te-types:te-topology-identifier; 3244 } // case value 3245 } // choice tunnel-attributes 3246 uses te:path-compute-info; 3247 uses requested-info; 3248 uses requested-state; 3249 } 3250 list tunnel-attributes { 3251 key "tunnel-name"; 3252 description 3253 "Tunnel attributes common to multiple request paths"; 3254 leaf tunnel-name { 3255 type string; 3256 description 3257 "TE tunnel name."; 3258 } 3259 uses te:encoding-and-switching-type; 3260 uses te:tunnel-common-attributes; 3261 uses te:tunnel-associations-properties; 3262 uses protection-restoration-properties; 3263 uses te-types:tunnel-constraints; 3264 uses te:tunnel-hierarchy-properties { 3265 augment "hierarchy/dependency-tunnels" { 3266 description 3267 "Augment with the list of dependency tunnel requests."; 3268 list dependency-tunnel-attributes { 3269 key "name"; 3270 description 3271 "A tunnel request entry that this tunnel request can 3272 potentially depend on."; 3273 leaf name { 3274 type leafref { 3275 path "/te:tunnels-path-compute/" 3276 + "te:path-compute-info/te-pc:tunnel-attributes/" 3277 + "te-pc:tunnel-name"; 3278 } 3279 description 3280 "Dependency tunnel request name."; 3281 } 3282 uses te:encoding-and-switching-type; 3283 } 3284 } 3285 } 3286 } 3287 uses synchronization-info; 3288 } // path-compute rpc input 3290 augment "/te:tunnels-path-compute/te:output/" 3291 + "te:path-compute-result" { 3292 description 3293 "Path Computation RPC output"; 3294 list response { 3295 key "response-id"; 3296 config false; 3297 description 3298 "response"; 3299 leaf response-id { 3300 type uint32; 3301 description 3302 "The response-id has the same value of the 3303 corresponding request-id."; 3304 } 3305 uses te:path-computation-response; 3306 uses reported-state; 3307 } 3308 } // path-compute rpc output 3310 augment "/te:tunnels-actions/te:input/te:tunnel-info/" 3311 + "te:filter-type" { 3312 description 3313 "Augment Tunnels Action RPC input filter types"; 3314 case path-compute-transactions { 3315 when "derived-from-or-self(../te:action-info/te:action, " 3316 + "'tunnel-action-path-compute-delete')"; 3317 description 3318 "Path Delete Action RPC"; 3320 leaf-list path-compute-transaction-id { 3321 type string; 3322 description 3323 "The list of the transaction-id values of the 3324 transient states to be deleted"; 3325 } 3326 } 3327 } // path-delete rpc input 3329 augment "/te:tunnels-actions/te:output" { 3330 description 3331 "Augment Tunnels Action RPC output with path delete result"; 3332 container path-computed-delete-result { 3333 description 3334 "Path Delete RPC output"; 3335 leaf-list path-compute-transaction-id { 3336 type string; 3337 description 3338 "The list of the transaction-id values of the 3339 transient states that have been successfully deleted"; 3340 } 3341 } 3342 } // path-delete rpc output 3343 } 3344 3346 Figure 12: TE path computation YANG module 3348 7. Security Considerations 3350 This document describes use cases of requesting Path Computation 3351 using YANG data models, which could be used at the ABNO Control 3352 Interface [RFC7491] and/or between controllers in ACTN [RFC8453]. As 3353 such, it does not introduce any new security considerations compared 3354 to the ones related to YANG specification, ABNO specification and 3355 ACTN Framework defined in [RFC7950], [RFC7491] and [RFC8453]. 3357 The YANG module defined in this document is designed to be accessed 3358 via the NETCONF protocol [RFC6241] or RESTCONF protocol [RFC8040]. 3359 The lowest NETCONF layer is the secure transport layer, and the 3360 mandatory-to-implement secure transport is Secure Shell (SSH) 3361 [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to- 3362 implement secure transport is TLS [RFC8446]. 3364 The Network Configuration Access Control Model (NACM) [RFC8341] 3365 provides the means to restrict access for particular NETCONF or 3366 RESTCONF users to a preconfigured subset of all available NETCONF or 3367 RESTCONF protocol operations and content. 3369 The YANG module defined in this document augments the "tunnels-path- 3370 compute" and the "tunnel-actions" RPCs defined in 3371 [I-D.ietf-teas-yang-te]. The security considerations provided in 3372 [I-D.ietf-teas-yang-te] are also applicable to the YANG module 3373 defined in this document. 3375 Some of the RPC operations defined in this YANG module may be 3376 considered sensitive or vulnerable in some network environments. It 3377 is thus important to control access to these operations. These are 3378 the operations and their sensitivity/vulnerability: 3380 "te-pc:response/computed-paths-properties": provides the same 3381 information provided by the "te:computed-paths-properties" defined in 3382 [I-D.ietf-teas-yang-te]. The security considerations provided in 3383 [I-D.ietf-teas-yang-te] for the TE tunnel state apply also to this 3384 subtree. 3386 "te-pc:response/te-pc:tunnel-ref", "te-pc:response/te-pc:primary- 3387 path-ref", "te-pc:response/te-pc:primary-reverse-path-ref", "te- 3388 pc:response/te-pc:secondary-path-ref" and "te-pc:response/te- 3389 pc:secondary-reverse-path-ref" provides a reference where the same 3390 information provided in "te-pc:response/computed-paths-properties" is 3391 temporarly stored with the operational datastore (see Section 3.3.1). 3392 Therefore access to this information does not provide any additional 3393 security issue that the information provided with "te-pc:response/ 3394 computed-paths-properties". 3396 "/te:tunnels-actions": the YANG model defined in this document 3397 augments this action with a new action type that allows deleting the 3398 transient states of computed paths (see Section 3.3.1). A malicious 3399 use of this action would have no impact on the paths carrying live 3400 traffic but it would preclude the client from using the "transient 3401 states" to request the set-up of exactly that path, if still 3402 available. 3404 The security considerations spelled out in the YANG specification 3405 [RFC7950] apply for this document as well. 3407 8. IANA Considerations 3409 This document registers the following URIs in the "ns" subregistry 3410 within the "IETF XML registry" [RFC3688]. 3412 URI: urn:ietf:params:xml:ns:yang:ietf-te-path-computation 3413 Registrant Contact: The IESG. 3414 XML: N/A, the requested URI is an XML namespace. 3416 This document registers a YANG module in the "YANG Module Names" 3417 registry [RFC7950]. 3419 name: ietf-te-path-computation 3420 namespace: urn:ietf:params:xml:ns:yang:ietf-te-path-computation 3421 prefix: te-pc 3422 reference: this document 3424 9. References 3426 9.1. Normative References 3428 [I-D.ietf-teas-yang-te] 3429 Saad, T., Gandhi, R., Liu, X., Beeram, V. P., Bryskin, I., 3430 and O. G. D. Dios, "A YANG Data Model for Traffic 3431 Engineering Tunnels, Label Switched Paths and Interfaces", 3432 Work in Progress, Internet-Draft, draft-ietf-teas-yang-te- 3433 29, 7 February 2022, . 3436 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3437 DOI 10.17487/RFC3688, January 2004, 3438 . 3440 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 3441 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 3442 DOI 10.17487/RFC5440, March 2009, 3443 . 3445 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 3446 "A Backward-Recursive PCE-Based Computation (BRPC) 3447 Procedure to Compute Shortest Constrained Inter-Domain 3448 Traffic Engineering Label Switched Paths", RFC 5441, 3449 DOI 10.17487/RFC5441, April 2009, 3450 . 3452 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 3453 Objective Functions in the Path Computation Element 3454 Communication Protocol (PCEP)", RFC 5541, 3455 DOI 10.17487/RFC5541, June 2009, 3456 . 3458 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 3459 and A. Bierman, Ed., "Network Configuration Protocol 3460 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 3461 . 3463 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 3464 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 3465 . 3467 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 3468 RFC 6991, DOI 10.17487/RFC6991, July 2013, 3469 . 3471 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 3472 Ceccarelli, D., and X. Zhang, "Problem Statement and 3473 Architecture for Information Exchange between 3474 Interconnected Traffic-Engineered Networks", BCP 206, 3475 RFC 7926, DOI 10.17487/RFC7926, July 2016, 3476 . 3478 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 3479 RFC 7950, DOI 10.17487/RFC7950, August 2016, 3480 . 3482 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 3483 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 3484 . 3486 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 3487 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 3488 . 3490 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 3491 Access Control Model", STD 91, RFC 8341, 3492 DOI 10.17487/RFC8341, March 2018, 3493 . 3495 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3496 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3497 . 3499 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 3500 "Common YANG Data Types for Traffic Engineering", 3501 RFC 8776, DOI 10.17487/RFC8776, June 2020, 3502 . 3504 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 3505 O. Gonzalez de Dios, "YANG Data Model for Traffic 3506 Engineering (TE) Topologies", RFC 8795, 3507 DOI 10.17487/RFC8795, August 2020, 3508 . 3510 9.2. Informative References 3512 [I-D.ietf-ccamp-otn-topo-yang] 3513 Zheng, H., Busi, I., Liu, X., Belotti, S., and O. G. D. 3514 Dios, "A YANG Data Model for Optical Transport Network 3515 Topology", Work in Progress, Internet-Draft, draft-ietf- 3516 ccamp-otn-topo-yang-14, 7 March 2022, 3517 . 3520 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 3521 Computation Element (PCE)-Based Architecture", RFC 4655, 3522 DOI 10.17487/RFC4655, August 2006, 3523 . 3525 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 3526 Path Computation Element Architecture to the Determination 3527 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 3528 DOI 10.17487/RFC6805, November 2012, 3529 . 3531 [RFC7446] Lee, Y., Ed., Bernstein, G., Ed., Li, D., and W. Imajuku, 3532 "Routing and Wavelength Assignment Information Model for 3533 Wavelength Switched Optical Networks", RFC 7446, 3534 DOI 10.17487/RFC7446, February 2015, 3535 . 3537 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 3538 Application-Based Network Operations", RFC 7491, 3539 DOI 10.17487/RFC7491, March 2015, 3540 . 3542 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 3543 and R. Wilton, "Network Management Datastore Architecture 3544 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 3545 . 3547 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 3548 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 3549 DOI 10.17487/RFC8453, August 2018, 3550 . 3552 [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. 3553 Yoon, "Information Model for Abstraction and Control of TE 3554 Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, 3555 September 2018, . 3557 Appendix A. Examples 3559 This section contains examples of use of the model with RESTCONF 3560 [RFC8040] and JSON encoding. 3562 These examples show how path computation can be requested for the 3563 tunnels configuration provided in Appendix A of 3564 [I-D.ietf-teas-yang-te]. 3566 A.1. Basic Path Computation 3568 This example uses the path computation RPC defined in this document 3569 to request the computation of the path for the tunnel defined in 3570 section 13.1 of of [I-D.ietf-teas-yang-te]. 3572 In this case, the TE Tunnel has only one primary path with no 3573 specific constraints. 3575 POST /restconf/operations/ietf-te:te:tunnels-path-compute HTTP/1.1 3576 Host: example.com 3577 Content-Type: application/yang-data+json 3579 { 3580 "ietf-te:input": { 3581 "path-compute-info": { 3582 "ietf-te-path-computation:path-request": [ 3583 { 3584 "request-id": 1, 3585 "tunnel-name": "Example_LSP_Tunnel_A_2", 3586 "encoding": "te-types:lsp-encoding-packet", 3587 "source": "10.0.0.1", 3588 "destination": "10.0.0.4", 3589 "bidirectional": "false", 3590 "signaling-type": "te-types:path-setup-rsvp" 3591 } 3592 ] 3593 } 3594 } 3595 } 3597 A.2. Path Computation with transient state 3599 This example uses the path computation RPC defined in this document 3600 to request the computation of the path for the tunnel defined in 3601 section 13.1 of of [I-D.ietf-teas-yang-te] requesting some transient 3602 state to be reported within the operational datastore, as described 3603 Section 3.3.1. 3605 In this case, the TE Tunnel has only one primary path with no 3606 specific constraints. 3608 POST /restconf/operations/ietf-te:te:tunnels-path-compute HTTP/1.1 3609 Host: example.com 3610 Content-Type: application/yang-data+json 3612 { 3613 "ietf-te:input": { 3614 "path-compute-info": { 3615 "ietf-te-path-computation:path-request": [ 3616 { 3617 "request-id": 2, 3618 "tunnel-name": "Example_LSP_Tunnel_A_2", 3619 "encoding": "te-types:lsp-encoding-packet", 3620 "source": "10.0.0.1", 3621 "destination": "10.0.0.4", 3622 "bidirectional": "false", 3623 "signaling-type": "te-types:path-setup-rsvp", 3624 "requested-state": { 3625 "transaction-id": "example" 3626 } 3627 } 3628 ] 3629 } 3630 } 3631 } 3633 A.3. Path Computation with Global Path Constraint 3635 This example uses the path computation RPC defined in this document 3636 to request the computation of the path for the tunnel defined in 3637 section 13.3 of of [I-D.ietf-teas-yang-te]. The 'named path 3638 constraint' is created in section 13.2 of [I-D.ietf-teas-yang-te] 3639 applies to this path computation request. 3641 POST /restconf/operations/ietf-te:te:tunnels-path-compute HTTP/1.1 3642 Host: example.com 3643 Content-Type: application/yang-data+json 3644 { 3645 "ietf-te:input": { 3646 "path-compute-info": { 3647 "ietf-te-path-computation:path-request": [ 3648 { 3649 "request-id": 3, 3650 "tunnel-name": "Example_LSP_Tunnel_A_4_1", 3651 "path-name": "Simple_LSP_1", 3652 "encoding": "te-types:lsp-encoding-packet", 3653 "source": "10.0.0.1", 3654 "destination": "10.0.0.4", 3655 "bidirectional": "false", 3656 "signaling-type": "path-setup-rsvp", 3657 "named-path-constraint": "max-hop-3", 3658 "requested-state": {} 3659 } 3660 ] 3661 } 3662 } 3663 } 3665 A.4. Path Computation with Per-tunnel Path Constraint 3667 This example uses the path computation RPC defined in this document 3668 to request the computation of the path for the tunnel defined in 3669 section 13.4 of of [I-D.ietf-teas-yang-te], using a per tunnel path 3670 constraint. 3672 POST /restconf/operations/ietf-te:te:tunnels-path-compute HTTP/1.1 3673 Host: example.com 3674 Content-Type: application/yang-data+json 3675 { 3676 "ietf-te:input": { 3677 "path-compute-info": { 3678 "ietf-te-path-computation:path-request": [ 3679 { 3680 "request-id": 4, 3681 "tunnel-name": "Example_LSP_Tunnel_A_4_2", 3682 "path-name": "path1", 3683 "encoding": "te-types:lsp-encoding-packet", 3684 "source": "10.0.0.1", 3685 "destination": "10.0.0.4", 3686 "bidirectional": "false", 3687 "signaling-type": "te-types:path-setup-rsvp", 3688 "path-metric-bounds": { 3689 "path-metric-bound": [ 3690 { 3691 "metric-type": "te-types:path-metric-hop", 3692 "upper-bound": "3" 3693 } 3694 ] 3695 } 3696 } 3697 ] 3698 } 3699 } 3700 } 3702 A.5. Path Computation result 3704 This example reports the output of the path computation RPC request 3705 described in Appendix A.4. 3707 HTTP/1.1 200 OK 3708 Host: example.com 3709 Content-Type: application/yang-data+json 3710 { 3711 "ietf-te:output": { 3712 "path-compute-result": { 3713 "ietf-te-path-computation:response": [ 3714 { 3715 "response-id": 3, 3716 "computed-paths-properties": { 3717 "computed-path-properties": [ 3718 { 3719 "k-index": "1", 3720 "path-properties": { 3721 "path-route-objects": { 3722 "path-route-object": [ 3723 { 3724 "index": "1", 3725 "numbered-node-hop": { 3726 "node-id": "10.0.0.2" 3727 } 3728 }, 3729 { 3730 "index": "2", 3731 "numbered-node-hop": { 3732 "node-id": "10.0.0.4" 3733 } 3734 } 3735 ] 3736 } 3737 } 3738 } 3739 ] 3740 }, 3741 "tunnel-ref": "Example_LSP_Tunnel_A_4_1", 3742 "primary-path-ref": "path1" 3743 } 3744 ] 3745 } 3746 } 3747 } 3749 Acknowledgments 3751 The authors would like to thank Igor Bryskin and Xian Zhang for 3752 participating in the initial discussions that have triggered this 3753 work and providing valuable insights. 3755 The authors would like to thank the authors of the TE tunnel YANG 3756 data model [I-D.ietf-teas-yang-te], in particular Igor Bryskin, 3757 Vishnu Pavan Beeram, Tarek Saad and Xufeng Liu, for their inputs to 3758 the discussions and support in having consistency between the Path 3759 Computation and TE tunnel YANG data models. 3761 The authors would like to thank Adrian Farrel, Dhruv Dhody, Igor 3762 Bryskin, Julien Meuric and Lou Berger for their valuable input to the 3763 discussions that has clarified that the path being set up is not 3764 necessarily the same as the path that has been previously computed 3765 and, in particular to Dhruv Dhody, for his suggestion to describe the 3766 need for a path verification phase to check that the actual path 3767 being set up meets the required end-to-end metrics and constraints. 3769 The authors would like to thank Aihua Guo, Lou Berger, Shaolong Gan, 3770 Martin Bjorklund and Tom Petch for their useful comments on how to 3771 define XPath statements in YANG RPCs. 3773 The authors would like to thank Haomian Zheng, Yanlei Zheng, Tom 3774 Petch, Aihua Guo and Martin Bjorklund for their review and valuable 3775 comments to this document. 3777 Previous versions of document were prepared using 2-Word- 3778 v2.0.template.dot. 3780 This document was prepared using kramdown. 3782 Contributors 3784 Victor Lopez 3785 Nokia 3786 Email: victor.lopez@nokia.com 3788 Ricard Vilalta 3789 CTTC 3790 Email: ricard.vilalta@cttc.es 3792 Karthik Sethuraman 3793 NEC 3794 Email: karthik.sethuraman@necam.com 3796 Michael Scharf 3797 Nokia 3798 Email: michael.scharf@gmail.com 3799 Dieter Beller 3800 Nokia 3801 Email: dieter.beller@nokia.com 3803 Gianmarco Bruno 3804 Ericsson 3805 Email: gianmarco.bruno@ericsson.com 3807 Francesco Lazzeri 3808 Ericsson 3809 Email: francesco.lazzeri@ericsson.com 3811 Young Lee 3812 Samsung Electronics 3813 Email: younglee.tx@gmail.com 3815 Carlo Perocchio 3816 Ericsson 3817 Email: carlo.perocchio@ericsson.com 3819 Olivier Dugeon 3820 Orange Labs 3821 Email: olivier.dugeon@orange.com 3823 Julien Meuric 3824 Orange Labs 3825 Email: julien.meuric@orange.com 3827 Authors' Addresses 3829 Italo Busi (editor) 3830 Huawei Technologies 3831 Email: italo.busi@huawei.com 3833 Sergio Belotti (editor) 3834 Nokia 3835 Email: sergio.belotti@nokia.com 3836 Oscar Gonzalez de Dios 3837 Telefonica 3838 Email: oscar.gonzalezdedios@telefonica.com 3840 Anurag Sharma 3841 Google 3842 Email: ansha@google.com 3844 Daniele Ceccarelli 3845 Ericsson 3846 Email: daniele.ceccarelli@ericsson.com