idnits 2.17.1 draft-ietf-teas-actn-vn-yang-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (7 March 2022) is 780 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 176, but not defined == Outdated reference: A later version (-26) exists of draft-ietf-ccamp-l1csm-yang-16 == Outdated reference: A later version (-12) exists of draft-ietf-teas-actn-pm-telemetry-autonomics-07 == Outdated reference: A later version (-15) exists of draft-ietf-teas-te-service-mapping-yang-09 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-29 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group Y. Lee, Ed. 3 Internet-Draft Samsung Electronics 4 Intended status: Standards Track D. Dhody, Ed. 5 Expires: 8 September 2022 Huawei Technologies 6 D. Ceccarelli 7 Ericsson 8 I. Bryskin 9 Individual 10 B. Yoon 11 ETRI 12 7 March 2022 14 A YANG Data Model for VN Operation 15 draft-ietf-teas-actn-vn-yang-14 17 Abstract 19 This document provides a YANG data model generally applicable to any 20 mode of Virtual Network (VN) operation. 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). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 8 September 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1.1. Requirements Language . . . . . . . . . . . . . . . . 4 58 1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 4 59 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4 60 2. Use-case of VN YANG Model in the ACTN context . . . . . . . . 5 61 2.1. Type 1 VN . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.2. Type 2 VN . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3. High-Level Control Flows with Examples . . . . . . . . . . . 7 64 3.1. Type 1 VN Illustration . . . . . . . . . . . . . . . . . 7 65 3.2. Type 2 VN Illustration . . . . . . . . . . . . . . . . . 8 66 3.2.1. VN and AP Usage . . . . . . . . . . . . . . . . . . . 11 67 4. VN Model Usage . . . . . . . . . . . . . . . . . . . . . . . 12 68 4.1. Customer view of VN . . . . . . . . . . . . . . . . . . . 12 69 4.2. Auto-creation of VN by MDSC . . . . . . . . . . . . . . . 12 70 4.3. Innovative Services . . . . . . . . . . . . . . . . . . . 12 71 4.3.1. VN Compute . . . . . . . . . . . . . . . . . . . . . 12 72 4.3.2. Multi-sources and Multi-destinations . . . . . . . . 16 73 4.3.3. Others . . . . . . . . . . . . . . . . . . . . . . . 17 74 4.3.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 18 75 5. VN YANG Model (Tree Structure) . . . . . . . . . . . . . . . 18 76 6. VN YANG Model . . . . . . . . . . . . . . . . . . . . . . . . 22 77 7. JSON Example . . . . . . . . . . . . . . . . . . . . . . . . 33 78 7.1. VN JSON . . . . . . . . . . . . . . . . . . . . . . . . . 34 79 7.2. TE-topology JSON . . . . . . . . . . . . . . . . . . . . 39 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 50 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 82 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 52 85 11.2. Informative References . . . . . . . . . . . . . . . . . 54 86 Appendix A. Performance Constraints . . . . . . . . . . . . . . 55 87 Appendix B. Contributors Addresses . . . . . . . . . . . . . . . 55 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 90 1. Introduction 92 This document provides a YANG [RFC7950] data model generally 93 applicable to any mode of Virtual Network (VN) operation. 95 The VN model defined in this document is applicable in generic sense 96 as an independent model in and of itself. The VN model defined in 97 this document can also work together with other customer service 98 models such as L3SM [RFC8299], L2SM [RFC8466] and L1CSM 99 [I-D.ietf-ccamp-l1csm-yang] to provide a complete life-cycle service 100 management and operations. 102 The YANG model discussed in this document basically provides the 103 following: 105 * Characteristics of Access Points (APs) that describe customer's 106 end point characteristics; 108 * Characteristics of Virtual Network Access Points (VNAP) that 109 describe how an AP is partitioned for multiple VNs sharing the AP 110 and its reference to a Link Termination Point (LTP) of the 111 Provider Edge (PE) Node; 113 * Characteristics of Virtual Networks (VNs) that describe the 114 customer's VN in terms of multiple VN Members comprising a VN, 115 multi- source and/or multi-destination characteristics of the VN 116 Member, the VN's reference to TE-topology's Abstract Node; 118 The actual VN instantiation and computation is performed with 119 Connectivity Matrices sub-module of TE-Topology Model [RFC8795] which 120 provides TE network topology abstraction and management operation. 121 Once TE-topology Model is used in triggering VN instantiation over 122 the networks, TE-tunnel [I-D.ietf-teas-yang-te] Model will inevitably 123 interact with TE-Topology model for setting up actual tunnels and 124 LSPs under the tunnels. 126 Abstraction and Control of Traffic Engineered Networks (ACTN) 127 describes a set of management and control functions used to operate 128 one or more TE networks to construct virtual networks that can be 129 represented to customers and that are built from abstractions of the 130 underlying TE networks [RFC8453]. ACTN is the primary example of the 131 usage of the VN YANG model. 133 Sections 2 and 3 provide the discussion of how the VN YANG model is 134 applicable to the ACTN context where Virtual Network Service (VNS) 135 operation is implemented for the Customer Network Controller (CNC)- 136 Multi-Domain Service Coordinator (MSDC) interface (CMI). 138 The YANG model on the CMI is also known as customer service model in 139 [RFC8309]. The YANG model discussed in this document is used to 140 operate customer-driven VNs during the VN instantiation, VN 141 computation, and its life-cycle service management and operations. 143 The VN operational state is included in the same tree as the 144 configuration consistent with Network Management Datastore 145 Architecture (NMDA) [RFC8342]. The origin of the data is indicated 146 as per the origin metadata annotation. 148 1.1. Terminology 150 Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used 151 in this document. 153 1.1.1. Requirements Language 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 157 "OPTIONAL" in this document are to be interpreted as described in BCP 158 14 [RFC2119] [RFC8174] when, and only when, they appear in all 159 capitals, as shown here. 161 1.2. Tree diagram 163 A simplified graphical representation of the data model is used in 164 Section 5 of this this document. The meaning of the symbols in these 165 diagrams is defined in [RFC8340]. 167 1.3. Prefixes in Data Node Names 169 In this document, names of data nodes and other data model objects 170 are prefixed using the standard prefix associated with the 171 corresponding YANG imported modules, as shown in Table 1. 173 +==========+=======================+===========+ 174 | Prefix | YANG module | Reference | 175 +==========+=======================+===========+ 176 | vn | ietf-vn | [RFCXXXX] | 177 +----------+-----------------------+-----------+ 178 | yang | ietf-yang-types | [RFC6991] | 179 +----------+-----------------------+-----------+ 180 | nw | ietf-network | [RFC8345] | 181 +----------+-----------------------+-----------+ 182 | nt | ietf-network-topology | [RFC8345] | 183 +----------+-----------------------+-----------+ 184 | te-types | ietf-te-types | [RFC8776] | 185 +----------+-----------------------+-----------+ 186 | tet | ietf-te-topology | [RFC8795] | 187 +----------+-----------------------+-----------+ 189 Table 1: Prefixes and corresponding YANG modules 191 Note: The RFC Editor will replace XXXX with the number assigned to 192 the RFC once this draft becomes an RFC. 194 2. Use-case of VN YANG Model in the ACTN context 196 In this section, ACTN is being used to illustrate the general usage 197 of the VN YANG model. The model presented in this section has the 198 following ACTN context. 200 +-------+ 201 | CNC | 202 +-------+ 203 | 204 | VN YANG + TE-topology YANG 205 | 206 +-----------------------+ 207 | MDSC | 208 +-----------------------+ 210 Figure 1: ACTN CMI 212 Both ACTN VN YANG and TE-topology models are used over the CMI to 213 establish a VN over TE networks. 215 2.1. Type 1 VN 217 As defined in [RFC8453], a Virtual Network is a customer view of the 218 TE network. To recapitulate VN types from [RFC8453], Type 1 VN is 219 defined as follows: 221 The VN can be seen as a set of edge-to-edge abstract links (a Type 1 222 VN). Each abstract link is referred to as a VN member and is formed 223 as an end-to-end tunnel across the underlying networks. Such tunnels 224 may be constructed by recursive slicing or abstraction of paths in 225 the underlying networks and can encompass edge points of the 226 customer's network, access links, intra-domain paths, and inter- 227 domain links. 229 If we were to create a VN where we have four VN-members as 230 follows: 232 VN-Member 1 L1-L4 233 VN-Member 2 L1-L7 234 VN-Member 3 L2-L4 235 VN-Member 4 L3-L8 237 Where L1, L2, L3, L4, L7 and L8 correspond to a Customer End- 238 Point, respectively. 240 This VN can be modeled as one abstract node representation as follows 241 in Figure 2: 243 +---------------+ 244 L1 ------| |------ L4 245 L2 ------| AN 1 |------ L7 246 L3 ------| |------ L8 247 +---------------+ 249 Figure 2: Abstract Node (One node topology) 251 Modeling a VN as one abstract node is the easiest way for customers 252 to express their end-to-end connectivity; however, customers are not 253 limited to express their VN only with one abstract node. 255 2.2. Type 2 VN 257 For some VN members of a VN, the customers are allowed to configure 258 the actual path (i.e., detailed virtual nodes and virtual links) over 259 the VN/abstract topology agreed mutually between CNC and MDSC prior 260 to or a topology created by the MDSC as part of VN instantiation. 261 Type 1 VN is a higher abstraction of a Type 2 VN. 263 If a Type 2 VN is desired for some or all of VN members of a type 1 264 VN (see the example in Section 2.1), the TE-topology model can 265 provide the following abstract topology (that consists of virtual 266 nodes and virtual links) which is built under the Type 1 VN. 268 +----------------------------------------------+ 269 | S1 S2 | 270 | O---------------O | 271 | ________/ \______ \ | 272 | / \ \ | 273 |S3 / \ S4 \ S5 | 274 L1----|-O----------------------O---------O-----------|------L4 275 | \ \ \ | 276 | \ \ \ | 277 | \ S6 \ S7 \ S8 | 278 | O ----------------O---------O-------|------L7 279 | / \ / \ ____/ | 280 |S9 / \ /S10 \ / | 281 L2-----|---O-----O---------------------O--------------|------L8 282 | / S11 | 283 L3-----|-- | 284 | | 285 +----------------------------------------------+ 287 Figure 3: Type 2 topology 289 As you see from Figure 3, the Type 1 abstract node is depicted as a 290 Type 1 abstract topology comprising of detailed virtual nodes and 291 virtual links. 293 As an example, if VN-member 1 (L1-L4) is chosen to configure its own 294 path over Type 2 topology, it can select, say, a path that consists 295 of the ERO {S3,S4,S5} based on the topology and its service 296 requirement. This capability is enacted via TE-topology 297 configuration by the customer. 299 3. High-Level Control Flows with Examples 301 3.1. Type 1 VN Illustration 303 If we were to create a VN where we have four VN-members as 304 follows: 306 VN-Member 1 L1-L4 307 VN-Member 2 L1-L7 308 VN-Member 3 L2-L4 309 VN-Member 4 L3-L8 311 Where L1, L2, L3, L4, L7 and L8 correspond to Access Points. 313 This VN can be modeled as one abstract node representation as 314 follows: 316 +---------------+ 317 L1 ------| |------ L4 318 L2 ------| AN 1 |------ L7 319 L3 ------| |------ L8 320 +---------------+ 322 If this VN is Type 1, the following diagram shows the message flow 323 between CNC and MDSC to instantiate this VN using VN and TE-Topology 324 Models. 326 +--------+ +--------+ 327 | CNC | | MDSC | 328 +--------+ +--------+ 329 | | 330 | | 331 CNC POST TE-topo | POST /nw:networks/nw:network/ | 332 model(with Conn. | nw:node/te-node-id/ | 333 Matrix on one | tet:connectivity-matrices/ | 334 Abstract node | tet:connectivity-matrix | 335 |-------------------------------->| 336 | HTTP 200 | 337 |<--------------------------------| 338 | | 339 CNC POST the | POST /virtual-network | 340 VN identifying |-------------------------------->| If there is 341 AP, VNAP and VN- | | multi-src/dest 342 Members and maps | | then MDSC 343 to the TE-topo | HTTP 200 | selects a 344 |<--------------------------------| src or dest 345 | | and update 346 | | VN YANG 347 CNC GET the | GET /virtual-network | 348 VN YANG status |-------------------------------->| 349 | | 350 | HTTP 200 (VN with status: | 351 | selected VN-members | 352 | in case of multi s-d) | 353 |<--------------------------------| 354 | | 356 3.2. Type 2 VN Illustration 358 For some VN members, the customer may want to "configure" explicit 359 routes over the path that connects its two end-points. Let us 360 consider the following example. 362 VN-Member 1 L1-L4 (via S3, S4, and S5) 364 VN-Member 2 L1-L7 (via S3, S4, S7 and S8) 366 VN-Member 3 L2-L7 (via S9, S10, and S11) 368 VN-Member 4 L3-L8 (via S9, S10 and S11) 370 Where the following topology is the underlay for Abstraction Node 1 371 (AN1). 373 AN1 374 ............................................ 375 . S1 S2 . 376 . O---------------O . 377 . ________/ \______ \ . 378 . / \ \ . 379 . S3/ \ S4 \ S5 . 380 L1----.-O----------------------O---------O-------.----------L4 381 . \ \ \ . 382 . \ \ \ . 383 . \ S6 \ S7 \ S8 . 384 . O ----------------O---------O---.----------L5 385 . / \ / \ ____/ \__.__________L6 386 .S9 / \ /S10 \ / . 387 L2-----.---O-----O---------------------O----------.----------L7 388 . / S11\_________.__________L8 389 L3-----.-- . 390 ............................................ 392 There are two options depending on whether CNC or MDSC creates the 393 single abstract node topology. 395 Case 1: 397 If CNC creates the single abstract node topology, the following 398 diagram shows the message flow between CNC and MDSC to instantiate 399 this VN using VN and TE-Topology Model. 401 +--------+ +--------+ 402 | CNC | | MDSC | 403 +--------+ +--------+ 404 | | 405 | | 406 CNC POST TE-topo | POST /nw:networks/nw:network/ | 407 model(with Conn. | nw:node/te-node-id/tet:connectivity- | 408 Matrix on one | matrices/tet:connectivity-matrix | 409 Abstract node and|---------------------------------------->| 410 Explicit paths in| | 411 the conn. matrix)| HTTP 200 | 412 |<----------------------------------------| 413 | | 414 CNC POST the | POST /virtual-network | 415 VN identifying |---------------------------------------->| 416 AP, VNAP and VN- | | 417 Members and maps | | 418 to the TE-topo | HTTP 200 | 419 |<----------------------------------------| 420 | | 421 | | 422 CNC GET the | GET /virtual-network | 423 VN YANG status |---------------------------------------->| 424 | | 425 | HTTP 200 (VN with status) | 426 |<----------------------------------------| 427 | | 429 Case 2: 431 On the other hand, if MDSC create the single abstract node topology 432 based VN YANG posted by the CNC, the following diagram shows the 433 message flow between CNC and MDSC to instantiate this VN using VN and 434 TE-Topology Models. 436 +--------+ +--------+ 437 | CNC | | MDSC | 438 +--------+ +--------+ 439 | | 440 | | 441 CNC POST VN | | 442 Identifying AP, | | 443 VNAP and VN- | POST /virtual-network | MDSC populates 444 Members |-------------------------------->| a single Abst. 445 | HTTP 200 | node topology 446 |<--------------------------------| by itself 447 | | 448 CNC GET VN & | GET /virtual-network & | 449 POST TE-Topo | POST /nw:networks/nw:network/ | 450 Models (with | nw:node/te-node-id/tet: | 451 Conn. Matrix | connectivity-matrices/ | 452 on the | tet:connectivity-matrix | 453 Abstract Node |-------------------------------->| 454 and explicit | | 455 paths in the | | 456 conn. matrix) | | 457 | HTTP 200 | 458 |<--------------------------------| 459 | | 460 | | 461 CNC GET the | GET /virtual-network | 462 VN YANG status |-------------------------------->| 463 | | 464 | HTTP 200 (VN with status) | 465 |<--------------------------------| 466 | | 468 Section 7 provides JSON examples for both VN model and TE-topology 469 Connectivity Matrix sub-model to illustrate how a VN can be created 470 by the CNC making use of the VN module as well as the TE-topology 471 Connectivity Matrix module. 473 3.2.1. VN and AP Usage 475 The customer access information may be known at the time of VN 476 creation. A shared logical AP identifier is used between the 477 customer and the operator to identify the access link between 478 Customer Edge (CE) and Provider Edge (PE) . This is described in 479 Section 6 of [RFC8453]. 481 In some VN operations, the customer access may not be known at the 482 initial VN creation. The VN operation allow a creation of VN with 483 only PE identifier as well. The customer access information could be 484 added later. 486 To achieve this the 'ap' container has a leaf for 'pe' node that 487 allows AP to be created with PE information. The vn-member (and vn) 488 could use APs that only have PE information initially. 490 4. VN Model Usage 492 4.1. Customer view of VN 494 The VN-YANG model allows to define a customer view, and allows the 495 customer to communicate using the VN constructs as described in the 496 [RFC8454]. It also allows to group the set of edge-to-edge links 497 (i.e., VN members) under a common umbrella of VN. This allows the 498 customer to instantiate and view the VN as one entity, making it 499 easier for some customers to work on VN without worrying about the 500 details of the provider based YANG models. 502 This is similar to the benefits of having a separate YANG model for 503 the customer services as described in [RFC8309], which states that 504 service models do not make any assumption of how a service is 505 actually engineered and delivered for a customer. 507 4.2. Auto-creation of VN by MDSC 509 The VN could be configured at the MDSC explicitly by the CNC using 510 the VN YANG model. In some other cases, the VN is not explicitly 511 configured, but created automatically by the MDSC based on the 512 customer service model and local policy, even in these case the VN 513 YANG model can be used by the CNC to learn details of the underlying 514 VN created to meet the requirements of customer service model. 516 4.3. Innovative Services 518 4.3.1. VN Compute 520 VN Model supports VN compute (pre-instantiation mode) to view the 521 full VN as a single entity before instantiation. Achieving this via 522 path computation or "compute only" tunnel setup does not provide the 523 same functionality. 525 +--------+ +--------+ 526 | CNC | | MDSC | 527 +--------+ +--------+ 528 | | 529 | | 530 CNC POST TE-topo | POST /nw:networks/nw:network/ | 531 model(with Conn. | nw:node/te-node-id/tet:connectivity- | 532 Matrix on one | matrices/tet:connectivity-matrix | 533 Abstract node and|---------------------------------------->| 534 constraints in | | 535 the conn. matrix)| HTTP 200 | 536 |<----------------------------------------| 537 | | 538 | | 539 CNC calls RPC to | RPC /vn-compute | 540 compute the VN |---------------------------------------->| 541 as per the | | 542 refered TE-Topo | | 543 | | 544 | HTTP 200 (Computed VN) | 545 |<----------------------------------------| 546 | | 548 The VN compute RPC allow you to optionally include the constraints 549 and the optimization criteria at the VN as well as at the individual 550 VN-member level. Thus, the RPC can be used independently to get the 551 computed VN result without creating an abstract topology first. 553 +--------+ +--------+ 554 | CNC | | MDSC | 555 +--------+ +--------+ 556 | | 557 | | 558 CNC calls RPC to | RPC /vn-compute | 559 compute the VN |---------------------------------------->| 560 as per the | | 561 constraints and | | 562 VN-Members | | 563 | HTTP 200 (Computed VN) | 564 |<----------------------------------------| 565 | | 567 In either case the output includes a reference to the single node 568 abstract topology with each VN-member including a reference to the 569 connectivity-matrix-id where the path properties could be found. 571 To achieve this the VN-compute RPC reuses the following common 572 groupings: 574 * te-types:generic-path-constraints: This is used optionally in the 575 RPC input at the VN and/or VN-member level. The VN-member level 576 overrides the VN-level data. This also overrides any constraints 577 in the referred abstract node in the TE topology. 579 * te-types:generic-path-optimization: This is used optionally in the 580 RPC input at the VN and/or VN-member level. The VN-member level 581 overrides the VN-level data. This also overrides any optimization 582 in the referred abstract node in the TE topology. 584 * vn-member: This identifies the VN member in both RPC input and 585 output. 587 * vn-policy: This is used optionally in the RPC input to apply any 588 VN level policies. 590 When MDSC receives this RPC it computes the VN based on the input 591 provided in the RPC call. This computation does not create a VN or 592 reserve any resources in the system, it simply computes the resulting 593 VN based on information at the MDSC or in coordination with the CNC. 594 A single node abstract topology is used to convey the result of the 595 each VN member as a reference to the connectivity-matrix-id. In case 596 of error, the error information is included. 598 rpcs: 599 +---x vn-compute 600 +---w input 601 | +---w te-topology-identifier 602 | | +---w provider-id? te-global-id 603 | | +---w client-id? te-global-id 604 | | +---w topology-id? te-topology-id 605 | +---w abstract-node? 606 | | -> /nw:networks/network/node/tet:te-node-id 607 | +---w path-constraints 608 | | +---w te-bandwidth 609 | | | +---w (technology)? 610 | | | ... 611 | | +---w link-protection? identityref 612 | | +---w setup-priority? uint8 613 | | +---w hold-priority? uint8 614 | | +---w signaling-type? identityref 615 | | +---w path-metric-bounds 616 | | | +---w path-metric-bound* [metric-type] 617 | | | ... 618 | | +---w path-affinities-values 619 | | | +---w path-affinities-value* [usage] 620 | | | ... 621 | | +---w path-affinity-names 622 | | | +---w path-affinity-name* [usage] 623 | | | ... 624 | | +---w path-srlgs-lists 625 | | | +---w path-srlgs-list* [usage] 626 | | | ... 627 | | +---w path-srlgs-names 628 | | | +---w path-srlgs-name* [usage] 629 | | | ... 630 | | +---w disjointness? te-path-disjointness 631 | +---w cos? te-types:te-ds-class 632 | +---w optimizations 633 | | +---w (algorithm)? 634 | | +--:(metric) {path-optimization-metric}? 635 | | | ... 636 | | +--:(objective-function) 637 | | {path-optimization-objective-function}? 638 | | ... 639 | +---w vn-member-list* [vnm-id] 640 | | +---w vnm-id vnm-id 641 | | +---w src 642 | | | +---w src? -> /access-point/ap/ap-id 643 | | | +---w src-vn-ap-id? 644 | | | | -> /access-point/ap/vn-ap/vn-ap-id 645 | | | +---w multi-src? boolean {multi-src-dest}? 646 | | +---w dest 647 | | | +---w dest? -> /access-point/ap/ap-id 648 | | | +---w dest-vn-ap-id? 649 | | | | -> /access-point/ap/vn-ap/vn-ap-id 650 | | | +---w multi-dest? boolean {multi-src-dest}? 651 | | +---w connectivity-matrix-id? leafref 652 | | +---w underlay 653 | | +---w path-constraints 654 | | | +---w te-bandwidth 655 | | | | ... 656 | | | +---w link-protection? identityref 657 | | | +---w setup-priority? uint8 658 | | | +---w hold-priority? uint8 659 | | | +---w signaling-type? identityref 660 | | | +---w path-metric-bounds 661 | | | | ... 662 | | | +---w path-affinities-values 663 | | | | ... 664 | | | +---w path-affinity-names 665 | | | | ... 666 | | | +---w path-srlgs-lists 667 | | | | ... 668 | | | +---w path-srlgs-names 669 | | | | ... 671 | | | +---w disjointness? te-path-disjointness 672 | | +---w cos? te-types:te-ds-class 673 | | +---w optimizations 674 | | +---w (algorithm)? 675 | | ... 676 | +---w vn-level-diversity? 677 | te-types:te-path-disjointness 678 +--ro output 679 +--ro te-topology-identifier 680 | +--ro provider-id? te-global-id 681 | +--ro client-id? te-global-id 682 | +--ro topology-id? te-topology-id 683 +--ro abstract-node? 684 | -> /nw:networks/network/node/tet:te-node-id 685 +--ro vn-member-list* [vnm-id] 686 +--ro vnm-id vnm-id 687 +--ro src 688 | +--ro src? -> /access-point/ap/ap-id 689 | +--ro src-vn-ap-id? 690 | | -> /access-point/ap/vn-ap/vn-ap-id 691 | +--ro multi-src? boolean {multi-src-dest}? 692 +--ro dest 693 | +--ro dest? -> /access-point/ap/ap-id 694 | +--ro dest-vn-ap-id? 695 | | -> /access-point/ap/vn-ap/vn-ap-id 696 | +--ro multi-dest? boolean {multi-src-dest}? 697 +--ro connectivity-matrix-id? leafref 698 +--ro underlay 699 +--ro if-selected? boolean 700 | {multi-src-dest}? 701 +--ro compute-status? vn-compute-status 702 +--ro error-info 703 +--ro error-description? string 704 +--ro error-timestamp? yang:date-and-time 705 +--ro error-reason? identityref 707 4.3.2. Multi-sources and Multi-destinations 709 In creating a virtual network, the list of sources or destinations or 710 both may not be pre-determined by the customer. For instance, for a 711 given source, there may be a list of multiple-destinations to which 712 the optimal destination may be chosen depending on the network 713 resource situations. Likewise, for a given destination, there may 714 also be multiple-sources from which the optimal source may be chosen. 715 In some cases, there may be a pool of multiple sources and 716 destinations from which the optimal source-destination may be chosen. 717 The following YANG module is shown for describing source container 718 and destination container. The following YANG tree shows how to 719 model multi-sources and multi-destinations. 721 module: ietf-vn 722 +--rw virtual-network 723 +--rw vn* [vn-id] 724 +--rw vn-id vn-id 725 +--rw te-topology-identifier 726 | +--rw provider-id? te-global-id 727 | +--rw client-id? te-global-id 728 | +--rw topology-id? te-topology-id 729 +--rw abstract-node? 730 | -> /nw:networks/network/node/tet:te-node-id 731 +--rw vn-member* [vnm-id] 732 | +--rw vnm-id vnm-id 733 | +--rw src 734 | | +--rw src? -> /access-point/ap/ap-id 735 | | +--rw src-vn-ap-id? 736 | | | -> /access-point/ap/vn-ap/vn-ap-id 737 | | +--rw multi-src? boolean {multi-src-dest}? 738 | +--rw dest 739 | | +--rw dest? -> /access-point/ap/ap-id 740 | | +--rw dest-vn-ap-id? 741 | | | -> /access-point/ap/vn-ap/vn-ap-id 742 | | +--rw multi-dest? boolean {multi-src-dest}? 743 | +--rw connectivity-matrix-id? leafref 744 | +--rw underlay 745 | +--ro oper-status? te-types:te-oper-status 746 +--ro if-selected? boolean {multi-src-dest}? 747 +--rw admin-status? te-types:te-admin-status 748 +--ro oper-status? te-types:te-oper-status 749 +--rw vn-level-diversity? te-types:te-path-disjointness 751 4.3.3. Others 753 The VN YANG model can be easily augmented to support the mapping of 754 VN to the Services such as L3SM and L2SM as described in 755 [I-D.ietf-teas-te-service-mapping-yang]. 757 The VN YANG model can be extended to support telemetry, performance 758 monitoring and network autonomics as described in 759 [I-D.ietf-teas-actn-pm-telemetry-autonomics]. 761 Note that the YANG model is tightly coupled with the TE Topology 762 model [RFC8795]. Any underlay technology not supported by [RFC8795] 763 is also not supported by this model. The model does include an empty 764 container called "underlay" that can be augmented. For example the 765 SR-policy information can be augmented for the SR underlay by a 766 future model. 768 Apart from the te-types:generic-path-constraints and te- 769 types:generic-path-optimization, an additional leaf cos for class of 770 service [RFC4124] is added to represent the Class-Type of traffic to 771 be used as one of the path constraints. 773 4.3.4. Summary 775 This section summarizes the innovative service features of the VN 776 YANG. 778 * Maintenance of AP and VNAP along with VN 780 * VN construct to group of edge-to-edge links 782 * VN Compute (pre-instantiate) 784 * Multi-Source / Multi-Destination 786 * Ability to support various VN and VNS Types 788 - VN Type 1: Customer configures the VN as a set of VN Members. 789 No other details need to be set by customer, making for a 790 simplified operations for the customer. 792 - VN Type 2: Along with VN Members, the customer could also 793 provide an abstract topology, this topology is provided by the 794 Abstract TE Topology YANG Model. 796 5. VN YANG Model (Tree Structure) 798 module: ietf-vn 799 +--rw access-point 800 | +--rw ap* [ap-id] 801 | +--rw ap-id ap-id 802 | +--rw pe? 803 | | -> /nw:networks/network/node/tet:te-node-id 804 | +--rw max-bandwidth? te-types:te-bandwidth 805 | +--rw avl-bandwidth? te-types:te-bandwidth 806 | +--rw vn-ap* [vn-ap-id] 807 | +--rw vn-ap-id ap-id 808 | +--rw vn? -> /virtual-network/vn/vn-id 809 | +--rw abstract-node? 810 | | -> /nw:networks/network/node/tet:te-node-id 811 | +--rw ltp? leafref 812 | +--ro max-bandwidth? te-types:te-bandwidth 813 +--rw virtual-network 814 +--rw vn* [vn-id] 815 +--rw vn-id vn-id 816 +--rw te-topology-identifier 817 | +--rw provider-id? te-global-id 818 | +--rw client-id? te-global-id 819 | +--rw topology-id? te-topology-id 820 +--rw abstract-node? 821 | -> /nw:networks/network/node/tet:te-node-id 822 +--rw vn-member* [vnm-id] 823 | +--rw vnm-id vnm-id 824 | +--rw src 825 | | +--rw src? -> /access-point/ap/ap-id 826 | | +--rw src-vn-ap-id? 827 | | | -> /access-point/ap/vn-ap/vn-ap-id 828 | | +--rw multi-src? boolean {multi-src-dest}? 829 | +--rw dest 830 | | +--rw dest? -> /access-point/ap/ap-id 831 | | +--rw dest-vn-ap-id? 832 | | | -> /access-point/ap/vn-ap/vn-ap-id 833 | | +--rw multi-dest? boolean {multi-src-dest}? 834 | +--rw connectivity-matrix-id? leafref 835 | +--rw underlay 836 | +--ro oper-status? te-types:te-oper-status 837 +--ro if-selected? boolean {multi-src-dest}? 838 +--rw admin-status? te-types:te-admin-status 839 +--ro oper-status? te-types:te-oper-status 840 +--rw vn-level-diversity? te-types:te-path-disjointness 842 rpcs: 843 +---x vn-compute 844 +---w input 845 | +---w te-topology-identifier 846 | | +---w provider-id? te-global-id 847 | | +---w client-id? te-global-id 848 | | +---w topology-id? te-topology-id 849 | +---w abstract-node? 850 | | -> /nw:networks/network/node/tet:te-node-id 851 | +---w path-constraints 852 | | +---w te-bandwidth 853 | | | +---w (technology)? 854 | | | ... 855 | | +---w link-protection? identityref 856 | | +---w setup-priority? uint8 857 | | +---w hold-priority? uint8 858 | | +---w signaling-type? identityref 859 | | +---w path-metric-bounds 860 | | | +---w path-metric-bound* [metric-type] 861 | | | ... 862 | | +---w path-affinities-values 863 | | | +---w path-affinities-value* [usage] 864 | | | ... 865 | | +---w path-affinity-names 866 | | | +---w path-affinity-name* [usage] 867 | | | ... 868 | | +---w path-srlgs-lists 869 | | | +---w path-srlgs-list* [usage] 870 | | | ... 871 | | +---w path-srlgs-names 872 | | | +---w path-srlgs-name* [usage] 873 | | | ... 874 | | +---w disjointness? te-path-disjointness 875 | +---w cos? te-types:te-ds-class 876 | +---w optimizations 877 | | +---w (algorithm)? 878 | | +--:(metric) {path-optimization-metric}? 879 | | | ... 880 | | +--:(objective-function) 881 | | {path-optimization-objective-function}? 882 | | ... 883 | +---w vn-member-list* [vnm-id] 884 | | +---w vnm-id vnm-id 885 | | +---w src 886 | | | +---w src? -> /access-point/ap/ap-id 887 | | | +---w src-vn-ap-id? 888 | | | | -> /access-point/ap/vn-ap/vn-ap-id 889 | | | +---w multi-src? boolean {multi-src-dest}? 890 | | +---w dest 891 | | | +---w dest? -> /access-point/ap/ap-id 892 | | | +---w dest-vn-ap-id? 893 | | | | -> /access-point/ap/vn-ap/vn-ap-id 894 | | | +---w multi-dest? boolean {multi-src-dest}? 895 | | +---w connectivity-matrix-id? leafref 896 | | +---w underlay 897 | | +---w path-constraints 898 | | | +---w te-bandwidth 899 | | | | ... 900 | | | +---w link-protection? identityref 901 | | | +---w setup-priority? uint8 902 | | | +---w hold-priority? uint8 903 | | | +---w signaling-type? identityref 904 | | | +---w path-metric-bounds 905 | | | | ... 906 | | | +---w path-affinities-values 907 | | | | ... 908 | | | +---w path-affinity-names 909 | | | | ... 910 | | | +---w path-srlgs-lists 911 | | | | ... 912 | | | +---w path-srlgs-names 913 | | | | ... 914 | | | +---w disjointness? te-path-disjointness 915 | | +---w cos? te-types:te-ds-class 916 | | +---w optimizations 917 | | +---w (algorithm)? 918 | | ... 919 | +---w vn-level-diversity? 920 | te-types:te-path-disjointness 921 +--ro output 922 +--ro te-topology-identifier 923 | +--ro provider-id? te-global-id 924 | +--ro client-id? te-global-id 925 | +--ro topology-id? te-topology-id 926 +--ro abstract-node? 927 | -> /nw:networks/network/node/tet:te-node-id 928 +--ro vn-member-list* [vnm-id] 929 +--ro vnm-id vnm-id 930 +--ro src 931 | +--ro src? -> /access-point/ap/ap-id 932 | +--ro src-vn-ap-id? 933 | | -> /access-point/ap/vn-ap/vn-ap-id 934 | +--ro multi-src? boolean {multi-src-dest}? 935 +--ro dest 936 | +--ro dest? -> /access-point/ap/ap-id 937 | +--ro dest-vn-ap-id? 938 | | -> /access-point/ap/vn-ap/vn-ap-id 939 | +--ro multi-dest? boolean {multi-src-dest}? 940 +--ro connectivity-matrix-id? leafref 941 +--ro underlay 942 +--ro if-selected? boolean 943 | {multi-src-dest}? 944 +--ro compute-status? vn-compute-status 945 +--ro error-info 946 +--ro error-description? string 947 +--ro error-timestamp? yang:date-and-time 948 +--ro error-reason? identityref 950 6. VN YANG Model 952 The YANG model is as follows: 954 file "ietf-vn@2022-03-07.yang" 955 module ietf-vn { 956 yang-version 1.1; 957 namespace "urn:ietf:params:xml:ns:yang:ietf-vn"; 958 prefix vn; 960 /* Import network */ 962 import ietf-yang-types { 963 prefix yang; 964 reference 965 "RFC 6991: Common YANG Data Types"; 966 } 967 import ietf-network { 968 prefix nw; 969 reference 970 "RFC 8345: A YANG Data Model for Network Topologies"; 971 } 973 /* Import network topology */ 975 import ietf-network-topology { 976 prefix nt; 977 reference 978 "RFC 8345: A YANG Data Model for Network Topologies"; 979 } 981 /* Import TE Common types */ 983 import ietf-te-types { 984 prefix te-types; 985 reference 986 "RFC 8776: Common YANG Data Types for Traffic Engineering"; 987 } 989 /* Import TE Topology */ 991 import ietf-te-topology { 992 prefix tet; 993 reference 994 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 995 Topologies"; 996 } 997 organization 998 "IETF Traffic Engineering Architecture and Signaling (TEAS) 999 Working Group"; 1000 contact 1001 "WG Web: 1002 WG List: 1003 Editor: Young Lee 1004 : Dhruv Dhody "; 1005 description 1006 "This module contains a YANG module for the Virtual Network 1007 (VN). It describes a VN operation module that takes place 1008 in the context of the Customer Network Controller (CNC)- 1009 Multi-Domain Service Coordinator (MSDC) interface (CMI) of 1010 the Abstraction and Control of Traffic Engineered Networks 1011 (ACTN) architecture where the CNC is the actor of a VN 1012 Instantiation/modification/deletion as per RFC 8453. 1014 Copyright (c) 2022 IETF Trust and the persons identified as 1015 authors of the code. All rights reserved. 1017 Redistribution and use in source and binary forms, with or 1018 without modification, is permitted pursuant to, and subject to 1019 the license terms contained in, the Revised BSD License set 1020 forth in Section 4.c of the IETF Trust's Legal Provisions 1021 Relating to IETF Documents 1022 (https://trustee.ietf.org/license-info). 1024 This version of this YANG module is part of RFC XXXX; see the 1025 RFC itself for full legal notices. 1027 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1028 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1029 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1030 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1031 they appear in all capitals, as shown here."; 1033 revision 2022-03-07 { 1034 description 1035 "initial version."; 1036 reference 1037 "RFC XXXX: A YANG Data Model for VN Operation"; 1038 } 1040 /* Features */ 1042 feature multi-src-dest { 1043 description 1044 "Support for selection of one src or destination 1045 among multiple."; 1046 reference 1047 "RFC 8453: Framework for Abstraction and Control of TE 1048 Networks (ACTN)"; 1049 } 1051 /* Typedef */ 1053 typedef vn-id { 1054 type string; 1055 description 1056 "Defines a type of Virtual Network (VN) identifier."; 1057 } 1059 typedef ap-id { 1060 type string; 1061 description 1062 "Defines a type of Access Point (AP) identifier."; 1063 } 1065 typedef vnm-id { 1066 type string; 1067 description 1068 "Defines a type of VN member identifier."; 1069 } 1071 typedef vn-compute-status { 1072 type te-types:te-common-status; 1073 description 1074 "Defines a type representing the VN compute status. Note 1075 that all status apart from up and down are considered as 1076 unknown."; 1077 } 1079 /* identities */ 1081 identity vn-computation-error-reason { 1082 description 1083 "Base identity for VN computation error reasons."; 1084 } 1086 identity vn-computation-error-not-ready { 1087 base vn-computation-error-reason; 1088 description 1089 "VN computation has failed because the MDSC is not 1090 ready"; 1091 } 1092 identity vn-computation-error-no-cnc { 1093 base vn-computation-error-reason; 1094 description 1095 "VN computation has failed because one or more dependent 1096 CNC are unavailable."; 1097 } 1099 identity vn-computation-error-no-resource { 1100 base vn-computation-error-reason; 1101 description 1102 "VN computation has failed because there is no 1103 available resource in one or more domains."; 1104 } 1106 identity vn-computation-error-path-not-found { 1107 base vn-computation-error-reason; 1108 description 1109 "VN computation failed as no path found."; 1110 } 1112 identity vn-computation-ap-unknown { 1113 base vn-computation-error-reason; 1114 description 1115 "VN computation failed as source or destination AP not 1116 known."; 1117 } 1119 /* Groupings */ 1121 grouping vn-ap { 1122 description 1123 "VNAP related information"; 1124 leaf vn-ap-id { 1125 type ap-id; 1126 description 1127 "A unique identifier for the referred VNAP"; 1128 } 1129 leaf vn { 1130 type leafref { 1131 path "/virtual-network/vn/vn-id"; 1132 } 1133 description 1134 "A reference to the VN"; 1135 } 1136 leaf abstract-node { 1137 type leafref { 1138 path "/nw:networks/nw:network/nw:node/tet:te-node-id"; 1139 } 1140 description 1141 "A reference to the abstract node in TE Topology that 1142 represent the VN"; 1143 } 1144 leaf ltp { 1145 type leafref { 1146 path "/nw:networks/nw:network/nw:node/" 1147 + "nt:termination-point/tet:te-tp-id"; 1148 } 1149 description 1150 "A reference to Link Termination Point (LTP) in the 1151 TE-topology"; 1152 reference 1153 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 1154 Topologies"; 1155 } 1156 leaf max-bandwidth { 1157 type te-types:te-bandwidth; 1158 config false; 1159 description 1160 "The max bandwidth of the VNAP"; 1161 } 1162 reference 1163 "RFC 8453: Framework for Abstraction and Control of TE 1164 Networks (ACTN), Section 6"; 1165 } //vn-ap 1167 grouping access-point { 1168 description 1169 "AP related information"; 1170 leaf ap-id { 1171 type ap-id; 1172 description 1173 "A unique identifier for the referred access point"; 1174 } 1175 leaf pe { 1176 type leafref { 1177 path "/nw:networks/nw:network/nw:node/tet:te-node-id"; 1178 } 1179 description 1180 "A reference to the PE node in the native TE Topology"; 1181 } 1182 leaf max-bandwidth { 1183 type te-types:te-bandwidth; 1184 description 1185 "The max bandwidth of the AP"; 1186 } 1187 leaf avl-bandwidth { 1188 type te-types:te-bandwidth; 1189 description 1190 "The available bandwidth of the AP"; 1191 } 1192 /*add details and any other properties of AP, 1193 not associated by a VN 1194 CE port, PE port etc. 1195 */ 1196 list vn-ap { 1197 key "vn-ap-id"; 1198 uses vn-ap; 1199 description 1200 "List of VNAP in this AP"; 1201 } 1202 reference 1203 "RFC 8453: Framework for Abstraction and Control of TE 1204 Networks (ACTN), Section 6"; 1205 } //access-point 1207 grouping vn-member { 1208 description 1209 "The vn-member is described by this grouping"; 1210 leaf vnm-id { 1211 type vnm-id; 1212 description 1213 "A vn-member identifier"; 1214 } 1215 container src { 1216 description 1217 "The source of VN Member"; 1218 leaf src { 1219 type leafref { 1220 path "/access-point/ap/ap-id"; 1221 } 1222 description 1223 "A reference to source AP"; 1224 } 1225 leaf src-vn-ap-id { 1226 type leafref { 1227 path "/access-point/ap/vn-ap/vn-ap-id"; 1228 } 1229 description 1230 "A reference to source VNAP"; 1231 } 1232 leaf multi-src { 1233 if-feature "multi-src-dest"; 1234 type boolean; 1235 default "false"; 1236 description 1237 "Is the source part of multi-source, where 1238 only one of the source is enabled"; 1239 } 1240 } 1241 container dest { 1242 description 1243 "the destination of VN Member"; 1244 leaf dest { 1245 type leafref { 1246 path "/access-point/ap/ap-id"; 1247 } 1248 description 1249 "A reference to destination AP"; 1250 } 1251 leaf dest-vn-ap-id { 1252 type leafref { 1253 path "/access-point/ap/vn-ap/vn-ap-id"; 1254 } 1255 description 1256 "A reference to dest VNAP"; 1257 } 1258 leaf multi-dest { 1259 if-feature "multi-src-dest"; 1260 type boolean; 1261 default "false"; 1262 description 1263 "Is destination part of multi-destination, where only one 1264 of the destination is enabled"; 1265 } 1266 } 1267 leaf connectivity-matrix-id { 1268 type leafref { 1269 path "/nw:networks/nw:network/nw:node/tet:te/" 1270 + "tet:te-node-attributes/" 1271 + "tet:connectivity-matrices/" 1272 + "tet:connectivity-matrix/tet:id"; 1273 } 1274 description 1275 "A reference to connectivity-matrix"; 1276 reference 1277 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 1278 Topologies"; 1279 } 1280 container underlay { 1281 description 1282 "An empty container that can be augmented with underlay 1283 technology information not supported by RFC 8795 (for 1284 example - Segement Routing (SR). "; 1285 } 1286 reference 1287 "RFC 8454: Information Model for Abstraction and Control of TE 1288 Networks (ACTN)"; 1289 } //vn-member 1291 grouping vn-policy { 1292 description 1293 "policy for VN-level diverisity"; 1294 leaf vn-level-diversity { 1295 type te-types:te-path-disjointness; 1296 description 1297 "The type of disjointness on the VN level (i.e., across all 1298 VN members)"; 1299 } 1300 } 1302 /* Configuration data nodes */ 1304 container access-point { 1305 description 1306 "AP configurations"; 1307 list ap { 1308 key "ap-id"; 1309 description 1310 "access-point identifier"; 1311 uses access-point { 1312 description 1313 "The access-point information"; 1314 } 1315 } 1316 reference 1317 "RFC 8453: Framework for Abstraction and Control of TE 1318 Networks (ACTN), Section 6"; 1319 } 1320 container virtual-network { 1321 description 1322 "VN configurations"; 1323 list vn { 1324 key "vn-id"; 1325 description 1326 "A virtual network is identified by a vn-id"; 1327 leaf vn-id { 1328 type vn-id; 1329 description 1330 "A unique VN identifier"; 1331 } 1332 /*An optional identifier to the TE Topology Model 1333 where the abstract nodes and links of the Topology 1334 can be found for Type 2 VNS*/ 1335 uses te-types:te-topology-identifier; 1336 leaf abstract-node { 1337 type leafref { 1338 path "/nw:networks/nw:network/nw:node/tet:te-node-id"; 1339 } 1340 description 1341 "A reference to the abstract node in TE Topology"; 1342 } 1343 list vn-member { 1344 key "vnm-id"; 1345 description 1346 "List of vn-members in a VN"; 1347 uses vn-member; 1348 leaf oper-status { 1349 type te-types:te-oper-status; 1350 config false; 1351 description 1352 "The vn-member operational state."; 1353 } 1354 } 1355 leaf if-selected { 1356 if-feature "multi-src-dest"; 1357 type boolean; 1358 default "false"; 1359 config false; 1360 description 1361 "Is the vn-member is selected among the multi-src/dest 1362 options"; 1363 } 1364 leaf admin-status { 1365 type te-types:te-admin-status; 1366 default "up"; 1367 description 1368 "VN administrative state."; 1369 } 1370 leaf oper-status { 1371 type te-types:te-oper-status; 1372 config false; 1373 description 1374 "VN operational state."; 1375 } 1376 uses vn-policy; 1377 } //vn 1378 reference 1379 "RFC 8453: Framework for Abstraction and Control of TE 1380 Networks (ACTN)"; 1381 } //vn 1383 /* RPC */ 1385 rpc vn-compute { 1386 description 1387 "The VN computation without actual instantiation. This is 1388 used by the CNC to get the VN results without actually 1389 creating it in the network. 1391 The input could include a reference to the single node 1392 abstract topology. It could optionally also include 1393 constraints and optimization criteria. The computation 1394 is done based on the list of VN-members. 1396 The output includes a reference to the single node 1397 abstract topology with each VN-member including a 1398 reference to the connectivity-matrix-id where the 1399 path properties could be found. Error information is 1400 also included."; 1401 input { 1402 uses te-types:te-topology-identifier; 1403 leaf abstract-node { 1404 type leafref { 1405 path "/nw:networks/nw:network/nw:node/tet:te-node-id"; 1406 } 1407 description 1408 "A reference to the abstract node in TE Topology"; 1409 } 1410 uses te-types:generic-path-constraints; 1411 leaf cos { 1412 type te-types:te-ds-class; 1413 description 1414 "The class of service"; 1415 } 1416 uses te-types:generic-path-optimization; 1417 list vn-member-list { 1418 key "vnm-id"; 1419 description 1420 "List of VN-members in a VN"; 1421 uses vn-member; 1422 uses te-types:generic-path-constraints; 1423 leaf cos { 1424 type te-types:te-ds-class; 1425 description 1426 "The class of service"; 1427 reference 1428 "RFC 4124: Protocol Extensions for Support of 1429 Diffserv-aware MPLS Traffic Engineering, 1430 Section 4.3.1"; 1431 } 1432 uses te-types:generic-path-optimization; 1433 } 1434 uses vn-policy; 1435 } 1436 output { 1437 uses te-types:te-topology-identifier; 1438 leaf abstract-node { 1439 type leafref { 1440 path "/nw:networks/nw:network/nw:node/tet:te-node-id"; 1441 } 1442 description 1443 "A reference to the abstract node in TE Topology"; 1444 } 1445 list vn-member-list { 1446 key "vnm-id"; 1447 description 1448 "List of VN-members in a VN"; 1449 uses vn-member; 1450 leaf if-selected { 1451 if-feature "multi-src-dest"; 1452 type boolean; 1453 default "false"; 1454 description 1455 "Is the vn-member is selected among the multi-src/dest 1456 options"; 1457 reference 1458 "RFC 8453: Framework for Abstraction and Control of TE 1459 Networks (ACTN), Section 7"; 1460 } 1461 leaf compute-status { 1462 type vn-compute-status; 1463 description 1464 "The VN-member compute state."; 1465 } 1466 container error-info { 1467 description 1468 "Error information related to the VN member"; 1469 leaf error-description { 1470 type string; 1471 description 1472 "Textual representation of the error occurred during 1473 VN compute."; 1474 } 1475 leaf error-timestamp { 1476 type yang:date-and-time; 1477 description 1478 "Timestamp of the attempt."; 1479 } 1480 leaf error-reason { 1481 type identityref { 1482 base vn-computation-error-reason; 1483 } 1484 description 1485 "Reason for the VN computation error."; 1486 } 1487 } 1488 } 1489 } 1490 } //vn-compute 1492 } 1493 1495 7. JSON Example 1497 This section provides json implementation examples as to how VN YANG 1498 model and TE topology model are used together to instantiate virtual 1499 networks. 1501 The example in this section includes following VN 1503 * VN1 (Type 1): Which maps to the single node topology abstract1 1504 (node D1) and consist of VN Members 104 (L1 to L4), 107 (L1 to 1505 L7), 204 (L2 to L4), 308 (L3 to L8) and 108 (L1 to L8). We also 1506 show how disjointness (node, link, srlg) is supported in the 1507 example on the global level (i.e., connectivity matrices level). 1509 * VN2 (Type 2): Which maps to the single node topology abstract2 1510 (node D2), this topology has an underlay topology (absolute) (see 1511 figure in section 3.2). This VN has a single VN member 105 (L1 to 1512 L5) and an underlay path (S4 and S7) has been set in the 1513 connectivity matrix of abstract2 topology; 1515 * VN3 (Type 1): This VN has a multi-source, multi-destination 1516 feature enable for VN Member 104 (L1 to L4)/107 (L1 to L7) {multi- 1517 src} and VN Member 204 (L2 to L4)/304 (L3 to L4) {multi-dest} 1518 usecase. The selected VN-member is known via the field "if- 1519 selected" and the corresponding connectivity-matrix-id. 1521 Note that the VN YANG model also include the AP and VNAP which shows 1522 various VN using the same AP. 1524 7.1. VN JSON 1526 { 1527 "access-point": { 1528 "ap": [ 1529 { 1530 "ap-id": "101", 1531 "vn-ap": [ 1532 { 1533 "vn-ap-id": "10101", 1534 "vn": "1", 1535 "abstract-node": "D1", 1536 "ltp": "1-0-1" 1537 }, 1538 { 1539 "vn-ap-id": "10102", 1540 "vn": "2", 1541 "abstract-node": "D2", 1542 "ltp": "1-0-1" 1543 }, 1544 { 1545 "vn-ap-id": "10103", 1546 "vn": "3", 1547 "abstract-node": "D3", 1548 "ltp": "1-0-1" 1549 } 1550 ] 1551 }, 1552 { 1553 "ap-id": "202", 1554 "vn-ap": [ 1555 { 1556 "vn-ap-id": "20201", 1557 "vn": "1", 1558 "abstract-node": "D1", 1559 "ltp": "2-0-2" 1560 } 1561 ] 1562 }, 1563 { 1564 "ap-id": "303", 1565 "vn-ap": [ 1566 { 1567 "vn-ap-id": "30301", 1568 "vn": "1", 1569 "abstract-node": "D1", 1570 "ltp": "3-0-3" 1571 }, 1572 { 1573 "vn-ap-id": "30303", 1574 "vn": "3", 1575 "abstract-node": "D3", 1576 "ltp": "3-0-3" 1577 } 1578 ] 1579 }, 1580 { 1581 "ap-id": "440", 1582 "vn-ap": [ 1583 { 1584 "vn-ap-id": "44001", 1585 "vn": "1", 1586 "abstract-node": "D1", 1587 "ltp": "4-4-0" 1588 } 1589 ] 1590 }, 1591 { 1592 "ap-id": "550", 1593 "vn-ap": [ 1594 { 1595 "vn-ap-id": "55002", 1596 "vn": "2", 1597 "abstract-node": "D2", 1598 "ltp": "5-5-0" 1599 } 1600 ] 1601 }, 1602 { 1603 "ap-id": "770", 1604 "vn-ap": [ 1605 { 1606 "vn-ap-id": "77001", 1607 "vn": "1", 1608 "abstract-node": "D1", 1609 "ltp": "7-7-0" 1610 }, 1611 { 1612 "vn-ap-id": "77003", 1613 "vn": "3", 1614 "abstract-node": "D3", 1615 "ltp": "7-7-0" 1616 } 1617 ] 1618 }, 1619 { 1620 "ap-id": "880", 1621 "vn-ap": [ 1622 { 1623 "vn-ap-id": "88001", 1624 "vn": "1", 1625 "abstract-node": "D1", 1626 "ltp": "8-8-0" 1627 }, 1628 { 1629 "vn-ap-id": "88003", 1630 "vn": "3", 1631 "abstract-node": "D3", 1632 "ltp": "8-8-0" 1633 } 1634 ] 1635 } 1636 ] 1637 }, 1638 "virtual-network": { 1639 "vn": [ 1640 { 1641 "vn-id": "1", 1642 "te-topology-identifier": { 1643 "topology-id": "abstract1" 1644 }, 1645 "abstract-node": "D1", 1646 "vn-member": [ 1647 { 1648 "vnm-id": "104", 1649 "src": { 1650 "src": "101", 1651 "src-vn-ap-id": "10101" 1652 }, 1653 "dest": { 1654 "dest": "440", 1655 "dest-vn-ap-id": "44001" 1656 }, 1657 "connectivity-matrix-id": "104" 1658 }, 1659 { 1660 "vnm-id": "107", 1661 "src": { 1662 "src": "101", 1663 "src-vn-ap-id": "10101" 1664 }, 1665 "dest": { 1666 "dest": "770", 1667 "dest-vn-ap-id": "77001" 1669 }, 1670 "connectivity-matrix-id": "107" 1671 }, 1672 { 1673 "vnm-id": "204", 1674 "src": { 1675 "src": "202", 1676 "dest-vn-ap-id": "20401" 1677 }, 1678 "dest": { 1679 "dest": "440", 1680 "dest-vn-ap-id": "44001" 1681 }, 1682 "connectivity-matrix-id": "204" 1683 }, 1684 { 1685 "vnm-id": "308", 1686 "src": { 1687 "src": "303", 1688 "src-vn-ap-id": "30301" 1689 }, 1690 "dest": { 1691 "dest": "880", 1692 "src-vn-ap-id": "88001" 1693 }, 1694 "connectivity-matrix-id": "308" 1695 }, 1696 { 1697 "vnm-id": "108", 1698 "src": { 1699 "src": "101", 1700 "src-vn-ap-id": "10101" 1701 }, 1702 "dest": { 1703 "dest": "880", 1704 "dest-vn-ap-id": "88001" 1705 }, 1706 "connectivity-matrix-id": "108" 1707 } 1708 ] 1709 }, 1710 { 1711 "vn-id": "2", 1712 "te-topology-identifier": { 1713 "topology-id": "abstract2" 1714 }, 1715 "abstract-node": "D2", 1716 "vn-member": [ 1717 { 1718 "vnm-id": "105", 1719 "src": { 1720 "src": "101", 1721 "src-vn-ap-id": "10102" 1722 }, 1723 "dest": { 1724 "dest": "550", 1725 "dest-vn-ap-id": "55002" 1726 }, 1727 "connectivity-matrix-id": "105" 1728 } 1729 ] 1730 }, 1731 { 1732 "vn-id": "3", 1733 "te-topology-identifier": { 1734 "topology-id": "abstract3" 1735 }, 1736 "abstract-node": "D3", 1737 "vn-member": [ 1738 { 1739 "vnm-id": "104", 1740 "src": { 1741 "src": "101" 1742 }, 1743 "dest": { 1744 "dest": "440", 1745 "multi-dest": true 1746 } 1747 }, 1748 { 1749 "vnm-id": "107", 1750 "src": { 1751 "src": "101", 1752 "src-vn-ap-id": "10103" 1753 }, 1754 "dest": { 1755 "dest": "770", 1756 "dest-vn-ap-id": "77003", 1757 "multi-dest": true 1758 }, 1759 "connectivity-matrix-id": "107", 1760 "if-selected": true 1761 }, 1762 { 1763 "vnm-id": "204", 1764 "src": { 1765 "src": "202", 1766 "multi-src": true 1767 }, 1768 "dest": { 1769 "dest": "440" 1770 } 1771 }, 1772 { 1773 "vnm-id": "304", 1774 "src": { 1775 "src": "303", 1776 "src-vn-ap-id": "30303", 1777 "multi-src": true 1778 }, 1779 "dest": { 1780 "dest": "440", 1781 "src-vn-ap-id": "44003" 1782 }, 1783 "connectivity-matrix-id": "304", 1784 "if-selected": true 1785 } 1786 ] 1787 } 1788 ] 1789 } 1790 } 1792 7.2. TE-topology JSON 1794 { 1795 "networks": { 1796 "network": [ 1797 { 1798 "network-types": { 1799 "te-topology": {} 1800 }, 1801 "network-id": "abstract1", 1802 "te-topology-identifier": { 1803 "provider-id": 0, 1804 "client-id": 0, 1805 "topology-id": "abstract1" 1806 }, 1807 "node": [ 1808 { 1809 "node-id": "D1", 1810 "te-node-id": "2.0.1.1", 1811 "te": { 1812 "te-node-attributes": { 1813 "domain-id": 1, 1814 "is-abstract": [ 1815 null 1816 ], 1817 "connectivity-matrices": { 1818 "is-allowed": true, 1819 "path-constraints": { 1820 "te-bandwidth": { 1821 "generic": "0x1p10" 1822 }, 1823 "disjointness": "node link srlg" 1824 }, 1825 "connectivity-matrix": [ 1826 { 1827 "id": 104, 1828 "from": { 1829 "tp-ref": "1-0-1" 1830 }, 1831 "to": { 1832 "tp-ref": "4-4-0" 1833 } 1834 }, 1835 { 1836 "id": 107, 1837 "from": { 1838 "tp-ref": "1-0-1" 1839 }, 1840 "to": { 1841 "tp-ref": "7-7-0" 1842 } 1843 }, 1844 { 1845 "id": 204, 1846 "from": { 1847 "tp-ref": "2-0-2" 1848 }, 1849 "to": { 1850 "tp-ref": "4-4-0" 1851 } 1852 }, 1853 { 1854 "id": 308, 1855 "from": { 1856 "tp-ref": "3-0-3" 1857 }, 1858 "to": { 1859 "tp-ref": "8-8-0" 1860 } 1862 }, 1863 { 1864 "id": 108, 1865 "from": { 1866 "tp-ref": "1-0-1" 1867 }, 1868 "to": { 1869 "tp-ref": "8-8-0" 1870 } 1871 } 1872 ] 1873 } 1874 }, 1875 "tunnel-termination-point": [ 1876 { 1877 "name": "1-0-1", 1878 "tunnel-tp-id": 10001, 1879 "switching-capability": "switching-otn", 1880 "encoding": "lsp-encoding-oduk" 1881 }, 1882 { 1883 "name": "1-1-0", 1884 "tunnel-tp-id": 10100, 1885 "switching-capability": "switching-otn", 1886 "encoding": "lsp-encoding-oduk" 1887 }, 1888 { 1889 "name": "2-0-2", 1890 "tunnel-tp-id": 20002, 1891 "switching-capability": "switching-otn", 1892 "encoding": "lsp-encoding-oduk" 1893 }, 1894 { 1895 "name": "2-2-0", 1896 "tunnel-tp-id": 20200, 1897 "switching-capability": "switching-otn", 1898 "encoding": "lsp-encoding-oduk" 1899 }, 1900 { 1901 "name": "3-0-3", 1902 "tunnel-tp-id": 30003, 1903 "switching-capability": "switching-otn", 1904 "encoding": "lsp-encoding-oduk" 1905 }, 1906 { 1907 "name": "3-3-0", 1908 "tunnel-tp-id": 30300, 1909 "switching-capability": "switching-otn", 1910 "encoding": "lsp-encoding-oduk" 1911 }, 1912 { 1913 "name": "4-0-4", 1914 "tunnel-tp-id": 40004, 1915 "switching-capability": "switching-otn", 1916 "encoding": "lsp-encoding-oduk" 1917 }, 1918 { 1919 "name": "4-4-0", 1920 "tunnel-tp-id": 40400, 1921 "switching-capability": "switching-otn", 1922 "encoding": "lsp-encoding-oduk" 1923 }, 1924 { 1925 "name": "5-0-5", 1926 "tunnel-tp-id": 50005, 1927 "switching-capability": "switching-otn", 1928 "encoding": "lsp-encoding-oduk" 1929 }, 1930 { 1931 "name": "5-5-0", 1932 "tunnel-tp-id": 50500, 1933 "switching-capability": "switching-otn", 1934 "encoding": "lsp-encoding-oduk" 1935 }, 1936 { 1937 "name": "6-0-6", 1938 "tunnel-tp-id": 60006, 1939 "switching-capability": "switching-otn", 1940 "encoding": "lsp-encoding-oduk" 1941 }, 1942 { 1943 "name": "6-6-0", 1944 "tunnel-tp-id": 60600, 1945 "switching-capability": "switching-otn", 1946 "encoding": "lsp-encoding-oduk" 1947 }, 1948 { 1949 "name": "7-0-7", 1950 "tunnel-tp-id": 70007, 1951 "switching-capability": "switching-otn", 1952 "encoding": "lsp-encoding-oduk" 1953 }, 1954 { 1955 "name": "7-7-0", 1956 "tunnel-tp-id": 70700, 1957 "switching-capability": "switching-otn", 1958 "encoding": "lsp-encoding-oduk" 1959 }, 1960 { 1961 "name": "8-0-8", 1962 "tunnel-tp-id": 80008, 1963 "switching-capability": "switching-otn", 1964 "encoding": "lsp-encoding-oduk" 1965 }, 1966 { 1967 "name": "8-8-0", 1968 "tunnel-tp-id": 80800, 1969 "switching-capability": "switching-otn", 1970 "encoding": "lsp-encoding-oduk" 1971 } 1972 ] 1973 } 1974 } 1975 ] 1976 }, 1977 { 1978 "network-types": { 1979 "te-topology": {} 1980 }, 1981 "network-id": "abstract2", 1982 "te-topology-identifier": { 1983 "provider-id": 0, 1984 "client-id": 0, 1985 "topology-id": "abstract2" 1986 }, 1987 "node": [ 1988 { 1989 "node-id": "D2", 1990 "te-node-id": "2.0.1.2", 1991 "te": { 1992 "te-node-attributes": { 1993 "domain-id": 1, 1994 "is-abstract": [ 1995 null 1996 ], 1997 "connectivity-matrices": { 1998 "is-allowed": true, 1999 "underlay": { 2000 "enabled": true 2001 }, 2002 "path-constraints": { 2003 "te-bandwidth": { 2004 "generic": "0x1p10" 2005 } 2007 }, 2008 "optimizations": { 2009 "objective-function": { 2010 "objective-function-type": "of-maximize-residual-bandwidth" 2011 } 2012 }, 2013 "connectivity-matrix": [ 2014 { 2015 "id": 105, 2016 "from": { 2017 "tp-ref": "1-0-1" 2018 }, 2019 "to": { 2020 "tp-ref": "5-5-0" 2021 }, 2022 "underlay": { 2023 "enabled": true, 2024 "primary-path": { 2025 "network-ref": "absolute", 2026 "path-element": [ 2027 { 2028 "path-element-id": 1, 2029 "numbered-node-hop": { 2030 "node-id": "4.4.4.4", 2031 "hop-type": "strict" 2032 } 2033 }, 2034 { 2035 "path-element-id": 2, 2036 "numbered-hop": { 2037 "node-id": "7.7.7.7", 2038 "hop-type": "strict" 2039 } 2040 } 2041 ] 2042 } 2043 } 2044 } 2045 ] 2046 } 2047 }, 2048 "tunnel-termination-point": [ 2049 { 2050 "name": "1-0-1", 2051 "tunnel-tp-id": 10001, 2052 "switching-capability": "switching-otn", 2053 "encoding": "lsp-encoding-oduk" 2054 }, 2055 { 2056 "name": "1-1-0", 2057 "tunnel-tp-id": 10100, 2058 "switching-capability": "switching-otn", 2059 "encoding": "lsp-encoding-oduk" 2060 }, 2061 { 2062 "name": "2-0-2", 2063 "tunnel-tp-id": 20002, 2064 "switching-capability": "switching-otn", 2065 "encoding": "lsp-encoding-oduk" 2066 }, 2067 { 2068 "name": "2-2-0", 2069 "tunnel-tp-id": 20200, 2070 "switching-capability": "switching-otn", 2071 "encoding": "lsp-encoding-oduk" 2072 }, 2073 { 2074 "name": "3-0-3", 2075 "tunnel-tp-id": 30003, 2076 "switching-capability": "switching-otn", 2077 "encoding": "lsp-encoding-oduk" 2078 }, 2079 { 2080 "name": "3-3-0", 2081 "tunnel-tp-id": 30300, 2082 "switching-capability": "switching-otn", 2083 "encoding": "lsp-encoding-oduk" 2084 }, 2085 { 2086 "name": "4-0-4", 2087 "tunnel-tp-id": 40004, 2088 "switching-capability": "switching-otn", 2089 "encoding": "lsp-encoding-oduk" 2090 }, 2091 { 2092 "name": "4-4-0", 2093 "tunnel-tp-id": 40400, 2094 "switching-capability": "switching-otn", 2095 "encoding": "lsp-encoding-oduk" 2096 }, 2097 { 2098 "name": "5-0-5", 2099 "tunnel-tp-id": 50005, 2100 "switching-capability": "switching-otn", 2101 "encoding": "lsp-encoding-oduk" 2102 }, 2103 { 2104 "name": "5-5-0", 2105 "tunnel-tp-id": 50500, 2106 "switching-capability": "switching-otn", 2107 "encoding": "lsp-encoding-oduk" 2108 }, 2109 { 2110 "name": "6-0-6", 2111 "tunnel-tp-id": 60006, 2112 "switching-capability": "switching-otn", 2113 "encoding": "lsp-encoding-oduk" 2114 }, 2115 { 2116 "name": "6-6-0", 2117 "tunnel-tp-id": 60600, 2118 "switching-capability": "switching-otn", 2119 "encoding": "lsp-encoding-oduk" 2120 }, 2121 { 2122 "name": "7-0-7", 2123 "tunnel-tp-id": 70007, 2124 "switching-capability": "switching-otn", 2125 "encoding": "lsp-encoding-oduk" 2126 }, 2127 { 2128 "name": "7-7-0", 2129 "tunnel-tp-id": 70700, 2130 "switching-capability": "switching-otn", 2131 "encoding": "lsp-encoding-oduk" 2132 }, 2133 { 2134 "name": "8-0-8", 2135 "tunnel-tp-id": 80008, 2136 "switching-capability": "switching-otn", 2137 "encoding": "lsp-encoding-oduk" 2138 }, 2139 { 2140 "name": "8-8-0", 2141 "tunnel-tp-id": 80800, 2142 "switching-capability": "switching-otn", 2143 "encoding": "lsp-encoding-oduk" 2144 } 2145 ] 2146 } 2147 } 2148 ] 2149 }, 2150 { 2151 "network-types": { 2152 "te-topology": {} 2153 }, 2154 "network-id": "abstract3", 2155 "te-topology-identifier": { 2156 "provider-id": 0, 2157 "client-id": 0, 2158 "topology-id": "abstract3" 2159 }, 2160 "node": [ 2161 { 2162 "node-id": "D3", 2163 "te-node-id": "3.0.1.1", 2164 "te": { 2165 "te-node-attributes": { 2166 "domain-id": 3, 2167 "is-abstract": [ 2168 null 2169 ], 2170 "connectivity-matrices": { 2171 "is-allowed": true, 2172 "path-constraints": { 2173 "te-bandwidth": { 2174 "generic": "0x1p10" 2175 } 2176 }, 2177 "connectivity-matrix": [ 2178 { 2179 "id": 107, 2180 "from": { 2181 "tp-ref": "1-0-1" 2182 }, 2183 "to": { 2184 "tp-ref": "7-7-0" 2185 } 2186 }, 2187 { 2188 "id": 308, 2189 "from": { 2190 "tp-ref": "3-0-3" 2191 }, 2192 "to": { 2193 "tp-ref": "8-8-0" 2194 } 2195 } 2196 ] 2197 } 2198 }, 2199 "tunnel-termination-point": [ 2200 { 2201 "name": "1-0-1", 2202 "tunnel-tp-id": 10001, 2203 "switching-capability": "switching-otn", 2204 "encoding": "lsp-encoding-oduk" 2205 }, 2206 { 2207 "name": "1-1-0", 2208 "tunnel-tp-id": 10100, 2209 "switching-capability": "switching-otn", 2210 "encoding": "lsp-encoding-oduk" 2211 }, 2212 { 2213 "name": "2-0-2", 2214 "tunnel-tp-id": 20002, 2215 "switching-capability": "switching-otn", 2216 "encoding": "lsp-encoding-oduk" 2217 }, 2218 { 2219 "name": "2-2-0", 2220 "tunnel-tp-id": 20200, 2221 "switching-capability": "switching-otn", 2222 "encoding": "lsp-encoding-oduk" 2223 }, 2224 { 2225 "name": "3-0-3", 2226 "tunnel-tp-id": 30003, 2227 "switching-capability": "switching-otn", 2228 "encoding": "lsp-encoding-oduk" 2229 }, 2230 { 2231 "name": "3-3-0", 2232 "tunnel-tp-id": 30300, 2233 "switching-capability": "switching-otn", 2234 "encoding": "lsp-encoding-oduk" 2235 }, 2236 { 2237 "name": "4-0-4", 2238 "tunnel-tp-id": 40004, 2239 "switching-capability": "switching-otn", 2240 "encoding": "lsp-encoding-oduk" 2241 }, 2242 { 2243 "name": "4-4-0", 2244 "tunnel-tp-id": 40400, 2245 "switching-capability": "switching-otn", 2246 "encoding": "lsp-encoding-oduk" 2248 }, 2249 { 2250 "name": "5-0-5", 2251 "tunnel-tp-id": 50005, 2252 "switching-capability": "switching-otn", 2253 "encoding": "lsp-encoding-oduk" 2254 }, 2255 { 2256 "name": "5-5-0", 2257 "tunnel-tp-id": 50500, 2258 "switching-capability": "switching-otn", 2259 "encoding": "lsp-encoding-oduk" 2260 }, 2261 { 2262 "name": "6-0-6", 2263 "tunnel-tp-id": 60006, 2264 "switching-capability": "switching-otn", 2265 "encoding": "lsp-encoding-oduk" 2266 }, 2267 { 2268 "name": "6-6-0", 2269 "tunnel-tp-id": 60600, 2270 "switching-capability": "switching-otn", 2271 "encoding": "lsp-encoding-oduk" 2272 }, 2273 { 2274 "name": "7-0-7", 2275 "tunnel-tp-id": 70007, 2276 "switching-capability": "switching-otn", 2277 "encoding": "lsp-encoding-oduk" 2278 }, 2279 { 2280 "name": "7-7-0", 2281 "tunnel-tp-id": 70700, 2282 "switching-capability": "switching-otn", 2283 "encoding": "lsp-encoding-oduk" 2284 }, 2285 { 2286 "name": "8-0-8", 2287 "tunnel-tp-id": 80008, 2288 "switching-capability": "switching-otn", 2289 "encoding": "lsp-encoding-oduk" 2290 }, 2291 { 2292 "name": "8-8-0", 2293 "tunnel-tp-id": 80800, 2294 "switching-capability": "switching-otn", 2295 "encoding": "lsp-encoding-oduk" 2297 } 2298 ] 2299 } 2300 } 2301 ] 2302 } 2303 ] 2304 } 2305 } 2307 8. Security Considerations 2309 The configuration, state, and action data defined in this document 2310 are designed to be accessed via a management protocol with a secure 2311 transport layer, such as NETCONF [RFC6241] or RESTCONF [RFC8040]. 2312 The lowest NETCONF layer is the secure transport layer, and the 2313 mandatory-to-implement secure transport is Secure Shell (SSH) 2314 [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory- 2315 to-implement secure transport is TLS [RFC8446]. 2317 The NETCONF access control model [RFC8341] provides the means to 2318 restrict access for particular NETCONF users to a preconfigured 2319 subset of all available NETCONF protocol operations and content. 2321 The model presented in this document is used in the interface between 2322 the Customer Network Controller (CNC) and Multi-Domain Service 2323 Coordinator (MDSC), which is referred to as CNC-MDSC Interface (CMI). 2324 Therefore, many security risks such as malicious attack and rogue 2325 elements attempting to connect to various ACTN components. 2326 Furthermore, some ACTN components (e.g., MSDC) represent a single 2327 point of failure and threat vector and must also manage policy 2328 conflicts and eavesdropping of communication between different ACTN 2329 components. 2331 A number of configuration data nodes defined in this document are 2332 writable/deletable (i.e., "config true") These data nodes may be 2333 considered sensitive or vulnerable in some network environments. 2335 These are the subtrees and data nodes and their sensitivity/ 2336 vulnerability: 2338 * ap: 2340 - ap-id 2342 - max-bandwidth 2344 - avl-bandwidth 2346 * vn-ap: 2348 - vn-ap-id 2350 - vn 2352 - abstract-node 2354 - ltp 2356 * vn 2358 - vn-id 2360 - vn-topology-id 2362 - abstract-node 2364 * vnm-id 2366 - src 2368 - src-vn-ap-id 2370 - dest 2372 - dest-vn-ap-id 2374 - connectivity-matrix-id 2376 9. IANA Considerations 2378 IANA is requested to make the following allocation for the URIs in 2379 the "ns" subregistry within the "IETF XML Registry" [RFC3688]: 2381 -------------------------------------------------------------------- 2382 URI: urn:ietf:params:xml:ns:yang:ietf-vn 2383 Registrant Contact: The IESG. 2384 XML: N/A, the requested URI is an XML namespace. 2385 -------------------------------------------------------------------- 2387 IANA is requested to make the following allocation for the YANG 2388 module in the "YANG Module Names" registry [RFC6020]: 2390 -------------------------------------------------------------------- 2391 name: ietf-vn 2392 namespace: urn:ietf:params:xml:ns:yang:ietf-vn 2393 prefix: vn 2394 reference: RFC XXXX 2395 -------------------------------------------------------------------- 2397 10. Acknowledgments 2399 The authors would like to thank Xufeng Liu, Adrian Farrel, and Tom 2400 Petch for their helpful comments and valuable suggestions. 2402 Thanks to Andy Bierman for YANGDIR review. 2404 11. References 2406 11.1. Normative References 2408 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2409 Requirement Levels", BCP 14, RFC 2119, 2410 DOI 10.17487/RFC2119, March 1997, 2411 . 2413 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2414 DOI 10.17487/RFC3688, January 2004, 2415 . 2417 [RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of 2418 Diffserv-aware MPLS Traffic Engineering", RFC 4124, 2419 DOI 10.17487/RFC4124, June 2005, 2420 . 2422 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2423 the Network Configuration Protocol (NETCONF)", RFC 6020, 2424 DOI 10.17487/RFC6020, October 2010, 2425 . 2427 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2428 and A. Bierman, Ed., "Network Configuration Protocol 2429 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2430 . 2432 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2433 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2434 . 2436 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2437 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2438 . 2440 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2441 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2442 . 2444 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2445 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2446 . 2448 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2449 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2450 May 2017, . 2452 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2453 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2454 . 2456 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2457 Access Control Model", STD 91, RFC 8341, 2458 DOI 10.17487/RFC8341, March 2018, 2459 . 2461 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2462 and R. Wilton, "Network Management Datastore Architecture 2463 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 2464 . 2466 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 2467 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 2468 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2469 2018, . 2471 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2472 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2473 . 2475 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 2476 "Common YANG Data Types for Traffic Engineering", 2477 RFC 8776, DOI 10.17487/RFC8776, June 2020, 2478 . 2480 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 2481 O. Gonzalez de Dios, "YANG Data Model for Traffic 2482 Engineering (TE) Topologies", RFC 8795, 2483 DOI 10.17487/RFC8795, August 2020, 2484 . 2486 11.2. Informative References 2488 [I-D.ietf-ccamp-l1csm-yang] 2489 Lee, Y., Lee, K., Zheng, H., Dios, O. G. D., and D. 2490 Ceccarelli, "A YANG Data Model for L1 Connectivity Service 2491 Model (L1CSM)", Work in Progress, Internet-Draft, draft- 2492 ietf-ccamp-l1csm-yang-16, 13 December 2021, 2493 . 2496 [I-D.ietf-teas-actn-pm-telemetry-autonomics] 2497 Lee, Y., Dhody, D., Karunanithi, S., Vilalta, R., King, 2498 D., and D. Ceccarelli, "YANG models for VN/TE Performance 2499 Monitoring Telemetry and Scaling Intent Autonomics", Work 2500 in Progress, Internet-Draft, draft-ietf-teas-actn-pm- 2501 telemetry-autonomics-07, 23 October 2021, 2502 . 2505 [I-D.ietf-teas-te-service-mapping-yang] 2506 Lee, Y., Dhody, D., Fioccola, G., Wu, Q., Ceccarelli, D., 2507 and J. Tantsura, "Traffic Engineering (TE) and Service 2508 Mapping YANG Model", Work in Progress, Internet-Draft, 2509 draft-ietf-teas-te-service-mapping-yang-09, 24 October 2510 2021, . 2513 [I-D.ietf-teas-yang-te] 2514 Saad, T., Gandhi, R., Liu, X., Beeram, V. P., Bryskin, I., 2515 and O. G. D. Dios, "A YANG Data Model for Traffic 2516 Engineering Tunnels, Label Switched Paths and Interfaces", 2517 Work in Progress, Internet-Draft, draft-ietf-teas-yang-te- 2518 29, 7 February 2022, 2519 . 2522 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 2523 Ceccarelli, D., and X. Zhang, "Problem Statement and 2524 Architecture for Information Exchange between 2525 Interconnected Traffic-Engineered Networks", BCP 206, 2526 RFC 7926, DOI 10.17487/RFC7926, July 2016, 2527 . 2529 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 2530 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 2531 DOI 10.17487/RFC8299, January 2018, 2532 . 2534 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 2535 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 2536 . 2538 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 2539 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 2540 DOI 10.17487/RFC8453, August 2018, 2541 . 2543 [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. 2544 Yoon, "Information Model for Abstraction and Control of TE 2545 Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, 2546 September 2018, . 2548 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 2549 Data Model for Layer 2 Virtual Private Network (L2VPN) 2550 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2551 2018, . 2553 Appendix A. Performance Constraints 2555 At the time of creation of VN, it is natural to provide VN level 2556 constraints and optimization criteria. It should be noted that this 2557 YANG model rely on the TE-Topology Model [RFC8795] by using a 2558 reference to an abstract node to achieve this. Further, 2559 connectivity-matrix structure is used to assign the constraints and 2560 optimization criteria include delay, jitter etc. [RFC8776] define 2561 some of the metric-types already and future documents are meant to 2562 augment it. 2564 Note that the VN compute allows inclusion of the constraints and the 2565 optimization criteria directly in the RPC to allow it to be used 2566 independently. 2568 Appendix B. Contributors Addresses 2569 Qin Wu 2570 Huawei Technologies 2571 Email: bill.wu@huawei.com 2573 Peter Park 2574 KT 2575 Email: peter.park@kt.com 2577 Haomian Zheng 2578 Huawei Technologies 2579 Email: zhenghaomian@huawei.com 2581 Xian Zhang 2582 Huawei Technologies 2583 Email: zhang.xian@huawei.com 2585 Sergio Belotti 2586 Nokia 2587 Email: sergio.belotti@nokia.com 2589 Takuya Miyasaka 2590 KDDI 2591 Email: ta-miyasaka@kddi.com 2593 Kenichi Ogaki 2594 KDDI 2595 Email: ke-oogaki@kddi.com 2597 Authors' Addresses 2599 Young Lee (editor) 2600 Samsung Electronics 2601 Email: younglee.tx@gmail.com 2603 Dhruv Dhody (editor) 2604 Huawei Technologies 2605 Divyashree Techno Park, Whitefield 2606 Bangalore 560066 2607 Karnataka 2608 India 2609 Email: dhruv.ietf@gmail.com 2611 Daniele Ceccarelli 2612 Ericsson 2613 Torshamnsgatan,48 2614 Stockholm, Sweden 2615 Email: daniele.ceccarelli@ericsson.com 2617 Igor Bryskin 2618 Individual 2619 Email: i_bryskin@yahoo.com 2621 Bin Yeong Yoon 2622 ETRI 2623 Email: byyun@etri.re.kr