idnits 2.17.1 draft-lee-teas-actn-vn-yang-00.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 (July 5, 2016) is 2846 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: 'ACTN-FW' is mentioned on line 92, but not defined == Missing Reference: 'TE-Tunnel' is mentioned on line 220, but not defined == Unused Reference: 'TE-tunnel' is defined on line 653, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-teas-actn-requirements (ref. 'ACTN-REQ') ** Downref: Normative reference to an Informational draft: draft-ceccarelli-teas-actn-framework (ref. 'ACTN-FWK') Summary: 2 errors (**), 0 flaws (~~), 4 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 Huawei 3 Intended Status: Standard Track D. Ceccarelli 4 Ericsson 5 Dhruv Doddy 6 Huawei 7 Takuya Miyasaka 8 KDDI 9 Peter Park 10 KT 11 Bin Young Yoon 12 ETRI 14 Expires: January 5, 2017 July 5, 2016 16 A Yang Data Model for ACTN VN Operation 18 draft-lee-teas-actn-vn-yang-00.txt 20 Abstract 22 This document provides a YANG data model for the Abstraction and 23 Control of Traffic Engineered (TE) networks (ACTN) Virtual Network 24 (VN) operation. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with 29 the provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six 37 months and may be updated, replaced, or obsoleted by other documents 38 at any time. It is inappropriate to use Internet-Drafts as 39 reference material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 This Internet-Draft will expire on January 5, 2017. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with 59 respect to this document. Code Components extracted from this 60 document must include Simplified BSD License text as described in 61 Section 4.e of the Trust Legal Provisions and are provided without 62 warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction...................................................2 67 1.1. Terminology...............................................3 68 1.2. ACTN CMI context..........................................3 69 2. ACTN VN YANG Model (Tree Structure)............................7 70 3. ACTN-VN YANG Model.............................................8 71 4. Security Considerations.......................................16 72 5. IANA Considerations...........................................16 73 6. Acknowledgments...............................................16 74 7. References....................................................17 75 7.1. Normative References.....................................17 76 7.2. Informative References...................................17 77 8. Contributors..................................................17 78 Authors' Addresses...............................................18 80 1. Introduction 82 This document provides a YANG data model for the Abstraction and 83 Control of Traffic Engineered (TE) networks (ACTN) Virtual Network 84 (VN) operation that is going to be implemented for the Customer 85 Network Controller (CNC)- Multi-Domain Service Coordinator (MSDC) 86 interface (CMI). The YANG model discussed in this document is used 87 to operate customer-driven VNs during the VN instantiation and its 88 life-cycle operations stages. 90 This document is based on the requirements identified in [ACTN-REQ] 91 and on the architecture framework defined in [ACTN-FWK]. As defined 92 in [ACTN-FW], a Virtual Network (VN) is a customer view of the TE 93 networks and may comprise a set of end-to-end tunnels connecting 94 customer's end points. Therefore, it is important to associate a VN 95 with its members (which are a number of end-to-end tunnels) that are 96 going to be created in the provider network. Each end-to-end tunnel 97 defined under a VN is referred to as a VN member. 99 The YANG model discussed in this document basically provides the 100 characteristics of VNs such as VN level parameters (e.g., VN ID, VN 101 member, VN objective function, VN service preference, etc.), 102 customer's end point characteristics (e.g., Customer Interface 103 Capability, Access Points Interface characteristics, etc.), and 104 other relevant VN information that needs to be known to the MDSC to 105 facilitate ACTN VN operation. 107 1.1. Terminology 109 - Abstract Topology: Every lower controller in the provider 110 network, when is representing its network topology to a higher 111 layer, it may want to hide details of the actual network 112 topology. In such case, an abstract topology may be used for 113 this purpose. Abstract topology enhances scalability for the 114 MDSC to operate multi-domain networks. The abstraction of 115 topology can be applied on both MPI and CMI, from PNC to MDSC 116 and from MDSC to CNC respectively. 118 - Access link: A link between a customer node and a provider 119 node. 121 - Access Point (AP): An access point is defined on an access 122 link. It is used to keep confidentiality between the customer 123 and the provider. It is an identifier shared between the 124 customer and the provider, used to map the end points of the 125 border node in the provider NW. The AP can be used by the 126 customer when requesting connectivity service to the provider. 127 A number of parameters, e.g. available bandwidth, need to be 128 associated to the AP to qualify it. 130 - VN Access Point (VNAP): A VNAP is defined within an AP as part 131 of a given VN and is used to identify the portion of the AP, 132 (and hence of the access link) dedicated to a given VN. 134 1.2. ACTN CMI context 136 The model presented in this document has the following ACTN context. 138 +-------+ 139 | CNC | 140 +-------+ 141 | 142 | <--- CMI (CNC-MDSC Interface) 143 | 144 +-----------------------+ 145 | MDSC | 146 +-----------------------+ 148 Figure 1. ACTN CMI 150 The CNC is the actor of the VN creation/modification/deletion (aka 151 VN CRUD (- Create, read, update and delete) model). A VN comprises a 152 set of the VN members. Each VN member is an end-to-end tunnel from a 153 customer point of view that connects customer endpoints (i.e., 154 source CE and destination CE). The following figure describes a VN 155 that comprises three VN members forming a full mesh for the VN as an 156 illustration. 158 VN Member 1 159 |<-------------------------------------->| 160 | | 161 | ------------- | 162 | ( ) | 163 | - - | 164 +---+ X ( Provider ) Z +---+ 165 |CE1|---+----( )---+---|CE2| 166 +---+ AP1 ( Network ) AP2 +---+ 167 .- - - _ -. 168 |\ ( ) /| 169 \ ------------- / 170 \ | / 171 ---- + AP3 ---- 172 VN Member 2 \ | / VN Member 3 173 \ Y | / 174 \ +---+ / 175 `----> |CE3|<----` 176 +---+ 178 Figure 2. Full Mesh Example for a VN 180 In Figure 2, a VN has three members, namely, VN Member 1, VN member 181 2, and VN member 3. VN Member 1 is an end-to-end tunnel identified 182 by CE1-AP1 (source) and CE2-AP2 (destination). Similarly, VN Member 183 2 by CE1-AP1 and CE3-AP3 and VN Member 3 by CE3-AP3 and CE2-AP2. 184 This particular VN shown in Figure 2 is a full mesh connectivity 185 across these three customer end-points. 187 It is also possible for the customer to create a VN which can be a 188 hub and spoke or any other form of connectivity depending on its 189 connectivity requirement. Each end-to-end tunnel may be 190 unidirectional or bidirectional which is also depending on its 191 connectivity requirements. The following figure shows some examples 192 of a VN that can represented in a different connectivity form 193 depending on the customer's connectivity requirements. 195 +---+ +---+ +---+ +---+ +---+ +---+ 196 |CE1|---------|CE2| |CE4|---------|CE5| |CE8|---------|CE9| 197 +---+ +--- +---+ +---+ +---+ +---+ 198 \ / | \ | \ | 199 \ / | \ | \ | 200 \ / | \ | \ | 201 \ / | \ | \ | 202 \ / | \ | \ | 203 \ / | \ | \ | 204 +---+ +---+ +---+ +---+ +---+ 205 |CE3| |CE6| |CE7| |CE6|---------|CE7| 206 +---+ +---+ +---+ +---+ +---+ 208 (a) Full Mesh (b) Hub and Spoke (c) partial Mesh 210 Figure 2. Different Connectivity Forms of a VN 212 It is important to note that a VN can associate a multiple number of 213 end-to-end tunnels (i.e., VN members) with one unique identifier. 214 From a customer standpoint, this simplifies its VN operation 215 significantly. 217 The MDSC interacts with the CNC for the VN operation. Once the 218 customer VN is requested by the CNC to the MDSC, the MDSC shall be 219 responsible for translating and mapping the VN request into specific 220 network centric-models (e.g., TE-tunnels [TE-Tunnel], TE-topology 221 [TE-TOPO], etc.) to coordinate the multi-domain network operations 222 with PNCs. The mapping and translation of a VN into network-centric 223 models is out of the scope of this document. 225 The set of assumptions that applies to this document is the 226 following: 228 - CNC is responsible for providing necessary Customer End-Points 229 information to the MDSC via the CMI. 230 - The access links (between Customer Edge (CE) Devices and the 231 Provider Edge (PE) Devices) are assumed to have been 232 provisioned prior to the VN instantiation request. 233 - Access point identifiers have been configured and therefore are 234 known in both the CNC and the MDSC. 236 2. ACTN VN YANG Model (Tree Structure) 238 module: ietf-actn-vn 239 +--rw actn 240 | +--rw ap 241 | | +--rw access-point-list* [access-point-id] 242 | | +--rw access-point-id uint32 243 | | +--rw access-point-name? string 244 | | +--rw max-bandwidth? decimal64 245 | | +--rw avl-bandwidth? decimal64 246 | +--rw vn 247 | +--rw vn-list* [vn-id] 248 | +--rw vn-id uint32 249 | +--rw vn-name? string 250 | +--rw vn-member-list* [vn-member-id] 251 | | +--rw vn-member-id uint32 252 | | +--rw src? leafref 253 | | +--rw src-vn-ap-id? uint32 254 | | +--rw dest? leafref 255 | | +--rw dest-vn-ap-id? uint32 256 | +--rw delay? uint32 257 | +--rw delay-variation? uint32 258 | +--rw packet-loss? decimal64 259 | +--rw bandwidth? decimal64 260 | +--rw protection? identityref 261 | +--rw local-reroute? boolean 262 | +--rw push-allowed? boolean 263 | +--rw incremental-update? boolean 264 | +--rw admin-status? identityref 265 +--ro actn-state 266 +--ro ap 267 | +--ro access-point-list* [access-point-id] 268 | +--ro access-point-id uint32 269 | +--ro access-point-name? string 270 | +--ro max-bandwidth? decimal64 271 | +--ro avl-bandwidth? decimal64 272 +--ro vn 273 +--ro vn-list* [vn-id] 274 +--ro vn-id uint32 275 +--ro vn-name? string 276 +--ro vn-member-list* [vn-member-id] 277 | +--ro vn-member-id uint32 278 | +--ro src? leafref 279 | +--ro src-vn-ap-id? uint32 280 | +--ro dest? leafref 281 | +--ro dest-vn-ap-id? uint32 282 | +--ro delay? uint32 283 | +--ro delay-variation? uint32 284 | +--ro packet-loss? decimal64 285 | +--ro oper-status? identityref 286 +--ro delay? uint32 287 +--ro delay-variation? uint32 288 +--ro packet-loss? decimal64 289 +--ro bandwidth? decimal64 290 +--ro protection? identityref 291 +--ro local-reroute? boolean 292 +--ro push-allowed? boolean 293 +--ro incremental-update? boolean 294 +--ro admin-status? identityref 295 +--ro oper-status? Identityref 297 3. ACTN-VN YANG Code 299 The YANG code is as follows: 301 file ietf-actn-vn@2016-7-5.yang 303 module ietf-actn-vn { 305 namespace "urn:ietf:params:xml:ns:yang:ietf-actn-vn"; 307 prefix "vn"; 309 /* Import TE generic types */ 310 import ietf-te-types { 311 prefix "te-types"; 312 } 313 organization 314 "IETF Traffic Engineering Architecture and Signaling (TEAS) 315 Working Group"; 317 contact 318 "Editor: Young Lee "; 320 description 321 "This module contains a YANG module for the ACTN VN. It 322 describes a VN operation module that takes place in the 323 context of the CNC-MDSC Interface (CMI) of the ACTN 324 architecture where the CNC is the actor of a VN creation 325 /modification /deletion."; 327 revision 2016-07-05 { 328 description 329 "initial version."; 330 reference 331 "TBD"; 332 } 334 /* 335 * Groupings 336 */ 338 grouping access-point{ 339 description 340 "AP related information"; 341 leaf access-point-id { 342 type uint32; 343 description 344 "unique identifier for the referred 345 access point"; 346 } 347 leaf access-point-name { 348 type string; 349 description 350 "ap name"; 351 } 352 leaf max-bandwidth { 353 type decimal64 { 354 fraction-digits 2; 355 range "0..max"; 356 } 357 description 358 "max bandwidth of the AP"; 359 } 360 leaf avl-bandwidth { 361 type decimal64 { 362 fraction-digits 2; 363 range "0..max"; 364 } 365 description 366 "available bandwidth of the AP"; 367 } 368 /*add details and any other properties of AP, 369 not associated by a VN 370 CE port, PE port etc. 372 This link may not be in the TE topology model(?) 373 thus reference to that model would be incorrect 374 */ 375 }//access-point 377 grouping vn-member { 378 description 379 "vn-member is described by this container"; 380 leaf vn-member-id { 381 type uint32; 382 description 383 "vn-member identifier"; 384 } 385 leaf src { 386 type leafref { 387 path "/actn/ap/access-point-list/access-point-id"; 388 } 389 description 390 "reference to source AP"; 391 } 392 leaf src-vn-ap-id{ 393 type uint32; 394 description 395 "vn-ap-id"; 396 } 397 leaf dest { 398 type leafref { 399 path "/actn/ap/access-point-list/access-point-id"; 400 } 401 description 402 "reference to destination AP"; 403 } 404 leaf dest-vn-ap-id{ 405 type uint32; 406 description 407 "vn-ap-id"; 408 } 410 /* can we add reference to itef-te model(?) here 411 */ 413 }//vn-member 415 grouping connectivity-metric { 416 description 417 "service aware metrics"; 418 leaf delay { 419 type uint32 { 420 range "0..max"; 421 } 422 description 423 "Path Delay or latency in micro seconds."; 424 } 425 leaf delay-variation { 426 type uint32 { 427 range "0..max"; 428 } 429 description 430 "Path Delay variation in micro seconds."; 431 } 432 leaf packet-loss { 433 type decimal64 { 434 fraction-digits 6; 435 range "0 .. max"; 437 } 438 description 439 "Path Packet Loss in percentage"; 440 } 441 /*should we add other metrics 442 like bandwidth utilization?*/ 444 }//connectivity-metric 446 grouping policy { 447 description 448 "policy related to vn-member-id"; 449 leaf local-reroute { 450 type boolean; 451 description 452 "Policy to state if reroute 453 can be done locally"; 454 } 455 leaf push-allowed { 456 type boolean; 457 description 458 "Policy to state if changes 459 can be pushed to the customer"; 460 } 461 leaf incremental-update { 462 type boolean; 463 description 464 "Policy to allow only the 465 changes to be reported"; 466 } 467 }//policy 469 grouping objective-function { 470 description 471 "objective-function"; 473 uses connectivity-metric; 475 leaf bandwidth { 476 type decimal64 { 477 fraction-digits 2; 478 range "0..max"; 479 } 480 description 481 "bandwidth requested/required for 482 vn-member-id"; 483 } 485 leaf protection { 486 type identityref { 487 base te-types:lsp-prot-type; 488 } 489 description "protection type."; 490 } 492 uses policy; 494 }//objective-function 496 /* 497 * Configuration data nodes 498 */ 499 container actn { 500 description 501 "actn is described by this container"; 502 container ap { 503 description 504 "AP configurations"; 505 list access-point-list { 506 key "access-point-id"; 507 description 508 "access-point identifier"; 509 uses access-point{ 510 description 511 "access-point information"; 512 } 513 } 514 } 515 container vn { 516 description 517 "VN configurations"; 519 list vn-list { 520 key "vn-id"; 521 description 522 "a virtual network is identified by a vn-id"; 523 leaf vn-id { 524 type uint32; 525 description 526 "a unique vn identifier"; 527 } 528 leaf vn-name { 529 type string; 530 description "vn name"; 531 } 532 list vn-member-list{ 533 key "vn-member-id"; 534 description 535 "List of VN-members in a VN"; 536 uses vn-member; 537 } 538 uses objective-function; 540 leaf admin-status { 541 type identityref { 542 base te-types:state-type; 543 } 544 default te-types:state-up; 545 description "VN administrative state."; 546 } 547 }//vn-list 548 }//vn 549 }//actn 551 /* 552 * Operational data nodes 553 */ 555 container actn-state{ 556 config false; 558 description 559 "actn is described by this container"; 561 container ap { 562 description 563 "AP state"; 564 list access-point-list { 565 key "access-point-id"; 566 description 567 "access-point identifier"; 568 uses access-point{ 569 description 570 "access-point information"; 571 } 572 } 573 } 574 container vn { 575 description 576 "VN state"; 577 list vn-list { 578 key "vn-id"; 579 description 580 "a virtual network is identified by a vn-id"; 581 leaf vn-id { 582 type uint32; 583 description 584 "a unique vn identifier"; 585 } 586 leaf vn-name { 587 type string; 588 description "vn name"; 589 } 590 list vn-member-list{ 591 key "vn-member-id"; 592 description 593 "List of VN-members in a VN"; 594 uses vn-member; 595 uses connectivity-metric; 596 leaf oper-status { 597 type identityref { 598 base te-types:state-type; 599 } 600 description 601 "VN-member operational state."; 602 } 603 } 605 uses objective-function; 607 leaf admin-status { 608 type identityref { 609 base te-types:state-type; 610 } 611 description "VN administrative state."; 612 } 613 leaf oper-status { 614 type identityref { 615 base te-types:state-type; 616 } 617 description "VN operational state."; 618 } 619 }//vn-list 620 }//vn 621 }//actn-state 622 } 624 626 4. Security Considerations 628 TDB 630 5. IANA Considerations 632 TDB 634 6. Acknowledgments 636 This document was prepared using 2-Word-v2.0.template.dot. 638 7. References 640 7.1. Normative References 642 [ACTN-REQ] Lee, et al., "Requirements for Abstraction and Control of 643 TE Networks", work in progress: draft-ietf-teas-actn- 644 requirements. 646 [ACTN-FWK] D. Ceccarelli, Y. Lee [Editors], "Framework for 647 Abstraction and Control of Traffic Engineered Networks", 648 work in progress: draft-ceccarelli-teas-actn-framework. 650 [TE-TOPO] X. Liu, et al., "YANG Data Model for TE Topologies", work 651 in progress: draft-ietf-teas-yang-te-topo. 653 [TE-tunnel] T. Saad, et al., "A YANG Data Model for Traffic 654 Engineering Tunnels and Interfaces", work in progress: 655 draft-ietf-teas-yang-te. 657 7.2. Informative References 659 8. Contributors 661 Contributor's Addresses 663 Haomian Zheng 664 Huawei Technologies 665 Email: zhenghaomian@huawei.com 667 Xian Zhang 668 Huawei Technologies 669 Email: zhang.xian@huawei.com 671 Sergio Belotti 672 Nokia 673 Email: sergio.belotti@nokia.com 675 Authors' Addresses 677 Young Lee (ed.) 678 Huawei Technologies 679 Email: leeyoung@huawei.com 681 Daniele Ceccarelli 682 Ericsson 683 Torshamnsgatan,48 684 Stockholm, Sweden 685 Email: daniele.ceccarelli@ericsson.com 687 Dhruv Dhoddy 688 Huawei Technologies, 689 Email: dhruv.ietf@gmail.com 691 Takuya Miyasaka 692 KDDI 693 Email: ta-miyasaka@kddi.com 695 Peter Park 696 KT 697 Email: peter.park@kt.com 699 Bin Yeong Yoon 700 ETRI 701 Email: byyun@etri.re.kr