idnits 2.17.1 draft-ietf-teas-yang-path-computation-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([TE-TUNNEL]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1212 has weird spacing: '...tion-id uin...' == Line 1219 has weird spacing: '...ic-type ide...' == Line 1227 has weird spacing: '...- usage ide...' == Line 1235 has weird spacing: '...ic-type ide...' == Line 1306 has weird spacing: '...o usage ide...' == (33 more instances...) -- The document date (March 11, 2019) is 1872 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) ** Downref: Normative reference to an Informational RFC: RFC 7491 ** Downref: Normative reference to an Informational RFC: RFC 8453 ** Downref: Normative reference to an Informational RFC: RFC 8454 Summary: 4 errors (**), 0 flaws (~~), 7 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: September 2019 Nokia 5 Victor Lopez 6 Oscar Gonzalez de Dios 7 Telefonica 8 Anurag Sharma 9 Google 10 Yan Shi 11 China Unicom 12 Ricard Vilalta 13 CTTC 14 Karthik Sethuraman 15 NEC 17 March 11, 2019 19 Yang model for requesting Path Computation 20 draft-ietf-teas-yang-path-computation-05.txt 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as 35 reference material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 42 This Internet-Draft will expire on September 11, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with 54 respect to this document. Code Components extracted from this 55 document must include Simplified BSD License text as described in 56 Section 4.e of the Trust Legal Provisions and are provided without 57 warranty as described in the Simplified BSD License. 59 Abstract 61 There are scenarios, typically in a hierarchical SDN context, where 62 the topology information provided by a TE network provider may not 63 be sufficient for its client to perform end-to-end path computation. 64 In these cases the client would need to request the provider to 65 calculate some (partial) feasible paths. 67 This document defines a YANG data model for a stateless RPC to 68 request path computation. This model complements the stateful 69 solution defined in [TE-TUNNEL]. 71 Moreover this document describes some use cases where a path 72 computation request, via YANG-based protocols (e.g., NETCONF or 73 RESTCONF), can be needed. 75 Table of Contents 77 1. Introduction...................................................3 78 1.1. Terminology...............................................5 79 2. Use Cases......................................................5 80 2.1. Packet/Optical Integration................................5 81 2.2. Multi-domain TE Networks.................................10 82 2.3. Data center interconnections.............................12 83 3. Motivations...................................................14 84 3.1. Motivation for a YANG Model..............................14 85 3.1.1. Benefits of common data models......................14 86 3.1.2. Benefits of a single interface......................15 87 3.1.3. Extensibility.......................................15 88 3.2. Interactions with TE Topology............................16 89 3.2.1. TE Topology Aggregation.............................17 90 3.2.2. TE Topology Abstraction.............................20 91 3.2.3. Complementary use of TE topology and path computation21 92 3.3. Stateless and Stateful Path Computation..................24 93 3.3.1. Temporary reporting of the computed path state......26 94 4. Path Computation and Optimization for multiple paths..........28 95 5. YANG Model for requesting Path Computation....................29 96 5.1. Synchronization of multiple path computation requests....29 97 5.2. Returned metric values...................................31 98 6. YANG model for stateless TE path computation..................33 99 6.1. YANG Tree................................................33 100 6.2. YANG Module..............................................43 101 7. Security Considerations.......................................58 102 8. IANA Considerations...........................................59 103 9. References....................................................59 104 9.1. Normative References.....................................59 105 9.1. Informative References...................................60 106 10. Acknowledgments..............................................61 107 Appendix A. Examples of dimensioning the "detailed connectivity 108 matrix" 62 110 1. Introduction 112 There are scenarios, typically in a hierarchical SDN context, where 113 the topology information provided by a TE network provider may not 114 be sufficient for its client to perform end-to-end path computation. 115 In these cases the client would need to request the provider to 116 calculate some (partial) feasible paths, complementing his topology 117 knowledge, to make his end-to-end path computation feasible. 119 This type of scenarios can be applied to different interfaces in 120 different reference architectures: 122 o ABNO control interface [RFC7491], in which an Application Service 123 Coordinator can request ABNO controller to take in charge path 124 calculation (see Figure 1 in [RFC7491]). 126 o ACTN [RFC8453], where a controller hierarchy is defined, the need 127 for path computation arises on both interfaces CMI (interface 128 between Customer Network Controller (CNC) and Multi Domain 129 Service Coordinator (MDSC)) and/or MPI (interface between MSDC- 130 PNC). [RFC8454] describes an information model for the Path 131 Computation request. 133 Multiple protocol solutions can be used for communication between 134 different controller hierarchical levels. This document assumes that 135 the controllers are communicating using YANG-based protocols (e.g., 136 NETCONF or RESTCONF). 138 Path Computation Elements, Controllers and Orchestrators perform 139 their operations based on Traffic Engineering Databases (TED). Such 140 TEDs can be described, in a technology agnostic way, with the YANG 141 Data Model for TE Topologies [TE-TOPO]. Furthermore, the technology 142 specific details of the TED are modeled in the augmented TE topology 143 models (e.g. [OTN-TOPO] for OTN ODU technologies). 145 The availability of such topology models allows providing the TED 146 using YANG-based protocols (e.g., NETCONF or RESTCONF). Furthermore, 147 it enables a PCE/Controller performing the necessary abstractions or 148 modifications and offering this customized topology to another 149 PCE/Controller or high level orchestrator. 151 Note: This document assumes that the client of the YANG data model 152 defined in this document may not implement a "PCE" functionality, as 153 defined in [RFC4655]. 155 The tunnels that can be provided over the networks described with 156 the topology models can be also set-up, deleted and modified via 157 YANG-based protocols (e.g., NETCONF or RESTCONF) using the TE-Tunnel 158 Yang model [TE-TUNNEL]. 160 This document proposes a YANG model for a path computation request 161 defined as a stateless RPC, which complements the stateful solution 162 defined in [TE-TUNNEL]. 164 Moreover, this document describes some use cases where a path 165 computation request, via YANG-based protocols (e.g., NETCONF or 166 RESTCONF), can be needed. 168 1.1. Terminology 170 TED: The traffic engineering database is a collection of all TE 171 information about all TE nodes and TE links in a given network. 173 PCE: A Path Computation Element (PCE) is an entity that is capable 174 of computing a network path or route based on a network graph, and 175 of applying computational constraints during the computation. The 176 PCE entity is an application that can be located within a network 177 node or component, on an out-of-network server, etc. For example, a 178 PCE would be able to compute the path of a TE LSP by operating on 179 the TED and considering bandwidth and other constraints applicable 180 to the TE LSP service request. [RFC4655] 182 2. Use Cases 184 This section presents different use cases, where a client needs to 185 request underlying SDN controllers for path computation. 187 The presented uses cases have been grouped, depending on the 188 different underlying topologies: a) Packet-Optical integration; b) 189 Multi-domain Traffic Engineered (TE) Networks; and c) Data center 190 interconnections. 192 2.1. Packet/Optical Integration 194 In this use case, an Optical network is used to provide connectivity 195 to some nodes of a Packet network (see Figure 1). 197 +----------------+ 198 | | 199 | Packet/Optical | 200 | Coordinator | 201 | | 202 +---+------+-----+ 203 | | 204 +------------+ | 205 | +-----------+ 206 +------V-----+ | 207 | | +------V-----+ 208 | Packet | | | 209 | Network | | Optical | 210 | Controller | | Network | 211 | | | Controller | 212 +------+-----+ +-------+----+ 213 | | 214 .........V......................... | 215 : Packet Network : | 216 +----+ +----+ | 217 | R1 |= = = = = = = = = = = = = = = =| R2 | | 218 +-+--+ +--+-+ | 219 | : : | | 220 | :................................ : | | 221 | | | 222 | +-----+ | | 223 | ...........| Opt |........... | | 224 | : | C | : | | 225 | : /+--+--+\ : | | 226 | : / | \ : | | 227 | : / | \ : | | 228 | +-----+ / +--+--+ \ +-----+ | | 229 | | Opt |/ | Opt | \| Opt | | | 230 +---| A | | D | | B |---+ | 231 +-----+\ +--+--+ /+-----+ | 232 : \ | / : | 233 : \ | / : | 234 : \ +--+--+ / Optical<---------+ 235 : \| Opt |/ Network: 236 :..........| E |..........: 237 +-----+ 239 Figure 1 - Packet/Optical Integration Use Case 241 Figure 1 as well as Figure 2 below only show a partial view of the 242 packet network connectivity, before additional packet connectivity 243 is provided by the Optical network. 245 It is assumed that the Optical network controller provides to the 246 packet/optical coordinator an abstracted view of the Optical 247 network. A possible abstraction could be to represent the whole 248 optical network as one "virtual node" with "virtual ports" connected 249 to the access links, as shown in Figure 2. 251 It is also assumed that Packet network controller can provide the 252 packet/optical coordinator the information it needs to setup 253 connectivity between packet nodes through the Optical network (e.g., 254 the access links). 256 The path computation request helps the coordinator to know the real 257 connections that can be provided by the optical network. 259 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,. 260 , Packet/Optical Coordinator view , 261 , +----+ , . 262 , | | , 263 , | R2 | , . 264 , +----+ +------------ + /+----+ , 265 , | | | |/-----/ / / , . 266 , | R1 |--O VP1 VP4 O / / , 267 , | |\ | | /----/ / , . 268 , +----+ \| |/ / , 269 , / O VP2 VP5 O / , . 270 , / | | +----+ , 271 , / | | | | , . 272 , / O VP3 VP6 O--| R4 | , 273 , +----+ /-----/|_____________| +----+ , . 274 , | |/ +------------ + , 275 , | R3 | , . 276 , +----+ ,,,,,,,,,,,,,,,,, 277 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,. 278 . Packet Network Controller view +----+ , 279 only packet nodes and packet links | | , . 280 . with access links to the optical network | R2 | , 281 , +----+ /+----+ , . 282 . , | | /-----/ / / , 283 , | R1 |--- / / , . 284 . , +----+\ /----/ / , 285 , / \ / / , . 286 . , / / , 287 , / +----+ , . 288 . , / | | , 289 , / ---| R4 | , . 290 . , +----+ /-----/ +----+ , 291 , | |/ , . 292 . , | R3 | , 293 , +----+ ,,,,,,,,,,,,,,,,,. 294 .,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, , 295 Optical Network Controller view , . 296 . only optical nodes, +--+ , 297 optical links and /|OF| , . 298 . access links from the +--++--+ / , 299 packet network |OA| \ /-----/ / , . 300 . , ---+--+--\ +--+/ / , 301 , \ | \ \-|OE|-------/ , . 302 . , \ | \ /-+--+ , 303 , \+--+ X | , . 305 . , |OB|-/ \ | , 306 , +--+-\ \+--+ , . 307 . , / \ \--|OD|--- , 308 , /-----/ +--+ +--+ , . 309 . , / |OC|/ , 310 , +--+ , . 311 ., ,,,,,,,,,,,,,,,,,, 312 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, , 313 . Actual Physical View +----+ , 314 , +--+ | | , 315 . , /|OF| | R2 | , 316 , +----+ +--++--+ /+----+ , 317 . , | | |OA| \ /-----/ / / , 318 , | R1 |---+--+--\ +--+/ / / , 319 . , +----+\ | \ \-|OE|-------/ / , 320 , / \ | \ /-+--+ / , 321 . , / \+--+ X | / , 322 , / |OB|-/ \ | +----+ , 323 . , / +--+-\ \+--+ | | , 324 , / / \ \--|OD|---| R4 | , 325 . , +----+ /-----/ +--+ +--+ +----+ , 326 , | |/ |OC|/ , 327 . , | R3 | +--+ , 328 , +----+ , 329 .,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 331 Figure 2 - Packet and Optical Topology Abstractions 333 In this use case, the coordinator needs to setup an optimal 334 underlying path for an IP link between R1 and R2. 336 As depicted in Figure 2, the coordinator has only an "abstracted 337 view" of the physical network, and it does not know the feasibility 338 or the cost of the possible optical paths (e.g., VP1-VP4 and VP2- 339 VP5), which depend from the current status of the physical resources 340 within the optical network and on vendor-specific optical 341 attributes. 343 The coordinator can request the underlying Optical domain controller 344 to compute a set of potential optimal paths, taking into account 345 optical constraints. Then, based on its own constraints, policy and 346 knowledge (e.g. cost of the access links), it can choose which one 347 of these potential paths to use to setup the optimal end-to-end path 348 crossing optical network. 350 ............................ 351 : : 352 O VP1 VP4 O 353 cost=10 /:\ /:\ cost=10 354 / : \----------------------/ : \ 355 +----+ / : cost=50 : \ +----+ 356 | |/ : : \| | 357 | R1 | : : | R2 | 358 | |\ : : /| | 359 +----+ \ : /--------------------\ : / +----+ 360 \ : / cost=55 \ : / 361 cost=5 \:/ \:/ cost=5 362 O VP2 VP5 O 363 : : 364 :..........................: 366 Figure 3 - Packet/Optical Path Computation Example 368 For example, in Figure 3, the Coordinator can request the Optical 369 network controller to compute the paths between VP1-VP4 and VP2-VP5 370 and then decide to setup the optimal end-to-end path using the VP2- 371 VP5 Optical path even this is not the optimal path from the Optical 372 domain perspective. 374 Considering the dynamicity of the connectivity constraints of an 375 Optical domain, it is possible that a path computed by the Optical 376 network controller when requested by the Coordinator is no longer 377 valid/available when the Coordinator requests it to be setup up. 378 This is further discussed in section 3.3. 380 2.2. Multi-domain TE Networks 382 In this use case there are two TE domains which are interconnected 383 together by multiple inter-domains links. 385 A possible example could be a multi-domain optical network. 387 +--------------+ 388 | Multi-domain | 389 | Controller | 390 +---+------+---+ 391 | | 392 +------------+ | 393 | +-----------+ 394 +------V-----+ | 395 | | | 396 | TE Domain | +------V-----+ 397 | Controller | | | 398 | 1 | | TE Domain | 399 +------+-----+ | Controller | 400 | | 2 | 401 | +------+-----+ 402 .........V.......... | 403 : : | 404 +-----+ : | 405 | | : .........V.......... 406 | X | : : : 407 | | +-----+ +-----+ : 408 +-----+ | | | | : 409 : | C |------| E | : 410 +-----+ +-----+ /| | | |\ +-----+ +-----+ 411 | | | |/ +-----+ +-----+ \| | | | 412 | A |----| B | : : | G |----| H | 413 | | | |\ : : /| | | | 414 +-----+ +-----+ \+-----+ +-----+/ +-----+ +-----+ 415 : | | | | : 416 : | D |------| F | : 417 : | | | | +-----+ 418 : +-----+ +-----+ | | 419 : : : | Y | 420 : : : | | 421 : Domain 1 : : Domain 2 +-----+ 422 :..................: :.................: 424 Figure 4 - Multi-domain multi-link interconnection 426 In order to setup an end-to-end multi-domain TE path (e.g., between 427 nodes A and H), the multi-domain controller needs to know the 428 feasibility or the cost of the possible TE paths within the two TE 429 domains, which depend from the current status of the physical 430 resources within each TE network. This is more challenging in case 431 of optical networks because the optimal paths depend also on vendor- 432 specific optical attributes (which may be different in the two 433 domains if they are provided by different vendors). 435 In order to setup a multi-domain TE path (e.g., between nodes A and 436 H), the multi-domain controller can request the TE domain 437 controllers to compute a set of intra-domain optimal paths and take 438 decisions based on the information received. For example: 440 o The multi-domain controller asks TE domain controllers to provide 441 set of paths between A-C, A-D, E-H and F-H 443 o TE domain controllers return a set of feasible paths with the 444 associated costs: the path A-C is not part of this set(in optical 445 networks, it is typical to have some paths not being feasible due 446 to optical constraints that are known only by the optical domain 447 controller) 449 o The multi-domain controller will select the path A-D-F-H since it 450 is the only feasible multi-domain path and then request the TE 451 domain controllers to setup the A-D and F-H intra-domain paths 453 o If there are multiple feasible paths, the multi-domain controller 454 can select the optimal path knowing the cost of the intra-domain 455 paths (provided by the TE domain controllers) and the cost of the 456 inter-domain links (known by the multi-domain controller) 458 This approach may have some scalability issues when the number of TE 459 domains is quite big (e.g. 20). 461 In this case, it would be worthwhile using the abstract TE topology 462 information provided by the TE domain controllers to limit the 463 number of potential optimal end-to-end paths and then request path 464 computation to fewer TE domain controllers in order to decide what 465 the optimal path within this limited set is. 467 For more details, see section 3.2.3. 469 2.3. Data center interconnections 471 In these use case, there is a TE domain which is used to provide 472 connectivity between data centers which are connected with the TE 473 domain using access links. 475 +--------------+ 476 | Cloud Network| 477 | Orchestrator | 478 +--------------+ 479 | | | | 480 +-------------+ | | +------------------------+ 481 | | +------------------+ | 482 | +--------V---+ | | 483 | | | | | 484 | | TE Network | | | 485 +------V-----+ | Controller | +------V-----+ | 486 | DC | +------------+ | DC | | 487 | Controller | | | Controller | | 488 +------------+ | +-----+ +------------+ | 489 | ....V...| |........ | | 490 | : | P | : | | 491 .....V..... : /+-----+\ : .....V..... | 492 : : +-----+ / | \ +-----+ : : | 493 : DC1 || : | |/ | \| | : DC2 || : | 494 : ||||----| PE1 | | | PE2 |---- |||| : | 495 : _|||||| : | |\ | /| | : _|||||| : | 496 : : +-----+ \ +-----+ / +-----+ : : | 497 :.........: : \| |/ : :.........: | 498 :.......| PE3 |.......: | 499 | | | 500 +-----+ +---------V--+ 501 .....|..... | DC | 502 : : | Controller | 503 : DC3 || : +------------+ 504 : |||| : | 505 : _|||||| <------------------+ 506 : : 507 :.........: 509 Figure 5 - Data Center Interconnection Use Case 511 In this use case, there is need to transfer data from Data Center 1 512 (DC1) to either DC2 or DC3 (e.g. workload migration). 514 The optimal decision depends both on the cost of the TE path (DC1- 515 DC2 or DC1-DC3) and of the data center resources within DC2 or DC3. 517 The cloud network orchestrator needs to make a decision for optimal 518 connection based on TE Network constraints and data centers 519 resources. It may not be able to make this decision because it has 520 only an abstract view of the TE network (as in use case in 2.1). 522 The cloud network orchestrator can request to the TE network 523 controller to compute the cost of the possible TE paths (e.g., DC1- 524 DC2 and DC1-DC3) and to the DC controller to provide the information 525 it needs about the required data center resources within DC2 and DC3 526 and then it can take the decision about the optimal solution based 527 on this information and its policy. 529 3. Motivations 531 This section provides the motivation for the YANG model defined in 532 this document. 534 Section 3.1 describes the motivation for a YANG model to request 535 path computation. 537 Section 3.2 describes the motivation for a YANG model which 538 complements the TE Topology YANG model defined in [TE-TOPO]. 540 Section 3.3 describes the motivation for a stateless YANG RPC which 541 complements the TE Tunnel YANG model defined in [TE-TUNNEL]. 543 3.1. Motivation for a YANG Model 545 3.1.1. Benefits of common data models 547 The YANG data model for requesting path computation is closely 548 aligned with the YANG data models that provide (abstract) TE 549 topology information, i.e., [TE-TOPO] as well as that are used to 550 configure and manage TE Tunnels, i.e., [TE-TUNNEL]. 552 There are many benefits in aligning the data model used for path 553 computation requests with the YANG data models used for TE topology 554 information and for TE Tunnels configuration and management: 556 o There is no need for an error-prone mapping or correlation of 557 information. 559 o It is possible to use the same endpoint identifiers in path 560 computation requests and in the topology modeling. 562 o The attributes used for path computation constraints are the same 563 as those used when setting up a TE Tunnel. 565 3.1.2. Benefits of a single interface 567 The system integration effort is typically lower if a single, 568 consistent interface is used by controllers, i.e., one data modeling 569 language (i.e., YANG) and a common protocol (e.g., NETCONF or 570 RESTCONF). 572 Practical benefits of using a single, consistent interface include: 574 1. Simple authentication and authorization: The interface between 575 different components has to be secured. If different protocols 576 have different security mechanisms, ensuring a common access 577 control model may result in overhead. For instance, there may be 578 a need to deal with different security mechanisms, e.g., 579 different credentials or keys. This can result in increased 580 integration effort. 582 2. Consistency: Keeping data consistent over multiple different 583 interfaces or protocols is not trivial. For instance, the 584 sequence of actions can matter in certain use cases, or 585 transaction semantics could be desired. While ensuring 586 consistency within one protocol can already be challenging, it is 587 typically cumbersome to achieve that across different protocols. 589 3. Testing: System integration requires comprehensive testing, 590 including corner cases. The more different technologies are 591 involved, the more difficult it is to run comprehensive test 592 cases and ensure proper integration. 594 4. Middle-box friendliness: Provider and consumer of path 595 computation requests may be located in different networks, and 596 middle-boxes such as firewalls, NATs, or load balancers may be 597 deployed. In such environments it is simpler to deploy a single 598 protocol. Also, it may be easier to debug connectivity problems. 600 5. Tooling reuse: Implementers may want to implement path 601 computation requests with tools and libraries that already exist 602 in controllers and/or orchestrators, e.g., leveraging the rapidly 603 growing eco-system for YANG tooling. 605 3.1.3. Extensibility 607 Path computation is only a subset of the typical functionality of a 608 controller. In many use cases, issuing path computation requests 609 comes along with the need to access other functionality on the same 610 system. In addition to obtaining TE topology, for instance also 611 configuration of services (setup/modification/deletion) may be 612 required, as well as: 614 1. Receiving notifications for topology changes as well as 615 integration with fault management 617 2. Performance management such as retrieving monitoring and 618 telemetry data 620 3. Service assurance, e.g., by triggering OAM functionality 622 4. Other fulfilment and provisioning actions beyond tunnels and 623 services, such as changing QoS configurations 625 YANG is a very extensible and flexible data modeling language that 626 can be used for all these use cases. 628 3.2. Interactions with TE Topology 630 The use cases described in section 2 have been described assuming 631 that the topology view exported by each underlying SDN controller to 632 the orchestrator is aggregated using the "virtual node model", 633 defined in [RFC7926]. 635 TE Topology information, e.g., as provided by [TE-TOPO], could in 636 theory be used by an underlying SDN controllers to provide TE 637 information to its client thus allowing a PCE available within its 638 client to perform multi-domain path computation by its own, without 639 requesting path computations to the underlying SDN controllers. 641 In case the client does not implement a PCE function, as discussed 642 in section 1, it could not perform path computation based on TE 643 Topology information and would instead need to request path 644 computation to the underlying controllers to get the information it 645 needs to compute the optimal end-to-end path. 647 This section analyzes the need for a client to request underlying 648 SDN controllers for path computation even in case it implements a 649 PCE functionality, as well as how the TE Topology information and 650 the path computation can be complementary. 652 In nutshell, there is a scalability trade-off between providing all 653 the TE information needed by PCE, when implemented by the client, to 654 take optimal path computation decisions by its own versus sending 655 too many requests to underlying SDN Domain Controllers to compute a 656 set of feasible optimal intra-domain TE paths. 658 3.2.1. TE Topology Aggregation 660 Using the TE Topology model, as defined in [TE-TOPO], the underlying 661 SDN controller can export the whole TE domain as a single abstract 662 TE node with a "detailed connectivity matrix". 664 The concept of a "detailed connectivity matrix" is defined in [TE- 665 TOPO] to provide specific TE attributes (e.g., delay, SRLGs and 666 summary TE metrics) as an extension of the "basic connectivity 667 matrix", which is based on the "connectivity matrix" defined in 668 [RFC7446]. 670 The information provided by the "detailed connectivity matrix" would 671 be equivalent to the information that should be provided by "virtual 672 link model" as defined in [RFC7926]. 674 For example, in the Packet/Optical integration use case, described 675 in section 2.1, the Optical network controller can make the 676 information shown in Figure 3 available to the Coordinator as part 677 of the TE Topology information and the Coordinator could use this 678 information to calculate by its own the optimal path between R1 and 679 R2, without requesting any additional information to the Optical 680 network Controller. 682 However, when designing the amount of information to provide within 683 the "detailed connectivity matrix", there is a tradeoff to be 684 considered between accuracy (i.e., providing "all" the information 685 that might be needed by the PCE available to Orchestrator) and 686 scalability. 688 Figure 6 below shows another example, similar to Figure 3, where 689 there are two possible Optical paths between VP1 and VP4 with 690 different properties (e.g., available bandwidth and cost). 692 ............................ 693 : /--------------------\ : 694 : / cost=65 \ : 695 :/ available-bw=10G \: 696 O VP1 VP4 O 697 cost=10 /:\ /:\ cost=10 698 / : \----------------------/ : \ 699 +----+ / : cost=50 : \ +----+ 700 | |/ : available-bw=2G : \| | 701 | R1 | : : | R2 | 702 | |\ : : /| | 703 +----+ \ : /--------------------\ : / +----+ 704 \ : / cost=55 \ : / 705 cost=5 \:/ available-bw=3G \:/ cost=5 706 O VP2 VP5 O 707 : : 708 :..........................: 710 Figure 6 - Packet/Optical Path Computation Example with multiple 711 choices 713 Reporting all the information, as in Figure 6, using the "detailed 714 connectivity matrix", is quite challenging from a scalability 715 perspective. The amount of this information is not just based on 716 number of end points (which would scale as N-square), but also on 717 many other parameters, including client rate, user 718 constraints/policies for the service, e.g. max latency < N ms, max 719 cost, etc., exclusion policies to route around busy links, min OSNR 720 margin, max preFEC BER etc. All these constraints could be different 721 based on connectivity requirements. 723 Examples of how the "detailed connectivity matrix" can be 724 dimensioned are described in Appendix A. 726 It is also worth noting that the "connectivity matrix" has been 727 originally defined in WSON, [RFC7446], to report the connectivity 728 constrains of a physical node within the WDM network: the 729 information it contains is pretty "static" and therefore, once taken 730 and stored in the TE data base, it can be always being considered 731 valid and up-to-date in path computation request. 733 Using the "basic connectivity matrix" with an abstract node to 734 abstract the information regarding the connectivity constraints of 735 an Optical domain, would make this information more "dynamic" since 736 the connectivity constraints of an Optical domain can change over 737 time because some optical paths that are feasible at a given time 738 may become unfeasible at a later time when e.g., another optical 739 path is established. The information in the "detailed connectivity 740 matrix" is even more dynamic since the establishment of another 741 optical path may change some of the parameters (e.g., delay or 742 available bandwidth) in the "detailed connectivity matrix" while not 743 changing the feasibility of the path. 745 The "connectivity matrix" is sometimes confused with optical reach 746 table that contain multiple (e.g. k-shortest) regen-free reachable 747 paths for every A-Z node combination in the network. Optical reach 748 tables can be calculated offline, utilizing vendor optical design 749 and planning tools, and periodically uploaded to the Controller: 750 these optical path reach tables are fairly static. However, to get 751 the connectivity matrix, between any two sites, either a regen free 752 path can be used, if one is available, or multiple regen free paths 753 are concatenated to get from src to dest, which can be a very large 754 combination. Additionally, when the optical path within optical 755 domain needs to be computed, it can result in different paths based 756 on input objective, constraints, and network conditions. In summary, 757 even though "optical reachability table" is fairly static, which 758 regen free paths to build the connectivity matrix between any source 759 and destination is very dynamic, and is done using very 760 sophisticated routing algorithms. 762 There is therefore the need to keep the information in the "detailed 763 connectivity matrix" updated which means that there another tradeoff 764 between the accuracy (i.e., providing "all" the information that 765 might be needed by the client's PCE) and having up-to-date 766 information. The more the information is provided and the longer it 767 takes to keep it up-to-date which increases the likelihood that the 768 client's PCE computes paths using not updated information. 770 It seems therefore quite challenging to have a "detailed 771 connectivity matrix" that provides accurate, scalable and updated 772 information to allow the client's PCE to take optimal decisions by 773 its own. 775 Instead, if the information in the "detailed connectivity matrix" is 776 not complete/accurate, we can have the following drawbacks 777 considering for example the case in Figure 6: 779 o If only the VP1-VP4 path with available bandwidth of 2 Gb/s and 780 cost 50 is reported, the client's PCE will fail to compute a 5 781 Gb/s path between routers R1 and R2, although this would be 782 feasible; 784 o If only the VP1-VP4 path with available bandwidth of 10 Gb/s and 785 cost 60 is reported, the client's PCE will compute, as optimal, 786 the 1 Gb/s path between R1 and R2 going through the VP2-VP5 path 787 within the Optical domain while the optimal path would actually 788 be the one going thought the VP1-VP4 sub-path (with cost 50) 789 within the Optical domain. 791 Using the approach proposed in this document, the client, when it 792 needs to setup an end-to-end path, it can request the Optical domain 793 controller to compute a set of optimal paths (e.g., for VP1-VP4 and 794 VP2-VP5) and take decisions based on the information received: 796 o When setting up a 5 Gb/s path between routers R1 and R2, the 797 Optical domain controller may report only the VP1-VP4 path as the 798 only feasible path: the Orchestrator can successfully setup the 799 end-to-end path passing though this Optical path; 801 o When setting up a 1 Gb/s path between routers R1 and R2, the 802 Optical domain controller (knowing that the path requires only 1 803 Gb/s) can report both the VP1-VP4 path, with cost 50, and the 804 VP2-VP5 path, with cost 65. The Orchestrator can then compute the 805 optimal path which is passing thought the VP1-VP4 sub-path (with 806 cost 50) within the Optical domain. 808 3.2.2. TE Topology Abstraction 810 Using the TE Topology model, as defined in [TE-TOPO], the underlying 811 SDN controller can export an abstract TE Topology, composed by a set 812 of TE nodes and TE links, representing the abstract view of the 813 topology controlled by each domain controller. 815 Considering the example in Figure 4, the TE domain controller 1 can 816 export a TE Topology encompassing the TE nodes A, B, C and D and the 817 TE Link interconnecting them. In a similar way, TE domain controller 818 2 can export a TE Topology encompassing the TE nodes E, F, G and H 819 and the TE Link interconnecting them. 821 In this example, for simplicity reasons, each abstract TE node maps 822 with each physical node, but this is not necessary. 824 In order to setup a multi-domain TE path (e.g., between nodes A and 825 H), the multi-domain controller can compute by its own an optimal 826 end-to-end path based on the abstract TE topology information 827 provided by the domain controllers. For example: 829 o Multi-domain controller's PCE, based on its own information, can 830 compute the optimal multi-domain path being A-B-C-E-G-H, and then 831 request the TE domain controllers to setup the A-B-C and E-G-H 832 intra-domain paths 834 o But, during path setup, the domain controller may find out that 835 A-B-C intra-domain path is not feasible (as discussed in section 836 2.2, in optical networks it is typical to have some paths not 837 being feasible due to optical constraints that are known only by 838 the optical domain controller), while only the path A-B-D is 839 feasible 841 o So what the multi-domain controller computed is not good and need 842 to re-start the path computation from scratch 844 As discussed in section 3.2.1, providing more extensive abstract 845 information from the TE domain controllers to the multi-domain 846 controller may lead to scalability problems. 848 In a sense this is similar to the problem of routing and wavelength 849 assignment within an Optical domain. It is possible to do first 850 routing (step 1) and then wavelength assignment (step 2), but the 851 chances of ending up with a good path is low. Alternatively, it is 852 possible to do combined routing and wavelength assignment, which is 853 known to be a more optimal and effective way for Optical path setup. 854 Similarly, it is possible to first compute an abstract end-to-end 855 path within the multi-domain Orchestrator (step 1) and then compute 856 an intra-domain path within each Optical domain (step 2), but there 857 are more chances not to find a path or to get a suboptimal path that 858 performing per-domain path computation and then stitch them. 860 3.2.3. Complementary use of TE topology and path computation 862 As discussed in section 2.2, there are some scalability issues with 863 path computation requests in a multi-domain TE network with many TE 864 domains, in terms of the number of requests to send to the TE domain 865 controllers. It would therefore be worthwhile using the TE topology 866 information provided by the domain controllers to limit the number 867 of requests. 869 An example can be described considering the multi-domain abstract 870 topology shown in Figure 7. In this example, an end-to-end TE path 871 between domains A and F needs to be setup. The transit domain should 872 be selected between domains B, C, D and E. 874 .........B......... 875 : _ _ _ _ _ _ _ _ : 876 :/ \: 877 +---O NOT FEASIBLE O---+ 878 cost=5| : : | 879 ......A...... | :.................: | ......F...... 880 : : | | : : 881 : O-----+ .........C......... +-----O : 882 : : : /-------------\ : : : 883 : : :/ \: : : 884 : cost<=20 O---------O cost <= 30 O---------O cost<=20 : 885 : /: cost=5 : : cost=5 :\ : 886 : /------/ : :.................: : \------\ : 887 : / : : \ : 888 :/ cost<=25 : .........D......... : cost<=25 \: 889 O-----------O-------+ : /-------------\ : +-------O-----------O 890 :\ : cost=5| :/ \: |cost=5 : /: 891 : \ : +-O cost <= 30 O-+ : / : 892 : \------\ : : : : /------/ : 893 : cost>=30 \: :.................: :/ cost>=30 : 894 : O-----+ +-----O : 895 :...........: | .........E......... | :...........: 896 | : /-------------\ : | 897 cost=5| :/ \: |cost=5 898 +---O cost >= 30 O---+ 899 : : 900 :.................: 902 Figure 7 - Multi-domain with many domains (Topology information) 904 The actual cost of each intra-domain path is not known a priori from 905 the abstract topology information. The Multi-domain controller only 906 knows, from the TE topology provided by the underlying domain 907 controllers, the feasibility of some intra-domain paths and some 908 upper-bound and/or lower-bound cost information. With this 909 information, together with the cost of inter-domain links, the 910 Multi-domain controller can understand by its own that: 912 o Domain B cannot be selected as the path connecting domains A and 913 E is not feasible; 915 o Domain E cannot be selected as a transit domain since it is know 916 from the abstract topology information provided by domain 917 controllers that the cost of the multi-domain path A-E-F (which 918 is 100, in the best case) will be always be higher than the cost 919 of the multi-domain paths A-D-F (which is 90, in the worst case) 920 and A-E-F (which is 80, in the worst case) 922 Therefore, the Multi-domain controller can understand by its own 923 that the optimal multi-domain path could be either A-D-F or A-E-F 924 but it cannot known which one of the two possible option actually 925 provides the optimal end-to-end path. 927 The Multi-domain controller can therefore request path computation 928 only to the TE domain controllers A, D, E and F (and not to all the 929 possible TE domain controllers). 931 .........B......... 932 : : 933 +---O O---+ 934 ......A...... | :.................: | ......F...... 935 : : | | : : 936 : O-----+ .........C......... +-----O : 937 : : : /-------------\ : : : 938 : : :/ \: : : 939 : cost=15 O---------O cost = 25 O---------O cost=10 : 940 : /: cost=5 : : cost=5 :\ : 941 : /------/ : :.................: : \------\ : 942 : / : : \ : 943 :/ cost=10 : .........D......... : cost=15 \: 944 O-----------O-------+ : /-------------\ : +-------O-----------O 945 : : cost=5| :/ \: |cost=5 : : 946 : : +-O cost = 15 O-+ : : 947 : : : : : : 948 : : :.................: : : 949 : O-----+ +-----O : 950 :...........: | .........E......... | :...........: 951 | : : | 952 +---O O---+ 953 :.................: 955 Figure 8 - Multi-domain with many domains (Path Computation 956 information) 958 Based on these requests, the Multi-domain controller can know the 959 actual cost of each intra-domain paths which belongs to potential 960 optimal end-to-end paths, as shown in Figure 8, and then compute the 961 optimal end-to-end path (e.g., A-D-F, having total cost of 50, 962 instead of A-C-F having a total cost of 70). 964 3.3. Stateless and Stateful Path Computation 966 The TE Tunnel YANG model, defined in [TE-TUNNEL], can support the 967 need to request path computation. 969 It is possible to request path computation by configuring a 970 "compute-only" TE tunnel and retrieving the computed path(s) in the 971 LSP(s) Record-Route Object (RRO) list as described in section 3.3.1 972 of [TE-TUNNEL]. 974 This is a stateful solution since the state of each created 975 "compute-only" TE tunnel needs to be maintained and updated, when 976 underlying network conditions change. 978 It is very useful to provide options for both stateless and stateful 979 path computation mechanisms. It is suggested to use stateless 980 mechanisms as much as possible and to rely on stateful path 981 computation when really needed. 983 Stateless RPC allows requesting path computation using a simple 984 atomic operation and it is the natural option/choice, especially 985 with stateless PCE. The stateless path computation solution assumes 986 that the underlying SDN controller (e.g., a PNC) will compute a path 987 twice during the process to setup an LSP: at time T1, when its 988 client (e.g., an MDSC) sends a path computation RPC request to it, 989 and later, at time T2, when the same client (MDSC) creates a 990 te-tunnel requesting the setup of the LSP. The underlying assumption 991 is that, if network conditions have not changed, the same path that 992 has been computed at time T1 is also computed at time T2 by the 993 underlying SDN controller (e.g. PNC) and therefore the path that is 994 setup at time T2 is exactly the same path that has been computed at 995 time T1. 997 Since the operation is stateless, there is no guarantee that the 998 returned path would still be available when path setup is requested: 999 this does not cause major issues in case the time between path 1000 computation and path setup is short (especially if compared with the 1001 time that would be needed to update the information of a very 1002 detailed connectivity matrix). 1004 In most of the cases, there is even no need to guarantee that the 1005 path that has been setup is the exactly same as the path that has 1006 been returned by path computation, especially if it has the same or 1007 even better metrics. Depending on the abstraction level applied by 1008 the server, the client may also not know the actual computed path. 1010 The most important requirement is that the required global 1011 objectives (e.g., multi-domain path metrics and constraints) are 1012 met. For this reason a path verification phase is necessary to 1013 verify that the actual path that has been setup meets the global 1014 objectives (for example in a multi-domain network, the resulting 1015 end-to-end path meets the required end-to-end metrics and 1016 constraints). 1018 In most of the cases, even if the setup path is not exactly the same 1019 as the path returned by path computation, its metrics and 1020 constraints are "good enough" (the path verification passes 1021 successfully). In the few corner cases where the path verification 1022 fails, it is possible repeat the whole process (path computation, 1023 path setup and path verification). 1025 In case the stateless solution is not sufficient and it would be the 1026 need to setup at T2 exactly the same path computed at T1 a stateful 1027 solution, based on "compute-only" TE tunnel, could be used to get 1028 notifications in case the computed path has been changed. In this 1029 case at time T1, the client (MDSC) creates a te-tunnel in a 1030 compute-only mode in the config DS and later, at time T2, changes 1031 the configuration of that te-tunnel (not to be any more in a 1032 compute-only mode) to trigger the setup of the LSP. 1034 It is worth noting that also the stateful solution, although 1035 increasing the likelihood that the computed path is available at 1036 path setup, does not guaranteed that because notifications may not 1037 be reliable or delivered on time. Path verification is needed also 1038 when stateful path computation is used. 1040 The stateful path computation has also the following drawbacks: 1042 o Several messages required for any path computation 1044 o Requires persistent storage in the provider controller 1046 o Need for garbage collection for stranded paths 1047 o Process burden to detect changes on the computed paths in order 1048 to provide notifications update 1050 3.3.1. Temporary reporting of the computed path state 1052 This section describes an optional extension to the stateless 1053 behavior where the underlying SDN controller, after having received 1054 a path computation RPC request, maintains some "temporary 1055 state" associated with the computed path, allowing the client to 1056 request the setup of exactly that path, if still available. 1058 This is similar to the stateful solution but, to avoid the drawbacks 1059 of the stateful approach, is leveraging the path computation RPC and 1060 the separation between configuration and operational DS, as defined 1061 in the NMDA architecture [RFC8342]. 1063 The underlying SDN controller, after having computed a path, as 1064 requested by a path computation RPC, also creates a te-tunnel 1065 instance within the operational DS, to store that computed path. 1066 This would be similar to the stateful solution with the only 1067 difference that there is no associated te-tunnel instance within the 1068 running DS. 1070 Since underlying SDN controller stores in the operational DS the 1071 computed path based on an abstract topology it exposes, it also 1072 remembers, internally, which is the actual native path (physical 1073 path), within its native topology (physical topology), associated 1074 with that compute-only te-tunnel instance. 1076 Afterwards, the client (e.g., MDSC) can request to setup that 1077 specific path by creating a te-tunnel instance (not in compute-only 1078 mode) in the running DS using the same tunnel-name of 1079 the existing te-tunnel in the operational datastore: this will 1080 trigger the underlying SDN controller to setup that path, if still 1081 available. 1083 There are still cases where the path being setup is not exactly the 1084 same as the path that has been computed: 1086 o When the tunnel is configured with path constraints which are not 1087 compatible with the computed path 1089 o When the tunnel setup is requested after the resources of the 1090 computed path are no longer available 1092 o When the tunnel setup is requested after the computed path is no 1093 longer known (e.g. due to a server reboot) by the underlying SDN 1094 controller 1096 In all these cases, the underlying SDN controller should compute and 1097 setup a new path. 1099 Therefore the "path verification" phase, as described in section 3.3 1100 above, is still needed to check that the path that has been setup is 1101 still "good enough". 1103 Since this new approach is not completely stateless, garbage 1104 collection is implemented using a timeout that, when it expires, 1105 triggers the removal of the computed path from the operational DS. 1106 This operation is fully controlled by the underlying SDN controller 1107 without the need for any action to be taken by the client that is 1108 not able to act on the operational datastore. The default value of 1109 this timeout is 10 minutes but a different value may be configured 1110 by the client. 1112 In addition, it is possible for the client to tag each path 1113 computation requests with a transaction-id allowing for a faster 1114 removal of all the paths associated with a transaction-id, without 1115 waiting for their timers to expire. 1117 The underlying SDN controller can remove from the operational DS all 1118 the paths computed with a given transaction-id which have not been 1119 setup either when it receives a Path Delete RPC request for that 1120 transaction-id or, automatically, right after the setup up of a path 1121 that have been previously computed with that transaction-id. 1123 This possibility is useful when multiple paths are computed but, at 1124 most, only one is setup (e.g., in multi-domain path computation 1125 scenario scenarios). After the selected path has been setup (e.g, in 1126 one domain during multi-domain path setup), all the other 1127 alternative computed paths can be automatically deleted by the 1128 underlying SDN controller (since no longer needed). The client can 1129 also request, using the Path Delete RPC request, the underlying SDN 1130 controller to remove all the computed paths, if none of them is 1131 going to be setup (e.g., in a transit domain not being selected by 1132 multi-domain path computation and so not being automatically 1133 deleted). 1135 This approach is complimentary and not alternative to the timer 1136 which is always needed to avoid stranded computed paths being stored 1137 in the operational DS when no path is setup and no explicit delete 1138 RPC is received. 1140 4. Path Computation and Optimization for multiple paths 1142 There are use cases, where it is advantageous to request path 1143 computation for a set of paths, through a network or through a 1144 network domain, using a single request [RFC5440]. 1146 In this case, sending a single request for multiple path 1147 computations, instead of sending multiple requests for each path 1148 computation, would reduce the protocol overhead and it would consume 1149 less resources (e.g., threads in the client and server). 1151 In the context of a typical multi-domain TE network, there could 1152 multiple choices for the ingress/egress points of a domain and the 1153 Multi-domain controller needs to request path computation between 1154 all the ingress/egress pairs to select the best pair. For example, 1155 in the example of section 2.2, the Multi-domain controller needs to 1156 request the TE network controller 1 to compute the A-C and the A-D 1157 paths and to the TE network controller 2 to compute the E-H and the 1158 F-H paths. 1160 It is also possible that the Multi-domain controller receives a 1161 request to setup a group of multiple end to end connections. The 1162 multi-domain controller needs to request each TE domain controller 1163 to compute multiple paths, one (or more) for each end to end 1164 connection. 1166 There are also scenarios where it can be needed to request path 1167 computation for a set of paths in a synchronized fashion. 1169 One example could be computing multiple diverse paths. Computing a 1170 set of diverse paths in a not-synchronized fashion, leads to the 1171 possibility of not being able to satisfy the diversity requirement. 1172 In this case, it is preferable to compute a sub-optimal primary path 1173 for which a diversely routed secondary path exists. 1175 There are also scenarios where it is needed to request optimizing a 1176 set of paths using objective functions that apply to the whole set 1177 of paths, see [RFC5541], e.g. to minimize the sum of the costs of 1178 all the computed paths in the set. 1180 5. YANG Model for requesting Path Computation 1182 This document define a YANG stateless RPC to request path 1183 computation as an "augmentation" of tunnel-rpc, defined in [TE- 1184 TUNNEL]. This model provides the RPC input attributes that are 1185 needed to request path computation and the RPC output attributes 1186 that are needed to report the computed paths. 1188 augment /te:tunnels-rpc/te:input/te:tunnel-info: 1189 +---- path-request* [request-id] 1190 | +---- request-id uint32 1191 ........... 1193 +--ro response* [response-id] 1194 +--ro response-id uint32 1195 +--ro (response-type)? 1196 +--:(no-path-case) 1197 | +--ro no-path! 1198 +--:(path-case) 1199 +--ro computed-path 1200 ........... 1202 This model extensively re-uses the grouping defined in [TE-TUNNEL] 1203 to ensure maximal syntax and semantics commonality. 1205 5.1. Synchronization of multiple path computation requests 1207 The YANG model permits to synchronize a set of multiple path 1208 requests (identified by specific request-id) all related to a "svec" 1209 container emulating the syntax of "SVEC" PCEP object [RFC5440]. 1211 +---- synchronization* [synchronization-id] 1212 +---- synchronization-id uint32 1213 +---- svec 1214 | +---- relaxable? boolean 1215 | +---- disjointness? te-path-disjointness 1216 | +---- request-id-number* uint32 1217 +---- svec-constraints 1218 | +---- path-metric-bound* [metric-type] 1219 | +---- metric-type identityref 1220 | +---- upper-bound? uint64 1221 +---- path-srlgs-lists 1222 | +---- path-srlgs-list* [usage] 1223 | +---- usage identityref 1224 | +---- values* srlg 1225 +---- path-srlgs-names 1226 | +---- path-srlgs-name* [usage] 1227 | +---- usage identityref 1228 | +---- names* string 1229 +---- exclude-objects 1230 ........... 1231 +---- optimizations 1232 +---- (algorithm)? 1233 +--:(metric) {te-types:path-optimization-metric}? 1234 | +---- optimization-metric* [metric-type] 1235 | +---- metric-type identityref 1236 | +---- weight? uint8 1237 +--:(objective-function) 1238 {te-types:path-optimization-objective- 1239 function}? 1240 +---- objective-function 1241 +---- objective-function-type? identityref 1243 The model, in addition to the metric types, defined in [TE-TUNNEL], 1244 which can be applied to each individual path request, defines 1245 additional specific metrics types that apply to a set of 1246 synchronized requests, as referenced in [RFC5541]. 1248 identity svec-metric-type { 1249 description 1250 "Base identity for svec metric type"; 1251 } 1253 identity svec-metric-cumul-te { 1254 base svec-metric-type; 1255 description 1256 "TE cumulative path metric"; 1257 } 1259 identity svec-metric-cumul-igp { 1260 base svec-metric-type; 1261 description 1262 "IGP cumulative path metric"; 1263 } 1265 identity svec-metric-cumul-hop { 1266 base svec-metric-type; 1267 description 1268 "Hop cumulative path metric"; 1269 } 1271 identity svec-metric-aggregate-bandwidth-consumption { 1272 base svec-metric-type; 1273 description 1274 "Cumulative bandwith consumption of the set of 1275 synchronized paths"; 1276 } 1278 identity svec-metric-load-of-the-most-loaded-link { 1279 base svec-metric-type; 1280 description 1281 "Load of the most loaded link"; 1282 } 1284 5.2. Returned metric values 1286 This YANG model provides a way to return the values of the metrics 1287 computed by the path computation in the output of RPC, together with 1288 other important information (e.g. srlg, affinities, explicit route), 1289 emulating the syntax of the "C" flag of the "METRIC" PCEP object 1290 [RFC5440]: 1292 augment /te:tunnels-rpc/te:output/te:result: 1293 +--ro response* [response-id] 1294 +--ro response-id uint32 1295 +--ro (response-type)? 1296 +--:(no-path-case) 1297 | +--ro no-path! 1298 +--:(path-case) 1299 +--ro computed-path 1300 +--ro path-properties 1301 | +--ro path-metric* [metric-type] 1302 | | +--ro metric-type identityref 1303 | | +--ro accumulative-value? uint64 1304 | +--ro path-affinities-values 1305 | | +--ro path-affinities-value* [usage] 1306 | | +--ro usage identityref 1307 | | +--ro value? admin-groups 1308 | +--ro path-affinity-names 1309 | | +--ro path-affinity-name* [usage] 1310 | | +--ro usage identityref 1311 | | +--ro affinity-name* [name] 1312 | | +--ro name string 1313 | +--ro path-srlgs-lists 1314 | | +--ro path-srlgs-list* [usage] 1315 | | +--ro usage identityref 1316 | | +--ro values* srlg 1317 | +--ro path-srlgs-names 1318 | | +--ro path-srlgs-name* [usage] 1319 | | +--ro usage identityref 1320 | | +--ro names* string 1321 | +--ro path-route-objects 1322 ........... 1324 It also allows to request in the input of RPC which information 1325 (metrics, srlg and/or affinities) should be returned: 1327 augment /te:tunnels-rpc/te:input/te:tunnel-info: 1328 +---- path-request* [request-id] 1329 | +---- request-id uint32 1330 ........... 1331 | +---- requested-metrics* [metric-type] 1332 | +---- return-srlgs? boolean 1333 | +---- return-affinities? boolean 1334 ........... 1336 This feature is essential for using a stateless path computation in 1337 a multi-domain TE network as described in section 2.2. In this case, 1338 the metrics returned by a path computation requested to a given TE 1339 network controller must be used by the client to compute the best 1340 end-to-end path. If they are missing the client cannot compare 1341 different paths calculated by the TE network controllers and choose 1342 the best one for the optimal e2e path. 1344 6. YANG model for stateless TE path computation 1346 6.1. YANG Tree 1348 Figure 9 below shows the tree diagram of the YANG model defined in 1349 module ietf-te-path-computation.yang. 1351 module: ietf-te-path-computation 1352 augment /te:tunnels-rpc/te:input/te:tunnel-info: 1353 +---- path-request* [request-id] 1354 | +---- request-id uint32 1355 | +---- encoding? identityref 1356 | +---- switching-type? identityref 1357 | +---- source? inet:ip-address 1358 | +---- destination? inet:ip-address 1359 | +---- src-tp-id? binary 1360 | +---- dst-tp-id? binary 1361 | +---- bidirectional? boolean 1362 | +---- te-topology-identifier 1363 | | +---- provider-id? te-global-id 1364 | | +---- client-id? te-global-id 1365 | | +---- topology-id? te-topology-id 1366 | +---- explicit-route-objects-always 1367 | | +---- route-object-exclude-always* [index] 1368 | | | +---- index uint32 1369 | | | +---- (type)? 1370 | | | +--:(numbered-node-hop) 1371 | | | | +---- numbered-node-hop 1372 | | | | +---- node-id te-node-id 1373 | | | | +---- hop-type? te-hop-type 1374 | | | +--:(numbered-link-hop) 1375 | | | | +---- numbered-link-hop 1376 | | | | +---- link-tp-id te-tp-id 1377 | | | | +---- hop-type? te-hop-type 1378 | | | | +---- direction? te-link-direction 1379 | | | +--:(unnumbered-link-hop) 1380 | | | | +---- unnumbered-link-hop 1381 | | | | +---- link-tp-id te-tp-id 1382 | | | | +---- node-id te-node-id 1383 | | | | +---- hop-type? te-hop-type 1384 | | | | +---- direction? te-link-direction 1385 | | | +--:(as-number) 1386 | | | | +---- as-number-hop 1387 | | | | +---- as-number inet:as-number 1388 | | | | +---- hop-type? te-hop-type 1389 | | | +--:(label) 1390 | | | +---- label-hop 1391 | | | +---- te-label 1392 | | | +---- (technology)? 1393 | | | | +--:(generic) 1394 | | | | +---- generic? 1395 | | | | rt-types:generalized-label 1396 | | | +---- direction? te-label-direction 1397 | | +---- route-object-include-exclude* [index] 1398 | | +---- explicit-route-usage? identityref 1399 | | +---- index uint32 1400 | | +---- (type)? 1401 | | +--:(numbered-node-hop) 1402 | | | +---- numbered-node-hop 1403 | | | +---- node-id te-node-id 1404 | | | +---- hop-type? te-hop-type 1405 | | +--:(numbered-link-hop) 1406 | | | +---- numbered-link-hop 1407 | | | +---- link-tp-id te-tp-id 1408 | | | +---- hop-type? te-hop-type 1409 | | | +---- direction? te-link-direction 1410 | | +--:(unnumbered-link-hop) 1411 | | | +---- unnumbered-link-hop 1412 | | | +---- link-tp-id te-tp-id 1413 | | | +---- node-id te-node-id 1414 | | | +---- hop-type? te-hop-type 1415 | | | +---- direction? te-link-direction 1416 | | +--:(as-number) 1417 | | | +---- as-number-hop 1418 | | | +---- as-number inet:as-number 1419 | | | +---- hop-type? te-hop-type 1420 | | +--:(label) 1421 | | | +---- label-hop 1422 | | | +---- te-label 1423 | | | +---- (technology)? 1424 | | | | +--:(generic) 1425 | | | | +---- generic? 1426 | | | | rt-types:generalized-label 1427 | | | +---- direction? te-label-direction 1428 | | +--:(srlg) 1429 | | +---- srlg 1430 | | +---- srlg? uint32 1431 | +---- path-constraints 1432 | | +---- te-bandwidth 1433 | | | +---- (technology)? 1434 | | | +--:(generic) 1435 | | | +---- generic? te-bandwidth 1436 | | +---- link-protection? identityref 1437 | | +---- setup-priority? uint8 1438 | | +---- hold-priority? uint8 1439 | | +---- signaling-type? identityref 1440 | | +---- path-metric-bounds 1441 | | | +---- path-metric-bound* [metric-type] 1442 | | | +---- metric-type identityref 1443 | | | +---- upper-bound? uint64 1444 | | +---- path-affinities-values 1445 | | | +---- path-affinities-value* [usage] 1446 | | | +---- usage identityref 1447 | | | +---- value? admin-groups 1448 | | +---- path-affinity-names 1449 | | | +---- path-affinity-name* [usage] 1450 | | | +---- usage identityref 1451 | | | +---- affinity-name* [name] 1452 | | | +---- name string 1453 | | +---- path-srlgs-lists 1454 | | | +---- path-srlgs-list* [usage] 1455 | | | +---- usage identityref 1456 | | | +---- values* srlg 1457 | | +---- path-srlgs-names 1458 | | | +---- path-srlgs-name* [usage] 1459 | | | +---- usage identityref 1460 | | | +---- names* string 1461 | | +---- disjointness? te-path-disjointness 1462 | +---- optimizations 1463 | | +---- (algorithm)? 1464 | | +--:(metric) {path-optimization-metric}? 1465 | | | +---- optimization-metric* [metric-type] 1466 | | | | +---- metric-type 1467 identityref 1468 | | | | +---- weight? uint8 1469 | | | | +---- explicit-route-exclude-objects 1470 | | | | | +---- route-object-exclude-object* [index] 1471 | | | | | +---- index uint32 1472 | | | | | +---- (type)? 1473 | | | | | +--:(numbered-node-hop) 1474 | | | | | | +---- numbered-node-hop 1475 | | | | | | +---- node-id te-node-id 1476 | | | | | | +---- hop-type? te-hop-type 1477 | | | | | +--:(numbered-link-hop) 1478 | | | | | | +---- numbered-link-hop 1479 | | | | | | +---- link-tp-id te-tp-id 1480 | | | | | | +---- hop-type? te-hop-type 1481 | | | | | | +---- direction? te-link- 1482 direction 1483 | | | | | +--:(unnumbered-link-hop) 1484 | | | | | | +---- unnumbered-link-hop 1485 | | | | | | +---- link-tp-id te-tp-id 1486 | | | | | | +---- node-id te-node-id 1487 | | | | | | +---- hop-type? te-hop-type 1488 | | | | | | +---- direction? te-link- 1489 direction 1490 | | | | | +--:(as-number) 1491 | | | | | | +---- as-number-hop 1492 | | | | | | +---- as-number inet:as-number 1493 | | | | | | +---- hop-type? te-hop-type 1494 | | | | | +--:(label) 1495 | | | | | | +---- label-hop 1496 | | | | | | +---- te-label 1497 | | | | | | +---- (technology)? 1498 | | | | | | | +--:(generic) 1499 | | | | | | | +---- generic? 1500 | | | | | | | rt- 1501 types:generalized-label 1502 | | | | | | +---- direction? 1503 | | | | | | te-label-direction 1504 | | | | | +--:(srlg) 1505 | | | | | +---- srlg 1506 | | | | | +---- srlg? uint32 1507 | | | | +---- explicit-route-include-objects 1508 | | | | +---- route-object-include-object* [index] 1509 | | | | +---- index uint32 1510 | | | | +---- (type)? 1511 | | | | +--:(numbered-node-hop) 1512 | | | | | +---- numbered-node-hop 1513 | | | | | +---- node-id te-node-id 1514 | | | | | +---- hop-type? te-hop-type 1515 | | | | +--:(numbered-link-hop) 1516 | | | | | +---- numbered-link-hop 1517 | | | | | +---- link-tp-id te-tp-id 1518 | | | | | +---- hop-type? te-hop-type 1519 | | | | | +---- direction? te-link- 1520 direction 1521 | | | | +--:(unnumbered-link-hop) 1522 | | | | | +---- unnumbered-link-hop 1523 | | | | | +---- link-tp-id te-tp-id 1524 | | | | | +---- node-id te-node-id 1525 | | | | | +---- hop-type? te-hop-type 1526 | | | | | +---- direction? te-link- 1527 direction 1528 | | | | +--:(as-number) 1529 | | | | | +---- as-number-hop 1530 | | | | | +---- as-number inet:as-number 1531 | | | | | +---- hop-type? te-hop-type 1532 | | | | +--:(label) 1533 | | | | +---- label-hop 1534 | | | | +---- te-label 1535 | | | | +---- (technology)? 1536 | | | | | +--:(generic) 1537 | | | | | +---- generic? 1538 | | | | | rt- 1539 types:generalized-label 1540 | | | | +---- direction? 1541 | | | | te-label-direction 1542 | | | +---- tiebreakers 1543 | | | +---- tiebreaker* [tiebreaker-type] 1544 | | | +---- tiebreaker-type identityref 1545 | | +--:(objective-function) 1546 | | {path-optimization-objective-function}? 1547 | | +---- objective-function 1548 | | +---- objective-function-type? identityref 1549 | +---- path-in-segment! 1550 | | +---- label-restrictions 1551 | | +---- label-restriction* [index] 1552 | | +---- restriction? enumeration 1553 | | +---- index uint32 1554 | | +---- label-start 1555 | | | +---- te-label 1556 | | | +---- (technology)? 1557 | | | | +--:(generic) 1558 | | | | +---- generic? rt-types:generalized- 1559 label 1560 | | | +---- direction? te-label-direction 1561 | | +---- label-end 1562 | | | +---- te-label 1563 | | | +---- (technology)? 1564 | | | | +--:(generic) 1565 | | | | +---- generic? rt-types:generalized- 1566 label 1567 | | | +---- direction? te-label-direction 1568 | | +---- label-step 1569 | | | +---- (technology)? 1570 | | | +--:(generic) 1571 | | | +---- generic? int32 1572 | | +---- range-bitmap? yang:hex-string 1573 | +---- path-out-segment! 1574 | | +---- label-restrictions 1575 | | +---- label-restriction* [index] 1576 | | +---- restriction? enumeration 1577 | | +---- index uint32 1578 | | +---- label-start 1579 | | | +---- te-label 1580 | | | +---- (technology)? 1581 | | | | +--:(generic) 1582 | | | | +---- generic? rt-types:generalized- 1583 label 1584 | | | +---- direction? te-label-direction 1585 | | +---- label-end 1586 | | | +---- te-label 1587 | | | +---- (technology)? 1588 | | | | +--:(generic) 1589 | | | | +---- generic? rt-types:generalized- 1590 label 1591 | | | +---- direction? te-label-direction 1592 | | +---- label-step 1593 | | | +---- (technology)? 1594 | | | +--:(generic) 1595 | | | +---- generic? int32 1596 | | +---- range-bitmap? yang:hex-string 1597 | +---- requested-metrics* [metric-type] 1598 | | +---- metric-type identityref 1599 | +---- return-srlgs? boolean 1600 | +---- return-affinities? boolean 1601 | +---- requested-state! 1602 | +---- timer? uint16 1603 | +---- transaction-id? string 1604 | +---- tunnel-name? string 1605 | +---- (path)? 1606 | +--:(primary) 1607 | | +---- primary-path-name? string 1608 | +--:(secondary) 1609 | +---- secondary-path-name? string 1610 +---- synchronization* [synchronization-id] 1611 +---- synchronization-id uint32 1612 +---- svec 1613 | +---- relaxable? boolean 1614 | +---- disjointness? te-path-disjointness 1615 | +---- request-id-number* uint32 1616 +---- svec-constraints 1617 | +---- path-metric-bound* [metric-type] 1618 | +---- metric-type identityref 1619 | +---- upper-bound? uint64 1620 +---- path-srlgs-lists 1621 | +---- path-srlgs-list* [usage] 1622 | +---- usage identityref 1623 | +---- values* srlg 1624 +---- path-srlgs-names 1625 | +---- path-srlgs-name* [usage] 1626 | +---- usage identityref 1627 | +---- names* string 1628 +---- exclude-objects 1629 | +---- excludes* [index] 1630 | +---- index uint32 1631 | +---- (type)? 1632 | +--:(numbered-node-hop) 1633 | | +---- numbered-node-hop 1634 | | +---- node-id te-node-id 1635 | | +---- hop-type? te-hop-type 1636 | +--:(numbered-link-hop) 1637 | | +---- numbered-link-hop 1638 | | +---- link-tp-id te-tp-id 1639 | | +---- hop-type? te-hop-type 1640 | | +---- direction? te-link-direction 1641 | +--:(unnumbered-link-hop) 1642 | | +---- unnumbered-link-hop 1643 | | +---- link-tp-id te-tp-id 1644 | | +---- node-id te-node-id 1645 | | +---- hop-type? te-hop-type 1646 | | +---- direction? te-link-direction 1647 | +--:(as-number) 1648 | | +---- as-number-hop 1649 | | +---- as-number inet:as-number 1650 | | +---- hop-type? te-hop-type 1651 | +--:(label) 1652 | +---- label-hop 1653 | +---- te-label 1654 | +---- (technology)? 1655 | | +--:(generic) 1656 | | +---- generic? 1657 | | rt-types:generalized-label 1658 | +---- direction? te-label-direction 1659 +---- optimizations 1660 +---- (algorithm)? 1661 +--:(metric) {te-types:path-optimization-metric}? 1662 | +---- optimization-metric* [metric-type] 1663 | +---- metric-type identityref 1664 | +---- weight? uint8 1665 +--:(objective-function) 1666 {te-types:path-optimization-objective- 1667 function}? 1668 +---- objective-function 1669 +---- objective-function-type? identityref 1670 augment /te:tunnels-rpc/te:output/te:result: 1671 +--ro response* [response-id] 1672 +--ro response-id uint32 1673 +--ro (response-type)? 1674 +--:(no-path-case) 1675 | +--ro no-path! 1676 +--:(path-case) 1677 +--ro computed-path 1678 +--ro path-properties 1679 | +--ro path-metric* [metric-type] 1680 | | +--ro metric-type identityref 1681 | | +--ro accumulative-value? uint64 1682 | +--ro path-affinities-values 1683 | | +--ro path-affinities-value* [usage] 1684 | | +--ro usage identityref 1685 | | +--ro value? admin-groups 1686 | +--ro path-affinity-names 1687 | | +--ro path-affinity-name* [usage] 1688 | | +--ro usage identityref 1689 | | +--ro affinity-name* [name] 1690 | | +--ro name string 1691 | +--ro path-srlgs-lists 1692 | | +--ro path-srlgs-list* [usage] 1693 | | +--ro usage identityref 1694 | | +--ro values* srlg 1695 | +--ro path-srlgs-names 1696 | | +--ro path-srlgs-name* [usage] 1697 | | +--ro usage identityref 1698 | | +--ro names* string 1699 | +--ro path-route-objects 1700 | +--ro path-route-object* [index] 1701 | +--ro index uint32 1702 | +--ro (type)? 1703 | +--:(numbered-node-hop) 1704 | | +--ro numbered-node-hop 1705 | | +--ro node-id te-node-id 1706 | | +--ro hop-type? te-hop-type 1707 | +--:(numbered-link-hop) 1708 | | +--ro numbered-link-hop 1709 | | +--ro link-tp-id te-tp-id 1710 | | +--ro hop-type? te-hop-type 1711 | | +--ro direction? te-link- 1712 direction 1713 | +--:(unnumbered-link-hop) 1714 | | +--ro unnumbered-link-hop 1715 | | +--ro link-tp-id te-tp-id 1716 | | +--ro node-id te-node-id 1717 | | +--ro hop-type? te-hop-type 1718 | | +--ro direction? te-link- 1719 direction 1720 | +--:(as-number) 1721 | | +--ro as-number-hop 1722 | | +--ro as-number inet:as-number 1723 | | +--ro hop-type? te-hop-type 1724 | +--:(label) 1725 | +--ro label-hop 1726 | +--ro te-label 1727 | +--ro (technology)? 1728 | | +--:(generic) 1729 | | +--ro generic? 1730 | | rt- 1731 types:generalized-label 1732 | +--ro direction? 1733 | te-label-direction 1734 +--ro tunnel-ref? te:tunnel-ref 1735 +--ro (path)? 1736 +--:(primary) 1737 | +--ro primary-path-ref? leafref 1738 +--:(secondary) 1739 +--ro secondary-path-ref? leafref 1740 augment /te:tunnels-rpc/te:input/te:tunnel-info: 1741 +---- deleted-paths-transaction-id* string 1742 augment /te:tunnels-rpc/te:output/te:result: 1743 +---- deleted-paths-transaction-id* string 1745 Figure 9 - TE path computation YANG tree 1747 6.2. YANG Module 1749 file "ietf-te-path-computation@2019-03-11.yang" 1750 module ietf-te-path-computation { 1751 yang-version 1.1; 1752 namespace "urn:ietf:params:xml:ns:yang:ietf-te-path-computation"; 1753 // replace with IANA namespace when assigned 1755 prefix "tepc"; 1757 import ietf-inet-types { 1758 prefix "inet"; 1759 } 1761 import ietf-te { 1762 prefix "te"; 1763 } 1765 import ietf-te-types { 1766 prefix "te-types"; 1767 } 1769 organization 1770 "Traffic Engineering Architecture and Signaling (TEAS) 1771 Working Group"; 1773 contact 1774 "WG Web: 1775 WG List: 1777 WG Chair: Lou Berger 1778 1780 WG Chair: Vishnu Pavan Beeram 1781 1783 "; 1785 description "YANG model for stateless TE path computation"; 1787 revision "2019-03-11" { 1788 description 1789 "Initial revision"; 1790 reference 1791 "draft-ietf-teas-yang-path-computation"; 1792 } 1794 /* 1795 * Features 1796 */ 1798 feature stateless-path-computation { 1799 description 1800 "This feature indicates that the system supports 1801 stateless path computation."; 1802 } 1804 /* 1805 * Groupings 1806 */ 1808 grouping path-info { 1809 uses te-types:generic-path-properties; 1810 description "Path computation output information"; 1812 } 1814 grouping requested-info { 1815 description 1816 "This grouping defines the information (e.g., metrics) 1817 which must be returned in the response"; 1818 list requested-metrics { 1819 key 'metric-type'; 1820 description 1821 "The list of the requested metrics 1822 The metrics listed here must be returned in the response. 1823 Returning other metrics in the response is optional."; 1824 leaf metric-type { 1825 type identityref { 1826 base te-types:path-metric-type; 1827 } 1828 description 1829 "The metric that must be returned in the response"; 1830 } 1831 } 1832 leaf return-srlgs { 1833 type boolean; 1834 default false; 1835 description 1836 "If true, path srlgs must be returned in the response. 1837 If false, returning path srlgs in the response optional."; 1838 } 1839 leaf return-affinities { 1840 type boolean; 1841 default false; 1842 description 1843 "If true, path affinities must be returned in the response. 1844 If false, returning path affinities in the response is 1845 optional."; 1846 } 1847 } 1849 grouping requested-state { 1850 description 1851 "Configuration for the transient state used 1852 to report the computed path"; 1853 leaf timer { 1854 type uint16; 1855 units minutes; 1856 default 10; 1857 description 1858 "The timeout after which the transient state reporting 1859 the computed path should be removed."; 1860 } 1861 leaf transaction-id { 1862 type string; 1863 description 1864 " 1865 The transaction-id associated with this path computation 1866 to be used for fast deletion of the transient states 1867 associated with multiple path computations. 1869 This transaction-id can be used to explicitly delete all 1870 the transient states of all the computed paths associated 1871 with the same transaction-id. 1873 When one path associated with a transaction-id is setup, 1874 the transient states of all the other computed paths 1875 with the same transaction-id are automatically removed. 1877 If not specified, the transient state is removed only 1878 when the timer expires (when the timer is specified) 1879 or not created at all (stateless path computation, 1880 when the timer is not specified). 1881 "; 1882 } 1883 leaf tunnel-name { 1884 type string; 1885 description 1886 " 1887 The suggested name to be assigned to the te-tunnel 1888 instance which is created to report the computed path. 1890 In case multiple paths are requested with the same 1891 suggested name, the server will create only one te-tunnel 1892 instance to report all the computed paths 1893 with the same suggested name. 1895 A different name can be assigned by server (e.g., when a 1896 te-tunnel with this name already exists). 1897 "; 1898 } 1899 choice path { 1900 description 1901 "The transient state of the computed path can be reported 1902 as a primary or a secondary path of a te-tunnel"; 1903 case primary { 1904 leaf primary-path-name { 1905 type string; 1906 description 1907 " 1908 The suggested name to be assigned to the 1909 p2p-primary-path instance which is created 1910 to report the computed path. 1912 A different name can be assigned by the server 1913 (e.g., when a p2p-primary-path with this name 1914 already exists). 1915 "; 1916 } 1917 } 1918 case secondary { 1919 leaf secondary-path-name { 1920 type string; 1921 description 1922 " 1923 The suggested name to be assigned to the 1924 p2p-secondary-path instance which is created 1925 to report the computed path. 1927 A different name can be assigned by the server 1928 (e.g., when a p2p-secondary-path with this 1929 name already exists). 1931 If not specified, the a p2p-primary-path is created 1932 by the server. 1933 "; 1934 } 1935 } 1936 } 1937 } 1939 grouping reported-state { 1940 description 1941 "Information about the transient state created 1942 to report the computed path"; 1944 leaf tunnel-ref { 1945 type te:tunnel-ref; 1946 description 1947 " 1948 Reference to the tunnel that reports the transient state 1949 of the computed path. 1951 If no transient state is created, this attribute is empty. 1952 "; 1953 } 1954 choice path { 1955 description 1956 "The transient state of the computed path can be reported 1957 as a primary or a secondary path of a te-tunnel"; 1958 case primary { 1959 leaf primary-path-ref { 1960 type leafref { 1961 path "/te:te/te:tunnels/" + 1962 "te:tunnel[te:name=current()/../tunnel-ref]/" + 1963 "te:p2p-primary-paths/te:p2p-primary-path/" + 1964 "te:name"; 1965 } 1966 must "../tunnel-ref" { 1967 description 1968 "The primary-path-name can only be reported 1969 if also the tunnel is reported 1970 to provide the complete reference."; 1971 } 1972 description 1973 " 1974 Reference to the p2p-primary-path that reports 1975 the transient state of the computed path. 1977 If no transient state is created, 1978 this attribute is empty. 1979 "; 1980 } 1981 } 1982 case secondary { 1983 leaf secondary-path-ref { 1984 type leafref { 1985 path "/te:te/te:tunnels/" + 1986 "te:tunnel[te:name=current()/../tunnel-ref]/" + 1987 "te:p2p-secondary-paths/te:p2p-secondary-path/" + 1988 "te:name"; 1989 } 1990 must "../tunnel-ref" { 1991 description 1992 "The secondary-path-name can only be reported 1993 if also the tunnel is reported to provide 1994 the complete reference."; 1995 } 1996 description 1997 " 1998 Reference to the p2p-secondary-path that reports 1999 the transient state of the computed path. 2001 If no transient state is created, 2002 this attribute is empty. 2003 "; 2004 } 2005 } 2006 } 2008 } 2010 identity svec-metric-type { 2011 description 2012 "Base identity for svec metric type"; 2013 } 2015 identity svec-metric-cumul-te { 2016 base svec-metric-type; 2017 description 2018 "TE cumulative path metric"; 2019 } 2021 identity svec-metric-cumul-igp { 2022 base svec-metric-type; 2023 description 2024 "IGP cumulative path metric"; 2025 } 2027 identity svec-metric-cumul-hop { 2028 base svec-metric-type; 2029 description 2030 "Hop cumulative path metric"; 2031 } 2033 identity svec-metric-aggregate-bandwidth-consumption { 2034 base svec-metric-type; 2035 description 2036 "Cumulative bandwith consumption of the set of 2037 synchronized paths"; 2038 } 2040 identity svec-metric-load-of-the-most-loaded-link { 2041 base svec-metric-type; 2042 description 2043 "Load of the most loaded link"; 2044 } 2046 grouping svec-metrics-bounds_config { 2047 description 2048 "TE path metric bounds grouping for computing a set of 2049 synchronized requests"; 2050 leaf metric-type { 2051 type identityref { 2052 base svec-metric-type; 2053 } 2054 description "TE path metric type usable for computing a set of 2055 synchronized requests"; 2056 } 2057 leaf upper-bound { 2058 type uint64; 2059 description "Upper bound on end-to-end svec path metric"; 2060 } 2061 } 2063 grouping svec-metrics-optimization_config { 2064 description 2065 "TE path metric bounds grouping for computing a set of 2066 synchronized requests"; 2068 leaf metric-type { 2069 type identityref { 2070 base svec-metric-type; 2071 } 2072 description "TE path metric type usable for computing a set of 2073 synchronized requests"; 2074 } 2075 leaf weight { 2076 type uint8; 2077 description "Metric normalization weight"; 2078 } 2079 } 2081 grouping svec-exclude { 2082 description "List of resources to be excluded by all the paths 2083 in the SVEC"; 2084 container exclude-objects { 2085 description "resources to be excluded"; 2086 list excludes { 2087 key index; 2088 ordered-by user; 2089 leaf index { 2090 type uint32; 2091 description "XRO subobject index"; 2092 } 2093 description 2094 "List of explicit route objects to always exclude 2095 from synchronized path computation"; 2096 uses te-types:explicit-route-hop; 2097 } 2098 } 2099 } 2101 grouping synchronization-constraints { 2102 description "Global constraints applicable to synchronized 2103 path computation"; 2104 container svec-constraints { 2105 description "global svec constraints"; 2106 list path-metric-bound { 2107 key metric-type; 2108 description "list of bound metrics"; 2109 uses svec-metrics-bounds_config; 2110 } 2111 } 2112 uses te-types:generic-path-srlgs; 2113 uses svec-exclude; 2114 } 2116 grouping synchronization-optimization { 2117 description "Synchronized request optimization"; 2118 container optimizations { 2119 description 2120 "The objective function container that includes attributes 2121 to impose when computing a synchronized set of paths"; 2123 choice algorithm { 2124 description "Optimizations algorithm."; 2125 case metric { 2126 if-feature te-types:path-optimization-metric; 2127 list optimization-metric { 2128 key "metric-type"; 2129 description "svec path metric type"; 2130 uses svec-metrics-optimization_config; 2131 } 2132 } 2133 case objective-function { 2134 if-feature te-types:path-optimization-objective-function; 2135 container objective-function { 2136 description 2137 "The objective function container that includes 2138 attributes to impose when computing a TE path"; 2139 leaf objective-function-type { 2140 type identityref { 2141 base te-types:objective-function-type; 2142 } 2143 default te-types:of-minimize-cost-path; 2144 description "Objective function entry"; 2145 } 2146 } 2147 } 2148 } 2149 } 2150 } 2152 grouping synchronization-info { 2153 description "Information for sync"; 2154 list synchronization { 2155 key "synchronization-id"; 2156 description "sync list"; 2157 leaf synchronization-id { 2158 type uint32; 2159 description "index"; 2160 } 2161 container svec { 2162 description 2163 "Synchronization VECtor"; 2165 leaf relaxable { 2166 type boolean; 2167 default true; 2168 description 2169 "If this leaf is true, path computation process is 2170 free to ignore svec content. 2171 Otherwise, it must take into account this svec."; 2172 } 2173 uses te-types:generic-path-disjointness; 2174 leaf-list request-id-number { 2175 type uint32; 2176 description 2177 "This list reports the set of path computation 2178 requests that must be synchronized."; 2179 } 2180 } 2181 uses synchronization-constraints; 2182 uses synchronization-optimization; 2183 } 2184 } 2186 grouping no-path-info { 2187 description "no-path-info"; 2188 container no-path { 2189 presence "Response without path information, due to failure 2190 performing the path computation"; 2191 description "if path computation cannot identify a path, 2192 rpc returns no path."; 2193 } 2194 } 2196 /* 2197 * These groupings should be removed when defined in te-types 2198 */ 2200 grouping encoding-and-switching-type { 2201 description 2202 "Common grouping to define the LSP encoding and 2203 switching types"; 2205 leaf encoding { 2206 type identityref { 2207 base te-types:lsp-encoding-types; 2208 } 2209 description "LSP encoding type"; 2210 reference "RFC3945"; 2211 } 2212 leaf switching-type { 2213 type identityref { 2214 base te-types:switching-capabilities; 2215 } 2216 description "LSP switching type"; 2217 reference "RFC3945"; 2218 } 2219 } 2221 grouping tunnel-p2p-common-params { 2222 description 2223 "Common grouping to define the TE tunnel parameters"; 2225 uses encoding-and-switching-type; 2226 leaf source { 2227 type inet:ip-address; 2228 description "TE tunnel source address."; 2229 } 2230 leaf destination { 2231 type inet:ip-address; 2232 description "P2P tunnel destination address"; 2233 } 2234 leaf src-tp-id { 2235 type binary; 2236 description 2237 "TE tunnel source termination point identifier."; 2238 } 2239 leaf dst-tp-id { 2240 type binary; 2241 description 2242 "TE tunnel destination termination point identifier."; 2244 } 2245 leaf bidirectional { 2246 type boolean; 2247 default 'false'; 2248 description "TE tunnel bidirectional"; 2249 } 2250 } 2252 /* 2253 * AUGMENTS TO TE RPC 2254 */ 2256 augment "/te:tunnels-rpc/te:input/te:tunnel-info" { 2257 description "Path Computation RPC input"; 2258 list path-request { 2259 key "request-id"; 2260 description "request-list"; 2261 leaf request-id { 2262 type uint32; 2263 mandatory true; 2264 description 2265 "Each path computation request is uniquely identified 2266 by the request-id-number."; 2267 } 2268 uses tunnel-p2p-common-params; 2269 uses te-types:te-topology-identifier; 2270 uses te-types:path-constraints-route-objects; 2271 uses te-types:generic-path-constraints; 2272 uses te-types:generic-path-optimization; 2273 uses te:path-access-segment-info; 2274 uses requested-info; 2275 container requested-state { 2276 presence 2277 "Request temporary reporting of the computed path state"; 2278 description 2279 "Configures attributes for the temporary reporting of the 2280 computed path state (e.g., expiration timer)."; 2281 uses requested-state; 2282 } 2284 } 2285 uses synchronization-info; 2286 } 2288 augment "/te:tunnels-rpc/te:output/te:result" { 2289 description "Path Computation RPC output"; 2290 list response { 2291 key "response-id"; 2292 config false; 2293 description "response"; 2294 leaf response-id { 2295 type uint32; 2296 description 2297 "The response-id has the same value of the corresponding 2298 request-id."; 2299 } 2300 choice response-type { 2301 config false; 2302 description "response-type"; 2303 case no-path-case { 2304 uses no-path-info; 2305 } 2306 case path-case { 2307 container computed-path { 2308 uses path-info; 2309 uses reported-state; 2310 description "Path computation service."; 2311 } 2312 } 2313 } 2314 } 2315 } 2317 augment "/te:tunnels-rpc/te:input/te:tunnel-info" { 2318 description "Path Delete RPC input"; 2319 leaf-list deleted-paths-transaction-id { 2320 type string; 2321 description 2322 "The list of the transaction-id values of the 2323 transient states to be deleted"; 2324 } 2325 } 2327 augment "/te:tunnels-rpc/te:output/te:result" { 2328 description "Path Delete RPC output"; 2329 leaf-list deleted-paths-transaction-id { 2330 type string; 2331 description 2332 "The list of the transaction-id values of the 2333 transient states that have been successfully deleted"; 2334 } 2335 } 2336 } 2337 2339 Figure 10 - TE path computation YANG module 2341 7. Security Considerations 2343 This document describes use cases of requesting Path Computation 2344 using YANG models, which could be used at the ABNO Control Interface 2345 [RFC7491] and/or between controllers in ACTN [RFC8453]. As such, it 2346 does not introduce any new security considerations compared to the 2347 ones related to YANG specification, ABNO specification and ACTN 2348 Framework defined in [RFC7950], [RFC7491] and [RFC8453]. 2350 The YANG module defined in this draft is designed to be accessed via 2351 the NETCONF protocol [RFC6241] or RESTCONF protocol [RFC8040]. The 2352 lowest NETCONF layer is the secure transport layer, and the 2353 mandatory-to-implement secure transport is Secure Shell (SSH) 2354 [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to- 2355 implement secure transport is TLS [RFC8446]. 2357 This document also defines common data types using the YANG data 2358 modeling language. The definitions themselves have no security 2359 impact on the Internet, but the usage of these definitions in 2360 concrete YANG modules might have. The security considerations 2361 spelled out in the YANG specification [RFC7950] apply for this 2362 document as well. 2364 The NETCONF access control model [RFC8341] provides the means to 2365 restrict access for particular NETCONF or RESTCONF users to a 2366 preconfigured subset of all available NETCONF or RESTCONF protocol 2367 operations and content. 2369 Note - The security analysis of each leaf is for further study. 2371 8. IANA Considerations 2373 This document registers the following URIs in the IETF XML registry 2374 [RFC3688]. Following the format in [RFC3688], the following 2375 registration is requested to be made. 2377 URI: urn:ietf:params:xml:ns:yang:ietf-te-path-computation 2378 XML: N/A, the requested URI is an XML namespace. 2380 This document registers a YANG module in the YANG Module Names 2381 registry [RFC7950]. 2383 name: ietf-te-path-computation 2384 namespace: urn:ietf:params:xml:ns:yang:ietf-te-path-computation 2385 prefix: tepc 2387 9. References 2389 9.1. Normative References 2391 [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 2392 2004. 2394 [RFC5440] Vasseur, JP., Le Roux, JL. et al., "Path Computation 2395 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 2396 March 2009. 2398 [RFC5541] Le Roux, JL. et al., " Encoding of Objective Functions in 2399 the Path Computation Element Communication Protocol 2400 (PCEP)", RFC 5541, June 2009. 2402 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2403 and A. Bierman, Ed., "Network Configuration Protocol 2404 (NETCONF)", RFC 6241, June 2011. 2406 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2407 Shell (SSH)", RFC 6242, June 2011. 2409 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2410 Protocol", RFC 8040, January 2017. 2412 [RFC8341] Bierman, A., and M. Bjorklund, "Network Configuration 2413 Access Control Model", RFC 8341, March 2018. 2415 [RFC7491] Farrel, A., King, D., "A PCE-Based Architecture for 2416 Application-Based Network Operations", RFC 7491, March 2417 2015. 2419 [RFC7926] Farrel, A. et al., "Problem Statement and Architecture for 2420 Information Exchange Between Interconnected Traffic 2421 Engineered Networks", RFC 7926, July 2016. 2423 [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC 2424 7950, August 2016. 2426 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2427 Protocol", RFC 8040, January 2017. 2429 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2430 Version 1.3", RFC 8446, August 2018. 2432 [RFC8453] Ceccarelli, D., Lee, Y. et al., "Framework for Abstraction 2433 and Control of TE Networks (ACTN)", RFC8453, August 2018. 2435 [RFC8454] Lee, Y. et al., "Information Model for Abstraction and 2436 Control of TE Networks (ACTN)", RFC8454, September 2018. 2438 [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", 2439 draft-ietf-teas-yang-te-topo, work in progress. 2441 [TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic 2442 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 2443 te, work in progress. 2445 9.1. Informative References 2447 [RFC4655] Farrel, A. et al., "A Path Computation Element (PCE)-Based 2448 Architecture", RFC 4655, August 2006. 2450 [RFC7139] Zhang, F. et al., "GMPLS Signaling Extensions for Control 2451 of Evolving G.709 Optical Transport Networks", RFC 7139, 2452 March 2014. 2454 [RFC7446] Lee, Y. et al., "Routing and Wavelength Assignment 2455 Information Model for Wavelength Switched Optical 2456 Networks", RFC 7446, February 2015. 2458 [RFC8233] Dhody, D. et al., "Extensions to the Path Computation 2459 Element Communication Protocol (PCEP) to Compute Service- 2460 Aware Label Switched Paths (LSPs)", RFC 8233, September 2461 2017 2463 [RFC8342] Bjorklund,M. et al. "Network Management Datastore 2464 Architecture (NMDA)", RFC 8342, March 2018 2466 [OTN-TOPO] Zheng, H. et al., "A YANG Data Model for Optical 2467 Transport Network Topology", draft-ietf-ccamp-otn-topo- 2468 yang, work in progress. 2470 [ITU-T G.709-2016] ITU-T Recommendation G.709 (06/16), "Interface 2471 for the optical transport network", June 2016. 2473 10. Acknowledgments 2475 The authors would like to thank Igor Bryskin and Xian Zhang for 2476 participating in the initial discussions that have triggered this 2477 work and providing valuable insights. 2479 The authors would like to thank the authors of the TE Tunnel YANG 2480 model [TE-TUNNEL], in particular Igor Bryskin, Vishnu Pavan Beeram, 2481 Tarek Saad and Xufeng Liu, for their inputs to the discussions and 2482 support in having consistency between the Path Computation and TE 2483 Tunnel YANG models. 2485 The authors would like to thank Adrian Farrel, Dhruv Dhody, Igor 2486 Bryskin, Julien Meuric and Lou Berger for their valuable input to 2487 the discussions that has clarified that the path being setup is not 2488 necessarily the same as the path that have been previously computed 2489 and, in particular to Dhruv Dhody, for his suggestion to describe 2490 the need for a path verification phase to check that the actual path 2491 being setup meets the required end-to-end metrics and constraints. 2493 This document was prepared using 2-Word-v2.0.template.dot. 2495 Appendix A. Examples of dimensioning the "detailed connectivity matrix" 2497 In the following table, a list of the possible constraints, 2498 associated with their potential cardinality, is reported. 2500 The maximum number of potential connections to be computed and 2501 reported is, in first approximation, the multiplication of all of 2502 them. 2504 Constraint Cardinality 2505 ---------- ------------------------------------------------------- 2507 End points N(N-1)/2 if connections are bidirectional (OTN and WDM), 2508 N(N-1) for unidirectional connections. 2510 Bandwidth In WDM networks, bandwidth values are expressed in GHz. 2512 On fixed-grid WDM networks, the central frequencies are 2513 on a 50GHz grid and the channel width of the transmitters 2514 are typically 50GHz such that each central frequency can 2515 be used, i.e., adjacent channels can be placed next to 2516 each other in terms of central frequencies. 2518 On flex-grid WDM networks, the central frequencies are on 2519 a 6.25GHz grid and the channel width of the transmitters 2520 can be multiples of 12.5GHz. 2522 For fixed-grid WDM networks typically there is only one 2523 possible bandwidth value (i.e., 50GHz) while for flex- 2524 grid WDM networks typically there are 4 possible 2525 bandwidth values (e.g., 37.5GHz, 50GHz, 62.5GHz, 75GHz). 2527 In OTN (ODU) networks, bandwidth values are expressed as 2528 pairs of ODU type and, in case of ODUflex, ODU rate in 2529 bytes/sec as described in section 5 of [RFC7139]. 2531 For "fixed" ODUk types, 6 possible bandwidth values are 2532 possible (i.e., ODU0, ODU1, ODU2, ODU2e, ODU3, ODU4). 2534 For ODUflex(GFP), up to 80 different bandwidth values can 2535 be specified, as defined in Table 7-8 of [ITU-T G.709- 2536 2016]. 2538 For other ODUflex types, like ODUflex(CBR), the number of 2539 possible bandwidth values depends on the rates of the 2540 clients that could be mapped over these ODUflex types, as 2541 shown in Table 7.2 of [ITU-T G.709-2016], which in theory 2542 could be a countinuum of values. However, since different 2543 ODUflex bandwidths that use the same number of TSs on 2544 each link along the path are equivalent for path 2545 computation purposes, up to 120 different bandwidth 2546 ranges can be specified. 2548 Ideas to reduce the number of ODUflex bandwidth values in 2549 the detailed connectivity matrix, to less than 100, are 2550 for further study. 2552 Bandwidth specification for ODUCn is currently for 2553 further study but it is expected that other bandwidth 2554 values can be specified as integer multiples of 100Gb/s. 2556 In IP we have bandwidth values in bytes/sec. In 2557 principle, this is a countinuum of values, but in 2558 practice we can identify a set of bandwidth ranges, where 2559 any bandwidth value inside the same range produces the 2560 same path. 2561 The number of such ranges is the cardinality, which 2562 depends on the topology, available bandwidth and status 2563 of the network. Simulations (Note: reference paper 2564 submitted for publication) show that values for medium 2565 size topologies (around 50-150 nodes) are in the range 4- 2566 7 (5 on average) for each end points couple. 2568 Metrics IGP, TE and hop number are the basic objective metrics 2569 defined so far. There are also the 2 objective functions 2570 defined in [RFC5541]: Minimum Load Path (MLP) and Maximum 2571 Residual Bandwidth Path (MBP). Assuming that one only 2572 metric or objective function can be optimized at once, 2573 the total cardinality here is 5. 2575 With [RFC8233], a number of additional metrics are 2576 defined, including Path Delay metric, Path Delay 2577 Variation metric and Path Loss metric, both for point-to- 2578 point and point-to-multipoint paths. This increases the 2579 cardinality to 8. 2581 Bounds Each metric can be associated with a bound in order to 2582 find a path having a total value of that metric lower 2583 than the given bound. This has a potentially very high 2584 cardinality (as any value for the bound is allowed). In 2585 practice there is a maximum value of the bound (the one 2586 with the maximum value of the associated metric) which 2587 results always in the same path, and a range approach 2588 like for bandwidth in IP should produce also in this case 2589 the cardinality. Assuming to have a cardinality similar 2590 to the one of the bandwidth (let say 5 on average) we 2591 should have 6 (IGP, TE, hop, path delay, path delay 2592 variation and path loss; we don't consider here the two 2593 objective functions of [RFC5541] as they are conceived 2594 only for optimization)*5 = 30 cardinality. 2596 Technology 2597 constraints For further study 2599 Priority We have 8 values for setup priority, which is used in 2600 path computation to route a path using free resources 2601 and, where no free resources are available, resources 2602 used by LSPs having a lower holding priority. 2604 Local prot It's possible to ask for a local protected service, where 2605 all the links used by the path are protected with fast 2606 reroute (this is only for IP networks, but line 2607 protection schemas are available on the other 2608 technologies as well). This adds an alternative path 2609 computation, so the cardinality of this constraint is 2. 2611 Administrative 2612 Colors Administrative colors (aka affinities) are typically 2613 assigned to links but when topology abstraction is used 2614 affinity information can also appear in the detailed 2615 connectivity matrix. 2617 There are 32 bits available for the affinities. Links can 2618 be tagged with any combination of these bits, and path 2619 computation can be constrained to include or exclude any 2620 or all of them. The relevant cardinality is 3 (include- 2621 any, exclude-any, include-all) times 2^32 possible 2622 values. However, the number of possible values used in 2623 real networks is quite small. 2625 Included Resources 2627 A path computation request can be associated to an 2628 ordered set of network resources (links, nodes) to be 2629 included along the computed path. This constraint would 2630 have a huge cardinality as in principle any combination 2631 of network resources is possible. However, as far as the 2632 Orchestrator doesn't know details about the internal 2633 topology of the domain, it shouldn't include this type of 2634 constraint at all (see more details below). 2636 Excluded Resources 2638 A path computation request can be associated to a set of 2639 network resources (links, nodes, SRLGs) to be excluded 2640 from the computed path. Like for included resources, 2641 this constraint has a potentially very high cardinality, 2642 but, once again, it can't be actually used by the 2643 Orchestrator, if it's not aware of the domain topology 2644 (see more details below). 2645 As discussed above, the Orchestrator can specify include or exclude 2646 resources depending on the abstract topology information that the 2647 domain controller exposes: 2649 o In case the domain controller exposes the entire domain as a 2650 single abstract TE node with his own external terminations and 2651 detailed connectivity matrix (whose size we are estimating), no 2652 other topological details are available, therefore the size of 2653 the detailed connectivity matrix only depends on the combination 2654 of the constraints that the Orchestrator can use in a path 2655 computation request to the domain controller. These constraints 2656 cannot refer to any details of the internal topology of the 2657 domain, as those details are not known to the Orchestrator and so 2658 they do not impact size of the detailed connectivity matrix 2659 exported. 2661 o Instead in case the domain controller exposes a topology 2662 including more than one abstract TE nodes and TE links, and their 2663 attributes (e.g. SRLGs, affinities for the links), the 2664 Orchestrator knows these details and therefore could compute a 2665 path across the domain referring to them in the constraints. The 2666 detailed connectivity matrixes, whose size need to be estimated 2667 here, are the ones relevant to the abstract TE nodes exported to 2668 the Orchestrator. These detailed connectivity matrixes and 2669 therefore theirs sizes, while cannot depend on the other abstract 2670 TE nodes and TE links, which are external to the given abstract 2671 node, could depend to SRLGs (and other attributes, like 2672 affinities) which could be present also in the portion of the 2673 topology represented by the abstract nodes, and therefore 2674 contribute to the size of the related detailed connectivity 2675 matrix. 2677 We also don't consider here the possibility to ask for more than one 2678 path in diversity or for point-to-multi-point paths, which are for 2679 further study. 2681 Considering for example an IP domain without considering SRLG and 2682 affinities, we have an estimated number of paths depending on these 2683 estimated cardinalities: 2685 Endpoints = N*(N-1), Bandwidth = 5, Metrics = 6, Bounds = 20, 2686 Priority = 8, Local prot = 2 2688 The number of paths to be pre-computed by each IP domain is 2689 therefore 24960 * N(N-1) where N is the number of domain access 2690 points. 2692 This means that with just 4 access points we have nearly 300000 2693 paths to compute, advertise and maintain (if a change happens in the 2694 domain, due to a fault, or just the deployment of new traffic, a 2695 substantial number of paths need to be recomputed and the relevant 2696 changes advertised to the upper controller). 2698 This seems quite challenging. In fact, if we assume a mean length of 2699 1K for the json describing a path (a quite conservative estimate), 2700 reporting 300000 paths means transferring and then parsing more than 2701 300 Mbytes for each domain. If we assume that 20% (to be checked) of 2702 this paths change when a new deployment of traffic occurs, we have 2703 60 Mbytes of transfer for each domain traversed by a new end-to-end 2704 path. If a network has, let say, 20 domains (we want to estimate the 2705 load for a non-trivial domain setup) in the beginning a total 2706 initial transfer of 6Gigs is needed, and eventually, assuming 4-5 2707 domains are involved in mean during a path deployment we could have 2708 240-300 Mbytes of changes advertised to the higher order controller. 2710 Further bare-bone solutions can be investigated, removing some more 2711 options, if this is considered not acceptable; in conclusion, it 2712 seems that an approach based only on the information provided by the 2713 detailed connectivity matrix is hardly feasible, and could be 2714 applicable only to small networks with a limited meshing degree 2715 between domains and renouncing to a number of path computation 2716 features. 2718 Contributors 2720 Dieter Beller 2721 Nokia 2722 Email: dieter.beller@nokia.com 2724 Gianmarco Bruno 2725 Ericsson 2726 Email: gianmarco.bruno@ericsson.com 2728 Francesco Lazzeri 2729 Ericsson 2730 Email: francesco.lazzeri@ericsson.com 2732 Young Lee 2733 Huawei 2734 Email: leeyoung@huawei.com 2736 Carlo Perocchio 2737 Ericsson 2738 Email: carlo.perocchio@ericsson.com 2740 Authors' Addresses 2742 Italo Busi (Editor) 2743 Huawei 2744 Email: italo.busi@huawei.com 2745 Sergio Belotti (Editor) 2746 Nokia 2747 Email: sergio.belotti@nokia.com 2749 Victor Lopez 2750 Telefonica 2751 Email: victor.lopezalvarez@telefonica.com 2753 Oscar Gonzalez de Dios 2754 Telefonica 2755 Email: oscar.gonzalezdedios@telefonica.com 2757 Anurag Sharma 2758 Google 2759 Email: ansha@google.com 2761 Yan Shi 2762 China Unicom 2763 Email: shiyan49@chinaunicom.cn 2765 Ricard Vilalta 2766 CTTC 2767 Email: ricard.vilalta@cttc.es 2769 Karthik Sethuraman 2770 NEC 2771 Email: karthik.sethuraman@necam.com 2773 Michael Scharf 2774 Nokia 2775 Email: michael.scharf@gmail.com 2777 Daniele Ceccarelli 2778 Ericsson 2779 Email: daniele.ceccarelli@ericsson.com