idnits 2.17.1 draft-ietf-teas-actn-vn-yang-07.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 (October 31, 2019) is 1638 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-21 == 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 SKKU 4 Intended status: Standards Track D. Dhody, Ed. 5 Expires: May 3, 2020 Huawei Technologies 6 D. Ceccarelli 7 Ericsson 8 I. Bryskin 9 Futurewei 10 B. Yoon 11 ETRI 12 October 31, 2019 14 A Yang Data Model for VN Operation 15 draft-ietf-teas-actn-vn-yang-07 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 May 3, 2020. 39 Copyright Notice 41 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 25 78 7.1. VN JSON . . . . . . . . . . . . . . . . . . . . . . . . . 26 79 7.2. TE-topology JSON . . . . . . . . . . . . . . . . . . . . 32 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 48 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 82 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 50 85 11.2. Informative References . . . . . . . . . . . . . . . . . 51 86 Appendix A. Contributors Addresses . . . . . . . . . . . . . . . 52 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 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@2019-10-31.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 revision 2019-10-31 { 735 description 736 "initial version."; 737 reference 738 "RFC XXXX: A Yang Data Model for VN Operation"; 739 } 741 /* Features */ 743 feature multi-src-dest { 744 description 745 "Support for selection of one src or destination 746 among multiple."; 747 } 749 /* Identity VN State*/ 751 identity vn-state-type { 752 description 753 "Base identity for VN state"; 754 } 756 identity vn-state-up { 757 base vn-state-type; 758 description 759 "VN state up"; 760 } 762 identity vn-state-down { 763 base vn-state-type; 764 description 765 "VN state down"; 766 } 768 /* Identity VN Admin State*/ 770 identity vn-admin-state-type { 771 description 772 "Base identity for VN admin states"; 773 } 775 identity vn-admin-state-up { 776 base vn-admin-state-type; 777 description 778 "VN administratively state up"; 779 } 781 identity vn-admin-state-down { 782 base vn-admin-state-type; 783 description 784 "VN administratively state down"; 785 } 787 /* Identity VN Compute State*/ 789 identity vn-compute-state-type { 790 description 791 "Base identity for compute states"; 792 } 794 identity vn-compute-state-computing { 795 base vn-compute-state-type; 796 description 797 "State path compute in progress"; 798 } 800 identity vn-compute-state-computation-ok { 801 base vn-compute-state-type; 802 description 803 "State path compute successful"; 804 } 806 identity vn-compute-state-computatione-failed { 807 base vn-compute-state-type; 808 description 809 "State path compute failed"; 810 } 812 /* typedef */ 814 typedef vn-disjointness { 815 type bits { 816 bit node { 817 position 0; 818 description 819 "node disjoint"; 820 } 821 bit link { 822 position 1; 823 description 824 "link disjoint"; 825 } 826 bit srlg { 827 position 2; 828 description 829 "srlg disjoint"; 830 } 831 } 832 description 833 "type of the resource disjointness for VN level applied 834 across all VN members in a VN"; 835 } 837 /* Groupings */ 839 grouping vn-ap { 840 description 841 "VNAP related information"; 842 leaf vn-ap-id { 843 type uint32; 844 description 845 "unique identifier for the referred VNAP"; 846 } 847 leaf vn { 848 type leafref { 849 path "/vn/vn-list/vn-id"; 850 } 851 description 852 "reference to the VN"; 853 } 854 leaf abstract-node { 855 type leafref { 856 path "/nw:networks/nw:network/nw:node/tet:te-node-id"; 857 } 858 description 859 "a reference to the abstract node in TE Topology that 860 represent the VN"; 861 } 862 leaf ltp { 863 type leafref { 864 path "/nw:networks/nw:network/nw:node/" 865 + "nt:termination-point/tet:te-tp-id"; 866 } 867 description 868 "Reference LTP in the TE-topology"; 869 } 870 }//vn-ap 872 grouping access-point { 873 description 874 "AP related information"; 875 leaf access-point-id { 876 type uint32; 877 description 878 "unique identifier for the referred access point"; 879 } 880 leaf access-point-name { 881 type string; 882 description 883 "ap name"; 884 } 885 leaf pe { 886 type leafref { 887 path "/nw:networks/nw:network/nw:node/tet:te-node-id"; 888 } 889 description 890 "a reference to the PE node in the native TE Topology"; 891 } 892 leaf max-bandwidth { 893 type te-types:te-bandwidth; 894 description 895 "max bandwidth of the AP"; 896 } 897 leaf avl-bandwidth { 898 type te-types:te-bandwidth; 899 description 900 "available bandwidth of the AP"; 901 } 902 /*add details and any other properties of AP, 903 not associated by a VN 904 CE port, PE port etc. 905 */ 906 list vn-ap { 907 key "vn-ap-id"; 908 uses vn-ap; 909 description 910 "list of VNAP in this AP"; 911 } 912 }//access-point 914 grouping vn-member { 915 description 916 "vn-member is described by this container"; 917 leaf vn-member-id { 918 type uint32; 919 description 920 "vn-member identifier"; 921 } 922 container src { 923 description 924 "the source of VN Member"; 925 leaf src { 926 type leafref { 927 path "/ap/access-point-list/access-point-id"; 928 } 929 description 930 "reference to source AP"; 931 } 932 leaf src-vn-ap-id { 933 type leafref { 934 path "/ap/access-point-list/vn-ap/vn-ap-id"; 935 } 936 description 937 "reference to source VNAP"; 938 } 939 leaf multi-src { 940 if-feature "multi-src-dest"; 941 type boolean; 942 description 943 "Is source part of multi-source, where 944 only one of the source is enabled"; 945 } 946 } 947 container dest { 948 description 949 "the destination of VN Member"; 950 leaf dest { 951 type leafref { 952 path "/ap/access-point-list/access-point-id"; 953 } 954 description 955 "reference to destination AP"; 956 } 957 leaf dest-vn-ap-id { 958 type leafref { 959 path "/ap/access-point-list/vn-ap/vn-ap-id"; 960 } 961 description 962 "reference to dest VNAP"; 963 } 964 leaf multi-dest { 965 if-feature "multi-src-dest"; 966 type boolean; 967 description 968 "Is destination part of multi-destination, where only one 969 of the destination is enabled"; 970 } 971 } 972 leaf connectivity-matrix-id { 973 type leafref { 974 path "/nw:networks/nw:network/nw:node/tet:te/" 975 + "tet:te-node-attributes/" 976 + "tet:connectivity-matrices/" 977 + "tet:connectivity-matrix/tet:id"; 978 } 979 description 980 "reference to connectivity-matrix"; 981 } 982 }//vn-member 984 grouping vn-policy { 985 description 986 "policy for VN-level diverisity"; 987 leaf vn-level-diversity { 988 type vn-disjointness; 989 description 990 "the type of disjointness on the VN level (i.e., across all 991 VN members)"; 992 } 993 } 995 /* Configuration data nodes */ 997 container ap { 998 description 999 "AP configurations"; 1000 list access-point-list { 1001 key "access-point-id"; 1002 description 1003 "access-point identifier"; 1004 uses access-point { 1005 description 1006 "access-point information"; 1007 } 1008 } 1009 } 1010 container vn { 1011 description 1012 "VN configurations"; 1013 list vn-list { 1014 key "vn-id"; 1015 description 1016 "a virtual network is identified by a vn-id"; 1017 leaf vn-id { 1018 type uint32; 1019 description 1020 "a unique vn identifier"; 1021 } 1022 leaf vn-name { 1023 type string; 1024 description 1025 "vn name"; 1026 } 1027 leaf vn-topology-id { 1028 type te-types:te-topology-id; 1029 description 1030 "An optional identifier to the TE Topology Model where the 1031 abstract nodes and links of the Topology can be found for 1032 Type 2 VNS"; 1033 } 1034 leaf abstract-node { 1035 type leafref { 1036 path "/nw:networks/nw:network/nw:node/tet:te-node-id"; 1037 } 1038 description 1039 "a reference to the abstract node in TE Topology"; 1040 } 1041 list vn-member-list { 1042 key "vn-member-id"; 1043 description 1044 "List of VN-members in a VN"; 1045 uses vn-member; 1046 leaf oper-status { 1047 type identityref { 1048 base vn-state-type; 1049 } 1050 config false; 1051 description 1052 "VN-member operational state."; 1053 } 1054 } 1055 leaf if-selected { 1056 if-feature "multi-src-dest"; 1057 type boolean; 1058 default "false"; 1059 config false; 1060 description 1061 "Is the vn-member is selected among the multi-src/dest 1062 options"; 1063 } 1064 leaf admin-status { 1065 type identityref { 1066 base vn-admin-state-type; 1067 } 1068 default "vn-admin-state-up"; 1069 description 1070 "VN administrative state."; 1071 } 1072 leaf oper-status { 1073 type identityref { 1074 base vn-state-type; 1075 } 1076 config false; 1077 description 1078 "VN operational state."; 1079 } 1080 uses vn-policy; 1081 }//vn-list 1082 }//vn 1084 /* RPC */ 1086 rpc vn-compute { 1087 description 1088 "The VN computation without actual instantiation"; 1089 input { 1090 leaf abstract-node { 1091 type leafref { 1092 path "/nw:networks/nw:network/nw:node/tet:te-node-id"; 1093 } 1094 description 1095 "a reference to the abstract node in TE Topology"; 1096 } 1097 list vn-member-list { 1098 key "vn-member-id"; 1099 description 1100 "List of VN-members in a VN"; 1101 uses vn-member; 1102 } 1103 uses vn-policy; 1104 } 1105 output { 1106 list vn-member-list { 1107 key "vn-member-id"; 1108 description 1109 "List of VN-members in a VN"; 1110 uses vn-member; 1111 leaf if-selected { 1112 if-feature "multi-src-dest"; 1113 type boolean; 1114 default "false"; 1115 description 1116 "Is the vn-member is selected among the multi-src/dest 1117 options"; 1118 } 1119 leaf compute-status { 1120 type identityref { 1121 base vn-compute-state-type; 1122 } 1123 description 1124 "VN-member compute state."; 1125 } 1126 } 1127 } 1128 }//vn-compute 1129 } 1130 1132 7. JSON Example 1134 This section provides json implementation examples as to how VN YANG 1135 model and TE topology model are used together to instantiate virtual 1136 networks. 1138 The example in this section includes following VN 1140 o VN1 (Type 1): Which maps to the single node topology abstract1 1141 (node D1) and consist of VN Members 104 (L1 to L4), 107 (L1 to 1142 L7), 204 (L2 to L4), 308 (L3 to L8) and 108 (L1 to L8). We also 1143 show how disjointness (node, link, srlg) is supported in the 1144 example on the global level (i.e., connectivity matrices level). 1146 o VN2 (Type 2): Which maps to the single node topology abstract2 1147 (node D2), this topology has an underlay topology (absolute) (see 1148 figure in section 3.2). This VN has a single VN member 105 (L1 to 1149 L5) and an underlay path (S4 and S7) has been set in the 1150 connectivity matrix of abstract2 topology; 1152 o VN3 (Type 1): This VN has a multi-source, multi-destination 1153 feature enable for VN Member 104 (L1 to L4)/107 (L1 to L7) {multi- 1154 src} and VN Member 204 (L2 to L4)/304 (L3 to L4) {multi-dest} 1155 usecase. The selected VN-member is known via the field "if- 1156 selected" and the corresponding connectivity-matrix-id. 1158 Note that the VN YANG model also include the AP and VNAP which shows 1159 various VN using the same AP. 1161 7.1. VN JSON 1163 { 1164 "ap":{ 1165 "access-point-list": [ 1166 { 1167 "access-point-id": 101, 1168 "access-point-name": "101", 1169 "vn-ap": [ 1170 { 1171 "vn-ap-id": 10101, 1172 "vn": 1, 1173 "abstract-node": "D1", 1174 "ltp": "1-0-1" 1175 }, 1176 { 1177 "vn-ap-id": 10102, 1178 "vn": 2, 1179 "abstract-node": "D2", 1180 "ltp": "1-0-1" 1181 }, 1182 { 1183 "vn-ap-id": 10103, 1184 "vn": 3, 1185 "abstract-node": "D3", 1186 "ltp": "1-0-1" 1187 }, 1188 ] 1189 }, 1190 { 1191 "access-point-id": 202, 1192 "access-point-name": "202", 1193 "vn-ap": [ 1194 { 1195 "vn-ap-id": 20201, 1196 "vn": 1, 1197 "abstract-node": "D1", 1198 "ltp": "2-0-2" 1199 } 1200 ] 1201 }, 1202 { 1203 "access-point-id": 303, 1204 "access-point-name": "303", 1205 "vn-ap": [ 1206 { 1207 "vn-ap-id": 30301, 1208 "vn": 1, 1209 "abstract-node": "D1", 1210 "ltp": "3-0-3" 1211 }, 1212 { 1213 "vn-ap-id": 30303, 1214 "vn": 3, 1215 "abstract-node": "D3", 1216 "ltp": "3-0-3" 1217 } 1218 ] 1219 }, 1220 { 1221 "access-point-id": 440, 1222 "access-point-name": "440", 1223 "vn-ap": [ 1224 { 1225 "vn-ap-id": 44001, 1226 "vn": 1, 1227 "abstract-node": "D1", 1228 "ltp": "4-4-0" 1229 } 1230 ] 1231 }, 1232 { 1233 "access-point-id": 550, 1234 "access-point-name": "550", 1235 "vn-ap": [ 1236 { 1237 "vn-ap-id": 55002, 1238 "vn": 2, 1239 "abstract-node": "D2", 1240 "ltp": "5-5-0" 1241 } 1242 ] 1243 }, 1244 { 1245 "access-point-id": 770, 1246 "access-point-name": "770", 1247 "vn-ap": [ 1248 { 1249 "vn-ap-id": 77001, 1250 "vn": 1, 1251 "abstract-node": "D1", 1252 "ltp": "7-7-0" 1253 }, 1254 { 1255 "vn-ap-id": 77003, 1256 "vn": 3, 1257 "abstract-node": "D3", 1258 "ltp": "7-7-0" 1259 } 1260 ] 1261 }, 1262 { 1263 "access-point-id": 880, 1264 "access-point-name": "880", 1265 "vn-ap": [ 1266 { 1267 "vn-ap-id": 88001, 1268 "vn": 1, 1269 "abstract-node": "D1", 1270 "ltp": "8-8-0" 1271 }, 1272 { 1273 "vn-ap-id": 88003, 1274 "vn": 3, 1275 "abstract-node": "D3", 1276 "ltp": "8-8-0" 1277 } 1278 ] 1279 } 1280 ] 1281 }, 1282 "vn":{ 1283 "vn-list": [ 1284 { 1285 "vn-id": 1, 1286 "vn-name": "vn1", 1287 "vn-topology-id": "te-topology:abstract1", 1288 "abstract-node": "D1", 1289 "vn-member-list": [ 1290 { 1291 "vn-member-id": 104, 1292 "src": { 1293 "src": 101, 1294 "src-vn-ap-id": 10101, 1295 }, 1296 "dest": { 1297 "dest": 440, 1298 "dest-vn-ap-id": 44001, 1299 }, 1300 "connectivity-matrix-id": 104 1301 }, 1302 { 1303 "vn-member-id": 107, 1304 "src": { 1305 "src": 101, 1306 "src-vn-ap-id": 10101, 1307 }, 1308 "dest": { 1309 "dest": 770, 1310 "dest-vn-ap-id": 77001, 1311 }, 1312 "connectivity-matrix-id": 107 1313 }, 1314 { 1315 "vn-member-id": 204, 1316 "src": { 1317 "src": 202, 1318 "dest-vn-ap-id": 20401, 1319 }, 1320 "dest": { 1321 "dest": 440, 1322 "dest-vn-ap-id": 44001, 1323 }, 1324 "connectivity-matrix-id": 204 1325 }, 1326 { 1327 "vn-member-id": 308, 1328 "src": { 1329 "src": 303, 1330 "src-vn-ap-id": 30301, 1331 }, 1332 "dest": { 1333 "dest": 880, 1334 "src-vn-ap-id": 88001, 1336 }, 1337 "connectivity-matrix-id": 308 1338 }, 1339 { 1340 "vn-member-id": 108, 1341 "src": { 1342 "src": 101, 1343 "src-vn-ap-id": 10101, 1344 }, 1345 "dest": { 1346 "dest": 880, 1347 "dest-vn-ap-id": 88001, 1348 }, 1349 "connectivity-matrix-id": 108 1350 } 1351 ] 1352 }, 1353 { 1354 "vn-id": 2, 1355 "vn-name": "vn2", 1356 "vn-topology-id": "te-topology:abstract2", 1357 "abstract-node": "D2", 1358 "vn-member-list": [ 1359 { 1360 "vn-member-id": 105, 1361 "src": { 1362 "src": 101, 1363 "src-vn-ap-id": 10102, 1364 }, 1365 "dest": { 1366 "dest": 550, 1367 "dest-vn-ap-id": 55002, 1368 }, 1369 "connectivity-matrix-id": 105 1370 } 1371 ] 1372 }, 1373 { 1374 "vn-id": 3, 1375 "vn-name": "vn3", 1376 "vn-topology-id": "te-topology:abstract3", 1377 "abstract-node": "D3", 1378 "vn-member-list": [ 1379 { 1380 "vn-member-id": 104, 1381 "src": { 1382 "src": 101, 1383 }, 1384 "dest": { 1385 "dest": 440, 1386 "multi-dest": true 1387 } 1388 }, 1389 { 1390 "vn-member-id": 107, 1391 "src": { 1392 "src": 101, 1393 "src-vn-ap-id": 10103, 1394 }, 1395 "dest": { 1396 "dest": 770, 1397 "dest-vn-ap-id": 77003, 1398 "multi-dest": true 1399 }, 1400 "connectivity-matrix-id": 107, 1401 "if-selected":true, 1402 }, 1403 { 1404 "vn-member-id": 204, 1405 "src": { 1406 "src": 202, 1407 "multi-src": true, 1408 }, 1409 "dest": { 1410 "dest": 440, 1411 }, 1412 }, 1413 { 1414 "vn-member-id": 304, 1415 "src": { 1416 "src": 303, 1417 "src-vn-ap-id": 30303, 1418 "multi-src": true, 1419 }, 1420 "dest": { 1421 "dest": 440, 1422 "src-vn-ap-id": 44003, 1423 }, 1424 "connectivity-matrix-id": 304, 1425 "if-selected":true, 1426 }, 1427 ] 1428 }, 1430 ] 1431 } 1433 } 1434 } 1436 7.2. TE-topology JSON 1438 { 1439 "networks": { 1440 "network": [ 1441 { 1442 "network-types": { 1443 "te-topology": {} 1444 }, 1445 "network-id": "abstract1", 1446 "provider-id": 201, 1447 "client-id": 600, 1448 "te-topology-id": "te-topology:abstract1", 1449 "node": [ 1450 { 1451 "node-id": "D1", 1452 "te-node-id": "2.0.1.1", 1453 "te": { 1455 "te-node-attributes": { 1456 "domain-id" : 1, 1457 "is-abstract": [null], 1458 "connectivity-matrices": { 1459 "is-allowed": true, 1460 "path-constraints": { 1461 "bandwidth-generic": { 1462 "te-bandwidth": { 1463 "generic": [ 1464 { 1465 "generic": "0x1p10", 1466 } 1467 ] 1468 } 1469 } 1470 "disjointness": "node link srlg", 1472 }, 1473 "connectivity-matrix": [ 1474 { 1475 "id": 104, 1476 "from": "1-0-1", 1477 "to": "4-4-0" 1478 }, 1479 { 1480 "id": 107, 1481 "from": "1-0-1", 1482 "to": "7-7-0" 1483 }, 1484 { 1485 "id": 204, 1486 "from": "2-0-2", 1487 "to": "4-4-0" 1488 }, 1489 { 1490 "id": 308, 1491 "from": "3-0-3", 1492 "to": "8-8-0" 1493 }, 1494 { 1495 "id": 108, 1496 "from": "1-0-1", 1497 "to": "8-8-0" 1498 }, 1499 ] 1500 } 1501 } 1502 }, 1503 "termination-point": [ 1505 { 1506 "tp-id": "1-0-1", 1507 "te-tp-id": 10001, 1508 "te": { 1509 "interface-switching-capability": [ 1510 { 1511 "switching-capability": "switching-otn", 1512 "encoding": "lsp-encoding-oduk" 1513 } 1514 ] 1515 } 1516 }, 1517 { 1518 "tp-id": "1-1-0", 1519 "te-tp-id": 10100, 1520 "te": { 1521 "interface-switching-capability": [ 1522 { 1523 "switching-capability": "switching-otn", 1524 "encoding": "lsp-encoding-oduk" 1525 } 1526 ] 1527 } 1529 }, 1530 { 1531 "tp-id": "2-0-2", 1532 "te-tp-id": 20002, 1533 "te": { 1534 "interface-switching-capability": [ 1535 { 1536 "switching-capability": "switching-otn", 1537 "encoding": "lsp-encoding-oduk" 1538 } 1539 ] 1540 } 1541 }, 1542 { 1543 "tp-id": "2-2-0", 1544 "te-tp-id": 20200, 1545 "te": { 1546 "interface-switching-capability": [ 1547 { 1548 "switching-capability": "switching-otn", 1549 "encoding": "lsp-encoding-oduk" 1550 } 1551 ] 1552 } 1553 }, 1554 { 1556 "tp-id": "3-0-3", 1557 "te-tp-id": 30003, 1558 "te": { 1559 "interface-switching-capability": [ 1560 { 1561 "switching-capability": "switching-otn", 1562 "encoding": "lsp-encoding-oduk" 1563 } 1564 ] 1565 } 1566 }, 1567 { 1568 "tp-id": "3-3-0", 1569 "te-tp-id": 30300, 1570 "te": { 1571 "interface-switching-capability": [ 1572 { 1573 "switching-capability": "switching-otn", 1574 "encoding": "lsp-encoding-oduk" 1575 } 1576 ] 1578 } 1579 }, 1580 { 1581 "tp-id": "4-0-4", 1582 "te-tp-id": 40004, 1583 "te": { 1584 "interface-switching-capability": [ 1585 { 1586 "switching-capability": "switching-otn", 1587 "encoding": "lsp-encoding-oduk" 1588 } 1589 ] 1590 } 1591 }, 1592 { 1593 "tp-id": "4-4-0", 1594 "te-tp-id": 40400, 1595 "te": { 1596 "interface-switching-capability": [ 1597 { 1598 "switching-capability": "switching-otn", 1599 "encoding": "lsp-encoding-oduk" 1600 } 1601 ] 1602 } 1603 }, 1604 { 1605 "tp-id": "5-0-5", 1606 "te-tp-id": 50005, 1607 "te": { 1608 "interface-switching-capability": [ 1609 { 1610 "switching-capability": "switching-otn", 1611 "encoding": "lsp-encoding-oduk" 1612 } 1613 ] 1614 } 1615 }, 1616 { 1617 "tp-id": "5-5-0", 1618 "te-tp-id": 50500, 1619 "te": { 1620 "interface-switching-capability": [ 1621 { 1622 "switching-capability": "switching-otn", 1623 "encoding": "lsp-encoding-oduk" 1624 } 1625 ] 1627 } 1628 }, 1629 { 1630 "tp-id": "6-0-6", 1631 "te-tp-id": 60006, 1632 "te": { 1633 "interface-switching-capability": [ 1634 { 1635 "switching-capability": "switching-otn", 1636 "encoding": "lsp-encoding-oduk" 1637 } 1638 ] 1639 } 1640 }, 1641 { 1642 "tp-id": "6-6-0", 1643 "te-tp-id": 60600, 1644 "te": { 1645 "interface-switching-capability": [ 1646 { 1647 "switching-capability": "switching-otn", 1648 "encoding": "lsp-encoding-oduk" 1649 } 1650 ] 1651 } 1652 }, 1653 { 1654 "tp-id": "7-0-7", 1655 "te-tp-id": 70007, 1656 "te": { 1657 "interface-switching-capability": [ 1658 { 1659 "switching-capability": "switching-otn", 1660 "encoding": "lsp-encoding-oduk" 1661 } 1662 ] 1663 } 1664 }, 1665 { 1666 "tp-id": "7-7-0", 1667 "te-tp-id": 70700, 1668 "te": { 1669 "interface-switching-capability": [ 1670 { 1671 "switching-capability": "switching-otn", 1672 "encoding": "lsp-encoding-oduk" 1673 } 1674 ] 1676 } 1677 }, 1678 { 1679 "tp-id": "8-0-8", 1680 "te-tp-id": 80008, 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": "8-8-0", 1692 "te-tp-id": 80800, 1693 "te": { 1694 "interface-switching-capability": [ 1695 { 1696 "switching-capability": "switching-otn", 1697 "encoding": "lsp-encoding-oduk" 1698 } 1699 ] 1700 } 1701 } 1702 ] 1703 } 1704 ] 1705 }, 1706 { 1707 "network-types": { 1708 "te-topology": {} 1709 }, 1710 "network-id": "abstract2", 1711 "provider-id": 201, 1712 "client-id": 600, 1713 "te-topology-id": "te-topology:abstract2", 1714 "node": [ 1715 { 1716 "node-id": "D2", 1717 "te-node-id": "2.0.1.2", 1718 "te": { 1719 "te-node-attributes": { 1720 "domain-id" : 1, 1721 "is-abstract": [null], 1722 "connectivity-matrices": { 1723 "is-allowed": true, 1724 "underlay": { 1725 "enabled": true 1726 }, 1727 "path-constraints": { 1728 "bandwidth-generic": { 1729 "te-bandwidth": { 1730 "generic": [ 1731 { 1732 "generic": "0x1p10" 1733 } 1734 ] 1735 } 1736 } 1737 }, 1738 "optimizations": { 1739 "objective-function": { 1740 "objective-function-type": 1741 "of-maximize-residual-bandwidth" 1742 } 1743 }, 1744 "connectivity-matrix": [ 1745 { 1746 "id": 105, 1747 "from": "1-0-1", 1748 "to": "5-5-0", 1749 "underlay": { 1750 "enabled": true, 1751 "primary-path": { 1752 "network-ref": "absolute", 1753 "path-element": [ 1754 { 1756 "path-element-id": 1, 1757 "index": 1, 1758 "numbered-hop": { 1759 "address": "4.4.4.4", 1760 "hop-type": "STRICT" 1761 } 1762 }, 1763 { 1764 "path-element-id": 2, 1765 "index": 2, 1766 "numbered-hop": { 1767 "address": "7.7.7.7", 1768 "hop-type": "STRICT" 1769 } 1770 } 1771 ] 1773 } 1774 } 1775 } 1776 ] 1777 } 1778 } 1779 }, 1780 "termination-point": [ 1781 { 1782 "tp-id": "1-0-1", 1783 "te-tp-id": 10001, 1784 "te": { 1785 "interface-switching-capability": [ 1786 { 1787 "switching-capability": "switching-otn", 1788 "encoding": "lsp-encoding-oduk" 1789 } 1790 ] 1791 } 1792 }, 1793 { 1794 "tp-id": "1-1-0", 1795 "te-tp-id": 10100, 1796 "te": { 1797 "interface-switching-capability": [ 1798 { 1799 "switching-capability": "switching-otn", 1800 "encoding": "lsp-encoding-oduk" 1801 } 1802 ] 1803 } 1804 }, 1805 { 1807 "tp-id": "2-0-2", 1808 "te-tp-id": 20002, 1809 "te": { 1810 "interface-switching-capability": [ 1811 { 1812 "switching-capability": "switching-otn", 1813 "encoding": "lsp-encoding-oduk" 1814 } 1815 ] 1816 } 1817 }, 1818 { 1819 "tp-id": "2-2-0", 1820 "te-tp-id": 20200, 1821 "te": { 1822 "interface-switching-capability": [ 1823 { 1824 "switching-capability": "switching-otn", 1825 "encoding": "lsp-encoding-oduk" 1826 } 1827 ] 1828 } 1829 }, 1830 { 1831 "tp-id": "3-0-3", 1832 "te-tp-id": 30003, 1833 "te": { 1834 "interface-switching-capability": [ 1835 { 1836 "switching-capability": "switching-otn", 1837 "encoding": "lsp-encoding-oduk" 1838 } 1839 ] 1840 } 1841 }, 1842 { 1843 "tp-id": "3-3-0", 1844 "te-tp-id": 30300, 1845 "te": { 1846 "interface-switching-capability": [ 1847 { 1848 "switching-capability": "switching-otn", 1849 "encoding": "lsp-encoding-oduk" 1850 } 1851 ] 1852 } 1853 }, 1854 { 1855 "tp-id": "4-0-4", 1856 "te-tp-id": 40004, 1857 "te": { 1858 "interface-switching-capability": [ 1859 { 1860 "switching-capability": "switching-otn", 1861 "encoding": "lsp-encoding-oduk" 1862 } 1863 ] 1864 } 1865 }, 1866 { 1867 "tp-id": "4-4-0", 1868 "te-tp-id": 40400, 1869 "te": { 1870 "interface-switching-capability": [ 1871 { 1872 "switching-capability": "switching-otn", 1873 "encoding": "lsp-encoding-oduk" 1874 } 1875 ] 1876 } 1877 }, 1878 { 1879 "tp-id": "5-0-5", 1880 "te-tp-id": 50005, 1881 "te": { 1882 "interface-switching-capability": [ 1883 { 1884 "switching-capability": "switching-otn", 1885 "encoding": "lsp-encoding-oduk" 1886 } 1887 ] 1888 } 1889 }, 1890 { 1891 "tp-id": "5-5-0", 1892 "te-tp-id": 50500, 1893 "te": { 1894 "interface-switching-capability": [ 1895 { 1896 "switching-capability": "switching-otn", 1897 "encoding": "lsp-encoding-oduk" 1898 } 1899 ] 1900 } 1901 }, 1902 { 1903 "tp-id": "6-0-6", 1904 "te-tp-id": 60006, 1905 "te": { 1906 "interface-switching-capability": [ 1907 { 1908 "switching-capability": "switching-otn", 1909 "encoding": "lsp-encoding-oduk" 1910 } 1911 ] 1912 } 1913 }, 1914 { 1915 "tp-id": "6-6-0", 1916 "te-tp-id": 60600, 1917 "te": { 1918 "interface-switching-capability": [ 1919 { 1920 "switching-capability": "switching-otn", 1921 "encoding": "lsp-encoding-oduk" 1922 } 1923 ] 1924 } 1925 }, 1926 { 1927 "tp-id": "7-0-7", 1928 "te-tp-id": 70007, 1929 "te": { 1930 "interface-switching-capability": [ 1931 { 1932 "switching-capability": "switching-otn", 1933 "encoding": "lsp-encoding-oduk" 1934 } 1935 ] 1936 } 1937 }, 1938 { 1939 "tp-id": "7-7-0", 1940 "te-tp-id": 70700, 1941 "te": { 1942 "interface-switching-capability": [ 1943 { 1944 "switching-capability": "switching-otn", 1945 "encoding": "lsp-encoding-oduk" 1946 } 1947 ] 1948 } 1949 }, 1950 { 1951 "tp-id": "8-0-8", 1952 "te-tp-id": 80008, 1953 "te": { 1955 "interface-switching-capability": [ 1956 { 1957 "switching-capability": "switching-otn", 1958 "encoding": "lsp-encoding-oduk" 1959 } 1960 ] 1961 } 1962 }, 1963 { 1964 "tp-id": "8-8-0", 1965 "te-tp-id": 80800, 1966 "te": { 1967 "interface-switching-capability": [ 1968 { 1969 "switching-capability": "switching-otn", 1970 "encoding": "lsp-encoding-oduk" 1971 } 1972 ] 1973 } 1974 } 1975 ] 1976 } 1977 ] 1978 }, 1979 { 1980 "network-types": { 1981 "te-topology": {} 1982 }, 1983 "network-id": "abstract3", 1984 "provider-id": 201, 1985 "client-id": 600, 1986 "te-topology-id": "te-topology:abstract3", 1987 "node": [ 1988 { 1989 "node-id": "D3", 1990 "te-node-id": "3.0.1.1", 1991 "te": { 1992 "te-node-attributes": { 1993 "domain-id" : 3, 1994 "is-abstract": [null], 1995 "connectivity-matrices": { 1996 "is-allowed": true, 1997 "path-constraints": { 1998 "bandwidth-generic": { 1999 "te-bandwidth": { 2000 "generic": [ 2001 { 2002 "generic": "0x1p10", 2003 } 2005 ] 2006 } 2007 } 2008 }, 2009 "connectivity-matrix": [ 2010 { 2011 "id": 107, 2012 "from": "1-0-1", 2013 "to": "7-7-0" 2014 }, 2015 { 2016 "id": 308, 2017 "from": "3-0-3", 2018 "to": "8-8-0" 2019 }, 2020 ] 2021 } 2022 } 2023 }, 2024 "termination-point": [ 2025 { 2026 "tp-id": "1-0-1", 2027 "te-tp-id": 10001, 2028 "te": { 2029 "interface-switching-capability": [ 2030 { 2031 "switching-capability": "switching-otn", 2032 "encoding": "lsp-encoding-oduk" 2033 } 2034 ] 2035 } 2036 }, 2037 { 2038 "tp-id": "1-1-0", 2039 "te-tp-id": 10100, 2040 "te": { 2041 "interface-switching-capability": [ 2042 { 2043 "switching-capability": "switching-otn", 2044 "encoding": "lsp-encoding-oduk" 2045 } 2046 ] 2047 } 2048 }, 2049 { 2050 "tp-id": "2-0-2", 2051 "te-tp-id": 20002, 2052 "te": { 2053 "interface-switching-capability": [ 2054 { 2055 "switching-capability": "switching-otn", 2056 "encoding": "lsp-encoding-oduk" 2057 } 2058 ] 2059 } 2060 }, 2061 { 2062 "tp-id": "2-2-0", 2063 "te-tp-id": 20200, 2064 "te": { 2065 "interface-switching-capability": [ 2066 { 2067 "switching-capability": "switching-otn", 2068 "encoding": "lsp-encoding-oduk" 2069 } 2070 ] 2071 } 2072 }, 2073 { 2074 "tp-id": "3-0-3", 2075 "te-tp-id": 30003, 2076 "te": { 2077 "interface-switching-capability": [ 2078 { 2079 "switching-capability": "switching-otn", 2080 "encoding": "lsp-encoding-oduk" 2081 } 2082 ] 2083 } 2084 }, 2085 { 2086 "tp-id": "3-3-0", 2087 "te-tp-id": 30300, 2088 "te": { 2089 "interface-switching-capability": [ 2090 { 2091 "switching-capability": "switching-otn", 2092 "encoding": "lsp-encoding-oduk" 2093 } 2094 ] 2095 } 2096 }, 2097 { 2098 "tp-id": "4-0-4", 2099 "te-tp-id": 40004, 2100 "te": { 2101 "interface-switching-capability": [ 2102 { 2104 "switching-capability": "switching-otn", 2105 "encoding": "lsp-encoding-oduk" 2106 } 2107 ] 2108 } 2110 }, 2111 { 2112 "tp-id": "4-4-0", 2113 "te-tp-id": 40400, 2114 "te": { 2115 "interface-switching-capability": [ 2116 { 2117 "switching-capability": "switching-otn", 2118 "encoding": "lsp-encoding-oduk" 2119 } 2120 ] 2121 } 2122 }, 2123 { 2124 "tp-id": "5-0-5", 2125 "te-tp-id": 50005, 2126 "te": { 2127 "interface-switching-capability": [ 2128 { 2129 "switching-capability": "switching-otn", 2130 "encoding": "lsp-encoding-oduk" 2131 } 2132 ] 2133 } 2134 }, 2135 { 2136 "tp-id": "5-5-0", 2137 "te-tp-id": 50500, 2138 "te": { 2139 "interface-switching-capability": [ 2140 { 2141 "switching-capability": "switching-otn", 2142 "encoding": "lsp-encoding-oduk" 2143 } 2144 ] 2145 } 2146 }, 2147 { 2148 "tp-id": "6-0-6", 2149 "te-tp-id": 60006, 2150 "te": { 2151 "interface-switching-capability": [ 2152 { 2153 "switching-capability": "switching-otn", 2154 "encoding": "lsp-encoding-oduk" 2155 } 2156 ] 2157 } 2159 }, 2160 { 2161 "tp-id": "6-6-0", 2162 "te-tp-id": 60600, 2163 "te": { 2164 "interface-switching-capability": [ 2165 { 2166 "switching-capability": "switching-otn", 2167 "encoding": "lsp-encoding-oduk" 2168 } 2169 ] 2170 } 2171 }, 2172 { 2173 "tp-id": "7-0-7", 2174 "te-tp-id": 70007, 2175 "te": { 2176 "interface-switching-capability": [ 2177 { 2178 "switching-capability": "switching-otn", 2179 "encoding": "lsp-encoding-oduk" 2180 } 2181 ] 2182 } 2183 }, 2184 { 2185 "tp-id": "7-7-0", 2186 "te-tp-id": 70700, 2187 "te": { 2188 "interface-switching-capability": [ 2189 { 2190 "switching-capability": "switching-otn", 2191 "encoding": "lsp-encoding-oduk" 2192 } 2193 ] 2194 } 2195 }, 2196 { 2197 "tp-id": "8-0-8", 2198 "te-tp-id": 80008, 2199 "te": { 2200 "interface-switching-capability": [ 2201 { 2202 "switching-capability": "switching-otn", 2203 "encoding": "lsp-encoding-oduk" 2204 } 2205 ] 2206 } 2208 }, 2209 { 2210 "tp-id": "8-8-0", 2211 "te-tp-id": 80800, 2212 "te": { 2213 "interface-switching-capability": [ 2214 { 2215 "switching-capability": "switching-otn", 2216 "encoding": "lsp-encoding-oduk" 2217 } 2218 ] 2219 } 2220 } 2221 ] 2222 } 2223 ] 2224 }, 2225 ] 2226 } 2227 } 2229 8. Security Considerations 2231 The configuration, state, and action data defined in this document 2232 are designed to be accessed via a management protocol with a secure 2233 transport layer, such as NETCONF [RFC6241] or RESTCONF [RFC8040]. 2234 The lowest NETCONF layer is the secure transport layer, and the 2235 mandatory-to-implement secure transport is Secure Shell (SSH) 2236 [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory- 2237 to-implement secure transport is TLS [RFC8446]. 2239 The NETCONF access control model [RFC8341] provides the means to 2240 restrict access for particular NETCONF users to a preconfigured 2241 subset of all available NETCONF protocol operations and content. 2243 The model presented in this document is used in the interface between 2244 the Customer Network Controller (CNC) and Multi-Domain Service 2245 Coordinator (MDSC), which is referred to as CNC-MDSC Interface (CMI). 2246 Therefore, many security risks such as malicious attack and rogue 2247 elements attempting to connect to various ACTN components. 2248 Furthermore, some ACTN components (e.g., MSDC) represent a single 2249 point of failure and threat vector and must also manage policy 2250 conflicts and eavesdropping of communication between different ACTN 2251 components. 2253 A number of configuration data nodes defined in this document are 2254 writable/deletable (i.e., "config true") These data nodes may be 2255 considered sensitive or vulnerable in some network environments. 2257 These are the subtrees and data nodes and their sensitivity/ 2258 vulnerability: 2260 o access-point-list: 2262 * access-point-id 2264 * max-bandwidth 2266 * avl-bandwidth 2268 o vn-ap: 2270 * vn-ap-id 2272 * vn 2274 * abstract-node 2276 * ltp 2278 o vn-list 2280 * vn-id 2282 * vn-topology-id 2284 * abstract-node 2286 o vn-member-id 2288 * src 2290 * src-vn-ap-id 2292 * dest 2294 * dest-vn-ap-id 2296 * connectivity-matrix-id 2298 9. IANA Considerations 2300 This document registers the following namespace URIs in the IETF XML 2301 registry [RFC3688]: 2303 -------------------------------------------------------------------- 2304 URI: urn:ietf:params:xml:ns:yang:ietf-vn 2305 Registrant Contact: The IESG. 2306 XML: N/A, the requested URI is an XML namespace. 2307 -------------------------------------------------------------------- 2309 This document registers the following YANG modules in the YANG Module 2310 Names registry [RFC6020]: 2312 -------------------------------------------------------------------- 2313 name: ietf-vn 2314 namespace: urn:ietf:params:xml:ns:yang:ietf-vn 2315 prefix: vn 2316 reference: RFC XXXX (TDB) 2317 -------------------------------------------------------------------- 2319 10. Acknowledgments 2321 The authors would like to thank Xufeng Liu and Adrian Farrel for 2322 their helpful comments and valuable suggestions. 2324 11. References 2326 11.1. Normative References 2328 [I-D.ietf-teas-yang-te] 2329 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 2330 "A YANG Data Model for Traffic Engineering Tunnels and 2331 Interfaces", draft-ietf-teas-yang-te-21 (work in 2332 progress), April 2019. 2334 [I-D.ietf-teas-yang-te-topo] 2335 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 2336 O. Dios, "YANG Data Model for Traffic Engineering (TE) 2337 Topologies", draft-ietf-teas-yang-te-topo-22 (work in 2338 progress), June 2019. 2340 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2341 DOI 10.17487/RFC3688, January 2004, 2342 . 2344 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2345 the Network Configuration Protocol (NETCONF)", RFC 6020, 2346 DOI 10.17487/RFC6020, October 2010, 2347 . 2349 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2350 and A. Bierman, Ed., "Network Configuration Protocol 2351 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2352 . 2354 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2355 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 2356 . 2358 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2359 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2360 . 2362 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 2363 Access Control Model", STD 91, RFC 8341, 2364 DOI 10.17487/RFC8341, March 2018, 2365 . 2367 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 2368 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 2369 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2370 2018, . 2372 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2373 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2374 . 2376 11.2. Informative References 2378 [I-D.ietf-ccamp-l1csm-yang] 2379 Lee, Y., Lee, K., Zheng, H., Dhody, D., Dios, O., and D. 2380 Ceccarelli, "A YANG Data Model for L1 Connectivity Service 2381 Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-10 (work in 2382 progress), September 2019. 2384 [I-D.ietf-teas-actn-pm-telemetry-autonomics] 2385 Lee, Y., Dhody, D., Karunanithi, S., Vilata, R., King, D., 2386 and D. Ceccarelli, "YANG models for VN/TE Performance 2387 Monitoring Telemetry and Scaling Intent Autonomics", 2388 draft-ietf-teas-actn-pm-telemetry-autonomics-01 (work in 2389 progress), October 2019. 2391 [I-D.ietf-teas-te-service-mapping-yang] 2392 Lee, Y., Dhody, D., Fioccola, G., WU, Q., Ceccarelli, D., 2393 and J. Tantsura, "Traffic Engineering (TE) and Service 2394 Mapping Yang Model", draft-ietf-teas-te-service-mapping- 2395 yang-02 (work in progress), September 2019. 2397 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 2398 Ceccarelli, D., and X. Zhang, "Problem Statement and 2399 Architecture for Information Exchange between 2400 Interconnected Traffic-Engineered Networks", BCP 206, 2401 RFC 7926, DOI 10.17487/RFC7926, July 2016, 2402 . 2404 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 2405 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 2406 DOI 10.17487/RFC8299, January 2018, 2407 . 2409 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 2410 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 2411 . 2413 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2414 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2415 . 2417 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2418 and R. Wilton, "Network Management Datastore Architecture 2419 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 2420 . 2422 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 2423 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 2424 DOI 10.17487/RFC8453, August 2018, 2425 . 2427 [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. 2428 Yoon, "Information Model for Abstraction and Control of TE 2429 Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, 2430 September 2018, . 2432 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 2433 Data Model for Layer 2 Virtual Private Network (L2VPN) 2434 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2435 2018, . 2437 Appendix A. Contributors Addresses 2438 Qin Wu 2439 Huawei Technologies 2440 Email: bill.wu@huawei.com 2442 Peter Park 2443 KT 2444 Email: peter.park@kt.com 2446 Haomian Zheng 2447 Huawei Technologies 2448 Email: zhenghaomian@huawei.com 2450 Xian Zhang 2451 Huawei Technologies 2452 Email: zhang.xian@huawei.com 2454 Sergio Belotti 2455 Nokia 2456 Email: sergio.belotti@nokia.com 2458 Takuya Miyasaka 2459 KDDI 2460 Email: ta-miyasaka@kddi.com 2462 Authors' Addresses 2464 Young Lee (editor) 2465 SKKU 2467 Email: younglee.tx@gmail.com 2469 Dhruv Dhody (editor) 2470 Huawei Technologies 2471 Divyashree Techno Park, Whitefield 2472 Bangalore, Karnataka 560066 2473 India 2475 Email: dhruv.ietf@gmail.com 2477 Daniele Ceccarelli 2478 Ericsson 2479 Torshamnsgatan,48 2480 Stockholm, Sweden 2482 Email: daniele.ceccarelli@ericsson.com 2483 Igor Bryskin 2484 Futurewei 2486 Email: i_bryskin@yahoo.com 2488 Bin Yeong Yoon 2489 ETRI 2491 Email: byyun@etri.re.kr