idnits 2.17.1 draft-ietf-teas-actn-vn-yang-12.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 : ---------------------------------------------------------------------------- No issues found here. 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 (25 August 2021) is 975 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 (-36) exists of draft-ietf-teas-yang-te-27 == Outdated reference: A later version (-26) exists of draft-ietf-ccamp-l1csm-yang-14 == Outdated reference: A later version (-12) exists of draft-ietf-teas-actn-pm-telemetry-autonomics-05 == Outdated reference: A later version (-15) exists of draft-ietf-teas-te-service-mapping-yang-07 Summary: 0 errors (**), 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: 26 February 2022 Huawei Technologies 6 D. Ceccarelli 7 Ericsson 8 I. Bryskin 9 Individual 10 B. Yoon 11 ETRI 12 25 August 2021 14 A YANG Data Model for VN Operation 15 draft-ietf-teas-actn-vn-yang-12 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 26 February 2022. 39 Copyright Notice 41 Copyright (c) 2021 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 Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified 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 . . . . . . . . 15 73 4.3.3. Others . . . . . . . . . . . . . . . . . . . . . . . 16 74 4.3.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 16 75 5. VN YANG Model (Tree Structure) . . . . . . . . . . . . . . . 17 76 6. VN YANG Model . . . . . . . . . . . . . . . . . . . . . . . . 20 77 7. JSON Example . . . . . . . . . . . . . . . . . . . . . . . . 31 78 7.1. VN JSON . . . . . . . . . . . . . . . . . . . . . . . . . 31 79 7.2. TE-topology JSON . . . . . . . . . . . . . . . . . . . . 37 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 53 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 82 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 55 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 55 85 11.2. Informative References . . . . . . . . . . . . . . . . . 57 86 Appendix A. Performance Constraints . . . . . . . . . . . . . . 59 87 Appendix B. Contributors Addresses . . . . . . . . . . . . . . . 59 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 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 | te-topo | 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 abstract-node? 602 | | -> /nw:networks/network/node/tet:te-node-id 603 | +---w path-constraints 604 | | ... 605 | +---w optimizations 606 | | ... 607 | +---w vn-member-list* [vnm-id] 608 | | +---w vnm-id vnm-id 609 | | +---w src 610 | | | +---w src? -> /access-point/ap/ap-id 611 | | | +---w src-vn-ap-id? -> /access-point/ap/vn-ap/vn-ap-id 612 | | | +---w multi-src? boolean {multi-src-dest}? 613 | | +---w dest 614 | | | +---w dest? -> /access-point/ap/ap-id 615 | | | +---w dest-vn-ap-id? -> /access-point/ap/vn-ap/vn-ap-id 616 | | | +---w multi-dest? boolean {multi-src-dest}? 617 | | +---w connectivity-matrix-id? leafref 618 | | +--rw underlay 619 | | +---w path-constraints 620 | | | | ... 621 | | +---w optimizations 622 | | ... 623 | +---w vn-level-diversity? te-types:te-path-disjointness 624 +--ro output 625 +--ro abstract-node? 626 | -> /nw:networks/network/node/tet:te-node-id 627 +--ro vn-member-list* [vnm-id] 628 +--ro vnm-id vnm-id 629 +--ro src 630 | +--ro src? -> /access-point/ap/ap-id 631 | +--ro src-vn-ap-id? -> /access-point/ap/vn-ap/vn-ap-id 632 | +--ro multi-src? boolean {multi-src-dest}? 633 +--ro dest 634 | +--ro dest? -> /access-point/ap/ap-id 635 | +--ro dest-vn-ap-id? -> /access-point/ap/vn-ap/vn-ap-id 636 | +--ro multi-dest? boolean {multi-src-dest}? 637 +--ro connectivity-matrix-id? leafref 638 +--rw underlay 639 +--ro if-selected? boolean 640 | {multi-src-dest}? 641 +--ro compute-status? vn-compute-status 642 +--ro error-info 643 +--ro error-description? string 644 +--ro error-timestamp? yang:date-and-time 645 +--ro error-reason? identityref 647 4.3.2. Multi-sources and Multi-destinations 649 In creating a virtual network, the list of sources or destinations or 650 both may not be pre-determined by the customer. For instance, for a 651 given source, there may be a list of multiple-destinations to which 652 the optimal destination may be chosen depending on the network 653 resource situations. Likewise, for a given destination, there may 654 also be multiple-sources from which the optimal source may be chosen. 655 In some cases, there may be a pool of multiple sources and 656 destinations from which the optimal source-destination may be chosen. 657 The following YANG module is shown for describing source container 658 and destination container. The following YANG tree shows how to 659 model multi-sources and multi-destinations. 661 +--rw virtual-network 662 +--rw vn* [vn-id] 663 +--rw vn-id vn-id 664 +--rw vn-topology-id? te-types:te-topology-id 665 +--rw abstract-node? 666 | -> /nw:networks/network/node/tet:te-node-id 667 +--rw vn-member* [vnm-id] 668 | +--rw vnm-id vnm-id 669 | +--rw src 670 | | +--rw src? -> /access-point/ap/ap-id 671 | | +--rw src-vn-ap-id? -> /access-point/ap/vn-ap/vn-ap-id 672 | | +--rw multi-src? boolean {multi-src-dest}? 673 | +--rw dest 674 | | +--rw dest? -> /access-point/ap/ap-id 675 | | +--rw dest-vn-ap-id? -> /access-point/ap/vn-ap/vn-ap-id 676 | | +--rw multi-dest? boolean {multi-src-dest}? 677 | +--rw connectivity-matrix-id? leafref 678 | +--rw underlay 679 | +--ro oper-status? te-types:te-oper-status 680 +--ro if-selected? boolean {multi-src-dest}? 681 +--rw admin-status? te-types:te-admin-status 682 +--ro oper-status? te-types:te-oper-status 683 +--rw vn-level-diversity? te-types:te-path-disjointness 685 4.3.3. Others 687 The VN YANG model can be easily augmented to support the mapping of 688 VN to the Services such as L3SM and L2SM as described in 689 [I-D.ietf-teas-te-service-mapping-yang]. 691 The VN YANG model can be extended to support telemetry, performance 692 monitoring and network autonomics as described in 693 [I-D.ietf-teas-actn-pm-telemetry-autonomics]. 695 Note that the YANG model is tightly coupled with the TE Topology 696 model [RFC8795]. Any underlay technology not supported by [RFC8795] 697 is also not supported by this model. The model does include an empty 698 container called "underlay" that can be augmented. For example the 699 SR-policy information can be augmented for the SR underlay by a 700 future model. 702 4.3.4. Summary 704 This section summarizes the innovative service features of the VN 705 YANG. 707 * Maintenance of AP and VNAP along with VN 708 * VN construct to group of edge-to-edge links 710 * VN Compute (pre-instantiate) 712 * Multi-Source / Multi-Destination 714 * Ability to support various VN and VNS Types 716 - VN Type 1: Customer configures the VN as a set of VN Members. 717 No other details need to be set by customer, making for a 718 simplified operations for the customer. 720 - VN Type 2: Along with VN Members, the customer could also 721 provide an abstract topology, this topology is provided by the 722 Abstract TE Topology YANG Model. 724 5. VN YANG Model (Tree Structure) 726 module: ietf-vn 727 +--rw access-point 728 | +--rw ap* [ap-id] 729 | +--rw ap-id ap-id 730 | +--rw pe? 731 | | -> /nw:networks/network/node/tet:te-node-id 732 | +--rw max-bandwidth? te-types:te-bandwidth 733 | +--rw avl-bandwidth? te-types:te-bandwidth 734 | +--rw vn-ap* [vn-ap-id] 735 | +--rw vn-ap-id ap-id 736 | +--rw vn? -> /virtual-network/vn/vn-id 737 | +--rw abstract-node? 738 | | -> /nw:networks/network/node/tet:te-node-id 739 | +--rw ltp? leafref 740 | +--ro max-bandwidth? te-types:te-bandwidth 741 +--rw virtual-network 742 +--rw vn* [vn-id] 743 +--rw vn-id vn-id 744 +--rw vn-topology-id? te-types:te-topology-id 745 +--rw abstract-node? 746 | -> /nw:networks/network/node/tet:te-node-id 747 +--rw vn-member* [vnm-id] 748 | +--rw vnm-id vnm-id 749 | +--rw src 750 | | +--rw src? -> /access-point/ap/ap-id 751 | | +--rw src-vn-ap-id? 752 | | | -> /access-point/ap/vn-ap/vn-ap-id 753 | | +--rw multi-src? boolean {multi-src-dest}? 754 | +--rw dest 755 | | +--rw dest? -> /access-point/ap/ap-id 756 | | +--rw dest-vn-ap-id? 757 | | | -> /access-point/ap/vn-ap/vn-ap-id 758 | | +--rw multi-dest? boolean {multi-src-dest}? 759 | +--rw connectivity-matrix-id? leafref 760 | +--rw underlay 761 | +--ro oper-status? te-types:te-oper-status 762 +--ro if-selected? boolean {multi-src-dest}? 763 +--rw admin-status? te-types:te-admin-status 764 +--ro oper-status? te-types:te-oper-status 765 +--rw vn-level-diversity? te-types:te-path-disjointness 767 rpcs: 768 +---x vn-compute 769 +---w input 770 | +---w abstract-node? 771 | | -> /nw:networks/network/node/tet:te-node-id 772 | +---w path-constraints 773 | | +---w te-bandwidth 774 | | | +---w (technology)? 775 | | | ... 776 | | +---w link-protection? identityref 777 | | +---w setup-priority? uint8 778 | | +---w hold-priority? uint8 779 | | +---w signaling-type? identityref 780 | | +---w path-metric-bounds 781 | | | +---w path-metric-bound* [metric-type] 782 | | | ... 783 | | +---w path-affinities-values 784 | | | +---w path-affinities-value* [usage] 785 | | | ... 786 | | +---w path-affinity-names 787 | | | +---w path-affinity-name* [usage] 788 | | | ... 789 | | +---w path-srlgs-lists 790 | | | +---w path-srlgs-list* [usage] 791 | | | ... 792 | | +---w path-srlgs-names 793 | | | +---w path-srlgs-name* [usage] 794 | | | ... 795 | | +---w disjointness? te-path-disjointness 796 | +---w optimizations 797 | | +---w (algorithm)? 798 | | +--:(metric) {path-optimization-metric}? 799 | | | ... 800 | | +--:(objective-function) 801 | | {path-optimization-objective-function}? 802 | | ... 803 | +---w vn-member-list* [vnm-id] 804 | | +---w vnm-id vnm-id 805 | | +---w src 806 | | | +---w src? -> /access-point/ap/ap-id 807 | | | +---w src-vn-ap-id? 808 | | | | -> /access-point/ap/vn-ap/vn-ap-id 809 | | | +---w multi-src? boolean {multi-src-dest}? 810 | | +---w dest 811 | | | +---w dest? -> /access-point/ap/ap-id 812 | | | +---w dest-vn-ap-id? 813 | | | | -> /access-point/ap/vn-ap/vn-ap-id 814 | | | +---w multi-dest? boolean {multi-src-dest}? 815 | | +---w connectivity-matrix-id? leafref 816 | | +---w underlay 817 | | +---w path-constraints 818 | | | +---w te-bandwidth 819 | | | | ... 820 | | | +---w link-protection? identityref 821 | | | +---w setup-priority? uint8 822 | | | +---w hold-priority? uint8 823 | | | +---w signaling-type? identityref 824 | | | +---w path-metric-bounds 825 | | | | ... 826 | | | +---w path-affinities-values 827 | | | | ... 828 | | | +---w path-affinity-names 829 | | | | ... 830 | | | +---w path-srlgs-lists 831 | | | | ... 832 | | | +---w path-srlgs-names 833 | | | | ... 834 | | | +---w disjointness? te-path-disjointness 835 | | +---w optimizations 836 | | +---w (algorithm)? 837 | | ... 838 | +---w vn-level-diversity? te-types:te-path-disjointness 839 +--ro output 840 +--ro abstract-node? 841 | -> /nw:networks/network/node/tet:te-node-id 842 +--ro vn-member-list* [vnm-id] 843 +--ro vnm-id vnm-id 844 +--ro src 845 | +--ro src? -> /access-point/ap/ap-id 846 | +--ro src-vn-ap-id? 847 | | -> /access-point/ap/vn-ap/vn-ap-id 848 | +--ro multi-src? boolean {multi-src-dest}? 849 +--ro dest 850 | +--ro dest? -> /access-point/ap/ap-id 851 | +--ro dest-vn-ap-id? 852 | | -> /access-point/ap/vn-ap/vn-ap-id 853 | +--ro multi-dest? boolean {multi-src-dest}? 854 +--ro connectivity-matrix-id? leafref 855 +--ro underlay 856 +--ro if-selected? boolean 857 | {multi-src-dest}? 858 +--ro compute-status? vn-compute-status 859 +--ro error-info 860 +--ro error-description? string 861 +--ro error-timestamp? yang:date-and-time 862 +--ro error-reason? identityref 864 6. VN YANG Model 866 The YANG model is as follows: 868 file "ietf-vn@2021-08-25.yang" 869 module ietf-vn { 870 yang-version 1.1; 871 namespace "urn:ietf:params:xml:ns:yang:ietf-vn"; 872 prefix vn; 874 /* Import network */ 876 import ietf-yang-types { 877 prefix yang; 878 reference 879 "RFC 6991: Common YANG Data Types"; 880 } 881 import ietf-network { 882 prefix nw; 883 reference 884 "RFC 8345: A YANG Data Model for Network Topologies"; 885 } 887 /* Import network topology */ 889 import ietf-network-topology { 890 prefix nt; 891 reference 892 "RFC 8345: A YANG Data Model for Network Topologies"; 893 } 895 /* Import TE Common types */ 897 import ietf-te-types { 898 prefix te-types; 899 reference 900 "RFC 8776: Common YANG Data Types for Traffic Engineering"; 901 } 903 /* Import TE Topology */ 905 import ietf-te-topology { 906 prefix tet; 907 reference 908 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 909 Topologies"; 910 } 912 organization 913 "IETF Traffic Engineering Architecture and Signaling (TEAS) 914 Working Group"; 915 contact 916 "WG Web: 917 WG List: 918 Editor: Young Lee 919 : Dhruv Dhody "; 920 description 921 "This module contains a YANG module for the VN. It describes a 922 VN operation module that takes place in the context of the 923 CNC-MDSC Interface (CMI) of the ACTN architecture where the 924 CNC is the actor of a VN Instantiation/modification/deletion 925 as per RFC 8453. 927 Copyright (c) 2021 IETF Trust and the persons identified as 928 authors of the code. All rights reserved. 930 Redistribution and use in source and binary forms, with or 931 without modification, is permitted pursuant to, and subject to 932 the license terms contained in, the Simplified BSD License set 933 forth in Section 4.c of the IETF Trust's Legal Provisions 934 Relating to IETF Documents 935 (https://trustee.ietf.org/license-info). 937 This version of this YANG module is part of RFC XXXX; see the 938 RFC itself for full legal notices. 940 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 941 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 942 'MAY', and 'OPTIONAL' in this document are to be interpreted as 943 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 944 they appear in all capitals, as shown here."; 946 revision 2021-08-25 { 947 description 948 "initial version."; 949 reference 950 "RFC XXXX: A YANG Data Model for VN Operation"; 951 } 953 /* Features */ 955 feature multi-src-dest { 956 description 957 "Support for selection of one src or destination 958 among multiple."; 959 reference 960 "RFC 8453: Framework for Abstraction and Control of TE 961 Networks (ACTN)"; 962 } 964 /* Typedef */ 966 typedef vn-id { 967 type string; 968 description 969 "Defines a type of Virtual Network (VN) identifier."; 970 } 972 typedef ap-id { 973 type string; 974 description 975 "Defines a type of Access Point (AP) identifier."; 976 } 978 typedef vnm-id { 979 type string; 980 description 981 "Defines a type of VN member identifier."; 982 } 984 typedef vn-compute-status { 985 type te-types:te-common-status; 986 description 987 "Defines a type representing the VN compute status. Note 988 that all status apart from up and down are considered as 989 unknown."; 990 } 992 /* identities */ 994 identity vn-computation-error-reason { 995 description 996 "Base identity for VN computation error reasons."; 997 } 999 identity vn-computation-error-not-ready { 1000 base vn-computation-error-reason; 1001 description 1002 "VN computation has failed because the MDSC is not 1003 ready"; 1004 } 1006 identity vn-computation-error-no-cnc { 1007 base vn-computation-error-reason; 1008 description 1009 "VN computation has failed because one or more dependent 1010 CNC are unavailable."; 1011 } 1013 identity vn-computation-error-no-resource { 1014 base vn-computation-error-reason; 1015 description 1016 "VN computation has failed because there is no 1017 available resource in one or more domains."; 1018 } 1020 identity vn-computation-error-path-not-found { 1021 base vn-computation-error-reason; 1022 description 1023 "VN computation failed as no path found."; 1024 } 1026 identity vn-computation-ap-unknown { 1027 base vn-computation-error-reason; 1028 description 1029 "VN computation failed as source or destination AP not 1030 known."; 1031 } 1033 /* Groupings */ 1035 grouping vn-ap { 1036 description 1037 "VNAP related information"; 1038 leaf vn-ap-id { 1039 type ap-id; 1040 description 1041 "A unique identifier for the referred VNAP"; 1042 } 1043 leaf vn { 1044 type leafref { 1045 path "/virtual-network/vn/vn-id"; 1046 } 1047 description 1048 "A reference to the VN"; 1049 } 1050 leaf abstract-node { 1051 type leafref { 1052 path "/nw:networks/nw:network/nw:node/tet:te-node-id"; 1053 } 1054 description 1055 "A reference to the abstract node in TE Topology that 1056 represent the VN"; 1057 } 1058 leaf ltp { 1059 type leafref { 1060 path "/nw:networks/nw:network/nw:node/" 1061 + "nt:termination-point/tet:te-tp-id"; 1062 } 1063 description 1064 "A reference to Link Termination Point (LTP) in the 1065 TE-topology"; 1066 reference 1067 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 1068 Topologies"; 1069 } 1070 leaf max-bandwidth { 1071 type te-types:te-bandwidth; 1072 config false; 1073 description 1074 "The max bandwidth of the VNAP"; 1075 } 1076 reference 1077 "RFC 8453: Framework for Abstraction and Control of TE 1078 Networks (ACTN), Section 6"; 1079 } //vn-ap 1081 grouping access-point { 1082 description 1083 "AP related information"; 1084 leaf ap-id { 1085 type ap-id; 1086 description 1087 "A unique identifier for the referred access point"; 1088 } 1089 leaf pe { 1090 type leafref { 1091 path "/nw:networks/nw:network/nw:node/tet:te-node-id"; 1093 } 1094 description 1095 "A reference to the PE node in the native TE Topology"; 1096 } 1097 leaf max-bandwidth { 1098 type te-types:te-bandwidth; 1099 description 1100 "The max bandwidth of the AP"; 1101 } 1102 leaf avl-bandwidth { 1103 type te-types:te-bandwidth; 1104 description 1105 "The available bandwidth of the AP"; 1106 } 1107 /*add details and any other properties of AP, 1108 not associated by a VN 1109 CE port, PE port etc. 1110 */ 1111 list vn-ap { 1112 key "vn-ap-id"; 1113 uses vn-ap; 1114 description 1115 "List of VNAP in this AP"; 1116 } 1117 reference 1118 "RFC 8453: Framework for Abstraction and Control of TE 1119 Networks (ACTN), Section 6"; 1120 } //access-point 1122 grouping vn-member { 1123 description 1124 "The vn-member is described by this grouping"; 1125 leaf vnm-id { 1126 type vnm-id; 1127 description 1128 "A vn-member identifier"; 1129 } 1130 container src { 1131 description 1132 "The source of VN Member"; 1133 leaf src { 1134 type leafref { 1135 path "/access-point/ap/ap-id"; 1136 } 1137 description 1138 "A reference to source AP"; 1139 } 1140 leaf src-vn-ap-id { 1141 type leafref { 1142 path "/access-point/ap/vn-ap/vn-ap-id"; 1143 } 1144 description 1145 "A reference to source VNAP"; 1146 } 1147 leaf multi-src { 1148 if-feature "multi-src-dest"; 1149 type boolean; 1150 default "false"; 1151 description 1152 "Is the source part of multi-source, where 1153 only one of the source is enabled"; 1154 } 1155 } 1156 container dest { 1157 description 1158 "the destination of VN Member"; 1159 leaf dest { 1160 type leafref { 1161 path "/access-point/ap/ap-id"; 1162 } 1163 description 1164 "A reference to destination AP"; 1165 } 1166 leaf dest-vn-ap-id { 1167 type leafref { 1168 path "/access-point/ap/vn-ap/vn-ap-id"; 1169 } 1170 description 1171 "A reference to dest VNAP"; 1172 } 1173 leaf multi-dest { 1174 if-feature "multi-src-dest"; 1175 type boolean; 1176 default "false"; 1177 description 1178 "Is destination part of multi-destination, where only one 1179 of the destination is enabled"; 1180 } 1181 } 1182 leaf connectivity-matrix-id { 1183 type leafref { 1184 path "/nw:networks/nw:network/nw:node/tet:te/" 1185 + "tet:te-node-attributes/" 1186 + "tet:connectivity-matrices/" 1187 + "tet:connectivity-matrix/tet:id"; 1188 } 1189 description 1190 "A reference to connectivity-matrix"; 1191 reference 1192 "RFC 8795: YANG Data Model for Traffic Engineering (TE) 1193 Topologies"; 1194 } 1195 container underlay { 1196 description 1197 "An empty container that can be augmented with underlay 1198 technology information not supported by RFC 8795 (for 1199 example - Segement Routing (SR). "; 1200 } 1201 reference 1202 "RFC 8454: Information Model for Abstraction and Control of TE 1203 Networks (ACTN)"; 1204 } //vn-member 1206 grouping vn-policy { 1207 description 1208 "policy for VN-level diverisity"; 1209 leaf vn-level-diversity { 1210 type te-types:te-path-disjointness; 1211 description 1212 "The type of disjointness on the VN level (i.e., across all 1213 VN members)"; 1214 } 1215 } 1217 /* Configuration data nodes */ 1219 container access-point { 1220 description 1221 "AP configurations"; 1222 list ap { 1223 key "ap-id"; 1224 description 1225 "access-point identifier"; 1226 uses access-point { 1227 description 1228 "The access-point information"; 1229 } 1230 } 1231 reference 1232 "RFC 8453: Framework for Abstraction and Control of TE 1233 Networks (ACTN), Section 6"; 1234 } 1235 container virtual-network { 1236 description 1237 "VN configurations"; 1238 list vn { 1239 key "vn-id"; 1240 description 1241 "A virtual network is identified by a vn-id"; 1242 leaf vn-id { 1243 type vn-id; 1244 description 1245 "A unique VN identifier"; 1246 } 1247 leaf vn-topology-id { 1248 type te-types:te-topology-id; 1249 description 1250 "An optional identifier to the TE Topology Model where the 1251 abstract nodes and links of the Topology can be found for 1252 Type 2 VNS"; 1253 } 1254 leaf abstract-node { 1255 type leafref { 1256 path "/nw:networks/nw:network/nw:node/tet:te-node-id"; 1257 } 1258 description 1259 "A reference to the abstract node in TE Topology"; 1260 } 1261 list vn-member { 1262 key "vnm-id"; 1263 description 1264 "List of vn-members in a VN"; 1265 uses vn-member; 1266 leaf oper-status { 1267 type te-types:te-oper-status; 1268 config false; 1269 description 1270 "The vn-member operational state."; 1271 } 1272 } 1273 leaf if-selected { 1274 if-feature "multi-src-dest"; 1275 type boolean; 1276 default "false"; 1277 config false; 1278 description 1279 "Is the vn-member is selected among the multi-src/dest 1280 options"; 1281 } 1282 leaf admin-status { 1283 type te-types:te-admin-status; 1284 default "up"; 1285 description 1286 "VN administrative state."; 1287 } 1288 leaf oper-status { 1289 type te-types:te-oper-status; 1290 config false; 1291 description 1292 "VN operational state."; 1293 } 1294 uses vn-policy; 1295 } //vn 1296 reference 1297 "RFC 8453: Framework for Abstraction and Control of TE 1298 Networks (ACTN)"; 1299 } //vn 1301 /* RPC */ 1303 rpc vn-compute { 1304 description 1305 "The VN computation without actual instantiation. This is 1306 used by the CNC to get the VN results without actually 1307 creating it in the network. 1309 The input could include a reference to the single node 1310 abstract topology. It could optionally also include 1311 constraints and optimization criteria. The computation 1312 is done based on the list of VN-members. 1314 The output includes a reference to the single node 1315 abstract topology with each VN-member including a 1316 reference to the connectivity-matrix-id where the 1317 path properties could be found. Error information is 1318 also included."; 1319 input { 1320 leaf abstract-node { 1321 type leafref { 1322 path "/nw:networks/nw:network/nw:node/tet:te-node-id"; 1323 } 1324 description 1325 "A reference to the abstract node in TE Topology"; 1326 } 1327 uses te-types:generic-path-constraints; 1328 uses te-types:generic-path-optimization; 1329 list vn-member-list { 1330 key "vnm-id"; 1331 description 1332 "List of VN-members in a VN"; 1334 uses vn-member; 1335 uses te-types:generic-path-constraints; 1336 uses te-types:generic-path-optimization; 1337 } 1338 uses vn-policy; 1339 } 1340 output { 1341 leaf abstract-node { 1342 type leafref { 1343 path "/nw:networks/nw:network/nw:node/tet:te-node-id"; 1344 } 1345 description 1346 "A reference to the abstract node in TE Topology"; 1347 } 1348 list vn-member-list { 1349 key "vnm-id"; 1350 description 1351 "List of VN-members in a VN"; 1352 uses vn-member; 1353 leaf if-selected { 1354 if-feature "multi-src-dest"; 1355 type boolean; 1356 default "false"; 1357 description 1358 "Is the vn-member is selected among the multi-src/dest 1359 options"; 1360 reference 1361 "RFC 8453: Framework for Abstraction and Control of TE 1362 Networks (ACTN), Section 7"; 1363 } 1364 leaf compute-status { 1365 type vn-compute-status; 1366 description 1367 "The VN-member compute state."; 1368 } 1369 container error-info { 1370 description 1371 "Error information related to the VN member"; 1372 leaf error-description { 1373 type string; 1374 description 1375 "Textual representation of the error occurred during 1376 VN compute."; 1377 } 1378 leaf error-timestamp { 1379 type yang:date-and-time; 1380 description 1381 "Timestamp of the attempt."; 1383 } 1384 leaf error-reason { 1385 type identityref { 1386 base vn-computation-error-reason; 1387 } 1388 description 1389 "Reason for the VN computation error."; 1390 } 1391 } 1392 } 1393 } 1394 } //vn-compute 1396 } 1397 1399 7. JSON Example 1401 This section provides json implementation examples as to how VN YANG 1402 model and TE topology model are used together to instantiate virtual 1403 networks. 1405 The example in this section includes following VN 1407 * VN1 (Type 1): Which maps to the single node topology abstract1 1408 (node D1) and consist of VN Members 104 (L1 to L4), 107 (L1 to 1409 L7), 204 (L2 to L4), 308 (L3 to L8) and 108 (L1 to L8). We also 1410 show how disjointness (node, link, srlg) is supported in the 1411 example on the global level (i.e., connectivity matrices level). 1413 * VN2 (Type 2): Which maps to the single node topology abstract2 1414 (node D2), this topology has an underlay topology (absolute) (see 1415 figure in section 3.2). This VN has a single VN member 105 (L1 to 1416 L5) and an underlay path (S4 and S7) has been set in the 1417 connectivity matrix of abstract2 topology; 1419 * VN3 (Type 1): This VN has a multi-source, multi-destination 1420 feature enable for VN Member 104 (L1 to L4)/107 (L1 to L7) {multi- 1421 src} and VN Member 204 (L2 to L4)/304 (L3 to L4) {multi-dest} 1422 usecase. The selected VN-member is known via the field "if- 1423 selected" and the corresponding connectivity-matrix-id. 1425 Note that the VN YANG model also include the AP and VNAP which shows 1426 various VN using the same AP. 1428 7.1. VN JSON 1429 { 1430 "access-point":{ 1431 "ap": [ 1432 { 1433 "ap-id": "101", 1434 "vn-ap": [ 1435 { 1436 "vn-ap-id": "10101", 1437 "vn": "1", 1438 "abstract-node": "D1", 1439 "ltp": "1-0-1" 1440 }, 1441 { 1442 "vn-ap-id": "10102", 1443 "vn": "2", 1444 "abstract-node": "D2", 1445 "ltp": "1-0-1" 1446 }, 1447 { 1448 "vn-ap-id": "10103", 1449 "vn": "3", 1450 "abstract-node": "D3", 1451 "ltp": "1-0-1" 1452 }, 1453 ] 1454 }, 1455 { 1456 "ap-id": "202", 1457 "vn-ap": [ 1458 { 1459 "vn-ap-id": "20201", 1460 "vn": "1", 1461 "abstract-node": "D1", 1462 "ltp": "2-0-2" 1463 } 1464 ] 1465 }, 1466 { 1467 "ap-id": "303", 1468 "vn-ap": [ 1469 { 1470 "vn-ap-id": "30301", 1471 "vn": "1", 1472 "abstract-node": "D1", 1473 "ltp": "3-0-3" 1474 }, 1475 { 1476 "vn-ap-id": "30303", 1477 "vn": "3", 1478 "abstract-node": "D3", 1479 "ltp": "3-0-3" 1480 } 1481 ] 1482 }, 1483 { 1484 "ap-id": "440", 1485 "vn-ap": [ 1486 { 1487 "vn-ap-id": "44001", 1488 "vn": "1", 1489 "abstract-node": "D1", 1490 "ltp": "4-4-0" 1491 } 1492 ] 1493 }, 1494 { 1495 "ap-id": "550", 1496 "vn-ap": [ 1497 { 1498 "vn-ap-id": "55002", 1499 "vn": "2", 1500 "abstract-node": "D2", 1501 "ltp": "5-5-0" 1502 } 1503 ] 1504 }, 1505 { 1506 "ap-id": "770", 1507 "vn-ap": [ 1508 { 1509 "vn-ap-id": "77001", 1510 "vn": "1", 1511 "abstract-node": "D1", 1512 "ltp": "7-7-0" 1513 }, 1514 { 1515 "vn-ap-id": "77003", 1516 "vn": "3", 1517 "abstract-node": "D3", 1518 "ltp": "7-7-0" 1519 } 1520 ] 1521 }, 1522 { 1523 "ap-id": "880", 1524 "vn-ap": [ 1525 { 1526 "vn-ap-id": "88001", 1527 "vn": "1", 1528 "abstract-node": "D1", 1529 "ltp": "8-8-0" 1530 }, 1531 { 1532 "vn-ap-id": "88003", 1533 "vn": "3", 1534 "abstract-node": "D3", 1535 "ltp": "8-8-0" 1536 } 1537 ] 1538 } 1539 ] 1540 }, 1541 "virtual-network":{ 1542 "vn": [ 1543 { 1544 "vn-id": "1", 1545 "vn-topology-id": "te-topology:abstract1", 1546 "abstract-node": "D1", 1547 "vn-member": [ 1548 { 1549 "vnm-id": "104", 1550 "src": { 1551 "src": "101", 1552 "src-vn-ap-id": "10101", 1553 }, 1554 "dest": { 1555 "dest": "440", 1556 "dest-vn-ap-id": "44001", 1557 }, 1558 "connectivity-matrix-id": 104 1559 }, 1560 { 1561 "vnm-id": "107", 1562 "src": { 1563 "src": "101", 1564 "src-vn-ap-id": "10101", 1565 }, 1566 "dest": { 1567 "dest": "770", 1568 "dest-vn-ap-id": "77001", 1569 }, 1570 "connectivity-matrix-id": 107 1571 }, 1572 { 1573 "vnm-id": "204", 1574 "src": { 1575 "src": "202", 1576 "dest-vn-ap-id": "20401", 1577 }, 1578 "dest": { 1579 "dest": "440", 1580 "dest-vn-ap-id": "44001", 1581 }, 1582 "connectivity-matrix-id": 204 1583 }, 1584 { 1585 "vnm-id": "308", 1586 "src": { 1587 "src": "303", 1588 "src-vn-ap-id": "30301", 1589 }, 1590 "dest": { 1591 "dest": "880", 1592 "src-vn-ap-id": "88001", 1593 }, 1594 "connectivity-matrix-id": 308 1595 }, 1596 { 1597 "vnm-id": "108", 1598 "src": { 1599 "src": "101", 1600 "src-vn-ap-id": "10101", 1601 }, 1602 "dest": { 1603 "dest": "880", 1604 "dest-vn-ap-id": "88001", 1605 }, 1606 "connectivity-matrix-id": "108" 1607 } 1608 ] 1609 }, 1610 { 1611 "vn-id": "2", 1612 "vn-topology-id": "te-topology:abstract2", 1613 "abstract-node": "D2", 1614 "vn-member": [ 1615 { 1616 "vnm-id": "105", 1617 "src": { 1618 "src": "101", 1619 "src-vn-ap-id": "10102", 1620 }, 1621 "dest": { 1622 "dest": "550", 1623 "dest-vn-ap-id": "55002", 1624 }, 1625 "connectivity-matrix-id": 105 1626 } 1627 ] 1628 }, 1629 { 1630 "vn-id": "3", 1631 "vn-topology-id": "te-topology:abstract3", 1632 "abstract-node": "D3", 1633 "vn-member": [ 1634 { 1635 "vnm-id": "104", 1636 "src": { 1637 "src": "101", 1638 }, 1639 "dest": { 1640 "dest": "440", 1641 "multi-dest": true 1642 } 1643 }, 1644 { 1645 "vnm-id": "107", 1646 "src": { 1647 "src": "101", 1648 "src-vn-ap-id": "10103", 1649 }, 1650 "dest": { 1651 "dest": "770", 1652 "dest-vn-ap-id": "77003", 1653 "multi-dest": true 1654 }, 1655 "connectivity-matrix-id": 107, 1656 "if-selected":true, 1657 }, 1658 { 1659 "vnm-id": "204", 1660 "src": { 1661 "src": "202", 1662 "multi-src": true, 1663 }, 1664 "dest": { 1665 "dest": "440", 1666 }, 1667 }, 1668 { 1669 "vnm-id": "304", 1670 "src": { 1671 "src": "303", 1672 "src-vn-ap-id": "30303", 1673 "multi-src": true, 1674 }, 1675 "dest": { 1676 "dest": "440", 1677 "src-vn-ap-id": "44003", 1678 }, 1679 "connectivity-matrix-id": 304, 1680 "if-selected":true, 1681 }, 1682 ] 1683 }, 1685 ] 1686 } 1688 } 1689 } 1691 7.2. TE-topology JSON 1693 { 1694 "networks": { 1695 "network": [ 1696 { 1697 "network-types": { 1698 "te-topology": {} 1699 }, 1700 "network-id": "abstract1", 1701 "provider-id": 201, 1702 "client-id": 600, 1703 "te-topology-id": "te-topology:abstract1", 1704 "node": [ 1705 { 1706 "node-id": "D1", 1707 "te-node-id": "2.0.1.1", 1708 "te": { 1710 "te-node-attributes": { 1711 "domain-id" : 1, 1712 "is-abstract": [null], 1713 "connectivity-matrices": { 1714 "is-allowed": true, 1715 "path-constraints": { 1716 "bandwidth-generic": { 1717 "te-bandwidth": { 1718 "generic": [ 1719 { 1720 "generic": "0x1p10", 1721 } 1722 ] 1723 } 1724 } 1725 "disjointness": "node link srlg", 1727 }, 1728 "connectivity-matrix": [ 1729 { 1730 "id": 104, 1731 "from": "1-0-1", 1732 "to": "4-4-0" 1733 }, 1734 { 1735 "id": 107, 1736 "from": "1-0-1", 1737 "to": "7-7-0" 1738 }, 1739 { 1740 "id": 204, 1741 "from": "2-0-2", 1742 "to": "4-4-0" 1743 }, 1744 { 1745 "id": 308, 1746 "from": "3-0-3", 1747 "to": "8-8-0" 1748 }, 1749 { 1750 "id": 108, 1751 "from": "1-0-1", 1752 "to": "8-8-0" 1753 }, 1754 ] 1755 } 1756 } 1757 }, 1758 "termination-point": [ 1760 { 1761 "tp-id": "1-0-1", 1762 "te-tp-id": 10001, 1763 "te": { 1764 "interface-switching-capability": [ 1765 { 1766 "switching-capability": "switching-otn", 1767 "encoding": "lsp-encoding-oduk" 1768 } 1769 ] 1770 } 1771 }, 1772 { 1773 "tp-id": "1-1-0", 1774 "te-tp-id": 10100, 1775 "te": { 1776 "interface-switching-capability": [ 1777 { 1778 "switching-capability": "switching-otn", 1779 "encoding": "lsp-encoding-oduk" 1780 } 1781 ] 1782 } 1783 }, 1784 { 1785 "tp-id": "2-0-2", 1786 "te-tp-id": 20002, 1787 "te": { 1788 "interface-switching-capability": [ 1789 { 1790 "switching-capability": "switching-otn", 1791 "encoding": "lsp-encoding-oduk" 1792 } 1793 ] 1794 } 1795 }, 1796 { 1797 "tp-id": "2-2-0", 1798 "te-tp-id": 20200, 1799 "te": { 1800 "interface-switching-capability": [ 1801 { 1802 "switching-capability": "switching-otn", 1803 "encoding": "lsp-encoding-oduk" 1804 } 1805 ] 1806 } 1807 }, 1808 { 1810 "tp-id": "3-0-3", 1811 "te-tp-id": 30003, 1812 "te": { 1813 "interface-switching-capability": [ 1814 { 1815 "switching-capability": "switching-otn", 1816 "encoding": "lsp-encoding-oduk" 1817 } 1818 ] 1819 } 1820 }, 1821 { 1822 "tp-id": "3-3-0", 1823 "te-tp-id": 30300, 1824 "te": { 1825 "interface-switching-capability": [ 1826 { 1827 "switching-capability": "switching-otn", 1828 "encoding": "lsp-encoding-oduk" 1829 } 1830 ] 1831 } 1832 }, 1833 { 1834 "tp-id": "4-0-4", 1835 "te-tp-id": 40004, 1836 "te": { 1837 "interface-switching-capability": [ 1838 { 1839 "switching-capability": "switching-otn", 1840 "encoding": "lsp-encoding-oduk" 1841 } 1842 ] 1843 } 1844 }, 1845 { 1846 "tp-id": "4-4-0", 1847 "te-tp-id": 40400, 1848 "te": { 1849 "interface-switching-capability": [ 1850 { 1851 "switching-capability": "switching-otn", 1852 "encoding": "lsp-encoding-oduk" 1853 } 1854 ] 1855 } 1856 }, 1857 { 1858 "tp-id": "5-0-5", 1859 "te-tp-id": 50005, 1860 "te": { 1861 "interface-switching-capability": [ 1862 { 1863 "switching-capability": "switching-otn", 1864 "encoding": "lsp-encoding-oduk" 1865 } 1866 ] 1867 } 1868 }, 1869 { 1870 "tp-id": "5-5-0", 1871 "te-tp-id": 50500, 1872 "te": { 1873 "interface-switching-capability": [ 1874 { 1875 "switching-capability": "switching-otn", 1876 "encoding": "lsp-encoding-oduk" 1877 } 1878 ] 1879 } 1880 }, 1881 { 1882 "tp-id": "6-0-6", 1883 "te-tp-id": 60006, 1884 "te": { 1885 "interface-switching-capability": [ 1886 { 1887 "switching-capability": "switching-otn", 1888 "encoding": "lsp-encoding-oduk" 1889 } 1890 ] 1891 } 1892 }, 1893 { 1894 "tp-id": "6-6-0", 1895 "te-tp-id": 60600, 1896 "te": { 1897 "interface-switching-capability": [ 1898 { 1899 "switching-capability": "switching-otn", 1900 "encoding": "lsp-encoding-oduk" 1901 } 1902 ] 1903 } 1904 }, 1905 { 1906 "tp-id": "7-0-7", 1907 "te-tp-id": 70007, 1908 "te": { 1909 "interface-switching-capability": [ 1910 { 1911 "switching-capability": "switching-otn", 1912 "encoding": "lsp-encoding-oduk" 1913 } 1914 ] 1915 } 1916 }, 1917 { 1918 "tp-id": "7-7-0", 1919 "te-tp-id": 70700, 1920 "te": { 1921 "interface-switching-capability": [ 1922 { 1923 "switching-capability": "switching-otn", 1924 "encoding": "lsp-encoding-oduk" 1925 } 1926 ] 1927 } 1928 }, 1929 { 1930 "tp-id": "8-0-8", 1931 "te-tp-id": 80008, 1932 "te": { 1933 "interface-switching-capability": [ 1934 { 1935 "switching-capability": "switching-otn", 1936 "encoding": "lsp-encoding-oduk" 1937 } 1938 ] 1939 } 1940 }, 1941 { 1942 "tp-id": "8-8-0", 1943 "te-tp-id": 80800, 1944 "te": { 1945 "interface-switching-capability": [ 1946 { 1947 "switching-capability": "switching-otn", 1948 "encoding": "lsp-encoding-oduk" 1949 } 1950 ] 1951 } 1952 } 1953 ] 1954 } 1955 ] 1956 }, 1957 { 1958 "network-types": { 1959 "te-topology": {} 1960 }, 1961 "network-id": "abstract2", 1962 "provider-id": 201, 1963 "client-id": 600, 1964 "te-topology-id": "te-topology:abstract2", 1965 "node": [ 1966 { 1967 "node-id": "D2", 1968 "te-node-id": "2.0.1.2", 1969 "te": { 1970 "te-node-attributes": { 1971 "domain-id" : 1, 1972 "is-abstract": [null], 1973 "connectivity-matrices": { 1974 "is-allowed": true, 1975 "underlay": { 1976 "enabled": true 1977 }, 1978 "path-constraints": { 1979 "bandwidth-generic": { 1980 "te-bandwidth": { 1981 "generic": [ 1982 { 1983 "generic": "0x1p10" 1984 } 1985 ] 1986 } 1987 } 1988 }, 1989 "optimizations": { 1990 "objective-function": { 1991 "objective-function-type": 1992 "of-maximize-residual-bandwidth" 1993 } 1994 }, 1995 "connectivity-matrix": [ 1996 { 1997 "id": 105, 1998 "from": "1-0-1", 1999 "to": "5-5-0", 2000 "underlay": { 2001 "enabled": true, 2002 "primary-path": { 2003 "network-ref": "absolute", 2004 "path-element": [ 2005 { 2007 "path-element-id": 1, 2008 "index": 1, 2009 "numbered-hop": { 2010 "address": "4.4.4.4", 2011 "hop-type": "STRICT" 2012 } 2013 }, 2014 { 2015 "path-element-id": 2, 2016 "index": 2, 2017 "numbered-hop": { 2018 "address": "7.7.7.7", 2019 "hop-type": "STRICT" 2020 } 2021 } 2022 ] 2023 } 2024 } 2025 } 2026 ] 2027 } 2028 } 2029 }, 2030 "termination-point": [ 2031 { 2032 "tp-id": "1-0-1", 2033 "te-tp-id": 10001, 2034 "te": { 2035 "interface-switching-capability": [ 2036 { 2037 "switching-capability": "switching-otn", 2038 "encoding": "lsp-encoding-oduk" 2039 } 2040 ] 2041 } 2042 }, 2043 { 2044 "tp-id": "1-1-0", 2045 "te-tp-id": 10100, 2046 "te": { 2047 "interface-switching-capability": [ 2048 { 2049 "switching-capability": "switching-otn", 2050 "encoding": "lsp-encoding-oduk" 2051 } 2052 ] 2054 } 2055 }, 2056 { 2058 "tp-id": "2-0-2", 2059 "te-tp-id": 20002, 2060 "te": { 2061 "interface-switching-capability": [ 2062 { 2063 "switching-capability": "switching-otn", 2064 "encoding": "lsp-encoding-oduk" 2065 } 2066 ] 2067 } 2068 }, 2069 { 2070 "tp-id": "2-2-0", 2071 "te-tp-id": 20200, 2072 "te": { 2073 "interface-switching-capability": [ 2074 { 2075 "switching-capability": "switching-otn", 2076 "encoding": "lsp-encoding-oduk" 2077 } 2078 ] 2079 } 2080 }, 2081 { 2082 "tp-id": "3-0-3", 2083 "te-tp-id": 30003, 2084 "te": { 2085 "interface-switching-capability": [ 2086 { 2087 "switching-capability": "switching-otn", 2088 "encoding": "lsp-encoding-oduk" 2089 } 2090 ] 2091 } 2092 }, 2093 { 2094 "tp-id": "3-3-0", 2095 "te-tp-id": 30300, 2096 "te": { 2097 "interface-switching-capability": [ 2098 { 2099 "switching-capability": "switching-otn", 2100 "encoding": "lsp-encoding-oduk" 2101 } 2103 ] 2104 } 2105 }, 2106 { 2107 "tp-id": "4-0-4", 2108 "te-tp-id": 40004, 2109 "te": { 2110 "interface-switching-capability": [ 2111 { 2112 "switching-capability": "switching-otn", 2113 "encoding": "lsp-encoding-oduk" 2114 } 2115 ] 2116 } 2117 }, 2118 { 2119 "tp-id": "4-4-0", 2120 "te-tp-id": 40400, 2121 "te": { 2122 "interface-switching-capability": [ 2123 { 2124 "switching-capability": "switching-otn", 2125 "encoding": "lsp-encoding-oduk" 2126 } 2127 ] 2128 } 2129 }, 2130 { 2131 "tp-id": "5-0-5", 2132 "te-tp-id": 50005, 2133 "te": { 2134 "interface-switching-capability": [ 2135 { 2136 "switching-capability": "switching-otn", 2137 "encoding": "lsp-encoding-oduk" 2138 } 2139 ] 2140 } 2141 }, 2142 { 2143 "tp-id": "5-5-0", 2144 "te-tp-id": 50500, 2145 "te": { 2146 "interface-switching-capability": [ 2147 { 2148 "switching-capability": "switching-otn", 2149 "encoding": "lsp-encoding-oduk" 2150 } 2152 ] 2153 } 2154 }, 2155 { 2156 "tp-id": "6-0-6", 2157 "te-tp-id": 60006, 2158 "te": { 2159 "interface-switching-capability": [ 2160 { 2161 "switching-capability": "switching-otn", 2162 "encoding": "lsp-encoding-oduk" 2163 } 2164 ] 2165 } 2166 }, 2167 { 2168 "tp-id": "6-6-0", 2169 "te-tp-id": 60600, 2170 "te": { 2171 "interface-switching-capability": [ 2172 { 2173 "switching-capability": "switching-otn", 2174 "encoding": "lsp-encoding-oduk" 2175 } 2176 ] 2177 } 2178 }, 2179 { 2180 "tp-id": "7-0-7", 2181 "te-tp-id": 70007, 2182 "te": { 2183 "interface-switching-capability": [ 2184 { 2185 "switching-capability": "switching-otn", 2186 "encoding": "lsp-encoding-oduk" 2187 } 2188 ] 2189 } 2190 }, 2191 { 2192 "tp-id": "7-7-0", 2193 "te-tp-id": 70700, 2194 "te": { 2195 "interface-switching-capability": [ 2196 { 2197 "switching-capability": "switching-otn", 2198 "encoding": "lsp-encoding-oduk" 2199 } 2201 ] 2202 } 2203 }, 2204 { 2205 "tp-id": "8-0-8", 2206 "te-tp-id": 80008, 2207 "te": { 2209 "interface-switching-capability": [ 2210 { 2211 "switching-capability": "switching-otn", 2212 "encoding": "lsp-encoding-oduk" 2213 } 2214 ] 2215 } 2216 }, 2217 { 2218 "tp-id": "8-8-0", 2219 "te-tp-id": 80800, 2220 "te": { 2221 "interface-switching-capability": [ 2222 { 2223 "switching-capability": "switching-otn", 2224 "encoding": "lsp-encoding-oduk" 2225 } 2226 ] 2227 } 2228 } 2229 ] 2230 } 2231 ] 2232 }, 2233 { 2234 "network-types": { 2235 "te-topology": {} 2236 }, 2237 "network-id": "abstract3", 2238 "provider-id": 201, 2239 "client-id": 600, 2240 "te-topology-id": "te-topology:abstract3", 2241 "node": [ 2242 { 2243 "node-id": "D3", 2244 "te-node-id": "3.0.1.1", 2245 "te": { 2246 "te-node-attributes": { 2247 "domain-id" : 3, 2248 "is-abstract": [null], 2249 "connectivity-matrices": { 2250 "is-allowed": true, 2251 "path-constraints": { 2252 "bandwidth-generic": { 2253 "te-bandwidth": { 2254 "generic": [ 2255 { 2256 "generic": "0x1p10", 2257 } 2259 ] 2260 } 2261 } 2262 }, 2263 "connectivity-matrix": [ 2264 { 2265 "id": 107, 2266 "from": "1-0-1", 2267 "to": "7-7-0" 2268 }, 2269 { 2270 "id": 308, 2271 "from": "3-0-3", 2272 "to": "8-8-0" 2273 }, 2274 ] 2275 } 2276 } 2277 }, 2278 "termination-point": [ 2279 { 2280 "tp-id": "1-0-1", 2281 "te-tp-id": 10001, 2282 "te": { 2283 "interface-switching-capability": [ 2284 { 2285 "switching-capability": "switching-otn", 2286 "encoding": "lsp-encoding-oduk" 2287 } 2288 ] 2289 } 2290 }, 2291 { 2292 "tp-id": "1-1-0", 2293 "te-tp-id": 10100, 2294 "te": { 2295 "interface-switching-capability": [ 2296 { 2297 "switching-capability": "switching-otn", 2298 "encoding": "lsp-encoding-oduk" 2299 } 2300 ] 2301 } 2302 }, 2303 { 2304 "tp-id": "2-0-2", 2305 "te-tp-id": 20002, 2306 "te": { 2307 "interface-switching-capability": [ 2308 { 2309 "switching-capability": "switching-otn", 2310 "encoding": "lsp-encoding-oduk" 2311 } 2312 ] 2313 } 2314 }, 2315 { 2316 "tp-id": "2-2-0", 2317 "te-tp-id": 20200, 2318 "te": { 2319 "interface-switching-capability": [ 2320 { 2321 "switching-capability": "switching-otn", 2322 "encoding": "lsp-encoding-oduk" 2323 } 2324 ] 2325 } 2326 }, 2327 { 2328 "tp-id": "3-0-3", 2329 "te-tp-id": 30003, 2330 "te": { 2331 "interface-switching-capability": [ 2332 { 2333 "switching-capability": "switching-otn", 2334 "encoding": "lsp-encoding-oduk" 2335 } 2336 ] 2337 } 2338 }, 2339 { 2340 "tp-id": "3-3-0", 2341 "te-tp-id": 30300, 2342 "te": { 2343 "interface-switching-capability": [ 2344 { 2345 "switching-capability": "switching-otn", 2346 "encoding": "lsp-encoding-oduk" 2347 } 2348 ] 2349 } 2350 }, 2351 { 2352 "tp-id": "4-0-4", 2353 "te-tp-id": 40004, 2354 "te": { 2355 "interface-switching-capability": [ 2356 { 2358 "switching-capability": "switching-otn", 2359 "encoding": "lsp-encoding-oduk" 2360 } 2361 ] 2362 } 2363 }, 2364 { 2365 "tp-id": "4-4-0", 2366 "te-tp-id": 40400, 2367 "te": { 2368 "interface-switching-capability": [ 2369 { 2370 "switching-capability": "switching-otn", 2371 "encoding": "lsp-encoding-oduk" 2372 } 2373 ] 2374 } 2375 }, 2376 { 2377 "tp-id": "5-0-5", 2378 "te-tp-id": 50005, 2379 "te": { 2380 "interface-switching-capability": [ 2381 { 2382 "switching-capability": "switching-otn", 2383 "encoding": "lsp-encoding-oduk" 2384 } 2385 ] 2386 } 2387 }, 2388 { 2389 "tp-id": "5-5-0", 2390 "te-tp-id": 50500, 2391 "te": { 2392 "interface-switching-capability": [ 2393 { 2394 "switching-capability": "switching-otn", 2395 "encoding": "lsp-encoding-oduk" 2396 } 2397 ] 2398 } 2399 }, 2400 { 2401 "tp-id": "6-0-6", 2402 "te-tp-id": 60006, 2403 "te": { 2404 "interface-switching-capability": [ 2405 { 2406 "switching-capability": "switching-otn", 2407 "encoding": "lsp-encoding-oduk" 2408 } 2409 ] 2410 } 2411 }, 2412 { 2413 "tp-id": "6-6-0", 2414 "te-tp-id": 60600, 2415 "te": { 2416 "interface-switching-capability": [ 2417 { 2418 "switching-capability": "switching-otn", 2419 "encoding": "lsp-encoding-oduk" 2420 } 2421 ] 2422 } 2423 }, 2424 { 2425 "tp-id": "7-0-7", 2426 "te-tp-id": 70007, 2427 "te": { 2428 "interface-switching-capability": [ 2429 { 2430 "switching-capability": "switching-otn", 2431 "encoding": "lsp-encoding-oduk" 2432 } 2433 ] 2434 } 2435 }, 2436 { 2437 "tp-id": "7-7-0", 2438 "te-tp-id": 70700, 2439 "te": { 2440 "interface-switching-capability": [ 2441 { 2442 "switching-capability": "switching-otn", 2443 "encoding": "lsp-encoding-oduk" 2444 } 2445 ] 2446 } 2447 }, 2448 { 2449 "tp-id": "8-0-8", 2450 "te-tp-id": 80008, 2451 "te": { 2452 "interface-switching-capability": [ 2453 { 2454 "switching-capability": "switching-otn", 2455 "encoding": "lsp-encoding-oduk" 2456 } 2457 ] 2458 } 2459 }, 2460 { 2461 "tp-id": "8-8-0", 2462 "te-tp-id": 80800, 2463 "te": { 2464 "interface-switching-capability": [ 2465 { 2466 "switching-capability": "switching-otn", 2467 "encoding": "lsp-encoding-oduk" 2468 } 2469 ] 2470 } 2471 } 2472 ] 2473 } 2474 ] 2475 }, 2476 ] 2477 } 2478 } 2480 8. Security Considerations 2482 The configuration, state, and action data defined in this document 2483 are designed to be accessed via a management protocol with a secure 2484 transport layer, such as NETCONF [RFC6241] or RESTCONF [RFC8040]. 2485 The lowest NETCONF layer is the secure transport layer, and the 2486 mandatory-to-implement secure transport is Secure Shell (SSH) 2487 [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory- 2488 to-implement secure transport is TLS [RFC8446]. 2490 The NETCONF access control model [RFC8341] provides the means to 2491 restrict access for particular NETCONF users to a preconfigured 2492 subset of all available NETCONF protocol operations and content. 2494 The model presented in this document is used in the interface between 2495 the Customer Network Controller (CNC) and Multi-Domain Service 2496 Coordinator (MDSC), which is referred to as CNC-MDSC Interface (CMI). 2497 Therefore, many security risks such as malicious attack and rogue 2498 elements attempting to connect to various ACTN components. 2499 Furthermore, some ACTN components (e.g., MSDC) represent a single 2500 point of failure and threat vector and must also manage policy 2501 conflicts and eavesdropping of communication between different ACTN 2502 components. 2504 A number of configuration data nodes defined in this document are 2505 writable/deletable (i.e., "config true") These data nodes may be 2506 considered sensitive or vulnerable in some network environments. 2508 These are the subtrees and data nodes and their sensitivity/ 2509 vulnerability: 2511 * ap: 2513 - ap-id 2515 - max-bandwidth 2517 - avl-bandwidth 2519 * vn-ap: 2521 - vn-ap-id 2523 - vn 2525 - abstract-node 2527 - ltp 2529 * vn 2531 - vn-id 2533 - vn-topology-id 2535 - abstract-node 2537 * vnm-id 2538 - src 2540 - src-vn-ap-id 2542 - dest 2544 - dest-vn-ap-id 2546 - connectivity-matrix-id 2548 9. IANA Considerations 2550 IANA is requested to make the following allocation for the URIs in 2551 the "ns" subregistry within the "IETF XML Registry" [RFC3688]: 2553 -------------------------------------------------------------------- 2554 URI: urn:ietf:params:xml:ns:yang:ietf-vn 2555 Registrant Contact: The IESG. 2556 XML: N/A, the requested URI is an XML namespace. 2557 -------------------------------------------------------------------- 2559 IANA is requested to make the following allocation for the YANG 2560 module in the "YANG Module Names" registry [RFC6020]: 2562 -------------------------------------------------------------------- 2563 name: ietf-vn 2564 namespace: urn:ietf:params:xml:ns:yang:ietf-vn 2565 prefix: vn 2566 reference: RFC XXXX 2567 -------------------------------------------------------------------- 2569 10. Acknowledgments 2571 The authors would like to thank Xufeng Liu, Adrian Farrel, and Tom 2572 Petch for their helpful comments and valuable suggestions. 2574 Thanks to Andy Bierman for YANGDIR review. 2576 11. References 2578 11.1. Normative References 2580 [I-D.ietf-teas-yang-te] 2581 Saad, T., Gandhi, R., Liu, X., Beeram, V. P., Bryskin, I., 2582 and O. G. D. Dios, "A YANG Data Model for Traffic 2583 Engineering Tunnels, Label Switched Paths and Interfaces", 2584 Work in Progress, Internet-Draft, draft-ietf-teas-yang-te- 2585 27, 8 July 2021, . 2588 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2589 Requirement Levels", BCP 14, RFC 2119, 2590 DOI 10.17487/RFC2119, March 1997, 2591 . 2593 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2594 DOI 10.17487/RFC3688, January 2004, 2595 . 2597 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2598 the Network Configuration Protocol (NETCONF)", RFC 6020, 2599 DOI 10.17487/RFC6020, October 2010, 2600 . 2602 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2603 and A. Bierman, Ed., "Network Configuration Protocol 2604 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2605 . 2607 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2608 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2609 . 2611 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2612 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2613 . 2615 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2616 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2617 . 2619 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2620 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2621 . 2623 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2624 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2625 May 2017, . 2627 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2628 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2629 . 2631 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2632 Access Control Model", STD 91, RFC 8341, 2633 DOI 10.17487/RFC8341, March 2018, 2634 . 2636 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2637 and R. Wilton, "Network Management Datastore Architecture 2638 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 2639 . 2641 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 2642 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 2643 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2644 2018, . 2646 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2647 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2648 . 2650 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 2651 "Common YANG Data Types for Traffic Engineering", 2652 RFC 8776, DOI 10.17487/RFC8776, June 2020, 2653 . 2655 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 2656 O. Gonzalez de Dios, "YANG Data Model for Traffic 2657 Engineering (TE) Topologies", RFC 8795, 2658 DOI 10.17487/RFC8795, August 2020, 2659 . 2661 11.2. Informative References 2663 [I-D.ietf-ccamp-l1csm-yang] 2664 Lee, Y., Lee, K., Zheng, H., Dios, O. G. D., and D. 2665 Ceccarelli, "A YANG Data Model for L1 Connectivity Service 2666 Model (L1CSM)", Work in Progress, Internet-Draft, draft- 2667 ietf-ccamp-l1csm-yang-14, 20 February 2021, 2668 . 2671 [I-D.ietf-teas-actn-pm-telemetry-autonomics] 2672 Lee, Y., Dhody, D., Karunanithi, S., Vilalta, R., King, 2673 D., and D. Ceccarelli, "YANG models for VN/TE Performance 2674 Monitoring Telemetry and Scaling Intent Autonomics", Work 2675 in Progress, Internet-Draft, draft-ietf-teas-actn-pm- 2676 telemetry-autonomics-05, 19 February 2021, 2677 . 2680 [I-D.ietf-teas-te-service-mapping-yang] 2681 Lee, Y., Dhody, D., Fioccola, G., Wu, Q., Ceccarelli, D., 2682 and J. Tantsura, "Traffic Engineering (TE) and Service 2683 Mapping Yang Model", Work in Progress, Internet-Draft, 2684 draft-ietf-teas-te-service-mapping-yang-07, 21 February 2685 2021, . 2688 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 2689 Ceccarelli, D., and X. Zhang, "Problem Statement and 2690 Architecture for Information Exchange between 2691 Interconnected Traffic-Engineered Networks", BCP 206, 2692 RFC 7926, DOI 10.17487/RFC7926, July 2016, 2693 . 2695 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 2696 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 2697 DOI 10.17487/RFC8299, January 2018, 2698 . 2700 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 2701 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 2702 . 2704 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 2705 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 2706 DOI 10.17487/RFC8453, August 2018, 2707 . 2709 [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. 2710 Yoon, "Information Model for Abstraction and Control of TE 2711 Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, 2712 September 2018, . 2714 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 2715 Data Model for Layer 2 Virtual Private Network (L2VPN) 2716 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2717 2018, . 2719 Appendix A. Performance Constraints 2721 At the time of creation of VN, it is natural to provide VN level 2722 constraints and optimization criteria. It should be noted that this 2723 YANG model rely on the TE-Topology Model [RFC8795] by using a 2724 reference to an abstract node to achieve this. Further, 2725 connectivity-matrix structure is used to assign the constraints and 2726 optimization criteria include delay, jitter etc. [RFC8776] define 2727 some of the metric-types already and future documents are meant to 2728 augment it. 2730 Note that the VN compute allows inclusion of the constraints and the 2731 optimization criteria directly in the RPC to allow it to be used 2732 independently. 2734 Appendix B. Contributors Addresses 2736 Qin Wu 2737 Huawei Technologies 2738 Email: bill.wu@huawei.com 2740 Peter Park 2741 KT 2742 Email: peter.park@kt.com 2744 Haomian Zheng 2745 Huawei Technologies 2746 Email: zhenghaomian@huawei.com 2748 Xian Zhang 2749 Huawei Technologies 2750 Email: zhang.xian@huawei.com 2752 Sergio Belotti 2753 Nokia 2754 Email: sergio.belotti@nokia.com 2756 Takuya Miyasaka 2757 KDDI 2758 Email: ta-miyasaka@kddi.com 2760 Kenichi Ogaki 2761 KDDI 2762 Email: ke-oogaki@kddi.com 2764 Authors' Addresses 2765 Young Lee (editor) 2766 Samsung Electronics 2768 Email: younglee.tx@gmail.com 2770 Dhruv Dhody (editor) 2771 Huawei Technologies 2772 Divyashree Techno Park, Whitefield 2773 Bangalore 560066 2774 Karnataka 2775 India 2777 Email: dhruv.ietf@gmail.com 2779 Daniele Ceccarelli 2780 Ericsson 2781 Torshamnsgatan,48 2782 Stockholm, Sweden 2784 Email: daniele.ceccarelli@ericsson.com 2786 Igor Bryskin 2787 Individual 2789 Email: i_bryskin@yahoo.com 2791 Bin Yeong Yoon 2792 ETRI 2794 Email: byyun@etri.re.kr