idnits 2.17.1 draft-ietf-teas-yang-path-computation-14.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 56 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1420 has weird spacing: '...ic-type ide...' == Line 1428 has weird spacing: '...- usage ide...' == Line 1439 has weird spacing: '...k-tp-id te-...' == Line 1444 has weird spacing: '...k-tp-id te-...' == Line 1450 has weird spacing: '...-number ine...' == (51 more instances...) -- The document date (July 12, 2021) is 1012 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3945' is defined on line 3399, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS Working Group Italo Busi (Ed.) 2 Internet Draft Huawei 3 Intended status: Standard Track Sergio Belotti (Ed.) 4 Expires: January 2022 Nokia 5 Victor Lopez 6 Nokia 7 Anurag Sharma 8 Google 9 Yan Shi 10 China Unicom 12 July 12, 2021 14 YANG Data Model for requesting Path Computation 15 draft-ietf-teas-yang-path-computation-14 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on January 12, 2022. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Abstract 57 There are scenarios, typically in a hierarchical Software-Defined 58 Networking (SDN) context, where the topology information provided by 59 a Traffic Engineering (TE) network provider may be insufficient for 60 its client to perform end-to-end path computation. In these cases the 61 client would need to request the provider to calculate some (partial) 62 feasible paths. 64 This document defines a YANG data model for a Remote Procedure Call 65 (RPC) to request path computation. This model complements the 66 solution, defined in RFC YYYY, to configure a TE tunnel path in 67 "compute-only" mode. 69 [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of 70 draft-ietf-teas-yang-te once it has been published. 72 Moreover this document describes some use cases where a path 73 computation request, via YANG-based protocols (e.g., NETCONF or 74 RESTCONF), can be needed. 76 Table of Contents 78 1. Introduction...................................................3 79 1.1. Terminology...............................................5 80 1.2. Tree Diagram..............................................5 81 1.3. Prefixes in Data Node Names...............................6 82 2. Use Cases......................................................6 83 2.1. Packet/Optical Integration................................6 84 2.2. Multi-domain TE networks.................................11 85 2.3. Data Center Interconnections.............................13 86 2.4. Backward Recursive Path Computation scenario.............15 87 2.5. Hierarchical PCE scenario................................16 88 3. Motivations...................................................19 89 3.1. Motivation for a YANG Model..............................19 90 3.1.1. Benefits of common data models......................19 91 3.1.2. Benefits of a single interface......................20 92 3.1.3. Extensibility.......................................21 93 3.2. Interactions with TE topology............................21 94 3.2.1. TE topology aggregation.............................22 95 3.2.2. TE topology abstraction.............................25 96 3.2.3. Complementary use of TE topology and path computation27 97 3.3. Path Computation RPC.....................................30 98 3.3.1. Temporary reporting of the computed path state......32 99 4. Path computation and optimization for multiple paths..........34 100 5. YANG data model for requesting Path Computation...............35 101 5.1. Synchronization of multiple path computation requests....35 102 5.2. Returned metric values...................................38 103 5.3. Multiple Paths Requests for the same TE tunnel...........39 104 5.3.1. Tunnel attributes specified by value................41 105 5.3.2. Tunnel attributes specified by reference............42 106 5.4. Multi-Layer Path Computation.............................44 107 6. YANG data model for TE path computation.......................45 108 6.1. Tree diagram.............................................45 109 6.2. YANG module..............................................59 110 7. Security Considerations.......................................84 111 8. IANA Considerations...........................................85 112 9. References....................................................85 113 9.1. Normative References.....................................85 114 9.2. Informative References...................................87 115 Appendix A. Examples of dimensioning the "detailed connectivity 116 matrix" 89 117 Acknowledgments..................................................95 118 Contributors.....................................................95 119 Authors' Addresses...............................................96 121 1. Introduction 123 There are scenarios, typically in a hierarchical Software-Defined 124 Networking (SDN) context, where the topology information provided by 125 a Traffic Engineering (TE) network provider may be insufficient for 126 its client to perform end-to-end path computation. In these cases the 127 client would need to request the provider to calculate some (partial) 128 feasible paths, complementing his topology knowledge, to make his 129 end-to-end path computation feasible. 131 This type of scenarios can be applied to different interfaces in 132 different reference architectures: 134 o Application-Based Network Operations (ABNO) control interface 135 [RFC7491], in which an Application Service Coordinator can request 136 ABNO controller to take in charge path calculation (see Figure 1 137 in [RFC7491]). 139 o Abstraction and Control of TE Networks (ACTN) [RFC8453], where a 140 controller hierarchy is defined, the need for path computation 141 arises on the interface between Customer Network Controller (CNC) 142 and Multi-Domain Service Coordinator (MDSC), called CNC-MDSC 143 Interface (CMI), and on the interface between MSDC and 144 Provisioning Network Controller (PNC), called MDSC-PNC Interface 145 (MPI). [RFC8454] describes an information model for the Path 146 Computation request. 148 Multiple protocol solutions can be used for communication between 149 different controller hierarchical levels. This document assumes that 150 the controllers are communicating using YANG-based protocols (e.g., 151 NETCONF [RFC6241] or RESTCONF [RFC8040]). 153 Path Computation Elements (PCEs), controllers and orchestrators 154 perform their operations based on Traffic Engineering Databases 155 (TED). Such TEDs can be described, in a technology agnostic way, with 156 the YANG data model for TE Topologies [RFC8795]. Furthermore, the 157 technology specific details of the TED are modeled in the augmented 158 TE topology models, e.g. [OTN-TOPO] for Optical Transport Network 159 (OTN) Optical Data Unit (ODU) technologies. 161 The availability of such topology models allows the provisioning of 162 the TED using YANG-based protocols (e.g., NETCONF or RESTCONF). 163 Furthermore, it enables a PCE/controller performing the necessary 164 abstractions or modifications and offering this customized topology 165 to another PCE/controller or high level orchestrator. 167 The tunnels that can be provided over the networks described with the 168 topology models can be also set-up, deleted and modified via YANG- 169 based protocols (e.g., NETCONF or RESTCONF) using the TE tunnel YANG 170 data model [TE-TUNNEL]. 172 This document defines a YANG data model [RFC7950] for an RPC to 173 request path computation, which complements the solution defined in 174 [TE-TUNNEL], to configure a TE tunnel path in "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 Network 187 Management Datastore Architecture [RFC8342]. 189 1.1. Terminology 191 TED: The traffic engineering database is a collection of all TE 192 information about all TE nodes and TE links in a given network. 194 PCE: A Path Computation Element (PCE) is an entity that is capable of 195 computing a network path or route based on a network graph, and of 196 applying computational constraints during the computation. The PCE 197 entity is an application that can be located within a network node or 198 component, on an out-of-network server, etc. For example, a PCE 199 would be able to compute the path of a TE Label Switched Path (LSP) 200 by operating on the TED and considering bandwidth and other 201 constraints applicable to the TE LSP service request. [RFC4655]. 203 Domain: TE information is the data relating to nodes and TE links 204 that is used in the process of selecting a TE path. TE information 205 is usually only available within a network. We call such a zone of 206 visibility of TE information a domain. An example of a domain may be 207 an IGP area or an Autonomous System. [RFC7926] 209 The terminology for describing YANG data models is found in 210 [RFC7950]. 212 1.2. Tree Diagram 214 Tree diagrams used in this document follow the notation defined in 215 [RFC8340]. 217 1.3. Prefixes in Data Node Names 219 In this document, names of data nodes and other data model objects 220 are prefixed using the standard prefix associated with the 221 corresponding YANG imported modules, as shown in Table 1. 223 +---------------+--------------------------+-----------------+ 224 | Prefix | YANG module | Reference | 225 +---------------+--------------------------+-----------------+ 226 | inet | ietf-inet-types | [RFC6991] | 227 | te-types | ietf-te-types | [RFC8776] | 228 | te | ietf-te | [TE-TUNNEL] | 229 | te-pc | ietf-te-path-computation | this document | 230 +---------------+--------------------------+-----------------+ 232 Table 1: Prefixes and corresponding YANG modules 234 2. Use Cases 236 This section presents some use cases, where a client needs to request 237 underlying SDN controllers for path computation. 239 The use of the YANG data model defined in this document is not 240 restricted to these use cases but can be used in any other use case 241 when deemed useful. 243 The presented uses cases have been grouped, depending on the 244 different underlying topologies: a) Packet/Optical Integration; b) 245 multi-domain Traffic Engineered (TE) Networks; and c) Data Center 246 Interconnections. Use cases d) and e) respectively present how to 247 apply this YANG data model for standard multi-domain PCE i.e. 248 Backward Recursive Path Computation [RFC5441] and Hierarchical PCE 249 [RFC6805]. 251 2.1. Packet/Optical Integration 253 In this use case, an optical domain is used to provide connectivity 254 to some nodes of a packet domain (see Figure 1). 256 +----------------+ 257 | | 258 | Packet/Optical | 259 | Coordinator | 260 | | 261 +---+------+-----+ 262 | | 263 +------------+ | 264 | +-----------+ 265 +------V-----+ | 266 | | +------V-----+ 267 | Packet | | | 268 | Domain | | Optical | 269 | Controller | | Domain | 270 | | | Controller | 271 +------+-----+ +-------+----+ 272 | | 273 .........V......................... | 274 : packet domain : | 275 +----+ +----+ | 276 | R1 |= = = = = = = = = = = = = = = =| R2 | | 277 +-+--+ +--+-+ | 278 | : : | | 279 | :................................ : | | 280 | | | 281 | +-----+ | | 282 | ...........| Opt |........... | | 283 | : | C | : | | 284 | : /+--+--+\ : | | 285 | : / | \ : | | 286 | : / | \ : | | 287 | +-----+ / +--+--+ \ +-----+ | | 288 | | Opt |/ | Opt | \| Opt | | | 289 +---| A | | D | | B |---+ | 290 +-----+\ +--+--+ /+-----+ | 291 : \ | / : | 292 : \ | / : | 293 : \ +--+--+ / optical<---------+ 294 : \| Opt |/ domain : 295 :..........| E |..........: 296 +-----+ 298 Figure 1 - Packet/Optical Integration use case 300 Figure 1 as well as Figure 2 below only show a partial view of the 301 packet network connectivity, before additional packet connectivity is 302 provided by the optical network. 304 It is assumed that the Optical Domain Controller provides to the 305 Packet/Optical Coordinator an abstracted view of the optical network. 306 A possible abstraction could be to represent the whole optical 307 network as one "virtual node" with "virtual ports" connected to the 308 access links, as shown in Figure 2. 310 It is also assumed that Packet Domain Controller can provide the 311 Packet/Optical Coordinator the information it needs to set up 312 connectivity between packet nodes through the optical network (e.g., 313 the access links). 315 The path computation request helps the Packet/Optical Coordinator to 316 know the real connections that can be provided by the optical 317 network. 319 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,. 320 , Packet/Optical Coordinator view , 321 , +----+ , . 322 , | | , 323 , | R2 | , . 324 , +----+ +------------ + /+----+ , 325 , | | | |/-----/ / / , . 326 , | R1 |--O VP1 VP4 O / / , 327 , | |\ | | /----/ / , . 328 , +----+ \| |/ / , 329 , / O VP2 VP5 O / , . 330 , / | | +----+ , 331 , / | | | | , . 332 , / O VP3 VP6 O--| R4 | , 333 , +----+ /-----/|_____________| +----+ , . 334 , | |/ +------------ + , 335 , | R3 | , . 336 , +----+ ,,,,,,,,,,,,,,,,, 337 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,. 338 . Packet Domain Controller view +----+ , 339 only packet nodes and packet links | | , . 340 . with access links to the optical network | R2 | , 341 , +----+ /+----+ , . 342 . , | | /-----/ / / , 343 , | R1 |--- / / , . 344 . , +----+\ /----/ / , 345 , / \ / / , . 346 . , / / , 347 , / +----+ , . 348 . , / | | , 349 , / ---| R4 | , . 350 . , +----+ /-----/ +----+ , 351 , | |/ , . 352 . , | R3 | , 353 , +----+ ,,,,,,,,,,,,,,,,,. 354 .,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, , 355 Optical Domain Controller view , . 356 . only optical nodes, +--+ , 357 optical links and /|OF| , . 358 . access links from the +--++--+ / , 359 packet network |OA| \ /-----/ / , . 360 . , ---+--+--\ +--+/ / , 361 , \ | \ \-|OE|-------/ , . 362 . , \ | \ /-+--+ , 363 , \+--+ X | , . 364 . , |OB|-/ \ | , 365 , +--+-\ \+--+ , . 366 . , / \ \--|OD|--- , 367 , /-----/ +--+ +--+ , . 368 . , / |OC|/ , 369 , +--+ , . 370 ., ,,,,,,,,,,,,,,,,,, 371 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, , 372 . Actual Physical View +----+ , 373 , +--+ | | , 374 . , /|OF| | R2 | , 375 , +----+ +--++--+ /+----+ , 376 . , | | |OA| \ /-----/ / / , 377 , | R1 |---+--+--\ +--+/ / / , 378 . , +----+\ | \ \-|OE|-------/ / , 379 , / \ | \ /-+--+ / , 380 . , / \+--+ X | / , 381 , / |OB|-/ \ | +----+ , 382 . , / +--+-\ \+--+ | | , 383 , / / \ \--|OD|---| R4 | , 384 . , +----+ /-----/ +--+ +--+ +----+ , 385 , | |/ |OC|/ , 386 . , | R3 | +--+ , 387 , +----+ , 388 .,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 390 Figure 2 - Packet and Optical Topology Abstractions 392 In this use case, the Packet/Optical Coordinator needs to set up an 393 optimal underlying path for an IP link between R1 and R2. 395 As depicted in Figure 2, the Packet/Optical Coordinator has only an 396 "abstracted view" of the physical network, and it does not know the 397 feasibility or the cost of the possible optical paths (e.g., VP1-VP4 398 and VP2-VP5), which depend on the current status of the physical 399 resources within the optical network and on vendor-specific optical 400 attributes. 402 The Packet/Optical Coordinator can request the underlying Optical 403 Domain Controller to compute a set of potential optimal paths, taking 404 into account optical constraints. Then, based on its own constraints, 405 policy and knowledge (e.g. cost of the access links), it can choose 406 which one of these potential paths to use to set up the optimal end- 407 to-end path crossing optical network. 409 ............................ 410 : : 411 O VP1 VP4 O 412 cost=10 /:\ /:\ cost=10 413 / : \----------------------/ : \ 414 +----+ / : cost=50 : \ +----+ 415 | |/ : : \| | 416 | R1 | : : | R2 | 417 | |\ : : /| | 418 +----+ \ : /--------------------\ : / +----+ 419 \ : / cost=55 \ : / 420 cost=5 \:/ \:/ cost=5 421 O VP2 VP5 O 422 : : 423 :..........................: 425 Figure 3 - Packet/Optical Integration path computation 426 example 428 For example, in Figure 3, the Packet/Optical Coordinator can request 429 the Optical Domain Controller to compute the paths between VP1-VP4 430 and VP2-VP5 and then decide to set up the optimal end-to-end path 431 using the VP2-VP5 optical path even if this is not the optimal path 432 from the optical domain perspective. 434 Considering the dynamicity of the connectivity constraints of an 435 optical domain, it is possible that a path computed by the Optical 436 Domain Controller when requested by the Packet/Optical Coordinator is 437 no longer valid/available when the Packet/Optical Coordinator 438 requests it to be set up. This is further discussed in section 3.3. 440 2.2. Multi-domain TE networks 442 In this use case there are two TE domains which are interconnected 443 together by multiple inter-domains links. 445 A possible example could be a multi-domain optical network. 447 +--------------+ 448 | Multi-Domain | 449 | Controller | 450 +---+------+---+ 451 | | 452 +------------+ | 453 | +-----------+ 454 +------V-----+ | 455 | | | 456 | TE Domain | +------V-----+ 457 | Controller | | | 458 | 1 | | TE Domain | 459 +------+-----+ | Controller | 460 | | 2 | 461 | +------+-----+ 462 .........V.......... | 463 : : | 464 +-----+ : | 465 | | : .........V.......... 466 | X | : : : 467 | | +-----+ +-----+ : 468 +-----+ | | | | : 469 : | C |------| E | : 470 +-----+ +-----+ /| | | |\ +-----+ +-----+ 471 | | | |/ +-----+ +-----+ \| | | | 472 | A |----| B | : : | G |----| H | 473 | | | |\ : : /| | | | 474 +-----+ +-----+ \+-----+ +-----+/ +-----+ +-----+ 475 : | | | | : 476 : | D |------| F | : 477 : | | | | +-----+ 478 : +-----+ +-----+ | | 479 : : : | Y | 480 : : : | | 481 : TE domain 1 : : TE domain 2 +-----+ 482 :..................: :.................: 484 Figure 4 - Multi-domain multi-link interconnection 486 In order to set up an end-to-end multi-domain TE path (e.g., between 487 nodes A and H), the Multi-Domain Controller needs to know the 488 feasibility or the cost of the possible TE paths within the two TE 489 domains, which depend on the current status of the physical resources 490 within each TE domain. This is more challenging in case of optical 491 networks because the optimal paths depend also on vendor-specific 492 optical attributes (which may be different in the two domains if they 493 are provided by different vendors). 495 In order to set up a multi-domain TE path (e.g., between nodes A and 496 H), the Multi-Domain Controller can request the TE Domain Controllers 497 to compute a set of intra-domain optimal paths and take decisions 498 based on the information received. For example: 500 o The Multi-Domain Controller asks TE Domain Controllers to provide 501 set of paths between A-C, A-D, E-H and F-H 503 o TE Domain Controllers return a set of feasible paths with the 504 associated costs: the path A-C is not part of this set (in optical 505 networks, it is typical to have some paths not being feasible due 506 to optical constraints that are known only by the Optical Domain 507 Controller) 509 o The Multi-Domain Controller will select the path A-D-F-H since it 510 is the only feasible multi-domain path and then request the TE 511 Domain Controllers to set up the A-D and F-H intra-domain paths 513 o If there are multiple feasible paths, the Multi-Domain Controller 514 can select the optimal path knowing the cost of the intra-domain 515 paths (provided by the TE domain controllers) and the cost of the 516 inter-domain links (known by the Multi-Domain Controller) 518 This approach may have some scalability issues when the number of TE 519 domains is quite big (e.g. 20). 521 In this case, it would be worthwhile using the abstract TE topology 522 information provided by the TE Domain Controllers to limit the number 523 of potential optimal end-to-end paths and then request path 524 computation from fewer TE Domain Controllers in order to decide what 525 the optimal path within this limited set is. 527 For more details, see section 3.2.3. 529 2.3. Data Center Interconnections 531 In these use case, there is a TE domain which is used to provide 532 connectivity between Data Centers which are connected with the TE 533 domain using access links. 535 +--------------+ 536 | Cloud Network| 537 | Orchestrator | 538 +--------------+ 539 | | | | 540 +-------------+ | | +------------------------+ 541 | | +------------------+ | 542 | +--------V---+ | | 543 | | | | | 544 | | TE Network | | | 545 +------V-----+ | Controller | +------V-----+ | 546 | DC | +------------+ | DC | | 547 | Controller | | | Controller | | 548 +------------+ | +-----+ +------------+ | 549 | ....V...| |........ | | 550 | : | P | : | | 551 .....V..... : /+-----+\ : .....V..... | 552 : : +-----+ / | \ +-----+ : : | 553 : DC1 || : | |/ | \| | : DC2 || : | 554 : ||||----| PE1 | | | PE2 |---- |||| : | 555 : _|||||| : | |\ | /| | : _|||||| : | 556 : : +-----+ \ +-----+ / +-----+ : : | 557 :.........: : \| |/ : :.........: | 558 :.......| PE3 |.......: | 559 | | | 560 +-----+ +---------V--+ 561 .....|..... | DC | 562 : : | Controller | 563 : DC3 || : +------------+ 564 : |||| : | 565 : _|||||| <------------------+ 566 : : 567 :.........: 569 Figure 5 - Data Center Interconnection use case 571 In this use case, there is the need to transfer data from Data Center 572 1 (DC1) to either DC2 or DC3 (e.g. workload migration). 574 The optimal decision depends both on the cost of the TE path (DC1-DC2 575 or DC1-DC3) and of the Data Center resources within DC2 or DC3. 577 The Cloud Network Orchestrator needs to make a decision for optimal 578 connection based on TE network constraints and Data Center resources. 580 It may not be able to make this decision because it has only an 581 abstract view of the TE network (as in use case in 2.1). 583 The Cloud Network Orchestrator can request to the TE Network 584 Controller to compute the cost of the possible TE paths (e.g., DC1- 585 DC2 and DC1-DC3) and to the DC Controller to provide the information 586 it needs about the required Data Center resources within DC2 and DC3 587 and then it can take the decision about the optimal solution based on 588 this information and its policy. 590 2.4. Backward Recursive Path Computation scenario 592 [RFC5441] has defined the Virtual Source Path Tree (VSPT) TLV within 593 PCE Reply Object in order to compute inter-domain paths following a 594 "Backward Recursive Path Computation" (BRPC) method. The main 595 principle is to forward the PCE request message up to the destination 596 domain. Then, each PCE involved in the computation will compute its 597 part of the path and send it back to the requester through PCE 598 Response message. The resulting computation is spread from 599 destination PCE to source PCE. Each PCE is in charge of merging the 600 path it received with the one it calculated. At the end, the source 601 PCE merges its local part of the path with the received one to 602 achieve the end-to-end path. 604 Figure 6 below show a typical BRPC scenario where 3 PCEs cooperate to 605 compute inter-domain paths. 607 +----------------+ +----------------+ 608 | Domain (B) | | Domain (C) | 609 | | | | 610 | /-------|---PCEP---|--------\ | 611 | / | | \ | 612 | (PCE) | | - (PCE) | 613 | / <----------> |D| | 614 | / | Inter | - | 615 +---|----^-------+ Domain +----------------+ 616 | | Link 617 PCEP | 618 | | Inter-domain Link 619 | | 620 +---|----v-------+ 621 | | | 622 | | Domain (A) | 623 | \ | 624 | (PCE) - | 625 | |S| | 626 | - | 627 +----------------+ 628 Figure 6 - BRPC Scenario 630 In this use case, a client can use the YANG data model defined in 631 this document to request path computation from the PCE that controls 632 the source of the tunnel. For example, a client can request to the 633 PCE of domain A to compute a path from a source S, within domain A, 634 to a destination D, within domain C. Then PCE of domain A will use 635 PCEP protocol, as per [RFC5441], to compute the path from S to D and 636 in turn gives the final answer to the requester. 638 2.5. Hierarchical PCE scenario 640 [RFC6805] has defined an architecture and extensions to the PCE 641 standard to compute inter-domain path following a hierarchical 642 method. Two new roles have been defined: parent PCE and child PCE. 643 The parent PCE is in charge to coordinate the end-to-end path 644 computation. For that purpose it sends to each child PCE involved in 645 the multi-domain path computation a PCE Request message to obtain the 646 local part of the path. Once received all answer through PCE Response 647 message, the parent PCE will merge the different local parts of the 648 path to achieve the end-to-end path. 650 Figure 7 below shows a typical hierarchical scenario where a parent 651 PCE request end-to-end path to the different child PCE. Note that a 652 PCE could take independently the role of child or parent PCE 653 depending of which PCE will request the path. 655 ----------------------------------------------------------------- 656 | Domain 5 | 657 | ----- | 658 | |PCE 5| | 659 | ----- | 660 | | 661 | ---------------- ---------------- ---------------- | 662 | | Domain 1 | | Domain 2 | | Domain 3 | | 663 | | | | | | | | 664 | | ----- | | ----- | | ----- | | 665 | | |PCE 1| | | |PCE 2| | | |PCE 3| | | 666 | | ----- | | ----- | | ----- | | 667 | | | | | | | | 668 | | ----| |---- ----| |---- | | 669 | | |BN11+---+BN21| |BN23+---+BN31| | | 670 | | - ----| |---- ----| |---- - | | 671 | | |S| | | | | |D| | | 672 | | - ----| |---- ----| |---- - | | 673 | | |BN12+---+BN22| |BN24+---+BN32| | | 674 | | ----| |---- ----| |---- | | 675 | | | | | | | | 676 | | ---- | | | | ---- | | 677 | | |BN13| | | | | |BN33| | | 678 | -----------+---- ---------------- ----+----------- | 679 | \ / | 680 | \ ---------------- / | 681 | \ | | / | 682 | \ |---- ----| / | 683 | ----+BN41| |BN42+---- | 684 | |---- ----| | 685 | | | | 686 | | ----- | | 687 | | |PCE 4| | | 688 | | ----- | | 689 | | | | 690 | | Domain 4 | | 691 | ---------------- | 692 | | 693 ----------------------------------------------------------------- 694 Figure 7 - Hierarchical domain topology from [RFC6805] 696 In this use case, a client can use the YANG data model defined in 697 this document to request to the parent PCE a path from a source S to 698 a destination D. The parent PCE will in turn contact the child PCEs 699 through PCEP protocol to compute the end-to-end path and then return 700 the computed path to the client, using the YANG data model defined in 701 this document. For example the YANG data model can be used to request 702 to PCE5 acting as parent PCE to compute a path from source S, within 703 domain 1, to destination D, within domain 3. PCE5 will contact child 704 PCEs of domain 1, 2 and 3 to obtain local part of the end-to-end path 705 through the PCEP protocol. Once received the PCE Response message, it 706 merges the answers to compute the end-to-end path and send it back to 707 the client. 709 3. Motivations 711 This section provides the motivation for the YANG data model defined 712 in this document. 714 Section 3.1 describes the motivation for a YANG data model to request 715 path computation. 717 Section 3.2 describes the motivation for a YANG data model which 718 complements the TE topology YANG data model defined in [RFC8795]. 720 Section 3.3 describes the motivation for a YANG RPC which complements 721 the TE tunnel YANG data model defined in [TE-TUNNEL]. 723 3.1. Motivation for a YANG Model 725 3.1.1. Benefits of common data models 727 The YANG data model for requesting path computation is closely 728 aligned with the YANG data models that provide (abstract) TE topology 729 information, i.e., [RFC8795] as well as that are used to configure 730 and manage TE tunnels, i.e., [TE-TUNNEL]. 732 There are many benefits in aligning the data model used for path 733 computation requests with the YANG data models used for TE topology 734 information and for TE tunnels configuration and management: 736 o There is no need for an error-prone mapping or correlation of 737 information. 739 o It is possible to use the same endpoint identifiers in path 740 computation requests and in the topology modeling. 742 o The attributes used for path computation constraints are the same 743 as those used when setting up a TE tunnel. 745 3.1.2. Benefits of a single interface 747 The system integration effort is typically lower if a single, 748 consistent interface is used by controllers, i.e., one data modeling 749 language (i.e., YANG) and a common protocol (e.g., NETCONF or 750 RESTCONF). 752 Practical benefits of using a single, consistent interface include: 754 1. Simple authentication and authorization: The interface between 755 different components has to be secured. If different protocols 756 have different security mechanisms, ensuring a common access 757 control model may result in overhead. For instance, there may be a 758 need to deal with different security mechanisms, e.g., different 759 credentials or keys. This can result in increased integration 760 effort. 762 2. Consistency: Keeping data consistent over multiple different 763 interfaces or protocols is not trivial. For instance, the sequence 764 of actions can matter in certain use cases, or transaction 765 semantics could be desired. While ensuring consistency within one 766 protocol can already be challenging, it is typically cumbersome to 767 achieve that across different protocols. 769 3. Testing: System integration requires comprehensive testing, 770 including corner cases. The more different technologies are 771 involved, the more difficult it is to run comprehensive test cases 772 and ensure proper integration. 774 4. Middle-box friendliness: Provider and consumer of path computation 775 requests may be located in different networks, and middle-boxes 776 such as firewalls, NATs, or load balancers may be deployed. In 777 such environments it is simpler to deploy a single protocol. Also, 778 it may be easier to debug connectivity problems. 780 5. Tooling reuse: Implementers may want to implement path computation 781 requests with tools and libraries that already exist in 782 controllers and/or orchestrators, e.g., leveraging the rapidly 783 growing eco-system for YANG tooling. 785 3.1.3. Extensibility 787 Path computation is only a subset of the typical functionality of a 788 controller. In many use cases, issuing path computation requests 789 comes along with the need to access other functionality on the same 790 system. In addition to obtaining TE topology, for instance also 791 configuration of services (set-up/modification/deletion) may be 792 required, as well as: 794 1. Receiving notifications for topology changes as well as 795 integration with fault management 797 2. Performance management such as retrieving monitoring and telemetry 798 data 800 3. Service assurance, e.g., by triggering OAM functionality 802 4. Other fulfilment and provisioning actions beyond tunnels and 803 services, such as changing QoS configurations 805 YANG is a very extensible and flexible data modeling language that 806 can be used for all these use cases. 808 3.2. Interactions with TE topology 810 The use cases described in section 2 have been described assuming 811 that the topology view exported by each underlying controller to its 812 client is aggregated using the "virtual node model", defined in 813 [RFC7926]. 815 TE topology information, e.g., as provided by [RFC8795], could in 816 theory be used by an underlying controller to provide TE information 817 to its client thus allowing a PCE available within its client to 818 perform multi-domain path computation on its own, without requesting 819 path computations to the underlying controllers. 821 In case the client does not implement a PCE function, as discussed in 822 section 1, it could not perform path computation based on TE topology 823 information and would instead need to request path computation from 824 the underlying controllers to get the information it needs to find 825 the optimal end-to-end path. 827 In case the client implements a PCE function, as discussed in section 828 1, the TE topology information needs to be complete and accurate, 829 which would bring to scalability issues. 831 Using TE topology to provide a "virtual link model" aggregation, as 832 described in [RFC7926], may be insufficient, unless the aggregation 833 provides a complete and accurate information, which would still cause 834 scalability issues, as described in sections 3.2.1 below. 836 Using TE topology abstraction, as described in [RFC7926], may lead to 837 compute an unfeasible path, as described in [RFC7926] in section 838 3.2.2 below. 840 Therefore when computing an optimal multi-domain path, there is a 841 scalability trade-off between providing complete and accurate TE 842 information and the number of path computation requests to the 843 underlying controllers. 845 The TE topology information used, in a complimentary way, to reduce 846 the number for path computation requests to the underlying 847 controllers, are described in section 3.2.3 below. 849 3.2.1. TE topology aggregation 851 Using the TE topology model, as defined in [RFC8795], the underlying 852 controller can export the whole TE domain as a single TE node with a 853 "detailed connectivity matrix" (which provides specific TE 854 attributes, such as delay, Shared Risk Link Groups (SRLGs) and other 855 TE metrics, between each ingress and egress links). 857 The information provided by the "detailed connectivity matrix" would 858 be equivalent to the information that should be provided by "virtual 859 link model" as defined in [RFC7926]. 861 For example, in the Packet/Optical Integration use case, described in 862 section 2.1, the Optical Domain Controller can make the information 863 shown in Figure 3 available to the Packet/Optical Coordinator as part 864 of the TE topology information and the Packet/Optical Coordinator 865 could use this information to calculate on its own the optimal path 866 between R1 and R2, without requesting any additional information to 867 the Optical Domain Controller. 869 However, when designing the amount of information to provide within 870 the "detailed connectivity matrix", there is a tradeoff to be 871 considered between accuracy (i.e., providing "all" the information 872 that might be needed by the PCE available within the client) and 873 scalability. 875 Figure 8 below shows another example, similar to Figure 3, where 876 there are two possible Optical paths between VP1 and VP4 with 877 different properties (e.g., available bandwidth and cost). 879 ............................ 880 : /--------------------\ : 881 : / cost=65 \ : 882 :/ available-bw=10G \: 883 O VP1 VP4 O 884 cost=10 /:\ /:\ cost=10 885 / : \----------------------/ : \ 886 +----+ / : cost=50 : \ +----+ 887 | |/ : available-bw=2G : \| | 888 | R1 | : : | R2 | 889 | |\ : : /| | 890 +----+ \ : /--------------------\ : / +----+ 891 \ : / cost=55 \ : / 892 cost=5 \:/ available-bw=3G \:/ cost=5 893 O VP2 VP5 O 894 : : 895 :..........................: 897 Figure 8 - Packet/Optical Integration path computation 898 example with multiple choices 900 If the information in the "detailed connectivity matrix" is not 901 complete/accurate, we can have the following drawbacks: 903 o If only the VP1-VP4 path with available bandwidth of 2 Gb/s and 904 cost 50 is reported, the client's PCE will fail to compute a 5 905 Gb/s path between routers R1 and R2, although this would be 906 feasible; 908 o If only the VP1-VP4 path with available bandwidth of 10 Gb/s and 909 cost 60 is reported, the client's PCE will compute, as optimal, 910 the 1 Gb/s path between R1 and R2 going through the VP2-VP5 path 911 within the optical domain while the optimal path would actually be 912 the one going thought the VP1-VP4 sub-path (with cost 50) within 913 the optical domain. 915 Reporting all the information, as in Figure 8, using the "detailed 916 connectivity matrix", is quite challenging from a scalability 917 perspective. The amount of this information is not just based on 918 number of end points (which would scale as N-square), but also on 919 many other parameters, including client rate, user 920 constraints/policies for the service, e.g. max latency < N ms, max 921 cost, etc., exclusion policies to route around busy links, min 922 Optical Signal to Noise Ratio (OSNR) margin, max pre-Forward Error 923 Correction (FEC) Bit Error Rate (BER) etc. All these constraints 924 could be different based on connectivity requirements. 926 Examples of how the "detailed connectivity matrix" can be dimensioned 927 are described in Appendix A. 929 It is also worth noting that the "connectivity matrix" has been 930 originally defined in Wavelength Switched Optical Networks (WSON), 931 [RFC7446], to report the connectivity constrains of a physical node 932 within the Wavelength Division Multiplexing (WDM) network: the 933 information it contains is pretty "static" and therefore, once taken 934 and stored in the TE data base, it can be always being considered 935 valid and up-to-date in path computation request. 937 The "connectivity matrix" is sometimes confused with "optical reach 938 table" that contain multiple (e.g. k-shortest) regen-free reachable 939 paths for every A-Z node combination in the network. Optical reach 940 tables can be calculated offline, utilizing vendor optical design and 941 planning tools, and periodically uploaded to the Controller: these 942 optical path reach tables are fairly static. However, to get the 943 connectivity matrix, between any two sites, either a regen free path 944 can be used, if one is available, or multiple regen free paths are 945 concatenated to get from the source to the destination, which can be 946 a very large combination. Additionally, when the optical path within 947 optical domain needs to be computed, it can result in different paths 948 based on input objective, constraints, and network conditions. In 949 summary, even though "optical reach table" is fairly static, which 950 regen free paths to build the connectivity matrix between any source 951 and destination is very dynamic, and is done using very sophisticated 952 routing algorithms. 954 Using the "basic connectivity matrix" with an abstract node to 955 abstract the information regarding the connectivity constraints of an 956 Optical domain, would make this information more "dynamic" since the 957 connectivity constraints of an optical domain can change over time 958 because some optical paths that are feasible at a given time may 959 become unfeasible at a later time when e.g., another optical path is 960 established. 962 The information in the "detailed connectivity matrix" is even more 963 dynamic since the establishment of another optical path may change 964 some of the parameters (e.g., delay or available bandwidth) in the 965 "detailed connectivity matrix" while not changing the feasibility of 966 the path. 968 There is therefore the need to keep the information in the "detailed 969 connectivity matrix" updated which means that there another tradeoff 970 between the accuracy (i.e., providing "all" the information that 971 might be needed by the client's PCE) and having up-to-date 972 information. The more the information is provided and the longer it 973 takes to keep it up-to-date which increases the likelihood that the 974 client's PCE computes paths using not updated information. 976 It seems therefore quite challenging to have a "detailed connectivity 977 matrix" that provides accurate, scalable and updated information to 978 allow the client's PCE to take optimal decisions by its own. 980 Considering the example in Figure 8 with the approach defined in this 981 document, the client, when it needs to set up an end-to-end path, it 982 can request the Optical Domain Controller to compute a set of optimal 983 paths (e.g., for VP1-VP4 and VP2-VP5) and take decisions based on the 984 information received: 986 o When setting up a 5 Gb/s path between routers R1 and R2, the 987 Optical Domain Controller may report only the VP1-VP4 path as the 988 only feasible path: the Packet/Optical Coordinator can 989 successfully set up the end-to-end path passing though this 990 optical path; 992 o When setting up a 1 Gb/s path between routers R1 and R2, the 993 Optical Domain Controller (knowing that the path requires only 1 994 Gb/s) can report both the VP1-VP4 path, with cost 50, and the VP2- 995 VP5 path, with cost 65. The Packet/Optical Coordinator can then 996 compute the optimal path which is passing thought the VP1-VP4 sub- 997 path (with cost 50) within the optical domain. 999 3.2.2. TE topology abstraction 1001 Using the TE topology model, as defined in [RFC8795], the underlying 1002 controller can export to its client an abstract TE topology, composed 1003 by a set of TE nodes and TE links, representing the abstract view of 1004 the topology under its control. 1006 For example, in the multi-domain TE network use case, described in 1007 section 2.2, the TE Domain Controller 1 can export a TE topology 1008 encompassing the TE nodes A, B, C and D and the TE links 1009 interconnecting them. In a similar way, the TE Domain Controller 2 1010 can export a TE topology encompassing the TE nodes E, F, G and H and 1011 the TE links interconnecting them. 1013 In this example, for simplicity reasons, each abstract TE node maps 1014 with each physical node, but this is not necessary. 1016 In order to set up a multi-domain TE path (e.g., between nodes A and 1017 H), the Multi-Domain Controller can compute by its own an optimal 1018 end-to-end path based on the abstract TE topology information 1019 provided by the domain controllers. For example: 1021 o Multi-Domain Controller can compute, based on its own TED data, 1022 the optimal multi-domain path being A-B-C-E-G-H, and then request 1023 the TE Domain Controllers to set up the A-B-C and E-G-H intra- 1024 domain paths 1026 o But, during path set-up, the TE Domain Controller may find out 1027 that A-B-C intra-domain path is not feasible (as discussed in 1028 section 2.2, in optical networks it is typical to have some paths 1029 not being feasible due to optical constraints that are known only 1030 by the Optical Domain Controller), while only the path A-B-D is 1031 feasible 1033 o So what the Multi-Domain Controller has computed is not good and 1034 it needs to re-start the path computation from scratch 1036 As discussed in section 3.2.1, providing more extensive abstract 1037 information from the TE Domain Controllers to the Multi-Domain 1038 Controller may lead to scalability problems. 1040 In a sense this is similar to the problem of routing and wavelength 1041 assignment within an optical domain. It is possible to do first 1042 routing (step 1) and then wavelength assignment (step 2), but the 1043 chances of ending up with a good path is low. Alternatively, it is 1044 possible to do combined routing and wavelength assignment, which is 1045 known to be a more optimal and effective way for optical path set-up. 1046 Similarly, it is possible to first compute an abstract end-to-end 1047 path within the Multi-Domain Controller (step 1) and then compute an 1048 intra-domain path within each optical domain (step 2), but there are 1049 more chances not to find a path or to get a suboptimal path than 1050 performing multiple per-domain path computations and then stitch 1051 them. 1053 3.2.3. Complementary use of TE topology and path computation 1055 As discussed in section 2.2, there are some scalability issues with 1056 path computation requests in a multi-domain TE network with many TE 1057 domains, in terms of the number of requests to send to the TE Domain 1058 Controllers. It would therefore be worthwhile using the abstract TE 1059 topology information provided by the TE Domain Controllers to limit 1060 the number of requests. 1062 An example can be described considering the multi-domain abstract TE 1063 topology shown in Figure 9. In this example, an end-to-end TE path 1064 between domains A and F needs to be set up. The transit TE domain 1065 should be selected between domains B, C, D and E. 1067 .........B......... 1068 : _ _ _ _ _ _ _ _ : 1069 :/ \: 1070 +---O NOT FEASIBLE O---+ 1071 cost=5| : : | 1072 ......A...... | :.................: | ......F...... 1073 : : | | : : 1074 : O-----+ .........C......... +-----O : 1075 : : : /-------------\ : : : 1076 : : :/ \: : : 1077 : cost<=20 O---------O cost <= 30 O---------O cost<=20 : 1078 : /: cost=5 : : cost=5 :\ : 1079 : /------/ : :.................: : \------\ : 1080 : / : : \ : 1081 :/ cost<=25 : .........D......... : cost<=25 \: 1082 O-----------O-------+ : /-------------\ : +-------O-----------O 1083 :\ : cost=5| :/ \: |cost=5 : /: 1084 : \ : +-O cost <= 30 O-+ : / : 1085 : \------\ : : : : /------/ : 1086 : cost>=30 \: :.................: :/ cost>=30 : 1087 : O-----+ +-----O : 1088 :...........: | .........E......... | :...........: 1089 | : /-------------\ : | 1090 cost=5| :/ \: |cost=5 1091 +---O cost >= 30 O---+ 1092 : : 1093 :.................: 1095 Figure 9 - Multi-domain with many domains (Topology 1096 information) 1098 The actual cost of each intra-domain path is not known a priori from 1099 the abstract topology information. The Multi-Domain Controller only 1100 knows, from the TE topology provided by the underlying domain 1101 controllers, the feasibility of some intra-domain paths and some 1102 upper-bound and/or lower-bound cost information. With this 1103 information, together with the cost of inter-domain links, the Multi- 1104 Domain Controller can understand by its own that: 1106 o Domain B cannot be selected as the path connecting domains A and F 1107 is not feasible; 1109 o Domain E cannot be selected as a transit domain since it is known 1110 from the abstract topology information provided by domain 1111 controllers that the cost of the multi-domain path A-E-F (which is 1112 100, in the best case) will be always be higher than the cost of 1113 the multi-domain paths A-D-F (which is 90, in the worst case) and 1114 A-C-F (which is 80, in the worst case). 1116 Therefore, the Multi-Domain Controller can understand by its own that 1117 the optimal multi-domain path could be either A-D-F or A-C-F but it 1118 cannot know which one of the two possible option actually provides 1119 the optimal end-to-end path. 1121 The Multi-Domain Controller can therefore request path computation 1122 only to the TE Domain Controllers A, D, C and F (and not to all the 1123 possible TE Domain Controllers). 1125 .........B......... 1126 : : 1127 +---O O---+ 1128 ......A...... | :.................: | ......F...... 1129 : : | | : : 1130 : O-----+ .........C......... +-----O : 1131 : : : /-------------\ : : : 1132 : : :/ \: : : 1133 : cost=15 O---------O cost = 25 O---------O cost=10 : 1134 : /: cost=5 : : cost=5 :\ : 1135 : /------/ : :.................: : \------\ : 1136 : / : : \ : 1137 :/ cost=10 : .........D......... : cost=15 \: 1138 O-----------O-------+ : /-------------\ : +-------O-----------O 1139 : : cost=5| :/ \: |cost=5 : : 1140 : : +-O cost = 15 O-+ : : 1141 : : : : : : 1142 : : :.................: : : 1143 : O-----+ +-----O : 1144 :...........: | .........E......... | :...........: 1145 | : : | 1146 +---O O---+ 1147 :.................: 1149 Figure 10 - Multi-domain with many domains (Path Computation 1150 information) 1152 Based on these requests, the Multi-Domain Controller can know the 1153 actual cost of each intra-domain paths which belongs to potential 1154 optimal end-to-end paths, as shown in Figure 10, and then compute the 1155 optimal end-to-end path (e.g., A-D-F, having total cost of 50, 1156 instead of A-C-F having a total cost of 70). 1158 3.3. Path Computation RPC 1160 The TE tunnel YANG data model, defined in [TE-TUNNEL], can support 1161 the need to request path computation, as described in section 5.1.2 1162 of [TE-TUNNEL]. 1164 This solution is stateful since the state of each created "compute- 1165 only" TE tunnel path needs to be maintained, in the YANG datastores 1166 (at least in the running datastore and operational datastore), and 1167 updated, when underlying network conditions change. 1169 The RPC mechanism allows requesting path computation using a simple 1170 atomic operation, without creating any state in the YANG datastores, 1171 and it is the natural option/choice, especially with stateless PCE. 1173 It is very useful to provide both the options of using an RPC as well 1174 as of setting up TE tunnel paths in "compute-only" mode. It is 1175 suggested to use the RPC as much as possible and to rely on 1176 "compute-only" TE tunnel paths, when really needed. 1178 Using the RPC solution would imply that the underlying controller 1179 (e.g., a PNC) computes a path twice during the process to set up an 1180 LSP: at time T1, when its client (e.g., an MDSC) sends a path 1181 computation RPC request to it, and later, at time T2, when the same 1182 client (MDSC) creates a TE tunnel requesting the set-up of the LSP. 1183 The underlying assumption is that, if network conditions have not 1184 changed, the same path that has been computed at time T1 is also 1185 computed at time T2 by the underlying controller (e.g. PNC) and 1186 therefore the path that is set up at time T2 is exactly the same path 1187 that has been computed at time T1. 1189 However, since the operation is stateless, there is no guarantee that 1190 the returned path would still be available when path set-up is 1191 requested: this does not cause major issues when the time between 1192 path computation and path set-up is short (especially if compared 1193 with the time that would be needed to update the information of a 1194 very detailed connectivity matrix). 1196 In most of the cases, there is even no need to guarantee that the 1197 path that has been set up is the exactly same as the path that has 1198 been returned by path computation, especially if it has the same or 1199 even better metrics. Depending on the abstraction level applied by 1200 the server, the client may also not know the actual computed path. 1202 The most important requirement is that the required global objectives 1203 (e.g., multi-domain path metrics and constraints) are met. For this 1204 reason a path verification phase is always necessary to verify that 1205 the actual path that has been set up meets the global objectives (for 1206 example in a multi-domain network, the resulting end-to-end path 1207 meets the required end-to-end metrics and constraints). 1209 In most of the cases, even if the path being set up is not exactly 1210 the same as the path returned by path computation, its metrics and 1211 constraints are "good enough" and the path verification passes 1212 successfully. In the few corner cases where the path verification 1213 fails, it is possible repeat the whole process (path computation, 1214 path set-up and path verification). 1216 In case it is required to set up at T2 exactly the same path computed 1217 at T1, the RPC solution should not be used and, instead, a "compute- 1218 only" TE tunnel path should be set up, allowing also notifications in 1219 case the computed path has been changed. 1221 In this case, at time T1, the client (MDSC) creates a TE tunnel in a 1222 compute-only mode in the running datastore and later, at time T2, 1223 changes the configuration of that TE tunnel (not to be any more in a 1224 compute-only mode) to trigger the set-up of the LSP over the path 1225 which have been computed at time T1 and reported in the operational 1226 datastore. 1228 It is worth noting that also using the "compute-only" TE tunnel path, 1229 although increasing the likelihood that the computed path is 1230 available at path set-up, does not guarantee that because 1231 notifications may not be reliable or delivered on time. Path 1232 verification is needed also in this case. 1234 The solution based on "compute-only" TE tunnel path has also the 1235 following drawbacks: 1237 o Several messages required for any path computation 1239 o Requires persistent storage in the underlying controller 1240 o Need for garbage collection for stranded paths 1242 o Process burden to detect changes on the computed paths in order to 1243 provide notifications update 1245 3.3.1. Temporary reporting of the computed path state 1247 This section describes an optional extension to the stateless 1248 behavior of the path computation RPC, where the underlying 1249 controller, after having received a path computation RPC request, 1250 maintains some "transient state" associated with the computed path, 1251 allowing the client to request the set-up of exactly that path, if 1252 still available. 1254 This is similar to the "compute-only" TE tunnel path solution but, to 1255 avoid the drawbacks of the stateful approach, is leveraging the path 1256 computation RPC and the separation between configuration and 1257 operational datastore, as defined in the NMDA architecture [RFC8342]. 1259 The underlying controller, after having computed a path, as requested 1260 by a path computation RPC, also creates a TE tunnel instance within 1261 the operational datastore, to store that computed path. This would be 1262 similar to a "compute-only" TE tunnel path, with the only difference 1263 that there is no associated TE tunnel instance within the running 1264 datastore. 1266 Since the underlying controller stores in the operational datastore 1267 the computed path based on an abstract topology it exposes, it also 1268 remembers, internally, which is the actual native path (physical 1269 path), within its native topology (physical topology), associated 1270 with that compute-only TE tunnel instance. 1272 Afterwards, the client (e.g., MDSC) can request the set-up of that 1273 specific path by creating a TE tunnel instance (not in compute-only 1274 mode) in the running datastore using the same tunnel-name of 1275 the existing TE tunnel in the operational datastore: this will 1276 trigger the underlying controller to set up that path, if still 1277 available. 1279 There are still cases where the path being set up is not exactly the 1280 same as the path that has been computed: 1282 o When the tunnel is configured with path constraints which are not 1283 compatible with the computed path; 1285 o When the tunnel set-up is requested after the resources of the 1286 computed path are no longer available; 1288 o When the tunnel set-up is requested after the computed path is no 1289 longer known (e.g. due to a server reboot) by the underlying 1290 controller. 1292 In all these cases, the underlying controller should compute and set 1293 up a new path. 1295 Therefore the "path verification" phase, as described in section 3.3 1296 above, is always needed to check that the path that has been set up 1297 is still "good enough". 1299 Since this new approach is not completely stateless, garbage 1300 collection is implemented using a timeout that, when it expires, 1301 triggers the removal of the computed path from the operational 1302 datastore. This operation is fully controlled by the underlying 1303 controller without the need for any action to be taken by the client 1304 that is not able to act on the operational datastore. The default 1305 value of this timeout is 10 minutes but a different value may be 1306 configured by the client. 1308 In addition, it is possible for the client to tag each path 1309 computation request with a transaction-id allowing for a faster 1310 removal of all the paths associated with a transaction-id, without 1311 waiting for their timers to expire. 1313 The underlying controller can remove from the operational datastore 1314 all the paths computed with a given transaction-id which have not 1315 been set up either when it receives a Path Delete RPC request for 1316 that transaction-id or, automatically, right after the set-up up of a 1317 path that has been previously computed with that transaction-id. 1319 This possibility is useful when multiple paths are computed but, at 1320 most, only one is set up (e.g., in multi-domain path computation 1321 scenario scenarios). After the selected path has been set up (e.g, in 1322 one domain during multi-domain path set-up), all the other 1323 alternative computed paths can be automatically deleted by the 1324 underlying controller (since no longer needed). The client can also 1325 request, using the Path Delete RPC request, the underlying controller 1326 to remove all the computed paths, if none of them is going to be set 1327 up (e.g., in a transit domain not being selected by multi-domain path 1328 computation and so not being automatically deleted). 1330 This approach is complimentary and not alternative to the timer which 1331 is always needed to avoid stranded computed paths being stored in the 1332 operational datastore when no path is set up and no explicit Path 1333 Delete RPC request is received. 1335 4. Path computation and optimization for multiple paths 1337 There are use cases, where it is advantageous to request path 1338 computation for a set of paths, through a network or through a 1339 network domain, using a single request [RFC5440]. 1341 In this case, sending a single request for multiple path 1342 computations, instead of sending multiple requests for each path 1343 computation, would reduce the protocol overhead and it would consume 1344 less resources (e.g., threads in the client and server). 1346 In the context of a typical multi-domain TE network, there could 1347 multiple choices for the ingress/egress points of a domain and the 1348 Multi-Domain Controller needs to request path computation between all 1349 the ingress/egress pairs to select the best pair. For example, in the 1350 example of section 2.2, the Multi-Domain Controller needs to request 1351 the TE Network Controller 1 to compute the A-C and the A-D paths and 1352 to the TE Network Controller 2 to compute the E-H and the F-H paths. 1354 It is also possible that the Multi-Domain Controller receives a 1355 request to set up a group of multiple end to end connections. The 1356 Multi-Domain Controller needs to request each TE domain Controller to 1357 compute multiple paths, one (or more) for each end to end connection. 1359 There are also scenarios where it can be needed to request path 1360 computation for a set of paths in a synchronized fashion. 1362 One example could be computing multiple diverse paths. Computing a 1363 set of diverse paths in an unsynchronized fashion, leads to the 1364 possibility of not being able to satisfy the diversity requirement. 1365 In this case, it is preferable to compute a sub-optimal primary path 1366 for which a diversely routed secondary path exists. 1368 There are also scenarios where it is needed to request optimizing a 1369 set of paths using objective functions that apply to the whole set of 1370 paths, see [RFC5541], e.g. to minimize the sum of the costs of all 1371 the computed paths in the set. 1373 5. YANG data model for requesting Path Computation 1375 This document define a YANG RPC to request path computation as an 1376 "augmentation" of tunnel-rpc, defined in [TE-TUNNEL]. This model 1377 provides the RPC input attributes that are needed to request path 1378 computation and the RPC output attributes that are needed to report 1379 the computed paths. 1381 augment /te:tunnels-path-compute/te:input/te:path-compute-info: 1382 +-- path-request* [request-id] 1383 | +-- request-id uint32 1384 | ........... 1386 augment /te:tunnels-path-compute/te:output/te:path-compute-result: 1387 +--ro response* [response-id] 1388 +--ro response-id uint32 1389 +--ro computed-paths-properties 1390 | +--ro computed-path-properties* [k-index] 1391 | +--ro k-index uint8 1392 | +--ro path-properties 1393 | ........... 1395 This model extensively re-uses the grouping defined in [TE-TUNNEL] 1396 and [RFC8776] to ensure maximal syntax and semantics commonality. 1398 This YANG data model allows one RPC to include multiple path 1399 requests, each path request being identified by a request-id. 1400 Therefore, one RPC can return multiple responses, one for each path 1401 request, being identified by a response-id equal to the corresponding 1402 request-id. Each response reports one or more computed paths, as 1403 requested by the k-requested-paths attribute. By default, each 1404 response reports one computed path. 1406 5.1. Synchronization of multiple path computation requests 1408 The YANG data model permits the synchronization of a set of multiple 1409 path requests (identified by specific request-id) all related to a 1410 "svec" container emulating the syntax of the Synchronization VECtor 1411 (SVEC) PCEP object, defined in [RFC5440]. 1413 +-- synchronization* [] 1414 +-- svec 1415 | +-- relaxable? boolean 1416 | +-- disjointness? te-path-disjointness 1417 | +-- request-id-number* uint32 1418 +-- svec-constraints 1419 | +-- path-metric-bound* [metric-type] 1420 | +-- metric-type identityref 1421 | +-- upper-bound? uint64 1422 +-- path-srlgs-lists 1423 | +-- path-srlgs-list* [usage] 1424 | +-- usage identityref 1425 | +-- values* srlg 1426 +-- path-srlgs-names 1427 | +-- path-srlgs-name* [usage] 1428 | +-- usage identityref 1429 | +-- names* string 1430 +-- exclude-objects 1431 | +-- excludes* [] 1432 | +-- (type)? 1433 | +--:(numbered-node-hop) 1434 | | +-- numbered-node-hop 1435 | | +-- node-id te-node-id 1436 | | +-- hop-type? te-hop-type 1437 | +--:(numbered-link-hop) 1438 | | +-- numbered-link-hop 1439 | | +-- link-tp-id te-tp-id 1440 | | +-- hop-type? te-hop-type 1441 | | +-- direction? te-link-direction 1442 | +--:(unnumbered-link-hop) 1443 | | +-- unnumbered-link-hop 1444 | | +-- link-tp-id te-tp-id 1445 | | +-- node-id te-node-id 1446 | | +-- hop-type? te-hop-type 1447 | | +-- direction? te-link-direction 1448 | +--:(as-number) 1449 | | +-- as-number-hop 1450 | | +-- as-number inet:as-number 1451 | | +-- hop-type? te-hop-type 1452 | +--:(label) 1453 | +-- label-hop 1454 | +-- te-label 1455 | +-- (technology)? 1456 | | +--:(generic) 1457 | | +-- generic? 1458 | | rt-types:generalized-label 1459 | +-- direction? te-label-direction 1460 +-- optimizations 1461 +-- (algorithm)? 1462 +--:(metric) {te-types:path-optimization-metric}? 1463 | +-- optimization-metric* [metric-type] 1464 | +-- metric-type identityref 1465 | +-- weight? uint8 1466 +--:(objective-function) 1467 {te-types:path-optimization-objective- 1468 function}? 1469 +-- objective-function 1470 +-- objective-function-type? identityref 1472 The model, in addition to the metric types, defined in [RFC8776], 1473 which can be applied to each individual path request, supports also 1474 additional metric types, which apply to a set of synchronized 1475 requests, as referenced in [RFC5541]. These additional metric types 1476 are defined by the following YANG identities: 1478 o svec-metric-type: base YANG identity from which cumulative metric 1479 types identities are derived. 1481 o svec-metric-cumul-te: cumulative TE cost metric type, as defined 1482 in [RFC5541]. 1484 o svec-metric-cumul-igp: cumulative IGP cost metric type, as defined 1485 in [RFC5541]. 1487 o svec-metric-cumul-hop: cumulative Hop metric type, representing 1488 the cumulative version of the Hop metric type defined in 1489 [RFC8776]. 1491 o svec-metric-aggregate-bandwidth-consumption: aggregate bandwidth 1492 consumption metric type, as defined in [RFC5541]. 1494 o svec-metric-load-of-the-most-loaded-link: load of the most loaded 1495 link metric type, as defined in [RFC5541]. 1497 5.2. Returned metric values 1499 This YANG data model provides a way to return the values of the 1500 metrics computed by the path computation in the output of RPC, 1501 together with other important information (e.g. srlg, affinities, 1502 explicit route), emulating the syntax of the "C" flag of the "METRIC" 1503 PCEP object [RFC5440]: 1505 | +--ro path-properties 1506 | +--ro path-metric* [metric-type] 1507 | | +--ro metric-type identityref 1508 | | +--ro accumulative-value? uint64 1509 | +--ro path-affinities-values 1510 | | +--ro path-affinities-value* [usage] 1511 | | +--ro usage identityref 1512 | | +--ro value? admin-groups 1513 | +--ro path-affinity-names 1514 | | +--ro path-affinity-name* [usage] 1515 | | +--ro usage identityref 1516 | | +--ro affinity-name* [name] 1517 | | +--ro name string 1518 | +--ro path-srlgs-lists 1519 | | +--ro path-srlgs-list* [usage] 1520 | | +--ro usage identityref 1521 | | +--ro values* srlg 1522 | +--ro path-srlgs-names 1523 | | +--ro path-srlgs-name* [usage] 1524 | | +--ro usage identityref 1525 | | +--ro names* string 1526 | +--ro path-route-objects 1527 | ........... 1529 It also allows the client to request which information (metrics, srlg 1530 and/or affinities) should be returned: 1532 | +-- request-id uint32 1533 | ........... 1534 | +-- requested-metrics* [metric-type] 1535 | | +-- metric-type identityref 1536 | +-- return-srlgs? boolean 1537 | +-- return-affinities? boolean 1538 | ........... 1540 This feature is essential for path computation in a multi-domain TE 1541 network as described in section 2.2. In this case, the metrics 1542 returned by a path computation requested to a given underlying 1543 controller must be used by the client to compute the best end-to-end 1544 path. If they are missing, the client cannot compare different paths 1545 calculated by the underlying controllers and choose the best one for 1546 the optimal end-to-end (e2e) path. 1548 5.3. Multiple Paths Requests for the same TE tunnel 1550 The YANG data model allows including multiple requests for different 1551 paths intended to be used within the same tunnel or within different 1552 tunnels. 1554 When multiple requested paths are intended to be used within the same 1555 tunnel (e.g., requesting path computation for the primary and 1556 secondary paths of a protected tunnel), the set of attributes that 1557 are intended to be configured on per-tunnel basis rather than on per- 1558 path basis are common to all these path requests. These attributes 1559 includes both attributes which can be configured only a per-tunnel 1560 basis (e.g., tunnel-name, source/destination TTP, encoding and 1561 switching-type) as well attributes which can be configured both on a 1562 per-tunnel and on a per-path basis (e.g., the te-bandwidth or the 1563 associations). 1565 Therefore, a tunnel-attributes list is defined, within the path 1566 computation request RPC: 1568 +-- tunnel-attributes* [tunnel-name] 1569 | +-- tunnel-name string 1570 | +-- encoding? identityref 1571 | +-- switching-type? identityref 1572 | ........... 1574 The path requests that are intended to be used within the same tunnel 1575 should reference the same entry in the tunnel-attributes list. This 1576 allows: 1578 o avoiding repeating the same set of per-tunnel parameters on 1579 multiple requested paths; 1581 o the server to understand what attributes are intended to be 1582 configured on a per-tunnel basis (e.g., the te-bandwidth 1583 configured in the tunnel-attributes) and what attributes are 1584 intended to be configured on a per-path basis(e.g., the te- 1585 bandwidth configured in the path-request). This could be useful 1586 especially when the server also creates a TE tunnel instance 1587 within the operational datastore to report the computed paths, as 1588 described in section 3.3.1: in this case, the tunnel-name is also 1589 used as the suggested name for that TE tunnel instance. 1591 The YANG data model allows also including requests for paths intended 1592 to modify existing tunnels (e.g., adding a protection path for an 1593 existing un-protected tunnel). In this case, the per-tunnel 1594 attributes are already provided in an existing TE tunnel instance and 1595 do not need to be re-configured in the path computation request RPC. 1596 Therefore, these requests should reference an existing TE tunnel 1597 instance. 1599 It is also possible to request computing paths without indicating in 1600 which tunnel they are intended to be used (e.g., in case of an 1601 unprotected tunnel). In this case, the per-tunnel attributes could be 1602 provided together with the per-path attributes in the path request, 1603 without using the tunnel-attributes list. 1605 The choices below are defined to distinguish the cases above: 1607 o whether the per-tunnel attributes are configured by reference 1608 (providing a leafref), to: 1610 o either a TE tunnel instance, if it exists; 1612 o or to an entry of the tunnel-attributes list, if the TE tunnel 1613 instance does not exist; 1615 o or by value, providing the set of tunnel attributes within the 1616 path request: 1618 | +-- (tunnel-attributes)? 1619 | | +--:(reference) 1620 | | | +-- tunnel-reference 1621 | | | +-- (tunnel-exist)? 1622 | | | | +--:(tunnel-ref) 1623 | | | | | +-- tunnel-ref te:tunnel-ref 1624 | | | | +--:(tunnel-attributes-ref) 1625 | | | | +-- tunnel-attributes-ref leafref 1626 | | ........... 1627 | | +--:(value) 1628 | | +-- tunnel-name? string 1629 | | ........... 1630 | | +-- encoding? identityref 1631 | | +-- switching-type? identityref 1632 | | ........... 1634 5.3.1. Tunnel attributes specified by value 1636 The (value) case provides the set of attributes that are configured 1637 only on per-tunnel basis (e.g., tunnel-name, source/destination TTP, 1638 encoding and switching-type). 1640 In this case, it is assumed that the requested path will be the only 1641 path within a tunnel. 1643 If the requested path is a transit segment of a multi-domain end-to- 1644 end path, it can be of any type (primary, secondary, reverse-primary 1645 or reverse-secondary), as specified by the (path-role) choice: 1647 | | +-- (path-role)? 1648 | | | +--:(primary-path) 1649 | | | +--:(secondary-path) 1650 | | | | +-- secondary-path! 1651 | | | | +-- primary-path-name? string 1652 | | | +--:(primary-reverse-path) 1653 | | | | +-- primary-reverse-path! 1654 | | | | +-- primary-path-name? string 1655 | | | +--:(secondary-reverse-path) 1656 | | | +-- secondary-reverse-path! 1657 | | | +-- primary-path-name? string 1658 | | | +-- primary-reverse-path-name? string 1660 In all the other cases, the requested path can only be a primary 1661 path. 1663 The secondary-path, the primary-reverse-path and the secondary- 1664 reverse-path are presence container used to indicate the role of the 1665 path: by default, the path is assumed to be a primary path. 1667 They optionally can contain the name of the primary-path under which 1668 the requested path could be associated within the YANG tree structure 1669 defined in [TE-TUNNEL], which could be useful when the server also 1670 creates a TE tunnel instance within the operational datastore to 1671 report the computed paths, as described in section 3.3.1: in this 1672 case, the tunnel-name and the path names are also used as the 1673 suggested name for that TE tunnel and path instances. 1675 5.3.2. Tunnel attributes specified by reference 1677 The (reference) case provides the information needed to associate 1678 multiple path requests that are intended to be used within the same 1679 tunnel. 1681 In order to indicate the role of the path being requested within the 1682 intended tunnel (e.g., primary or secondary path), the (path-role) 1683 choice is defined: 1685 | | | +-- (path-role) 1686 | | | +--:(primary-path) 1687 | | | | +-- primary-path! 1688 | | | | ........... 1689 | | | +--:(secondary-path) 1690 | | | | +-- secondary-path 1691 | | | | ........... 1692 | | | +--:(primary-reverse-path) 1693 | | | | +-- primary-reverse-path 1694 | | | | ........... 1695 | | | +--:(secondary-reverse-path) 1696 | | | +-- secondary-reverse-path 1697 | | | ........... 1699 The primary-path is a presence container used to indicate that the 1700 requested path is intended to be used as a primary path. It can also 1701 contain some attributes which are configured only on primary paths 1702 (e.g., the k-requested-paths). 1704 The secondary-path container indicates that the requested path is 1705 intended to be used as a secondary path and it contains at least 1706 references to one or more primary paths which can use it as a 1707 candidate secondary path: 1709 | | | | +-- secondary-path 1710 | | | | ........... 1711 | | | | +-- primary-path-ref* [] 1712 | | | | +-- (primary-path-exist)? 1713 | | | | +--:(path-ref) 1714 | | | | | +-- primary-path-ref leafref 1715 | | | | +--:(path-request-ref) 1716 | | | | +-- path-request-ref leafref 1718 A requested secondary path can reference any requested primary paths, 1719 and, in case they are intended to be used within an existing TE 1720 tunnel, it could also reference any existing primary-paths. 1722 The secondary-path container can also contain some attributes which 1723 are configured only on secondary paths (e.g., the protection-type). 1725 The primary-reverse-path container indicates that the requested path 1726 is intended to be used as a primary reverse path and it contains only 1727 the reference to the primary path which is intended to use it as a 1728 reverse path: 1730 | | | | +-- primary-reverse-path 1731 | | | | +-- (primary-path-exist)? 1732 | | | | +--:(path-ref) 1733 | | | | | +-- primary-path-ref leafref 1734 | | | | +--:(path-request-ref) 1735 | | | | +-- path-request-ref leafref 1737 A requested primary reverse path can reference either a requested 1738 primary path, or, in case it is intended to be used within an 1739 existing TE tunnel, an existing primary-path. 1741 The secondary-reverse-path container indicates that the requested 1742 path is intended to be used as a secondary reverse path and it 1743 contains at least references to one or more primary paths, whose 1744 primary reverse path can use it as a candidate secondary reverse 1745 path: 1747 | | | +-- secondary-reverse-path 1748 | | | ........... 1749 | | | +-- primary-reverse-path-ref* [] 1750 | | | +-- (primary-reverse-path-exist)? 1751 | | | +--:(path-ref) 1752 | | | | +-- primary-path-ref leafref 1753 | | | +--:(path-request-ref) 1754 | | | +-- path-request-ref leafref 1756 A requested secondary reverse path can reference any requested 1757 primary paths, and, in case they are intended to be used within an 1758 existing TE tunnel, it could reference also existing primary-paths. 1760 The secondary-reverse-path container can also contain some attributes 1761 which are configured only on secondary reverse paths (e.g., the 1762 protection-type). 1764 In case the requested path is a transit segment of a multi-domain 1765 end-to-end path, the primary-path may not be needed to be 1766 setup/computed. However, the request for path computation of a 1767 secondary-path or a primary-reverse or of a secondary-reverse-path 1768 requires that the primary-path exists or it is requested within the 1769 same RPC request. In the latter case, the path request for the 1770 primary-path should have an empty ERO to indicate to the server that 1771 path computation is not requested and no path properties will 1772 therefore be returned in the RPC response. 1774 5.4. Multi-Layer Path Computation 1776 The models supports requesting multi-layer path computation following 1777 the same approach based on dependency tunnels, as defined in [TE- 1778 TUNNEL]. 1780 The tunnel-attributes of a given client-layer path request can 1781 reference server-layer TE tunnels which can already exist in the YANG 1782 datastore or be specified in the tunnel-attributes list, within the 1783 same RPC request: 1785 | +-- dependency-tunnels 1786 | | +-- dependency-tunnel* [name] 1787 | | | +-- name -> /te:te/tunnels/tunnel/name 1788 | | | +-- encoding? identityref 1789 | | | +-- switching-type? identityref 1790 | | +-- dependency-tunnel-attributes* [name] 1791 | | +-- name leafref 1792 | | +-- encoding? identityref 1793 | | +-- switching-type? identityref 1795 In a similar way as in [TE-TUNNEL], the server-layer tunnel 1796 attributes should provide the information of what would be the 1797 dynamic link in the client layer topology supported by that tunnel, 1798 if instantiated: 1800 | +-- hierarchical-link 1801 | +-- local-te-node-id? te-types:te-node-id 1802 | +-- local-te-link-tp-id? te-types:te-tp-id 1803 | +-- remote-te-node-id? te-types:te-node-id 1804 | +-- te-topology-identifier 1805 | +-- provider-id? te-global-id 1806 | +-- client-id? te-global-id 1807 | +-- topology-id? te-topology-id 1809 It is worth noting that since path computation RPC is stateless, the 1810 dynamic hierarchical links configured for the server-layer tunnel 1811 attributes cannot be used for path computation of any client-layer 1812 path unless explicitly referenced in the dependency-tunnel-attributes 1813 list within the same RPC request. 1815 6. YANG data model for TE path computation 1817 6.1. Tree diagram 1819 Figure 11 below shows the tree diagram of the YANG data model defined 1820 in module ietf-te-path-computation.yang. 1822 module: ietf-te-path-computation 1824 augment /te:tunnels-path-compute/te:input/te:path-compute-info: 1825 +-- path-request* [request-id] 1826 | +-- request-id uint32 1827 | +-- (tunnel-attributes)? 1828 | | +--:(reference) 1829 | | | +-- tunnel-reference 1830 | | | +-- (tunnel-exist)? 1831 | | | | +--:(tunnel-ref) 1832 | | | | | +-- tunnel-ref te:tunnel-ref 1833 | | | | +--:(tunnel-attributes-ref) 1834 | | | | +-- tunnel-attributes-ref leafref 1835 | | | +-- path-name? string 1836 | | | +-- (path-role) 1837 | | | +--:(primary-path) 1838 | | | | +-- primary-path! 1839 | | | | +-- preference? uint8 1840 | | | | +-- k-requested-paths? uint8 1841 | | | +--:(secondary-path) 1842 | | | | +-- secondary-path 1843 | | | | +-- preference? uint8 1844 | | | | +-- protection-type? identityref 1845 | | | | +-- restoration-type? identityref 1846 | | | | +-- restoration-scheme? identityref 1847 | | | | +-- primary-path-ref* [] 1848 | | | | +-- (primary-path-exist)? 1849 | | | | +--:(path-ref) 1850 | | | | | +-- primary-path-ref leafref 1851 | | | | +--:(path-request-ref) 1852 | | | | +-- path-request-ref leafref 1853 | | | +--:(primary-reverse-path) 1854 | | | | +-- primary-reverse-path 1855 | | | | +-- (primary-path-exist)? 1856 | | | | +--:(path-ref) 1857 | | | | | +-- primary-path-ref leafref 1858 | | | | +--:(path-request-ref) 1859 | | | | +-- path-request-ref leafref 1860 | | | +--:(secondary-reverse-path) 1861 | | | +-- secondary-reverse-path 1862 | | | +-- preference? uint8 1863 | | | +-- protection-type? identityref 1864 | | | +-- restoration-type? identityref 1865 | | | +-- restoration-scheme? identityref 1866 | | | +-- primary-reverse-path-ref* [] 1867 | | | +-- (primary-reverse-path-exist)? 1868 | | | +--:(path-ref) 1869 | | | | +-- primary-path-ref leafref 1870 | | | +--:(path-request-ref) 1871 | | | +-- path-request-ref leafref 1872 | | +--:(value) 1873 | | +-- tunnel-name? string 1874 | | +-- path-name? string 1875 | | +-- (path-role)? 1876 | | | +--:(primary-path) 1877 | | | +--:(secondary-path) 1878 | | | | +-- secondary-path! 1879 | | | | +-- primary-path-name? string 1880 | | | +--:(primary-reverse-path) 1881 | | | | +-- primary-reverse-path! 1882 | | | | +-- primary-path-name? string 1883 | | | +--:(secondary-reverse-path) 1884 | | | +-- secondary-reverse-path! 1885 | | | +-- primary-path-name? string 1886 | | | +-- primary-reverse-path-name? string 1887 | | +-- k-requested-paths? uint8 1888 | | +-- encoding? identityref 1889 | | +-- switching-type? identityref 1890 | | +-- source? te-types:te-node-id 1891 | | +-- destination? te-types:te-node-id 1892 | | +-- src-tunnel-tp-id? binary 1893 | | +-- dst-tunnel-tp-id? binary 1894 | | +-- bidirectional? boolean 1895 | | +-- te-topology-identifier 1896 | | +-- provider-id? te-global-id 1897 | | +-- client-id? te-global-id 1898 | | +-- topology-id? te-topology-id 1899 | +-- association-objects 1900 | | +-- association-object* [association-key] 1901 | | | +-- association-key string 1902 | | | +-- type? identityref 1903 | | | +-- id? uint16 1904 | | | +-- source 1905 | | | +-- id? te-gen-node-id 1906 | | | +-- type? enumeration 1907 | | +-- association-object-extended* [association-key] 1908 | | +-- association-key string 1909 | | +-- type? identityref 1910 | | +-- id? uint16 1911 | | +-- source 1912 | | | +-- id? te-gen-node-id 1913 | | | +-- type? enumeration 1914 | | +-- global-source? uint32 1915 | | +-- extended-id? yang:hex-string 1916 | +-- optimizations 1917 | | +-- (algorithm)? 1918 | | +--:(metric) {path-optimization-metric}? 1919 | | | +-- optimization-metric* [metric-type] 1920 | | | | +-- metric-type identityref 1921 | | | | +-- weight? uint8 1922 | | | | +-- explicit-route-exclude-objects 1923 | | | | | +-- route-object-exclude-object* [index] 1924 | | | | | +-- index uint32 1925 | | | | | +-- (type)? 1926 | | | | | +--:(numbered-node-hop) 1927 | | | | | | +-- numbered-node-hop 1928 | | | | | | +-- node-id te-node-id 1929 | | | | | | +-- hop-type? te-hop-type 1930 | | | | | +--:(numbered-link-hop) 1931 | | | | | | +-- numbered-link-hop 1932 | | | | | | +-- link-tp-id te-tp-id 1933 | | | | | | +-- hop-type? te-hop-type 1934 | | | | | | +-- direction? te-link-direction 1935 | | | | | +--:(unnumbered-link-hop) 1936 | | | | | | +-- unnumbered-link-hop 1937 | | | | | | +-- link-tp-id te-tp-id 1938 | | | | | | +-- node-id te-node-id 1939 | | | | | | +-- hop-type? te-hop-type 1940 | | | | | | +-- direction? te-link-direction 1941 | | | | | +--:(as-number) 1942 | | | | | | +-- as-number-hop 1943 | | | | | | +-- as-number inet:as-number 1944 | | | | | | +-- hop-type? te-hop-type 1945 | | | | | +--:(label) 1946 | | | | | | +-- label-hop 1947 | | | | | | +-- te-label 1948 | | | | | | +-- (technology)? 1949 | | | | | | | +--:(generic) 1950 | | | | | | | +-- generic? 1951 | | | | | | | rt- 1952 types:generalized-label 1953 | | | | | | +-- direction? 1954 | | | | | | te-label-direction 1955 | | | | | +--:(srlg) 1956 | | | | | +-- srlg 1957 | | | | | +-- srlg? uint32 1958 | | | | +-- explicit-route-include-objects 1959 | | | | +-- route-object-include-object* [index] 1960 | | | | +-- index uint32 1961 | | | | +-- (type)? 1962 | | | | +--:(numbered-node-hop) 1963 | | | | | +-- numbered-node-hop 1964 | | | | | +-- node-id te-node-id 1965 | | | | | +-- hop-type? te-hop-type 1966 | | | | +--:(numbered-link-hop) 1967 | | | | | +-- numbered-link-hop 1968 | | | | | +-- link-tp-id te-tp-id 1969 | | | | | +-- hop-type? te-hop-type 1970 | | | | | +-- direction? te-link-direction 1971 | | | | +--:(unnumbered-link-hop) 1972 | | | | | +-- unnumbered-link-hop 1973 | | | | | +-- link-tp-id te-tp-id 1974 | | | | | +-- node-id te-node-id 1975 | | | | | +-- hop-type? te-hop-type 1976 | | | | | +-- direction? te-link-direction 1977 | | | | +--:(as-number) 1978 | | | | | +-- as-number-hop 1979 | | | | | +-- as-number inet:as-number 1980 | | | | | +-- hop-type? te-hop-type 1981 | | | | +--:(label) 1982 | | | | +-- label-hop 1983 | | | | +-- te-label 1984 | | | | +-- (technology)? 1985 | | | | | +--:(generic) 1986 | | | | | +-- generic? 1987 | | | | | rt- 1988 types:generalized-label 1989 | | | | +-- direction? 1990 | | | | te-label-direction 1991 | | | +-- tiebreakers 1992 | | | +-- tiebreaker* [tiebreaker-type] 1993 | | | +-- tiebreaker-type identityref 1994 | | +--:(objective-function) 1995 | | {path-optimization-objective-function}? 1996 | | +-- objective-function 1997 | | +-- objective-function-type? identityref 1998 | +-- named-path-constraint? leafref 1999 | | {te-types:named-path-constraints}? 2000 | +-- te-bandwidth 2001 | | +-- (technology)? 2002 | | +--:(generic) 2003 | | +-- generic? te-bandwidth 2004 | +-- link-protection? identityref 2005 | +-- setup-priority? uint8 2006 | +-- hold-priority? uint8 2007 | +-- signaling-type? identityref 2008 | +-- path-metric-bounds 2009 | | +-- path-metric-bound* [metric-type] 2010 | | +-- metric-type identityref 2011 | | +-- upper-bound? uint64 2012 | +-- path-affinities-values 2013 | | +-- path-affinities-value* [usage] 2014 | | +-- usage identityref 2015 | | +-- value? admin-groups 2016 | +-- path-affinity-names 2017 | | +-- path-affinity-name* [usage] 2018 | | +-- usage identityref 2019 | | +-- affinity-name* [name] 2020 | | +-- name string 2021 | +-- path-srlgs-lists 2022 | | +-- path-srlgs-list* [usage] 2023 | | +-- usage identityref 2024 | | +-- values* srlg 2025 | +-- path-srlgs-names 2026 | | +-- path-srlgs-name* [usage] 2027 | | +-- usage identityref 2028 | | +-- names* string 2029 | +-- disjointness? te-path-disjointness 2030 | +-- explicit-route-objects-always 2031 | | +-- route-object-exclude-always* [index] 2032 | | | +-- index uint32 2033 | | | +-- (type)? 2034 | | | +--:(numbered-node-hop) 2035 | | | | +-- numbered-node-hop 2036 | | | | +-- node-id te-node-id 2037 | | | | +-- hop-type? te-hop-type 2038 | | | +--:(numbered-link-hop) 2039 | | | | +-- numbered-link-hop 2040 | | | | +-- link-tp-id te-tp-id 2041 | | | | +-- hop-type? te-hop-type 2042 | | | | +-- direction? te-link-direction 2043 | | | +--:(unnumbered-link-hop) 2044 | | | | +-- unnumbered-link-hop 2045 | | | | +-- link-tp-id te-tp-id 2046 | | | | +-- node-id te-node-id 2047 | | | | +-- hop-type? te-hop-type 2048 | | | | +-- direction? te-link-direction 2049 | | | +--:(as-number) 2050 | | | | +-- as-number-hop 2051 | | | | +-- as-number inet:as-number 2052 | | | | +-- hop-type? te-hop-type 2053 | | | +--:(label) 2054 | | | +-- label-hop 2055 | | | +-- te-label 2056 | | | +-- (technology)? 2057 | | | | +--:(generic) 2058 | | | | +-- generic? 2059 | | | | rt-types:generalized-label 2060 | | | +-- direction? te-label-direction 2061 | | +-- route-object-include-exclude* [index] 2062 | | +-- explicit-route-usage? identityref 2063 | | +-- index uint32 2064 | | +-- (type)? 2065 | | +--:(numbered-node-hop) 2066 | | | +-- numbered-node-hop 2067 | | | +-- node-id te-node-id 2068 | | | +-- hop-type? te-hop-type 2069 | | +--:(numbered-link-hop) 2070 | | | +-- numbered-link-hop 2071 | | | +-- link-tp-id te-tp-id 2072 | | | +-- hop-type? te-hop-type 2073 | | | +-- direction? te-link-direction 2074 | | +--:(unnumbered-link-hop) 2075 | | | +-- unnumbered-link-hop 2076 | | | +-- link-tp-id te-tp-id 2077 | | | +-- node-id te-node-id 2078 | | | +-- hop-type? te-hop-type 2079 | | | +-- direction? te-link-direction 2080 | | +--:(as-number) 2081 | | | +-- as-number-hop 2082 | | | +-- as-number inet:as-number 2083 | | | +-- hop-type? te-hop-type 2084 | | +--:(label) 2085 | | | +-- label-hop 2086 | | | +-- te-label 2087 | | | +-- (technology)? 2088 | | | | +--:(generic) 2089 | | | | +-- generic? 2090 | | | | rt-types:generalized-label 2091 | | | +-- direction? te-label-direction 2092 | | +--:(srlg) 2093 | | +-- srlg 2094 | | +-- srlg? uint32 2095 | +-- path-in-segment! 2096 | | +-- label-restrictions 2097 | | +-- label-restriction* [index] 2098 | | +-- restriction? enumeration 2099 | | +-- index uint32 2100 | | +-- label-start 2101 | | | +-- te-label 2102 | | | +-- (technology)? 2103 | | | | +--:(generic) 2104 | | | | +-- generic? rt-types:generalized-label 2105 | | | +-- direction? te-label-direction 2106 | | +-- label-end 2107 | | | +-- te-label 2108 | | | +-- (technology)? 2109 | | | | +--:(generic) 2110 | | | | +-- generic? rt-types:generalized-label 2111 | | | +-- direction? te-label-direction 2112 | | +-- label-step 2113 | | | +-- (technology)? 2114 | | | +--:(generic) 2115 | | | +-- generic? int32 2116 | | +-- range-bitmap? yang:hex-string 2117 | +-- path-out-segment! 2118 | | +-- label-restrictions 2119 | | +-- label-restriction* [index] 2120 | | +-- restriction? enumeration 2121 | | +-- index uint32 2122 | | +-- label-start 2123 | | | +-- te-label 2124 | | | +-- (technology)? 2125 | | | | +--:(generic) 2126 | | | | +-- generic? rt-types:generalized-label 2127 | | | +-- direction? te-label-direction 2128 | | +-- label-end 2129 | | | +-- te-label 2130 | | | +-- (technology)? 2131 | | | | +--:(generic) 2132 | | | | +-- generic? rt-types:generalized-label 2133 | | | +-- direction? te-label-direction 2134 | | +-- label-step 2135 | | | +-- (technology)? 2136 | | | +--:(generic) 2137 | | | +-- generic? int32 2138 | | +-- range-bitmap? yang:hex-string 2139 | +-- requested-metrics* [metric-type] 2140 | | +-- metric-type identityref 2141 | +-- return-srlgs? boolean 2142 | +-- return-affinities? boolean 2143 | +-- requested-state! 2144 | +-- timer? uint16 2145 | +-- transaction-id? string 2146 +-- tunnel-attributes* [tunnel-name] 2147 | +-- tunnel-name string 2148 | +-- encoding? identityref 2149 | +-- switching-type? identityref 2150 | +-- source? te-types:te-node-id 2151 | +-- destination? te-types:te-node-id 2152 | +-- src-tunnel-tp-id? binary 2153 | +-- dst-tunnel-tp-id? binary 2154 | +-- bidirectional? boolean 2155 | +-- association-objects 2156 | | +-- association-object* [association-key] 2157 | | | +-- association-key string 2158 | | | +-- type? identityref 2159 | | | +-- id? uint16 2160 | | | +-- source 2161 | | | +-- id? te-gen-node-id 2162 | | | +-- type? enumeration 2163 | | +-- association-object-extended* [association-key] 2164 | | +-- association-key string 2165 | | +-- type? identityref 2166 | | +-- id? uint16 2167 | | +-- source 2168 | | | +-- id? te-gen-node-id 2169 | | | +-- type? enumeration 2170 | | +-- global-source? uint32 2171 | | +-- extended-id? yang:hex-string 2172 | +-- protection-type? identityref 2173 | +-- restoration-type? identityref 2174 | +-- restoration-scheme? identityref 2175 | +-- te-topology-identifier 2176 | | +-- provider-id? te-global-id 2177 | | +-- client-id? te-global-id 2178 | | +-- topology-id? te-topology-id 2179 | +-- te-bandwidth 2180 | | +-- (technology)? 2181 | | +--:(generic) 2182 | | +-- generic? te-bandwidth 2183 | +-- link-protection? identityref 2184 | +-- setup-priority? uint8 2185 | +-- hold-priority? uint8 2186 | +-- signaling-type? identityref 2187 | +-- hierarchy 2188 | +-- dependency-tunnels 2189 | | +-- dependency-tunnel* [name] 2190 | | | +-- name -> /te:te/tunnels/tunnel/name 2191 | | | +-- encoding? identityref 2192 | | | +-- switching-type? identityref 2193 | | +-- dependency-tunnel-attributes* [name] 2194 | | +-- name leafref 2195 | | +-- encoding? identityref 2196 | | +-- switching-type? identityref 2197 | +-- hierarchical-link 2198 | +-- local-te-node-id? te-types:te-node-id 2199 | +-- local-te-link-tp-id? te-types:te-tp-id 2200 | +-- remote-te-node-id? te-types:te-node-id 2201 | +-- te-topology-identifier 2202 | +-- provider-id? te-global-id 2203 | +-- client-id? te-global-id 2204 | +-- topology-id? te-topology-id 2205 +-- synchronization* [] 2206 +-- svec 2207 | +-- relaxable? boolean 2208 | +-- disjointness? te-path-disjointness 2209 | +-- request-id-number* uint32 2210 +-- svec-constraints 2211 | +-- path-metric-bound* [metric-type] 2212 | +-- metric-type identityref 2213 | +-- upper-bound? uint64 2214 +-- path-srlgs-lists 2215 | +-- path-srlgs-list* [usage] 2216 | +-- usage identityref 2217 | +-- values* srlg 2218 +-- path-srlgs-names 2219 | +-- path-srlgs-name* [usage] 2220 | +-- usage identityref 2221 | +-- names* string 2222 +-- exclude-objects 2223 | +-- excludes* [] 2224 | +-- (type)? 2225 | +--:(numbered-node-hop) 2226 | | +-- numbered-node-hop 2227 | | +-- node-id te-node-id 2228 | | +-- hop-type? te-hop-type 2229 | +--:(numbered-link-hop) 2230 | | +-- numbered-link-hop 2231 | | +-- link-tp-id te-tp-id 2232 | | +-- hop-type? te-hop-type 2233 | | +-- direction? te-link-direction 2234 | +--:(unnumbered-link-hop) 2235 | | +-- unnumbered-link-hop 2236 | | +-- link-tp-id te-tp-id 2237 | | +-- node-id te-node-id 2238 | | +-- hop-type? te-hop-type 2239 | | +-- direction? te-link-direction 2240 | +--:(as-number) 2241 | | +-- as-number-hop 2242 | | +-- as-number inet:as-number 2243 | | +-- hop-type? te-hop-type 2244 | +--:(label) 2245 | +-- label-hop 2246 | +-- te-label 2247 | +-- (technology)? 2248 | | +--:(generic) 2249 | | +-- generic? 2250 | | rt-types:generalized-label 2251 | +-- direction? te-label-direction 2252 +-- optimizations 2253 +-- (algorithm)? 2254 +--:(metric) {te-types:path-optimization-metric}? 2255 | +-- optimization-metric* [metric-type] 2256 | +-- metric-type identityref 2257 | +-- weight? uint8 2258 +--:(objective-function) 2259 {te-types:path-optimization-objective- 2260 function}? 2261 +-- objective-function 2262 +-- objective-function-type? identityref 2264 augment /te:tunnels-path-compute/te:output/te:path-compute-result: 2265 +--ro response* [response-id] 2266 +--ro response-id uint32 2267 +--ro computed-paths-properties 2268 | +--ro computed-path-properties* [k-index] 2269 | +--ro k-index uint8 2270 | +--ro path-properties 2271 | +--ro path-metric* [metric-type] 2272 | | +--ro metric-type identityref 2273 | | +--ro accumulative-value? uint64 2274 | +--ro path-affinities-values 2275 | | +--ro path-affinities-value* [usage] 2276 | | +--ro usage identityref 2277 | | +--ro value? admin-groups 2278 | +--ro path-affinity-names 2279 | | +--ro path-affinity-name* [usage] 2280 | | +--ro usage identityref 2281 | | +--ro affinity-name* [name] 2282 | | +--ro name string 2283 | +--ro path-srlgs-lists 2284 | | +--ro path-srlgs-list* [usage] 2285 | | +--ro usage identityref 2286 | | +--ro values* srlg 2287 | +--ro path-srlgs-names 2288 | | +--ro path-srlgs-name* [usage] 2289 | | +--ro usage identityref 2290 | | +--ro names* string 2291 | +--ro path-route-objects 2292 | | +--ro path-route-object* [index] 2293 | | +--ro index uint32 2294 | | +--ro (type)? 2295 | | +--:(numbered-node-hop) 2296 | | | +--ro numbered-node-hop 2297 | | | +--ro node-id te-node-id 2298 | | | +--ro hop-type? te-hop-type 2299 | | +--:(numbered-link-hop) 2300 | | | +--ro numbered-link-hop 2301 | | | +--ro link-tp-id te-tp-id 2302 | | | +--ro hop-type? te-hop-type 2303 | | | +--ro direction? te-link-direction 2304 | | +--:(unnumbered-link-hop) 2305 | | | +--ro unnumbered-link-hop 2306 | | | +--ro link-tp-id te-tp-id 2307 | | | +--ro node-id te-node-id 2308 | | | +--ro hop-type? te-hop-type 2309 | | | +--ro direction? te-link-direction 2310 | | +--:(as-number) 2311 | | | +--ro as-number-hop 2312 | | | +--ro as-number inet:as-number 2313 | | | +--ro hop-type? te-hop-type 2314 | | +--:(label) 2315 | | +--ro label-hop 2316 | | +--ro te-label 2317 | | +--ro (technology)? 2318 | | | +--:(generic) 2319 | | | +--ro generic? 2320 | | | rt-types:generalized- 2321 label 2322 | | +--ro direction? 2323 | | te-label-direction 2324 | +--ro te-bandwidth 2325 | | +--ro (technology)? 2326 | | +--:(generic) 2327 | | +--ro generic? te-bandwidth 2328 | +--ro disjointness-type? 2329 | te-types:te-path-disjointness 2330 +--ro computed-path-error-infos 2331 | +--ro computed-path-error-info* [] 2332 | +--ro error-description? string 2333 | +--ro error-timestamp? yang:date-and-time 2334 | +--ro error-reason? identityref 2335 +--ro tunnel-ref? te:tunnel-ref 2336 +--ro (path-role)? 2337 +--:(primary) 2338 | +--ro primary-path-ref? leafref 2339 +--:(primary-reverse) 2340 | +--ro primary-reverse-path-ref? leafref 2341 +--:(secondary) 2342 | +--ro secondary-path-ref? leafref 2343 +--:(secondary-reverse) 2344 +--ro secondary-reverse-path-ref? leafref 2345 augment /te:tunnels-actions/te:input/te:tunnel-info/te:filter-type: 2346 +--:(path-compute-transactions) 2347 +-- path-compute-transaction-id* string 2348 augment /te:tunnels-actions/te:output: 2349 +--ro path-computed-delete-result 2350 +--ro path-compute-transaction-id* string 2352 Figure 11 - TE path computation tree diagram 2354 6.2. YANG module 2356 file "ietf-te-path-computation@2021-07-12.yang" 2357 module ietf-te-path-computation { 2358 yang-version 1.1; 2359 namespace "urn:ietf:params:xml:ns:yang:ietf-te-path-computation"; 2360 prefix te-pc; 2362 import ietf-te { 2363 prefix te; 2364 reference 2365 "RFCYYYY: A YANG Data Model for Traffic Engineering Tunnels 2366 and Interfaces"; 2367 } 2369 /* Note: The RFC Editor will replace YYYY with the number assigned 2370 to the RFC once draft-ietf-teas-yang-te becomes an RFC.*/ 2372 import ietf-te-types { 2373 prefix te-types; 2374 reference 2375 "RFC8776: Common YANG Data Types for Traffic Engineering."; 2376 } 2378 organization 2379 "Traffic Engineering Architecture and Signaling (TEAS) 2380 Working Group"; 2381 contact 2382 "WG Web: 2383 WG List: 2385 Editor: Italo Busi 2386 2388 Editor: Sergio Belotti 2389 2391 Editor: Victor Lopez 2392 2394 Editor: Oscar Gonzalez de Dios 2395 2397 Editor: Anurag Sharma 2398 2400 Editor: Yan Shi 2401 2403 Editor: Ricard Vilalta 2404 2406 Editor: Karthik Sethuraman 2407 2409 Editor: Michael Scharf 2410 2412 Editor: Daniele Ceccarelli 2413 2415 "; 2416 description 2417 "This module defines a YANG data model for requesting Traffic 2418 Engineering (TE) path computation. The YANG model defined in 2419 this document is based on RPCs augmenting the RPCs defined in 2420 the generic TE module (ietf-te). 2422 The model fully conforms to the 2423 Network Management Datastore Architecture (NMDA). 2425 Copyright (c) 2021 IETF Trust and the persons 2426 identified as authors of the code. All rights reserved. 2428 Redistribution and use in source and binary forms, with or 2429 without modification, is permitted pursuant to, and subject 2430 to the license terms contained in, the Simplified BSD License 2431 set forth in Section 4.c of the IETF Trust's Legal Provisions 2433 Relating to IETF Documents 2434 (http://trustee.ietf.org/license-info). 2436 This version of this YANG module is part of RFC XXXX; see 2437 the RFC itself for full legal notices."; 2439 // RFC Ed.: replace XXXX with actual RFC number and remove 2440 // this note 2441 // replace the revision date with the module publication date 2442 // the format is (year-month-day) 2444 revision 2021-07-12 { 2445 description 2446 "Initial revision"; 2447 reference 2448 "RFC XXXX: YANG Data Model for requesting Path Computation"; 2449 } 2451 // RFC Ed.: replace XXXX with actual RFC number and remove 2452 // this note 2454 /* 2455 * Identities 2456 */ 2458 identity svec-metric-type { 2459 description 2460 "Base identity for SVEC metric type."; 2462 reference 2463 "RFC5541: Encoding of Objective Functions in the Path 2464 Computation Element Communication Protocol (PCEP)."; 2465 } 2467 identity svec-metric-cumul-te { 2468 base svec-metric-type; 2469 description 2470 "Cumulative TE cost."; 2471 reference 2472 "RFC5541: Encoding of Objective Functions in the Path 2473 Computation Element Communication Protocol (PCEP)."; 2474 } 2476 identity svec-metric-cumul-igp { 2477 base svec-metric-type; 2478 description 2479 "Cumulative IGP cost."; 2480 reference 2481 "RFC5541: Encoding of Objective Functions in the Path 2482 Computation Element Communication Protocol (PCEP)."; 2483 } 2485 identity svec-metric-cumul-hop { 2486 base svec-metric-type; 2487 description 2488 "Cumulative Hop path metric."; 2489 reference 2490 "RFC8776: Common YANG Data Types for Traffic Engineering."; 2491 } 2493 identity svec-metric-aggregate-bandwidth-consumption { 2494 base svec-metric-type; 2495 description 2496 "Aggregate bandwidth consumption."; 2497 reference 2498 "RFC5541: Encoding of Objective Functions in the Path 2499 Computation Element Communication Protocol (PCEP)."; 2500 } 2501 identity svec-metric-load-of-the-most-loaded-link { 2502 base svec-metric-type; 2503 description 2504 "Load of the most loaded link."; 2505 reference 2506 "RFC5541: Encoding of Objective Functions in the Path 2507 Computation Element Communication Protocol (PCEP)."; 2508 } 2510 identity tunnel-action-path-compute-delete { 2511 base te:tunnel-actions-type; 2512 description 2513 "Action type to delete the transient states 2514 of computed paths, as described in section 3.3.1 of 2515 RFC XXXX."; 2516 reference 2517 "RFC XXXX: YANG Data Model for requesting Path Computation"; 2518 } 2520 /* 2521 * Groupings 2522 */ 2524 grouping protection-restoration-properties { 2525 description 2526 "This grouping defines the restoration and protection types 2527 for a path in the path computation request."; 2528 leaf protection-type { 2529 type identityref { 2530 base te-types:lsp-protection-type; 2531 } 2532 default "te-types:lsp-protection-unprotected"; 2533 description 2534 "LSP protection type."; 2535 } 2536 leaf restoration-type { 2537 type identityref { 2538 base te-types:lsp-restoration-type; 2540 } 2541 default "te-types:lsp-restoration-restore-any"; 2542 description 2543 "LSP restoration type."; 2544 } 2545 leaf restoration-scheme { 2546 type identityref { 2547 base te-types:restoration-scheme-type; 2548 } 2549 default "te-types:restoration-scheme-preconfigured"; 2550 description 2551 "LSP restoration scheme."; 2552 } 2553 } // grouping protection-restoration-properties 2555 grouping requested-info { 2556 description 2557 "This grouping defines the information (e.g., metrics) 2558 which is requested, in the path computation request, to be 2559 returned in the path computation response."; 2560 list requested-metrics { 2561 key "metric-type"; 2562 description 2563 "The list of the requested metrics. 2564 The metrics listed here must be returned in the response. 2565 Returning other metrics in the response is optional."; 2566 leaf metric-type { 2567 type identityref { 2568 base te-types:path-metric-type; 2569 } 2570 description 2571 "The metric that must be returned in the response"; 2572 } 2573 } 2574 leaf return-srlgs { 2575 type boolean; 2576 default "false"; 2577 description 2578 "If true, path srlgs must be returned in the response. 2580 If false, returning path srlgs in the response optional."; 2581 } 2582 leaf return-affinities { 2583 type boolean; 2584 default "false"; 2585 description 2586 "If true, path affinities must be returned in the response. 2587 If false, returning path affinities in the response is 2588 optional."; 2589 } 2590 } // grouping requested-info 2592 grouping requested-state { 2593 description 2594 "Configuration for the transient state used 2595 to report the computed path"; 2596 container requested-state { 2597 presence 2598 "Request temporary reporting of the computed path state"; 2599 description 2600 "Configures attributes for the temporary reporting of the 2601 computed path state (e.g., expiration timer)."; 2602 leaf timer { 2603 type uint16; 2604 units "minutes"; 2605 default "10"; 2606 description 2607 "The timeout after which the transient state reporting 2608 the computed path should be removed."; 2609 } 2610 leaf transaction-id { 2611 type string; 2612 description 2613 "The transaction-id associated with this path computation 2614 to be used for fast deletion of the transient states 2615 associated with multiple path computations. 2617 This transaction-id can be used to explicitly delete all 2618 the transient states of all the computed paths associated 2619 with the same transaction-id. 2621 When one path associated with a transaction-id is setup, 2622 the transient states of all the other computed paths 2623 with the same transaction-id are automatically removed. 2625 If not specified, the transient state is removed only 2626 when the timer expires (when the timer is specified) 2627 or not created at all (stateless path computation, 2628 when the timer is not specified)."; 2629 } 2630 } 2631 } // grouping requested-state 2633 grouping reported-state { 2634 description 2635 "This grouping defines the information, returned in the path 2636 computation response, reporting the transient state related 2637 to the computed path"; 2638 leaf tunnel-ref { 2639 type te:tunnel-ref; 2640 description 2641 " 2642 Reference to the tunnel that reports the transient state 2643 of the computed path. 2645 If no transient state is created, this attribute is 2646 omitted. 2647 "; 2648 } 2649 choice path-role { 2650 description 2651 "The transient state of the computed path can be reported 2652 as a primary, primary-reverse, secondary or 2653 a secondary-reverse path of a te-tunnel"; 2654 case primary { 2655 leaf primary-path-ref { 2656 type leafref { 2657 path "/te:te/te:tunnels/" 2658 + "te:tunnel[te:name=current()/../tunnel-ref]/" 2659 + "te:primary-paths/te:primary-path/" 2660 + "te:name"; 2661 } 2662 must '../tunnel-ref' { 2663 description 2664 "The primary-path name can only be reported 2665 if also the tunnel name is reported."; 2666 } 2667 description 2668 " 2669 Reference to the primary-path that reports 2670 the transient state of the computed path. 2672 If no transient state is created, 2673 this attribute is omitted. 2674 "; 2675 } 2676 } // case primary 2677 case primary-reverse { 2678 leaf primary-reverse-path-ref { 2679 type leafref { 2680 path "/te:te/te:tunnels/" 2681 + "te:tunnel[te:name=current()/../tunnel-ref]/" 2682 + "te:primary-paths/te:primary-path/" 2683 + "te:name"; 2684 } 2685 must '../tunnel-ref' { 2686 description 2687 "The primary-reverse-path name can only be reported 2688 if also the tunnel name is reported."; 2689 } 2690 description 2691 " 2692 Reference to the primary-reverse-path that reports 2693 the transient state of the computed path. 2695 If no transient state is created, 2696 this attribute is omitted. 2698 "; 2699 } 2700 } // case primary-reverse 2701 case secondary { 2702 leaf secondary-path-ref { 2703 type leafref { 2704 path "/te:te/te:tunnels/" 2705 + "te:tunnel[te:name=current()/../tunnel-ref]/" 2706 + "te:secondary-paths/te:secondary-path/" 2707 + "te:name"; 2708 } 2709 must '../tunnel-ref' { 2710 description 2711 "The secondary-path name can only be reported 2712 if also the tunnel name is reported."; 2713 } 2714 description 2715 " 2716 Reference to the secondary-path that reports 2717 the transient state of the computed path. 2719 If no transient state is created, 2720 this attribute is omitted. 2721 "; 2722 } 2723 } // case secondary 2724 case secondary-reverse { 2725 leaf secondary-reverse-path-ref { 2726 type leafref { 2727 path "/te:te/te:tunnels/" 2728 + "te:tunnel[te:name=current()/../tunnel-ref]/" 2729 + "te:secondary-reverse-paths/" 2730 + "te:secondary-reverse-path/te:name"; 2731 } 2732 must '../tunnel-ref' { 2733 description 2734 "The secondary-reverse-path name can only be reported 2735 if also the tunnel name is reported."; 2736 } 2737 description 2738 " 2739 Reference to the secondary-reverse-path that reports 2740 the transient state of the computed path. 2742 If no transient state is created, 2743 this attribute is omitted. 2744 "; 2745 } 2746 } // case secondary 2747 } // choice path 2748 } // grouping reported-state 2750 grouping synchronization-constraints { 2751 description 2752 "Global constraints applicable to synchronized path 2753 computation requests."; 2754 container svec-constraints { 2755 description 2756 "global svec constraints"; 2757 list path-metric-bound { 2758 key "metric-type"; 2759 description 2760 "list of bound metrics"; 2761 leaf metric-type { 2762 type identityref { 2763 base svec-metric-type; 2764 } 2765 description 2766 "SVEC metric type."; 2767 reference 2768 "RFC5541: Encoding of Objective Functions in the Path 2769 Computation Element Communication Protocol (PCEP)."; 2770 } 2771 leaf upper-bound { 2772 type uint64; 2773 description 2774 "Upper bound on SVEC metric"; 2775 } 2777 } 2778 } 2779 uses te-types:generic-path-srlgs; 2780 container exclude-objects { 2781 description 2782 "Resources to be excluded"; 2783 list excludes { 2784 description 2785 "List of Explicit Route Objects to always exclude 2786 from synchronized path computation"; 2787 uses te-types:explicit-route-hop; 2788 } 2789 } 2790 } // grouping synchronization-constraints 2792 grouping synchronization-optimization { 2793 description 2794 "Optimizations applicable to synchronized path 2795 computation requests."; 2796 container optimizations { 2797 description 2798 "The objective function container that includes attributes 2799 to impose when computing a synchronized set of paths"; 2800 choice algorithm { 2801 description 2802 "Optimizations algorithm."; 2803 case metric { 2804 if-feature "te-types:path-optimization-metric"; 2805 list optimization-metric { 2806 key "metric-type"; 2807 description 2808 "svec path metric type"; 2809 leaf metric-type { 2810 type identityref { 2811 base svec-metric-type; 2812 } 2813 description 2814 "TE path metric type usable for computing a set of 2815 synchronized requests"; 2817 } 2818 leaf weight { 2819 type uint8; 2820 description 2821 "Metric normalization weight"; 2822 } 2823 } 2824 } 2825 case objective-function { 2826 if-feature 2827 "te-types:path-optimization-objective-function"; 2828 container objective-function { 2829 description 2830 "The objective function container that includes 2831 attributes to impose when computing a TE path"; 2832 leaf objective-function-type { 2833 type identityref { 2834 base te-types:objective-function-type; 2835 } 2836 default "te-types:of-minimize-cost-path"; 2837 description 2838 "Objective function entry"; 2839 } 2840 } 2841 } 2842 } 2843 } 2844 } // grouping synchronization-optimization 2846 grouping synchronization-info { 2847 description 2848 "Information for synchronized path computation requests."; 2849 list synchronization { 2850 description 2851 "List of Synchronization VECtors."; 2852 container svec { 2853 description 2854 "Synchronization VECtor"; 2855 leaf relaxable { 2856 type boolean; 2857 default "true"; 2858 description 2859 "If this leaf is true, path computation process is 2860 free to ignore svec content. 2861 Otherwise, it must take into account this svec."; 2862 } 2863 uses te-types:generic-path-disjointness; 2864 leaf-list request-id-number { 2865 type uint32; 2866 description 2867 "This list reports the set of path computation 2868 requests that must be synchronized."; 2869 } 2870 } 2871 uses synchronization-constraints; 2872 uses synchronization-optimization; 2873 } 2874 } // grouping synchronization-info 2876 grouping encoding-and-switching-type { 2877 description 2878 "Common grouping to define the LSP encoding and 2879 switching types"; 2880 leaf encoding { 2881 type identityref { 2882 base te-types:lsp-encoding-types; 2883 } 2884 default "te-types:lsp-encoding-packet"; 2885 description 2886 "LSP encoding type."; 2887 reference 2888 "RFC3945"; 2889 } 2890 leaf switching-type { 2891 type identityref { 2892 base te-types:switching-capabilities; 2893 } 2894 default "te-types:switching-psc1"; 2895 description 2896 "LSP switching type."; 2897 reference 2898 "RFC3945"; 2899 } 2900 } 2902 grouping tunnel-common-attributes { 2903 description 2904 "Common grouping to define the TE tunnel parameters"; 2905 uses encoding-and-switching-type; 2906 leaf source { 2907 type te-types:te-node-id; 2908 description 2909 "TE tunnel source node ID."; 2910 } 2911 leaf destination { 2912 type te-types:te-node-id; 2913 description 2914 "TE tunnel destination node identifier."; 2915 } 2916 leaf src-tunnel-tp-id { 2917 type binary; 2918 description 2919 "TE tunnel source termination point identifier."; 2920 } 2921 leaf dst-tunnel-tp-id { 2922 type binary; 2923 description 2924 "TE tunnel destination termination point identifier."; 2925 } 2926 leaf bidirectional { 2927 type boolean; 2928 default "false"; 2929 description 2930 "Indicates a bidirectional co-routed LSP."; 2931 } 2932 } 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"; 3078 } 3079 must '../../tunnel-ref' { 3080 description 3081 "The primary-path can be referenced 3082 if also the tunnel is referenced."; 3083 } 3084 mandatory true; 3085 description 3086 "The referenced primary path"; 3087 } 3088 } // case path-ref 3089 case path-request-ref { 3090 leaf path-request-ref { 3091 type leafref { 3092 path "/te:tunnels-path-compute/" 3093 + "te:path-compute-info/" 3094 + "te-pc:path-request/" 3095 + "te-pc:request-id"; 3096 } 3097 mandatory true; 3098 description 3099 "The referenced primary path request"; 3100 } 3101 } // case path-request-ref 3102 } // choice primary-path-exist 3103 } // container primary-reverse-path 3104 } // case primary-reverse-path 3105 case secondary-reverse-path { 3106 container secondary-reverse-path { 3107 description 3108 "TE secondary reverse path"; 3109 uses te:path-preference; 3110 uses protection-restoration-properties; 3111 list primary-reverse-path-ref { 3112 min-elements 1; 3113 description 3114 "The list of primary reverse paths that 3115 reference this path as a candidate 3116 secondary reverse path"; 3117 choice primary-reverse-path-exist { 3118 description 3119 "Whether the path reference is to an existing 3120 te-tunnel path or to another path request"; 3121 case path-ref { 3122 leaf primary-path-ref { 3123 type leafref { 3124 path "/te:te/te:tunnels/te:tunnel" 3125 + "[te:name=current()/../../../" 3126 + "tunnel-ref]/te:primary-paths/" 3127 + "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 tunnel-common-attributes; 3242 uses te-types:te-topology-identifier; 3243 } // case value 3244 } // choice tunnel-attributes 3245 uses te:path-compute-info; 3246 uses requested-info; 3247 uses requested-state; 3248 } 3249 list tunnel-attributes { 3250 key "tunnel-name"; 3251 description 3252 "Tunnel attributes common to multiple request paths"; 3253 leaf tunnel-name { 3254 type string; 3255 description 3256 "TE tunnel name."; 3257 } 3258 uses tunnel-common-attributes; 3259 uses te:tunnel-associations-properties; 3260 uses protection-restoration-properties; 3261 uses te-types:tunnel-constraints; 3262 uses te:tunnel-hierarchy-properties { 3263 augment "hierarchy/dependency-tunnels" { 3264 description 3265 "Augment with the list of dependency tunnel requests."; 3266 list dependency-tunnel-attributes { 3267 key "name"; 3268 description 3269 "A tunnel request entry that this tunnel request can 3270 potentially depend on."; 3271 leaf name { 3272 type leafref { 3273 path "/te:tunnels-path-compute/" 3274 + "te:path-compute-info/te-pc:tunnel-attributes/" 3275 + "te-pc:tunnel-name"; 3276 } 3277 description 3278 "Dependency tunnel request name."; 3279 } 3280 uses encoding-and-switching-type; 3281 } 3282 } 3283 } 3284 } 3285 uses synchronization-info; 3286 } // path-compute rpc input 3288 augment "/te:tunnels-path-compute/te:output/" 3289 + "te:path-compute-result" { 3290 description 3291 "Path Computation RPC output"; 3292 list response { 3293 key "response-id"; 3294 config false; 3295 description 3296 "response"; 3297 leaf response-id { 3298 type uint32; 3299 description 3300 "The response-id has the same value of the 3301 corresponding request-id."; 3302 } 3303 uses te:path-computation-response; 3304 uses reported-state; 3305 } 3306 } // path-compute rpc output 3308 augment "/te:tunnels-actions/te:input/te:tunnel-info/" 3309 + "te:filter-type" { 3310 description 3311 "Augment Tunnels Action RPC input filter types"; 3312 case path-compute-transactions { 3313 when "derived-from-or-self(../te:action-info/te:action, " 3314 + "'tunnel-action-path-compute-delete')"; 3315 description 3316 "Path Delete Action RPC"; 3317 leaf-list path-compute-transaction-id { 3318 type string; 3319 description 3320 "The list of the transaction-id values of the 3321 transient states to be deleted"; 3322 } 3323 } 3325 } // path-delete rpc input 3327 augment "/te:tunnels-actions/te:output" { 3328 description 3329 "Augment Tunnels Action RPC output with path delete result"; 3330 container path-computed-delete-result { 3331 description 3332 "Path Delete RPC output"; 3333 leaf-list path-compute-transaction-id { 3334 type string; 3335 description 3336 "The list of the transaction-id values of the 3337 transient states that have been successfully deleted"; 3338 } 3339 } 3340 } // path-delete rpc output 3341 } 3342 3344 Figure 12 - TE path computation YANG module 3346 7. Security Considerations 3348 This document describes use cases of requesting Path Computation 3349 using YANG data models, which could be used at the ABNO Control 3350 Interface [RFC7491] and/or between controllers in ACTN [RFC8453]. As 3351 such, it does not introduce any new security considerations compared 3352 to the ones related to YANG specification, ABNO specification and 3353 ACTN Framework defined in [RFC7950], [RFC7491] and [RFC8453]. 3355 The YANG module defined in this draft is designed to be accessed via 3356 the NETCONF protocol [RFC6241] or RESTCONF protocol [RFC8040]. The 3357 lowest NETCONF layer is the secure transport layer, and the 3358 mandatory-to-implement secure transport is Secure Shell (SSH) 3359 [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to- 3360 implement secure transport is TLS [RFC8446]. 3362 This document also defines common data types using the YANG data 3363 modeling language. The definitions themselves have no security impact 3364 on the Internet, but the usage of these definitions in concrete YANG 3365 modules might have. The security considerations spelled out in the 3366 YANG specification [RFC7950] apply for this document as well. 3368 The NETCONF access control model [RFC8341] provides the means to 3369 restrict access for particular NETCONF or RESTCONF users to a 3370 preconfigured subset of all available NETCONF or RESTCONF protocol 3371 operations and content. 3373 Note - The security analysis of each leaf is for further study. 3375 8. IANA Considerations 3377 This document registers the following URIs in the "ns" subregistry 3378 within the "IETF XML registry" [RFC3688]. 3380 URI: urn:ietf:params:xml:ns:yang:ietf-te-path-computation 3381 Registrant Contact: The IESG. 3382 XML: N/A, the requested URI is an XML namespace. 3384 This document registers a YANG module in the "YANG Module Names" 3385 registry [RFC7950]. 3387 name: ietf-te-path-computation 3388 namespace: urn:ietf:params:xml:ns:yang:ietf-te-path-computation 3389 prefix: te-pc 3390 reference: this document 3392 9. References 3394 9.1. Normative References 3396 [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 3397 2004. 3399 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 3400 Switching (GMPLS) Architecture", RFC 3945, DOI 3401 10.17487/RFC3945, October 2004, . 3404 [RFC5440] Vasseur, JP., Le Roux, JL. et al., "Path Computation 3405 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 3406 March 2009. 3408 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 3409 "A Backward-Recursive PCE-Based Computation (BRPC) 3410 Procedure to Compute Shortest Constrained Inter-Domain 3411 Traffic Engineering Label Switched Paths", RFC 5441, 3412 DOI 10.17487/RFC5441, April 2009, . 3415 [RFC5541] Le Roux, JL. et al., "Encoding of Objective Functions in 3416 the Path Computation Element Communication Protocol 3417 (PCEP)", RFC 5541, June 2009. 3419 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 3420 and A. Bierman, Ed., "Network Configuration Protocol 3421 (NETCONF)", RFC 6241, June 2011. 3423 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 3424 Shell (SSH)", RFC 6242, June 2011. 3426 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, July 3427 2013. 3429 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 3430 Protocol", RFC 8040, January 2017. 3432 [RFC8341] Bierman, A., and M. Bjorklund, "Network Configuration 3433 Access Control Model", RFC 8341, March 2018. 3435 [RFC7926] Farrel, A. et al., "Problem Statement and Architecture for 3436 Information Exchange Between Interconnected Traffic 3437 Engineered Networks", RFC 7926, July 2016. 3439 [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC 3440 7950, August 2016. 3442 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 3443 Protocol", RFC 8040, January 2017. 3445 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 3446 215, RFC 8340, March 2018. 3448 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3449 Version 1.3", RFC 8446, August 2018. 3451 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 3452 "Common YANG Data Types for Traffic Engineering", RFC8776, 3453 June 2020. 3455 [RFC8795] Liu, X. et al., " Liu, X. et al., "YANG Data Model for 3456 Traffic Engineering (TE) Topologies", RFC8795, August 2020. 3458 [TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic 3459 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 3460 te, work in progress. 3462 9.2. Informative References 3464 [RFC4655] Farrel, A. et al., "A Path Computation Element (PCE)-Based 3465 Architecture", RFC 4655, August 2006. 3467 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 3468 Path Computation Element Architecture to the Determination 3469 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, DOI 3470 10.17487/RFC6805, November 2012, . 3473 [RFC7139] Zhang, F. et al., "GMPLS Signaling Extensions for Control 3474 of Evolving G.709 Optical Transport Networks", RFC 7139, 3475 March 2014. 3477 [RFC7446] Lee, Y. et al., "Routing and Wavelength Assignment 3478 Information Model for Wavelength Switched Optical 3479 Networks", RFC 7446, February 2015. 3481 [RFC7491] Farrel, A., King, D., "A PCE-Based Architecture for 3482 Application-Based Network Operations", RFC 7491, March 3483 2015. 3485 [RFC8233] Dhody, D. et al., "Extensions to the Path Computation 3486 Element Communication Protocol (PCEP) to Compute Service- 3487 Aware Label Switched Paths (LSPs)", RFC 8233, September 3488 2017 3490 [RFC8342] Bjorklund,M. et al. "Network Management Datastore 3491 Architecture (NMDA)", RFC 8342, March 2018 3493 [RFC8453] Ceccarelli, D., Lee, Y. et al., "Framework for Abstraction 3494 and Control of TE Networks (ACTN)", RFC8453, August 2018. 3496 [RFC8454] Lee, Y. et al., "Information Model for Abstraction and 3497 Control of TE Networks (ACTN)", RFC8454, September 2018. 3499 [OTN-TOPO] Zheng, H. et al., "A YANG Data Model for Optical Transport 3500 Network Topology", draft-ietf-ccamp-otn-topo-yang, work in 3501 progress. 3503 [ITU-T G.709-2016] ITU-T Recommendation G.709 (06/16), "Interface 3504 for the optical transport network", June 2016. 3506 Appendix A. Examples of dimensioning the "detailed connectivity matrix" 3508 In the following table, a list of the possible constraints, 3509 associated with their potential cardinality, is reported. 3511 The maximum number of potential connections to be computed and 3512 reported is, in first approximation, the multiplication of all of 3513 them. 3515 Constraint Cardinality 3516 ---------- ------------------------------------------------------- 3518 End points N(N-1)/2 if connections are bidirectional (OTN and WDM), 3519 N(N-1) for unidirectional connections. 3521 Bandwidth In WDM networks, bandwidth values are expressed in GHz. 3523 On fixed-grid WDM networks, the central frequencies are 3524 on a 50GHz grid and the channel width of the transmitters 3525 are typically 50GHz such that each central frequency can 3526 be used, i.e., adjacent channels can be placed next to 3527 each other in terms of central frequencies. 3529 On flex-grid WDM networks, the central frequencies are on 3530 a 6.25GHz grid and the channel width of the transmitters 3531 can be multiples of 12.5GHz. 3533 For fixed-grid WDM networks typically there is only one 3534 possible bandwidth value (i.e., 50GHz) while for flex- 3535 grid WDM networks typically there are 4 possible 3536 bandwidth values (e.g., 37.5GHz, 50GHz, 62.5GHz, 75GHz). 3538 In OTN (ODU) networks, bandwidth values are expressed as 3539 pairs of ODU type and, in case of ODUflex, ODU rate in 3540 bytes/sec as described in section 5 of [RFC7139]. 3542 For "fixed" ODUk types, 6 possible bandwidth values are 3543 possible (i.e., ODU0, ODU1, ODU2, ODU2e, ODU3, ODU4). 3545 For ODUflex(GFP), up to 80 different bandwidth values can 3546 be specified, as defined in Table 7-8 of [ITU-T G.709- 3547 2016]. 3549 For other ODUflex types, like ODUflex(CBR), the number of 3550 possible bandwidth values depends on the rates of the 3551 clients that could be mapped over these ODUflex types, as 3552 shown in Table 7.2 of [ITU-T G.709-2016], which in theory 3553 could be a countinuum of values. However, since different 3554 ODUflex bandwidths that use the same number of TSs on 3555 each link along the path are equivalent for path 3556 computation purposes, up to 120 different bandwidth 3557 ranges can be specified. 3559 Ideas to reduce the number of ODUflex bandwidth values in 3560 the detailed connectivity matrix, to less than 100, are 3561 for further study. 3563 Bandwidth specification for ODUCn is currently for 3564 further study but it is expected that other bandwidth 3565 values can be specified as integer multiples of 100Gb/s. 3567 In IP we have bandwidth values in bytes/sec. In 3568 principle, this is a countinuum of values, but in 3569 practice we can identify a set of bandwidth ranges, where 3570 any bandwidth value inside the same range produces the 3571 same path. 3572 The number of such ranges is the cardinality, which 3573 depends on the topology, available bandwidth and status 3574 of the network. Simulations (Note: reference paper 3575 submitted for publication) show that values for medium 3576 size topologies (around 50-150 nodes) are in the range 4- 3577 7 (5 on average) for each end points couple. 3579 Metrics IGP, TE and hop number are the basic objective metrics 3580 defined so far. There are also the 2 objective functions 3581 defined in [RFC5541]: Minimum Load Path (MLP) and Maximum 3582 Residual Bandwidth Path (MBP). Assuming that one only 3583 metric or objective function can be optimized at once, 3584 the total cardinality here is 5. 3586 With [RFC8233], a number of additional metrics are 3587 defined, including Path Delay metric, Path Delay 3588 Variation metric and Path Loss metric, both for point-to- 3589 point and point-to-multipoint paths. This increases the 3590 cardinality to 8. 3592 Bounds Each metric can be associated with a bound in order to 3593 find a path having a total value of that metric lower 3594 than the given bound. This has a potentially very high 3595 cardinality (as any value for the bound is allowed). In 3596 practice there is a maximum value of the bound (the one 3597 with the maximum value of the associated metric) which 3598 results always in the same path, and a range approach 3599 like for bandwidth in IP should produce also in this case 3600 the cardinality. Assuming to have a cardinality similar 3601 to the one of the bandwidth (let say 5 on average) we 3602 should have 6 (IGP, TE, hop, path delay, path delay 3603 variation and path loss; we don't consider here the two 3604 objective functions of [RFC5541] as they are conceived 3605 only for optimization)*5 = 30 cardinality. 3607 Technology 3608 constraints For further study 3610 Priority We have 8 values for set-up priority, which is used in 3611 path computation to route a path using free resources 3612 and, where no free resources are available, resources 3613 used by LSPs having a lower holding priority. 3615 Local prot It's possible to ask for a local protected service, where 3616 all the links used by the path are protected with fast 3617 reroute (this is only for IP networks, but line 3618 protection schemas are available on the other 3619 technologies as well). This adds an alternative path 3620 computation, so the cardinality of this constraint is 2. 3622 Administrative 3623 Colors Administrative colors (aka affinities) are typically 3624 assigned to links but when topology abstraction is used 3625 affinity information can also appear in the detailed 3626 connectivity matrix. 3628 There are 32 bits available for the affinities. Links can 3629 be tagged with any combination of these bits, and path 3630 computation can be constrained to include or exclude any 3631 or all of them. The relevant cardinality is 3 (include- 3632 any, exclude-any, include-all) times 2^32 possible 3633 values. However, the number of possible values used in 3634 real networks is quite small. 3636 Included Resources 3638 A path computation request can be associated to an 3639 ordered set of network resources (links, nodes) to be 3640 included along the computed path. This constraint would 3641 have a huge cardinality as in principle any combination 3642 of network resources is possible. However, as far as the 3643 client doesn't know details about the internal topology 3644 of the domain, it shouldn't include this type of 3645 constraint at all (see more details below). 3647 Excluded Resources 3649 A path computation request can be associated to a set of 3650 network resources (links, nodes, SRLGs) to be excluded 3651 from the computed path. Like for included resources, this 3652 constraint has a potentially very high cardinality, but, 3653 once again, it can't be actually used by the client, if 3654 it's not aware of the domain topology (see more details 3655 below). 3656 As discussed above, the client can specify include or exclude 3657 resources depending on the abstract topology information that the 3658 underlying controller exposes: 3660 o In case the underlying controller exposes the entire domain as a 3661 single abstract TE node with his own external terminations and 3662 detailed connectivity matrix (whose size we are estimating), no 3663 other topological details are available, therefore the size of the 3664 detailed connectivity matrix only depends on the combination of 3665 the constraints that the client can use in a path computation 3666 request to its underlying controller. These constraints cannot 3667 refer to any details of the internal topology of the domain, as 3668 those details are not known to the client and so they do not 3669 impact size of the detailed connectivity matrix exported. 3671 o Instead in case the underlying controller exposes a topology 3672 including more than one abstract TE nodes and TE links, and their 3673 attributes (e.g. SRLGs, affinities for the links), the client 3674 knows these details and therefore could compute a path across the 3675 domain referring to them in the constraints. The detailed 3676 connectivity matrixes, whose size need to be estimated here, are 3677 the ones relevant to the abstract TE nodes exported to the client. 3678 These detailed connectivity matrixes and therefore theirs sizes, 3679 while cannot depend on the other abstract TE nodes and TE links, 3680 which are external to the given abstract node, could depend to 3681 SRLGs (and other attributes, like affinities) which could be 3682 present also in the portion of the topology represented by the 3683 abstract nodes, and therefore contribute to the size of the 3684 related detailed connectivity matrix. 3686 We also don't consider here the possibility to ask for more than one 3687 path in diversity or for point-to-multi-point paths, which are for 3688 further study. 3690 Considering for example an IP domain without considering SRLG and 3691 affinities, we have an estimated number of paths depending on these 3692 estimated cardinalities: 3694 Endpoints = N*(N-1), Bandwidth = 5, Metrics = 6, Bounds = 20, 3695 Priority = 8, Local prot = 2 3697 The number of paths to be pre-computed by each IP domain is therefore 3698 24960 * N(N-1) where N is the number of domain access points. 3700 This means that with just 4 access points we have nearly 300000 paths 3701 to compute, advertise and maintain (if a change happens in the 3702 domain, due to a fault, or just the deployment of new traffic, a 3703 substantial number of paths need to be recomputed and the relevant 3704 changes advertised to the client). 3706 This seems quite challenging. In fact, if we assume a mean length of 3707 1K for the json describing a path (a quite conservative estimate), 3708 reporting 300000 paths means transferring and then parsing more than 3709 300 Mbytes for each domain. If we assume that 20% (to be checked) of 3710 this paths change when a new deployment of traffic occurs, we have 60 3711 Mbytes of transfer for each domain traversed by a new end-to-end 3712 path. If a network has, let say, 20 domains (we want to estimate the 3713 load for a non-trivial domain set-up) in the beginning a total 3714 initial transfer of 6Gigs is needed, and eventually, assuming 4-5 3715 domains are involved in mean during a path deployment we could have 3716 240-300 Mbytes of changes advertised to the client. 3718 Further bare-bone solutions can be investigated, removing some more 3719 options, if this is considered not acceptable; in conclusion, it 3720 seems that an approach based only on the information provided by the 3721 detailed connectivity matrix is hardly feasible, and could be 3722 applicable only to small networks with a limited meshing degree 3723 between domains and renouncing to a number of path computation 3724 features. 3726 Acknowledgments 3728 The authors would like to thank Igor Bryskin and Xian Zhang for 3729 participating in the initial discussions that have triggered this 3730 work and providing valuable insights. 3732 The authors would like to thank the authors of the TE tunnel YANG 3733 data model [TE-TUNNEL], in particular Igor Bryskin, Vishnu Pavan 3734 Beeram, Tarek Saad and Xufeng Liu, for their inputs to the 3735 discussions and support in having consistency between the Path 3736 Computation and TE tunnel YANG data models. 3738 The authors would like to thank Adrian Farrel, Dhruv Dhody, Igor 3739 Bryskin, Julien Meuric and Lou Berger for their valuable input to the 3740 discussions that has clarified that the path being set up is not 3741 necessarily the same as the path that has been previously computed 3742 and, in particular to Dhruv Dhody, for his suggestion to describe the 3743 need for a path verification phase to check that the actual path 3744 being set up meets the required end-to-end metrics and constraints. 3746 The authors would like to thank Aihua Guo, Lou Berger, Shaolong Gan, 3747 Martin Bjorklund and Tom Petch for their useful comments on how to 3748 define XPath statements in YANG RPCs. 3750 The authors would like to thank Haomian Zheng, Yanlei Zheng, Tom 3751 Petch, Aihua Guo and Martin Bjorklund for their review and valuable 3752 comments to this document. 3754 This document was prepared using 2-Word-v2.0.template.dot. 3756 Contributors 3758 Dieter Beller 3759 Nokia 3760 Email: dieter.beller@nokia.com 3762 Gianmarco Bruno 3763 Ericsson 3764 Email: gianmarco.bruno@ericsson.com 3765 Francesco Lazzeri 3766 Ericsson 3767 Email: francesco.lazzeri@ericsson.com 3769 Young Lee 3770 Samsung Electronics 3771 Email: younglee.tx@gmail.com 3773 Carlo Perocchio 3774 Ericsson 3775 Email: carlo.perocchio@ericsson.com 3777 Olivier Dugeon 3778 Orange Labs 3779 Email: olivier.dugeon@orange.com 3781 Julien Meuric 3782 Orange Labs 3783 Email: julien.meuric@orange.com 3785 Authors' Addresses 3787 Italo Busi (Editor) 3788 Huawei 3789 Email: italo.busi@huawei.com 3791 Sergio Belotti (Editor) 3792 Nokia 3793 Email: sergio.belotti@nokia.com 3795 Victor Lopez 3796 Nokia 3797 Email: victor.lopez@nokia.com 3799 Oscar Gonzalez de Dios 3800 Telefonica 3801 Email: oscar.gonzalezdedios@telefonica.com 3802 Anurag Sharma 3803 Google 3804 Email: ansha@google.com 3806 Yan Shi 3807 China Unicom 3808 Email: shiyan49@chinaunicom.cn 3810 Ricard Vilalta 3811 CTTC 3812 Email: ricard.vilalta@cttc.es 3814 Karthik Sethuraman 3815 NEC 3816 Email: karthik.sethuraman@necam.com 3818 Michael Scharf 3819 Nokia 3820 Email: michael.scharf@gmail.com 3822 Daniele Ceccarelli 3823 Ericsson 3824 Email: daniele.ceccarelli@ericsson.com