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