idnits 2.17.1 draft-ietf-teas-actn-vn-yang-02.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 14) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 36 instances of too long lines in the document, the longest one being 22 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 673 has weird spacing: '... "delay path ...' == Line 1110 has weird spacing: '... rpc vn-co...' -- The document date (September 19, 2018) is 2046 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: 'TE-Topo' is mentioned on line 138, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 170, but not defined == Missing Reference: 'TE-Tunnel' is mentioned on line 172, but not defined == Missing Reference: 'ACTN-INFO' is mentioned on line 443, but not defined == Missing Reference: 'RFC6241' is mentioned on line 2263, but not defined == Missing Reference: 'RFC8040' is mentioned on line 2263, but not defined == Missing Reference: 'RFC6242' is mentioned on line 2266, but not defined == Missing Reference: 'RFC8446' is mentioned on line 2267, but not defined == Missing Reference: 'RFC8341' is mentioned on line 2269, but not defined == Missing Reference: 'RFC3688' is mentioned on line 2316, but not defined == Missing Reference: 'RFC6020' is mentioned on line 2327, but not defined Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS Working Group Y. Lee (Editor) 2 Internet Draft Dhruv Dhody (Editor) 3 Intended Status: Standard Track Huawei 4 Expires: March 19, 2019 D. Ceccarelli 5 Ericsson 6 Igor Bryskin 7 Huawei 8 Bin Yeong Yoon 9 ETRI 10 Qin Wu 11 Huawei 12 Peter Park 13 KT 15 September 19, 2018 17 A Yang Data Model for ACTN VN Operation 19 draft-ietf-teas-actn-vn-yang-02 21 Abstract 23 This document provides a YANG data model for the Abstraction and 24 Control of Traffic Engineered (TE) networks (ACTN) Virtual Network 25 Service (VNS) operation. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with 30 the provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other documents 39 at any time. It is inappropriate to use Internet-Drafts as 40 reference material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 47 This Internet-Draft will expire on March 19, 2019. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with 59 respect to this document. Code Components extracted from this 60 document must include Simplified BSD License text as described in 61 Section 4.e of the Trust Legal Provisions and are provided without 62 warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction...................................................3 67 1.1. Terminology...............................................4 68 1.2. Tree diagram..............................................4 69 1.3. Prefixes in Data Node Names...............................4 70 2. ACTN CMI context...............................................5 71 2.1. Type 1 VN.................................................5 72 2.2. Type 2 VN.................................................6 73 3. High-Level Control Flows with Examples.........................7 74 3.1. Type 1 VN Illustration....................................7 75 3.2. Type 2 VN Illustration....................................8 76 4. Justification of the ACTN VN Model on the CMI.................11 77 4.1. Customer view of VN......................................11 78 4.2. Innovative Services......................................11 79 4.2.1. VN Compute..........................................11 80 4.2.2. Multi-sources and Multi-destinations................12 81 4.2.3. Others..............................................13 82 4.3. Summary..................................................13 83 5. ACTN VN YANG Model (Tree Structure)...........................13 84 6. ACTN-VN YANG Code.............................................15 85 7. JSON Example..................................................27 86 7.1. ACTN VN JSON.............................................28 87 7.2. TE-topology JSON.........................................33 88 8. Security Considerations.......................................49 89 9. IANA Considerations...........................................51 90 10. Acknowledgments..............................................51 91 11. References...................................................52 92 11.1. Normative References....................................52 93 11.2. Informative References..................................52 94 12. Contributors.................................................53 95 Authors' Addresses...............................................53 97 1. Introduction 99 Abstraction and Control of Traffic Engineered Networks (ACTN) 100 describes a set of management and control functions used to operate 101 one or more TE networks to construct virtual networks that can be 102 represented to customers and that are built from abstractions of the 103 underlying TE networks [RFC8453]. 105 This document provides a YANG data model for the Abstraction and 106 Control of Traffic Engineered (TE) networks (ACTN) Virtual Network 107 Service (VNS) operation that is going to be implemented for the 108 Customer Network Controller (CNC)- Multi-Domain Service Coordinator 109 (MSDC) interface (CMI). 111 The YANG model on the CMI is also known as customer service model in 112 [RFC8309]. The YANG model discussed in this document is used to 113 operate customer-driven VNs during the VN instantiation, VN 114 computation, and its life-cycle service management and operations. 116 The VN model defined in this document can also work together with 117 other customer service models such as L3SM [RFC8299], L2SM [L2SM] 118 and L1CSM [L1CSM] to provide a complete life-cycle service 119 management and operations. 121 The YANG model discussed in this document basically provides the 122 following: 124 o Characteristics of Access Points (APs) that describe customer's 125 end point characteristics; 127 o Characteristics of Virtual Network Access Points (VNAP) that 128 describe How an AP is partitioned for multiple VNs sharing the AP 129 and its reference to a Link Termination Point (LTP) of the 130 Provider Edge (PE) Node; 132 o Characteristics of Virtual Networks (VNs) that describe the 133 customer's VNs in terms of VN Members comprising a VN, multi- 134 source and/or multi-destination characteristics of VN Member, the 135 VN's reference to TE-topology's Abstract Node; 137 The actual VN instantiation and computation is performed with 138 Connectivity Matrices sub-module of TE-Topology Model [TE-Topo] 139 which provides TE network topology abstraction and management 140 operation. Once TE-topology Model is used in triggering VN 141 instantiation over the networks, TE-tunnel [TE-tunnel] Model will 142 inevitably interact with TE-Topology model for setting up actual 143 tunnels and LSPs under the tunnels. 145 The ACTN VN operational state is included in the same tree as the 146 configuration consistent with Network Management Datastore 147 Architecture (NMDA) [RFC8342]. The origin of the data is indicated 148 as per the origin metadata annotation. 150 1.1. Terminology 152 Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used 153 in this document. 155 1.2. Tree diagram 157 A simplified graphical representation of the data model is used in 158 Section 5 of this this document. The meaning of the symbols in 159 these diagrams is defined in [RFC8340]. 161 1.3. Prefixes in Data Node Names 163 In this document, names of data nodes and other data model objects 164 are prefixed using the standard prefix associated with the 165 corresponding YANG imported modules, as shown in Table 1. 167 +---------+------------------------------+-----------------+ 168 | Prefix | YANG module | Reference | 169 +---------+------------------------------+-----------------+ 170 | vn | ietf-actn-vn | [RFCXXXX] | 171 | nw | ietf-network | [RFC8345] | 172 | te-types| ietf-te-types | [TE-Tunnel] | 173 | te-topo | ietf-te-topology | [TE-TOPO] | 174 +---------+------------------------------+-----------------+ 176 Table 1: Prefixes and corresponding YANG modules 178 Note: The RFC Editor will replace XXXX with the number assigned to 179 the RFC once this draft becomes an RFC. 181 2. ACTN CMI context 183 The model presented in this document has the following ACTN context. 185 +-------+ 186 | CNC | 187 +-------+ 188 | 189 | VN YANG + TE-topology YANG 190 | 191 +-----------------------+ 192 | MDSC | 193 +-----------------------+ 195 Figure 1. ACTN CMI 197 Both ACTN VN YANG and TE-topology models are used over the CMI to 198 establish a VN over TE networks. 200 2.1. Type 1 VN 202 As defined in [RFC8453], a Virtual Network is a customer view of the 203 TE network. To recapitulate VN types from [RFC8453], Type 1 VN is 204 defined as follows: 206 The VN can be seen as a set of edge-to-edge abstract links (a Type 1 207 VN). Each abstract link is referred to as a VN member and is formed 208 as an end-to-end tunnel across the underlying networks. Such tunnels 209 may be constructed by recursive slicing or abstraction of paths in 210 the underlying networks and can encompass edge points of the 211 customer's network, access links, intra-domain paths, and inter- 212 domain links. 214 If we were to create a VN where we have four VN-members as follows: 216 VN-Member 1 L1-L4 217 VN-Member 2 L1-L7 218 VN-Member 3 L2-L4 219 VN-Member 4 L3-L8 221 Where L1, L2, L3, L4, L7 and L8 correspond to a Customer 222 End-Point, respectively. 224 This VN can be modeled as one abstract node representation as 225 follows in Figure 2: 227 +---------------+ 228 L1 ------| |------ L4 229 L2 ------| AN 1 |------ L7 230 L3 ------| |------ L8 231 +---------------+ 233 Figure 2. Abstract Node (One node topology) 235 Modeling a VN as one abstract node is the easiest way for customers 236 to express their end-to-end connectivity; however, customers are not 237 limited to express their VN only with one abstract node. In some 238 cases, more than one abstract nodes can be employed to express their 239 VN. 241 2.2. Type 2 VN 243 For some VN members of a VN, the customers are allowed to configure 244 the actual path (i.e., detailed virtual nodes and virtual links) 245 over the VN/abstract topology agreed mutually between CNC and MDSC 246 prior to or a topology created by the MDSC as part of VN 247 instantiation. Type 2 VN is always built on top of a Type 1 VN. 249 If a Type 2 VN is desired for some or all of VN members of a type 1 250 VN (see the example in Section 2.1), the TE-topology model can 251 provide the following abstract topology (that consists of virtual 252 nodes and virtual links) which is built on top of the Type 1 VN. 254 +----------------------------------------------+ 255 | S1 S2 | 256 | O---------------O | 257 | ________/ \______ \ | 258 | / \ \ | 259 |S3 / \ S4 \ S5 | 260 L1----|-O----------------------O---------O-----------|------L4 261 | \ \ \ | 262 | \ \ \ | 263 | \ S6 \ S7 \ S8 | 264 | O ----------------O---------O-------|------L7 265 | / \ / \ ____/ | 266 |S9 / \ /S10 \ / | 267 L2-----|---O-----O---------------------O--------------|------L8 268 | / S11 | 269 L3-----|-- | 270 | | 271 +----------------------------------------------+ 273 Figure 3. Type 2 topology 275 As you see from Figure 3, the Type 1 abstract node is depicted as a 276 Type 1 abstract topology comprising of detailed virtual nodes and 277 virtual links. 279 As an example, if VN-member 1 (L1-L4) is chosen to configure its own 280 path over Type 2 topology, it can select, say, a path that consists 281 of the ERO {S3,S4,S5} based on the topology and its service 282 requirement. This capability is enacted via TE-topology 283 configuration by the customer. 285 3. High-Level Control Flows with Examples 287 3.1. Type 1 VN Illustration 289 If we were to create a VN where we have four VN-members as follows: 291 VN-Member 1 L1-L4 292 VN-Member 2 L1-L7 293 VN-Member 3 L2-L4 294 VN-Member 4 L3-L8 296 Where L1, L2, L3, L4, L7 and L8 correspond to Customer End-Point, 297 respectively. 299 This VN can be modeled as one abstract node representation as 300 follows: 302 +---------------+ 303 L1 ------| |------ L4 304 L2 ------| AN 1 |------ L7 305 L3 ------| |------ L8 306 +---------------+ 308 If this VN is Type 1, the following diagram shows the message flow 309 between CNC and MDSC to instantiate this VN using ACTN VN and TE- 310 Topology Model. 312 +--------+ +--------+ 313 | CNC | | MDSC | 314 +--------+ +--------+ 315 | | 316 | | 317 CNC POST TE-topo | POST /nw:networks/nw:network/ | 318 model(with Conn. | nw:node/te-node-id/tet:connectivity- | 319 Matrix on one | matrices/tet:connectivity-matrix | 320 Abstract node |---------------------------------------->| 321 | HTTP 200 | 322 |<----------------------------------------| 323 | | 324 CNC POST the ACTN| POST /ACTN VN | 325 VN identifying |---------------------------------------->| If there is 326 AP, VNAP and VN- | | multi-dest'n 327 Members and maps | | module, then 328 to the TE-topo | HTTP 200 | MDSC selects a 329 |<----------------------------------------| src or dest'n 330 | | and update 331 | | ACTN VN YANG 332 CNC GET the ACTN | GET /ACTN VN | 333 VN YANG status |---------------------------------------->| 334 | | 335 | HTTP 200 (ACTN VN with status: selected| 336 | VN-members in case of multi s-d | 337 |<----------------------------------------| 338 | | 340 3.2. Type 2 VN Illustration 342 For some VN members, the customer may want to "configure" explicit 343 routes over the path that connects its two end-points. Let us 344 consider the following example. 346 VN-Member 1 L1-L4 347 VN-Member 2 L1-L7 (via S4 and S7) 349 VN-Member 3 L2-L4 351 VN-Member 4 L3-L8 (via S10) 353 Where the following topology is the underlay for Abstraction Node 1 354 (AN1). 356 S1 S2 357 O---------------O 358 ________/ \______ \ 359 / \ \ 360 S3 / \ S4 \ S5 361 L1------O----------------------O---------O------------------L4 362 \ \ \ 363 \ \ \ 364 \ S6 \ S7 \ S8 365 O ----------------O---------O--------------L5 366 / \ / \ ____/ \_____________L6 367 S9 / \ /S10 \ / 368 L2---------O-----O---------------------O---------------------L7 369 / S11\____________________L8 370 L3-------- 372 If CNC creates the single abstract topology, the following diagram 373 shows the message flow between CNC and MDSC to instantiate this VN 374 using ACTN VN and TE-Topology Model. 376 +--------+ +--------+ 377 | CNC | | MDSC | 378 +--------+ +--------+ 379 | | 380 | | 381 CNC POST TE-topo | POST /nw:networks/nw:network/ | 382 model(with Conn. | nw:node/te-node-id/tet:connectivity- | 383 Matrix on one | matrices/tet:connectivity-matrix | 384 Abstract node and|---------------------------------------->| 385 Explicit paths in| | 386 The conn. Matrix | HTTP 200 | 387 |<----------------------------------------| 388 | | 389 CNC POST the ACTN| POST /ACTN VN | 390 VN identifying |---------------------------------------->| 391 AP, VNAP and VN- | | 392 Members and maps | | 393 to the TE-topo | HTTP 200 | 394 |<----------------------------------------| 395 | | 396 | | 397 CNC GET the ACTN | GET /ACTN VN | 398 VN YANG status |---------------------------------------->| 399 | | 400 | HTTP 200 (ACTN VN with status) | 401 |<----------------------------------------| 402 | | 404 On the other hand, if MDSC create single node topology based ACTN VN 405 YANG posted by the CNC, the following diagram shows the message flow 406 between CNC and MDSC to instantiate this VN using ACTN VN and TE- 407 Topology Model. 409 +--------+ +--------+ 410 | CNC | | MDSC | 411 +--------+ +--------+ 412 | | 413 | | 414 CNC POST ACTN VN | | 415 Identifying AP, | | 416 VNAP and VN- | POST /ACTN VN | MDSC populates 417 Members |---------------------------------------->| a single Abst. 418 | HTTP 200 | node topology 419 |<----------------------------------------| by itself 420 | | 421 CNC POST the ACTN| POST /ACTN VN | 422 VN identifying |---------------------------------------->| 423 AP, VNAP and VN- | | 424 Members and maps | | 425 to the TE-topo | HTTP 200 | 426 |<----------------------------------------| 427 | | 428 | | 430 CNC GET the ACTN | GET /ACTN VN | 431 VN YANG status |---------------------------------------->| 432 | | 433 | HTTP 200 (ACTN VN with status) | 434 |<----------------------------------------| 435 | | 437 4. ACTN VN Model Usage 439 4.1. Customer view of VN 441 The VN-Yang model allows to define a customer view, and allows the 442 customer to communicate using the VN constructs as described in the 443 [ACTN-INFO]. It also allows to group the set of edge-to-edge links 444 (i.e., VN members) under a common umbrella of VN. This allows the 445 customer to instantiate and view the VN as one entity, making it 446 easier for some customers to work on VN without worrying about the 447 details of the provider based YANG models. 449 This is similar to the benefits of having a separate YANG model for 450 the customer services as described in [RFC8309], which states that 451 service models do not make any assumption of how a service is 452 actually engineered and delivered for a customer. 454 4.2. Auto-creation of VN by MDSC 456 The VN could be configured at the MDSC explicitly by the CNC using 457 the ACTN VN yang model. In some other cases, the VN is not 458 explicitly configured, but created automatically by the MDSC based 459 on the customer service model and local policy, even in these case 460 the ACTN VN yang model can be used by the CNC to learn details of 461 the underlying VN created to meet the requirements of customer 462 service model. 464 4.3. Innovative Services 466 4.3.1. VN Compute 468 ACTN VN supports VN compute (pre-instantiation mode) to view the 469 full VN as a single entity before instantiation. Achieving this via 470 path computation or "compute only" tunnel setup does not provide the 471 same functionality. 473 4.3.2. Multi-sources and Multi-destinations 475 In creating a virtual network, the list of sources or destinations 476 or both may not be pre-determined by the customer. For instance, for 477 a given source, there may be a list of multiple-destinations to 478 which the optimal destination may be chosen depending on the network 479 resource situations. Likewise, for a given destination, there may 480 also be multiple-sources from which the optimal source may be 481 chosen. In some cases, there may be a pool of multiple sources and 482 destinations from which the optimal source-destination may be 483 chosen. The following YANG module is shown for describing source 484 container and destination container. The following YANG tree shows 485 how to model multi-sources and multi-destinations. 487 +--rw actn 488 . . . 489 +--rw vn 490 +--rw vn-list* [vn-id] 491 +--rw vn-id uint32 492 +--rw vn-name? string 493 +--rw vn-topology-id? te-types:te-topology-id 494 +--rw abstract-node? -> /nw:networks/network/node/tet:te-node-id 495 +--rw vn-member-list* [vn-member-id] 496 | +--rw vn-member-id uint32 497 | +--rw src 498 | | +--rw src? -> /actn/ap/access-point-list/access-point-id 499 | | +--rw src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id 500 | | +--rw multi-src? boolean {multi-src-dest}? 501 | +--rw dest 502 | | +--rw dest? -> /actn/ap/access-point-list/access-point- 503 id 504 | | +--rw dest-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id 505 | | +--rw multi-dest? boolean {multi-src-dest}? 506 | +--rw connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te- 507 node-attributes/connectivity-matrices/connectivity-matrix/id 508 | +--ro oper-status? identityref 509 +--ro if-selected? boolean {multi-src-dest}? 510 +--rw admin-status? identityref 511 +--ro oper-status? identityref 513 4.3.3. Others 515 The VN Yang model can be easily augmented to support the mapping of 516 VN to the Services such as L3SM and L2SM as described in [TE-MAP]. 518 The VN Yang model can be extended to support telemetry, performance 519 monitoring and network autonomics as described in [ACTN-PM]. 521 4.3.4. Summary 523 This section summarizes the innovative service features of the ACTN 524 VN Yang. 526 o Maintenance of AP and VNAP along with VN. 528 o VN construct to group of edge-to-edge links 530 o VN Compute (pre-instantiate) 532 o Multi-Source / Multi-Destination 534 o Ability to support various VN and VNS Types 536 * VN Type 1: Customer configures the VN as a set of VN 537 Members. 538 No other details need to be set by customer, making for a 539 simplified operations for the customer. 541 * VN Type 2: Along with VN Members, the customer could also 542 provide an abstract topology, this topology is provided by 543 the Abstract TE Topology Yang Model. 545 5. ACTN VN YANG Model (Tree Structure) 547 module: ietf-actn-vn 548 +--rw actn 549 +--rw ap 550 | +--rw access-point-list* [access-point-id] 551 | +--rw access-point-id uint32 552 | +--rw access-point-name? string 553 | +--rw max-bandwidth? te-types:te-bandwidth 554 | +--rw avl-bandwidth? te-types:te-bandwidth 555 | +--rw vn-ap* [vn-ap-id] 556 | +--rw vn-ap-id uint32 557 | +--rw vn? -> /actn/vn/vn-list/vn-id 558 | +--rw abstract-node? -> /nw:networks/network/node/tet:te-node-id 559 | +--rw ltp? te-types:te-tp-id 560 +--rw vn 561 +--rw vn-list* [vn-id] 562 +--rw vn-id uint32 563 +--rw vn-name? string 564 +--rw vn-topology-id? te-types:te-topology-id 565 +--rw abstract-node? -> /nw:networks/network/node/tet:te-node-id 566 +--rw vn-member-list* [vn-member-id] 567 | +--rw vn-member-id uint32 568 | +--rw src 569 | | +--rw src? -> /actn/ap/access-point-list/access-point-id 570 | | +--rw src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id 571 | | +--rw multi-src? boolean {multi-src-dest}? 572 | +--rw dest 573 | | +--rw dest? -> /actn/ap/access-point-list/access-point-id 574 | | +--rw dest-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id 575 | | +--rw multi-dest? boolean {multi-src-dest}? 576 | +--rw connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te-node- 577 attributes/connectivity-matrices/connectivity-matrix/id 578 | +--ro oper-status? identityref 579 +--ro if-selected? boolean {multi-src-dest}? 580 +--rw admin-status? identityref 581 +--ro oper-status? identityref 582 +--rw vn-level-diversity? vn-disjointness 584 rpcs: 585 +---x vn-compute 586 +---w input 587 | +---w abstract-node? -> /nw:networks/network/node/tet:te-node-id 588 | +---w vn-member-list* [vn-member-id] 589 | | +---w vn-member-id uint32 590 | | +---w src 591 | | | +---w src? -> /actn/ap/access-point-list/access-point-id 592 | | | +---w src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id 593 | | | +---w multi-src? boolean {multi-src-dest}? 594 | | +---w dest 595 | | | +---w dest? -> /actn/ap/access-point-list/access-point-id 596 | | | +---w dest-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id 597 | | | +---w multi-dest? boolean {multi-src-dest}? 598 | | +---w connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te-node- 599 attributes/connectivity-matrices/connectivity-matrix/id 600 | +---w vn-level-diversity? vn-disjointness 601 +--ro output 602 +--ro vn-member-list* [vn-member-id] 603 +--ro vn-member-id uint32 604 +--ro src 605 | +--ro src? -> /actn/ap/access-point-list/access-point-id 606 | +--ro src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id 607 | +--ro multi-src? boolean {multi-src-dest}? 608 +--ro dest 609 | +--ro dest? -> /actn/ap/access-point-list/access-point-id 610 | +--ro dest-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id 611 | +--ro multi-dest? boolean {multi-src-dest}? 612 +--ro connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te-node- 613 attributes/connectivity-matrices/connectivity-matrix/id 614 +--ro if-selected? boolean {multi-src-dest}? 615 +--ro compute-status? identityref 617 6. ACTN-VN YANG Code 619 The YANG code is as follows: 621 file "ietf-actn-vn@2018-02-27.yang" 623 module ietf-actn-vn { 624 namespace "urn:ietf:params:xml:ns:yang:ietf-actn-vn"; 625 prefix "vn"; 627 /* Import network */ 628 import ietf-network { 629 prefix "nw"; 630 } 632 /* Import TE generic types */ 633 import ietf-te-types { 634 prefix "te-types"; 635 } 637 /* Import Abstract TE Topology */ 638 import ietf-te-topology { 639 prefix "tet"; 640 } 642 organization 643 "IETF Traffic Engineering Architecture and Signaling (TEAS) 644 Working Group"; 645 contact 646 "Editor: Young Lee 647 : Dhruv Dhody "; 648 description 649 "This module contains a YANG module for the ACTN VN. It 650 describes a VN operation module that takes place in the 651 context of the CNC-MDSC Interface (CMI) of the ACTN 652 architecture where the CNC is the actor of a VN 653 Instantiation/modification /deletion."; 655 revision 2018-02-27 { 656 description 657 "initial version."; 658 reference 659 "TBD"; 660 } 661 /* 662 * Features 663 */ 664 feature multi-src-dest { 665 description 666 "Support for selection of one src or destination 667 among multiple."; 668 } 670 /*identity path-metric-delay { 671 base te-types:path-metric-type; 672 description 673 "delay path metric"; 674 } 675 identity path-metric-delay-variation { 676 base te-types:path-metric-type; 677 description 678 "delay-variation path metric"; 679 } 680 identity path-metric-loss { 681 base te-types:path-metric-type; 682 description 683 "loss path metric"; 684 }*/ 686 identity vn-state-type { 687 description 688 "Base identity for VN state"; 689 } 690 identity vn-state-up { 691 base vn-state-type; 692 description "VN state up"; 693 } 694 identity vn-state-down { 695 base vn-state-type; 696 description "VN state down"; 697 } 698 identity vn-admin-state-type { 699 description 700 "Base identity for VN admin states"; 701 } 702 identity vn-admin-state-up { 703 base vn-admin-state-type; 704 description "VN administratively state up"; 705 } 706 identity vn-admin-state-down { 707 base vn-admin-state-type; 708 description "VN administratively state down"; 709 } 710 identity vn-compute-state-type { 711 description 712 "Base identity for compute states"; 713 } 714 identity vn-compute-state-computing { 715 base vn-compute-state-type; 716 description 717 "State path compute in progress"; 718 } 719 identity vn-compute-state-computation-ok { 720 base vn-compute-state-type; 721 description 722 "State path compute successful"; 723 } 724 identity vn-compute-state-computatione-failed { 725 base vn-compute-state-type; 726 description 727 "State path compute failed"; 728 } 729 /* 730 * Groupings 731 */ 733 typedef vn-disjointness { 734 type bits { 735 bit node { 736 position 0; 737 description "node disjoint"; 738 } 739 bit link { 740 position 1; 741 description "link disjoint"; 742 } 743 bit srlg { 744 position 2; 745 description "srlg disjoint"; 746 } 747 } 748 description 749 "type of the resource disjointness for 750 VN level applied across all VN members 751 in a VN"; 752 } 754 grouping vn-ap { 755 description 756 "VNAP related information"; 757 leaf vn-ap-id { 758 type uint32; 759 description 760 "unique identifier for the referred 761 VNAP"; 762 } 763 leaf vn { 764 type leafref { 765 path "/actn/vn/vn-list/vn-id"; 766 } 767 description 768 "reference to the VN"; 769 } 770 leaf abstract-node { 771 type leafref { 772 path "/nw:networks/nw:network/nw:node/" 773 + "tet:te-node-id"; 774 } 775 description 776 "a reference to the abstract node in TE 777 Topology"; 778 } 779 leaf ltp { 780 type te-types:te-tp-id; 781 description 782 "Reference LTP in the TE-topology"; 783 } 784 } 785 grouping access-point{ 786 description 787 "AP related information"; 788 leaf access-point-id { 789 type uint32; 790 description 791 "unique identifier for the referred 792 access point"; 793 } 794 leaf access-point-name { 795 type string; 796 description 797 "ap name"; 798 } 800 leaf max-bandwidth { 801 type te-types:te-bandwidth; 802 description 803 "max bandwidth of the AP"; 804 } 805 leaf avl-bandwidth { 806 type te-types:te-bandwidth; 807 description 808 "available bandwidth of the AP"; 809 } 810 /*add details and any other properties of AP, 811 not associated by a VN 812 CE port, PE port etc. 813 */ 814 list vn-ap { 815 key vn-ap-id; 816 uses vn-ap; 817 description 818 "list of VNAP in this AP"; 819 } 820 }//access-point 821 grouping vn-member { 822 description 823 "vn-member is described by this container"; 824 leaf vn-member-id { 825 type uint32; 826 description 827 "vn-member identifier"; 828 } 829 container src 830 { 831 description 832 "the source of VN Member"; 833 leaf src { 834 type leafref { 835 path "/actn/ap/access-point-list/access-point-id"; 836 } 837 description 838 "reference to source AP"; 839 } 840 leaf src-vn-ap-id{ 841 type leafref { 842 path "/actn/ap/access-point-list/vn-ap/vn-ap-id"; 843 } 844 description 845 "reference to source VNAP"; 846 } 847 leaf multi-src { 848 if-feature multi-src-dest; 849 type boolean; 850 description 851 "Is source part of multi-source, where 852 only one of the source is enabled"; 853 } 854 } 855 container dest 856 { 857 description 858 "the destination of VN Member"; 859 leaf dest { 860 type leafref { 861 path "/actn/ap/access-point-list/access-point-id"; 862 } 863 description 864 "reference to destination AP"; 865 } 866 leaf dest-vn-ap-id{ 867 type leafref { 868 path "/actn/ap/access-point-list/vn-ap/vn-ap-id"; 869 } 870 description 871 "reference to dest VNAP"; 872 } 873 leaf multi-dest { 874 if-feature multi-src-dest; 875 type boolean; 876 description 877 "Is destination part of multi-destination, where 878 only one of the destination is enabled"; 879 } 881 } 882 leaf connetivity-matrix-id{ 883 type leafref { 884 path "/nw:networks/nw:network/nw:node/tet:te/" 885 + "tet:te-node-attributes/" 886 + "tet:connectivity-matrices/" 887 + "tet:connectivity-matrix/tet:id"; 888 } 889 description 890 "reference to connetivity-matrix"; 891 } 892 }//vn-member 893 /* 894 grouping policy { 895 description 896 "policy related to vn-member-id"; 897 leaf local-reroute { 898 type boolean; 899 description 900 "Policy to state if reroute 901 can be done locally"; 902 } 903 leaf push-allowed { 904 type boolean; 905 description 906 "Policy to state if changes 907 can be pushed to the customer"; 908 } 909 leaf incremental-update { 910 type boolean; 911 description 912 "Policy to allow only the 913 changes to be reported"; 914 } 915 }//policy 916 */ 917 grouping vn-policy { 918 description 919 "policy for VN-level diverisity"; 920 leaf vn-level-diversity { 921 type vn-disjointness; 922 description 923 "the type of disjointness on the VN level 924 (i.e., across all VN members)"; 925 } 927 } 928 /* 929 grouping metrics-op { 930 description 931 "metric related information"; 932 list metric{ 933 key "metric-type"; 934 config false; 935 description 936 "The list of metrics for VN"; 937 leaf metric-type { 938 type identityref { 939 base te-types:path-metric-type; 940 } 941 description 942 "The VN metric type."; 943 } 944 leaf value{ 945 type uint32; 946 description 947 "The limit value"; 948 } 949 } 950 } 951 */ 952 /* 953 grouping metrics { 954 description 955 "metric related information"; 956 list metric{ 957 key "metric-type"; 958 description 959 "The list of metrics for VN"; 960 uses te:path-metrics-bounds_config; 961 container optimize{ 962 description 963 "optimizing constraints"; 964 leaf enabled{ 965 type boolean; 966 description 967 "Metric to optimize"; 968 } 969 leaf value{ 970 type uint32; 971 description 972 "The computed value"; 973 } 974 } 975 } 976 } 977 */ 978 /* 979 grouping service-metric { 980 description 981 "service-metric"; 982 uses te:path-objective-function_config; 983 uses metrics; 984 uses te-types:common-constraints_config; 985 uses te:protection-restoration-params_config; 986 uses policy; 987 }//service-metric 988 */ 989 /* 990 * Configuration data nodes 991 */ 992 container actn { 993 description 994 "actn is described by this container"; 995 container ap { 996 description 997 "AP configurations"; 998 list access-point-list { 999 key "access-point-id"; 1000 description 1001 "access-point identifier"; 1002 uses access-point{ 1003 description 1004 "access-point information"; 1005 } 1006 } 1007 } 1008 container vn { 1009 description 1010 "VN configurations"; 1011 list vn-list { 1012 key "vn-id"; 1013 description 1014 "a virtual network is identified by a vn-id"; 1015 leaf vn-id { 1016 type uint32; 1017 description 1018 "a unique vn identifier"; 1019 } 1020 leaf vn-name { 1021 type string; 1022 description "vn name"; 1023 } 1024 leaf vn-topology-id{ 1025 type te-types:te-topology-id; 1026 description 1027 "An optional identifier to the TE Topology 1028 Model where the abstract nodes and links 1029 of the Topology can be found for Type 2 1030 VNS"; 1031 } 1032 leaf abstract-node { 1033 type leafref { 1034 path "/nw:networks/nw:network/nw:node/" 1035 + "tet:te-node-id"; 1036 } 1037 description 1038 "a reference to the abstract node in TE 1039 Topology"; 1040 } 1041 list vn-member-list{ 1042 key "vn-member-id"; 1043 description 1044 "List of VN-members in a VN"; 1045 uses vn-member; 1046 /*uses metrics-op;*/ 1047 leaf oper-status { 1048 type identityref { 1049 base vn-state-type; 1050 } 1051 config false; 1052 description 1053 "VN-member operational state."; 1054 } 1056 } 1057 leaf if-selected{ 1058 if-feature multi-src-dest; 1059 type boolean; 1060 default false; 1061 config false; 1062 description 1063 "Is the vn-member is selected among the 1064 multi-src/dest options"; 1065 } 1066 /* 1067 container multi-src-dest{ 1068 if-feature multi-src-dest; 1069 config false; 1070 description 1071 "The selected VN Member when multi-src 1072 and/or mult-destination is enabled."; 1073 leaf selected-vn-member{ 1074 type leafref { 1075 path "/actn/vn/vn-list/vn-member-list" 1076 + "/vn-member-id"; 1077 } 1078 description 1079 "The selected VN Member along the set 1080 of source and destination configured 1081 with multi-source and/or multi-destination"; 1082 } 1083 } 1084 */ 1085 /*uses service-metric;*/ 1086 leaf admin-status { 1087 type identityref { 1088 base vn-admin-state-type; 1089 } 1090 default vn-admin-state-up; 1091 description "VN administrative state."; 1092 } 1093 leaf oper-status { 1094 type identityref { 1095 base vn-state-type; 1096 } 1097 config false; 1098 description "VN operational state."; 1099 } 1100 uses vn-policy; 1101 }//vn-list 1102 }//vn 1103 }//actn 1104 /* 1105 * Notifications - TBD 1106 */ 1107 /* 1108 * RPC 1109 */ 1110 rpc vn-compute{ 1111 description 1112 "The VN computation without actual 1113 instantiation"; 1114 input { 1115 leaf abstract-node { 1116 type leafref { 1117 path "/nw:networks/nw:network/nw:node/" 1118 + "tet:te-node-id"; 1119 } 1120 description 1121 "a reference to the abstract node in TE 1122 Topology"; 1123 } 1124 list vn-member-list{ 1125 key "vn-member-id"; 1126 description 1127 "List of VN-members in a VN"; 1128 uses vn-member; 1129 } 1130 uses vn-policy; 1131 /*uses service-metric;*/ 1132 } 1133 output { 1134 list vn-member-list{ 1135 key "vn-member-id"; 1136 description 1137 "List of VN-members in a VN"; 1138 uses vn-member; 1139 leaf if-selected{ 1140 if-feature multi-src-dest; 1141 type boolean; 1142 default false; 1143 description 1144 "Is the vn-member is selected among 1145 the multi-src/dest options"; 1146 } 1147 /*uses metrics-op;*/ 1148 leaf compute-status { 1149 type identityref { 1150 base vn-compute-state-type; 1151 } 1152 description 1153 "VN-member compute state."; 1154 } 1155 } 1156 /* 1157 container multi-src-dest{ 1158 if-feature multi-src-dest; 1159 description 1160 "The selected VN Member when multi-src 1161 and/or mult-destination is enabled."; 1162 leaf selected-vn-member-id{ 1163 type uint32; 1164 description 1165 "The selected VN Member-id from the 1166 input"; 1167 } 1168 }*/ 1169 } 1170 } 1171 } 1173 1175 7. JSON Example 1177 This section provides json implementation examples as to how ACTN VN 1178 YANG model and TE topology model are used together to instantiate 1179 virtual networks. 1181 The example in this section includes following VN 1183 o VN1 (Type 1): Which maps to the single node topology abstract1 1184 (node D1) and consist of VN Members 104 (L1 to L4), 107 (L1 to 1185 L7), 204 (L2 to L4), 308 (L3 to L8) and 108 (L1 to L8). We also 1186 show how disjointness (node, link, srlg) is supported in the 1187 example on the global level (i.e., connectivity matrices level). 1189 o VN2 (Type 2): Which maps to the single node topology abstract2 1190 (node D2), this topology has an underlay topology (absolute) (see 1191 figure in section 3.2). This VN has a single VN member 105 (L1 to 1192 L5) and an underlay path (S4 and S7) has been set in the 1193 connectivity matrix of abstract2 topology; 1195 o VN3 (Type 1): This VN has a multi-source, multi-destination 1196 feature enable for VN Member 104 (L1 to L4)/107 (L1 to L7) 1197 [multi-src] and VN Member 204 (L2 to L4)/304 (L3 to L4) [multi- 1198 dest] usecase. The selected VN-member is known via the field "if- 1199 selected" and the corresponding connectivity-matrix-id. 1201 Note that the ACTN VN YANG model also include the AP and VNAP which 1202 shows various VN using the same AP. 1203 7.1. ACTN VN JSON 1205 { 1206 "actn":{ 1207 "ap":{ 1208 "access-point-list": [ 1209 { 1210 "access-point-id": 101, 1211 "access-point-name": "101", 1212 "vn-ap": [ 1213 { 1214 "vn-ap-id": 10101, 1215 "vn": 1, 1216 "abstract-node": "D1", 1217 "ltp": "1-0-1" 1218 }, 1219 { 1220 "vn-ap-id": 10102, 1221 "vn": 2, 1222 "abstract-node": "D2", 1223 "ltp": "1-0-1" 1224 }, 1225 { 1226 "vn-ap-id": 10103, 1227 "vn": 3, 1228 "abstract-node": "D3", 1229 "ltp": "1-0-1" 1230 }, 1231 ] 1232 }, 1233 { 1234 "access-point-id": 202, 1235 "access-point-name": "202", 1236 "vn-ap": [ 1237 { 1238 "vn-ap-id": 20201, 1239 "vn": 1, 1240 "abstract-node": "D1", 1241 "ltp": "2-0-2" 1242 } 1243 ] 1244 }, 1245 { 1246 "access-point-id": 303, 1247 "access-point-name": "303", 1248 "vn-ap": [ 1249 { 1250 "vn-ap-id": 30301, 1251 "vn": 1, 1252 "abstract-node": "D1", 1253 "ltp": "3-0-3" 1254 }, 1255 { 1256 "vn-ap-id": 30303, 1257 "vn": 3, 1258 "abstract-node": "D3", 1259 "ltp": "3-0-3" 1260 } 1261 ] 1262 }, 1263 { 1264 "access-point-id": 440, 1265 "access-point-name": "440", 1266 "vn-ap": [ 1267 { 1268 "vn-ap-id": 44001, 1269 "vn": 1, 1270 "abstract-node": "D1", 1271 "ltp": "4-4-0" 1272 } 1273 ] 1274 }, 1275 { 1276 "access-point-id": 550, 1277 "access-point-name": "550", 1278 "vn-ap": [ 1279 { 1280 "vn-ap-id": 55002, 1281 "vn": 2, 1282 "abstract-node": "D2", 1283 "ltp": "5-5-0" 1284 } 1285 ] 1287 }, 1288 { 1289 "access-point-id": 770, 1290 "access-point-name": "770", 1291 "vn-ap": [ 1292 { 1293 "vn-ap-id": 77001, 1294 "vn": 1, 1295 "abstract-node": "D1", 1296 "ltp": "7-7-0" 1297 }, 1298 { 1299 "vn-ap-id": 77003, 1300 "vn": 3, 1301 "abstract-node": "D3", 1302 "ltp": "7-7-0" 1303 } 1304 ] 1305 }, 1306 { 1307 "access-point-id": 880, 1308 "access-point-name": "880", 1309 "vn-ap": [ 1310 { 1311 "vn-ap-id": 88001, 1312 "vn": 1, 1313 "abstract-node": "D1", 1314 "ltp": "8-8-0" 1315 }, 1316 { 1317 "vn-ap-id": 88003, 1318 "vn": 3, 1319 "abstract-node": "D3", 1320 "ltp": "8-8-0" 1321 } 1322 ] 1323 } 1324 ] 1325 }, 1326 "vn":{ 1327 "vn-list": [ 1328 { 1329 "vn-id": 1, 1330 "vn-name": "vn1", 1331 "vn-topology-id": "te-topology:abstract1", 1332 "abstract-node": "D1", 1333 "vn-member-list": [ 1334 { 1335 "vn-member-id": 104, 1336 "src": { 1337 "src": 101, 1338 "src-vn-ap-id": 10101, 1339 }, 1340 "dest": { 1341 "dest": 440, 1342 "dest-vn-ap-id": 44001, 1343 }, 1344 "connectivity-matrix-id": 104 1345 }, 1346 { 1347 "vn-member-id": 107, 1348 "src": { 1349 "src": 101, 1350 "src-vn-ap-id": 10101, 1351 }, 1352 "dest": { 1353 "dest": 770, 1354 "dest-vn-ap-id": 77001, 1355 }, 1356 "connectivity-matrix-id": 107 1357 }, 1358 { 1359 "vn-member-id": 204, 1360 "src": { 1361 "src": 202, 1362 "dest-vn-ap-id": 20401, 1363 }, 1364 "dest": { 1365 "dest": 440, 1366 "dest-vn-ap-id": 44001, 1367 }, 1368 "connectivity-matrix-id": 204 1369 }, 1370 { 1371 "vn-member-id": 308, 1372 "src": { 1373 "src": 303, 1374 "src-vn-ap-id": 30301, 1375 }, 1376 "dest": { 1377 "dest": 880, 1378 "src-vn-ap-id": 88001, 1379 }, 1380 "connectivity-matrix-id": 308 1381 }, 1382 { 1383 "vn-member-id": 108, 1384 "src": { 1385 "src": 101, 1386 "src-vn-ap-id": 10101, 1387 }, 1388 "dest": { 1389 "dest": 880, 1390 "dest-vn-ap-id": 88001, 1391 }, 1392 "connectivity-matrix-id": 108 1393 } 1394 ] 1395 }, 1396 { 1397 "vn-id": 2, 1398 "vn-name": "vn2", 1399 "vn-topology-id": "te-topology:abstract2", 1400 "abstract-node": "D2", 1401 "vn-member-list": [ 1402 { 1403 "vn-member-id": 105, 1404 "src": { 1405 "src": 101, 1406 "src-vn-ap-id": 10102, 1407 }, 1408 "dest": { 1409 "dest": 550, 1410 "dest-vn-ap-id": 55002, 1411 }, 1412 "connectivity-matrix-id": 105 1413 } 1414 ] 1415 }, 1416 { 1417 "vn-id": 3, 1418 "vn-name": "vn3", 1419 "vn-topology-id": "te-topology:abstract3", 1420 "abstract-node": "D3", 1421 "vn-member-list": [ 1422 { 1423 "vn-member-id": 104, 1424 "src": { 1425 "src": 101, 1426 }, 1427 "dest": { 1428 "dest": 440, 1429 "multi-dest": true 1430 } 1431 }, 1432 { 1433 "vn-member-id": 107, 1434 "src": { 1435 "src": 101, 1436 "src-vn-ap-id": 10103, 1437 }, 1438 "dest": { 1439 "dest": 770, 1440 "dest-vn-ap-id": 77003, 1441 "multi-dest": true 1442 }, 1443 "connectivity-matrix-id": 107, 1444 "if-selected":true, 1445 }, 1446 { 1447 "vn-member-id": 204, 1448 "src": { 1449 "src": 202, 1450 "multi-src": true, 1451 }, 1452 "dest": { 1453 "dest": 440, 1454 }, 1455 }, 1456 { 1457 "vn-member-id": 304, 1458 "src": { 1459 "src": 303, 1460 "src-vn-ap-id": 30303, 1461 "multi-src": true, 1462 }, 1463 "dest": { 1464 "dest": 440, 1465 "src-vn-ap-id": 44003, 1466 }, 1467 "connectivity-matrix-id": 304, 1468 "if-selected":true, 1469 }, 1470 ] 1471 }, 1473 ] 1474 } 1476 } 1477 } 1479 7.2. TE-topology JSON 1481 { 1482 "networks": { 1483 "network": [ 1484 { 1485 "network-types": { 1486 "te-topology": {} 1487 }, 1488 "network-id": "abstract1", 1489 "provider-id": 201, 1490 "client-id": 600, 1491 "te-topology-id": "te-topology:abstract1", 1492 "node": [ 1493 { 1494 "node-id": "D1", 1495 "te-node-id": "2.0.1.1", 1496 "te": { 1497 "te-node-attributes": { 1498 "domain-id" : 1, 1499 "is-abstract": [null], 1500 "connectivity-matrices": { 1501 "is-allowed": true, 1502 "path-constraints": { 1503 "bandwidth-generic": { 1504 "te-bandwidth": { 1505 "generic": [ 1506 { 1507 "generic": "0x1p10", 1508 } 1509 ] 1510 } 1511 } 1512 "disjointness": "node link srlg", 1514 }, 1515 "connectivity-matrix": [ 1516 { 1517 "id": 104, 1518 "from": "1-0-1", 1519 "to": "4-4-0" 1520 }, 1521 { 1522 "id": 107, 1523 "from": "1-0-1", 1524 "to": "7-7-0" 1525 }, 1526 { 1527 "id": 204, 1528 "from": "2-0-2", 1529 "to": "4-4-0" 1530 }, 1531 { 1532 "id": 308, 1533 "from": "3-0-3", 1534 "to": "8-8-0" 1535 }, 1536 { 1537 "id": 108, 1538 "from": "1-0-1", 1539 "to": "8-8-0" 1540 }, 1541 ] 1542 } 1543 } 1544 }, 1545 "termination-point": [ 1546 { 1547 "tp-id": "1-0-1", 1548 "te-tp-id": 10001, 1549 "te": { 1550 "interface-switching-capability": [ 1551 { 1552 "switching-capability": "switching-otn", 1553 "encoding": "lsp-encoding-oduk" 1554 } 1555 ] 1556 } 1557 }, 1558 { 1559 "tp-id": "1-1-0", 1560 "te-tp-id": 10100, 1561 "te": { 1562 "interface-switching-capability": [ 1563 { 1564 "switching-capability": "switching-otn", 1565 "encoding": "lsp-encoding-oduk" 1566 } 1567 ] 1568 } 1569 }, 1570 { 1571 "tp-id": "2-0-2", 1572 "te-tp-id": 20002, 1573 "te": { 1574 "interface-switching-capability": [ 1575 { 1576 "switching-capability": "switching-otn", 1577 "encoding": "lsp-encoding-oduk" 1578 } 1579 ] 1580 } 1582 }, 1583 { 1584 "tp-id": "2-2-0", 1585 "te-tp-id": 20200, 1586 "te": { 1587 "interface-switching-capability": [ 1588 { 1589 "switching-capability": "switching-otn", 1590 "encoding": "lsp-encoding-oduk" 1591 } 1592 ] 1593 } 1594 }, 1595 { 1596 "tp-id": "3-0-3", 1597 "te-tp-id": 30003, 1598 "te": { 1599 "interface-switching-capability": [ 1600 { 1601 "switching-capability": "switching-otn", 1602 "encoding": "lsp-encoding-oduk" 1603 } 1604 ] 1605 } 1606 }, 1607 { 1608 "tp-id": "3-3-0", 1609 "te-tp-id": 30300, 1610 "te": { 1611 "interface-switching-capability": [ 1612 { 1613 "switching-capability": "switching-otn", 1614 "encoding": "lsp-encoding-oduk" 1615 } 1616 ] 1617 } 1618 }, 1619 { 1620 "tp-id": "4-0-4", 1621 "te-tp-id": 40004, 1622 "te": { 1623 "interface-switching-capability": [ 1624 { 1625 "switching-capability": "switching-otn", 1626 "encoding": "lsp-encoding-oduk" 1627 } 1628 ] 1629 } 1630 }, 1631 { 1632 "tp-id": "4-4-0", 1633 "te-tp-id": 40400, 1634 "te": { 1635 "interface-switching-capability": [ 1636 { 1637 "switching-capability": "switching-otn", 1638 "encoding": "lsp-encoding-oduk" 1639 } 1640 ] 1641 } 1642 }, 1643 { 1644 "tp-id": "5-0-5", 1645 "te-tp-id": 50005, 1646 "te": { 1647 "interface-switching-capability": [ 1648 { 1649 "switching-capability": "switching-otn", 1650 "encoding": "lsp-encoding-oduk" 1651 } 1652 ] 1653 } 1654 }, 1655 { 1656 "tp-id": "5-5-0", 1657 "te-tp-id": 50500, 1658 "te": { 1659 "interface-switching-capability": [ 1660 { 1661 "switching-capability": "switching-otn", 1662 "encoding": "lsp-encoding-oduk" 1663 } 1664 ] 1665 } 1666 }, 1667 { 1668 "tp-id": "6-0-6", 1669 "te-tp-id": 60006, 1670 "te": { 1671 "interface-switching-capability": [ 1672 { 1673 "switching-capability": "switching-otn", 1674 "encoding": "lsp-encoding-oduk" 1675 } 1676 ] 1677 } 1678 }, 1679 { 1680 "tp-id": "6-6-0", 1681 "te-tp-id": 60600, 1682 "te": { 1683 "interface-switching-capability": [ 1684 { 1685 "switching-capability": "switching-otn", 1686 "encoding": "lsp-encoding-oduk" 1687 } 1688 ] 1689 } 1690 }, 1691 { 1692 "tp-id": "7-0-7", 1693 "te-tp-id": 70007, 1694 "te": { 1695 "interface-switching-capability": [ 1696 { 1697 "switching-capability": "switching-otn", 1698 "encoding": "lsp-encoding-oduk" 1699 } 1700 ] 1701 } 1702 }, 1703 { 1704 "tp-id": "7-7-0", 1705 "te-tp-id": 70700, 1706 "te": { 1707 "interface-switching-capability": [ 1708 { 1709 "switching-capability": "switching-otn", 1710 "encoding": "lsp-encoding-oduk" 1711 } 1712 ] 1713 } 1714 }, 1715 { 1716 "tp-id": "8-0-8", 1717 "te-tp-id": 80008, 1718 "te": { 1719 "interface-switching-capability": [ 1720 { 1721 "switching-capability": "switching-otn", 1722 "encoding": "lsp-encoding-oduk" 1723 } 1724 ] 1725 } 1726 }, 1727 { 1728 "tp-id": "8-8-0", 1729 "te-tp-id": 80800, 1730 "te": { 1731 "interface-switching-capability": [ 1732 { 1733 "switching-capability": "switching-otn", 1734 "encoding": "lsp-encoding-oduk" 1735 } 1736 ] 1737 } 1738 } 1739 ] 1740 } 1741 ] 1742 }, 1743 { 1744 "network-types": { 1745 "te-topology": {} 1746 }, 1747 "network-id": "abstract2", 1748 "provider-id": 201, 1749 "client-id": 600, 1750 "te-topology-id": "te-topology:abstract2", 1751 "node": [ 1752 { 1753 "node-id": "D2", 1754 "te-node-id": "2.0.1.2", 1755 "te": { 1756 "te-node-attributes": { 1757 "domain-id" : 1, 1758 "is-abstract": [null], 1759 "connectivity-matrices": { 1760 "is-allowed": true, 1761 "underlay": { 1762 "enabled": true 1763 }, 1764 "path-constraints": { 1765 "bandwidth-generic": { 1766 "te-bandwidth": { 1767 "generic": [ 1768 { 1769 "generic": "0x1p10" 1770 } 1771 ] 1772 } 1773 } 1774 }, 1775 "optimizations": { 1776 "objective-function": { 1777 "objective-function-type": "of-maximize-residual- 1778 bandwidth" 1779 } 1780 }, 1781 "connectivity-matrix": [ 1782 { 1783 "id": 105, 1784 "from": "1-0-1", 1785 "to": "5-5-0", 1786 "underlay": { 1787 "enabled": true, 1788 "primary-path": { 1789 "network-ref": "absolute", 1790 "path-element": [ 1791 { 1792 "path-element-id": 1, 1793 "index": 1, 1794 "numbered-hop": { 1795 "address": "4.4.4.4", 1796 "hop-type": "STRICT" 1797 } 1798 }, 1799 { 1800 "path-element-id": 2, 1801 "index": 2, 1802 "numbered-hop": { 1803 "address": "7.7.7.7", 1804 "hop-type": "STRICT" 1805 } 1806 } 1807 ] 1808 } 1809 } 1810 } 1811 ] 1812 } 1813 } 1814 }, 1815 "termination-point": [ 1816 { 1817 "tp-id": "1-0-1", 1818 "te-tp-id": 10001, 1819 "te": { 1820 "interface-switching-capability": [ 1821 { 1822 "switching-capability": "switching-otn", 1823 "encoding": "lsp-encoding-oduk" 1824 } 1825 ] 1827 } 1828 }, 1829 { 1830 "tp-id": "1-1-0", 1831 "te-tp-id": 10100, 1832 "te": { 1833 "interface-switching-capability": [ 1834 { 1835 "switching-capability": "switching-otn", 1836 "encoding": "lsp-encoding-oduk" 1837 } 1838 ] 1839 } 1840 }, 1841 { 1842 "tp-id": "2-0-2", 1843 "te-tp-id": 20002, 1844 "te": { 1845 "interface-switching-capability": [ 1846 { 1847 "switching-capability": "switching-otn", 1848 "encoding": "lsp-encoding-oduk" 1849 } 1850 ] 1851 } 1852 }, 1853 { 1854 "tp-id": "2-2-0", 1855 "te-tp-id": 20200, 1856 "te": { 1857 "interface-switching-capability": [ 1858 { 1859 "switching-capability": "switching-otn", 1860 "encoding": "lsp-encoding-oduk" 1861 } 1862 ] 1863 } 1864 }, 1865 { 1866 "tp-id": "3-0-3", 1867 "te-tp-id": 30003, 1868 "te": { 1869 "interface-switching-capability": [ 1870 { 1871 "switching-capability": "switching-otn", 1872 "encoding": "lsp-encoding-oduk" 1873 } 1874 ] 1875 } 1877 }, 1878 { 1879 "tp-id": "3-3-0", 1880 "te-tp-id": 30300, 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": "4-0-4", 1892 "te-tp-id": 40004, 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": "4-4-0", 1904 "te-tp-id": 40400, 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": "5-0-5", 1916 "te-tp-id": 50005, 1917 "te": { 1918 "interface-switching-capability": [ 1919 { 1920 "switching-capability": "switching-otn", 1921 "encoding": "lsp-encoding-oduk" 1922 } 1923 ] 1924 } 1925 }, 1926 { 1927 "tp-id": "5-5-0", 1928 "te-tp-id": 50500, 1929 "te": { 1930 "interface-switching-capability": [ 1931 { 1932 "switching-capability": "switching-otn", 1933 "encoding": "lsp-encoding-oduk" 1934 } 1935 ] 1936 } 1937 }, 1938 { 1939 "tp-id": "6-0-6", 1940 "te-tp-id": 60006, 1941 "te": { 1942 "interface-switching-capability": [ 1943 { 1944 "switching-capability": "switching-otn", 1945 "encoding": "lsp-encoding-oduk" 1946 } 1947 ] 1948 } 1949 }, 1950 { 1951 "tp-id": "6-6-0", 1952 "te-tp-id": 60600, 1953 "te": { 1954 "interface-switching-capability": [ 1955 { 1956 "switching-capability": "switching-otn", 1957 "encoding": "lsp-encoding-oduk" 1958 } 1959 ] 1960 } 1961 }, 1962 { 1963 "tp-id": "7-0-7", 1964 "te-tp-id": 70007, 1965 "te": { 1966 "interface-switching-capability": [ 1967 { 1968 "switching-capability": "switching-otn", 1969 "encoding": "lsp-encoding-oduk" 1970 } 1971 ] 1972 } 1973 }, 1974 { 1975 "tp-id": "7-7-0", 1976 "te-tp-id": 70700, 1977 "te": { 1978 "interface-switching-capability": [ 1979 { 1980 "switching-capability": "switching-otn", 1981 "encoding": "lsp-encoding-oduk" 1982 } 1983 ] 1984 } 1985 }, 1986 { 1987 "tp-id": "8-0-8", 1988 "te-tp-id": 80008, 1989 "te": { 1990 "interface-switching-capability": [ 1991 { 1992 "switching-capability": "switching-otn", 1993 "encoding": "lsp-encoding-oduk" 1994 } 1995 ] 1996 } 1997 }, 1998 { 1999 "tp-id": "8-8-0", 2000 "te-tp-id": 80800, 2001 "te": { 2002 "interface-switching-capability": [ 2003 { 2004 "switching-capability": "switching-otn", 2005 "encoding": "lsp-encoding-oduk" 2006 } 2007 ] 2008 } 2009 } 2010 ] 2011 } 2012 ] 2013 }, 2014 { 2015 "network-types": { 2016 "te-topology": {} 2017 }, 2018 "network-id": "abstract3", 2019 "provider-id": 201, 2020 "client-id": 600, 2021 "te-topology-id": "te-topology:abstract3", 2022 "node": [ 2023 { 2024 "node-id": "D3", 2025 "te-node-id": "3.0.1.1", 2026 "te": { 2027 "te-node-attributes": { 2028 "domain-id" : 3, 2029 "is-abstract": [null], 2030 "connectivity-matrices": { 2031 "is-allowed": true, 2032 "path-constraints": { 2033 "bandwidth-generic": { 2034 "te-bandwidth": { 2035 "generic": [ 2036 { 2037 "generic": "0x1p10", 2038 } 2039 ] 2040 } 2041 } 2042 }, 2043 "connectivity-matrix": [ 2044 { 2045 "id": 107, 2046 "from": "1-0-1", 2047 "to": "7-7-0" 2048 }, 2049 { 2050 "id": 308, 2051 "from": "3-0-3", 2052 "to": "8-8-0" 2053 }, 2054 ] 2055 } 2056 } 2057 }, 2058 "termination-point": [ 2059 { 2060 "tp-id": "1-0-1", 2061 "te-tp-id": 10001, 2062 "te": { 2063 "interface-switching-capability": [ 2064 { 2065 "switching-capability": "switching-otn", 2066 "encoding": "lsp-encoding-oduk" 2067 } 2068 ] 2069 } 2070 }, 2071 { 2072 "tp-id": "1-1-0", 2073 "te-tp-id": 10100, 2074 "te": { 2075 "interface-switching-capability": [ 2076 { 2077 "switching-capability": "switching-otn", 2078 "encoding": "lsp-encoding-oduk" 2079 } 2080 ] 2081 } 2082 }, 2083 { 2084 "tp-id": "2-0-2", 2085 "te-tp-id": 20002, 2086 "te": { 2087 "interface-switching-capability": [ 2088 { 2089 "switching-capability": "switching-otn", 2090 "encoding": "lsp-encoding-oduk" 2091 } 2092 ] 2093 } 2094 }, 2095 { 2096 "tp-id": "2-2-0", 2097 "te-tp-id": 20200, 2098 "te": { 2099 "interface-switching-capability": [ 2100 { 2101 "switching-capability": "switching-otn", 2102 "encoding": "lsp-encoding-oduk" 2103 } 2104 ] 2105 } 2106 }, 2107 { 2108 "tp-id": "3-0-3", 2109 "te-tp-id": 30003, 2110 "te": { 2111 "interface-switching-capability": [ 2112 { 2113 "switching-capability": "switching-otn", 2114 "encoding": "lsp-encoding-oduk" 2115 } 2116 ] 2117 } 2118 }, 2119 { 2120 "tp-id": "3-3-0", 2121 "te-tp-id": 30300, 2122 "te": { 2123 "interface-switching-capability": [ 2124 { 2125 "switching-capability": "switching-otn", 2126 "encoding": "lsp-encoding-oduk" 2127 } 2128 ] 2129 } 2130 }, 2131 { 2132 "tp-id": "4-0-4", 2133 "te-tp-id": 40004, 2134 "te": { 2135 "interface-switching-capability": [ 2136 { 2137 "switching-capability": "switching-otn", 2138 "encoding": "lsp-encoding-oduk" 2139 } 2140 ] 2141 } 2142 }, 2143 { 2144 "tp-id": "4-4-0", 2145 "te-tp-id": 40400, 2146 "te": { 2147 "interface-switching-capability": [ 2148 { 2149 "switching-capability": "switching-otn", 2150 "encoding": "lsp-encoding-oduk" 2151 } 2152 ] 2153 } 2154 }, 2155 { 2156 "tp-id": "5-0-5", 2157 "te-tp-id": 50005, 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": "5-5-0", 2169 "te-tp-id": 50500, 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": "6-0-6", 2181 "te-tp-id": 60006, 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": "6-6-0", 2193 "te-tp-id": 60600, 2194 "te": { 2195 "interface-switching-capability": [ 2196 { 2197 "switching-capability": "switching-otn", 2198 "encoding": "lsp-encoding-oduk" 2199 } 2200 ] 2201 } 2202 }, 2203 { 2204 "tp-id": "7-0-7", 2205 "te-tp-id": 70007, 2206 "te": { 2207 "interface-switching-capability": [ 2208 { 2209 "switching-capability": "switching-otn", 2210 "encoding": "lsp-encoding-oduk" 2211 } 2212 ] 2213 } 2214 }, 2215 { 2216 "tp-id": "7-7-0", 2217 "te-tp-id": 70700, 2218 "te": { 2219 "interface-switching-capability": [ 2220 { 2221 "switching-capability": "switching-otn", 2222 "encoding": "lsp-encoding-oduk" 2223 } 2224 ] 2225 } 2226 }, 2227 { 2228 "tp-id": "8-0-8", 2229 "te-tp-id": 80008, 2230 "te": { 2231 "interface-switching-capability": [ 2232 { 2233 "switching-capability": "switching-otn", 2234 "encoding": "lsp-encoding-oduk" 2235 } 2236 ] 2237 } 2238 }, 2239 { 2240 "tp-id": "8-8-0", 2241 "te-tp-id": 80800, 2242 "te": { 2243 "interface-switching-capability": [ 2244 { 2245 "switching-capability": "switching-otn", 2246 "encoding": "lsp-encoding-oduk" 2247 } 2248 ] 2249 } 2250 } 2251 ] 2252 } 2253 ] 2254 }, 2255 ] 2256 } 2257 } 2259 8. Security Considerations 2261 The configuration, state, and action data defined in this document 2262 are designed to be accessed via a management protocol with a secure 2263 transport layer, such as NETCONF [RFC6241] or RESTCONF [RFC8040]. 2264 The lowest NETCONF layer is the secure transport layer, and the 2265 mandatory-to-implement secure transport is Secure Shell (SSH) 2266 [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory- 2267 to-implement secure transport is TLS [RFC8446]. 2269 The NETCONF access control model [RFC8341] provides the means to 2270 restrict access for particular NETCONF users to a preconfigured 2271 subset of all available NETCONF protocol operations and content. 2273 The model presented in this document is used in the interface 2274 between the Customer Network Controller (CNC) and Multi-Domain 2275 Service Coordinator (MDSC), which is referred to as CNC-MDSC 2276 Interface (CMI). Therefore, many security risks such as malicious 2277 attack and rogue elements attempting to connect to various ACTN 2278 components. Furthermore, some ACTN components (e.g., MSDC) 2279 represent a single point of failure and threat vector and must also 2280 manage policy conflicts and eavesdropping of communication between 2281 different ACTN components. 2283 A number of configuration data nodes defined in this document are 2284 writable/deletable (i.e., "config true") These data nodes may be 2285 considered sensitive or vulnerable in some network environments. 2287 These are the subtrees and data nodes and their 2288 sensitivity/vulnerability: 2290 - access-point-list: 2291 o access-point-id 2292 o max-bandwidth 2293 o avl-bandwidth 2295 - vn-ap: 2296 o vn-ap-id 2297 o vn 2298 o abstract-node 2299 o ltp 2301 - vn-list 2302 o vn-id 2303 o vn-topology-id 2304 o abstract-node 2306 - vn-member-id 2307 o src 2308 o src-vn-ap-id 2309 o dest 2310 o dest-vn-ap-id 2311 o connectivity-matrix-id 2313 9. IANA Considerations 2315 This document registers the following namespace URIs in the IETF XML 2316 registry [RFC3688]: 2318 -------------------------------------------------------------------- 2319 URI: urn:ietf:params:xml:ns:yang:ietf-actn-vn 2320 Registrant Contact: The IESG. 2321 XML: N/A, the requested URI is an XML namespace. 2322 -------------------------------------------------------------------- 2324 This document registers the following YANG modules in the YANG 2325 Module 2327 Names registry [RFC6020]: 2329 -------------------------------------------------------------------- 2330 name: ietf-actn-vn 2331 namespace: urn:ietf:params:xml:ns:yang:ietf-actn-vn 2332 reference: RFC XXXX (TDB) 2333 -------------------------------------------------------------------- 2335 10. Acknowledgments 2337 The authors would like to thank Xufeng Liu for his helpful comments 2338 and valuable suggestions. 2340 11. References 2342 11.1. Normative References 2344 [TE-TOPO] X. Liu, et al., "YANG Data Model for TE Topologies", work 2345 in progress: draft-ietf-teas-yang-te-topo. 2347 [TE-tunnel] T. Saad, et al., "A YANG Data Model for Traffic 2348 Engineering Tunnels and Interfaces", work in progress: 2349 draft-ietf-teas-yang-te. 2351 11.2. Informative References 2353 [RFC7926] A. Farrel (Ed.), "Problem Statement and Architecture for 2354 Information Exchange between Interconnected Traffic- 2355 Engineered Networks", RFC 7926, July 2016. 2357 [RFC8453] D. Ceccarelli and Y. Lee (Editors), "Framework for 2358 Abstraction and Control of Traffic Engineered Networks", 2359 RFC 8453, August 2018. 2361 [TE-MAP] Y. Lee, D. Dhody, and D. Ceccarelli, "Traffic Engineering 2362 and Service Mapping Yang Model", draft-lee-teas-te- 2363 service-mapping-yang, work in progress. 2365 [ACTN-PM] Y. Lee, et al., "YANG models for ACTN TE Performance 2366 Monitoring Telemetry and Network Autonomics", draft-lee- 2367 teas-actn-pm-telemetry-autonomics, work in progress. 2369 [L1CSM] G. Fioccola, Ed. & Y. Lee, Ed., "A Yang Data Model for L1 2370 Connectivity Service Model (L1CSM)", draft-ietf-ccamp- 2371 l1csm-yang, work in progress. 2372 [L2SM] G. Fioccola, Ed., "A YANG Data Model for L2VPN Service 2373 Delivery", draft-ietf-l2sm-l2vpn-service-model, work in 2374 progress. 2376 [RFC8299] Q. Wu, Ed., S. Litkowski, L. Tomotaki, and K. Ogaki, "YANG 2377 Data Model for L3VPN Service Delivery", RFC 8299, January 2378 2018. 2380 [RFC8309] Q. Wu, W. Cheng, and A. Farrel. "Service Models 2381 Explained", RFC 8309, January 2018. 2383 [RFC8340] M. Bjorklund and L. Berger (Editors), "YANG Tree 2384 Diagrams", RFC 8340, March 2018. 2386 [RFC8345] A. Clemm, et al, "A YANG Data Model for Network 2387 Topologies", RFC 8345, March 2018. 2389 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2390 and R. Wilton, "Network Management Datastore Architecture 2391 (NMDA)", RFC 8342, March 2018. 2393 12. Contributors 2395 Contributor's Addresses 2397 Haomian Zheng 2398 Huawei Technologies 2399 Email: zhenghaomian@huawei.com 2401 Xian Zhang 2402 Huawei Technologies 2403 Email: zhang.xian@huawei.com 2405 Sergio Belotti 2406 Nokia 2407 Email: sergio.belotti@nokia.com 2409 Takuya Miyasaka 2410 KDDI 2411 Email: ta-miyasaka@kddi.com 2413 Authors' Addresses 2415 Young Lee (ed.) 2416 Huawei Technologies 2417 Email: leeyoung@huawei.com 2419 Dhruv Dhody (ed.) 2420 Huawei Technologies 2421 Email: dhruv.ietf@gmail.com 2422 Daniele Ceccarelli 2423 Ericsson 2424 Torshamnsgatan,48 2425 Stockholm, Sweden 2426 Email: daniele.ceccarelli@ericsson.com 2428 Igor Bryskin 2429 Huawei 2430 Email: Igor.Bryskin@huawei.com 2432 Bin Yeong Yoon 2433 ETRI 2434 Email: byyun@etri.re.kr 2436 Qin Wu 2437 Huawei Technologies 2438 Email: bill.wu@huawei.com 2440 Peter Park 2441 KT 2442 Email: peter.park@kt.com