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