idnits 2.17.1 draft-lee-teas-actn-vn-yang-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 31 instances of too long lines in the document, the longest one being 11 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 337 has weird spacing: '...mber-id uin...' == Line 344 has weird spacing: '...ment-id uin...' == Line 458 has weird spacing: '...n-ap-id uin...' == Line 467 has weird spacing: '...mber-id uin...' == Line 480 has weird spacing: '...ment-id uin...' == (9 more instances...) -- The document date (July 3, 2017) is 2488 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: 'Service-YANG' is mentioned on line 91, but not defined == Missing Reference: 'ACTN-INFO' is mentioned on line 355, but not defined == Missing Reference: 'NMDA' is mentioned on line 125, but not defined == Missing Reference: 'ACTN-Frame' is mentioned on line 130, but not defined == Missing Reference: 'ACTN-FW' is mentioned on line 229, but not defined == Missing Reference: 'TE-Tunnel' is mentioned on line 278, but not defined == Unused Reference: 'TE-tunnel' is defined on line 1169, but no explicit reference was found in the text == Unused Reference: 'ACTN-REQ' is defined on line 1179, but no explicit reference was found in the text == Unused Reference: 'ACTN-FWK' is defined on line 1183, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 16 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS Working Group Y. Lee (Editor) 2 Internet Draft Dhruv Dhody 3 Intended Status: Standard Track Huawei 4 D. Ceccarelli 5 Ericsson 6 Takuya Miyasaka 7 KDDI 8 Peter Park 9 KT 10 Bin Yeung Yoon 11 ETRI 13 Expires: January 3, 2018 July 3, 2017 15 A Yang Data Model for ACTN VN Operation 17 draft-lee-teas-actn-vn-yang-05 19 Abstract 21 This document provides a YANG data model for the Abstraction and 22 Control of Traffic Engineered (TE) networks (ACTN) Virtual Network 23 (VN) operation. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with 28 the provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six 36 months and may be updated, replaced, or obsoleted by other documents 37 at any time. It is inappropriate to use Internet-Drafts as 38 reference material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 This Internet-Draft will expire on January 3, 2018. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with 58 respect to this document. Code Components extracted from this 59 document must include Simplified BSD License text as described in 60 Section 4.e of the Trust Legal Provisions and are provided without 61 warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction...................................................2 66 1.1. Terminology...............................................3 67 2. ACTN CMI context...............................................3 68 2.1. Type 1 VNS................................................5 69 2.2. Type 2 VNS................................................7 70 2.3. Justification of the ACTN VN Model on the CMI.............9 71 3. ACTN VN YANG Model (Tree Structure)...........................11 72 4. ACTN-VN YANG Code.............................................14 73 5. Security Considerations.......................................26 74 6. IANA Considerations...........................................26 75 7. Acknowledgments...............................................26 76 8. References....................................................27 77 8.1. Normative References.....................................27 78 8.2. Informative References...................................27 79 9. Contributors..................................................27 80 Authors' Addresses...............................................28 82 1. Introduction 84 This document provides a YANG data model for the Abstraction and 85 Control of Traffic Engineered (TE) networks (ACTN) Virtual Network 86 (VN) operation that is going to be implemented for the Customer 87 Network Controller (CNC)- Multi-Domain Service Coordinator (MSDC) 88 interface (CMI). 90 The YANG model on the CMI is also known as customer service model in 91 [Service-YANG]. The YANG model discussed in this document is used to 92 operate customer-driven VNs during the VN computation, VN 93 instantiation and its life-cycle management and operations. 95 Note that the YANG model presented in this draft has two aspects: 97 - VN pre-instantiation mode of operation (also known as VN compute); 98 - VN instantiation mode of operation. 100 The VN pre-instantiation mode of operation is concerned about 101 service inquiry before making a formal request for VN instantiation. 102 This operation is important for a customer to make sure the network 103 can provide VN services it desires. 105 The VN instantiation mode of operation is concerned about 106 instantiating VNs. In the VN instantiation mode, the CNC provides 107 the VN service definition that includes VN members, VN service 108 objective, VN service policy and preferences, etc. Upon receipt of a 109 VN instantiation request, the MDSC (in coordination with PNCs) 110 executes service request into network operation that include 111 creating tunnels/paths and securing network resources/slices for 112 VNs. 114 The YANG model discussed in this document basically provides the 115 characteristics of VNs such as VN level parameters (e.g., VN ID, VN 116 member, VN objective function, VN service preference, etc.), 117 customer's end point characteristics (e.g., Customer Interface 118 Capability, Access Points Interface characteristics, etc.), and 119 other relevant VN information that needs to be known to the MDSC to 120 facilitate ACTN VN operation. This is as per the ACTN Information 121 Model described in [ACTN-INFO]. 123 The ACTN VN operational state is included in the same tree as the 124 configuration consistent with Network Management Datastore 125 Architecture (NMDA) [NMDA]. The origin of the data is indicated as 126 per the origin metadata annotation. 128 1.1. Terminology 130 Refer to [ACTN-Frame] and [RFC7926] for the key terms used in this 131 document. 133 2. ACTN CMI context 135 The model presented in this document has the following ACTN context. 137 +-------+ 138 | CNC | 139 +-------+ 140 | 141 | <--- CMI (CNC-MDSC Interface) 142 | 143 +-----------------------+ 144 | MDSC | 145 +-----------------------+ 147 Figure 1. ACTN CMI 149 As defined in [ACTN-FW], a Virtual Network is a customer view of the 150 TE network. It further defines various VN operations and VN types 151 as follows: 153 o VN Type: 155 a. The VN can be seen as set of end-to-end tunnels from a 156 customer point of view, where each tunnel is referred as a 157 VN member. Each VN member can then be formed by recursive 158 slicing or abstraction of paths in underlying networks. 159 Such end-to-end tunnels may comprise of customer end 160 points, access links, intra-domain paths, and inter-domain 161 links. In this view, VN is thus a set of VN members (which 162 is referred to as Type 1 VN) 164 b. The VN can also be seen as a topology comprising of 165 physical, sliced, and abstract nodes and links. This VN is 166 referred to as Type 2 VN. The nodes in this case include 167 physical customer end points, border nodes, and internal 168 nodes as well as abstracted nodes. Similarly the links 169 include physical access links, inter-domain links, and 170 intra-domain links as well as abstract links. With VN type 171 2, it is still possible to view VN member-level. 173 It further defines a Virtual Network Service (VNS) as follows: 175 o VNS is requested by the customer and negotiated with the 176 provider. There are three types of VNS defined in this 177 document. Type 1 VNS refers to VNS in which customer is allowed 178 to create and operate a Type 1 VN. Type 2a and 2b VNS refers to 179 the VNS in which customer is allowed to create and operates a 180 Type 2 VN. With Type 2a VNS, once the VN is statically created 181 at service configuration time, the customer is not allowed to 182 change the topology (i.e., adding or deleting abstract 183 nodes/links). Type 2b VNS is the same as Type 2a VNS except 184 that the customer is allowed to change topology dynamically 185 from the initial topology created at service configuration 186 time. 188 For both cases, the CNC can dynamically add VN elements. For case 1, 189 the VN element is an end-to-end tunnel and for case 2, the VN 190 element can be virtual nodes or virtual links. 192 2.1. Type 1 VNS 194 This section considers a Type 1 VNS, where the customer provides its 195 VN requirements in terms of VN members and VNAP. 197 The following figure describes a VN that comprises three VN members 198 forming a full mesh for the VN as an illustration. 200 VN Member 1 201 |<-------------------------------------->| 202 | | 203 | ------------- | 204 | ( ) | 205 | - - | 206 +---+ X ( Provider ) Z +---+ 207 |CE1|---+----( )---+---|CE2| 208 +---+ AP1 ( Network ) AP2 +---+ 209 .- - - _ -. 210 |\ ( ) /| 211 \ ------------- / 212 \ | / 213 ---- + AP3 ---- 214 VN Member 2 \ | / VN Member 3 215 \ Y | / 216 \ +---+ / 217 `----> |CE3|<----` 218 +---+ 220 Figure 2. Full Mesh Example for a VN 222 In Figure 2, a VN has three members, namely, VN Member 1, VN member 223 2, and VN member 3. VN Member 1 is an end-to-end tunnel identified 224 by CE1-AP1 (source) and CE2-AP2 (destination). Similarly, VN Member 225 2 by CE1-AP1 and CE3-AP3 and VN Member 3 by CE3-AP3 and CE2-AP2. 226 This particular VN shown in Figure 2 is a full mesh connectivity 227 across these three customer end-points. 229 [ACTN-FW] define the Access Point (AP) as a logical identifier to 230 identify the access link between customer and provider, and VN 231 Access Point (VNAP) is defined as a binding between AP and VN. 233 The set of assumptions that applies to this document is the 234 following: 236 - CNC is responsible for providing necessary Customer End-Points 237 information to the MDSC via the CMI. 238 - The access links (between Customer Edge (CE) Devices and the 239 Provider Edge (PE) Devices) are assumed to have been 240 provisioned prior to the VN instantiation request. 241 Access point identifiers have been configured and therefore are 242 known in both the CNC and the MDSC. This YANG model maintains 243 the list of AP and VNAP. 245 It is also possible for the customer to create a VN which can be a 246 hub and spoke or any other form of connectivity depending on its 247 connectivity requirement. Each VN-member may be unidirectional or 248 bidirectional which is also depending on its connectivity 249 requirements. The following figure shows some examples of a VN that 250 can be represented in a different connectivity form depending on the 251 customer's connectivity requirements. 253 +---+ +---+ +---+ +---+ +---+ +---+ 254 |CE1|---------|CE2| |CE4|---------|CE5| |CE8|---------|CE9| 255 +---+ +---+ +---+ +---+ +---+ +---+ 256 \ / | \ | \ | 257 \ / | \ | \ | 258 \ / | \ | \ | 259 \ / | \ | \ | 260 \ / | \ | \ | 261 \ / | \ | \ | 262 +---+ +---+ +---+ +---+ +---+ 263 |CE3| |CE6| |CE7| |CE6|---------|CE7| 264 +---+ +---+ +---+ +---+ +---+ 266 (a) Full Mesh (b) Hub and Spoke (c) partial Mesh 268 Figure 3. Different Connectivity Forms of a VN 270 It is important to note that a VN can associate a multiple number of 271 end-to-end tunnels (i.e., VN members) with one unique identifier 272 under the VN umbrella. From a customer standpoint, this simplifies 273 its VN operation significantly. 275 The MDSC interacts with the CNC for the VN operation. Once the 276 customer VN is requested by the CNC to the MDSC, the MDSC shall be 277 responsible for translating and mapping the VN request into specific 278 network centric-models (e.g., TE-tunnels [TE-Tunnel], TE-topology 279 [TE-TOPO], etc.) to coordinate the multi-domain network operations 280 with PNCs. 282 2.2. Type 2 VNS 284 A type 2 VNS would allow the customer to also configure and learn a 285 VN abstract topology (Type 2 VN) via the TE topology yang model [TE- 286 TOPO]. A reference to the abstract topology is maintain in the VN 287 Yang model. Any change in topology (Type 2b VN) would be made via 288 [TE-TOPO]. Further, the ACTN VN Yang model is used for Type 2 VNS in 289 exactly the same way by configuring the VN members and corresponding 290 VNAP as described in section 2.1. 292 Using the path in VN-member in the ACTN VN yang model, CNC can also 293 set a path based on the abstract topology in [TE-TOPO]. Figure 4 294 shows an example VN abstract topology with six virtual nodes and six 295 virtual links configured and learned from via [TE-TOPO]. For each VN 296 member, the customer configures the path over the VN abstract 297 topology. For instance, for VN-member 1 (that connects CE1 to CE2), 298 the customer may choose a path comprising VL12 or alternatively a 299 path comprising of VL13-VL36-VL26 depending on the virtual link 300 state of the topology. If VN-member 1 needs to configure a link- 301 diversity path from VN-member 2 (CE1-CE3), then VN-member 1 should 302 configure a path comprising VL12 while VN-member 2 should configure 303 a path comprising VL13-VL34 to avoid the links that overlap. 305 |<----------------VN-member 1---------------->| 307 +------+ VL12 +------+ 308 --- CE1------|VNode1|----------------|VNode2|------CE2 --- 309 /|\ +------+ +------+ /|\ 310 | \ / | 311 | VL13 \ / VL26 | 312 | +------+ VL36 +------+ | 313 VN-member 2 |VNode3|--------|VNode6| | 314 | +------+ +------+ | 315 | VL34 / \ VL56 | 316 | / \ | 317 \|/ +------+ +------+ . 318 --- CE3------|VNode4| --------------|VNode5| / 319 +------+ VL45 +------+ / 320 / 321 / 322 <------------------VN-member 3-----------------' 324 Figure 4. Type 2 VNS with VN abstract topology 326 The following YANG tree segment shows how YANG is modeled to support 327 Type VNS where for each VN-member how a path can be configured. 329 +--rw vn 330 +--rw vn-list* [vn-id] 331 +--rw vn-id uint32 332 +--rw vn-name? string 333 +--rw vn-topology-ref {type-2}? 334 | +--rw network-ref? 335 | -> /nw:networks/network/network-id 336 +--rw vn-member-list* [vn-member-id] 337 | +--rw vn-member-id uint32 338 | +--rw src 339 . . . 340 | +--rw dest 341 . . . 342 | +--rw path {type-2}? 343 | | +--rw path-element* [path-element-id] 344 | | +--rw path-element-id uint32 345 | | +--rw index? uint32 346 | | +--rw address? te-types:te-tp-id 347 | | +--rw hop-type? te-types:te-hop-type 349 2.3. Justification of the ACTN VN Model on the CMI. 351 2.3.1 Customer view of VN 353 The VN-Yang model allows to define a customer view, and allows the 354 customer to communicate using the VN constructs as described in the 355 [ACTN-INFO]. It also allows to group the set of E2E tunnels (i.e VN 356 members) under a common umbrella of VN. This allows the customer to 357 instantiate and view the VN as one entity, making it easier for some 358 customers to work on VN without worrying about the details of the 359 provider based YANG models. 361 Further, there are certain advantages to maintain a set of E2E 362 Tunnels as one VN unit for applying policy, reroute, protection, 363 restoration, etc., rather than treating each TE-tunnel as individual 364 unit. This allows customer to set one VN to be disjoint to another 365 as a whole, allows the optimization functions to be applied to the 366 VN rather than to an individual tunnels. 368 This is similar to the benefits of having a separate YANG model for 369 the customer services as described in [SERVICE-YANG], which states 370 that service models do not make any assumption of how a service is 371 actually engineered and delivered for a customer; details of how 372 network protocols and devices are engineered to deliver a service 373 are captured in other models that are not exposed through the 374 Customer-Provider Interface. Ability to hide the complexity of the 375 TE topology and TE tunnel YANG from some customers would be 376 beneficial. 378 2.3.2 Innovative Services 380 2.3.2.1 VN Compute 382 ACTN VN supports VN compute (pre-instantiation mode) to view the 383 full VN as a single entity before instantiation. Achieving this via 384 path computation or "compute only" tunnel setup does not provide the 385 same functionality. 387 2.3.2.2 Multi-sources and Multi-destinations 388 In creating a virtual network, the list of sources or destinations 389 or both may not be pre-determined by the customer. For instance, for 390 a given source, there may be a list of multiple-destinations to 391 which the optimal destination may be chosen depending on the network 392 resource situations. Likewise, for a given destination, there may 393 also be multiple-sources from which the optimal source may be 394 chosen. In some cases, there may be a pool of multiple sources and 395 destinations from which the optimal source-destination may be 396 chosen. The following YANG module is shown for describing source 397 container and destination container. The following YANG tree shows 398 how to model multi-sources and multi-destinations. 400 +--rw actn 401 | +--rw vn 402 | +--rw vn-list* [vn-id] 403 | ... 404 | | +--rw src 405 | | | +--rw src? leafref 406 | | | +--rw src-vn-ap-id? uint32 407 | | | +--rw multi-src? boolean 408 | | +--rw dest 409 | | +--rw dest? leafref 410 | | +--rw dest-vn-ap-id? uint32 411 | | +--rw multi-dest? boolean 413 2.3.2.3 Others 415 The VN Yang model can be easily augmented to support the mapping of 416 VN to the Services such as L3SM and L2SM as described in [TE-MAP]. 418 The VN Yang model can be extended to support telemetry, performance 419 monitoring and network autonomics as described in [ACTN-PM]. 421 2.3.3 Summary 423 This section summarizes the innovative service features of the ACTN 424 VN Yang. 426 o Maintenance of AP and VNAP along with VN. 428 o VN construct to group E2E tunnels 430 o VN Compute (pre-instantiate) 432 o Multi-Source / Multi-Destination 434 o Ability to support various VN and VNS Types 436 * VN Type 1: Customer configures the VN as a set of VN 437 Members. 438 No other details need to be set by customer, making for a 439 simplified operations for the customer. 441 * VN Type 2: Along with VN Members, the customer could also 442 provide an abstract topology, this topology is provided by 443 the Abstract TE Topology Yang Model. 445 3. ACTN VN YANG Model (Tree Structure) 447 module: ietf-actn-vn 448 +--rw actn 449 +--rw ap 450 | +--rw access-point-list* [access-point-id] 451 | +--rw access-point-id uint32 452 | +--rw access-point-name? string 453 | +--rw src-tp-id? binary 454 | +--rw dst-tp-id? binary 455 | +--rw max-bandwidth? te-types:te-bandwidth 456 | +--rw avl-bandwidth? te-types:te-bandwidth 457 | +--rw vn-ap* [vn-ap-id] 458 | +--rw vn-ap-id uint32 459 | +--rw vn? -> /actn/vn/vn-list/vn-id 460 +--rw vn 461 +--rw vn-list* [vn-id] 462 +--rw vn-id uint32 463 +--rw vn-name? string 464 +--rw vn-topology-id? te-types:te-topology-id 465 | {type-2}? 466 +--rw vn-member-list* [vn-member-id] 467 | +--rw vn-member-id uint32 468 | +--rw src 469 | | +--rw src? leafref 470 | | +--rw src-vn-ap-id? leafref 471 | | +--rw multi-src? boolean 472 | | {multi-src-dest}? 473 | +--rw dest 474 | | +--rw dest? leafref 475 | | +--rw dest-vn-ap-id? leafref 476 | | +--rw multi-dest? boolean 477 | | {multi-src-dest}? 478 | +--rw path {type-2}? 479 | | +--rw path-element* [path-element-id] 480 | | +--rw path-element-id uint32 481 | | +--rw index? uint32 482 | | +--rw address? te-types:te-tp-id 483 | | +--rw hop-type? te-types:te-hop-type 484 | +--ro metric* [metric-type] 485 | | +--ro metric-type identityref 486 | | +--ro value? uint32 487 | +--ro oper-status? identityref 488 | +--ro tunnel-ref? te:tunnel-ref 489 +--ro multi-src-dest {multi-src-dest}? 490 | +--ro selected-vn-member? leafref 491 +--rw objective-function? pcep:objective-function 492 +--rw metric* [metric-type] 493 | +--rw metric-type identityref 494 | +--rw limit 495 | | +--rw enabled? boolean 496 | | +--rw value? uint32 497 | +--rw optimize 498 | +--rw enabled? boolean 499 | +--rw value? uint32 500 +--rw bandwidth? te-types:te-bandwidth 501 +--rw protection? identityref 502 +--rw local-reroute? boolean 503 +--rw push-allowed? boolean 504 +--rw incremental-update? boolean 505 +--rw admin-status? identityref 506 +--ro oper-status? identityref 508 rpcs: 509 +---x vn-compute 510 +---w input 511 | +---w vn-member-list* [vn-member-id] 512 | | +---w vn-member-id uint32 513 | | +---w src 514 | | | +---w src? leafref 515 | | | +---w src-vn-ap-id? leafref 516 | | | +---w multi-src? boolean {multi-src-dest}? 517 | | +---w dest 518 | | | +---w dest? leafref 519 | | | +---w dest-vn-ap-id? leafref 520 | | | +---w multi-dest? boolean 521 | | | {multi-src-dest}? 522 | | +---w path {type-2}? 523 | | +---w path-element* [path-element-id] 524 | | +---w path-element-id uint32 525 | | +---w index? uint32 526 | | +---w address? te-types:te-tp-id 527 | | +---w hop-type? te-types:te-hop-type 528 | +---w objective-function? pcep:objective-function 529 | +---w metric* [metric-type] 530 | | +---w metric-type identityref 531 | | +---w limit 532 | | | +---w enabled? boolean 533 | | | +---w value? uint32 534 | | +---w optimize 535 | | +---w enabled? boolean 536 | | +---w value? uint32 537 | +---w bandwidth? te-types:te-bandwidth 538 | +---w protection? identityref 539 | +---w local-reroute? boolean 540 | +---w push-allowed? boolean 541 | +---w incremental-update? boolean 542 +--ro output 543 +--ro vn-member-list* [vn-member-id] 544 | +--ro vn-member-id uint32 545 | +--ro src 546 | | +--ro src? leafref 547 | | +--ro src-vn-ap-id? leafref 548 | | +--ro multi-src? boolean {multi-src-dest}? 549 | +--ro dest 550 | | +--ro dest? leafref 551 | | +--ro dest-vn-ap-id? leafref 552 | | +--ro multi-dest? boolean 553 | | {multi-src-dest}? 554 | +--ro path {type-2}? 555 | | +--ro path-element* [path-element-id] 556 | | +--ro path-element-id uint32 557 | | +--ro index? uint32 558 | | +--ro address? te-types:te-tp-id 559 | | +--ro hop-type? te-types:te-hop-type 560 | +--ro metric* [metric-type] 561 | | +--ro metric-type identityref 562 | | +--ro value? uint32 563 | +--ro compute-status? identityref 564 +--ro multi-src-dest {multi-src-dest}? 565 +--ro selected-vn-member-id? uint32 567 4. ACTN-VN YANG Code 569 The YANG code is as follows: 571 file "ietf-actn-vn@2017-07-03.yang" 573 module ietf-actn-vn { 575 namespace "urn:ietf:params:xml:ns:yang:ietf-actn-vn"; 577 prefix "vn"; 579 /* Import TE generic types */ 580 import ietf-te-types { 581 prefix "te-types"; 582 } 584 import ietf-te { 585 prefix "te"; 586 } 588 import ietf-pcep { 589 prefix "pcep"; 590 } 592 organization 593 "IETF Traffic Engineering Architecture and Signaling (TEAS) 594 Working Group"; 596 contact 597 "Editor: Young Lee 598 : Dhruv Dhody "; 600 description 601 "This module contains a YANG module for the ACTN VN. It 602 describes a VN operation module that takes place in the 603 context of the CNC-MDSC Interface (CMI) of the ACTN 604 architecture where the CNC is the actor of a VN Instantiation 605 /modification /deletion."; 607 revision 2017-07-03 { 608 description 609 "initial version."; 610 reference 611 "TBD"; 612 } 614 /* 615 * Features 616 */ 618 feature multi-src-dest { 619 description 620 "Support for selection of one src or destination 621 among multiple."; 622 } 624 feature type-2 { 625 description 626 "Support for Type 2 VNS based on the abstract VN 627 Topology."; 628 } 630 identity path-metric-delay { 631 base te-types:path-metric-type; 632 description 633 "delay path metric"; 634 } 636 identity path-metric-delay-variation { 637 base te-types:path-metric-type; 638 description 639 "delay-variation path metric"; 640 } 642 identity path-metric-loss { 643 base te-types:path-metric-type; 644 description 645 "loss path metric"; 646 } 648 identity vn-state-type { 649 description 650 "Base identity for VN state"; 651 } 653 identity vn-state-up { 654 base vn-state-type; 655 description "VN state up"; 656 } 658 identity vn-state-down { 659 base vn-state-type; 660 description "VN state down"; 661 } 663 identity vn-admin-state-type { 664 description 665 "Base identity for VN admin states"; 666 } 668 identity vn-admin-state-up { 669 base vn-admin-state-type; 670 description "VN administratively state up"; 671 } 673 identity vn-admin-state-down { 674 base vn-admin-state-type; 675 description "VN administratively state down"; 676 } 678 identity vn-compute-state-type { 679 description 680 "Base identity for compute states"; 681 } 683 identity vn-compute-state-computing { 684 base vn-compute-state-type; 685 description 686 "State path compute in progress"; 687 } 689 identity vn-compute-state-computation-ok { 690 base vn-compute-state-type; 691 description 692 "State path compute successful"; 693 } 695 identity vn-compute-state-computatione-failed { 696 base vn-compute-state-type; 697 description 698 "State path compute failed"; 699 } 701 /* 702 * Groupings 703 */ 704 grouping vn-ap { 705 description 706 "VNAP related information"; 707 leaf vn-ap-id { 708 type uint32; 709 description 710 "unique identifier for the referred 711 VNAP"; 712 } 713 leaf vn { 714 type leafref { 715 path "/actn/vn/vn-list/vn-id"; 716 } 717 description 718 "reference to the VN"; 719 } 720 } 722 grouping access-point{ 723 description 724 "AP related information"; 725 leaf access-point-id { 726 type uint32; 727 description 728 "unique identifier for the referred 729 access point"; 730 } 731 leaf access-point-name { 732 type string; 733 description 734 "ap name"; 735 } 736 /*using direct tp-id for now as per ietf-te 737 should check if reference is better*/ 738 leaf src-tp-id { 739 type binary; 740 description 741 "TE tunnel source termination point identifier."; 742 } 743 leaf dst-tp-id { 744 type binary; 745 description 746 "TE tunnel destination termination point identifier."; 747 } 748 leaf max-bandwidth { 749 type te-types:te-bandwidth; 750 description 751 "max bandwidth of the AP"; 753 } 754 leaf avl-bandwidth { 755 type te-types:te-bandwidth; 756 description 757 "available bandwidth of the AP"; 758 } 759 /*add details and any other properties of AP, 760 not associated by a VN 761 CE port, PE port etc. 763 */ 765 list vn-ap { 766 key vn-ap-id; 767 uses vn-ap; 768 description 769 "list of VNAP in this AP"; 770 } 772 }//access-point 774 grouping vn-member { 775 description 776 "vn-member is described by this container"; 777 leaf vn-member-id { 778 type uint32; 779 description 780 "vn-member identifier"; 781 } 782 container src 783 { 784 description 785 "the source of VN Member"; 786 leaf src { 787 type leafref { 788 path "/actn/ap/access-point-list/access-point-id"; 789 } 790 description 791 "reference to source AP"; 792 } 793 leaf src-vn-ap-id{ 794 type leafref { 795 path "/actn/ap/access-point-list/vn-ap/vn-ap-id"; 796 } 797 description 798 "reference to source VNAP"; 799 } 800 leaf multi-src { 801 if-feature multi-src-dest; 802 type boolean; 803 description 804 "Is source part of multi-source, where 805 only one of the source is enabled"; 806 } 807 } 808 container dest 809 { 810 description 811 "the destination of VN Member"; 812 leaf dest { 813 type leafref { 814 path "/actn/ap/access-point-list/access-point-id"; 815 } 816 description 817 "reference to destination AP"; 818 } 819 leaf dest-vn-ap-id{ 820 type leafref { 821 path "/actn/ap/access-point-list/vn-ap/vn-ap-id"; 822 } 823 description 824 "reference to dest VNAP"; 825 } 826 leaf multi-dest { 827 if-feature multi-src-dest; 828 type boolean; 829 description 830 "Is destination part of multi-destination, where 831 only one of the destination is enabled"; 832 } 833 } 834 container path 835 { 836 if-feature type-2; 837 description 838 "the path if set by the customer"; 839 list path-element { 840 key "path-element-id"; 841 description 842 "A list of path elements describing the service path."; 843 leaf path-element-id { 844 type uint32; 845 description "To identify the element in a path."; 846 } 847 leaf index { 848 type uint32; 849 description "ERO subobject index"; 850 } 851 leaf address { 852 type te-types:te-tp-id; 853 description 854 "Numbered link TE termination point address. 855 Should refer to the abstract TE topology 856 of this VN"; 857 } 858 leaf hop-type { 859 type te-types:te-hop-type; 860 description 861 "strict or loose hop"; 862 } 863 } 864 } 865 }//vn-member 867 grouping policy { 868 description 869 "policy related to vn-member-id"; 870 leaf local-reroute { 871 type boolean; 872 description 873 "Policy to state if reroute 874 can be done locally"; 875 } 876 leaf push-allowed { 877 type boolean; 878 description 879 "Policy to state if changes 880 can be pushed to the customer"; 881 } 882 leaf incremental-update { 883 type boolean; 884 description 885 "Policy to allow only the 886 changes to be reported"; 887 } 888 }//policy 890 grouping metrics-op { 891 description 892 "metric related information"; 893 list metric{ 894 key "metric-type"; 895 config false; 896 description 897 "The list of metrics for VN"; 898 leaf metric-type { 899 type identityref { 900 base te-types:path-metric-type; 901 } 902 description 903 "The VN metric type."; 904 } 905 leaf value{ 906 type uint32; 907 description 908 "The limit value"; 909 } 910 } 912 } 914 grouping metrics { 915 description 916 "metric related information"; 917 list metric{ 918 key "metric-type"; 919 description 920 "The list of metrics for VN"; 921 leaf metric-type { 922 type identityref { 923 base te-types:path-metric-type; 924 } 925 description 926 "The VN metric type."; 927 } 928 container limit { 929 description 930 "Limiting contraints"; 931 leaf enabled{ 932 type boolean; 933 description 934 "Limit contraint is enabled"; 935 } 936 leaf value{ 937 type uint32; 938 description 939 "The limit value"; 940 } 941 } 942 container optimize{ 943 description 944 "optimizing constraints"; 945 leaf enabled{ 946 type boolean; 947 description 948 "Metric to optimize"; 950 } 951 leaf value{ 952 type uint32; 953 description 954 "The computed value"; 955 } 956 } 957 } 959 } 961 grouping service-metric { 962 description 963 "service-metric"; 964 leaf objective-function { 965 type pcep:objective-function; 966 description 967 "operational state of the objective function"; 968 } 970 uses metrics; 972 leaf bandwidth { 973 type te-types:te-bandwidth; 974 description 975 "bandwidth requested/required for 976 vn-member-id"; 977 } 979 leaf protection { 980 type identityref { 981 base te-types:lsp-prot-type; 982 } 983 description "protection type."; 984 } 986 uses policy; 988 }//service-metric 990 /* 991 * Configuration data nodes 992 */ 993 container actn { 994 description 995 "actn is described by this container"; 996 container ap { 997 description 998 "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"; 1014 list vn-list { 1015 key "vn-id"; 1016 description 1017 "a virtual network is identified by a vn-id"; 1018 leaf vn-id { 1019 type uint32; 1020 description 1021 "a unique vn identifier"; 1022 } 1023 leaf vn-name { 1024 type string; 1025 description "vn name"; 1026 } 1027 leaf vn-topology-id{ 1028 if-feature type-2; 1029 type te-types:te-topology-id; 1030 description 1031 "An optional identifier to the TE Topology 1032 Model where the abstract nodes and links 1033 of the Topology can be found for Type 2 1034 VNS"; 1036 } 1037 list vn-member-list{ 1038 key "vn-member-id"; 1039 description 1040 "List of VN-members in a VN"; 1041 uses vn-member; 1042 uses metrics-op; 1043 leaf oper-status { 1044 type identityref { 1045 base vn-state-type; 1046 } 1047 config false; 1048 description 1049 "VN-member operational state."; 1050 } 1051 leaf tunnel-ref { 1052 type te:tunnel-ref; 1053 config false; 1054 description 1055 "A reference to the TE tunnel 1056 in the TE model"; 1057 } 1058 } 1059 container multi-src-dest{ 1060 if-feature multi-src-dest; 1061 config false; 1062 description 1063 "The selected VN Member when multi-src 1064 and/or mult-destination is enabled."; 1065 leaf selected-vn-member{ 1066 type leafref { 1067 path "/actn/vn/vn-list/vn-member-list/vn-member-id"; 1068 } 1069 description 1070 "The selected VN Member along the set 1071 of source and destination configured 1072 with multi-source and/or multi-destination"; 1073 } 1074 } 1076 uses service-metric; 1078 leaf admin-status { 1079 type identityref { 1080 base vn-admin-state-type; 1081 } 1082 default vn-admin-state-up; 1083 description "VN administrative state."; 1084 } 1085 leaf oper-status { 1086 type identityref { 1087 base vn-state-type; 1088 } 1089 config false; 1090 description "VN operational state."; 1091 } 1093 }//vn-list 1094 }//vn 1095 }//actn 1096 /* 1097 * Notifications - TBD 1098 */ 1099 /* 1100 * RPC 1101 */ 1102 rpc vn-compute{ 1103 description 1104 "The VN computation without actual 1105 instantiation"; 1106 input { 1107 list vn-member-list{ 1108 key "vn-member-id"; 1109 description 1110 "List of VN-members in a VN"; 1111 uses vn-member; 1112 } 1113 uses service-metric; 1114 } 1115 output { 1116 list vn-member-list{ 1117 key "vn-member-id"; 1118 description 1119 "List of VN-members in a VN"; 1120 uses vn-member; 1121 uses metrics-op; 1122 leaf compute-status { 1123 type identityref { 1124 base vn-compute-state-type; 1125 } 1126 description 1127 "VN-member compute state."; 1128 } 1129 } 1130 container multi-src-dest{ 1131 if-feature multi-src-dest; 1132 description 1133 "The selected VN Member when multi-src 1134 and/or mult-destination is enabled."; 1135 leaf selected-vn-member-id{ 1136 type uint32; 1137 description 1138 "The selected VN Member-id from the 1139 input"; 1140 } 1141 } 1142 } 1143 } 1145 } 1147 1149 5. Security Considerations 1151 TDB 1153 6. IANA Considerations 1155 TDB 1157 7. Acknowledgments 1159 The authors would like to thank Igor Bryskin and Xufeng Liu for 1160 their helpful comments and valuable contributions. 1162 8. References 1164 8.1. Normative References 1166 [TE-TOPO] X. Liu, et al., "YANG Data Model for TE Topologies", work 1167 in progress: draft-ietf-teas-yang-te-topo. 1169 [TE-tunnel] T. Saad, et al., "A YANG Data Model for Traffic 1170 Engineering Tunnels and Interfaces", work in progress: 1171 draft-ietf-teas-yang-te. 1173 8.2. Informative References 1175 [RFC7926] A. Farrel (Ed.), "Problem Statement and Architecture for 1176 Information Exchange between Interconnected Traffic- 1177 Engineered Networks", RFC 7926, July 2016. 1179 [ACTN-REQ] Lee, et al., "Requirements for Abstraction and Control of 1180 TE Networks", draft-ietf-teas-actn-requirements, work in 1181 progress. 1183 [ACTN-FWK] D. Ceccarelli, Y. Lee [Editors], "Framework for 1184 Abstraction and Control of Traffic Engineered Networks", 1185 draft-ceccarelli-teas-actn-framework, work in progress. 1187 [TE-MAP] Y. Lee, D. Dhody, and D. Ceccarelli, "Traffic Engineering 1188 and Service Mapping Yang Model", draft-lee-teas-te- 1189 service-mapping-yang, work in progress. 1191 [SERVICE-YANG] Q. Wu, W. Liu and A. Farrel, "Service Models 1192 Explained", draft-wu-opsawg-service-model-explained, 1193 work in progress. 1195 [ACTN-PM] Y. Lee, et al., "YANG models for ACTN TE Performance 1196 Monitoring Telemetry and Network Autonomics", draft-lee- 1197 teas-actn-pm-telemetry-autonomics, work in progress. 1199 9. Contributors 1201 Contributor's Addresses 1203 Haomian Zheng 1204 Huawei Technologies 1205 Email: zhenghaomian@huawei.com 1206 Xian Zhang 1207 Huawei Technologies 1208 Email: zhang.xian@huawei.com 1210 Sergio Belotti 1211 Nokia 1212 Email: sergio.belotti@nokia.com 1214 Authors' Addresses 1216 Young Lee (ed.) 1217 Huawei Technologies 1218 Email: leeyoung@huawei.com 1220 Dhruv Dhody 1221 Huawei Technologies 1222 Email: dhruv.ietf@gmail.com 1224 Daniele Ceccarelli 1225 Ericsson 1226 Torshamnsgatan,48 1227 Stockholm, Sweden 1228 Email: daniele.ceccarelli@ericsson.com 1230 Takuya Miyasaka 1231 KDDI 1232 Email: ta-miyasaka@kddi.com 1234 Peter Park 1235 KT 1236 Email: peter.park@kt.com 1238 Bin Yeong Yoon 1239 ETRI 1240 Email: byyun@etri.re.kr