idnits 2.17.1 draft-ietf-teas-yang-path-computation-16.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 1421 has weird spacing: '...ic-type ide...' == Line 1429 has weird spacing: '...- usage ide...' == Line 1440 has weird spacing: '...k-tp-id te-...' == Line 1445 has weird spacing: '...k-tp-id te-...' == Line 1451 has weird spacing: '...-number ine...' == (51 more instances...) -- The document date (September 6, 2021) is 963 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 3403, 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: March 2022 Nokia 5 Victor Lopez 6 Nokia 7 Anurag Sharma 8 Google 9 Yan Shi 10 China Unicom 12 September 6, 2021 14 YANG Data Model for requesting Path Computation 15 draft-ietf-teas-yang-path-computation-16 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 March 6, 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 97 computation.........................................27 98 3.3. Path Computation RPC.....................................30 99 3.3.1. Temporary reporting of the computed path state......32 100 4. Path computation and optimization for multiple paths..........34 101 5. YANG data model for requesting Path Computation...............35 102 5.1. Synchronization of multiple path computation requests....35 103 5.2. Returned metric values...................................38 104 5.3. Multiple Paths Requests for the same TE tunnel...........39 105 5.3.1. Tunnel attributes specified by value................41 106 5.3.2. Tunnel attributes specified by reference............42 107 5.4. Multi-Layer Path Computation.............................44 108 6. YANG data model for TE path computation.......................45 109 6.1. Tree diagram.............................................45 110 6.2. YANG module..............................................59 111 7. Security Considerations.......................................84 112 8. IANA Considerations...........................................85 113 9. References....................................................85 114 9.1. Normative References.....................................85 115 9.2. Informative References...................................87 116 Appendix A. Examples of dimensioning the "detailed 117 connectivity matrix"..............................89 118 Acknowledgments..................................................95 119 Contributors.....................................................95 120 Authors' Addresses...............................................96 122 1. Introduction 124 There are scenarios, typically in a hierarchical Software-Defined 125 Networking (SDN) context, where the topology information provided by 126 a Traffic Engineering (TE) network provider may be insufficient for 127 its client to perform end-to-end path computation. In these cases the 128 client would need to request the provider to calculate some (partial) 129 feasible paths, complementing his topology knowledge, to make his 130 end-to-end path computation feasible. 132 This type of scenarios can be applied to different interfaces in 133 different reference architectures: 135 o Application-Based Network Operations (ABNO) control interface 136 [RFC7491], in which an Application Service Coordinator can request 137 ABNO controller to take in charge path calculation (see Figure 1 138 in [RFC7491]). 140 o Abstraction and Control of TE Networks (ACTN) [RFC8453], where a 141 controller hierarchy is defined, the need for path computation 142 arises on the interface between Customer Network Controller (CNC) 143 and Multi-Domain Service Coordinator (MDSC), called CNC-MDSC 144 Interface (CMI), and on the interface between MSDC and 145 Provisioning Network Controller (PNC), called MDSC-PNC Interface 146 (MPI). [RFC8454] describes an information model for the Path 147 Computation request. 149 Multiple protocol solutions can be used for communication between 150 different controller hierarchical levels. This document assumes that 151 the controllers are communicating using YANG-based protocols (e.g., 152 NETCONF [RFC6241] or RESTCONF [RFC8040]). 154 Path Computation Elements (PCEs), controllers and orchestrators 155 perform their operations based on Traffic Engineering Databases 156 (TED). Such TEDs can be described, in a technology agnostic way, with 157 the YANG data model for TE Topologies [RFC8795]. Furthermore, the 158 technology specific details of the TED are modeled in the augmented 159 TE topology models, e.g. [OTN-TOPO] for Optical Transport Network 160 (OTN) Optical Data Unit (ODU) technologies. 162 The availability of such topology models allows the provisioning of 163 the TED using YANG-based protocols (e.g., NETCONF or RESTCONF). 164 Furthermore, it enables a PCE/controller performing the necessary 165 abstractions or modifications and offering this customized topology 166 to another PCE/controller or high level orchestrator. 168 The tunnels that can be provided over the networks described with the 169 topology models can be also set-up, deleted and modified via YANG- 170 based protocols (e.g., NETCONF or RESTCONF) using the TE tunnel YANG 171 data model [TE-TUNNEL]. 173 This document defines a YANG data model [RFC7950] for an RPC to 174 request path computation, which complements the solution defined in 175 [TE-TUNNEL], to configure a TE tunnel path in "compute-only" mode. 177 The YANG data model definition does not make any assumption about 178 whether that the client or the server implement a "PCE" 179 functionality, as defined in [RFC4655], and the Path Computation 180 Element Communication Protocol (PCEP) protocol, as defined in 181 [RFC5440]. 183 Moreover, this document describes some use cases where a path 184 computation request, via YANG-based protocols (e.g., NETCONF or 185 RESTCONF), can be needed. 187 The YANG data model defined in this document conforms to the Network 188 Management Datastore Architecture [RFC8342]. 190 1.1. Terminology 192 TED: The traffic engineering database is a collection of all TE 193 information about all TE nodes and TE links in a given network. 195 PCE: A Path Computation Element (PCE) is an entity that is capable of 196 computing a network path or route based on a network graph, and of 197 applying computational constraints during the computation. The PCE 198 entity is an application that can be located within a network node or 199 component, on an out-of-network server, etc. For example, a PCE 200 would be able to compute the path of a TE Label Switched Path (LSP) 201 by operating on the TED and considering bandwidth and other 202 constraints applicable to the TE LSP service request. [RFC4655]. 204 Domain: TE information is the data relating to nodes and TE links 205 that is used in the process of selecting a TE path. TE information 206 is usually only available within a network. We call such a zone of 207 visibility of TE information a domain. An example of a domain may be 208 an IGP area or an Autonomous System. [RFC7926] 210 The terminology for describing YANG data models is found in 211 [RFC7950]. 213 1.2. Tree Diagram 215 Tree diagrams used in this document follow the notation defined in 216 [RFC8340]. 218 1.3. Prefixes in Data Node Names 220 In this document, names of data nodes and other data model objects 221 are prefixed using the standard prefix associated with the 222 corresponding YANG imported modules, as shown in Table 1. 224 +---------------+--------------------------+-----------------+ 225 | Prefix | YANG module | Reference | 226 +---------------+--------------------------+-----------------+ 227 | inet | ietf-inet-types | [RFC6991] | 228 | te-types | ietf-te-types | [RFC8776] | 229 | te | ietf-te | [TE-TUNNEL] | 230 | te-pc | ietf-te-path-computation | this document | 231 +---------------+--------------------------+-----------------+ 233 Table 1: Prefixes and corresponding YANG modules 235 2. Use Cases 237 This section presents some use cases, where a client needs to request 238 underlying SDN controllers for path computation. 240 The use of the YANG data model defined in this document is not 241 restricted to these use cases but can be used in any other use case 242 when deemed useful. 244 The presented uses cases have been grouped, depending on the 245 different underlying topologies: a) Packet/Optical Integration; b) 246 multi-domain Traffic Engineered (TE) Networks; and c) Data Center 247 Interconnections. Use cases d) and e) respectively present how to 248 apply this YANG data model for standard multi-domain PCE i.e. 249 Backward Recursive Path Computation [RFC5441] and Hierarchical PCE 250 [RFC6805]. 252 2.1. Packet/Optical Integration 254 In this use case, an optical domain is used to provide connectivity 255 to some nodes of a packet domain (see Figure 1). 257 +----------------+ 258 | | 259 | Packet/Optical | 260 | Coordinator | 261 | | 262 +---+------+-----+ 263 | | 264 +------------+ | 265 | +-----------+ 266 +------V-----+ | 267 | | +------V-----+ 268 | Packet | | | 269 | Domain | | Optical | 270 | Controller | | Domain | 271 | | | Controller | 272 +------+-----+ +-------+----+ 273 | | 274 .........V......................... | 275 : packet domain : | 276 +----+ +----+ | 277 | R1 |= = = = = = = = = = = = = = = =| R2 | | 278 +-+--+ +--+-+ | 279 | : : | | 280 | :................................ : | | 281 | | | 282 | +-----+ | | 283 | ...........| Opt |........... | | 284 | : | C | : | | 285 | : /+--+--+\ : | | 286 | : / | \ : | | 287 | : / | \ : | | 288 | +-----+ / +--+--+ \ +-----+ | | 289 | | Opt |/ | Opt | \| Opt | | | 290 +---| A | | D | | B |---+ | 291 +-----+\ +--+--+ /+-----+ | 292 : \ | / : | 293 : \ | / : | 294 : \ +--+--+ / optical<---------+ 295 : \| Opt |/ domain : 296 :..........| E |..........: 297 +-----+ 299 Figure 1 - Packet/Optical Integration use case 301 Figure 1 as well as Figure 2 below only show a partial view of the 302 packet network connectivity, before additional packet connectivity is 303 provided by the optical network. 305 It is assumed that the Optical Domain Controller provides to the 306 Packet/Optical Coordinator an abstracted view of the optical network. 307 A possible abstraction could be to represent the whole optical 308 network as one "virtual node" with "virtual ports" connected to the 309 access links, as shown in Figure 2. 311 It is also assumed that Packet Domain Controller can provide the 312 Packet/Optical Coordinator the information it needs to set up 313 connectivity between packet nodes through the optical network (e.g., 314 the access links). 316 The path computation request helps the Packet/Optical Coordinator to 317 know the real connections that can be provided by the optical 318 network. 320 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,. 321 , Packet/Optical Coordinator view , 322 , +----+ , . 323 , | | , 324 , | R2 | , . 325 , +----+ +------------ + /+----+ , 326 , | | | |/-----/ / / , . 327 , | R1 |--O VP1 VP4 O / / , 328 , | |\ | | /----/ / , . 329 , +----+ \| |/ / , 330 , / O VP2 VP5 O / , . 331 , / | | +----+ , 332 , / | | | | , . 333 , / O VP3 VP6 O--| R4 | , 334 , +----+ /-----/|_____________| +----+ , . 335 , | |/ +------------ + , 336 , | R3 | , . 337 , +----+ ,,,,,,,,,,,,,,,,, 338 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,. 339 . Packet Domain Controller view +----+ , 340 only packet nodes and packet links | | , . 341 . with access links to the optical network | R2 | , 342 , +----+ /+----+ , . 343 . , | | /-----/ / / , 344 , | R1 |--- / / , . 345 . , +----+\ /----/ / , 346 , / \ / / , . 347 . , / / , 348 , / +----+ , . 349 . , / | | , 350 , / ---| R4 | , . 351 . , +----+ /-----/ +----+ , 352 , | |/ , . 353 . , | R3 | , 354 , +----+ ,,,,,,,,,,,,,,,,,. 355 .,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, , 356 Optical Domain Controller view , . 357 . only optical nodes, +--+ , 358 optical links and /|OF| , . 359 . access links from the +--++--+ / , 360 packet network |OA| \ /-----/ / , . 361 . , ---+--+--\ +--+/ / , 362 , \ | \ \-|OE|-------/ , . 363 . , \ | \ /-+--+ , 364 , \+--+ X | , . 365 . , |OB|-/ \ | , 366 , +--+-\ \+--+ , . 367 . , / \ \--|OD|--- , 368 , /-----/ +--+ +--+ , . 369 . , / |OC|/ , 370 , +--+ , . 371 ., ,,,,,,,,,,,,,,,,,, 372 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, , 373 . Actual Physical View +----+ , 374 , +--+ | | , 375 . , /|OF| | R2 | , 376 , +----+ +--++--+ /+----+ , 377 . , | | |OA| \ /-----/ / / , 378 , | R1 |---+--+--\ +--+/ / / , 379 . , +----+\ | \ \-|OE|-------/ / , 380 , / \ | \ /-+--+ / , 381 . , / \+--+ X | / , 382 , / |OB|-/ \ | +----+ , 383 . , / +--+-\ \+--+ | | , 384 , / / \ \--|OD|---| R4 | , 385 . , +----+ /-----/ +--+ +--+ +----+ , 386 , | |/ |OC|/ , 387 . , | R3 | +--+ , 388 , +----+ , 389 .,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 391 Figure 2 - Packet and Optical Topology Abstractions 393 In this use case, the Packet/Optical Coordinator needs to set up an 394 optimal underlying path for an IP link between R1 and R2. 396 As depicted in Figure 2, the Packet/Optical Coordinator has only an 397 "abstracted view" of the physical network, and it does not know the 398 feasibility or the cost of the possible optical paths (e.g., VP1-VP4 399 and VP2-VP5), which depend on the current status of the physical 400 resources within the optical network and on vendor-specific optical 401 attributes. 403 The Packet/Optical Coordinator can request the underlying Optical 404 Domain Controller to compute a set of potential optimal paths, taking 405 into account optical constraints. Then, based on its own constraints, 406 policy and knowledge (e.g. cost of the access links), it can choose 407 which one of these potential paths to use to set up the optimal end- 408 to-end path crossing optical network. 410 ............................ 411 : : 412 O VP1 VP4 O 413 cost=10 /:\ /:\ cost=10 414 / : \----------------------/ : \ 415 +----+ / : cost=50 : \ +----+ 416 | |/ : : \| | 417 | R1 | : : | R2 | 418 | |\ : : /| | 419 +----+ \ : /--------------------\ : / +----+ 420 \ : / cost=55 \ : / 421 cost=5 \:/ \:/ cost=5 422 O VP2 VP5 O 423 : : 424 :..........................: 426 Figure 3 - Packet/Optical Integration path computation 427 example 429 For example, in Figure 3, the Packet/Optical Coordinator can request 430 the Optical Domain Controller to compute the paths between VP1-VP4 431 and VP2-VP5 and then decide to set up the optimal end-to-end path 432 using the VP2-VP5 optical path even if this is not the optimal path 433 from the optical domain perspective. 435 Considering the dynamicity of the connectivity constraints of an 436 optical domain, it is possible that a path computed by the Optical 437 Domain Controller when requested by the Packet/Optical Coordinator is 438 no longer valid/available when the Packet/Optical Coordinator 439 requests it to be set up. This is further discussed in section 3.3. 441 2.2. Multi-domain TE networks 443 In this use case there are two TE domains which are interconnected 444 together by multiple inter-domains links. 446 A possible example could be a multi-domain optical network. 448 +--------------+ 449 | Multi-Domain | 450 | Controller | 451 +---+------+---+ 452 | | 453 +------------+ | 454 | +-----------+ 455 +------V-----+ | 456 | | | 457 | TE Domain | +------V-----+ 458 | Controller | | | 459 | 1 | | TE Domain | 460 +------+-----+ | Controller | 461 | | 2 | 462 | +------+-----+ 463 .........V.......... | 464 : : | 465 +-----+ : | 466 | | : .........V.......... 467 | X | : : : 468 | | +-----+ +-----+ : 469 +-----+ | | | | : 470 : | C |------| E | : 471 +-----+ +-----+ /| | | |\ +-----+ +-----+ 472 | | | |/ +-----+ +-----+ \| | | | 473 | A |----| B | : : | G |----| H | 474 | | | |\ : : /| | | | 475 +-----+ +-----+ \+-----+ +-----+/ +-----+ +-----+ 476 : | | | | : 477 : | D |------| F | : 478 : | | | | +-----+ 479 : +-----+ +-----+ | | 480 : : : | Y | 481 : : : | | 482 : TE domain 1 : : TE domain 2 +-----+ 483 :..................: :.................: 485 Figure 4 - Multi-domain multi-link interconnection 487 In order to set up an end-to-end multi-domain TE path (e.g., between 488 nodes A and H), the Multi-Domain Controller needs to know the 489 feasibility or the cost of the possible TE paths within the two TE 490 domains, which depend on the current status of the physical resources 491 within each TE domain. This is more challenging in case of optical 492 networks because the optimal paths depend also on vendor-specific 493 optical attributes (which may be different in the two domains if they 494 are provided by different vendors). 496 In order to set up a multi-domain TE path (e.g., between nodes A and 497 H), the Multi-Domain Controller can request the TE Domain Controllers 498 to compute a set of intra-domain optimal paths and take decisions 499 based on the information received. For example: 501 o The Multi-Domain Controller asks TE Domain Controllers to provide 502 set of paths between A-C, A-D, E-H and F-H 504 o TE Domain Controllers return a set of feasible paths with the 505 associated costs: the path A-C is not part of this set (in optical 506 networks, it is typical to have some paths not being feasible due 507 to optical constraints that are known only by the Optical Domain 508 Controller) 510 o The Multi-Domain Controller will select the path A-D-F-H since it 511 is the only feasible multi-domain path and then request the TE 512 Domain Controllers to set up the A-D and F-H intra-domain paths 514 o If there are multiple feasible paths, the Multi-Domain Controller 515 can select the optimal path knowing the cost of the intra-domain 516 paths (provided by the TE domain controllers) and the cost of the 517 inter-domain links (known by the Multi-Domain Controller) 519 This approach may have some scalability issues when the number of TE 520 domains is quite big (e.g. 20). 522 In this case, it would be worthwhile using the abstract TE topology 523 information provided by the TE Domain Controllers to limit the number 524 of potential optimal end-to-end paths and then request path 525 computation from fewer TE Domain Controllers in order to decide what 526 the optimal path within this limited set is. 528 For more details, see section 3.2.3. 530 2.3. Data Center Interconnections 532 In these use case, there is a TE domain which is used to provide 533 connectivity between Data Centers which are connected with the TE 534 domain using access links. 536 +--------------+ 537 | Cloud Network| 538 | Orchestrator | 539 +--------------+ 540 | | | | 541 +-------------+ | | +------------------------+ 542 | | +------------------+ | 543 | +--------V---+ | | 544 | | | | | 545 | | TE Network | | | 546 +------V-----+ | Controller | +------V-----+ | 547 | DC | +------------+ | DC | | 548 | Controller | | | Controller | | 549 +------------+ | +-----+ +------------+ | 550 | ....V...| |........ | | 551 | : | P | : | | 552 .....V..... : /+-----+\ : .....V..... | 553 : : +-----+ / | \ +-----+ : : | 554 : DC1 || : | |/ | \| | : DC2 || : | 555 : ||||----| PE1 | | | PE2 |---- |||| : | 556 : _|||||| : | |\ | /| | : _|||||| : | 557 : : +-----+ \ +-----+ / +-----+ : : | 558 :.........: : \| |/ : :.........: | 559 :.......| PE3 |.......: | 560 | | | 561 +-----+ +---------V--+ 562 .....|..... | DC | 563 : : | Controller | 564 : DC3 || : +------------+ 565 : |||| : | 566 : _|||||| <------------------+ 567 : : 568 :.........: 570 Figure 5 - Data Center Interconnection use case 572 In this use case, there is the need to transfer data from Data Center 573 1 (DC1) to either DC2 or DC3 (e.g. workload migration). 575 The optimal decision depends both on the cost of the TE path (DC1-DC2 576 or DC1-DC3) and of the Data Center resources within DC2 or DC3. 578 The Cloud Network Orchestrator needs to make a decision for optimal 579 connection based on TE network constraints and Data Center resources. 581 It may not be able to make this decision because it has only an 582 abstract view of the TE network (as in use case in 2.1). 584 The Cloud Network Orchestrator can request to the TE Network 585 Controller to compute the cost of the possible TE paths (e.g., DC1- 586 DC2 and DC1-DC3) and to the DC Controller to provide the information 587 it needs about the required Data Center resources within DC2 and DC3 588 and then it can take the decision about the optimal solution based on 589 this information and its policy. 591 2.4. Backward Recursive Path Computation scenario 593 [RFC5441] has defined the Virtual Source Path Tree (VSPT) TLV within 594 PCE Reply Object in order to compute inter-domain paths following a 595 "Backward Recursive Path Computation" (BRPC) method. The main 596 principle is to forward the PCE request message up to the destination 597 domain. Then, each PCE involved in the computation will compute its 598 part of the path and send it back to the requester through PCE 599 Response message. The resulting computation is spread from 600 destination PCE to source PCE. Each PCE is in charge of merging the 601 path it received with the one it calculated. At the end, the source 602 PCE merges its local part of the path with the received one to 603 achieve the end-to-end path. 605 Figure 6 below show a typical BRPC scenario where 3 PCEs cooperate to 606 compute inter-domain paths. 608 +----------------+ +----------------+ 609 | Domain (B) | | Domain (C) | 610 | | | | 611 | /-------|---PCEP---|--------\ | 612 | / | | \ | 613 | (PCE) | | - (PCE) | 614 | / <----------> |D| | 615 | / | Inter | - | 616 +---|----^-------+ Domain +----------------+ 617 | | Link 618 PCEP | 619 | | Inter-domain Link 620 | | 621 +---|----v-------+ 622 | | | 623 | | Domain (A) | 624 | \ | 625 | (PCE) - | 626 | |S| | 627 | - | 628 +----------------+ 629 Figure 6 - BRPC Scenario 631 In this use case, a client can use the YANG data model defined in 632 this document to request path computation from the PCE that controls 633 the source of the tunnel. For example, a client can request to the 634 PCE of domain A to compute a path from a source S, within domain A, 635 to a destination D, within domain C. Then PCE of domain A will use 636 PCEP protocol, as per [RFC5441], to compute the path from S to D and 637 in turn gives the final answer to the requester. 639 2.5. Hierarchical PCE scenario 641 [RFC6805] has defined an architecture and extensions to the PCE 642 standard to compute inter-domain path following a hierarchical 643 method. Two new roles have been defined: parent PCE and child PCE. 644 The parent PCE is in charge to coordinate the end-to-end path 645 computation. For that purpose it sends to each child PCE involved in 646 the multi-domain path computation a PCE Request message to obtain the 647 local part of the path. Once received all answer through PCE Response 648 message, the parent PCE will merge the different local parts of the 649 path to achieve the end-to-end path. 651 Figure 7 below shows a typical hierarchical scenario where a parent 652 PCE request end-to-end path to the different child PCE. Note that a 653 PCE could take independently the role of child or parent PCE 654 depending of which PCE will request the path. 656 ----------------------------------------------------------------- 657 | Domain 5 | 658 | ----- | 659 | |PCE 5| | 660 | ----- | 661 | | 662 | ---------------- ---------------- ---------------- | 663 | | Domain 1 | | Domain 2 | | Domain 3 | | 664 | | | | | | | | 665 | | ----- | | ----- | | ----- | | 666 | | |PCE 1| | | |PCE 2| | | |PCE 3| | | 667 | | ----- | | ----- | | ----- | | 668 | | | | | | | | 669 | | ----| |---- ----| |---- | | 670 | | |BN11+---+BN21| |BN23+---+BN31| | | 671 | | - ----| |---- ----| |---- - | | 672 | | |S| | | | | |D| | | 673 | | - ----| |---- ----| |---- - | | 674 | | |BN12+---+BN22| |BN24+---+BN32| | | 675 | | ----| |---- ----| |---- | | 676 | | | | | | | | 677 | | ---- | | | | ---- | | 678 | | |BN13| | | | | |BN33| | | 679 | -----------+---- ---------------- ----+----------- | 680 | \ / | 681 | \ ---------------- / | 682 | \ | | / | 683 | \ |---- ----| / | 684 | ----+BN41| |BN42+---- | 685 | |---- ----| | 686 | | | | 687 | | ----- | | 688 | | |PCE 4| | | 689 | | ----- | | 690 | | | | 691 | | Domain 4 | | 692 | ---------------- | 693 | | 694 ----------------------------------------------------------------- 695 Figure 7 - Hierarchical domain topology from [RFC6805] 697 In this use case, a client can use the YANG data model defined in 698 this document to request to the parent PCE a path from a source S to 699 a destination D. The parent PCE will in turn contact the child PCEs 700 through PCEP protocol to compute the end-to-end path and then return 701 the computed path to the client, using the YANG data model defined in 702 this document. For example the YANG data model can be used to request 703 to PCE5 acting as parent PCE to compute a path from source S, within 704 domain 1, to destination D, within domain 3. PCE5 will contact child 705 PCEs of domain 1, 2 and 3 to obtain local part of the end-to-end path 706 through the PCEP protocol. Once received the PCE Response message, it 707 merges the answers to compute the end-to-end path and send it back to 708 the client. 710 3. Motivations 712 This section provides the motivation for the YANG data model defined 713 in this document. 715 Section 3.1 describes the motivation for a YANG data model to request 716 path computation. 718 Section 3.2 describes the motivation for a YANG data model which 719 complements the TE topology YANG data model defined in [RFC8795]. 721 Section 3.3 describes the motivation for a YANG RPC which complements 722 the TE tunnel YANG data model defined in [TE-TUNNEL]. 724 3.1. Motivation for a YANG Model 726 3.1.1. Benefits of common data models 728 The YANG data model for requesting path computation is closely 729 aligned with the YANG data models that provide (abstract) TE topology 730 information, i.e., [RFC8795] as well as that are used to configure 731 and manage TE tunnels, i.e., [TE-TUNNEL]. 733 There are many benefits in aligning the data model used for path 734 computation requests with the YANG data models used for TE topology 735 information and for TE tunnels configuration and management: 737 o There is no need for an error-prone mapping or correlation of 738 information. 740 o It is possible to use the same endpoint identifiers in path 741 computation requests and in the topology modeling. 743 o The attributes used for path computation constraints are the same 744 as those used when setting up a TE tunnel. 746 3.1.2. Benefits of a single interface 748 The system integration effort is typically lower if a single, 749 consistent interface is used by controllers, i.e., one data modeling 750 language (i.e., YANG) and a common protocol (e.g., NETCONF or 751 RESTCONF). 753 Practical benefits of using a single, consistent interface include: 755 1. Simple authentication and authorization: The interface between 756 different components has to be secured. If different protocols 757 have different security mechanisms, ensuring a common access 758 control model may result in overhead. For instance, there may be a 759 need to deal with different security mechanisms, e.g., different 760 credentials or keys. This can result in increased integration 761 effort. 763 2. Consistency: Keeping data consistent over multiple different 764 interfaces or protocols is not trivial. For instance, the sequence 765 of actions can matter in certain use cases, or transaction 766 semantics could be desired. While ensuring consistency within one 767 protocol can already be challenging, it is typically cumbersome to 768 achieve that across different protocols. 770 3. Testing: System integration requires comprehensive testing, 771 including corner cases. The more different technologies are 772 involved, the more difficult it is to run comprehensive test cases 773 and ensure proper integration. 775 4. Middle-box friendliness: Provider and consumer of path computation 776 requests may be located in different networks, and middle-boxes 777 such as firewalls, NATs, or load balancers may be deployed. In 778 such environments it is simpler to deploy a single protocol. Also, 779 it may be easier to debug connectivity problems. 781 5. Tooling reuse: Implementers may want to implement path computation 782 requests with tools and libraries that already exist in 783 controllers and/or orchestrators, e.g., leveraging the rapidly 784 growing eco-system for YANG tooling. 786 3.1.3. Extensibility 788 Path computation is only a subset of the typical functionality of a 789 controller. In many use cases, issuing path computation requests 790 comes along with the need to access other functionality on the same 791 system. In addition to obtaining TE topology, for instance also 792 configuration of services (set-up/modification/deletion) may be 793 required, as well as: 795 1. Receiving notifications for topology changes as well as 796 integration with fault management 798 2. Performance management such as retrieving monitoring and telemetry 799 data 801 3. Service assurance, e.g., by triggering OAM functionality 803 4. Other fulfilment and provisioning actions beyond tunnels and 804 services, such as changing QoS configurations 806 YANG is a very extensible and flexible data modeling language that 807 can be used for all these use cases. 809 3.2. Interactions with TE topology 811 The use cases described in section 2 have been described assuming 812 that the topology view exported by each underlying controller to its 813 client is aggregated using the "virtual node model", defined in 814 [RFC7926]. 816 TE topology information, e.g., as provided by [RFC8795], could in 817 theory be used by an underlying controller to provide TE information 818 to its client thus allowing a PCE available within its client to 819 perform multi-domain path computation on its own, without requesting 820 path computations to the underlying controllers. 822 In case the client does not implement a PCE function, as discussed in 823 section 1, it could not perform path computation based on TE topology 824 information and would instead need to request path computation from 825 the underlying controllers to get the information it needs to find 826 the optimal end-to-end path. 828 In case the client implements a PCE function, as discussed in section 829 1, the TE topology information needs to be complete and accurate, 830 which would bring to scalability issues. 832 Using TE topology to provide a "virtual link model" aggregation, as 833 described in [RFC7926], may be insufficient, unless the aggregation 834 provides a complete and accurate information, which would still cause 835 scalability issues, as described in sections 3.2.1 below. 837 Using TE topology abstraction, as described in [RFC7926], may lead to 838 compute an unfeasible path, as described in [RFC7926] in section 839 3.2.2 below. 841 Therefore when computing an optimal multi-domain path, there is a 842 scalability trade-off between providing complete and accurate TE 843 information and the number of path computation requests to the 844 underlying controllers. 846 The TE topology information used, in a complimentary way, to reduce 847 the number for path computation requests to the underlying 848 controllers, are described in section 3.2.3 below. 850 3.2.1. TE topology aggregation 852 Using the TE topology model, as defined in [RFC8795], the underlying 853 controller can export the whole TE domain as a single TE node with a 854 "detailed connectivity matrix" (which provides specific TE 855 attributes, such as delay, Shared Risk Link Groups (SRLGs) and other 856 TE metrics, between each ingress and egress links). 858 The information provided by the "detailed connectivity matrix" would 859 be equivalent to the information that should be provided by "virtual 860 link model" as defined in [RFC7926]. 862 For example, in the Packet/Optical Integration use case, described in 863 section 2.1, the Optical Domain Controller can make the information 864 shown in Figure 3 available to the Packet/Optical Coordinator as part 865 of the TE topology information and the Packet/Optical Coordinator 866 could use this information to calculate on its own the optimal path 867 between R1 and R2, without requesting any additional information to 868 the Optical Domain Controller. 870 However, when designing the amount of information to provide within 871 the "detailed connectivity matrix", there is a tradeoff to be 872 considered between accuracy (i.e., providing "all" the information 873 that might be needed by the PCE available within the client) and 874 scalability. 876 Figure 8 below shows another example, similar to Figure 3, where 877 there are two possible Optical paths between VP1 and VP4 with 878 different properties (e.g., available bandwidth and cost). 880 ............................ 881 : /--------------------\ : 882 : / cost=65 \ : 883 :/ available-bw=10G \: 884 O VP1 VP4 O 885 cost=10 /:\ /:\ cost=10 886 / : \----------------------/ : \ 887 +----+ / : cost=50 : \ +----+ 888 | |/ : available-bw=2G : \| | 889 | R1 | : : | R2 | 890 | |\ : : /| | 891 +----+ \ : /--------------------\ : / +----+ 892 \ : / cost=55 \ : / 893 cost=5 \:/ available-bw=3G \:/ cost=5 894 O VP2 VP5 O 895 : : 896 :..........................: 898 Figure 8 - Packet/Optical Integration path computation 899 example with multiple choices 901 If the information in the "detailed connectivity matrix" is not 902 complete/accurate, we can have the following drawbacks: 904 o If only the VP1-VP4 path with available bandwidth of 2 Gb/s and 905 cost 50 is reported, the client's PCE will fail to compute a 5 906 Gb/s path between routers R1 and R2, although this would be 907 feasible; 909 o If only the VP1-VP4 path with available bandwidth of 10 Gb/s and 910 cost 60 is reported, the client's PCE will compute, as optimal, 911 the 1 Gb/s path between R1 and R2 going through the VP2-VP5 path 912 within the optical domain while the optimal path would actually be 913 the one going thought the VP1-VP4 sub-path (with cost 50) within 914 the optical domain. 916 Reporting all the information, as in Figure 8, using the "detailed 917 connectivity matrix", is quite challenging from a scalability 918 perspective. The amount of this information is not just based on 919 number of end points (which would scale as N-square), but also on 920 many other parameters, including client rate, user 921 constraints/policies for the service, e.g. max latency < N ms, max 922 cost, etc., exclusion policies to route around busy links, min 923 Optical Signal to Noise Ratio (OSNR) margin, max pre-Forward Error 924 Correction (FEC) Bit Error Rate (BER) etc. All these constraints 925 could be different based on connectivity requirements. 927 Examples of how the "detailed connectivity matrix" can be dimensioned 928 are described in Appendix A. 930 It is also worth noting that the "connectivity matrix" has been 931 originally defined in Wavelength Switched Optical Networks (WSON), 932 [RFC7446], to report the connectivity constrains of a physical node 933 within the Wavelength Division Multiplexing (WDM) network: the 934 information it contains is pretty "static" and therefore, once taken 935 and stored in the TE data base, it can be always being considered 936 valid and up-to-date in path computation request. 938 The "connectivity matrix" is sometimes confused with "optical reach 939 table" that contain multiple (e.g. k-shortest) regen-free reachable 940 paths for every A-Z node combination in the network. Optical reach 941 tables can be calculated offline, utilizing vendor optical design and 942 planning tools, and periodically uploaded to the Controller: these 943 optical path reach tables are fairly static. However, to get the 944 connectivity matrix, between any two sites, either a regen free path 945 can be used, if one is available, or multiple regen free paths are 946 concatenated to get from the source to the destination, which can be 947 a very large combination. Additionally, when the optical path within 948 optical domain needs to be computed, it can result in different paths 949 based on input objective, constraints, and network conditions. In 950 summary, even though "optical reach table" is fairly static, which 951 regen free paths to build the connectivity matrix between any source 952 and destination is very dynamic, and is done using very sophisticated 953 routing algorithms. 955 Using the "basic connectivity matrix" with an abstract node to 956 abstract the information regarding the connectivity constraints of an 957 Optical domain, would make this information more "dynamic" since the 958 connectivity constraints of an optical domain can change over time 959 because some optical paths that are feasible at a given time may 960 become unfeasible at a later time when e.g., another optical path is 961 established. 963 The information in the "detailed connectivity matrix" is even more 964 dynamic since the establishment of another optical path may change 965 some of the parameters (e.g., delay or available bandwidth) in the 966 "detailed connectivity matrix" while not changing the feasibility of 967 the path. 969 There is therefore the need to keep the information in the "detailed 970 connectivity matrix" updated which means that there another tradeoff 971 between the accuracy (i.e., providing "all" the information that 972 might be needed by the client's PCE) and having up-to-date 973 information. The more the information is provided and the longer it 974 takes to keep it up-to-date which increases the likelihood that the 975 client's PCE computes paths using not updated information. 977 It seems therefore quite challenging to have a "detailed connectivity 978 matrix" that provides accurate, scalable and updated information to 979 allow the client's PCE to take optimal decisions by its own. 981 Considering the example in Figure 8 with the approach defined in this 982 document, the client, when it needs to set up an end-to-end path, it 983 can request the Optical Domain Controller to compute a set of optimal 984 paths (e.g., for VP1-VP4 and VP2-VP5) and take decisions based on the 985 information received: 987 o When setting up a 5 Gb/s path between routers R1 and R2, the 988 Optical Domain Controller may report only the VP1-VP4 path as the 989 only feasible path: the Packet/Optical Coordinator can 990 successfully set up the end-to-end path passing though this 991 optical path; 993 o When setting up a 1 Gb/s path between routers R1 and R2, the 994 Optical Domain Controller (knowing that the path requires only 1 995 Gb/s) can report both the VP1-VP4 path, with cost 50, and the VP2- 996 VP5 path, with cost 65. The Packet/Optical Coordinator can then 997 compute the optimal path which is passing thought the VP1-VP4 sub- 998 path (with cost 50) within the optical domain. 1000 3.2.2. TE topology abstraction 1002 Using the TE topology model, as defined in [RFC8795], the underlying 1003 controller can export to its client an abstract TE topology, composed 1004 by a set of TE nodes and TE links, representing the abstract view of 1005 the topology under its control. 1007 For example, in the multi-domain TE network use case, described in 1008 section 2.2, the TE Domain Controller 1 can export a TE topology 1009 encompassing the TE nodes A, B, C and D and the TE links 1010 interconnecting them. In a similar way, the TE Domain Controller 2 1011 can export a TE topology encompassing the TE nodes E, F, G and H and 1012 the TE links interconnecting them. 1014 In this example, for simplicity reasons, each abstract TE node maps 1015 with each physical node, but this is not necessary. 1017 In order to set up a multi-domain TE path (e.g., between nodes A and 1018 H), the Multi-Domain Controller can compute by its own an optimal 1019 end-to-end path based on the abstract TE topology information 1020 provided by the domain controllers. For example: 1022 o Multi-Domain Controller can compute, based on its own TED data, 1023 the optimal multi-domain path being A-B-C-E-G-H, and then request 1024 the TE Domain Controllers to set up the A-B-C and E-G-H intra- 1025 domain paths 1027 o But, during path set-up, the TE Domain Controller may find out 1028 that A-B-C intra-domain path is not feasible (as discussed in 1029 section 2.2, in optical networks it is typical to have some paths 1030 not being feasible due to optical constraints that are known only 1031 by the Optical Domain Controller), while only the path A-B-D is 1032 feasible 1034 o So what the Multi-Domain Controller has computed is not good and 1035 it needs to re-start the path computation from scratch 1037 As discussed in section 3.2.1, providing more extensive abstract 1038 information from the TE Domain Controllers to the Multi-Domain 1039 Controller may lead to scalability problems. 1041 In a sense this is similar to the problem of routing and wavelength 1042 assignment within an optical domain. It is possible to do first 1043 routing (step 1) and then wavelength assignment (step 2), but the 1044 chances of ending up with a good path is low. Alternatively, it is 1045 possible to do combined routing and wavelength assignment, which is 1046 known to be a more optimal and effective way for optical path set-up. 1047 Similarly, it is possible to first compute an abstract end-to-end 1048 path within the Multi-Domain Controller (step 1) and then compute an 1049 intra-domain path within each optical domain (step 2), but there are 1050 more chances not to find a path or to get a suboptimal path than 1051 performing multiple per-domain path computations and then stitch 1052 them. 1054 3.2.3. Complementary use of TE topology and path computation 1056 As discussed in section 2.2, there are some scalability issues with 1057 path computation requests in a multi-domain TE network with many TE 1058 domains, in terms of the number of requests to send to the TE Domain 1059 Controllers. It would therefore be worthwhile using the abstract TE 1060 topology information provided by the TE Domain Controllers to limit 1061 the number of requests. 1063 An example can be described considering the multi-domain abstract TE 1064 topology shown in Figure 9. In this example, an end-to-end TE path 1065 between domains A and F needs to be set up. The transit TE domain 1066 should be selected between domains B, C, D and E. 1068 .........B......... 1069 : _ _ _ _ _ _ _ _ : 1070 :/ \: 1071 +---O NOT FEASIBLE O---+ 1072 cost=5| : : | 1073 ......A...... | :.................: | ......F...... 1074 : : | | : : 1075 : O-----+ .........C......... +-----O : 1076 : : : /-------------\ : : : 1077 : : :/ \: : : 1078 : cost<=20 O---------O cost <= 30 O---------O cost<=20 : 1079 : /: cost=5 : : cost=5 :\ : 1080 : /------/ : :.................: : \------\ : 1081 : / : : \ : 1082 :/ cost<=25 : .........D......... : cost<=25 \: 1083 O-----------O-------+ : /-------------\ : +-------O-----------O 1084 :\ : cost=5| :/ \: |cost=5 : /: 1085 : \ : +-O cost <= 30 O-+ : / : 1086 : \------\ : : : : /------/ : 1087 : cost>=30 \: :.................: :/ cost>=30 : 1088 : O-----+ +-----O : 1089 :...........: | .........E......... | :...........: 1090 | : /-------------\ : | 1091 cost=5| :/ \: |cost=5 1092 +---O cost >= 30 O---+ 1093 : : 1094 :.................: 1096 Figure 9 - Multi-domain with many domains (Topology 1097 information) 1099 The actual cost of each intra-domain path is not known a priori from 1100 the abstract topology information. The Multi-Domain Controller only 1101 knows, from the TE topology provided by the underlying domain 1102 controllers, the feasibility of some intra-domain paths and some 1103 upper-bound and/or lower-bound cost information. With this 1104 information, together with the cost of inter-domain links, the Multi- 1105 Domain Controller can understand by its own that: 1107 o Domain B cannot be selected as the path connecting domains A and F 1108 is not feasible; 1110 o Domain E cannot be selected as a transit domain since it is known 1111 from the abstract topology information provided by domain 1112 controllers that the cost of the multi-domain path A-E-F (which is 1113 100, in the best case) will be always be higher than the cost of 1114 the multi-domain paths A-D-F (which is 90, in the worst case) and 1115 A-C-F (which is 80, in the worst case). 1117 Therefore, the Multi-Domain Controller can understand by its own that 1118 the optimal multi-domain path could be either A-D-F or A-C-F but it 1119 cannot know which one of the two possible option actually provides 1120 the optimal end-to-end path. 1122 The Multi-Domain Controller can therefore request path computation 1123 only to the TE Domain Controllers A, D, C and F (and not to all the 1124 possible TE Domain Controllers). 1126 .........B......... 1127 : : 1128 +---O O---+ 1129 ......A...... | :.................: | ......F...... 1130 : : | | : : 1131 : O-----+ .........C......... +-----O : 1132 : : : /-------------\ : : : 1133 : : :/ \: : : 1134 : cost=15 O---------O cost = 25 O---------O cost=10 : 1135 : /: cost=5 : : cost=5 :\ : 1136 : /------/ : :.................: : \------\ : 1137 : / : : \ : 1138 :/ cost=10 : .........D......... : cost=15 \: 1139 O-----------O-------+ : /-------------\ : +-------O-----------O 1140 : : cost=5| :/ \: |cost=5 : : 1141 : : +-O cost = 15 O-+ : : 1142 : : : : : : 1143 : : :.................: : : 1144 : O-----+ +-----O : 1145 :...........: | .........E......... | :...........: 1146 | : : | 1147 +---O O---+ 1148 :.................: 1150 Figure 10 - Multi-domain with many domains (Path Computation 1151 information) 1153 Based on these requests, the Multi-Domain Controller can know the 1154 actual cost of each intra-domain paths which belongs to potential 1155 optimal end-to-end paths, as shown in Figure 10, and then compute the 1156 optimal end-to-end path (e.g., A-D-F, having total cost of 50, 1157 instead of A-C-F having a total cost of 70). 1159 3.3. Path Computation RPC 1161 The TE tunnel YANG data model, defined in [TE-TUNNEL], can support 1162 the need to request path computation, as described in section 5.1.2 1163 of [TE-TUNNEL]. 1165 This solution is stateful since the state of each created "compute- 1166 only" TE tunnel path needs to be maintained, in the YANG datastores 1167 (at least in the running datastore and operational datastore), and 1168 updated, when underlying network conditions change. 1170 The RPC mechanism allows requesting path computation using a simple 1171 atomic operation, without creating any state in the YANG datastores, 1172 and it is the natural option/choice, especially with stateless PCE. 1174 It is very useful to provide both the options of using an RPC as well 1175 as of setting up TE tunnel paths in "compute-only" mode. It is 1176 suggested to use the RPC as much as possible and to rely on 1177 "compute-only" TE tunnel paths, when really needed. 1179 Using the RPC solution would imply that the underlying controller 1180 (e.g., a PNC) computes a path twice during the process to set up an 1181 LSP: at time T1, when its client (e.g., an MDSC) sends a path 1182 computation RPC request to it, and later, at time T2, when the same 1183 client (MDSC) creates a TE tunnel requesting the set-up of the LSP. 1184 The underlying assumption is that, if network conditions have not 1185 changed, the same path that has been computed at time T1 is also 1186 computed at time T2 by the underlying controller (e.g. PNC) and 1187 therefore the path that is set up at time T2 is exactly the same path 1188 that has been computed at time T1. 1190 However, since the operation is stateless, there is no guarantee that 1191 the returned path would still be available when path set-up is 1192 requested: this does not cause major issues when the time between 1193 path computation and path set-up is short (especially if compared 1194 with the time that would be needed to update the information of a 1195 very detailed connectivity matrix). 1197 In most of the cases, there is even no need to guarantee that the 1198 path that has been set up is the exactly same as the path that has 1199 been returned by path computation, especially if it has the same or 1200 even better metrics. Depending on the abstraction level applied by 1201 the server, the client may also not know the actual computed path. 1203 The most important requirement is that the required global objectives 1204 (e.g., multi-domain path metrics and constraints) are met. For this 1205 reason a path verification phase is always necessary to verify that 1206 the actual path that has been set up meets the global objectives (for 1207 example in a multi-domain network, the resulting end-to-end path 1208 meets the required end-to-end metrics and constraints). 1210 In most of the cases, even if the path being set up is not exactly 1211 the same as the path returned by path computation, its metrics and 1212 constraints are "good enough" and the path verification passes 1213 successfully. In the few corner cases where the path verification 1214 fails, it is possible repeat the whole process (path computation, 1215 path set-up and path verification). 1217 In case it is required to set up at T2 exactly the same path computed 1218 at T1, the RPC solution should not be used and, instead, a "compute- 1219 only" TE tunnel path should be set up, allowing also notifications in 1220 case the computed path has been changed. 1222 In this case, at time T1, the client (MDSC) creates a TE tunnel in a 1223 compute-only mode in the running datastore and later, at time T2, 1224 changes the configuration of that TE tunnel (not to be any more in a 1225 compute-only mode) to trigger the set-up of the LSP over the path 1226 which have been computed at time T1 and reported in the operational 1227 datastore. 1229 It is worth noting that also using the "compute-only" TE tunnel path, 1230 although increasing the likelihood that the computed path is 1231 available at path set-up, does not guarantee that because 1232 notifications may not be reliable or delivered on time. Path 1233 verification is needed also in this case. 1235 The solution based on "compute-only" TE tunnel path has also the 1236 following drawbacks: 1238 o Several messages required for any path computation 1240 o Requires persistent storage in the underlying controller 1241 o Need for garbage collection for stranded paths 1243 o Process burden to detect changes on the computed paths in order to 1244 provide notifications update 1246 3.3.1. Temporary reporting of the computed path state 1248 This section describes an optional extension to the stateless 1249 behavior of the path computation RPC, where the underlying 1250 controller, after having received a path computation RPC request, 1251 maintains some "transient state" associated with the computed path, 1252 allowing the client to request the set-up of exactly that path, if 1253 still available. 1255 This is similar to the "compute-only" TE tunnel path solution but, to 1256 avoid the drawbacks of the stateful approach, is leveraging the path 1257 computation RPC and the separation between configuration and 1258 operational datastore, as defined in the NMDA architecture [RFC8342]. 1260 The underlying controller, after having computed a path, as requested 1261 by a path computation RPC, also creates a TE tunnel instance within 1262 the operational datastore, to store that computed path. This would be 1263 similar to a "compute-only" TE tunnel path, with the only difference 1264 that there is no associated TE tunnel instance within the running 1265 datastore. 1267 Since the underlying controller stores in the operational datastore 1268 the computed path based on an abstract topology it exposes, it also 1269 remembers, internally, which is the actual native path (physical 1270 path), within its native topology (physical topology), associated 1271 with that compute-only TE tunnel instance. 1273 Afterwards, the client (e.g., MDSC) can request the set-up of that 1274 specific path by creating a TE tunnel instance (not in compute-only 1275 mode) in the running datastore using the same tunnel-name of 1276 the existing TE tunnel in the operational datastore: this will 1277 trigger the underlying controller to set up that path, if still 1278 available. 1280 There are still cases where the path being set up is not exactly the 1281 same as the path that has been computed: 1283 o When the tunnel is configured with path constraints which are not 1284 compatible with the computed path; 1286 o When the tunnel set-up is requested after the resources of the 1287 computed path are no longer available; 1289 o When the tunnel set-up is requested after the computed path is no 1290 longer known (e.g. due to a server reboot) by the underlying 1291 controller. 1293 In all these cases, the underlying controller should compute and set 1294 up a new path. 1296 Therefore the "path verification" phase, as described in section 3.3 1297 above, is always needed to check that the path that has been set up 1298 is still "good enough". 1300 Since this new approach is not completely stateless, garbage 1301 collection is implemented using a timeout that, when it expires, 1302 triggers the removal of the computed path from the operational 1303 datastore. This operation is fully controlled by the underlying 1304 controller without the need for any action to be taken by the client 1305 that is not able to act on the operational datastore. The default 1306 value of this timeout is 10 minutes but a different value may be 1307 configured by the client. 1309 In addition, it is possible for the client to tag each path 1310 computation request with a transaction-id allowing for a faster 1311 removal of all the paths associated with a transaction-id, without 1312 waiting for their timers to expire. 1314 The underlying controller can remove from the operational datastore 1315 all the paths computed with a given transaction-id which have not 1316 been set up either when it receives a Path Delete RPC request for 1317 that transaction-id or, automatically, right after the set-up up of a 1318 path that has been previously computed with that transaction-id. 1320 This possibility is useful when multiple paths are computed but, at 1321 most, only one is set up (e.g., in multi-domain path computation 1322 scenario scenarios). After the selected path has been set up (e.g, in 1323 one domain during multi-domain path set-up), all the other 1324 alternative computed paths can be automatically deleted by the 1325 underlying controller (since no longer needed). The client can also 1326 request, using the Path Delete RPC request, the underlying controller 1327 to remove all the computed paths, if none of them is going to be set 1328 up (e.g., in a transit domain not being selected by multi-domain path 1329 computation and so not being automatically deleted). 1331 This approach is complimentary and not alternative to the timer which 1332 is always needed to avoid stranded computed paths being stored in the 1333 operational datastore when no path is set up and no explicit Path 1334 Delete RPC request is received. 1336 4. Path computation and optimization for multiple paths 1338 There are use cases, where it is advantageous to request path 1339 computation for a set of paths, through a network or through a 1340 network domain, using a single request [RFC5440]. 1342 In this case, sending a single request for multiple path 1343 computations, instead of sending multiple requests for each path 1344 computation, would reduce the protocol overhead and it would consume 1345 less resources (e.g., threads in the client and server). 1347 In the context of a typical multi-domain TE network, there could 1348 multiple choices for the ingress/egress points of a domain and the 1349 Multi-Domain Controller needs to request path computation between all 1350 the ingress/egress pairs to select the best pair. For example, in the 1351 example of section 2.2, the Multi-Domain Controller needs to request 1352 the TE Network Controller 1 to compute the A-C and the A-D paths and 1353 to the TE Network Controller 2 to compute the E-H and the F-H paths. 1355 It is also possible that the Multi-Domain Controller receives a 1356 request to set up a group of multiple end to end connections. The 1357 Multi-Domain Controller needs to request each TE domain Controller to 1358 compute multiple paths, one (or more) for each end to end connection. 1360 There are also scenarios where it can be needed to request path 1361 computation for a set of paths in a synchronized fashion. 1363 One example could be computing multiple diverse paths. Computing a 1364 set of diverse paths in an unsynchronized fashion, leads to the 1365 possibility of not being able to satisfy the diversity requirement. 1366 In this case, it is preferable to compute a sub-optimal primary path 1367 for which a diversely routed secondary path exists. 1369 There are also scenarios where it is needed to request optimizing a 1370 set of paths using objective functions that apply to the whole set of 1371 paths, see [RFC5541], e.g. to minimize the sum of the costs of all 1372 the computed paths in the set. 1374 5. YANG data model for requesting Path Computation 1376 This document define a YANG RPC to request path computation as an 1377 "augmentation" of tunnel-rpc, defined in [TE-TUNNEL]. This model 1378 provides the RPC input attributes that are needed to request path 1379 computation and the RPC output attributes that are needed to report 1380 the computed paths. 1382 augment /te:tunnels-path-compute/te:input/te:path-compute-info: 1383 +-- path-request* [request-id] 1384 | +-- request-id uint32 1385 | ........... 1387 augment /te:tunnels-path-compute/te:output/te:path-compute-result: 1388 +--ro response* [response-id] 1389 +--ro response-id uint32 1390 +--ro computed-paths-properties 1391 | +--ro computed-path-properties* [k-index] 1392 | +--ro k-index uint8 1393 | +--ro path-properties 1394 | ........... 1396 This model extensively re-uses the grouping defined in [TE-TUNNEL] 1397 and [RFC8776] to ensure maximal syntax and semantics commonality. 1399 This YANG data model allows one RPC to include multiple path 1400 requests, each path request being identified by a request-id. 1401 Therefore, one RPC can return multiple responses, one for each path 1402 request, being identified by a response-id equal to the corresponding 1403 request-id. Each response reports one or more computed paths, as 1404 requested by the k-requested-paths attribute. By default, each 1405 response reports one computed path. 1407 5.1. Synchronization of multiple path computation requests 1409 The YANG data model permits the synchronization of a set of multiple 1410 path requests (identified by specific request-id) all related to a 1411 "svec" container emulating the syntax of the Synchronization VECtor 1412 (SVEC) PCEP object, defined in [RFC5440]. 1414 +-- synchronization* [] 1415 +-- svec 1416 | +-- relaxable? boolean 1417 | +-- disjointness? te-path-disjointness 1418 | +-- request-id-number* uint32 1419 +-- svec-constraints 1420 | +-- path-metric-bound* [metric-type] 1421 | +-- metric-type identityref 1422 | +-- upper-bound? uint64 1423 +-- path-srlgs-lists 1424 | +-- path-srlgs-list* [usage] 1425 | +-- usage identityref 1426 | +-- values* srlg 1427 +-- path-srlgs-names 1428 | +-- path-srlgs-name* [usage] 1429 | +-- usage identityref 1430 | +-- names* string 1431 +-- exclude-objects 1432 | +-- excludes* [] 1433 | +-- (type)? 1434 | +--:(numbered-node-hop) 1435 | | +-- numbered-node-hop 1436 | | +-- node-id te-node-id 1437 | | +-- hop-type? te-hop-type 1438 | +--:(numbered-link-hop) 1439 | | +-- numbered-link-hop 1440 | | +-- link-tp-id te-tp-id 1441 | | +-- hop-type? te-hop-type 1442 | | +-- direction? te-link-direction 1443 | +--:(unnumbered-link-hop) 1444 | | +-- unnumbered-link-hop 1445 | | +-- link-tp-id te-tp-id 1446 | | +-- node-id te-node-id 1447 | | +-- hop-type? te-hop-type 1448 | | +-- direction? te-link-direction 1449 | +--:(as-number) 1450 | | +-- as-number-hop 1451 | | +-- as-number inet:as-number 1452 | | +-- hop-type? te-hop-type 1453 | +--:(label) 1454 | +-- label-hop 1455 | +-- te-label 1456 | +-- (technology)? 1457 | | +--:(generic) 1458 | | +-- generic? 1459 | | rt-types:generalized-label 1460 | +-- direction? te-label-direction 1461 +-- optimizations 1462 +-- (algorithm)? 1463 +--:(metric) {te-types:path-optimization-metric}? 1464 | +-- optimization-metric* [metric-type] 1465 | +-- metric-type identityref 1466 | +-- weight? uint8 1467 +--:(objective-function) 1468 {te-types:path-optimization-objective- 1469 function}? 1470 +-- objective-function 1471 +-- objective-function-type? identityref 1473 The model, in addition to the metric types, defined in [RFC8776], 1474 which can be applied to each individual path request, supports also 1475 additional metric types, which apply to a set of synchronized 1476 requests, as referenced in [RFC5541]. These additional metric types 1477 are defined by the following YANG identities: 1479 o svec-metric-type: base YANG identity from which cumulative metric 1480 types identities are derived. 1482 o svec-metric-cumul-te: cumulative TE cost metric type, as defined 1483 in [RFC5541]. 1485 o svec-metric-cumul-igp: cumulative IGP cost metric type, as defined 1486 in [RFC5541]. 1488 o svec-metric-cumul-hop: cumulative Hop metric type, representing 1489 the cumulative version of the Hop metric type defined in 1490 [RFC8776]. 1492 o svec-metric-aggregate-bandwidth-consumption: aggregate bandwidth 1493 consumption metric type, as defined in [RFC5541]. 1495 o svec-metric-load-of-the-most-loaded-link: load of the most loaded 1496 link metric type, as defined in [RFC5541]. 1498 5.2. Returned metric values 1500 This YANG data model provides a way to return the values of the 1501 metrics computed by the path computation in the output of RPC, 1502 together with other important information (e.g. srlg, affinities, 1503 explicit route), emulating the syntax of the "C" flag of the "METRIC" 1504 PCEP object [RFC5440]: 1506 | +--ro path-properties 1507 | +--ro path-metric* [metric-type] 1508 | | +--ro metric-type identityref 1509 | | +--ro accumulative-value? uint64 1510 | +--ro path-affinities-values 1511 | | +--ro path-affinities-value* [usage] 1512 | | +--ro usage identityref 1513 | | +--ro value? admin-groups 1514 | +--ro path-affinity-names 1515 | | +--ro path-affinity-name* [usage] 1516 | | +--ro usage identityref 1517 | | +--ro affinity-name* [name] 1518 | | +--ro name string 1519 | +--ro path-srlgs-lists 1520 | | +--ro path-srlgs-list* [usage] 1521 | | +--ro usage identityref 1522 | | +--ro values* srlg 1523 | +--ro path-srlgs-names 1524 | | +--ro path-srlgs-name* [usage] 1525 | | +--ro usage identityref 1526 | | +--ro names* string 1527 | +--ro path-route-objects 1528 | ........... 1530 It also allows the client to request which information (metrics, srlg 1531 and/or affinities) should be returned: 1533 | +-- request-id uint32 1534 | ........... 1535 | +-- requested-metrics* [metric-type] 1536 | | +-- metric-type identityref 1537 | +-- return-srlgs? boolean 1538 | +-- return-affinities? boolean 1539 | ........... 1541 This feature is essential for path computation in a multi-domain TE 1542 network as described in section 2.2. In this case, the metrics 1543 returned by a path computation requested to a given underlying 1544 controller must be used by the client to compute the best end-to-end 1545 path. If they are missing, the client cannot compare different paths 1546 calculated by the underlying controllers and choose the best one for 1547 the optimal end-to-end (e2e) path. 1549 5.3. Multiple Paths Requests for the same TE tunnel 1551 The YANG data model allows including multiple requests for different 1552 paths intended to be used within the same tunnel or within different 1553 tunnels. 1555 When multiple requested paths are intended to be used within the same 1556 tunnel (e.g., requesting path computation for the primary and 1557 secondary paths of a protected tunnel), the set of attributes that 1558 are intended to be configured on per-tunnel basis rather than on per- 1559 path basis are common to all these path requests. These attributes 1560 includes both attributes which can be configured only a per-tunnel 1561 basis (e.g., tunnel-name, source/destination TTP, encoding and 1562 switching-type) as well attributes which can be configured both on a 1563 per-tunnel and on a per-path basis (e.g., the te-bandwidth or the 1564 associations). 1566 Therefore, a tunnel-attributes list is defined, within the path 1567 computation request RPC: 1569 +-- tunnel-attributes* [tunnel-name] 1570 | +-- tunnel-name string 1571 | +-- encoding? identityref 1572 | +-- switching-type? identityref 1573 | ........... 1575 The path requests that are intended to be used within the same tunnel 1576 should reference the same entry in the tunnel-attributes list. This 1577 allows: 1579 o avoiding repeating the same set of per-tunnel parameters on 1580 multiple requested paths; 1582 o the server to understand what attributes are intended to be 1583 configured on a per-tunnel basis (e.g., the te-bandwidth 1584 configured in the tunnel-attributes) and what attributes are 1585 intended to be configured on a per-path basis(e.g., the te- 1586 bandwidth configured in the path-request). This could be useful 1587 especially when the server also creates a TE tunnel instance 1588 within the operational datastore to report the computed paths, as 1589 described in section 3.3.1: in this case, the tunnel-name is also 1590 used as the suggested name for that TE tunnel instance. 1592 The YANG data model allows also including requests for paths intended 1593 to modify existing tunnels (e.g., adding a protection path for an 1594 existing un-protected tunnel). In this case, the per-tunnel 1595 attributes are already provided in an existing TE tunnel instance and 1596 do not need to be re-configured in the path computation request RPC. 1597 Therefore, these requests should reference an existing TE tunnel 1598 instance. 1600 It is also possible to request computing paths without indicating in 1601 which tunnel they are intended to be used (e.g., in case of an 1602 unprotected tunnel). In this case, the per-tunnel attributes could be 1603 provided together with the per-path attributes in the path request, 1604 without using the tunnel-attributes list. 1606 The choices below are defined to distinguish the cases above: 1608 o whether the per-tunnel attributes are configured by reference 1609 (providing a leafref), to: 1611 o either a TE tunnel instance, if it exists; 1613 o or to an entry of the tunnel-attributes list, if the TE tunnel 1614 instance does not exist; 1616 o or by value, providing the set of tunnel attributes within the 1617 path request: 1619 | +-- (tunnel-attributes)? 1620 | | +--:(reference) 1621 | | | +-- tunnel-reference 1622 | | | +-- (tunnel-exist)? 1623 | | | | +--:(tunnel-ref) 1624 | | | | | +-- tunnel-ref te:tunnel-ref 1625 | | | | +--:(tunnel-attributes-ref) 1626 | | | | +-- tunnel-attributes-ref leafref 1627 | | ........... 1628 | | +--:(value) 1629 | | +-- tunnel-name? string 1630 | | ........... 1631 | | +-- encoding? identityref 1632 | | +-- switching-type? identityref 1633 | | ........... 1635 5.3.1. Tunnel attributes specified by value 1637 The (value) case provides the set of attributes that are configured 1638 only on per-tunnel basis (e.g., tunnel-name, source/destination TTP, 1639 encoding and switching-type). 1641 In this case, it is assumed that the requested path will be the only 1642 path within a tunnel. 1644 If the requested path is a transit segment of a multi-domain end-to- 1645 end path, it can be of any type (primary, secondary, reverse-primary 1646 or reverse-secondary), as specified by the (path-role) choice: 1648 | | +-- (path-role)? 1649 | | | +--:(primary-path) 1650 | | | +--:(secondary-path) 1651 | | | | +-- secondary-path! 1652 | | | | +-- primary-path-name? string 1653 | | | +--:(primary-reverse-path) 1654 | | | | +-- primary-reverse-path! 1655 | | | | +-- primary-path-name? string 1656 | | | +--:(secondary-reverse-path) 1657 | | | +-- secondary-reverse-path! 1658 | | | +-- primary-path-name? string 1659 | | | +-- primary-reverse-path-name? string 1661 In all the other cases, the requested path can only be a primary 1662 path. 1664 The secondary-path, the primary-reverse-path and the secondary- 1665 reverse-path are presence container used to indicate the role of the 1666 path: by default, the path is assumed to be a primary path. 1668 They optionally can contain the name of the primary-path under which 1669 the requested path could be associated within the YANG tree structure 1670 defined in [TE-TUNNEL], which could be useful when the server also 1671 creates a TE tunnel instance within the operational datastore to 1672 report the computed paths, as described in section 3.3.1: in this 1673 case, the tunnel-name and the path names are also used as the 1674 suggested name for that TE tunnel and path instances. 1676 5.3.2. Tunnel attributes specified by reference 1678 The (reference) case provides the information needed to associate 1679 multiple path requests that are intended to be used within the same 1680 tunnel. 1682 In order to indicate the role of the path being requested within the 1683 intended tunnel (e.g., primary or secondary path), the (path-role) 1684 choice is defined: 1686 | | | +-- (path-role) 1687 | | | +--:(primary-path) 1688 | | | | +-- primary-path! 1689 | | | | ........... 1690 | | | +--:(secondary-path) 1691 | | | | +-- secondary-path 1692 | | | | ........... 1693 | | | +--:(primary-reverse-path) 1694 | | | | +-- primary-reverse-path 1695 | | | | ........... 1696 | | | +--:(secondary-reverse-path) 1697 | | | +-- secondary-reverse-path 1698 | | | ........... 1700 The primary-path is a presence container used to indicate that the 1701 requested path is intended to be used as a primary path. It can also 1702 contain some attributes which are configured only on primary paths 1703 (e.g., the k-requested-paths). 1705 The secondary-path container indicates that the requested path is 1706 intended to be used as a secondary path and it contains at least 1707 references to one or more primary paths which can use it as a 1708 candidate secondary path: 1710 | | | | +-- secondary-path 1711 | | | | ........... 1712 | | | | +-- primary-path-ref* [] 1713 | | | | +-- (primary-path-exist)? 1714 | | | | +--:(path-ref) 1715 | | | | | +-- primary-path-ref leafref 1716 | | | | +--:(path-request-ref) 1717 | | | | +-- path-request-ref leafref 1719 A requested secondary path can reference any requested primary paths, 1720 and, in case they are intended to be used within an existing TE 1721 tunnel, it could also reference any existing primary-paths. 1723 The secondary-path container can also contain some attributes which 1724 are configured only on secondary paths (e.g., the protection-type). 1726 The primary-reverse-path container indicates that the requested path 1727 is intended to be used as a primary reverse path and it contains only 1728 the reference to the primary path which is intended to use it as a 1729 reverse path: 1731 | | | | +-- primary-reverse-path 1732 | | | | +-- (primary-path-exist)? 1733 | | | | +--:(path-ref) 1734 | | | | | +-- primary-path-ref leafref 1735 | | | | +--:(path-request-ref) 1736 | | | | +-- path-request-ref leafref 1738 A requested primary reverse path can reference either a requested 1739 primary path, or, in case it is intended to be used within an 1740 existing TE tunnel, an existing primary-path. 1742 The secondary-reverse-path container indicates that the requested 1743 path is intended to be used as a secondary reverse path and it 1744 contains at least references to one or more primary paths, whose 1745 primary reverse path can use it as a candidate secondary reverse 1746 path: 1748 | | | +-- secondary-reverse-path 1749 | | | ........... 1750 | | | +-- primary-reverse-path-ref* [] 1751 | | | +-- (primary-reverse-path-exist)? 1752 | | | +--:(path-ref) 1753 | | | | +-- primary-path-ref leafref 1754 | | | +--:(path-request-ref) 1755 | | | +-- path-request-ref leafref 1757 A requested secondary reverse path can reference any requested 1758 primary paths, and, in case they are intended to be used within an 1759 existing TE tunnel, it could reference also existing primary-paths. 1761 The secondary-reverse-path container can also contain some attributes 1762 which are configured only on secondary reverse paths (e.g., the 1763 protection-type). 1765 In case the requested path is a transit segment of a multi-domain 1766 end-to-end path, the primary-path may not be needed to be 1767 setup/computed. However, the request for path computation of a 1768 secondary-path or a primary-reverse or of a secondary-reverse-path 1769 requires that the primary-path exists or it is requested within the 1770 same RPC request. In the latter case, the path request for the 1771 primary-path should have an empty ERO to indicate to the server that 1772 path computation is not requested and no path properties will 1773 therefore be returned in the RPC response. 1775 5.4. Multi-Layer Path Computation 1777 The models supports requesting multi-layer path computation following 1778 the same approach based on dependency tunnels, as defined in [TE- 1779 TUNNEL]. 1781 The tunnel-attributes of a given client-layer path request can 1782 reference server-layer TE tunnels which can already exist in the YANG 1783 datastore or be specified in the tunnel-attributes list, within the 1784 same RPC request: 1786 | +-- dependency-tunnels 1787 | | +-- dependency-tunnel* [name] 1788 | | | +-- name -> /te:te/tunnels/tunnel/name 1789 | | | +-- encoding? identityref 1790 | | | +-- switching-type? identityref 1791 | | +-- dependency-tunnel-attributes* [name] 1792 | | +-- name leafref 1793 | | +-- encoding? identityref 1794 | | +-- switching-type? identityref 1796 In a similar way as in [TE-TUNNEL], the server-layer tunnel 1797 attributes should provide the information of what would be the 1798 dynamic link in the client layer topology supported by that tunnel, 1799 if instantiated: 1801 | +-- hierarchical-link 1802 | +-- local-te-node-id? te-types:te-node-id 1803 | +-- local-te-link-tp-id? te-types:te-tp-id 1804 | +-- remote-te-node-id? te-types:te-node-id 1805 | +-- te-topology-identifier 1806 | +-- provider-id? te-global-id 1807 | +-- client-id? te-global-id 1808 | +-- topology-id? te-topology-id 1810 It is worth noting that since path computation RPC is stateless, the 1811 dynamic hierarchical links configured for the server-layer tunnel 1812 attributes cannot be used for path computation of any client-layer 1813 path unless explicitly referenced in the dependency-tunnel-attributes 1814 list within the same RPC request. 1816 6. YANG data model for TE path computation 1818 6.1. Tree diagram 1820 Figure 11 below shows the tree diagram of the YANG data model defined 1821 in module ietf-te-path-computation.yang. 1823 module: ietf-te-path-computation 1825 augment /te:tunnels-path-compute/te:input/te:path-compute-info: 1826 +-- path-request* [request-id] 1827 | +-- request-id uint32 1828 | +-- (tunnel-attributes)? 1829 | | +--:(reference) 1830 | | | +-- tunnel-reference 1831 | | | +-- (tunnel-exist)? 1832 | | | | +--:(tunnel-ref) 1833 | | | | | +-- tunnel-ref te:tunnel-ref 1834 | | | | +--:(tunnel-attributes-ref) 1835 | | | | +-- tunnel-attributes-ref leafref 1836 | | | +-- path-name? string 1837 | | | +-- (path-role) 1838 | | | +--:(primary-path) 1839 | | | | +-- primary-path! 1840 | | | | +-- preference? uint8 1841 | | | | +-- k-requested-paths? uint8 1842 | | | +--:(secondary-path) 1843 | | | | +-- secondary-path 1844 | | | | +-- preference? uint8 1845 | | | | +-- protection-type? identityref 1846 | | | | +-- restoration-type? identityref 1847 | | | | +-- restoration-scheme? identityref 1848 | | | | +-- primary-path-ref* [] 1849 | | | | +-- (primary-path-exist)? 1850 | | | | +--:(path-ref) 1851 | | | | | +-- primary-path-ref leafref 1852 | | | | +--:(path-request-ref) 1853 | | | | +-- path-request-ref leafref 1854 | | | +--:(primary-reverse-path) 1855 | | | | +-- primary-reverse-path 1856 | | | | +-- (primary-path-exist)? 1857 | | | | +--:(path-ref) 1858 | | | | | +-- primary-path-ref leafref 1859 | | | | +--:(path-request-ref) 1860 | | | | +-- path-request-ref leafref 1861 | | | +--:(secondary-reverse-path) 1862 | | | +-- secondary-reverse-path 1863 | | | +-- preference? uint8 1864 | | | +-- protection-type? identityref 1865 | | | +-- restoration-type? identityref 1866 | | | +-- restoration-scheme? identityref 1867 | | | +-- primary-reverse-path-ref* [] 1868 | | | +-- (primary-reverse-path-exist)? 1869 | | | +--:(path-ref) 1870 | | | | +-- primary-path-ref leafref 1871 | | | +--:(path-request-ref) 1872 | | | +-- path-request-ref leafref 1873 | | +--:(value) 1874 | | +-- tunnel-name? string 1875 | | +-- path-name? string 1876 | | +-- (path-role)? 1877 | | | +--:(primary-path) 1878 | | | +--:(secondary-path) 1879 | | | | +-- secondary-path! 1880 | | | | +-- primary-path-name? string 1881 | | | +--:(primary-reverse-path) 1882 | | | | +-- primary-reverse-path! 1883 | | | | +-- primary-path-name? string 1884 | | | +--:(secondary-reverse-path) 1885 | | | +-- secondary-reverse-path! 1886 | | | +-- primary-path-name? string 1887 | | | +-- primary-reverse-path-name? string 1888 | | +-- k-requested-paths? uint8 1889 | | +-- encoding? identityref 1890 | | +-- switching-type? identityref 1891 | | +-- source? te-types:te-node-id 1892 | | +-- destination? te-types:te-node-id 1893 | | +-- src-tunnel-tp-id? binary 1894 | | +-- dst-tunnel-tp-id? binary 1895 | | +-- bidirectional? boolean 1896 | | +-- te-topology-identifier 1897 | | +-- provider-id? te-global-id 1898 | | +-- client-id? te-global-id 1899 | | +-- topology-id? te-topology-id 1900 | +-- association-objects 1901 | | +-- association-object* [association-key] 1902 | | | +-- association-key string 1903 | | | +-- type? identityref 1904 | | | +-- id? uint16 1905 | | | +-- source 1906 | | | +-- id? te-gen-node-id 1907 | | | +-- type? enumeration 1908 | | +-- association-object-extended* [association-key] 1909 | | +-- association-key string 1910 | | +-- type? identityref 1911 | | +-- id? uint16 1912 | | +-- source 1913 | | | +-- id? te-gen-node-id 1914 | | | +-- type? enumeration 1915 | | +-- global-source? uint32 1916 | | +-- extended-id? yang:hex-string 1917 | +-- optimizations 1918 | | +-- (algorithm)? 1919 | | +--:(metric) {path-optimization-metric}? 1920 | | | +-- optimization-metric* [metric-type] 1921 | | | | +-- metric-type identityref 1922 | | | | +-- weight? uint8 1923 | | | | +-- explicit-route-exclude-objects 1924 | | | | | +-- route-object-exclude-object* [index] 1925 | | | | | +-- index uint32 1926 | | | | | +-- (type)? 1927 | | | | | +--:(numbered-node-hop) 1928 | | | | | | +-- numbered-node-hop 1929 | | | | | | +-- node-id te-node-id 1930 | | | | | | +-- hop-type? te-hop-type 1931 | | | | | +--:(numbered-link-hop) 1932 | | | | | | +-- numbered-link-hop 1933 | | | | | | +-- link-tp-id te-tp-id 1934 | | | | | | +-- hop-type? te-hop-type 1935 | | | | | | +-- direction? te-link-direction 1936 | | | | | +--:(unnumbered-link-hop) 1937 | | | | | | +-- unnumbered-link-hop 1938 | | | | | | +-- link-tp-id te-tp-id 1939 | | | | | | +-- node-id te-node-id 1940 | | | | | | +-- hop-type? te-hop-type 1941 | | | | | | +-- direction? te-link-direction 1942 | | | | | +--:(as-number) 1943 | | | | | | +-- as-number-hop 1944 | | | | | | +-- as-number inet:as-number 1945 | | | | | | +-- hop-type? te-hop-type 1946 | | | | | +--:(label) 1947 | | | | | | +-- label-hop 1948 | | | | | | +-- te-label 1949 | | | | | | +-- (technology)? 1950 | | | | | | | +--:(generic) 1951 | | | | | | | +-- generic? 1952 | | | | | | | rt- 1953 types:generalized-label 1954 | | | | | | +-- direction? 1955 | | | | | | te-label-direction 1956 | | | | | +--:(srlg) 1957 | | | | | +-- srlg 1958 | | | | | +-- srlg? uint32 1959 | | | | +-- explicit-route-include-objects 1960 | | | | +-- route-object-include-object* [index] 1961 | | | | +-- index uint32 1962 | | | | +-- (type)? 1963 | | | | +--:(numbered-node-hop) 1964 | | | | | +-- numbered-node-hop 1965 | | | | | +-- node-id te-node-id 1966 | | | | | +-- hop-type? te-hop-type 1967 | | | | +--:(numbered-link-hop) 1968 | | | | | +-- numbered-link-hop 1969 | | | | | +-- link-tp-id te-tp-id 1970 | | | | | +-- hop-type? te-hop-type 1971 | | | | | +-- direction? te-link-direction 1972 | | | | +--:(unnumbered-link-hop) 1973 | | | | | +-- unnumbered-link-hop 1974 | | | | | +-- link-tp-id te-tp-id 1975 | | | | | +-- node-id te-node-id 1976 | | | | | +-- hop-type? te-hop-type 1977 | | | | | +-- direction? te-link-direction 1978 | | | | +--:(as-number) 1979 | | | | | +-- as-number-hop 1980 | | | | | +-- as-number inet:as-number 1981 | | | | | +-- hop-type? te-hop-type 1982 | | | | +--:(label) 1983 | | | | +-- label-hop 1984 | | | | +-- te-label 1985 | | | | +-- (technology)? 1986 | | | | | +--:(generic) 1987 | | | | | +-- generic? 1988 | | | | | rt- 1989 types:generalized-label 1990 | | | | +-- direction? 1991 | | | | te-label-direction 1992 | | | +-- tiebreakers 1993 | | | +-- tiebreaker* [tiebreaker-type] 1994 | | | +-- tiebreaker-type identityref 1995 | | +--:(objective-function) 1996 | | {path-optimization-objective-function}? 1997 | | +-- objective-function 1998 | | +-- objective-function-type? identityref 1999 | +-- named-path-constraint? leafref 2000 | | {te-types:named-path-constraints}? 2001 | +-- te-bandwidth 2002 | | +-- (technology)? 2003 | | +--:(generic) 2004 | | +-- generic? te-bandwidth 2005 | +-- link-protection? identityref 2006 | +-- setup-priority? uint8 2007 | +-- hold-priority? uint8 2008 | +-- signaling-type? identityref 2009 | +-- path-metric-bounds 2010 | | +-- path-metric-bound* [metric-type] 2011 | | +-- metric-type identityref 2012 | | +-- upper-bound? uint64 2013 | +-- path-affinities-values 2014 | | +-- path-affinities-value* [usage] 2015 | | +-- usage identityref 2016 | | +-- value? admin-groups 2017 | +-- path-affinity-names 2018 | | +-- path-affinity-name* [usage] 2019 | | +-- usage identityref 2020 | | +-- affinity-name* [name] 2021 | | +-- name string 2022 | +-- path-srlgs-lists 2023 | | +-- path-srlgs-list* [usage] 2024 | | +-- usage identityref 2025 | | +-- values* srlg 2026 | +-- path-srlgs-names 2027 | | +-- path-srlgs-name* [usage] 2028 | | +-- usage identityref 2029 | | +-- names* string 2030 | +-- disjointness? te-path-disjointness 2031 | +-- explicit-route-objects-always 2032 | | +-- route-object-exclude-always* [index] 2033 | | | +-- index uint32 2034 | | | +-- (type)? 2035 | | | +--:(numbered-node-hop) 2036 | | | | +-- numbered-node-hop 2037 | | | | +-- node-id te-node-id 2038 | | | | +-- hop-type? te-hop-type 2039 | | | +--:(numbered-link-hop) 2040 | | | | +-- numbered-link-hop 2041 | | | | +-- link-tp-id te-tp-id 2042 | | | | +-- hop-type? te-hop-type 2043 | | | | +-- direction? te-link-direction 2044 | | | +--:(unnumbered-link-hop) 2045 | | | | +-- unnumbered-link-hop 2046 | | | | +-- link-tp-id te-tp-id 2047 | | | | +-- node-id te-node-id 2048 | | | | +-- hop-type? te-hop-type 2049 | | | | +-- direction? te-link-direction 2050 | | | +--:(as-number) 2051 | | | | +-- as-number-hop 2052 | | | | +-- as-number inet:as-number 2053 | | | | +-- hop-type? te-hop-type 2054 | | | +--:(label) 2055 | | | +-- label-hop 2056 | | | +-- te-label 2057 | | | +-- (technology)? 2058 | | | | +--:(generic) 2059 | | | | +-- generic? 2060 | | | | rt-types:generalized-label 2061 | | | +-- direction? te-label-direction 2062 | | +-- route-object-include-exclude* [index] 2063 | | +-- explicit-route-usage? identityref 2064 | | +-- index uint32 2065 | | +-- (type)? 2066 | | +--:(numbered-node-hop) 2067 | | | +-- numbered-node-hop 2068 | | | +-- node-id te-node-id 2069 | | | +-- hop-type? te-hop-type 2070 | | +--:(numbered-link-hop) 2071 | | | +-- numbered-link-hop 2072 | | | +-- link-tp-id te-tp-id 2073 | | | +-- hop-type? te-hop-type 2074 | | | +-- direction? te-link-direction 2075 | | +--:(unnumbered-link-hop) 2076 | | | +-- unnumbered-link-hop 2077 | | | +-- link-tp-id te-tp-id 2078 | | | +-- node-id te-node-id 2079 | | | +-- hop-type? te-hop-type 2080 | | | +-- direction? te-link-direction 2081 | | +--:(as-number) 2082 | | | +-- as-number-hop 2083 | | | +-- as-number inet:as-number 2084 | | | +-- hop-type? te-hop-type 2085 | | +--:(label) 2086 | | | +-- label-hop 2087 | | | +-- te-label 2088 | | | +-- (technology)? 2089 | | | | +--:(generic) 2090 | | | | +-- generic? 2091 | | | | rt-types:generalized-label 2092 | | | +-- direction? te-label-direction 2093 | | +--:(srlg) 2094 | | +-- srlg 2095 | | +-- srlg? uint32 2096 | +-- path-in-segment! 2097 | | +-- label-restrictions 2098 | | +-- label-restriction* [index] 2099 | | +-- restriction? enumeration 2100 | | +-- index uint32 2101 | | +-- label-start 2102 | | | +-- te-label 2103 | | | +-- (technology)? 2104 | | | | +--:(generic) 2105 | | | | +-- generic? rt-types:generalized-label 2106 | | | +-- direction? te-label-direction 2107 | | +-- label-end 2108 | | | +-- te-label 2109 | | | +-- (technology)? 2110 | | | | +--:(generic) 2111 | | | | +-- generic? rt-types:generalized-label 2112 | | | +-- direction? te-label-direction 2113 | | +-- label-step 2114 | | | +-- (technology)? 2115 | | | +--:(generic) 2116 | | | +-- generic? int32 2117 | | +-- range-bitmap? yang:hex-string 2118 | +-- path-out-segment! 2119 | | +-- label-restrictions 2120 | | +-- label-restriction* [index] 2121 | | +-- restriction? enumeration 2122 | | +-- index uint32 2123 | | +-- label-start 2124 | | | +-- te-label 2125 | | | +-- (technology)? 2126 | | | | +--:(generic) 2127 | | | | +-- generic? rt-types:generalized-label 2128 | | | +-- direction? te-label-direction 2129 | | +-- label-end 2130 | | | +-- te-label 2131 | | | +-- (technology)? 2132 | | | | +--:(generic) 2133 | | | | +-- generic? rt-types:generalized-label 2134 | | | +-- direction? te-label-direction 2135 | | +-- label-step 2136 | | | +-- (technology)? 2137 | | | +--:(generic) 2138 | | | +-- generic? int32 2139 | | +-- range-bitmap? yang:hex-string 2140 | +-- requested-metrics* [metric-type] 2141 | | +-- metric-type identityref 2142 | +-- return-srlgs? boolean 2143 | +-- return-affinities? boolean 2144 | +-- requested-state! 2145 | +-- timer? uint16 2146 | +-- transaction-id? string 2147 +-- tunnel-attributes* [tunnel-name] 2148 | +-- tunnel-name string 2149 | +-- encoding? identityref 2150 | +-- switching-type? identityref 2151 | +-- source? te-types:te-node-id 2152 | +-- destination? te-types:te-node-id 2153 | +-- src-tunnel-tp-id? binary 2154 | +-- dst-tunnel-tp-id? binary 2155 | +-- bidirectional? boolean 2156 | +-- association-objects 2157 | | +-- association-object* [association-key] 2158 | | | +-- association-key string 2159 | | | +-- type? identityref 2160 | | | +-- id? uint16 2161 | | | +-- source 2162 | | | +-- id? te-gen-node-id 2163 | | | +-- type? enumeration 2164 | | +-- association-object-extended* [association-key] 2165 | | +-- association-key string 2166 | | +-- type? identityref 2167 | | +-- id? uint16 2168 | | +-- source 2169 | | | +-- id? te-gen-node-id 2170 | | | +-- type? enumeration 2171 | | +-- global-source? uint32 2172 | | +-- extended-id? yang:hex-string 2173 | +-- protection-type? identityref 2174 | +-- restoration-type? identityref 2175 | +-- restoration-scheme? identityref 2176 | +-- te-topology-identifier 2177 | | +-- provider-id? te-global-id 2178 | | +-- client-id? te-global-id 2179 | | +-- topology-id? te-topology-id 2180 | +-- te-bandwidth 2181 | | +-- (technology)? 2182 | | +--:(generic) 2183 | | +-- generic? te-bandwidth 2184 | +-- link-protection? identityref 2185 | +-- setup-priority? uint8 2186 | +-- hold-priority? uint8 2187 | +-- signaling-type? identityref 2188 | +-- hierarchy 2189 | +-- dependency-tunnels 2190 | | +-- dependency-tunnel* [name] 2191 | | | +-- name -> /te:te/tunnels/tunnel/name 2192 | | | +-- encoding? identityref 2193 | | | +-- switching-type? identityref 2194 | | +-- dependency-tunnel-attributes* [name] 2195 | | +-- name leafref 2196 | | +-- encoding? identityref 2197 | | +-- switching-type? identityref 2198 | +-- hierarchical-link 2199 | +-- local-te-node-id? te-types:te-node-id 2200 | +-- local-te-link-tp-id? te-types:te-tp-id 2201 | +-- remote-te-node-id? te-types:te-node-id 2202 | +-- te-topology-identifier 2203 | +-- provider-id? te-global-id 2204 | +-- client-id? te-global-id 2205 | +-- topology-id? te-topology-id 2206 +-- synchronization* [] 2207 +-- svec 2208 | +-- relaxable? boolean 2209 | +-- disjointness? te-path-disjointness 2210 | +-- request-id-number* uint32 2211 +-- svec-constraints 2212 | +-- path-metric-bound* [metric-type] 2213 | +-- metric-type identityref 2214 | +-- upper-bound? uint64 2215 +-- path-srlgs-lists 2216 | +-- path-srlgs-list* [usage] 2217 | +-- usage identityref 2218 | +-- values* srlg 2219 +-- path-srlgs-names 2220 | +-- path-srlgs-name* [usage] 2221 | +-- usage identityref 2222 | +-- names* string 2223 +-- exclude-objects 2224 | +-- excludes* [] 2225 | +-- (type)? 2226 | +--:(numbered-node-hop) 2227 | | +-- numbered-node-hop 2228 | | +-- node-id te-node-id 2229 | | +-- hop-type? te-hop-type 2230 | +--:(numbered-link-hop) 2231 | | +-- numbered-link-hop 2232 | | +-- link-tp-id te-tp-id 2233 | | +-- hop-type? te-hop-type 2234 | | +-- direction? te-link-direction 2235 | +--:(unnumbered-link-hop) 2236 | | +-- unnumbered-link-hop 2237 | | +-- link-tp-id te-tp-id 2238 | | +-- node-id te-node-id 2239 | | +-- hop-type? te-hop-type 2240 | | +-- direction? te-link-direction 2241 | +--:(as-number) 2242 | | +-- as-number-hop 2243 | | +-- as-number inet:as-number 2244 | | +-- hop-type? te-hop-type 2245 | +--:(label) 2246 | +-- label-hop 2247 | +-- te-label 2248 | +-- (technology)? 2249 | | +--:(generic) 2250 | | +-- generic? 2251 | | rt-types:generalized-label 2252 | +-- direction? te-label-direction 2253 +-- optimizations 2254 +-- (algorithm)? 2255 +--:(metric) {te-types:path-optimization-metric}? 2256 | +-- optimization-metric* [metric-type] 2257 | +-- metric-type identityref 2258 | +-- weight? uint8 2259 +--:(objective-function) 2260 {te-types:path-optimization-objective- 2261 function}? 2262 +-- objective-function 2263 +-- objective-function-type? identityref 2265 augment /te:tunnels-path-compute/te:output/te:path-compute-result: 2266 +--ro response* [response-id] 2267 +--ro response-id uint32 2268 +--ro computed-paths-properties 2269 | +--ro computed-path-properties* [k-index] 2270 | +--ro k-index uint8 2271 | +--ro path-properties 2272 | +--ro path-metric* [metric-type] 2273 | | +--ro metric-type identityref 2274 | | +--ro accumulative-value? uint64 2275 | +--ro path-affinities-values 2276 | | +--ro path-affinities-value* [usage] 2277 | | +--ro usage identityref 2278 | | +--ro value? admin-groups 2279 | +--ro path-affinity-names 2280 | | +--ro path-affinity-name* [usage] 2281 | | +--ro usage identityref 2282 | | +--ro affinity-name* [name] 2283 | | +--ro name string 2284 | +--ro path-srlgs-lists 2285 | | +--ro path-srlgs-list* [usage] 2286 | | +--ro usage identityref 2287 | | +--ro values* srlg 2288 | +--ro path-srlgs-names 2289 | | +--ro path-srlgs-name* [usage] 2290 | | +--ro usage identityref 2291 | | +--ro names* string 2292 | +--ro path-route-objects 2293 | | +--ro path-route-object* [index] 2294 | | +--ro index uint32 2295 | | +--ro (type)? 2296 | | +--:(numbered-node-hop) 2297 | | | +--ro numbered-node-hop 2298 | | | +--ro node-id te-node-id 2299 | | | +--ro hop-type? te-hop-type 2300 | | +--:(numbered-link-hop) 2301 | | | +--ro numbered-link-hop 2302 | | | +--ro link-tp-id te-tp-id 2303 | | | +--ro hop-type? te-hop-type 2304 | | | +--ro direction? te-link-direction 2305 | | +--:(unnumbered-link-hop) 2306 | | | +--ro unnumbered-link-hop 2307 | | | +--ro link-tp-id te-tp-id 2308 | | | +--ro node-id te-node-id 2309 | | | +--ro hop-type? te-hop-type 2310 | | | +--ro direction? te-link-direction 2311 | | +--:(as-number) 2312 | | | +--ro as-number-hop 2313 | | | +--ro as-number inet:as-number 2314 | | | +--ro hop-type? te-hop-type 2315 | | +--:(label) 2316 | | +--ro label-hop 2317 | | +--ro te-label 2318 | | +--ro (technology)? 2319 | | | +--:(generic) 2320 | | | +--ro generic? 2321 | | | rt-types:generalized- 2322 label 2323 | | +--ro direction? 2324 | | te-label-direction 2325 | +--ro te-bandwidth 2326 | | +--ro (technology)? 2327 | | +--:(generic) 2328 | | +--ro generic? te-bandwidth 2329 | +--ro disjointness-type? 2330 | te-types:te-path-disjointness 2331 +--ro computed-path-error-infos 2332 | +--ro computed-path-error-info* [] 2333 | +--ro error-description? string 2334 | +--ro error-timestamp? yang:date-and-time 2335 | +--ro error-reason? identityref 2336 +--ro tunnel-ref? te:tunnel-ref 2337 +--ro (path-role)? 2338 +--:(primary) 2339 | +--ro primary-path-ref? leafref 2340 +--:(primary-reverse) 2341 | +--ro primary-reverse-path-ref? leafref 2342 +--:(secondary) 2343 | +--ro secondary-path-ref? leafref 2344 +--:(secondary-reverse) 2345 +--ro secondary-reverse-path-ref? leafref 2346 augment /te:tunnels-actions/te:input/te:tunnel-info/te:filter-type: 2347 +--:(path-compute-transactions) 2348 +-- path-compute-transaction-id* string 2349 augment /te:tunnels-actions/te:output: 2350 +--ro path-computed-delete-result 2351 +--ro path-compute-transaction-id* string 2353 Figure 11 - TE path computation tree diagram 2355 6.2. YANG module 2357 file "ietf-te-path-computation@2021-09-06.yang" 2358 module ietf-te-path-computation { 2359 yang-version 1.1; 2360 namespace "urn:ietf:params:xml:ns:yang:ietf-te-path-computation"; 2361 prefix te-pc; 2363 import ietf-te { 2364 prefix te; 2365 revision-date "2021-02-20"; 2366 reference 2367 "RFCYYYY: A YANG Data Model for Traffic Engineering Tunnels 2368 and Interfaces"; 2369 } 2371 /* Note: The RFC Editor will replace YYYY with the number assigned 2372 to the RFC once draft-ietf-teas-yang-te becomes an RFC.*/ 2374 import ietf-te-types { 2375 prefix te-types; 2376 reference 2377 "RFC8776: Common YANG Data Types for Traffic Engineering."; 2378 } 2380 organization 2381 "Traffic Engineering Architecture and Signaling (TEAS) 2382 Working Group"; 2384 contact 2385 "WG Web: 2386 WG List: 2388 Editor: Italo Busi 2389 2391 Editor: Sergio Belotti 2392 2394 Editor: Victor Lopez 2395 2397 Editor: Oscar Gonzalez de Dios 2398 2400 Editor: Anurag Sharma 2401 2403 Editor: Yan Shi 2404 2406 Editor: Ricard Vilalta 2407 2409 Editor: Karthik Sethuraman 2410 2412 Editor: Michael Scharf 2413 2415 Editor: Daniele Ceccarelli 2416 2418 "; 2419 description 2420 "This module defines a YANG data model for requesting Traffic 2421 Engineering (TE) path computation. The YANG model defined in 2422 this document is based on RPCs augmenting the RPCs defined in 2423 the generic TE module (ietf-te). 2424 The model fully conforms to the 2425 Network Management Datastore Architecture (NMDA). 2427 Copyright (c) 2021 IETF Trust and the persons 2428 identified as authors of the code. All rights reserved. 2430 Redistribution and use in source and binary forms, with or 2431 without modification, is permitted pursuant to, and subject 2432 to the license terms contained in, the Simplified BSD License 2433 set forth in Section 4.c of the IETF Trust's Legal Provisions 2435 Relating to IETF Documents 2436 (http://trustee.ietf.org/license-info). 2438 This version of this YANG module is part of RFC XXXX; see 2439 the RFC itself for full legal notices."; 2441 // RFC Ed.: replace XXXX with actual RFC number and remove 2442 // this note 2443 // replace the revision date with the module publication date 2444 // the format is (year-month-day) 2446 revision 2021-09-06 { 2447 description 2448 "Initial revision"; 2449 reference 2450 "RFC XXXX: YANG Data Model for requesting Path Computation"; 2451 } 2453 // RFC Ed.: replace XXXX with actual RFC number and remove 2454 // this note 2456 /* 2457 * Identities 2458 */ 2460 identity svec-metric-type { 2461 description 2462 "Base identity for SVEC metric type."; 2463 reference 2464 "RFC5541: Encoding of Objective Functions in the Path 2465 Computation Element Communication Protocol (PCEP)."; 2466 } 2468 identity svec-metric-cumul-te { 2469 base svec-metric-type; 2470 description 2471 "Cumulative TE cost."; 2472 reference 2473 "RFC5541: Encoding of Objective Functions in the Path 2474 Computation Element Communication Protocol (PCEP)."; 2475 } 2477 identity svec-metric-cumul-igp { 2478 base svec-metric-type; 2479 description 2480 "Cumulative IGP cost."; 2481 reference 2482 "RFC5541: Encoding of Objective Functions in the Path 2483 Computation Element Communication Protocol (PCEP)."; 2484 } 2486 identity svec-metric-cumul-hop { 2487 base svec-metric-type; 2488 description 2489 "Cumulative Hop path metric."; 2490 reference 2491 "RFC8776: Common YANG Data Types for Traffic Engineering."; 2492 } 2494 identity svec-metric-aggregate-bandwidth-consumption { 2495 base svec-metric-type; 2496 description 2497 "Aggregate bandwidth consumption."; 2498 reference 2499 "RFC5541: Encoding of Objective Functions in the Path 2500 Computation Element Communication Protocol (PCEP)."; 2502 } 2504 identity svec-metric-load-of-the-most-loaded-link { 2505 base svec-metric-type; 2506 description 2507 "Load of the most loaded link."; 2508 reference 2509 "RFC5541: Encoding of Objective Functions in the Path 2510 Computation Element Communication Protocol (PCEP)."; 2511 } 2513 identity tunnel-action-path-compute-delete { 2514 base te:tunnel-actions-type; 2515 description 2516 "Action type to delete the transient states 2517 of computed paths, as described in section 3.3.1 of 2518 RFC XXXX."; 2519 reference 2520 "RFC XXXX: YANG Data Model for requesting Path Computation"; 2521 } 2523 /* 2524 * Groupings 2525 */ 2527 grouping protection-restoration-properties { 2528 description 2529 "This grouping defines the restoration and protection types 2530 for a path in the path computation request."; 2531 leaf protection-type { 2532 type identityref { 2533 base te-types:lsp-protection-type; 2534 } 2535 default "te-types:lsp-protection-unprotected"; 2536 description 2537 "LSP protection type."; 2538 } 2539 leaf restoration-type { 2540 type identityref { 2541 base te-types:lsp-restoration-type; 2542 } 2543 default "te-types:lsp-restoration-restore-any"; 2544 description 2545 "LSP restoration type."; 2546 } 2547 leaf restoration-scheme { 2548 type identityref { 2549 base te-types:restoration-scheme-type; 2550 } 2551 default "te-types:restoration-scheme-preconfigured"; 2552 description 2553 "LSP restoration scheme."; 2554 } 2555 } // grouping protection-restoration-properties 2557 grouping requested-info { 2558 description 2559 "This grouping defines the information (e.g., metrics) 2560 which is requested, in the path computation request, to be 2561 returned in the path computation response."; 2562 list requested-metrics { 2563 key "metric-type"; 2564 description 2565 "The list of the requested metrics. 2566 The metrics listed here must be returned in the response. 2567 Returning other metrics in the response is optional."; 2568 leaf metric-type { 2569 type identityref { 2570 base te-types:path-metric-type; 2571 } 2572 description 2573 "The metric that must be returned in the response"; 2574 } 2575 } 2576 leaf return-srlgs { 2577 type boolean; 2578 default "false"; 2579 description 2580 "If true, path srlgs must be returned in the response. 2581 If false, returning path srlgs in the response optional."; 2582 } 2583 leaf return-affinities { 2584 type boolean; 2585 default "false"; 2586 description 2587 "If true, path affinities must be returned in the response. 2588 If false, returning path affinities in the response is 2589 optional."; 2590 } 2591 } // grouping requested-info 2593 grouping requested-state { 2594 description 2595 "Configuration for the transient state used 2596 to report the computed path"; 2597 container requested-state { 2598 presence 2599 "Request temporary reporting of the computed path state"; 2600 description 2601 "Configures attributes for the temporary reporting of the 2602 computed path state (e.g., expiration timer)."; 2603 leaf timer { 2604 type uint16; 2605 units "minutes"; 2606 default "10"; 2607 description 2608 "The timeout after which the transient state reporting 2609 the computed path should be removed."; 2610 } 2611 leaf transaction-id { 2612 type string; 2613 description 2614 "The transaction-id associated with this path computation 2615 to be used for fast deletion of the transient states 2616 associated with multiple path computations. 2618 This transaction-id can be used to explicitly delete all 2619 the transient states of all the computed paths associated 2620 with the same transaction-id. 2622 When one path associated with a transaction-id is setup, 2623 the transient states of all the other computed paths 2624 with the same transaction-id are automatically removed. 2626 If not specified, the transient state is removed only 2627 when the timer expires (when the timer is specified) 2628 or not created at all (stateless path computation, 2629 when the timer is not specified)."; 2630 } 2631 } 2632 } // grouping requested-state 2634 grouping reported-state { 2635 description 2636 "This grouping defines the information, returned in the path 2637 computation response, reporting the transient state related 2638 to the computed path"; 2639 leaf tunnel-ref { 2640 type te:tunnel-ref; 2641 description 2642 " 2643 Reference to the tunnel that reports the transient state 2644 of the computed path. 2646 If no transient state is created, this attribute is 2647 omitted. 2648 "; 2649 } 2650 choice path-role { 2651 description 2652 "The transient state of the computed path can be reported 2653 as a primary, primary-reverse, secondary or 2654 a secondary-reverse path of a te-tunnel"; 2655 case primary { 2656 leaf primary-path-ref { 2657 type leafref { 2658 path "/te:te/te:tunnels/" 2659 + "te:tunnel[te:name=current()/../tunnel-ref]/" 2660 + "te:primary-paths/te:primary-path/" 2661 + "te:name"; 2662 } 2663 must '../tunnel-ref' { 2664 description 2665 "The primary-path name can only be reported 2666 if also the tunnel name is reported."; 2667 } 2668 description 2669 " 2670 Reference to the primary-path that reports 2671 the transient state of the computed path. 2673 If no transient state is created, 2674 this attribute is omitted. 2675 "; 2676 } 2677 } // case primary 2678 case primary-reverse { 2679 leaf primary-reverse-path-ref { 2680 type leafref { 2681 path "/te:te/te:tunnels/" 2682 + "te:tunnel[te:name=current()/../tunnel-ref]/" 2683 + "te:primary-paths/te:primary-path/" 2684 + "te:name"; 2685 } 2686 must '../tunnel-ref' { 2687 description 2688 "The primary-reverse-path name can only be reported 2689 if also the tunnel name is reported."; 2690 } 2691 description 2692 " 2693 Reference to the primary-reverse-path that reports 2694 the transient state of the computed path. 2696 If no transient state is created, 2697 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."; 2737 } 2738 description 2739 " 2740 Reference to the secondary-reverse-path that reports 2741 the transient state of the computed path. 2743 If no transient state is created, 2744 this attribute is omitted. 2745 "; 2746 } 2747 } // case secondary 2748 } // choice path 2749 } // grouping reported-state 2751 grouping synchronization-constraints { 2752 description 2753 "Global constraints applicable to synchronized path 2754 computation requests."; 2755 container svec-constraints { 2756 description 2757 "global svec constraints"; 2758 list path-metric-bound { 2759 key "metric-type"; 2760 description 2761 "list of bound metrics"; 2762 leaf metric-type { 2763 type identityref { 2764 base svec-metric-type; 2765 } 2766 description 2767 "SVEC metric type."; 2768 reference 2769 "RFC5541: Encoding of Objective Functions in the Path 2770 Computation Element Communication Protocol (PCEP)."; 2771 } 2772 leaf upper-bound { 2773 type uint64; 2774 description 2775 "Upper bound on SVEC metric"; 2777 } 2778 } 2779 } 2780 uses te-types:generic-path-srlgs; 2781 container exclude-objects { 2782 description 2783 "Resources to be excluded"; 2784 list excludes { 2785 description 2786 "List of Explicit Route Objects to always exclude 2787 from synchronized path computation"; 2788 uses te-types:explicit-route-hop; 2789 } 2790 } 2791 } // grouping synchronization-constraints 2793 grouping synchronization-optimization { 2794 description 2795 "Optimizations applicable to synchronized path 2796 computation requests."; 2797 container optimizations { 2798 description 2799 "The objective function container that includes attributes 2800 to impose when computing a synchronized set of paths"; 2801 choice algorithm { 2802 description 2803 "Optimizations algorithm."; 2804 case metric { 2805 if-feature "te-types:path-optimization-metric"; 2806 list optimization-metric { 2807 key "metric-type"; 2808 description 2809 "svec path metric type"; 2810 leaf metric-type { 2811 type identityref { 2812 base svec-metric-type; 2813 } 2814 description 2815 "TE path metric type usable for computing a set of 2816 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"; 2856 leaf relaxable { 2857 type boolean; 2858 default "true"; 2859 description 2860 "If this leaf is true, path computation process is 2861 free to ignore svec content. 2862 Otherwise, it must take into account this svec."; 2863 } 2864 uses te-types:generic-path-disjointness; 2865 leaf-list request-id-number { 2866 type uint32; 2867 description 2868 "This list reports the set of path computation 2869 requests that must be synchronized."; 2870 } 2871 } 2872 uses synchronization-constraints; 2873 uses synchronization-optimization; 2874 } 2875 } // grouping synchronization-info 2877 grouping encoding-and-switching-type { 2878 description 2879 "Common grouping to define the LSP encoding and 2880 switching types"; 2881 leaf encoding { 2882 type identityref { 2883 base te-types:lsp-encoding-types; 2884 } 2885 default "te-types:lsp-encoding-packet"; 2886 description 2887 "LSP encoding type."; 2888 reference 2889 "RFC3945"; 2890 } 2891 leaf switching-type { 2892 type identityref { 2893 base te-types:switching-capabilities; 2894 } 2895 default "te-types:switching-psc1"; 2896 description 2897 "LSP switching type."; 2898 reference 2899 "RFC3945"; 2900 } 2901 } 2903 grouping tunnel-common-attributes { 2904 description 2905 "Common grouping to define the TE tunnel parameters"; 2906 uses encoding-and-switching-type; 2907 leaf source { 2908 type te-types:te-node-id; 2909 description 2910 "TE tunnel source node ID."; 2911 } 2912 leaf destination { 2913 type te-types:te-node-id; 2914 description 2915 "TE tunnel destination node identifier."; 2916 } 2917 leaf src-tunnel-tp-id { 2918 type binary; 2919 description 2920 "TE tunnel source termination point identifier."; 2921 } 2922 leaf dst-tunnel-tp-id { 2923 type binary; 2924 description 2925 "TE tunnel destination termination point identifier."; 2926 } 2927 leaf bidirectional { 2928 type boolean; 2929 default "false"; 2930 description 2931 "Indicates a bidirectional co-routed LSP."; 2932 } 2933 } 2934 /* 2935 * Augment TE RPCs 2936 */ 2938 augment "/te:tunnels-path-compute/te:input/te:path-compute-info" { 2939 description 2940 "Path Computation RPC input"; 2941 list path-request { 2942 key "request-id"; 2943 description 2944 "The list of the requested paths to be computed"; 2945 leaf request-id { 2946 type uint32; 2947 mandatory true; 2948 description 2949 "Each path computation request is uniquely identified 2950 within the RPC request by the request-id-number."; 2951 } 2952 choice tunnel-attributes { 2953 default "value"; 2954 description 2955 "Whether the tunnel attributes are specified by value 2956 within this path computation request or by reference. 2957 The reference could be either to an existing te-tunnel 2958 or to an entry in the tunnel-attributes list"; 2959 case reference { 2960 container tunnel-reference { 2961 description 2962 "Attributes for a requested path that belongs to 2963 either an exiting te-tunnel or to an entry in the 2964 tunnel-attributes list."; 2965 choice tunnel-exist { 2966 description 2967 "Whether the tunnel reference is to an existing 2968 te-tunnel or to an entry in the tunnel-attributes 2969 list"; 2970 case tunnel-ref { 2971 leaf tunnel-ref { 2972 type te:tunnel-ref; 2973 mandatory true; 2974 description 2975 "The referenced te-tunnel instance"; 2976 } 2977 } // case tunnel-ref 2978 case tunnel-attributes-ref { 2979 leaf tunnel-attributes-ref { 2980 type leafref { 2981 path "/te:tunnels-path-compute/" 2982 + "te:path-compute-info/" 2983 + "te-pc:tunnel-attributes/te-pc:tunnel-name"; 2984 } 2985 mandatory true; 2986 description 2987 "The referenced te-tunnel instance"; 2988 } 2989 } // case tunnel-attributes-ref 2990 } // choice tunnel-exist 2991 leaf path-name { 2992 type string; 2993 description 2994 "TE path name."; 2995 } 2996 choice path-role { 2997 mandatory true; 2998 description 2999 "Whether this path is a primary, or a reverse 3000 primary, or a secondary, or a reverse secondary 3001 path."; 3002 case primary-path { 3003 container primary-path { 3004 presence "Indicates that the requested path 3005 is a primary path"; 3006 description 3007 "TE primary path"; 3008 uses te:path-preference; 3009 uses te:k-requested-paths; 3010 } // container primary-path 3012 } // case primary-path 3013 case secondary-path { 3014 container secondary-path { 3015 description 3016 "TE secondary path"; 3017 uses te:path-preference; 3018 uses protection-restoration-properties; 3019 list primary-path-ref { 3020 min-elements 1; 3021 description 3022 "The list of primary paths that reference 3023 this path as a candidate secondary path"; 3024 choice primary-path-exist { 3025 description 3026 "Whether the path reference is to an existing 3027 te-tunnel path or to another path request"; 3028 case path-ref { 3029 leaf primary-path-ref { 3030 type leafref { 3031 path "/te:te/te:tunnels/te:tunnel" 3032 + "[te:name=current()/../../../" 3033 + "tunnel-ref]/te:primary-paths/" 3034 + "te:primary-path/te:name"; 3035 } 3036 must '../../../tunnel-ref' { 3037 description 3038 "The primary-path can be referenced 3039 if also the tunnel is referenced."; 3040 } 3041 mandatory true; 3042 description 3043 "The referenced primary path"; 3044 } 3045 } // case path-ref 3046 case path-request-ref { 3047 leaf path-request-ref { 3048 type leafref { 3049 path "/te:tunnels-path-compute/" 3050 + "te:path-compute-info/" 3051 + "te-pc:path-request/" 3052 + "te-pc:request-id"; 3053 } 3054 mandatory true; 3055 description 3056 "The referenced primary path request"; 3057 } 3058 } // case path-request-ref 3059 } // choice primary-path-exist 3060 } // list primary-path-ref 3061 } // container secondary-path 3062 } // case secondary-path 3063 case primary-reverse-path { 3064 container primary-reverse-path { 3065 description 3066 "TE primary reverse path"; 3067 choice primary-path-exist { 3068 description 3069 "Whether the path reference to the primary 3070 paths for which this path is the reverse-path 3071 is to an existing te-tunnel path or to 3072 another path request."; 3073 case path-ref { 3074 leaf primary-path-ref { 3075 type leafref { 3076 path "/te:te/te:tunnels/te:tunnel[te:name" 3077 + "=current()/../../tunnel-ref]/" 3078 + "te:primary-paths/te:primary-path/" 3079 + "te:name"; 3080 } 3081 must '../../tunnel-ref' { 3082 description 3083 "The primary-path can be referenced 3084 if also the tunnel is referenced."; 3085 } 3086 mandatory true; 3087 description 3088 "The referenced primary path"; 3089 } 3091 } // case path-ref 3092 case path-request-ref { 3093 leaf path-request-ref { 3094 type leafref { 3095 path "/te:tunnels-path-compute/" 3096 + "te:path-compute-info/" 3097 + "te-pc:path-request/" 3098 + "te-pc:request-id"; 3099 } 3100 mandatory true; 3101 description 3102 "The referenced primary path request"; 3103 } 3104 } // case path-request-ref 3105 } // choice primary-path-exist 3106 } // container primary-reverse-path 3107 } // case primary-reverse-path 3108 case secondary-reverse-path { 3109 container secondary-reverse-path { 3110 description 3111 "TE secondary reverse path"; 3112 uses te:path-preference; 3113 uses protection-restoration-properties; 3114 list primary-reverse-path-ref { 3115 min-elements 1; 3116 description 3117 "The list of primary reverse paths that 3118 reference this path as a candidate 3119 secondary reverse path"; 3120 choice primary-reverse-path-exist { 3121 description 3122 "Whether the path reference is to an existing 3123 te-tunnel path or to another path request"; 3124 case path-ref { 3125 leaf primary-path-ref { 3126 type leafref { 3127 path "/te:te/te:tunnels/te:tunnel" 3128 + "[te:name=current()/../../../" 3129 + "tunnel-ref]/te:primary-paths/" 3130 + "te:primary-path/te:name"; 3131 } 3132 must '../../../tunnel-ref' { 3133 description 3134 "The primary-path can be referenced 3135 if also the tunnel is referenced."; 3136 } 3137 mandatory true; 3138 description 3139 "The referenced primary path"; 3140 } 3141 } // case path-ref 3142 case path-request-ref { 3143 leaf path-request-ref { 3144 type leafref { 3145 path "/te:tunnels-path-compute/" 3146 + "te:path-compute-info/" 3147 + "te-pc:path-request/" 3148 + "te-pc:request-id"; 3149 } 3150 mandatory true; 3151 description 3152 "The referenced primary reverse path 3153 request"; 3154 } 3155 } // case path-request-ref 3156 } // choice primary-reverse-path-exist 3157 } // list primary-reverse-path-ref 3158 } // container secondary-reverse-path 3159 } // case secondary-reverse-path 3160 } // choice tunnel-path-role 3161 } 3162 } // case reference 3163 case value { 3164 leaf tunnel-name { 3165 type string; 3166 description 3167 "TE tunnel name."; 3168 } 3169 leaf path-name { 3170 type string; 3171 description 3172 "TE path name."; 3173 } 3174 choice path-role { 3175 when 'not (./source) and not (./destination) and 3176 not (./src-tunnel-tp-id) and 3177 not (./dst-tunnel-tp-id)' { 3178 description 3179 "When the tunnel attributes are specified by value 3180 within this path computation, it is assumed that the 3181 requested path will be the only path of a tunnel. 3183 If the requested path is a transit segment path, it 3184 could be of any type. Otherwise it could only be a 3185 primary path."; 3186 } 3187 default primary-path; 3188 description 3189 "Indicates whether the requested path is a primary 3190 path, a secondary path, a reverse primary path or a 3191 reverse secondary path."; 3192 case primary-path { 3193 description 3194 "The requested path is a primary path."; 3195 } 3196 container secondary-path { 3197 presence 3198 "Indicates that the requested path is a secondary 3199 path."; 3200 description 3201 "The name of the primary path which the requested 3202 primary reverse path belongs to."; 3203 leaf primary-path-name { 3204 type string; 3205 description 3206 "TE primary path name."; 3207 } 3209 } // container secondary-path 3210 container primary-reverse-path { 3211 presence 3212 "Indicates that the requested path is a primary 3213 reverse path."; 3214 description 3215 "The name of the primary path which the requested 3216 primary reverse path belongs to."; 3217 leaf primary-path-name { 3218 type string; 3219 description 3220 "TE primary path name."; 3221 } 3222 } // container primary-reverse-path 3223 container secondary-reverse-path { 3224 presence 3225 "Indicates that the requested path is a secondary 3226 reverse path."; 3227 description 3228 "The names of the primary path and of the primary 3229 reverse path which the requested secondary reverse 3230 path belongs to."; 3231 leaf primary-path-name { 3232 type string; 3233 description 3234 "TE primary path name."; 3235 } 3236 leaf primary-reverse-path-name { 3237 type string; 3238 description 3239 "TE primary reverse path name."; 3240 } 3241 } // container primary-reverse-path 3242 } // choice path-role 3243 uses te:k-requested-paths; 3244 uses tunnel-common-attributes; 3245 uses te-types:te-topology-identifier; 3246 } // case value 3247 } // choice tunnel-attributes 3248 uses te:path-compute-info; 3249 uses requested-info; 3250 uses requested-state; 3251 } 3252 list tunnel-attributes { 3253 key "tunnel-name"; 3254 description 3255 "Tunnel attributes common to multiple request paths"; 3256 leaf tunnel-name { 3257 type string; 3258 description 3259 "TE tunnel name."; 3260 } 3261 uses tunnel-common-attributes; 3262 uses te:tunnel-associations-properties; 3263 uses protection-restoration-properties; 3264 uses te-types:tunnel-constraints; 3265 uses te:tunnel-hierarchy-properties { 3266 augment "hierarchy/dependency-tunnels" { 3267 description 3268 "Augment with the list of dependency tunnel requests."; 3269 list dependency-tunnel-attributes { 3270 key "name"; 3271 description 3272 "A tunnel request entry that this tunnel request can 3273 potentially depend on."; 3274 leaf name { 3275 type leafref { 3276 path "/te:tunnels-path-compute/" 3277 + "te:path-compute-info/te-pc:tunnel-attributes/" 3278 + "te-pc:tunnel-name"; 3279 } 3280 description 3281 "Dependency tunnel request name."; 3282 } 3283 uses encoding-and-switching-type; 3284 } 3285 } 3286 } 3288 } 3289 uses synchronization-info; 3290 } // path-compute rpc input 3292 augment "/te:tunnels-path-compute/te:output/" 3293 + "te:path-compute-result" { 3294 description 3295 "Path Computation RPC output"; 3296 list response { 3297 key "response-id"; 3298 config false; 3299 description 3300 "response"; 3301 leaf response-id { 3302 type uint32; 3303 description 3304 "The response-id has the same value of the 3305 corresponding request-id."; 3306 } 3307 uses te:path-computation-response; 3308 uses reported-state; 3309 } 3310 } // path-compute rpc output 3312 augment "/te:tunnels-actions/te:input/te:tunnel-info/" 3313 + "te:filter-type" { 3314 description 3315 "Augment Tunnels Action RPC input filter types"; 3316 case path-compute-transactions { 3317 when "derived-from-or-self(../te:action-info/te:action, " 3318 + "'tunnel-action-path-compute-delete')"; 3319 description 3320 "Path Delete Action RPC"; 3321 leaf-list path-compute-transaction-id { 3322 type string; 3323 description 3324 "The list of the transaction-id values of the 3325 transient states to be deleted"; 3326 } 3328 } 3329 } // path-delete rpc input 3331 augment "/te:tunnels-actions/te:output" { 3332 description 3333 "Augment Tunnels Action RPC output with path delete result"; 3334 container path-computed-delete-result { 3335 description 3336 "Path Delete RPC output"; 3337 leaf-list path-compute-transaction-id { 3338 type string; 3339 description 3340 "The list of the transaction-id values of the 3341 transient states that have been successfully deleted"; 3342 } 3343 } 3344 } // path-delete rpc output 3345 } 3346 3348 Figure 12 - TE path computation YANG module 3350 7. Security Considerations 3352 This document describes use cases of requesting Path Computation 3353 using YANG data models, which could be used at the ABNO Control 3354 Interface [RFC7491] and/or between controllers in ACTN [RFC8453]. As 3355 such, it does not introduce any new security considerations compared 3356 to the ones related to YANG specification, ABNO specification and 3357 ACTN Framework defined in [RFC7950], [RFC7491] and [RFC8453]. 3359 The YANG module defined in this draft is designed to be accessed via 3360 the NETCONF protocol [RFC6241] or RESTCONF protocol [RFC8040]. The 3361 lowest NETCONF layer is the secure transport layer, and the 3362 mandatory-to-implement secure transport is Secure Shell (SSH) 3363 [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to- 3364 implement secure transport is TLS [RFC8446]. 3366 This document also defines common data types using the YANG data 3367 modeling language. The definitions themselves have no security impact 3368 on the Internet, but the usage of these definitions in concrete YANG 3369 modules might have. The security considerations spelled out in the 3370 YANG specification [RFC7950] apply for this document as well. 3372 The NETCONF access control model [RFC8341] provides the means to 3373 restrict access for particular NETCONF or RESTCONF users to a 3374 preconfigured subset of all available NETCONF or RESTCONF protocol 3375 operations and content. 3377 Note - The security analysis of each leaf is for further study. 3379 8. IANA Considerations 3381 This document registers the following URIs in the "ns" subregistry 3382 within the "IETF XML registry" [RFC3688]. 3384 URI: urn:ietf:params:xml:ns:yang:ietf-te-path-computation 3385 Registrant Contact: The IESG. 3386 XML: N/A, the requested URI is an XML namespace. 3388 This document registers a YANG module in the "YANG Module Names" 3389 registry [RFC7950]. 3391 name: ietf-te-path-computation 3392 namespace: urn:ietf:params:xml:ns:yang:ietf-te-path-computation 3393 prefix: te-pc 3394 reference: this document 3396 9. References 3398 9.1. Normative References 3400 [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 3401 2004. 3403 [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label 3404 Switching (GMPLS) Architecture", RFC 3945, DOI 3405 10.17487/RFC3945, October 2004, . 3408 [RFC5440] Vasseur, JP., Le Roux, JL. et al., "Path Computation 3409 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 3410 March 2009. 3412 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 3413 "A Backward-Recursive PCE-Based Computation (BRPC) 3414 Procedure to Compute Shortest Constrained Inter-Domain 3415 Traffic Engineering Label Switched Paths", RFC 5441, 3416 DOI 10.17487/RFC5441, April 2009, . 3419 [RFC5541] Le Roux, JL. et al., "Encoding of Objective Functions in 3420 the Path Computation Element Communication Protocol 3421 (PCEP)", RFC 5541, June 2009. 3423 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 3424 and A. Bierman, Ed., "Network Configuration Protocol 3425 (NETCONF)", RFC 6241, June 2011. 3427 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 3428 Shell (SSH)", RFC 6242, June 2011. 3430 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, July 3431 2013. 3433 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 3434 Protocol", RFC 8040, January 2017. 3436 [RFC8341] Bierman, A., and M. Bjorklund, "Network Configuration 3437 Access Control Model", RFC 8341, March 2018. 3439 [RFC7926] Farrel, A. et al., "Problem Statement and Architecture for 3440 Information Exchange Between Interconnected Traffic 3441 Engineered Networks", RFC 7926, July 2016. 3443 [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC 3444 7950, August 2016. 3446 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 3447 Protocol", RFC 8040, January 2017. 3449 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 3450 215, RFC 8340, March 2018. 3452 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3453 Version 1.3", RFC 8446, August 2018. 3455 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 3456 "Common YANG Data Types for Traffic Engineering", RFC8776, 3457 June 2020. 3459 [RFC8795] Liu, X. et al., " Liu, X. et al., "YANG Data Model for 3460 Traffic Engineering (TE) Topologies", RFC8795, August 2020. 3462 [TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic 3463 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 3464 te, work in progress. 3466 9.2. Informative References 3468 [RFC4655] Farrel, A. et al., "A Path Computation Element (PCE)-Based 3469 Architecture", RFC 4655, August 2006. 3471 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 3472 Path Computation Element Architecture to the Determination 3473 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, DOI 3474 10.17487/RFC6805, November 2012, . 3477 [RFC7139] Zhang, F. et al., "GMPLS Signaling Extensions for Control 3478 of Evolving G.709 Optical Transport Networks", RFC 7139, 3479 March 2014. 3481 [RFC7446] Lee, Y. et al., "Routing and Wavelength Assignment 3482 Information Model for Wavelength Switched Optical 3483 Networks", RFC 7446, February 2015. 3485 [RFC7491] Farrel, A., King, D., "A PCE-Based Architecture for 3486 Application-Based Network Operations", RFC 7491, March 3487 2015. 3489 [RFC8233] Dhody, D. et al., "Extensions to the Path Computation 3490 Element Communication Protocol (PCEP) to Compute Service- 3491 Aware Label Switched Paths (LSPs)", RFC 8233, September 3492 2017 3494 [RFC8342] Bjorklund,M. et al. "Network Management Datastore 3495 Architecture (NMDA)", RFC 8342, March 2018 3497 [RFC8453] Ceccarelli, D., Lee, Y. et al., "Framework for Abstraction 3498 and Control of TE Networks (ACTN)", RFC8453, August 2018. 3500 [RFC8454] Lee, Y. et al., "Information Model for Abstraction and 3501 Control of TE Networks (ACTN)", RFC8454, September 2018. 3503 [OTN-TOPO] Zheng, H. et al., "A YANG Data Model for Optical Transport 3504 Network Topology", draft-ietf-ccamp-otn-topo-yang, work in 3505 progress. 3507 [ITU-T G.709-2016] ITU-T Recommendation G.709 (06/16), "Interface 3508 for the optical transport network", June 2016. 3510 Appendix A. Examples of dimensioning the "detailed connectivity matrix" 3512 In the following table, a list of the possible constraints, 3513 associated with their potential cardinality, is reported. 3515 The maximum number of potential connections to be computed and 3516 reported is, in first approximation, the multiplication of all of 3517 them. 3519 Constraint Cardinality 3520 ---------- ------------------------------------------------------- 3522 End points N(N-1)/2 if connections are bidirectional (OTN and WDM), 3523 N(N-1) for unidirectional connections. 3525 Bandwidth In WDM networks, bandwidth values are expressed in GHz. 3527 On fixed-grid WDM networks, the central frequencies are 3528 on a 50GHz grid and the channel width of the transmitters 3529 are typically 50GHz such that each central frequency can 3530 be used, i.e., adjacent channels can be placed next to 3531 each other in terms of central frequencies. 3533 On flex-grid WDM networks, the central frequencies are on 3534 a 6.25GHz grid and the channel width of the transmitters 3535 can be multiples of 12.5GHz. 3537 For fixed-grid WDM networks typically there is only one 3538 possible bandwidth value (i.e., 50GHz) while for flex- 3539 grid WDM networks typically there are 4 possible 3540 bandwidth values (e.g., 37.5GHz, 50GHz, 62.5GHz, 75GHz). 3542 In OTN (ODU) networks, bandwidth values are expressed as 3543 pairs of ODU type and, in case of ODUflex, ODU rate in 3544 bytes/sec as described in section 5 of [RFC7139]. 3546 For "fixed" ODUk types, 6 possible bandwidth values are 3547 possible (i.e., ODU0, ODU1, ODU2, ODU2e, ODU3, ODU4). 3549 For ODUflex(GFP), up to 80 different bandwidth values can 3550 be specified, as defined in Table 7-8 of [ITU-T G.709- 3551 2016]. 3553 For other ODUflex types, like ODUflex(CBR), the number of 3554 possible bandwidth values depends on the rates of the 3555 clients that could be mapped over these ODUflex types, as 3556 shown in Table 7.2 of [ITU-T G.709-2016], which in theory 3557 could be a countinuum of values. However, since different 3558 ODUflex bandwidths that use the same number of TSs on 3559 each link along the path are equivalent for path 3560 computation purposes, up to 120 different bandwidth 3561 ranges can be specified. 3563 Ideas to reduce the number of ODUflex bandwidth values in 3564 the detailed connectivity matrix, to less than 100, are 3565 for further study. 3567 Bandwidth specification for ODUCn is currently for 3568 further study but it is expected that other bandwidth 3569 values can be specified as integer multiples of 100Gb/s. 3571 In IP we have bandwidth values in bytes/sec. In 3572 principle, this is a countinuum of values, but in 3573 practice we can identify a set of bandwidth ranges, where 3574 any bandwidth value inside the same range produces the 3575 same path. 3576 The number of such ranges is the cardinality, which 3577 depends on the topology, available bandwidth and status 3578 of the network. Simulations (Note: reference paper 3579 submitted for publication) show that values for medium 3580 size topologies (around 50-150 nodes) are in the range 4- 3581 7 (5 on average) for each end points couple. 3583 Metrics IGP, TE and hop number are the basic objective metrics 3584 defined so far. There are also the 2 objective functions 3585 defined in [RFC5541]: Minimum Load Path (MLP) and Maximum 3586 Residual Bandwidth Path (MBP). Assuming that one only 3587 metric or objective function can be optimized at once, 3588 the total cardinality here is 5. 3590 With [RFC8233], a number of additional metrics are 3591 defined, including Path Delay metric, Path Delay 3592 Variation metric and Path Loss metric, both for point-to- 3593 point and point-to-multipoint paths. This increases the 3594 cardinality to 8. 3596 Bounds Each metric can be associated with a bound in order to 3597 find a path having a total value of that metric lower 3598 than the given bound. This has a potentially very high 3599 cardinality (as any value for the bound is allowed). In 3600 practice there is a maximum value of the bound (the one 3601 with the maximum value of the associated metric) which 3602 results always in the same path, and a range approach 3603 like for bandwidth in IP should produce also in this case 3604 the cardinality. Assuming to have a cardinality similar 3605 to the one of the bandwidth (let say 5 on average) we 3606 should have 6 (IGP, TE, hop, path delay, path delay 3607 variation and path loss; we don't consider here the two 3608 objective functions of [RFC5541] as they are conceived 3609 only for optimization)*5 = 30 cardinality. 3611 Technology 3612 constraints For further study 3614 Priority We have 8 values for set-up priority, which is used in 3615 path computation to route a path using free resources 3616 and, where no free resources are available, resources 3617 used by LSPs having a lower holding priority. 3619 Local prot It's possible to ask for a local protected service, where 3620 all the links used by the path are protected with fast 3621 reroute (this is only for IP networks, but line 3622 protection schemas are available on the other 3623 technologies as well). This adds an alternative path 3624 computation, so the cardinality of this constraint is 2. 3626 Administrative 3627 Colors Administrative colors (aka affinities) are typically 3628 assigned to links but when topology abstraction is used 3629 affinity information can also appear in the detailed 3630 connectivity matrix. 3632 There are 32 bits available for the affinities. Links can 3633 be tagged with any combination of these bits, and path 3634 computation can be constrained to include or exclude any 3635 or all of them. The relevant cardinality is 3 (include- 3636 any, exclude-any, include-all) times 2^32 possible 3637 values. However, the number of possible values used in 3638 real networks is quite small. 3640 Included Resources 3642 A path computation request can be associated to an 3643 ordered set of network resources (links, nodes) to be 3644 included along the computed path. This constraint would 3645 have a huge cardinality as in principle any combination 3646 of network resources is possible. However, as far as the 3647 client doesn't know details about the internal topology 3648 of the domain, it shouldn't include this type of 3649 constraint at all (see more details below). 3651 Excluded Resources 3653 A path computation request can be associated to a set of 3654 network resources (links, nodes, SRLGs) to be excluded 3655 from the computed path. Like for included resources, this 3656 constraint has a potentially very high cardinality, but, 3657 once again, it can't be actually used by the client, if 3658 it's not aware of the domain topology (see more details 3659 below). 3660 As discussed above, the client can specify include or exclude 3661 resources depending on the abstract topology information that the 3662 underlying controller exposes: 3664 o In case the underlying controller exposes the entire domain as a 3665 single abstract TE node with his own external terminations and 3666 detailed connectivity matrix (whose size we are estimating), no 3667 other topological details are available, therefore the size of the 3668 detailed connectivity matrix only depends on the combination of 3669 the constraints that the client can use in a path computation 3670 request to its underlying controller. These constraints cannot 3671 refer to any details of the internal topology of the domain, as 3672 those details are not known to the client and so they do not 3673 impact size of the detailed connectivity matrix exported. 3675 o Instead in case the underlying controller exposes a topology 3676 including more than one abstract TE nodes and TE links, and their 3677 attributes (e.g. SRLGs, affinities for the links), the client 3678 knows these details and therefore could compute a path across the 3679 domain referring to them in the constraints. The detailed 3680 connectivity matrixes, whose size need to be estimated here, are 3681 the ones relevant to the abstract TE nodes exported to the client. 3682 These detailed connectivity matrixes and therefore theirs sizes, 3683 while cannot depend on the other abstract TE nodes and TE links, 3684 which are external to the given abstract node, could depend to 3685 SRLGs (and other attributes, like affinities) which could be 3686 present also in the portion of the topology represented by the 3687 abstract nodes, and therefore contribute to the size of the 3688 related detailed connectivity matrix. 3690 We also don't consider here the possibility to ask for more than one 3691 path in diversity or for point-to-multi-point paths, which are for 3692 further study. 3694 Considering for example an IP domain without considering SRLG and 3695 affinities, we have an estimated number of paths depending on these 3696 estimated cardinalities: 3698 Endpoints = N*(N-1), Bandwidth = 5, Metrics = 6, Bounds = 20, 3699 Priority = 8, Local prot = 2 3701 The number of paths to be pre-computed by each IP domain is therefore 3702 24960 * N(N-1) where N is the number of domain access points. 3704 This means that with just 4 access points we have nearly 300000 paths 3705 to compute, advertise and maintain (if a change happens in the 3706 domain, due to a fault, or just the deployment of new traffic, a 3707 substantial number of paths need to be recomputed and the relevant 3708 changes advertised to the client). 3710 This seems quite challenging. In fact, if we assume a mean length of 3711 1K for the json describing a path (a quite conservative estimate), 3712 reporting 300000 paths means transferring and then parsing more than 3713 300 Mbytes for each domain. If we assume that 20% (to be checked) of 3714 this paths change when a new deployment of traffic occurs, we have 60 3715 Mbytes of transfer for each domain traversed by a new end-to-end 3716 path. If a network has, let say, 20 domains (we want to estimate the 3717 load for a non-trivial domain set-up) in the beginning a total 3718 initial transfer of 6Gigs is needed, and eventually, assuming 4-5 3719 domains are involved in mean during a path deployment we could have 3720 240-300 Mbytes of changes advertised to the client. 3722 Further bare-bone solutions can be investigated, removing some more 3723 options, if this is considered not acceptable; in conclusion, it 3724 seems that an approach based only on the information provided by the 3725 detailed connectivity matrix is hardly feasible, and could be 3726 applicable only to small networks with a limited meshing degree 3727 between domains and renouncing to a number of path computation 3728 features. 3730 Acknowledgments 3732 The authors would like to thank Igor Bryskin and Xian Zhang for 3733 participating in the initial discussions that have triggered this 3734 work and providing valuable insights. 3736 The authors would like to thank the authors of the TE tunnel YANG 3737 data model [TE-TUNNEL], in particular Igor Bryskin, Vishnu Pavan 3738 Beeram, Tarek Saad and Xufeng Liu, for their inputs to the 3739 discussions and support in having consistency between the Path 3740 Computation and TE tunnel YANG data models. 3742 The authors would like to thank Adrian Farrel, Dhruv Dhody, Igor 3743 Bryskin, Julien Meuric and Lou Berger for their valuable input to the 3744 discussions that has clarified that the path being set up is not 3745 necessarily the same as the path that has been previously computed 3746 and, in particular to Dhruv Dhody, for his suggestion to describe the 3747 need for a path verification phase to check that the actual path 3748 being set up meets the required end-to-end metrics and constraints. 3750 The authors would like to thank Aihua Guo, Lou Berger, Shaolong Gan, 3751 Martin Bjorklund and Tom Petch for their useful comments on how to 3752 define XPath statements in YANG RPCs. 3754 The authors would like to thank Haomian Zheng, Yanlei Zheng, Tom 3755 Petch, Aihua Guo and Martin Bjorklund for their review and valuable 3756 comments to this document. 3758 This document was prepared using 2-Word-v2.0.template.dot. 3760 Contributors 3762 Dieter Beller 3763 Nokia 3764 Email: dieter.beller@nokia.com 3766 Gianmarco Bruno 3767 Ericsson 3768 Email: gianmarco.bruno@ericsson.com 3769 Francesco Lazzeri 3770 Ericsson 3771 Email: francesco.lazzeri@ericsson.com 3773 Young Lee 3774 Samsung Electronics 3775 Email: younglee.tx@gmail.com 3777 Carlo Perocchio 3778 Ericsson 3779 Email: carlo.perocchio@ericsson.com 3781 Olivier Dugeon 3782 Orange Labs 3783 Email: olivier.dugeon@orange.com 3785 Julien Meuric 3786 Orange Labs 3787 Email: julien.meuric@orange.com 3789 Authors' Addresses 3791 Italo Busi (Editor) 3792 Huawei 3793 Email: italo.busi@huawei.com 3795 Sergio Belotti (Editor) 3796 Nokia 3797 Email: sergio.belotti@nokia.com 3799 Victor Lopez 3800 Nokia 3801 Email: victor.lopez@nokia.com 3803 Oscar Gonzalez de Dios 3804 Telefonica 3805 Email: oscar.gonzalezdedios@telefonica.com 3806 Anurag Sharma 3807 Google 3808 Email: ansha@google.com 3810 Yan Shi 3811 China Unicom 3812 Email: shiyan49@chinaunicom.cn 3814 Ricard Vilalta 3815 CTTC 3816 Email: ricard.vilalta@cttc.es 3818 Karthik Sethuraman 3819 NEC 3820 Email: karthik.sethuraman@necam.com 3822 Michael Scharf 3823 Nokia 3824 Email: michael.scharf@gmail.com 3826 Daniele Ceccarelli 3827 Ericsson 3828 Email: daniele.ceccarelli@ericsson.com