idnits 2.17.1 draft-lee-teas-actn-vn-yang-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 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 340 has weird spacing: '...mber-id uin...' == Line 353 has weird spacing: '...ment-id uin...' == Line 466 has weird spacing: '...n-ap-id uin...' == Line 475 has weird spacing: '...mber-id uin...' == Line 488 has weird spacing: '...ment-id uin...' == (9 more instances...) -- The document date (October 30, 2017) is 2371 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 364, 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 231, but not defined == Missing Reference: 'TE-Tunnel' is mentioned on line 282, but not defined == Unused Reference: 'TE-tunnel' is defined on line 1176, but no explicit reference was found in the text == Unused Reference: 'ACTN-REQ' is defined on line 1186, but no explicit reference was found in the text == Unused Reference: 'ACTN-FWK' is defined on line 1190, 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 Expires: April 30, 2018 D. Ceccarelli 5 Ericsson 6 Takuya Miyasaka 7 KDDI 8 Peter Park 9 KT 10 Bin Yeung Yoon 11 ETRI 13 October 30, 2017 15 A Yang Data Model for ACTN VN Operation 17 draft-lee-teas-actn-vn-yang-08 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 Service (VNS) 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 April 30, 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...............................................4 68 2.1. Type 1 VNS................................................5 69 2.2. Type 2 VNS................................................8 70 2.3. Justification of the ACTN VN Model on the CMI............10 71 3. ACTN VN YANG Model (Tree Structure)...........................12 72 4. ACTN-VN YANG Code.............................................15 73 5. Security Considerations.......................................27 74 6. IANA Considerations...........................................27 75 7. Acknowledgments...............................................27 76 8. References....................................................28 77 8.1. Normative References.....................................28 78 8.2. Informative References...................................28 79 9. Contributors..................................................29 80 Authors' Addresses...............................................29 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 Service (VNS) operation that is going to be implemented for the 87 Customer Network Controller (CNC)- Multi-Domain Service Coordinator 88 (MSDC) 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. To recapitulate VN types from [ACTN-FW], there are two 151 views of a VN as follows: 153 a) The VN can be seen as a set of edge-to-edge links (a Type 1 154 VN). Each link is referred as a VN member and is formed as 155 an end-to-end tunnel across the underlying networks. Such 156 tunnels may be constructed by recursive slicing or 157 abstraction of paths in the underlying networks and can 158 encompass edge points of the customer's network, access 159 links, intra-domain paths, and inter-domain links. 161 b) The VN can also be seen as a topology of virtual nodes and 162 virtual links (a Type 2 VN). The provider needs to map the 163 VN to actual resource assignment, which is known as virtual 164 network embedding. The nodes in this case include physical 165 end points, border nodes, and internal nodes as well as 166 abstracted nodes. Similarly the links include physical 167 access links, inter-domain links, and intra-domain links as 168 well as abstract links. 170 It [ACTN-FW] further defines a Virtual Network Service (VNS) as 171 follows: 173 A Virtual Network Service (VNS) is the service agreement between a 174 customer and provider to provide a VN. There are three types of VNS 175 defined in this document. 177 o Type 1 VNS refers to a VNS in which the customer is allowed 178 to create and operate a Type 1 VN. 180 o Type 2a and 2b VNS refer to VNSs in which the customer is 181 allowed to create and operates a Type 2 VN. With a Type 182 2a VNS, the VN is statically created at service 183 configuration time and the customer is not allowed to 184 change the topology (e.g., by adding or deleting abstract 185 nodes and links). A Type 2b VNS is the same as a Type 2a 186 VNS except that the customer is allowed to make dynamic 187 changes to the initial topology created at service 188 configuration time. 190 Note that the VNS definition and its types are based on and 191 consistent with OIF Virtual Transport Network Service (VTNS) [OIF- 192 VTNS]. VNS Type 1, 2a and 2b correspond to OIF VTNS Type A, B and C, 193 respectively. 195 2.1. Type 1 VNS 197 This section considers a Type 1 VNS, where the customer provides its 198 VN requirements in terms of VN members and VNAP. Figure 2 describes 199 a VN that comprises three VN members forming a full mesh for the VN 200 as an illustration. 202 VN Member 1 203 |<-------------------------------------->| 204 | | 205 | ------------- | 206 | ( ) | 207 | - - | 208 +---+ X ( Provider ) Z +---+ 209 |CE1|---+----( )---+---|CE2| 210 +---+ AP1 ( Network ) AP2 +---+ 211 .- - - _ -. 212 |\ ( ) /| 213 \ ------------- / 214 \ | / 215 ---- + AP3 ---- 216 VN Member 2 \ | / VN Member 3 217 \ Y | / 218 \ +---+ / 219 `----> |CE3|<----` 220 +---+ 222 Figure 2. Full Mesh Example for a VN 224 In Figure 2, a VN has three members, namely, VN Member 1, VN member 225 2, and VN member 3. VN Member 1 is an edge-to-edge link identified 226 by CE1-AP1 (source) and CE2-AP2 (destination). Similarly, VN Member 227 2 by CE1-AP1 and CE3-AP3 and VN Member 3 by CE3-AP3 and CE2-AP2. 228 This particular VN shown in Figure 2 is a full mesh connectivity 229 across these three customer end-points. 231 [ACTN-FW] defines the Access Point (AP) is a logical identifier 232 shared between the customer and the provider used to identify an 233 access link. The AP is used by the customer when requesting a VNS, 234 and VN Access Point (VNAP) is defined as a binding between an AP and 235 a given VN. 237 The set of assumptions that applies to this document is the 238 following: 240 - CNC is responsible for providing necessary Customer End-Points 241 information to the MDSC via the CMI. 242 - The access links (between Customer Edge (CE) Devices and the 243 Provider Edge (PE) Devices) are assumed to have been 244 provisioned prior to the VN instantiation request. 245 Access point identifiers have been configured and therefore are 246 known in both the CNC and the MDSC. This YANG model maintains 247 the list of AP and VNAP. 249 It is also possible for the customer to create a VN which can be a 250 hub and spoke or any other form of connectivity depending on its 251 connectivity requirement. Each VN-member may be unidirectional or 252 bidirectional which is also depending on its connectivity 253 requirements. The following figure shows some examples of a VN that 254 can be represented in a different connectivity form depending on the 255 customer's connectivity requirements. 257 +---+ +---+ +---+ +---+ +---+ +---+ 258 |CE1|---------|CE2| |CE4|---------|CE5| |CE8|---------|CE9| 259 +---+ +---+ +---+ +---+ +---+ +---+ 260 \ / | \ | \ | 261 \ / | \ | \ | 262 \ / | \ | \ | 263 \ / | \ | \ | 264 \ / | \ | \ | 265 \ / | \ | \ | 266 +---+ +---+ +---+ +---+ +---+ 267 |CE3| |CE6| |CE7| |CE6|---------|CE7| 268 +---+ +---+ +---+ +---+ +---+ 270 (a) Full Mesh (b) Hub and Spoke (c) partial Mesh 272 Figure 3. Different Connectivity Forms of a VN 274 It is important to note that a VN can associate a multiple number of 275 edge-to-edge links (i.e., VN members) with one unique identifier 276 under the VN umbrella. From a customer standpoint, this simplifies 277 its VN operation significantly. 279 The MDSC interacts with the CNC for the VN operation. Once the 280 customer VN is requested by the CNC to the MDSC, the MDSC shall be 281 responsible for translating and mapping the VN request into specific 282 network centric-models (e.g., TE-tunnels [TE-Tunnel], TE-topology 283 [TE-TOPO], etc.) to coordinate the multi-domain network operations 284 with Provisioning Network Controllers (PNCs). 286 2.2. Type 2 VNS 288 A type 2 VNS would allow the customer to also configure and learn a 289 VN abstract topology (Type 2 VN) via the TE topology yang model [TE- 290 TOPO]. A reference to the abstract topology is maintain in the VN 291 Yang model. Any change in topology (Type 2b VN) would be made via 292 [TE-TOPO]. Further, the ACTN VN Yang model is used for Type 2 VNS in 293 exactly the same way by configuring the VN members and corresponding 294 VNAP as described in section 2.1. 296 Using the path in VN-member in the ACTN VN yang model, CNC can also 297 set a path based on the abstract topology in [TE-TOPO]. Figure 4 298 shows an example VN abstract topology with six virtual nodes and six 299 virtual links configured and learned from via [TE-TOPO]. For each VN 300 member, the customer configures the path over the VN abstract 301 topology. For instance, for VN-member 1 (that connects CE1 to CE2), 302 the customer may choose a path comprising VL12 or alternatively a 303 path comprising of VL13-VL36-VL26 depending on the virtual link 304 state of the topology. If VN-member 1 needs to configure a link- 305 diversity path from VN-member 2 (CE1-CE3), then VN-member 1 should 306 configure a path comprising VL12 while VN-member 2 should configure 307 a path comprising VL13-VL34 to avoid the links that overlap. 309 |<----------------VN-member 1----------------->| 311 +------+ VL12 +------+ 312 --- CE1------|VNode1|----------------|VNode2|------CE2 --- 313 /|\ +------+ +------+ /|\ 314 | \ / | 315 | VL13 \ / VL26 | 316 | +------+ VL36 +------+ | 317 VN-member 2 |VNode3|--------|VNode6| | 318 | +------+ +------+ | 319 | VL34 / \ VL56 | 320 | / \ | 321 \|/ +------+ +------+ . 322 --- CE3------|VNode4|--------------|VNode5| / 323 +------+ VL45 +------+ / 324 / 325 / 326 |<------------------VN-member 3-----------------' 328 Figure 4. Type 2 VNS with VN abstract topology 330 The following YANG tree segment shows how YANG is modeled to support 331 Type VNS where for each VN-member how a path can be configured. 333 +--rw vn 334 +--rw vn-list* [vn-id] 335 +--rw vn-id uint32 336 +--rw vn-name? string 337 +--rw vn-topology-id? te-types:te-topology-id 338 | {type-2}? 339 +--rw vn-member-list* [vn-member-id] 340 | +--rw vn-member-id uint32 341 | +--rw src 342 | | +--rw src? leafref 343 | | +--rw src-vn-ap-id? leafref 344 | | +--rw multi-src? boolean 345 | | {multi-src-dest}? 346 | +--rw dest 347 | | +--rw dest? leafref 348 | | +--rw dest-vn-ap-id? leafref 349 | | +--rw multi-dest? boolean 350 | | {multi-src-dest}? 351 | +--rw path {type-2}? 352 | | +--rw path-element* [path-element-id] 353 | | +--rw path-element-id uint32 354 | | +--rw index? uint32 355 | | +--rw address? te-types:te-tp-id 356 | | +--rw hop-type? te-types:te-hop-type 358 2.3. Justification of the ACTN VN Model on the CMI. 360 2.3.1 Customer view of VN 362 The VN-Yang model allows to define a customer view, and allows the 363 customer to communicate using the VN constructs as described in the 364 [ACTN-INFO]. It also allows to group the set of edge-to-edge links 365 (i.e., VN members) under a common umbrella of VN. This allows the 366 customer to instantiate and view the VN as one entity, making it 367 easier for some customers to work on VN without worrying about the 368 details of the provider based YANG models. 370 Further, there are certain advantages to maintain a set of E2E 371 Tunnels as one VN unit for applying policy, reroute, protection, 372 restoration, etc., rather than treating each TE-tunnel as individual 373 unit. This allows customer to set one VN to be disjoint to another 374 as a whole, allows the optimization functions to be applied to the 375 VN rather than to an individual tunnels. 377 This is similar to the benefits of having a separate YANG model for 378 the customer services as described in [SERVICE-YANG], which states 379 that service models do not make any assumption of how a service is 380 actually engineered and delivered for a customer; details of how 381 network protocols and devices are engineered to deliver a service 382 are captured in other models that are not exposed through the 383 Customer-Provider Interface. Ability to hide the complexity of the 384 TE topology and TE tunnel YANG from some customers would be 385 beneficial. 387 2.3.2 Innovative Services 389 2.3.2.1 VN Compute 391 ACTN VN supports VN compute (pre-instantiation mode) to view the 392 full VN as a single entity before instantiation. Achieving this via 393 path computation or "compute only" tunnel setup does not provide the 394 same functionality. 396 2.3.2.2 Multi-sources and Multi-destinations 397 In creating a virtual network, the list of sources or destinations 398 or both may not be pre-determined by the customer. For instance, for 399 a given source, there may be a list of multiple-destinations to 400 which the optimal destination may be chosen depending on the network 401 resource situations. Likewise, for a given destination, there may 402 also be multiple-sources from which the optimal source may be 403 chosen. In some cases, there may be a pool of multiple sources and 404 destinations from which the optimal source-destination may be 405 chosen. The following YANG module is shown for describing source 406 container and destination container. The following YANG tree shows 407 how to model multi-sources and multi-destinations. 409 +--rw actn 410 | +--rw vn 411 | +--rw vn-list* [vn-id] 412 | ... 413 | | +--rw src 414 | | | +--rw src? leafref 415 | | | +--rw src-vn-ap-id? uint32 416 | | | +--rw multi-src? boolean 417 | | +--rw dest 418 | | +--rw dest? leafref 419 | | +--rw dest-vn-ap-id? uint32 420 | | +--rw multi-dest? boolean 422 2.3.2.3 Others 424 The VN Yang model can be easily augmented to support the mapping of 425 VN to the Services such as L3SM and L2SM as described in [TE-MAP]. 427 The VN Yang model can be extended to support telemetry, performance 428 monitoring and network autonomics as described in [ACTN-PM]. 430 2.3.3 Summary 432 This section summarizes the innovative service features of the ACTN 433 VN Yang. 435 o Maintenance of AP and VNAP along with VN. 437 o VN construct to group of edge-to-edge links 438 o VN Compute (pre-instantiate) 440 o Multi-Source / Multi-Destination 442 o Ability to support various VN and VNS Types 444 * VN Type 1: Customer configures the VN as a set of VN 445 Members. 446 No other details need to be set by customer, making for a 447 simplified operations for the customer. 449 * VN Type 2: Along with VN Members, the customer could also 450 provide an abstract topology, this topology is provided by 451 the Abstract TE Topology Yang Model. 453 3. ACTN VN YANG Model (Tree Structure) 455 module: ietf-actn-vn 456 +--rw actn 457 +--rw ap 458 | +--rw access-point-list* [access-point-id] 459 | +--rw access-point-id uint32 460 | +--rw access-point-name? string 461 | +--rw src-tp-id? binary 462 | +--rw dst-tp-id? binary 463 | +--rw max-bandwidth? te-types:te-bandwidth 464 | +--rw avl-bandwidth? te-types:te-bandwidth 465 | +--rw vn-ap* [vn-ap-id] 466 | +--rw vn-ap-id uint32 467 | +--rw vn? -> /actn/vn/vn-list/vn-id 468 +--rw vn 469 +--rw vn-list* [vn-id] 470 +--rw vn-id uint32 471 +--rw vn-name? string 472 +--rw vn-topology-id? te-types:te-topology-id 473 | {type-2}? 474 +--rw vn-member-list* [vn-member-id] 475 | +--rw vn-member-id uint32 476 | +--rw src 477 | | +--rw src? leafref 478 | | +--rw src-vn-ap-id? leafref 479 | | +--rw multi-src? boolean 480 | | {multi-src-dest}? 481 | +--rw dest 482 | | +--rw dest? leafref 483 | | +--rw dest-vn-ap-id? leafref 484 | | +--rw multi-dest? boolean 485 | | {multi-src-dest}? 486 | +--rw path {type-2}? 487 | | +--rw path-element* [path-element-id] 488 | | +--rw path-element-id uint32 489 | | +--rw index? uint32 490 | | +--rw address? te-types:te-tp-id 491 | | +--rw hop-type? te-types:te-hop-type 492 | +--ro metric* [metric-type] 493 | | +--ro metric-type identityref 494 | | +--ro value? uint32 495 | +--ro oper-status? identityref 496 | +--ro tunnel-ref? te:tunnel-ref 497 +--ro multi-src-dest {multi-src-dest}? 498 | +--ro selected-vn-member? leafref 499 +--rw objective-function? pcep:objective-function 500 +--rw metric* [metric-type] 501 | +--rw metric-type identityref 502 | +--rw limit 503 | | +--rw enabled? boolean 504 | | +--rw value? uint32 505 | +--rw optimize 506 | +--rw enabled? boolean 507 | +--rw value? uint32 508 +--rw bandwidth? te-types:te-bandwidth 509 +--rw protection? identityref 510 +--rw local-reroute? boolean 511 +--rw push-allowed? boolean 512 +--rw incremental-update? boolean 513 +--rw admin-status? identityref 514 +--ro oper-status? identityref 516 rpcs: 517 +---x vn-compute 518 +---w input 519 | +---w vn-member-list* [vn-member-id] 520 | | +---w vn-member-id uint32 521 | | +---w src 522 | | | +---w src? leafref 523 | | | +---w src-vn-ap-id? leafref 524 | | | +---w multi-src? boolean {multi-src-dest}? 525 | | +---w dest 526 | | | +---w dest? leafref 527 | | | +---w dest-vn-ap-id? leafref 528 | | | +---w multi-dest? boolean 529 | | | {multi-src-dest}? 530 | | +---w path {type-2}? 531 | | +---w path-element* [path-element-id] 532 | | +---w path-element-id uint32 533 | | +---w index? uint32 534 | | +---w address? te-types:te-tp-id 535 | | +---w hop-type? te-types:te-hop-type 536 | +---w objective-function? pcep:objective-function 537 | +---w metric* [metric-type] 538 | | +---w metric-type identityref 539 | | +---w limit 540 | | | +---w enabled? boolean 541 | | | +---w value? uint32 542 | | +---w optimize 543 | | +---w enabled? boolean 544 | | +---w value? uint32 545 | +---w bandwidth? te-types:te-bandwidth 546 | +---w protection? identityref 547 | +---w local-reroute? boolean 548 | +---w push-allowed? boolean 549 | +---w incremental-update? boolean 550 +--ro output 551 +--ro vn-member-list* [vn-member-id] 552 | +--ro vn-member-id uint32 553 | +--ro src 554 | | +--ro src? leafref 555 | | +--ro src-vn-ap-id? leafref 556 | | +--ro multi-src? boolean {multi-src-dest}? 557 | +--ro dest 558 | | +--ro dest? leafref 559 | | +--ro dest-vn-ap-id? leafref 560 | | +--ro multi-dest? boolean 561 | | {multi-src-dest}? 562 | +--ro path {type-2}? 563 | | +--ro path-element* [path-element-id] 564 | | +--ro path-element-id uint32 565 | | +--ro index? uint32 566 | | +--ro address? te-types:te-tp-id 567 | | +--ro hop-type? te-types:te-hop-type 568 | +--ro metric* [metric-type] 569 | | +--ro metric-type identityref 570 | | +--ro value? uint32 571 | +--ro compute-status? identityref 572 +--ro multi-src-dest {multi-src-dest}? 573 +--ro selected-vn-member-id? uint32 575 4. ACTN-VN YANG Code 577 The YANG code is as follows: 579 file "ietf-actn-vn@2017-10-23.yang" 581 module ietf-actn-vn { 583 namespace "urn:ietf:params:xml:ns:yang:ietf-actn-vn"; 585 prefix "vn"; 587 /* Import TE generic types */ 588 import ietf-te-types { 589 prefix "te-types"; 590 } 592 import ietf-te { 593 prefix "te"; 594 } 596 import ietf-pcep { 597 prefix "pcep"; 598 } 600 organization 601 "IETF Traffic Engineering Architecture and Signaling (TEAS) 602 Working Group"; 604 contact 605 "Editor: Young Lee 606 : Dhruv Dhody "; 608 description 609 "This module contains a YANG module for the ACTN VN. It 610 describes a VN operation module that takes place in the 611 context of the CNC-MDSC Interface (CMI) of the ACTN 612 architecture where the CNC is the actor of a VN Instantiation 613 /modification /deletion."; 615 revision 2017-10-23 { 616 description 617 "initial version."; 618 reference 619 "TBD"; 620 } 622 /* 623 * Features 624 */ 626 feature multi-src-dest { 627 description 628 "Support for selection of one src or destination 629 among multiple."; 630 } 632 feature type-2 { 633 description 634 "Support for Type 2 VNS based on the abstract VN 635 Topology."; 636 } 638 identity path-metric-delay { 639 base te-types:path-metric-type; 640 description 641 "delay path metric"; 642 } 644 identity path-metric-delay-variation { 645 base te-types:path-metric-type; 646 description 647 "delay-variation path metric"; 648 } 650 identity path-metric-loss { 651 base te-types:path-metric-type; 652 description 653 "loss path metric"; 654 } 656 identity vn-state-type { 657 description 658 "Base identity for VN state"; 659 } 661 identity vn-state-up { 662 base vn-state-type; 663 description "VN state up"; 665 } 667 identity vn-state-down { 668 base vn-state-type; 669 description "VN state down"; 670 } 672 identity vn-admin-state-type { 673 description 674 "Base identity for VN admin states"; 675 } 677 identity vn-admin-state-up { 678 base vn-admin-state-type; 679 description "VN administratively state up"; 680 } 682 identity vn-admin-state-down { 683 base vn-admin-state-type; 684 description "VN administratively state down"; 685 } 687 identity vn-compute-state-type { 688 description 689 "Base identity for compute states"; 690 } 692 identity vn-compute-state-computing { 693 base vn-compute-state-type; 694 description 695 "State path compute in progress"; 696 } 698 identity vn-compute-state-computation-ok { 699 base vn-compute-state-type; 700 description 701 "State path compute successful"; 702 } 704 identity vn-compute-state-computatione-failed { 705 base vn-compute-state-type; 706 description 707 "State path compute failed"; 708 } 710 /* 711 * Groupings 712 */ 713 grouping vn-ap { 714 description 715 "VNAP related information"; 716 leaf vn-ap-id { 717 type uint32; 718 description 719 "unique identifier for the referred 720 VNAP"; 721 } 722 leaf vn { 723 type leafref { 724 path "/actn/vn/vn-list/vn-id"; 725 } 726 description 727 "reference to the VN"; 728 } 729 } 731 grouping access-point{ 732 description 733 "AP related information"; 734 leaf access-point-id { 735 type uint32; 736 description 737 "unique identifier for the referred 738 access point"; 739 } 740 leaf access-point-name { 741 type string; 742 description 743 "ap name"; 744 } 745 /*using direct tp-id for now as per ietf-te 746 should check if reference is better*/ 747 leaf src-tp-id { 748 type binary; 749 description 750 "TE tunnel source termination point identifier."; 751 } 752 leaf dst-tp-id { 753 type binary; 754 description 755 "TE tunnel destination termination point identifier."; 756 } 757 leaf max-bandwidth { 758 type te-types:te-bandwidth; 759 description 760 "max bandwidth of the AP"; 761 } 762 leaf avl-bandwidth { 763 type te-types:te-bandwidth; 764 description 765 "available bandwidth of the AP"; 766 } 767 /*add details and any other properties of AP, 768 not associated by a VN 769 CE port, PE port etc. 771 */ 773 list vn-ap { 774 key vn-ap-id; 775 uses vn-ap; 776 description 777 "list of VNAP in this AP"; 778 } 780 }//access-point 782 grouping vn-member { 783 description 784 "vn-member is described by this container"; 785 leaf vn-member-id { 786 type uint32; 787 description 788 "vn-member identifier"; 789 } 790 container src 791 { 792 description 793 "the source of VN Member"; 794 leaf src { 795 type leafref { 796 path "/actn/ap/access-point-list/access-point-id"; 797 } 798 description 799 "reference to source AP"; 800 } 801 leaf src-vn-ap-id{ 802 type leafref { 803 path "/actn/ap/access-point-list/vn-ap/vn-ap-id"; 804 } 805 description 806 "reference to source VNAP"; 807 } 808 leaf multi-src { 809 if-feature multi-src-dest; 810 type boolean; 811 description 812 "Is source part of multi-source, where 813 only one of the source is enabled"; 814 } 815 } 816 container dest 817 { 818 description 819 "the destination of VN Member"; 820 leaf dest { 821 type leafref { 822 path "/actn/ap/access-point-list/access-point-id"; 823 } 824 description 825 "reference to destination AP"; 826 } 827 leaf dest-vn-ap-id{ 828 type leafref { 829 path "/actn/ap/access-point-list/vn-ap/vn-ap-id"; 830 } 831 description 832 "reference to dest VNAP"; 833 } 834 leaf multi-dest { 835 if-feature multi-src-dest; 836 type boolean; 837 description 838 "Is destination part of multi-destination, where 839 only one of the destination is enabled"; 840 } 841 } 842 container path 843 { 844 if-feature type-2; 845 description 846 "the path if set by the customer"; 847 list path-element { 848 key "path-element-id"; 849 description 850 "A list of path elements describing the service path."; 851 leaf path-element-id { 852 type uint32; 853 description "To identify the element in a path."; 854 } 855 leaf index { 856 type uint32; 857 description "ERO subobject index"; 858 } 859 leaf address { 860 type te-types:te-tp-id; 861 description 862 "Numbered link TE termination point address. 863 Should refer to the abstract TE topology 864 of this VN"; 865 } 866 leaf hop-type { 867 type te-types:te-hop-type; 868 description 869 "strict or loose hop"; 870 } 871 } 872 } 873 }//vn-member 875 grouping policy { 876 description 877 "policy related to vn-member-id"; 878 leaf local-reroute { 879 type boolean; 880 description 881 "Policy to state if reroute 882 can be done locally"; 883 } 884 leaf push-allowed { 885 type boolean; 886 description 887 "Policy to state if changes 888 can be pushed to the customer"; 889 } 890 leaf incremental-update { 891 type boolean; 892 description 893 "Policy to allow only the 894 changes to be reported"; 895 } 896 }//policy 898 grouping metrics-op { 899 description 900 "metric related information"; 901 list metric{ 902 key "metric-type"; 903 config false; 904 description 905 "The list of metrics for VN"; 906 leaf metric-type { 907 type identityref { 908 base te-types:path-metric-type; 909 } 910 description 911 "The VN metric type."; 912 } 913 leaf value{ 914 type uint32; 915 description 916 "The limit value"; 917 } 918 } 920 } 922 grouping metrics { 923 description 924 "metric related information"; 925 list metric{ 926 key "metric-type"; 927 description 928 "The list of metrics for VN"; 929 leaf metric-type { 930 type identityref { 931 base te-types:path-metric-type; 932 } 933 description 934 "The VN metric type."; 935 } 936 container limit { 937 description 938 "Limiting contraints"; 939 leaf enabled{ 940 type boolean; 941 description 942 "Limit contraint is enabled"; 943 } 944 leaf value{ 945 type uint32; 946 description 947 "The limit value"; 948 } 949 } 950 container optimize{ 951 description 952 "optimizing constraints"; 953 leaf enabled{ 954 type boolean; 955 description 956 "Metric to optimize"; 957 } 958 leaf value{ 959 type uint32; 960 description 961 "The computed value"; 962 } 963 } 964 } 966 } 968 grouping service-metric { 969 description 970 "service-metric"; 971 leaf objective-function { 972 type pcep:objective-function; 973 description 974 "operational state of the objective function"; 975 } 977 uses metrics; 979 leaf bandwidth { 980 type te-types:te-bandwidth; 981 description 982 "bandwidth requested/required for 983 vn-member-id"; 984 } 986 leaf protection { 987 type identityref { 988 base te-types:lsp-protection-type; 989 } 990 description "protection type."; 991 } 993 uses policy; 995 }//service-metric 997 /* 998 * Configuration data nodes 999 */ 1000 container actn { 1001 description 1002 "actn is described by this container"; 1003 container ap { 1004 description 1005 "AP configurations"; 1006 list access-point-list { 1007 key "access-point-id"; 1008 description 1009 "access-point identifier"; 1010 uses access-point{ 1011 description 1012 "access-point information"; 1013 } 1014 } 1015 } 1016 container vn { 1017 description 1018 "VN configurations"; 1020 list vn-list { 1021 key "vn-id"; 1022 description 1023 "a virtual network is identified by a vn-id"; 1024 leaf vn-id { 1025 type uint32; 1026 description 1027 "a unique vn identifier"; 1028 } 1029 leaf vn-name { 1030 type string; 1031 description "vn name"; 1032 } 1033 leaf vn-topology-id{ 1034 if-feature type-2; 1035 type te-types:te-topology-id; 1036 description 1037 "An optional identifier to the TE Topology 1038 Model where the abstract nodes and links 1039 of the Topology can be found for Type 2 1040 VNS"; 1042 } 1043 list vn-member-list{ 1044 key "vn-member-id"; 1045 description 1046 "List of VN-members in a VN"; 1047 uses vn-member; 1048 uses metrics-op; 1049 leaf oper-status { 1050 type identityref { 1051 base vn-state-type; 1052 } 1053 config false; 1054 description 1056 "VN-member operational state."; 1058 } 1059 leaf tunnel-ref { 1060 type te:tunnel-ref; 1061 config false; 1062 description 1063 "A reference to the TE tunnel 1064 in the TE model"; 1065 } 1066 } 1067 container multi-src-dest{ 1068 if-feature multi-src-dest; 1069 config false; 1070 description 1071 "The selected VN Member when multi-src 1072 and/or mult-destination is enabled."; 1073 leaf selected-vn-member{ 1074 type leafref { 1075 path "/actn/vn/vn-list/vn-member-list/vn-member-id"; 1076 } 1077 description 1078 "The selected VN Member along the set 1079 of source and destination configured 1080 with multi-source and/or multi-destination"; 1081 } 1082 } 1084 uses service-metric; 1086 leaf admin-status { 1087 type identityref { 1088 base vn-admin-state-type; 1089 } 1090 default vn-admin-state-up; 1091 description "VN administrative state."; 1092 } 1093 leaf oper-status { 1094 type identityref { 1095 base vn-state-type; 1096 } 1097 config false; 1098 description "VN operational state."; 1099 } 1101 }//vn-list 1102 }//vn 1103 }//actn 1105 /* 1106 * Notifications - TBD 1107 */ 1108 /* 1109 * RPC 1110 */ 1111 rpc vn-compute{ 1112 description 1113 "The VN computation without actual 1114 instantiation"; 1115 input { 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 } 1122 uses service-metric; 1123 } 1124 output { 1125 list vn-member-list{ 1126 key "vn-member-id"; 1127 description 1128 "List of VN-members in a VN"; 1129 uses vn-member; 1130 uses metrics-op; 1131 leaf compute-status { 1132 type identityref { 1133 base vn-compute-state-type; 1134 } 1135 description 1136 "VN-member compute state."; 1137 } 1138 } 1139 container multi-src-dest{ 1140 if-feature multi-src-dest; 1141 description 1142 "The selected VN Member when multi-src 1143 and/or mult-destination is enabled."; 1144 leaf selected-vn-member-id{ 1145 type uint32; 1146 description 1147 "The selected VN Member-id from the 1148 input"; 1149 } 1150 } 1151 } 1152 } 1153 } 1154 1156 5. Security Considerations 1158 TDB 1160 6. IANA Considerations 1162 TDB 1164 7. Acknowledgments 1166 The authors would like to thank Igor Bryskin and Xufeng Liu for 1167 their helpful comments and valuable contributions. 1169 8. References 1171 8.1. Normative References 1173 [TE-TOPO] X. Liu, et al., "YANG Data Model for TE Topologies", work 1174 in progress: draft-ietf-teas-yang-te-topo. 1176 [TE-tunnel] T. Saad, et al., "A YANG Data Model for Traffic 1177 Engineering Tunnels and Interfaces", work in progress: 1178 draft-ietf-teas-yang-te. 1180 8.2. Informative References 1182 [RFC7926] A. Farrel (Ed.), "Problem Statement and Architecture for 1183 Information Exchange between Interconnected Traffic- 1184 Engineered Networks", RFC 7926, July 2016. 1186 [ACTN-REQ] Lee, et al., "Requirements for Abstraction and Control of 1187 TE Networks", draft-ietf-teas-actn-requirements, work in 1188 progress. 1190 [ACTN-FWK] D. Ceccarelli, Y. Lee [Editors], "Framework for 1191 Abstraction and Control of Traffic Engineered Networks", 1192 draft-ceccarelli-teas-actn-framework, work in progress. 1194 [TE-MAP] Y. Lee, D. Dhody, and D. Ceccarelli, "Traffic Engineering 1195 and Service Mapping Yang Model", draft-lee-teas-te- 1196 service-mapping-yang, work in progress. 1198 [SERVICE-YANG] Q. Wu, W. Liu and A. Farrel, "Service Models 1199 Explained", draft-wu-opsawg-service-model-explained, 1200 work in progress. 1202 [ACTN-PM] Y. Lee, et al., "YANG models for ACTN TE Performance 1203 Monitoring Telemetry and Network Autonomics", draft-lee- 1204 teas-actn-pm-telemetry-autonomics, work in progress. 1206 [OIF-VTNS] Virtual Transport Network Services 1.0 Specification, IA 1207 OIF-VTNS-1.0, April 2017. 1209 9. Contributors 1211 Contributor's Addresses 1213 Haomian Zheng 1214 Huawei Technologies 1215 Email: zhenghaomian@huawei.com 1217 Xian Zhang 1218 Huawei Technologies 1219 Email: zhang.xian@huawei.com 1221 Sergio Belotti 1222 Nokia 1223 Email: sergio.belotti@nokia.com 1225 Authors' Addresses 1227 Young Lee (ed.) 1228 Huawei Technologies 1229 Email: leeyoung@huawei.com 1231 Dhruv Dhody 1232 Huawei Technologies 1233 Email: dhruv.ietf@gmail.com 1235 Daniele Ceccarelli 1236 Ericsson 1237 Torshamnsgatan,48 1238 Stockholm, Sweden 1239 Email: daniele.ceccarelli@ericsson.com 1241 Takuya Miyasaka 1242 KDDI 1243 Email: ta-miyasaka@kddi.com 1245 Peter Park 1246 KT 1247 Email: peter.park@kt.com 1248 Bin Yeong Yoon 1249 ETRI 1250 Email: byyun@etri.re.kr