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