idnits 2.17.1 draft-ietf-teas-actn-vn-yang-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 34 instances of too long lines in the document, the longest one being 14 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 677 has weird spacing: '... "delay path ...' == Line 1112 has weird spacing: '... rpc vn-co...' -- The document date (February 4, 2019) is 1908 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 127, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 176, but not defined == Missing Reference: 'TE-Tunnel' is mentioned on line 178, but not defined == Missing Reference: 'ACTN-INFO' is mentioned on line 451, but not defined == Missing Reference: 'RFC6241' is mentioned on line 2260, but not defined == Missing Reference: 'RFC8040' is mentioned on line 2260, but not defined == Missing Reference: 'RFC6242' is mentioned on line 2264, but not defined == Missing Reference: 'RFC8446' is mentioned on line 2265, but not defined == Missing Reference: 'RFC8341' is mentioned on line 2267, but not defined == Missing Reference: 'RFC3688' is mentioned on line 2314, but not defined == Missing Reference: 'RFC6020' is mentioned on line 2325, but not defined Summary: 1 error (**), 0 flaws (~~), 14 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: August 3, 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 February 4, 2019 17 A Yang Data Model for VN Operation 19 draft-ietf-teas-actn-vn-yang-04 21 Abstract 23 This document provides a YANG data model generally applicable to any 24 mode of Virtual Network (VN) operation. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with 29 the provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six 37 months and may be updated, replaced, or obsoleted by other documents 38 at any time. It is inappropriate to use Internet-Drafts as 39 reference material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 This Internet-Draft will expire on August 3, 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 Introduction.....................................................3 67 1.................................................................3 68 1.1. Terminology...............................................4 69 1.2. Tree diagram..............................................4 70 1.3. Prefixes in Data Node Names...............................4 71 2. Use-case of VN Yang Model in the ACTN context..................5 72 2.1. Type 1 VN.................................................5 73 2.2. Type 2 VN.................................................6 74 3. High-Level Control Flows with Examples.........................7 75 3.1. Type 1 VN Illustration....................................7 76 3.2. Type 2 VN Illustration....................................8 77 4. VN Model Usage................................................11 78 4.1. Customer view of VN......................................11 79 4.2. Auto-creation of VN by MDSC..............................11 80 4.3. Innovative Services......................................11 81 4.3.1. VN Compute..........................................11 82 4.3.2. Multi-sources and Multi-destinations................12 83 4.3.3. Others..............................................12 84 4.3.4. Summary.............................................13 85 5. VN YANG Model (Tree Structure)................................13 86 6. VN YANG Code..................................................15 87 7. JSON Example..................................................27 88 7.1. VN JSON..................................................28 89 7.2. TE-topology JSON.........................................33 90 8. Security Considerations.......................................49 91 9. IANA Considerations...........................................51 92 10. Acknowledgments..............................................51 93 11. References...................................................52 94 11.1. Normative References....................................52 95 11.2. Informative References..................................52 96 12. Contributors.................................................53 97 Authors' Addresses...............................................53 99 1. Introduction 101 This document provides a YANG data model generally applicable to any 102 mode of Virtual Network (VN) operation. 104 The VN model defined in this document is applicable in generic sense 105 as an independent model in and of itself. The VN model defined in 106 this document can also work together with other customer service 107 models such as L3SM [RFC8299], L2SM [L2SM] and L1CSM [L1CSM] to 108 provide a complete life-cycle service management and operations. 110 The YANG model discussed in this document basically provides the 111 following: 113 o Characteristics of Access Points (APs) that describe customer's 114 end point characteristics; 116 o Characteristics of Virtual Network Access Points (VNAP) that 117 describe How an AP is partitioned for multiple VNs sharing the AP 118 and its reference to a Link Termination Point (LTP) of the 119 Provider Edge (PE) Node; 121 o Characteristics of Virtual Networks (VNs) that describe the 122 customer's VNs in terms of VN Members comprising a VN, multi- 123 source and/or multi-destination characteristics of VN Member, the 124 VN's reference to TE-topology's Abstract Node; 126 The actual VN instantiation and computation is performed with 127 Connectivity Matrices sub-module of TE-Topology Model [TE-Topo] 128 which provides TE network topology abstraction and management 129 operation. Once TE-topology Model is used in triggering VN 130 instantiation over the networks, TE-tunnel [TE-tunnel] Model will 131 inevitably interact with TE-Topology model for setting up actual 132 tunnels and LSPs under the tunnels. 134 Abstraction and Control of Traffic Engineered Networks (ACTN) 135 describes a set of management and control functions used to operate 136 one or more TE networks to construct virtual networks that can be 137 represented to customers and that are built from abstractions of the 138 underlying TE networks [RFC8453]. ACTN is the primary example of the 139 usage of the VN Yang model. 141 Sections 2 and 3 provide the discussion of how the VN Yang model is 142 applicable to the ACTN context where Virtual Network Service (VNS) 143 operation is implemented for the Customer Network Controller (CNC)- 144 Multi-Domain Service Coordinator (MSDC) interface (CMI). 146 The YANG model on the CMI is also known as customer service model in 147 [RFC8309]. The YANG model discussed in this document is used to 148 operate customer-driven VNs during the VN instantiation, VN 149 computation, and its life-cycle service management and operations. 151 The VN operational state is included in the same tree as the 152 configuration consistent with Network Management Datastore 153 Architecture (NMDA) [RFC8342]. The origin of the data is indicated 154 as per the origin metadata annotation. 156 1.1. Terminology 158 Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used 159 in this document. 161 1.2. Tree diagram 163 A simplified graphical representation of the data model is used in 164 Section 5 of this this document. The meaning of the symbols in 165 these diagrams is defined in [RFC8340]. 167 1.3. Prefixes in Data Node Names 169 In this document, names of data nodes and other data model objects 170 are prefixed using the standard prefix associated with the 171 corresponding YANG imported modules, as shown in Table 1. 173 +---------+------------------------------+-----------------+ 174 | Prefix | YANG module | Reference | 175 +---------+------------------------------+-----------------+ 176 | vn | ietf-vn | [RFCXXXX] | 177 | nw | ietf-network | [RFC8345] | 178 | te-types| ietf-te-types | [TE-Tunnel] | 179 | te-topo | ietf-te-topology | [TE-TOPO] | 180 +---------+------------------------------+-----------------+ 182 Table 1: Prefixes and corresponding YANG modules 184 Note: The RFC Editor will replace XXXX with the number assigned to 185 the RFC once this draft becomes an RFC. 187 2. Use-case of VN Yang Model in the ACTN context 189 In this section, ACTN is being used to illustrate the general usage 190 of the VN yang model. The model presented in this section has the 191 following ACTN context. 193 +-------+ 194 | CNC | 195 +-------+ 196 | 197 | VN YANG + TE-topology YANG 198 | 199 +-----------------------+ 200 | MDSC | 201 +-----------------------+ 203 Figure 1. ACTN CMI 205 Both ACTN VN YANG and TE-topology models are used over the CMI to 206 establish a VN over TE networks. 208 2.1. Type 1 VN 210 As defined in [RFC8453], a Virtual Network is a customer view of the 211 TE network. To recapitulate VN types from [RFC8453], Type 1 VN is 212 defined as follows: 214 The VN can be seen as a set of edge-to-edge abstract links (a Type 1 215 VN). Each abstract link is referred to as a VN member and is formed 216 as an end-to-end tunnel across the underlying networks. Such tunnels 217 may be constructed by recursive slicing or abstraction of paths in 218 the underlying networks and can encompass edge points of the 219 customer's network, access links, intra-domain paths, and inter- 220 domain links. 222 If we were to create a VN where we have four VN-members as follows: 224 VN-Member 1 L1-L4 225 VN-Member 2 L1-L7 226 VN-Member 3 L2-L4 227 VN-Member 4 L3-L8 229 Where L1, L2, L3, L4, L7 and L8 correspond to a Customer 230 End-Point, respectively. 232 This VN can be modeled as one abstract node representation as 233 follows in Figure 2: 235 +---------------+ 236 L1 ------| |------ L4 237 L2 ------| AN 1 |------ L7 238 L3 ------| |------ L8 239 +---------------+ 241 Figure 2. Abstract Node (One node topology) 243 Modeling a VN as one abstract node is the easiest way for customers 244 to express their end-to-end connectivity; however, customers are not 245 limited to express their VN only with one abstract node. In some 246 cases, more than one abstract nodes can be employed to express their 247 VN. 249 2.2. Type 2 VN 251 For some VN members of a VN, the customers are allowed to configure 252 the actual path (i.e., detailed virtual nodes and virtual links) 253 over the VN/abstract topology agreed mutually between CNC and MDSC 254 prior to or a topology created by the MDSC as part of VN 255 instantiation. Type 2 VN is always built on top of a Type 1 VN. 257 If a Type 2 VN is desired for some or all of VN members of a type 1 258 VN (see the example in Section 2.1), the TE-topology model can 259 provide the following abstract topology (that consists of virtual 260 nodes and virtual links) which is built on top of the Type 1 VN. 262 +----------------------------------------------+ 263 | S1 S2 | 264 | O---------------O | 265 | ________/ \______ \ | 266 | / \ \ | 267 |S3 / \ S4 \ S5 | 268 L1----|-O----------------------O---------O-----------|------L4 269 | \ \ \ | 270 | \ \ \ | 271 | \ S6 \ S7 \ S8 | 272 | O ----------------O---------O-------|------L7 273 | / \ / \ ____/ | 274 |S9 / \ /S10 \ / | 275 L2-----|---O-----O---------------------O--------------|------L8 276 | / S11 | 277 L3-----|-- | 278 | | 279 +----------------------------------------------+ 281 Figure 3. Type 2 topology 283 As you see from Figure 3, the Type 1 abstract node is depicted as a 284 Type 1 abstract topology comprising of detailed virtual nodes and 285 virtual links. 287 As an example, if VN-member 1 (L1-L4) is chosen to configure its own 288 path over Type 2 topology, it can select, say, a path that consists 289 of the ERO {S3,S4,S5} based on the topology and its service 290 requirement. This capability is enacted via TE-topology 291 configuration by the customer. 293 3. High-Level Control Flows with Examples 295 3.1. Type 1 VN Illustration 297 If we were to create a VN where we have four VN-members as follows: 299 VN-Member 1 L1-L4 300 VN-Member 2 L1-L7 301 VN-Member 3 L2-L4 302 VN-Member 4 L3-L8 304 Where L1, L2, L3, L4, L7 and L8 correspond to Customer End-Point, 305 respectively. 307 This VN can be modeled as one abstract node representation as 308 follows: 310 +---------------+ 311 L1 ------| |------ L4 312 L2 ------| AN 1 |------ L7 313 L3 ------| |------ L8 314 +---------------+ 316 If this VN is Type 1, the following diagram shows the message flow 317 between CNC and MDSC to instantiate this VN using VN and TE-Topology 318 Models. 320 +--------+ +--------+ 321 | CNC | | MDSC | 322 +--------+ +--------+ 323 | | 324 | | 325 CNC POST TE-topo | POST /nw:networks/nw:network/ | 326 model(with Conn. | nw:node/te-node-id/tet:connectivity- | 327 Matrix on one | matrices/tet:connectivity-matrix | 328 Abstract node |---------------------------------------->| 329 | HTTP 200 | 330 |<----------------------------------------| 331 | | 332 CNC POST the | POST /VN | 333 VN identifying |---------------------------------------->| If there is 334 AP, VNAP and VN- | | multi-dest'n 335 Members and maps | | module, then 336 to the TE-topo | HTTP 200 | MDSC selects a 337 |<----------------------------------------| src or dest'n 338 | | and update 339 | | VN YANG 340 CNC GET the | GET /VN | 341 VN YANG status |---------------------------------------->| 342 | | 343 | HTTP 200 (VN with status: selected | 344 | VN-members in case of multi s-d | 345 |<----------------------------------------| 346 | | 348 3.2. Type 2 VN Illustration 350 For some VN members, the customer may want to "configure" explicit 351 routes over the path that connects its two end-points. Let us 352 consider the following example. 354 VN-Member 1 L1-L4 356 VN-Member 2 L1-L7 (via S4 and S7) 358 VN-Member 3 L2-L4 360 VN-Member 4 L3-L8 (via S10) 362 Where the following topology is the underlay for Abstraction Node 1 363 (AN1). 365 S1 S2 366 O---------------O 367 ________/ \______ \ 368 / \ \ 369 S3 / \ S4 \ S5 370 L1------O----------------------O---------O------------------L4 371 \ \ \ 372 \ \ \ 373 \ S6 \ S7 \ S8 374 O ----------------O---------O--------------L5 375 / \ / \ ____/ \_____________L6 376 S9 / \ /S10 \ / 377 L2---------O-----O---------------------O---------------------L7 378 / S11\____________________L8 379 L3-------- 381 If CNC creates the single abstract topology, the following diagram 382 shows the message flow between CNC and MDSC to instantiate this VN 383 using VN and TE-Topology Model. 385 +--------+ +--------+ 386 | CNC | | MDSC | 387 +--------+ +--------+ 388 | | 389 | | 390 CNC POST TE-topo | POST /nw:networks/nw:network/ | 391 model(with Conn. | nw:node/te-node-id/tet:connectivity- | 392 Matrix on one | matrices/tet:connectivity-matrix | 393 Abstract node and|---------------------------------------->| 394 Explicit paths in| | 395 The conn. Matrix | HTTP 200 | 396 |<----------------------------------------| 397 | | 398 CNC POST the | POST /VN | 399 VN identifying |---------------------------------------->| 400 AP, VNAP and VN- | | 401 Members and maps | | 402 to the TE-topo | HTTP 200 | 403 |<----------------------------------------| 404 | | 405 | | 406 CNC GET the | GET /VN | 407 VN YANG status |---------------------------------------->| 408 | | 409 | HTTP 200 (VN with status) | 410 |<----------------------------------------| 411 | | 413 On the other hand, if MDSC create single node topology based VN YANG 414 posted by the CNC, the following diagram shows the message flow 415 between CNC and MDSC to instantiate this VN using VN and TE-Topology 416 Models. 418 +--------+ +--------+ 419 | CNC | | MDSC | 420 +--------+ +--------+ 421 | | 422 | | 423 CNC POST VN | | 424 Identifying AP, | | 425 VNAP and VN- | POST /VN | MDSC populates 426 Members |---------------------------------------->| a single Abst. 427 | HTTP 200 | node topology 428 |<----------------------------------------| by itself 429 | | 430 CNC POST the | POST /VN | 431 VN identifying |---------------------------------------->| 432 AP, VNAP and VN- | | 433 Members and maps | | 434 to the TE-topo | HTTP 200 | 435 |<----------------------------------------| 436 | | 437 | | 438 CNC GET the | GET /VN | 439 VN YANG status |---------------------------------------->| 440 | | 441 | HTTP 200 (VN with status) | 442 |<----------------------------------------| 443 | | 445 4. VN Model Usage 447 4.1. Customer view of VN 449 The VN-Yang model allows to define a customer view, and allows the 450 customer to communicate using the VN constructs as described in the 451 [ACTN-INFO]. It also allows to group the set of edge-to-edge links 452 (i.e., VN members) under a common umbrella of VN. This allows the 453 customer to instantiate and view the VN as one entity, making it 454 easier for some customers to work on VN without worrying about the 455 details of the provider based YANG models. 457 This is similar to the benefits of having a separate YANG model for 458 the customer services as described in [RFC8309], which states that 459 service models do not make any assumption of how a service is 460 actually engineered and delivered for a customer. 462 4.2. Auto-creation of VN by MDSC 464 The VN could be configured at the MDSC explicitly by the CNC using 465 the VN yang model. In some other cases, the VN is not explicitly 466 configured, but created automatically by the MDSC based on the 467 customer service model and local policy, even in these case the VN 468 yang model can be used by the CNC to learn details of the underlying 469 VN created to meet the requirements of customer service model. 471 4.3. Innovative Services 473 4.3.1. VN Compute 475 VN Model supports VN compute (pre-instantiation mode) to view the 476 full VN as a single entity before instantiation. Achieving this via 477 path computation or "compute only" tunnel setup does not provide the 478 same functionality. 480 4.3.2. Multi-sources and Multi-destinations 482 In creating a virtual network, the list of sources or destinations 483 or both may not be pre-determined by the customer. For instance, for 484 a given source, there may be a list of multiple-destinations to 485 which the optimal destination may be chosen depending on the network 486 resource situations. Likewise, for a given destination, there may 487 also be multiple-sources from which the optimal source may be 488 chosen. In some cases, there may be a pool of multiple sources and 489 destinations from which the optimal source-destination may be 490 chosen. The following YANG module is shown for describing source 491 container and destination container. The following YANG tree shows 492 how to model multi-sources and multi-destinations. 494 +--rw vn 495 +--rw vn-list* [vn-id] 496 +--rw vn-id uint32 497 +--rw vn-name? string 498 +--rw vn-topology-id? te-types:te-topology-id 499 +--rw abstract-node? -> /nw:networks/network/node/tet:te-node-id 500 +--rw vn-member-list* [vn-member-id] 501 | +--rw vn-member-id uint32 502 | +--rw src 503 | | +--rw src? -> /ap/access-point-list/access-point-id 504 | | +--rw src-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id 505 | | +--rw multi-src? boolean {multi-src-dest}? 506 | +--rw dest 507 | | +--rw dest? -> /ap/access-point-list/access-point-id 508 | | +--rw dest-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id 509 | | +--rw multi-dest? boolean {multi-src-dest}? 510 | +--rw connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te- 511 node-attributes/connectivity-matrices/connectivity-matrix/id 512 | +--ro oper-status? identityref 513 +--ro if-selected? boolean {multi-src-dest}? 514 +--rw admin-status? identityref 515 +--ro oper-status? identityref 517 4.3.3. Others 519 The VN Yang model can be easily augmented to support the mapping of 520 VN to the Services such as L3SM and L2SM as described in [TE-MAP]. 522 The VN Yang model can be extended to support telemetry, performance 523 monitoring and network autonomics as described in [ACTN-PM]. 525 4.3.4. Summary 527 This section summarizes the innovative service features of the VN 528 Yang. 530 o Maintenance of AP and VNAP along with VN. 532 o VN construct to group of edge-to-edge links 534 o VN Compute (pre-instantiate) 536 o Multi-Source / Multi-Destination 538 o Ability to support various VN and VNS Types 540 * VN Type 1: Customer configures the VN as a set of VN 541 Members. 542 No other details need to be set by customer, making for a 543 simplified operations for the customer. 545 * VN Type 2: Along with VN Members, the customer could also 546 provide an abstract topology, this topology is provided by 547 the Abstract TE Topology Yang Model. 549 5. VN YANG Model (Tree Structure) 551 module: ietf-vn 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? -> /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? -> /ap/access-point-list/access-point-id 573 | | +--rw src-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id 574 | | +--rw multi-src? boolean {multi-src-dest}? 575 | +--rw dest 576 | | +--rw dest? -> /ap/access-point-list/access-point-id 577 | | +--rw dest-vn-ap-id? -> /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- 580 node-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? -> /ap/access-point-list/access-point-id 595 | | | +---w src-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id 596 | | | +---w multi-src? boolean {multi-src-dest}? 597 | | +---w dest 598 | | | +---w dest? -> /ap/access-point-list/access-point-id 599 | | | +---w dest-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id 600 | | | +---w multi-dest? boolean {multi-src-dest}? 601 | | +---w connetivity-matrix-id? -> 602 /nw:networks/network/node/tet:te/te-node-attributes/connectivity- 603 matrices/connectivity-matrix/id 604 | +---w vn-level-diversity? vn-disjointness 605 +--ro output 606 +--ro vn-member-list* [vn-member-id] 607 +--ro vn-member-id uint32 608 +--ro src 609 | +--ro src? -> /ap/access-point-list/access-point-id 610 | +--ro src-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id 611 | +--ro multi-src? boolean {multi-src-dest}? 612 +--ro dest 613 | +--ro dest? -> /ap/access-point-list/access-point-id 614 | +--ro dest-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id 615 | +--ro multi-dest? boolean {multi-src-dest}? 616 +--ro connetivity-matrix-id? -> 617 /nw:networks/network/node/tet:te/te-node-attributes/connectivity- 618 matrices/connectivity-matrix/id 619 +--ro if-selected? boolean {multi-src-dest}? 620 +--ro compute-status? Identityref 622 6. VN YANG Code 624 The YANG code is as follows: 626 file "ietf-vn@2019-02-04.yang" 628 module ietf-vn { 629 namespace "urn:ietf:params:xml:ns:yang:ietf-vn"; 630 prefix "vn"; 632 /* Import network */ 633 import ietf-network { 634 prefix "nw"; 635 } 637 /* Import TE generic types */ 638 import ietf-te-types { 639 prefix "te-types"; 640 } 642 /* Import Abstract TE Topology */ 643 import ietf-te-topology { 644 prefix "tet"; 645 } 647 organization 648 "IETF Traffic Engineering Architecture and Signaling (TEAS) 649 Working Group"; 650 contact 651 "Editor: Young Lee 652 : Dhruv Dhody "; 653 description 654 "This module contains a YANG module for the VN. It 655 describes a VN operation module that takes place in the 656 context of the CNC-MDSC Interface (CMI) of the ACTN 657 architecture where the CNC is the actor of a VN 658 Instantiation/modification /deletion."; 659 revision 2019-02-04 { 660 description 661 "initial version."; 662 reference 663 "TBD"; 664 } 665 /* 666 * Features 667 */ 668 feature multi-src-dest { 669 description 670 "Support for selection of one src or destination 671 among multiple."; 672 } 674 /*identity path-metric-delay { 675 base te-types:path-metric-type; 676 description 677 "delay path metric"; 678 } 679 identity path-metric-delay-variation { 680 base te-types:path-metric-type; 681 description 682 "delay-variation path metric"; 683 } 684 identity path-metric-loss { 685 base te-types:path-metric-type; 686 description 687 "loss path metric"; 688 }*/ 690 identity vn-state-type { 691 description 692 "Base identity for VN state"; 693 } 694 identity vn-state-up { 695 base vn-state-type; 696 description "VN state up"; 697 } 698 identity vn-state-down { 699 base vn-state-type; 700 description "VN state down"; 701 } 702 identity vn-admin-state-type { 703 description 704 "Base identity for VN admin states"; 705 } 706 identity vn-admin-state-up { 707 base vn-admin-state-type; 708 description "VN administratively state up"; 709 } 710 identity vn-admin-state-down { 711 base vn-admin-state-type; 712 description "VN administratively state down"; 713 } 714 identity vn-compute-state-type { 715 description 716 "Base identity for compute states"; 717 } 718 identity vn-compute-state-computing { 719 base vn-compute-state-type; 720 description 721 "State path compute in progress"; 722 } 723 identity vn-compute-state-computation-ok { 724 base vn-compute-state-type; 725 description 726 "State path compute successful"; 727 } 728 identity vn-compute-state-computatione-failed { 729 base vn-compute-state-type; 730 description 731 "State path compute failed"; 732 } 733 /* 734 * Groupings 735 */ 737 typedef vn-disjointness { 738 type bits { 739 bit node { 740 position 0; 741 description "node disjoint"; 742 } 743 bit link { 744 position 1; 745 description "link disjoint"; 746 } 747 bit srlg { 748 position 2; 749 description "srlg disjoint"; 750 } 751 } 752 description 753 "type of the resource disjointness for 754 VN level applied across all VN members 755 in a VN"; 756 } 758 grouping vn-ap { 759 description 760 "VNAP related information"; 761 leaf vn-ap-id { 762 type uint32; 763 description 764 "unique identifier for the referred 765 VNAP"; 766 } 767 leaf vn { 768 type leafref { 769 path "/vn/vn-list/vn-id"; 770 } 771 description 772 "reference to the VN"; 773 } 774 leaf abstract-node { 775 type leafref { 776 path "/nw:networks/nw:network/nw:node/" 777 + "tet:te-node-id"; 778 } 779 description 780 "a reference to the abstract node in TE 781 Topology"; 782 } 783 leaf ltp { 784 type te-types:te-tp-id; 785 description 786 "Reference LTP in the TE-topology"; 787 } 788 } 789 grouping access-point{ 790 description 791 "AP related information"; 792 leaf access-point-id { 793 type uint32; 794 description 795 "unique identifier for the referred 796 access point"; 797 } 798 leaf access-point-name { 799 type string; 800 description 801 "ap name"; 802 } 804 leaf max-bandwidth { 805 type te-types:te-bandwidth; 806 description 807 "max bandwidth of the AP"; 808 } 809 leaf avl-bandwidth { 810 type te-types:te-bandwidth; 811 description 812 "available bandwidth of the AP"; 813 } 814 /*add details and any other properties of AP, 815 not associated by a VN 816 CE port, PE port etc. 817 */ 818 list vn-ap { 819 key vn-ap-id; 820 uses vn-ap; 821 description 822 "list of VNAP in this AP"; 823 } 824 }//access-point 825 grouping vn-member { 826 description 827 "vn-member is described by this container"; 828 leaf vn-member-id { 829 type uint32; 830 description 831 "vn-member identifier"; 832 } 833 container src 834 { 835 description 836 "the source of VN Member"; 837 leaf src { 838 type leafref { 839 path "/ap/access-point-list/access-point-id"; 840 } 841 description 842 "reference to source AP"; 843 } 844 leaf src-vn-ap-id{ 845 type leafref { 846 path "/ap/access-point-list/vn-ap/vn-ap-id"; 847 } 848 description 849 "reference to source VNAP"; 850 } 851 leaf multi-src { 852 if-feature multi-src-dest; 853 type boolean; 854 description 855 "Is source part of multi-source, where 856 only one of the source is enabled"; 857 } 858 } 859 container dest 860 { 861 description 862 "the destination of VN Member"; 863 leaf dest { 864 type leafref { 865 path "/ap/access-point-list/access-point-id"; 866 } 867 description 868 "reference to destination AP"; 869 } 870 leaf dest-vn-ap-id{ 871 type leafref { 872 path "/ap/access-point-list/vn-ap/vn-ap-id"; 873 } 874 description 875 "reference to dest VNAP"; 876 } 877 leaf multi-dest { 878 if-feature multi-src-dest; 879 type boolean; 880 description 881 "Is destination part of multi-destination, where 882 only one of the destination is enabled"; 883 } 884 } 885 leaf connetivity-matrix-id{ 886 type leafref { 887 path "/nw:networks/nw:network/nw:node/tet:te/" 888 + "tet:te-node-attributes/" 889 + "tet:connectivity-matrices/" 890 + "tet:connectivity-matrix/tet:id"; 891 } 892 description 893 "reference to connetivity-matrix"; 894 } 895 }//vn-member 896 /* 897 grouping policy { 898 description 899 "policy related to vn-member-id"; 900 leaf local-reroute { 901 type boolean; 902 description 903 "Policy to state if reroute 904 can be done locally"; 905 } 906 leaf push-allowed { 907 type boolean; 908 description 909 "Policy to state if changes 910 can be pushed to the customer"; 911 } 912 leaf incremental-update { 913 type boolean; 914 description 915 "Policy to allow only the 916 changes to be reported"; 917 } 918 }//policy 919 */ 920 grouping vn-policy { 921 description 922 "policy for VN-level diverisity"; 923 leaf vn-level-diversity { 924 type vn-disjointness; 925 description 926 "the type of disjointness on the VN level 927 (i.e., across all VN members)"; 928 } 929 } 930 /* 931 grouping metrics-op { 932 description 933 "metric related information"; 934 list metric{ 935 key "metric-type"; 936 config false; 937 description 938 "The list of metrics for VN"; 939 leaf metric-type { 940 type identityref { 941 base te-types:path-metric-type; 942 } 943 description 944 "The VN metric type."; 945 } 946 leaf value{ 947 type uint32; 948 description 949 "The limit value"; 950 } 951 } 952 } 953 */ 954 /* 955 grouping metrics { 956 description 957 "metric related information"; 958 list metric{ 959 key "metric-type"; 960 description 961 "The list of metrics for VN"; 962 uses te:path-metrics-bounds_config; 963 container optimize{ 964 description 965 "optimizing constraints"; 966 leaf enabled{ 967 type boolean; 968 description 969 "Metric to optimize"; 971 } 972 leaf value{ 973 type uint32; 974 description 975 "The computed value"; 976 } 977 } 978 } 979 } 980 */ 981 /* 982 grouping service-metric { 983 description 984 "service-metric"; 985 uses te:path-objective-function_config; 986 uses metrics; 987 uses te-types:common-constraints_config; 988 uses te:protection-restoration-params_config; 989 uses policy; 990 }//service-metric 991 */ 992 /* 993 * Configuration data nodes 994 */ 996 container ap { 997 description 998 "AP configurations"; 999 list access-point-list { 1000 key "access-point-id"; 1001 description 1002 "access-point identifier"; 1003 uses access-point { 1004 description 1005 "access-point information"; 1006 } 1007 } 1008 } 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 } 1068 /* 1069 container multi-src-dest{ 1070 if-feature multi-src-dest; 1071 config false; 1072 description 1073 "The selected VN Member when multi-src 1074 and/or mult-destination is enabled."; 1075 leaf selected-vn-member{ 1076 type leafref { 1077 path "/vn/vn-list/vn-member-list" 1078 + "/vn-member-id"; 1079 } 1080 description 1081 "The selected VN Member along the set 1082 of source and destination configured 1083 with multi-source and/or multi-destination"; 1084 } 1085 } 1086 */ 1087 /*uses service-metric;*/ 1088 leaf admin-status { 1089 type identityref { 1090 base vn-admin-state-type; 1091 } 1092 default vn-admin-state-up; 1093 description "VN administrative state."; 1094 } 1095 leaf oper-status { 1096 type identityref { 1097 base vn-state-type; 1098 } 1099 config false; 1100 description "VN operational state."; 1101 } 1102 uses vn-policy; 1103 }//vn-list 1104 }//vn 1106 /* 1107 * Notifications - TBD 1108 */ 1109 /* 1110 * RPC 1111 */ 1112 rpc vn-compute{ 1113 description 1114 "The VN computation without actual 1115 instantiation"; 1116 input { 1117 leaf abstract-node { 1118 type leafref { 1119 path "/nw:networks/nw:network/nw:node/" 1120 + "tet:te-node-id"; 1121 } 1122 description 1123 "a reference to the abstract node in TE 1124 Topology"; 1125 } 1126 list vn-member-list{ 1127 key "vn-member-id"; 1128 description 1129 "List of VN-members in a VN"; 1130 uses vn-member; 1131 } 1132 uses vn-policy; 1133 /*uses service-metric;*/ 1134 } 1135 output { 1136 list vn-member-list{ 1137 key "vn-member-id"; 1138 description 1139 "List of VN-members in a VN"; 1140 uses vn-member; 1141 leaf if-selected{ 1142 if-feature multi-src-dest; 1143 type boolean; 1144 default false; 1145 description 1146 "Is the vn-member is selected among 1147 the multi-src/dest options"; 1148 } 1149 /*uses metrics-op;*/ 1150 leaf compute-status { 1151 type identityref { 1152 base vn-compute-state-type; 1153 } 1154 description 1155 "VN-member compute state."; 1156 } 1157 } 1158 /* 1159 container multi-src-dest{ 1160 if-feature multi-src-dest; 1161 description 1162 "The selected VN Member when multi-src 1163 and/or mult-destination is enabled."; 1164 leaf selected-vn-member-id{ 1165 type uint32; 1166 description 1167 "The selected VN Member-id from the 1168 input"; 1169 } 1170 }*/ 1171 } 1172 } 1173 } 1175 1177 7. JSON Example 1179 This section provides json implementation examples as to how VN YANG 1180 model and TE topology model are used together to instantiate virtual 1181 networks. 1183 The example in this section includes following VN 1185 o VN1 (Type 1): Which maps to the single node topology abstract1 1186 (node D1) and consist of VN Members 104 (L1 to L4), 107 (L1 to 1187 L7), 204 (L2 to L4), 308 (L3 to L8) and 108 (L1 to L8). We also 1188 show how disjointness (node, link, srlg) is supported in the 1189 example on the global level (i.e., connectivity matrices level). 1191 o VN2 (Type 2): Which maps to the single node topology abstract2 1192 (node D2), this topology has an underlay topology (absolute) (see 1193 figure in section 3.2). This VN has a single VN member 105 (L1 to 1194 L5) and an underlay path (S4 and S7) has been set in the 1195 connectivity matrix of abstract2 topology; 1197 o VN3 (Type 1): This VN has a multi-source, multi-destination 1198 feature enable for VN Member 104 (L1 to L4)/107 (L1 to L7) 1199 [multi-src] and VN Member 204 (L2 to L4)/304 (L3 to L4) [multi- 1200 dest] usecase. The selected VN-member is known via the field "if- 1201 selected" and the corresponding connectivity-matrix-id. 1203 Note that the VN YANG model also include the AP and VNAP which shows 1204 various VN using the same AP. 1205 7.1. VN JSON 1207 { 1208 "ap":{ 1209 "access-point-list": [ 1210 { 1211 "access-point-id": 101, 1212 "access-point-name": "101", 1213 "vn-ap": [ 1214 { 1215 "vn-ap-id": 10101, 1216 "vn": 1, 1217 "abstract-node": "D1", 1218 "ltp": "1-0-1" 1219 }, 1220 { 1221 "vn-ap-id": 10102, 1222 "vn": 2, 1223 "abstract-node": "D2", 1224 "ltp": "1-0-1" 1225 }, 1226 { 1227 "vn-ap-id": 10103, 1228 "vn": 3, 1229 "abstract-node": "D3", 1230 "ltp": "1-0-1" 1231 }, 1232 ] 1233 }, 1234 { 1235 "access-point-id": 202, 1236 "access-point-name": "202", 1237 "vn-ap": [ 1238 { 1239 "vn-ap-id": 20201, 1240 "vn": 1, 1241 "abstract-node": "D1", 1242 "ltp": "2-0-2" 1243 } 1244 ] 1245 }, 1246 { 1247 "access-point-id": 303, 1248 "access-point-name": "303", 1249 "vn-ap": [ 1250 { 1251 "vn-ap-id": 30301, 1252 "vn": 1, 1253 "abstract-node": "D1", 1254 "ltp": "3-0-3" 1255 }, 1256 { 1257 "vn-ap-id": 30303, 1258 "vn": 3, 1259 "abstract-node": "D3", 1260 "ltp": "3-0-3" 1261 } 1262 ] 1263 }, 1264 { 1265 "access-point-id": 440, 1266 "access-point-name": "440", 1267 "vn-ap": [ 1268 { 1269 "vn-ap-id": 44001, 1270 "vn": 1, 1271 "abstract-node": "D1", 1272 "ltp": "4-4-0" 1273 } 1274 ] 1275 }, 1276 { 1277 "access-point-id": 550, 1278 "access-point-name": "550", 1279 "vn-ap": [ 1280 { 1281 "vn-ap-id": 55002, 1282 "vn": 2, 1283 "abstract-node": "D2", 1284 "ltp": "5-5-0" 1285 } 1286 ] 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 } 1581 }, 1582 { 1583 "tp-id": "2-2-0", 1584 "te-tp-id": 20200, 1585 "te": { 1586 "interface-switching-capability": [ 1587 { 1588 "switching-capability": "switching-otn", 1589 "encoding": "lsp-encoding-oduk" 1590 } 1591 ] 1592 } 1593 }, 1594 { 1595 "tp-id": "3-0-3", 1596 "te-tp-id": 30003, 1597 "te": { 1598 "interface-switching-capability": [ 1599 { 1600 "switching-capability": "switching-otn", 1601 "encoding": "lsp-encoding-oduk" 1602 } 1603 ] 1604 } 1605 }, 1606 { 1607 "tp-id": "3-3-0", 1608 "te-tp-id": 30300, 1609 "te": { 1610 "interface-switching-capability": [ 1611 { 1612 "switching-capability": "switching-otn", 1613 "encoding": "lsp-encoding-oduk" 1614 } 1615 ] 1616 } 1617 }, 1618 { 1619 "tp-id": "4-0-4", 1620 "te-tp-id": 40004, 1621 "te": { 1622 "interface-switching-capability": [ 1623 { 1624 "switching-capability": "switching-otn", 1625 "encoding": "lsp-encoding-oduk" 1626 } 1627 ] 1628 } 1629 }, 1630 { 1631 "tp-id": "4-4-0", 1632 "te-tp-id": 40400, 1633 "te": { 1634 "interface-switching-capability": [ 1635 { 1636 "switching-capability": "switching-otn", 1637 "encoding": "lsp-encoding-oduk" 1638 } 1639 ] 1640 } 1641 }, 1642 { 1643 "tp-id": "5-0-5", 1644 "te-tp-id": 50005, 1645 "te": { 1646 "interface-switching-capability": [ 1647 { 1648 "switching-capability": "switching-otn", 1649 "encoding": "lsp-encoding-oduk" 1650 } 1651 ] 1652 } 1653 }, 1654 { 1655 "tp-id": "5-5-0", 1656 "te-tp-id": 50500, 1657 "te": { 1658 "interface-switching-capability": [ 1659 { 1660 "switching-capability": "switching-otn", 1661 "encoding": "lsp-encoding-oduk" 1662 } 1663 ] 1664 } 1665 }, 1666 { 1667 "tp-id": "6-0-6", 1668 "te-tp-id": 60006, 1669 "te": { 1670 "interface-switching-capability": [ 1671 { 1672 "switching-capability": "switching-otn", 1673 "encoding": "lsp-encoding-oduk" 1674 } 1675 ] 1676 } 1677 }, 1678 { 1679 "tp-id": "6-6-0", 1680 "te-tp-id": 60600, 1681 "te": { 1682 "interface-switching-capability": [ 1683 { 1684 "switching-capability": "switching-otn", 1685 "encoding": "lsp-encoding-oduk" 1686 } 1687 ] 1688 } 1689 }, 1690 { 1691 "tp-id": "7-0-7", 1692 "te-tp-id": 70007, 1693 "te": { 1694 "interface-switching-capability": [ 1695 { 1696 "switching-capability": "switching-otn", 1697 "encoding": "lsp-encoding-oduk" 1698 } 1699 ] 1700 } 1701 }, 1702 { 1703 "tp-id": "7-7-0", 1704 "te-tp-id": 70700, 1705 "te": { 1706 "interface-switching-capability": [ 1707 { 1708 "switching-capability": "switching-otn", 1709 "encoding": "lsp-encoding-oduk" 1710 } 1711 ] 1712 } 1713 }, 1714 { 1715 "tp-id": "8-0-8", 1716 "te-tp-id": 80008, 1717 "te": { 1718 "interface-switching-capability": [ 1719 { 1720 "switching-capability": "switching-otn", 1721 "encoding": "lsp-encoding-oduk" 1722 } 1723 ] 1724 } 1725 }, 1726 { 1727 "tp-id": "8-8-0", 1728 "te-tp-id": 80800, 1729 "te": { 1730 "interface-switching-capability": [ 1731 { 1732 "switching-capability": "switching-otn", 1733 "encoding": "lsp-encoding-oduk" 1734 } 1735 ] 1736 } 1737 } 1738 ] 1739 } 1740 ] 1741 }, 1742 { 1743 "network-types": { 1744 "te-topology": {} 1745 }, 1746 "network-id": "abstract2", 1747 "provider-id": 201, 1748 "client-id": 600, 1749 "te-topology-id": "te-topology:abstract2", 1750 "node": [ 1751 { 1752 "node-id": "D2", 1753 "te-node-id": "2.0.1.2", 1754 "te": { 1755 "te-node-attributes": { 1756 "domain-id" : 1, 1757 "is-abstract": [null], 1758 "connectivity-matrices": { 1759 "is-allowed": true, 1760 "underlay": { 1761 "enabled": true 1762 }, 1763 "path-constraints": { 1764 "bandwidth-generic": { 1765 "te-bandwidth": { 1766 "generic": [ 1767 { 1768 "generic": "0x1p10" 1769 } 1770 ] 1771 } 1772 } 1773 }, 1774 "optimizations": { 1775 "objective-function": { 1776 "objective-function-type": "of-maximize-residual- 1777 bandwidth" 1778 } 1779 }, 1780 "connectivity-matrix": [ 1781 { 1782 "id": 105, 1783 "from": "1-0-1", 1784 "to": "5-5-0", 1785 "underlay": { 1786 "enabled": true, 1787 "primary-path": { 1788 "network-ref": "absolute", 1789 "path-element": [ 1790 { 1791 "path-element-id": 1, 1792 "index": 1, 1793 "numbered-hop": { 1794 "address": "4.4.4.4", 1795 "hop-type": "STRICT" 1796 } 1797 }, 1798 { 1799 "path-element-id": 2, 1800 "index": 2, 1801 "numbered-hop": { 1802 "address": "7.7.7.7", 1803 "hop-type": "STRICT" 1804 } 1805 } 1806 ] 1807 } 1808 } 1809 } 1810 ] 1811 } 1812 } 1813 }, 1814 "termination-point": [ 1815 { 1816 "tp-id": "1-0-1", 1817 "te-tp-id": 10001, 1818 "te": { 1819 "interface-switching-capability": [ 1820 { 1821 "switching-capability": "switching-otn", 1822 "encoding": "lsp-encoding-oduk" 1823 } 1824 ] 1825 } 1826 }, 1827 { 1828 "tp-id": "1-1-0", 1829 "te-tp-id": 10100, 1830 "te": { 1831 "interface-switching-capability": [ 1832 { 1833 "switching-capability": "switching-otn", 1834 "encoding": "lsp-encoding-oduk" 1835 } 1836 ] 1837 } 1838 }, 1839 { 1840 "tp-id": "2-0-2", 1841 "te-tp-id": 20002, 1842 "te": { 1843 "interface-switching-capability": [ 1844 { 1845 "switching-capability": "switching-otn", 1846 "encoding": "lsp-encoding-oduk" 1847 } 1848 ] 1849 } 1850 }, 1851 { 1852 "tp-id": "2-2-0", 1853 "te-tp-id": 20200, 1854 "te": { 1855 "interface-switching-capability": [ 1856 { 1857 "switching-capability": "switching-otn", 1858 "encoding": "lsp-encoding-oduk" 1859 } 1860 ] 1861 } 1862 }, 1863 { 1864 "tp-id": "3-0-3", 1865 "te-tp-id": 30003, 1866 "te": { 1867 "interface-switching-capability": [ 1868 { 1869 "switching-capability": "switching-otn", 1870 "encoding": "lsp-encoding-oduk" 1871 } 1872 ] 1873 } 1874 }, 1875 { 1876 "tp-id": "3-3-0", 1877 "te-tp-id": 30300, 1878 "te": { 1879 "interface-switching-capability": [ 1880 { 1881 "switching-capability": "switching-otn", 1882 "encoding": "lsp-encoding-oduk" 1883 } 1884 ] 1885 } 1886 }, 1887 { 1888 "tp-id": "4-0-4", 1889 "te-tp-id": 40004, 1890 "te": { 1891 "interface-switching-capability": [ 1892 { 1893 "switching-capability": "switching-otn", 1894 "encoding": "lsp-encoding-oduk" 1895 } 1896 ] 1897 } 1898 }, 1899 { 1900 "tp-id": "4-4-0", 1901 "te-tp-id": 40400, 1902 "te": { 1903 "interface-switching-capability": [ 1904 { 1905 "switching-capability": "switching-otn", 1906 "encoding": "lsp-encoding-oduk" 1907 } 1908 ] 1909 } 1910 }, 1911 { 1912 "tp-id": "5-0-5", 1913 "te-tp-id": 50005, 1914 "te": { 1915 "interface-switching-capability": [ 1916 { 1917 "switching-capability": "switching-otn", 1918 "encoding": "lsp-encoding-oduk" 1919 } 1920 ] 1921 } 1922 }, 1923 { 1924 "tp-id": "5-5-0", 1925 "te-tp-id": 50500, 1926 "te": { 1927 "interface-switching-capability": [ 1928 { 1929 "switching-capability": "switching-otn", 1930 "encoding": "lsp-encoding-oduk" 1931 } 1932 ] 1933 } 1934 }, 1935 { 1936 "tp-id": "6-0-6", 1937 "te-tp-id": 60006, 1938 "te": { 1939 "interface-switching-capability": [ 1940 { 1941 "switching-capability": "switching-otn", 1942 "encoding": "lsp-encoding-oduk" 1943 } 1944 ] 1945 } 1946 }, 1947 { 1948 "tp-id": "6-6-0", 1949 "te-tp-id": 60600, 1950 "te": { 1951 "interface-switching-capability": [ 1952 { 1953 "switching-capability": "switching-otn", 1954 "encoding": "lsp-encoding-oduk" 1955 } 1956 ] 1957 } 1958 }, 1959 { 1960 "tp-id": "7-0-7", 1961 "te-tp-id": 70007, 1962 "te": { 1963 "interface-switching-capability": [ 1964 { 1965 "switching-capability": "switching-otn", 1966 "encoding": "lsp-encoding-oduk" 1967 } 1968 ] 1969 } 1970 }, 1971 { 1972 "tp-id": "7-7-0", 1973 "te-tp-id": 70700, 1974 "te": { 1975 "interface-switching-capability": [ 1976 { 1977 "switching-capability": "switching-otn", 1978 "encoding": "lsp-encoding-oduk" 1979 } 1980 ] 1981 } 1982 }, 1983 { 1984 "tp-id": "8-0-8", 1985 "te-tp-id": 80008, 1986 "te": { 1987 "interface-switching-capability": [ 1988 { 1989 "switching-capability": "switching-otn", 1990 "encoding": "lsp-encoding-oduk" 1991 } 1992 ] 1993 } 1994 }, 1995 { 1996 "tp-id": "8-8-0", 1997 "te-tp-id": 80800, 1998 "te": { 1999 "interface-switching-capability": [ 2000 { 2001 "switching-capability": "switching-otn", 2002 "encoding": "lsp-encoding-oduk" 2003 } 2004 ] 2005 } 2006 } 2007 ] 2008 } 2009 ] 2010 }, 2011 { 2012 "network-types": { 2013 "te-topology": {} 2014 }, 2015 "network-id": "abstract3", 2016 "provider-id": 201, 2017 "client-id": 600, 2018 "te-topology-id": "te-topology:abstract3", 2019 "node": [ 2020 { 2021 "node-id": "D3", 2022 "te-node-id": "3.0.1.1", 2023 "te": { 2024 "te-node-attributes": { 2025 "domain-id" : 3, 2026 "is-abstract": [null], 2027 "connectivity-matrices": { 2028 "is-allowed": true, 2029 "path-constraints": { 2030 "bandwidth-generic": { 2031 "te-bandwidth": { 2032 "generic": [ 2033 { 2034 "generic": "0x1p10", 2035 } 2036 ] 2037 } 2038 } 2039 }, 2040 "connectivity-matrix": [ 2041 { 2042 "id": 107, 2043 "from": "1-0-1", 2044 "to": "7-7-0" 2045 }, 2046 { 2047 "id": 308, 2048 "from": "3-0-3", 2049 "to": "8-8-0" 2050 }, 2051 ] 2052 } 2053 } 2054 }, 2055 "termination-point": [ 2056 { 2057 "tp-id": "1-0-1", 2058 "te-tp-id": 10001, 2059 "te": { 2060 "interface-switching-capability": [ 2061 { 2062 "switching-capability": "switching-otn", 2063 "encoding": "lsp-encoding-oduk" 2064 } 2065 ] 2066 } 2067 }, 2068 { 2069 "tp-id": "1-1-0", 2070 "te-tp-id": 10100, 2071 "te": { 2072 "interface-switching-capability": [ 2073 { 2074 "switching-capability": "switching-otn", 2075 "encoding": "lsp-encoding-oduk" 2076 } 2077 ] 2078 } 2079 }, 2080 { 2081 "tp-id": "2-0-2", 2082 "te-tp-id": 20002, 2083 "te": { 2084 "interface-switching-capability": [ 2085 { 2086 "switching-capability": "switching-otn", 2087 "encoding": "lsp-encoding-oduk" 2088 } 2089 ] 2090 } 2091 }, 2092 { 2093 "tp-id": "2-2-0", 2094 "te-tp-id": 20200, 2095 "te": { 2096 "interface-switching-capability": [ 2097 { 2098 "switching-capability": "switching-otn", 2099 "encoding": "lsp-encoding-oduk" 2100 } 2101 ] 2102 } 2103 }, 2104 { 2105 "tp-id": "3-0-3", 2106 "te-tp-id": 30003, 2107 "te": { 2108 "interface-switching-capability": [ 2109 { 2110 "switching-capability": "switching-otn", 2111 "encoding": "lsp-encoding-oduk" 2112 } 2113 ] 2114 } 2115 }, 2116 { 2117 "tp-id": "3-3-0", 2118 "te-tp-id": 30300, 2119 "te": { 2120 "interface-switching-capability": [ 2121 { 2122 "switching-capability": "switching-otn", 2123 "encoding": "lsp-encoding-oduk" 2124 } 2125 ] 2126 } 2127 }, 2128 { 2129 "tp-id": "4-0-4", 2130 "te-tp-id": 40004, 2131 "te": { 2132 "interface-switching-capability": [ 2133 { 2134 "switching-capability": "switching-otn", 2135 "encoding": "lsp-encoding-oduk" 2136 } 2137 ] 2138 } 2139 }, 2140 { 2141 "tp-id": "4-4-0", 2142 "te-tp-id": 40400, 2143 "te": { 2144 "interface-switching-capability": [ 2145 { 2146 "switching-capability": "switching-otn", 2147 "encoding": "lsp-encoding-oduk" 2148 } 2149 ] 2150 } 2151 }, 2152 { 2153 "tp-id": "5-0-5", 2154 "te-tp-id": 50005, 2155 "te": { 2156 "interface-switching-capability": [ 2157 { 2158 "switching-capability": "switching-otn", 2159 "encoding": "lsp-encoding-oduk" 2160 } 2161 ] 2162 } 2163 }, 2164 { 2165 "tp-id": "5-5-0", 2166 "te-tp-id": 50500, 2167 "te": { 2168 "interface-switching-capability": [ 2169 { 2170 "switching-capability": "switching-otn", 2171 "encoding": "lsp-encoding-oduk" 2172 } 2173 ] 2174 } 2175 }, 2176 { 2177 "tp-id": "6-0-6", 2178 "te-tp-id": 60006, 2179 "te": { 2180 "interface-switching-capability": [ 2181 { 2182 "switching-capability": "switching-otn", 2183 "encoding": "lsp-encoding-oduk" 2184 } 2185 ] 2186 } 2187 }, 2188 { 2189 "tp-id": "6-6-0", 2190 "te-tp-id": 60600, 2191 "te": { 2192 "interface-switching-capability": [ 2193 { 2194 "switching-capability": "switching-otn", 2195 "encoding": "lsp-encoding-oduk" 2196 } 2197 ] 2198 } 2199 }, 2200 { 2201 "tp-id": "7-0-7", 2202 "te-tp-id": 70007, 2203 "te": { 2204 "interface-switching-capability": [ 2205 { 2206 "switching-capability": "switching-otn", 2207 "encoding": "lsp-encoding-oduk" 2208 } 2209 ] 2210 } 2211 }, 2212 { 2213 "tp-id": "7-7-0", 2214 "te-tp-id": 70700, 2215 "te": { 2216 "interface-switching-capability": [ 2217 { 2218 "switching-capability": "switching-otn", 2219 "encoding": "lsp-encoding-oduk" 2220 } 2221 ] 2222 } 2223 }, 2224 { 2225 "tp-id": "8-0-8", 2226 "te-tp-id": 80008, 2227 "te": { 2228 "interface-switching-capability": [ 2229 { 2230 "switching-capability": "switching-otn", 2231 "encoding": "lsp-encoding-oduk" 2232 } 2233 ] 2234 } 2235 }, 2236 { 2237 "tp-id": "8-8-0", 2238 "te-tp-id": 80800, 2239 "te": { 2240 "interface-switching-capability": [ 2241 { 2242 "switching-capability": "switching-otn", 2243 "encoding": "lsp-encoding-oduk" 2244 } 2245 ] 2246 } 2247 } 2248 ] 2249 } 2250 ] 2251 }, 2252 ] 2253 } 2254 } 2256 8. Security Considerations 2258 The configuration, state, and action data defined in this document 2259 are designed to be accessed via a management protocol with a secure 2260 transport layer, such as NETCONF [RFC6241] or RESTCONF [RFC8040]. 2261 The lowest NETCONF layer is the secure transport layer, and the 2262 mandatory-to-implement secure transport is Secure Shell (SSH) 2264 [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory- 2265 to-implement secure transport is TLS [RFC8446]. 2267 The NETCONF access control model [RFC8341] provides the means to 2268 restrict access for particular NETCONF users to a preconfigured 2269 subset of all available NETCONF protocol operations and content. 2271 The model presented in this document is used in the interface 2272 between the Customer Network Controller (CNC) and Multi-Domain 2273 Service Coordinator (MDSC), which is referred to as CNC-MDSC 2274 Interface (CMI). Therefore, many security risks such as malicious 2275 attack and rogue elements attempting to connect to various ACTN 2276 components. Furthermore, some ACTN components (e.g., MSDC) 2277 represent a single point of failure and threat vector and must also 2278 manage policy conflicts and eavesdropping of communication between 2279 different ACTN components. 2281 A number of configuration data nodes defined in this document are 2282 writable/deletable (i.e., "config true") These data nodes may be 2283 considered sensitive or vulnerable in some network environments. 2285 These are the subtrees and data nodes and their 2286 sensitivity/vulnerability: 2288 - access-point-list: 2289 o access-point-id 2290 o max-bandwidth 2291 o avl-bandwidth 2293 - vn-ap: 2294 o vn-ap-id 2295 o vn 2296 o abstract-node 2297 o ltp 2299 - vn-list 2300 o vn-id 2301 o vn-topology-id 2302 o abstract-node 2304 - vn-member-id 2305 o src 2306 o src-vn-ap-id 2307 o dest 2308 o dest-vn-ap-id 2309 o connectivity-matrix-id 2311 9. IANA Considerations 2313 This document registers the following namespace URIs in the IETF XML 2314 registry [RFC3688]: 2316 -------------------------------------------------------------------- 2317 URI: urn:ietf:params:xml:ns:yang:ietf-vn 2318 Registrant Contact: The IESG. 2319 XML: N/A, the requested URI is an XML namespace. 2320 -------------------------------------------------------------------- 2322 This document registers the following YANG modules in the YANG 2323 Module 2325 Names registry [RFC6020]: 2327 -------------------------------------------------------------------- 2328 name: ietf-vn 2329 namespace: urn:ietf:params:xml:ns:yang:ietf-vn 2330 reference: RFC XXXX (TDB) 2331 -------------------------------------------------------------------- 2333 10. Acknowledgments 2335 The authors would like to thank Xufeng Liu and Adrian Farrel for 2336 their helpful comments and valuable suggestions. 2338 11. References 2340 11.1. Normative References 2342 [TE-TOPO] X. Liu, et al., "YANG Data Model for TE Topologies", work 2343 in progress: draft-ietf-teas-yang-te-topo. 2345 [TE-tunnel] T. Saad, et al., "A YANG Data Model for Traffic 2346 Engineering Tunnels and Interfaces", work in progress: 2347 draft-ietf-teas-yang-te. 2349 11.2. Informative References 2351 [RFC7926] A. Farrel (Ed.), "Problem Statement and Architecture for 2352 Information Exchange between Interconnected Traffic- 2353 Engineered Networks", RFC 7926, July 2016. 2355 [RFC8453] D. Ceccarelli and Y. Lee (Editors), "Framework for 2356 Abstraction and Control of Traffic Engineered Networks", 2357 RFC 8453, August 2018. 2359 [TE-MAP] Y. Lee, D. Dhody, and D. Ceccarelli, "Traffic Engineering 2360 and Service Mapping Yang Model", draft-lee-teas-te- 2361 service-mapping-yang, work in progress. 2363 [ACTN-PM] Y. Lee, et al., "YANG models for ACTN TE Performance 2364 Monitoring Telemetry and Network Autonomics", draft-lee- 2365 teas-actn-pm-telemetry-autonomics, work in progress. 2367 [L1CSM] G. Fioccola, Ed. & Y. Lee, Ed., "A Yang Data Model for L1 2368 Connectivity Service Model (L1CSM)", draft-ietf-ccamp- 2369 l1csm-yang, work in progress. 2370 [L2SM] G. Fioccola, Ed., "A YANG Data Model for L2VPN Service 2371 Delivery", draft-ietf-l2sm-l2vpn-service-model, work in 2372 progress. 2374 [RFC8299] Q. Wu, Ed., S. Litkowski, L. Tomotaki, and K. Ogaki, "YANG 2375 Data Model for L3VPN Service Delivery", RFC 8299, January 2376 2018. 2378 [RFC8309] Q. Wu, W. Cheng, and A. Farrel. "Service Models 2379 Explained", RFC 8309, January 2018. 2381 [RFC8340] M. Bjorklund and L. Berger (Editors), "YANG Tree 2382 Diagrams", RFC 8340, March 2018. 2384 [RFC8345] A. Clemm, et al, "A YANG Data Model for Network 2385 Topologies", RFC 8345, March 2018. 2387 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2388 and R. Wilton, "Network Management Datastore Architecture 2389 (NMDA)", RFC 8342, March 2018. 2391 12. Contributors 2393 Contributor's Addresses 2395 Haomian Zheng 2396 Huawei Technologies 2397 Email: zhenghaomian@huawei.com 2399 Xian Zhang 2400 Huawei Technologies 2401 Email: zhang.xian@huawei.com 2403 Sergio Belotti 2404 Nokia 2405 Email: sergio.belotti@nokia.com 2407 Takuya Miyasaka 2408 KDDI 2409 Email: ta-miyasaka@kddi.com 2411 Authors' Addresses 2413 Young Lee (ed.) 2414 Huawei Technologies 2415 Email: leeyoung@huawei.com 2417 Dhruv Dhody (ed.) 2418 Huawei Technologies 2419 Email: dhruv.ietf@gmail.com 2420 Daniele Ceccarelli 2421 Ericsson 2422 Torshamnsgatan,48 2423 Stockholm, Sweden 2424 Email: daniele.ceccarelli@ericsson.com 2426 Igor Bryskin 2427 Huawei 2428 Email: Igor.Bryskin@huawei.com 2430 Bin Yeong Yoon 2431 ETRI 2432 Email: byyun@etri.re.kr 2434 Qin Wu 2435 Huawei Technologies 2436 Email: bill.wu@huawei.com 2438 Peter Park 2439 KT 2440 Email: peter.park@kt.com