idnits 2.17.1 draft-lee-teas-actn-vn-yang-01.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 13 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 -- The document date (July 20, 2016) is 2837 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 232, but not defined == Unused Reference: 'TE-tunnel' is defined on line 665, 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: 3 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 20, 2017 July 20, 2016 16 A Yang Data Model for ACTN VN Operation 18 draft-lee-teas-actn-vn-yang-01.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 20, 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). 153 1. A VN may comprise a set of end-to-end tunnels from a customer 154 point of view that connects customer endpoints (i.e., source CE 155 and destination CE). See Figure 3 for this VN type. 157 2. A VN may comprise of a number of virtual nodes and virtual links 158 (more than a tunnel). 160 For both cases, the CNC can dynamically add VN elements. For case 1, 161 the VN element is an end-to-end tunnel and for case 2, the VN 162 element can be virtual nodes or virtual links. 164 In the subsequent discussion, the first form of VN will be 165 discussed. 167 The following figure describes a VN that comprises three VN members 168 forming a full mesh for the VN as an illustration. 170 VN Member 1 171 |<-------------------------------------->| 172 | | 173 | ------------- | 174 | ( ) | 175 | - - | 176 +---+ X ( Provider ) Z +---+ 177 |CE1|---+----( )---+---|CE2| 178 +---+ AP1 ( Network ) AP2 +---+ 179 .- - - _ -. 180 |\ ( ) /| 181 \ ------------- / 182 \ | / 183 ---- + AP3 ---- 184 VN Member 2 \ | / VN Member 3 185 \ Y | / 186 \ +---+ / 187 `----> |CE3|<----` 188 +---+ 190 Figure 2. Full Mesh Example for a VN 192 In Figure 2, a VN has three members, namely, VN Member 1, VN member 193 2, and VN member 3. VN Member 1 is an end-to-end tunnel identified 194 by CE1-AP1 (source) and CE2-AP2 (destination). Similarly, VN Member 195 2 by CE1-AP1 and CE3-AP3 and VN Member 3 by CE3-AP3 and CE2-AP2. 196 This particular VN shown in Figure 2 is a full mesh connectivity 197 across these three customer end-points. 199 It is also possible for the customer to create a VN which can be a 200 hub and spoke or any other form of connectivity depending on its 201 connectivity requirement. Each end-to-end tunnel may be 202 unidirectional or bidirectional which is also depending on its 203 connectivity requirements. The following figure shows some examples 204 of a VN that can represented in a different connectivity form 205 depending on the customer's connectivity requirements. 207 +---+ +---+ +---+ +---+ +---+ +---+ 208 |CE1|---------|CE2| |CE4|---------|CE5| |CE8|---------|CE9| 209 +---+ +---+ +---+ +---+ +---+ +---+ 210 \ / | \ | \ | 211 \ / | \ | \ | 212 \ / | \ | \ | 213 \ / | \ | \ | 214 \ / | \ | \ | 215 \ / | \ | \ | 216 +---+ +---+ +---+ +---+ +---+ 217 |CE3| |CE6| |CE7| |CE6|---------|CE7| 218 +---+ +---+ +---+ +---+ +---+ 220 (a) Full Mesh (b) Hub and Spoke (c) partial Mesh 222 Figure 3. Different Connectivity Forms of a VN 224 It is important to note that a VN can associate a multiple number of 225 end-to-end tunnels (i.e., VN members) with one unique identifier. 226 From a customer standpoint, this simplifies its VN operation 227 significantly. 229 The MDSC interacts with the CNC for the VN operation. Once the 230 customer VN is requested by the CNC to the MDSC, the MDSC shall be 231 responsible for translating and mapping the VN request into specific 232 network centric-models (e.g., TE-tunnels [TE-Tunnel], TE-topology 233 [TE-TOPO], etc.) to coordinate the multi-domain network operations 234 with PNCs. The mapping and translation of a VN into network-centric 235 models is out of the scope of this document. 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. 248 2. ACTN VN YANG Model (Tree Structure) 250 module: ietf-actn-vn 251 +--rw actn 252 | +--rw ap 253 | | +--rw access-point-list* [access-point-id] 254 | | +--rw access-point-id uint32 255 | | +--rw access-point-name? string 256 | | +--rw max-bandwidth? decimal64 257 | | +--rw avl-bandwidth? decimal64 258 | +--rw vn 259 | +--rw vn-list* [vn-id] 260 | +--rw vn-id uint32 261 | +--rw vn-name? string 262 | +--rw vn-member-list* [vn-member-id] 263 | | +--rw vn-member-id uint32 264 | | +--rw src? leafref 265 | | +--rw src-vn-ap-id? uint32 266 | | +--rw dest? leafref 267 | | +--rw dest-vn-ap-id? uint32 268 | +--rw delay? uint32 269 | +--rw delay-variation? uint32 270 | +--rw packet-loss? decimal64 271 | +--rw bandwidth? decimal64 272 | +--rw protection? identityref 273 | +--rw local-reroute? boolean 274 | +--rw push-allowed? boolean 275 | +--rw incremental-update? boolean 276 | +--rw admin-status? identityref 277 +--ro actn-state 278 +--ro ap 279 | +--ro access-point-list* [access-point-id] 280 | +--ro access-point-id uint32 281 | +--ro access-point-name? string 282 | +--ro max-bandwidth? decimal64 283 | +--ro avl-bandwidth? decimal64 284 +--ro vn 285 +--ro vn-list* [vn-id] 286 +--ro vn-id uint32 287 +--ro vn-name? string 288 +--ro vn-member-list* [vn-member-id] 289 | +--ro vn-member-id uint32 290 | +--ro src? leafref 291 | +--ro src-vn-ap-id? uint32 292 | +--ro dest? leafref 293 | +--ro dest-vn-ap-id? uint32 294 | +--ro delay? uint32 295 | +--ro delay-variation? uint32 296 | +--ro packet-loss? decimal64 297 | +--ro oper-status? identityref 298 +--ro delay? uint32 299 +--ro delay-variation? uint32 300 +--ro packet-loss? decimal64 301 +--ro bandwidth? decimal64 302 +--ro protection? identityref 303 +--ro local-reroute? boolean 304 +--ro push-allowed? boolean 305 +--ro incremental-update? boolean 306 +--ro admin-status? identityref 307 +--ro oper-status? Identityref 309 3. ACTN-VN YANG Code 311 The YANG code is as follows: 313 file ietf-actn-vn@2016-7-5.yang 315 module ietf-actn-vn { 317 namespace "urn:ietf:params:xml:ns:yang:ietf-actn-vn"; 319 prefix "vn"; 321 /* Import TE generic types */ 322 import ietf-te-types { 323 prefix "te-types"; 324 } 325 organization 326 "IETF Traffic Engineering Architecture and Signaling (TEAS) 327 Working Group"; 329 contact 330 "Editor: Young Lee "; 332 description 333 "This module contains a YANG module for the ACTN VN. It 334 describes a VN operation module that takes place in the 335 context of the CNC-MDSC Interface (CMI) of the ACTN 336 architecture where the CNC is the actor of a VN creation 337 /modification /deletion."; 339 revision 2016-07-05 { 340 description 341 "initial version."; 342 reference 343 "TBD"; 344 } 346 /* 347 * Groupings 348 */ 350 grouping access-point{ 351 description 352 "AP related information"; 353 leaf access-point-id { 354 type uint32; 355 description 356 "unique identifier for the referred 357 access point"; 358 } 359 leaf access-point-name { 360 type string; 361 description 362 "ap name"; 363 } 364 leaf max-bandwidth { 365 type decimal64 { 366 fraction-digits 2; 367 range "0..max"; 368 } 369 description 370 "max bandwidth of the AP"; 371 } 372 leaf avl-bandwidth { 373 type decimal64 { 374 fraction-digits 2; 375 range "0..max"; 376 } 377 description 378 "available bandwidth of the AP"; 379 } 380 /*add details and any other properties of AP, 381 not associated by a VN 382 CE port, PE port etc. 384 This link may not be in the TE topology model(?) 385 thus reference to that model would be incorrect 386 */ 387 }//access-point 389 grouping vn-member { 390 description 391 "vn-member is described by this container"; 392 leaf vn-member-id { 393 type uint32; 394 description 395 "vn-member identifier"; 396 } 397 leaf src { 398 type leafref { 399 path "/actn/ap/access-point-list/access-point-id"; 400 } 401 description 402 "reference to source AP"; 403 } 404 leaf src-vn-ap-id{ 405 type uint32; 406 description 407 "vn-ap-id"; 408 } 409 leaf dest { 410 type leafref { 411 path "/actn/ap/access-point-list/access-point-id"; 412 } 413 description 414 "reference to destination AP"; 415 } 416 leaf dest-vn-ap-id{ 417 type uint32; 418 description 419 "vn-ap-id"; 420 } 422 /* can we add reference to itef-te model(?) here 423 */ 425 }//vn-member 427 grouping connectivity-metric { 428 description 429 "service aware metrics"; 430 leaf delay { 431 type uint32 { 432 range "0..max"; 433 } 434 description 435 "Path Delay or latency in micro seconds."; 436 } 437 leaf delay-variation { 438 type uint32 { 439 range "0..max"; 440 } 441 description 442 "Path Delay variation in micro seconds."; 443 } 444 leaf packet-loss { 445 type decimal64 { 446 fraction-digits 6; 447 range "0 .. max"; 449 } 450 description 451 "Path Packet Loss in percentage"; 452 } 453 /*should we add other metrics 454 like bandwidth utilization?*/ 456 }//connectivity-metric 458 grouping policy { 459 description 460 "policy related to vn-member-id"; 461 leaf local-reroute { 462 type boolean; 463 description 464 "Policy to state if reroute 465 can be done locally"; 466 } 467 leaf push-allowed { 468 type boolean; 469 description 470 "Policy to state if changes 471 can be pushed to the customer"; 472 } 473 leaf incremental-update { 474 type boolean; 475 description 476 "Policy to allow only the 477 changes to be reported"; 478 } 479 }//policy 481 grouping objective-function { 482 description 483 "objective-function"; 485 uses connectivity-metric; 487 leaf bandwidth { 488 type decimal64 { 489 fraction-digits 2; 490 range "0..max"; 491 } 492 description 493 "bandwidth requested/required for 494 vn-member-id"; 495 } 497 leaf protection { 498 type identityref { 499 base te-types:lsp-prot-type; 500 } 501 description "protection type."; 502 } 504 uses policy; 506 }//objective-function 508 /* 509 * Configuration data nodes 510 */ 511 container actn { 512 description 513 "actn is described by this container"; 514 container ap { 515 description 516 "AP configurations"; 517 list access-point-list { 518 key "access-point-id"; 519 description 520 "access-point identifier"; 521 uses access-point{ 522 description 523 "access-point information"; 524 } 525 } 526 } 527 container vn { 528 description 529 "VN configurations"; 531 list vn-list { 532 key "vn-id"; 533 description 534 "a virtual network is identified by a vn-id"; 535 leaf vn-id { 536 type uint32; 537 description 538 "a unique vn identifier"; 539 } 540 leaf vn-name { 541 type string; 542 description "vn name"; 543 } 544 list vn-member-list{ 545 key "vn-member-id"; 546 description 547 "List of VN-members in a VN"; 548 uses vn-member; 549 } 550 uses objective-function; 552 leaf admin-status { 553 type identityref { 554 base te-types:state-type; 555 } 556 default te-types:state-up; 557 description "VN administrative state."; 558 } 559 }//vn-list 560 }//vn 561 }//actn 563 /* 564 * Operational data nodes 565 */ 567 container actn-state{ 568 config false; 570 description 571 "actn is described by this container"; 573 container ap { 574 description 575 "AP state"; 576 list access-point-list { 577 key "access-point-id"; 578 description 579 "access-point identifier"; 580 uses access-point{ 581 description 582 "access-point information"; 583 } 584 } 585 } 586 container vn { 587 description 588 "VN state"; 589 list vn-list { 590 key "vn-id"; 591 description 592 "a virtual network is identified by a vn-id"; 593 leaf vn-id { 594 type uint32; 595 description 596 "a unique vn identifier"; 597 } 598 leaf vn-name { 599 type string; 600 description "vn name"; 601 } 602 list vn-member-list{ 603 key "vn-member-id"; 604 description 605 "List of VN-members in a VN"; 606 uses vn-member; 607 uses connectivity-metric; 608 leaf oper-status { 609 type identityref { 610 base te-types:state-type; 611 } 612 description 613 "VN-member operational state."; 614 } 615 } 617 uses objective-function; 619 leaf admin-status { 620 type identityref { 621 base te-types:state-type; 622 } 623 description "VN administrative state."; 624 } 625 leaf oper-status { 626 type identityref { 627 base te-types:state-type; 628 } 629 description "VN operational state."; 630 } 631 }//vn-list 632 }//vn 633 }//actn-state 634 } 636 638 4. Security Considerations 640 TDB 642 5. IANA Considerations 644 TDB 646 6. Acknowledgments 648 This document was prepared using 2-Word-v2.0.template.dot. 650 7. References 652 7.1. Normative References 654 [ACTN-REQ] Lee, et al., "Requirements for Abstraction and Control of 655 TE Networks", work in progress: draft-ietf-teas-actn- 656 requirements. 658 [ACTN-FWK] D. Ceccarelli, Y. Lee [Editors], "Framework for 659 Abstraction and Control of Traffic Engineered Networks", 660 work in progress: draft-ceccarelli-teas-actn-framework. 662 [TE-TOPO] X. Liu, et al., "YANG Data Model for TE Topologies", work 663 in progress: draft-ietf-teas-yang-te-topo. 665 [TE-tunnel] T. Saad, et al., "A YANG Data Model for Traffic 666 Engineering Tunnels and Interfaces", work in progress: 667 draft-ietf-teas-yang-te. 669 7.2. Informative References 671 8. Contributors 673 Contributor's Addresses 675 Haomian Zheng 676 Huawei Technologies 677 Email: zhenghaomian@huawei.com 679 Xian Zhang 680 Huawei Technologies 681 Email: zhang.xian@huawei.com 683 Sergio Belotti 684 Nokia 685 Email: sergio.belotti@nokia.com 687 Authors' Addresses 689 Young Lee (ed.) 690 Huawei Technologies 691 Email: leeyoung@huawei.com 693 Daniele Ceccarelli 694 Ericsson 695 Torshamnsgatan,48 696 Stockholm, Sweden 697 Email: daniele.ceccarelli@ericsson.com 699 Dhruv Dhoddy 700 Huawei Technologies, 701 Email: dhruv.ietf@gmail.com 703 Takuya Miyasaka 704 KDDI 705 Email: ta-miyasaka@kddi.com 707 Peter Park 708 KT 709 Email: peter.park@kt.com 711 Bin Yeong Yoon 712 ETRI 713 Email: byyun@etri.re.kr