idnits 2.17.1 draft-lee-teas-actn-vn-yang-03.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 33 instances of too long lines in the document, the longest one being 14 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 333 has weird spacing: '...mber-id uin...' == Line 345 has weird spacing: '...ic-type ide...' == Line 372 has weird spacing: '...mber-id uin...' == Line 383 has weird spacing: '...ic-type ide...' == Line 398 has weird spacing: '...ic-type ide...' == (6 more instances...) -- The document date (March 9, 2017) is 2604 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-Frame' is mentioned on line 123, but not defined == Missing Reference: 'ACTN-FW' is mentioned on line 142, but not defined == Missing Reference: 'TE-Tunnel' is mentioned on line 247, but not defined == Unused Reference: 'TE-tunnel' is defined on line 962, but no explicit reference was found in the text == Unused Reference: 'ACTN-REQ' is defined on line 976, but no explicit reference was found in the text == Unused Reference: 'ACTN-FWK' is defined on line 980, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-wu-opsawg-service-model-explained (ref. 'Service-YANG') Summary: 2 errors (**), 0 flaws (~~), 13 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 Young Yoon 11 ETRI 13 Expires: September 9, 2017 March 9, 2017 15 A Yang Data Model for ACTN VN Operation 17 draft-lee-teas-actn-vn-yang-03 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 September 9, 2017. 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. Justification of the ACTN VN Model on the CMI.............7 69 2.2. Multi-sources and multi-destinations......................7 70 3. ACTN VN YANG Model (Tree Structure)............................9 71 4. ACTN-VN YANG Code.............................................12 72 5. Security Considerations.......................................23 73 6. IANA Considerations...........................................23 74 7. Acknowledgments...............................................23 75 8. References....................................................24 76 8.1. Normative References.....................................24 77 8.2. Informative References...................................24 78 9. Contributors..................................................24 79 Authors' Addresses...............................................25 81 1. Introduction 83 This document provides a YANG data model for the Abstraction and 84 Control of Traffic Engineered (TE) networks (ACTN) Virtual Network 85 (VN) operation that is going to be implemented for the Customer 86 Network Controller (CNC)- Multi-Domain Service Coordinator (MSDC) 87 interface (CMI). 89 The YANG model on the CMI is also known as customer service model in 90 [Service-YANG]. The YANG model discussed in this document is used to 91 operate customer-driven VNs during the VN computation, VN 92 instantiation and its life-cycle operations stages. 94 Note that the YANG model presented in this draft has two aspects: 96 - VN pre-instantiation mode of operation (also known as VN compute); 97 - VN instantiation mode of operation. 99 The VN pre-instantiation mode of operation is concerned about 100 service inquiry before making a formal request for VN instantiation. 101 This operation is important for a customer to make sure the network 102 can provide VN services it desires. 104 The VN instantiation mode of operation is concerned about 105 instantiating VNs. In the VN instantiation mode, the CNC provides 106 the VN service definition that includes VN members, VN service 107 objective, VN service policy and preferences, etc. Upon receipt of a 108 VN instantiation request, the MDSC (in coordination with PNCs) 109 executes service request into network operation that include 110 creating tunnels/paths and securing network resources/slices for 111 VNs. 113 The YANG model discussed in this document basically provides the 114 characteristics of VNs such as VN level parameters (e.g., VN ID, VN 115 member, VN objective function, VN service preference, etc.), 116 customer's end point characteristics (e.g., Customer Interface 117 Capability, Access Points Interface characteristics, etc.), and 118 other relevant VN information that needs to be known to the MDSC to 119 facilitate ACTN VN operation. 121 1.1. Terminology 123 Refer to [ACTN-Frame] and [RFC7926] for the key terms used in this 124 document. 126 2. ACTN CMI context 128 The model presented in this document has the following ACTN context. 130 +-------+ 131 | CNC | 132 +-------+ 133 | 134 | <--- CMI (CNC-MDSC Interface) 135 | 136 +-----------------------+ 137 | MDSC | 138 +-----------------------+ 140 Figure 1. ACTN CMI 142 As defined in [ACTN-FW], a Virtual Network is a client view 143 (typically a network slice) of the transport network. It can be 144 presented by the provider as a set of physical and/or abstracted 145 resources. Depending on the agreement between client and provider 146 various VN operations and VN views are possible. 148 a) VN can be seen as an (or set of) e2e tunnel(s) from a customer 149 point of view where an e2e tunnel is referred as a VN member. 150 Each VN member (i.e., e2e tunnel) can then be formed by 151 recursive aggregation of lower level paths at a provider level. 152 Such end to end tunnels may comprise of customer end points, 153 access links, intra domain paths and inter-domain link. In this 154 view VN is thus a list of VN members. 156 b) VN can also be seen as a terms of topology comprising of 157 physical and abstracted nodes and links. The nodes in this case 158 include physical customer end points, border nodes, and 159 internal nodes as well as abstracted nodes. Similarly the links 160 includes physical access, inter-domain and intra-domain links 161 as well as abstracted links. The abstracted nodes and links in 162 this view can be pre-negotiated or created dynamically. 164 For both cases, the CNC can dynamically add VN elements. For case 1, 165 the VN element is an end-to-end tunnel and for case 2, the VN 166 element can be virtual nodes or virtual links. 168 In the subsequent discussion, the first form of VN will be 169 discussed. 171 The following figure describes a VN that comprises three VN members 172 forming a full mesh for the VN as an illustration. 174 VN Member 1 175 |<-------------------------------------->| 176 | | 177 | ------------- | 178 | ( ) | 179 | - - | 180 +---+ X ( Provider ) Z +---+ 181 |CE1|---+----( )---+---|CE2| 182 +---+ AP1 ( Network ) AP2 +---+ 183 .- - - _ -. 184 |\ ( ) /| 185 \ ------------- / 186 \ | / 187 ---- + AP3 ---- 188 VN Member 2 \ | / VN Member 3 189 \ Y | / 190 \ +---+ / 191 `----> |CE3|<----` 192 +---+ 194 Figure 2. Full Mesh Example for a VN 196 In Figure 2, a VN has three members, namely, VN Member 1, VN member 197 2, and VN member 3. VN Member 1 is an end-to-end tunnel identified 198 by CE1-AP1 (source) and CE2-AP2 (destination). Similarly, VN Member 199 2 by CE1-AP1 and CE3-AP3 and VN Member 3 by CE3-AP3 and CE2-AP2. 200 This particular VN shown in Figure 2 is a full mesh connectivity 201 across these three customer end-points. 203 The set of assumptions that applies to this document is the 204 following: 206 - CNC is responsible for providing necessary Customer End-Points 207 information to the MDSC via the CMI. 208 - The access links (between Customer Edge (CE) Devices and the 209 Provider Edge (PE) Devices) are assumed to have been 210 provisioned prior to the VN instantiation request. 211 Access point identifiers have been configured and therefore are 212 known in both the CNC and the MDSC. 214 It is also possible for the customer to create a VN which can be a 215 hub and spoke or any other form of connectivity depending on its 216 connectivity requirement. Each end-to-end tunnel may be 217 unidirectional or bidirectional which is also depending on its 218 connectivity requirements. The following figure shows some examples 219 of a VN that can be represented in a different connectivity form 220 depending on the customer's connectivity requirements. 222 +---+ +---+ +---+ +---+ +---+ +---+ 223 |CE1|---------|CE2| |CE4|---------|CE5| |CE8|---------|CE9| 224 +---+ +---+ +---+ +---+ +---+ +---+ 225 \ / | \ | \ | 226 \ / | \ | \ | 227 \ / | \ | \ | 228 \ / | \ | \ | 229 \ / | \ | \ | 230 \ / | \ | \ | 231 +---+ +---+ +---+ +---+ +---+ 232 |CE3| |CE6| |CE7| |CE6|---------|CE7| 233 +---+ +---+ +---+ +---+ +---+ 235 (a) Full Mesh (b) Hub and Spoke (c) partial Mesh 237 Figure 3. Different Connectivity Forms of a VN 239 It is important to note that a VN can associate a multiple number of 240 end-to-end tunnels (i.e., VN members) with one unique identifier. 241 From a customer standpoint, this simplifies its VN operation 242 significantly. 244 The MDSC interacts with the CNC for the VN operation. Once the 245 customer VN is requested by the CNC to the MDSC, the MDSC shall be 246 responsible for translating and mapping the VN request into specific 247 network centric-models (e.g., TE-tunnels [TE-Tunnel], TE-topology 248 [TE-TOPO], etc.) to coordinate the multi-domain network operations 249 with PNCs. 251 2.1. Justification of the ACTN VN Model on the CMI. 253 1. It binds multiple e2e tunnels as a VN. VN is a unit for 254 concurrency. TE-tunnel model deals each VN member as a separate 255 entity, so it loses concurrent allocation of TE resources. TE- 256 tunnel model is a sequential provisioning approach. 258 2. It is easier for some customers to work on VN level/Network 259 slicing rather than individual TE tunnels. 261 3. ACTN VN supports multi-source and multi-destination which TE- 262 tunnel model does not support. (See Section 2.2 for details) 264 4. ACTN VN supports VN compute (pre-instantiation mode) which TE- 265 tunnel model does not. 267 5. There are certain advantages to keep a set of TE-tunnels as one VN 268 unit for applying policy, reroute, protection, restoration, etc. 269 rather than treating each TE-tunnel as individual unit. 271 2.2. Multi-sources and multi-destinations 273 In creating a virtual network, the list of sources or destinations 274 or both may not be pre-determined by the customer. For instance, for 275 a given source, there may be a list of multiple-destinations to 276 which the optimal destination may be chosen depending on the network 277 resource situations. Likewise, for a given destination, there may 278 also be multiple-sources from which the optimal source may be 279 chosen. In some cases, there may be a pool of multiple sources and 280 destinations from which the optimal source-destination may be 281 chosen. The following YANG module is shown for describing source 282 container and destination container. See details in Section 4. 284 +--rw actn 285 | +--rw vn 286 | +--rw vn-list* [vn-id] 287 | ... 288 | | +--rw src 289 | | | +--rw src? -> /actn/ap/access-point-list/access- 290 point-id 291 | | | +--rw src-vn-ap-id? uint32 292 | | | +--rw multi-src? boolean 293 | | +--rw dest 294 | | +--rw dest? -> /actn/ap/access-point-list/access- 295 point-id 296 | | +--rw dest-vn-ap-id? uint32 297 | | +--rw multi-dest? boolean 299 +--ro actn-state 300 +--ro vn 301 +--ro vn-list* [vn-id] 302 | +--ro src 303 | | +--ro src? -> /actn/ap/access-point-list/access- 304 point-id 305 | | +--ro src-vn-ap-id? uint32 306 | | +--ro multi-src? boolean 307 | +--ro dest 308 | | +--ro dest? -> /actn/ap/access-point-list/access- 309 point-id 310 | | +--ro dest-vn-ap-id? uint32 311 | | +--ro multi-dest? boolean 312 ... 313 +--ro multi-src-dest 314 | +--ro selected-vn-member? -> /actn-state/vn/vn-list/vn-id 316 3. ACTN VN YANG Model (Tree Structure) 318 module: ietf-actn-vn 319 +--rw actn 320 | +--rw ap 321 | | +--rw access-point-list* [access-point-id] 322 | | +--rw access-point-id uint32 323 | | +--rw access-point-name? string 324 | | +--rw src-tp-id? binary 325 | | +--rw dst-tp-id? binary 326 | | +--rw max-bandwidth? tet:te-bandwidth 327 | | +--rw avl-bandwidth? tet:te-bandwidth 328 | +--rw vn 329 | +--rw vn-list* [vn-id] 330 | +--rw vn-id uint32 331 | +--rw vn-name? string 332 | +--rw vn-member-list* [vn-member-id] 333 | | +--rw vn-member-id uint32 334 | | +--rw src 335 | | | +--rw src? -> /actn/ap/access-point-list/access-point-id 336 | | | +--rw src-vn-ap-id? uint32 337 | | | +--rw multi-src? boolean 338 | | +--rw dest 339 | | +--rw dest? -> /actn/ap/access-point-list/access-point- 340 id 341 | | +--rw dest-vn-ap-id? uint32 342 | | +--rw multi-dest? boolean 343 | +--rw objective-function? pcep:objective-function 344 | +--rw metric* [metric-type] 345 | | +--rw metric-type identityref 346 | | +--rw limit 347 | | | +--rw enabled? boolean 348 | | | +--rw value? uint32 349 | | +--rw optimize 350 | | +--rw enabled? boolean 351 | | +--rw value? uint32 352 | +--rw bandwidth? tet:te-bandwidth 353 | +--rw protection? identityref 354 | +--rw local-reroute? boolean 355 | +--rw push-allowed? boolean 356 | +--rw incremental-update? boolean 357 | +--rw admin-status? identityref 358 +--ro actn-state 359 +--ro ap 360 | +--ro access-point-list* [access-point-id] 361 | +--ro access-point-id uint32 362 | +--ro access-point-name? string 363 | +--ro src-tp-id? binary 364 | +--ro dst-tp-id? binary 365 | +--ro max-bandwidth? tet:te-bandwidth 366 | +--ro avl-bandwidth? tet:te-bandwidth 367 +--ro vn 368 +--ro vn-list* [vn-id] 369 +--ro vn-id uint32 370 +--ro vn-name? string 371 +--ro vn-member-list* [vn-member-id] 372 | +--ro vn-member-id uint32 373 | +--ro src 374 | | +--ro src? -> /actn/ap/access-point-list/access-point-id 375 | | +--ro src-vn-ap-id? uint32 376 | | +--ro multi-src? boolean 377 | +--ro dest 378 | | +--ro dest? -> /actn/ap/access-point-list/access-point- 379 id 380 | | +--ro dest-vn-ap-id? uint32 381 | | +--ro multi-dest? boolean 382 | +--ro metric* [metric-type] 383 | | +--ro metric-type identityref 384 | | +--ro limit 385 | | | +--ro enabled? boolean 386 | | | +--ro value? uint32 387 | | +--ro optimize 388 | | +--ro enabled? boolean 389 | | +--ro value? uint32 390 | +--ro oper-status? identityref 391 | +--ro tunnel-ref? te:tunnel-ref 392 +--ro multi-src-dest 393 | +--ro selected-vn-member? -> /actn-state/vn/vn-list/vn-id 394 +--ro vn-topology-ref 395 | +--ro network-ref? -> /nw:networks/network/network-id 396 +--ro objective-function? pcep:objective-function 397 +--ro metric* [metric-type] 398 | +--ro metric-type identityref 399 | +--ro limit 400 | | +--ro enabled? boolean 401 | | +--ro value? uint32 402 | +--ro optimize 403 | +--ro enabled? boolean 404 | +--ro value? uint32 405 +--ro bandwidth? tet:te-bandwidth 406 +--ro protection? identityref 407 +--ro local-reroute? boolean 408 +--ro push-allowed? boolean 409 +--ro incremental-update? boolean 410 +--ro admin-status? identityref 411 +--ro oper-status? identityref 413 rpcs: 414 +---x vn-compute 415 +---w input 416 | +---w vn-member-list* [vn-member-id] 417 | | +---w vn-member-id uint32 418 | | +---w src 419 | | | +---w src? -> /actn/ap/access-point-list/access-point-id 420 | | | +---w src-vn-ap-id? uint32 421 | | | +---w multi-src? boolean 422 | | +---w dest 423 | | +---w dest? -> /actn/ap/access-point-list/access-point-id 424 | | +---w dest-vn-ap-id? uint32 425 | | +---w multi-dest? boolean 426 | +---w objective-function? pcep:objective-function 427 | +---w metric* [metric-type] 428 | | +---w metric-type identityref 429 | | +---w limit 430 | | | +---w enabled? boolean 431 | | | +---w value? uint32 432 | | +---w optimize 433 | | +---w enabled? boolean 434 | | +---w value? uint32 435 | +---w bandwidth? tet:te-bandwidth 436 | +---w protection? identityref 437 | +---w local-reroute? boolean 438 | +---w push-allowed? boolean 439 | +---w incremental-update? boolean 440 +--ro output 441 +--ro vn-member-list* [vn-member-id] 442 | +--ro vn-member-id uint32 443 | +--ro src 444 | | +--ro src? -> /actn/ap/access-point-list/access-point-id 445 | | +--ro src-vn-ap-id? uint32 446 | | +--ro multi-src? boolean 447 | +--ro dest 448 | | +--ro dest? -> /actn/ap/access-point-list/access-point-id 449 | | +--ro dest-vn-ap-id? uint32 450 | | +--ro multi-dest? boolean 451 | +--ro metric* [metric-type] 452 | | +--ro metric-type identityref 453 | | +--ro limit 454 | | | +--ro enabled? boolean 455 | | | +--ro value? uint32 456 | | +--ro optimize 457 | | +--ro enabled? boolean 458 | | +--ro value? uint32 459 | +--ro oper-status? identityref 460 +--ro multi-src-dest 461 +--ro selected-vn-member-id? uint32 463 4. ACTN-VN YANG Code 465 The YANG code is as follows: 467 file "ietf-actn-vn@2017-03-09.yang" 469 module ietf-actn-vn { 471 namespace "urn:ietf:params:xml:ns:yang:ietf-actn-vn"; 472 prefix "vn"; 474 /* Import TE generic types */ 475 import ietf-te-types { 476 prefix "te-types"; 477 } 479 import ietf-te-topology { 480 prefix "tet"; 481 } 483 import ietf-te { 484 prefix "te"; 485 } 487 import ietf-pcep { 488 prefix "pcep"; 489 } 491 organization 492 "IETF Traffic Engineering Architecture and Signaling (TEAS) 493 Working Group"; 495 contact 496 "Editor: Young Lee 497 Editor: Dhruv Dhody "; 499 description 500 "This module contains a YANG module for the ACTN VN. It 501 describes a VN operation module that takes place in the 502 context of the CNC-MDSC Interface (CMI) of the ACTN 503 architecture where the CNC is the actor of a VN Instantiation 504 /modification /deletion."; 506 revision 2017-03-09 { 507 description 508 "initial version."; 509 reference 510 "TBD"; 511 } 513 identity path-metric-delay { 514 base te-types:path-metric-type; 515 description 516 "delay path metric"; 517 } 519 identity path-metric-delay-variation { 520 base te-types:path-metric-type; 521 description 522 "delay-variation path metric"; 523 } 525 identity path-metric-loss { 526 base te-types:path-metric-type; 527 description 528 "loss path metric"; 529 } 531 /* 532 * Groupings 533 */ 535 grouping access-point{ 536 description 537 "AP related information"; 538 leaf access-point-id { 539 type uint32; 540 description 541 "unique identifier for the referred 542 access point"; 543 } 544 leaf access-point-name { 545 type string; 546 description 547 "ap name"; 548 } 549 /*using direct tp-id for now as per ietf-te 550 should check if reference is better*/ 551 leaf src-tp-id { 552 type binary; 553 description 554 "TE tunnel source termination point identifier."; 555 } 556 leaf dst-tp-id { 557 type binary; 558 description 559 "TE tunnel destination termination point identifier."; 560 } 561 leaf max-bandwidth { 562 type tet:te-bandwidth; 563 description 564 "max bandwidth of the AP"; 565 } 566 leaf avl-bandwidth { 567 type tet:te-bandwidth; 568 description 569 "available bandwidth of the AP"; 570 } 571 /*add details and any other properties of AP, 572 not associated by a VN 573 CE port, PE port etc. 575 */ 576 }//access-point 578 grouping vn-member { 579 description 580 "vn-member is described by this container"; 581 leaf vn-member-id { 582 type uint32; 583 description 584 "vn-member identifier"; 585 } 586 container src 587 { 588 description 589 "the source of VN Member"; 590 leaf src { 591 type leafref { 592 path "/actn/ap/access-point-list/access-point-id"; 593 } 594 description 595 "reference to source AP"; 596 } 597 leaf src-vn-ap-id{ 598 type uint32; 599 description 601 "vn-ap-id"; 602 } 603 leaf multi-src { 604 type boolean; 605 description 606 "Is source part of multi-source, where 607 only one of the source is enabled"; 608 } 609 } 610 container dest 611 { 612 description 613 "the destination of VN Member"; 614 leaf dest { 615 type leafref { 616 path "/actn/ap/access-point-list/access-point-id"; 617 } 618 description 619 "reference to destination AP"; 620 } 621 leaf dest-vn-ap-id{ 622 type uint32; 623 description 624 "vn-ap-id"; 625 } 626 leaf multi-dest { 627 type boolean; 628 description 629 "Is destination part of multi-destination, where 630 only one of the destination is enabled"; 631 } 632 } 633 }//vn-member 635 grouping policy { 636 description 637 "policy related to vn-member-id"; 638 leaf local-reroute { 639 type boolean; 640 description 641 "Policy to state if reroute 642 can be done locally"; 643 } 644 leaf push-allowed { 645 type boolean; 646 description 647 "Policy to state if changes 648 can be pushed to the customer"; 649 } 650 leaf incremental-update { 651 type boolean; 652 description 653 "Policy to allow only the 654 changes to be reported"; 655 } 656 }//policy 658 grouping metrics { 659 description 660 "metric related information"; 661 list metric{ 662 key "metric-type"; 663 description 664 "The list of metrics for VN"; 665 leaf metric-type { 666 type identityref { 667 base te-types:path-metric-type; 668 } 669 description 670 "The VN metric type."; 671 } 672 container limit { 673 description 674 "Limiting contraints"; 675 leaf enabled{ 676 type boolean; 677 description 678 "Limit contraint is enabled"; 679 } 680 leaf value{ 681 type uint32; 682 description 683 "The limit value"; 684 } 685 } 686 container optimize{ 687 description 688 "optimizing constraints"; 689 leaf enabled{ 690 type boolean; 691 description 692 "Metric to optimize"; 693 } 694 leaf value{ 695 type uint32; 696 description 697 "The computed value"; 698 } 699 } 700 } 702 } 704 grouping service-metric { 705 description 706 "service-metric"; 707 leaf objective-function { 708 type pcep:objective-function; 709 description 710 "operational state of the objective function"; 711 } 713 uses metrics; 715 leaf bandwidth { 716 type tet:te-bandwidth; 717 description 718 "bandwidth requested/required for 719 vn-member-id"; 720 } 722 leaf protection { 723 type identityref { 724 base te-types:lsp-prot-type; 725 } 726 description "protection type."; 727 } 729 uses policy; 731 }//service-metric 733 /* 734 * Configuration data nodes 735 */ 736 container actn { 737 description 738 "actn is described by this container"; 739 container ap { 740 description 741 "AP configurations"; 742 list access-point-list { 743 key "access-point-id"; 744 description 745 "access-point identifier"; 746 uses access-point{ 747 description 748 "access-point information"; 749 } 750 } 751 } 752 container vn { 753 description 754 "VN configurations"; 756 list vn-list { 757 key "vn-id"; 758 description 759 "a virtual network is identified by a vn-id"; 760 leaf vn-id { 761 type uint32; 762 description 763 "a unique vn identifier"; 764 } 765 leaf vn-name { 766 type string; 767 description "vn name"; 768 } 769 list vn-member-list{ 770 key "vn-member-id"; 771 description 772 "List of VN-members in a VN"; 773 uses vn-member; 774 } 775 uses service-metric; 777 leaf admin-status { 778 type identityref { 779 base te-types:state-type; 780 } 781 default te-types:state-up; 782 description "VN administrative state."; 783 } 785 }//vn-list 787 }//vn 788 }//actn 790 /* 791 * Operational data nodes 792 */ 794 container actn-state{ 795 config false; 797 description 798 "actn is described by this container"; 800 container ap { 801 description 802 "AP state"; 803 list access-point-list { 804 key "access-point-id"; 805 description 806 "access-point identifier"; 807 uses access-point{ 808 description 809 "access-point information"; 810 } 811 } 812 } 813 container vn { 814 description 815 "VN state"; 816 list vn-list { 817 key "vn-id"; 818 description 819 "a virtual network is identified by a vn-id"; 820 leaf vn-id { 821 type uint32; 822 description 823 "a unique vn identifier"; 824 } 825 leaf vn-name { 826 type string; 827 description "vn name"; 828 } 829 list vn-member-list{ 830 key "vn-member-id"; 831 description 832 "List of VN-members in a VN"; 833 uses vn-member; 834 uses metrics; 835 leaf oper-status { 836 type identityref { 837 base te-types:state-type; 838 } 839 description 841 "VN-member operational state."; 842 } 843 leaf tunnel-ref { 844 type te:tunnel-ref; 845 description 846 "A reference to the TE tunnel 847 in the TE model"; 848 } 849 } 850 container multi-src-dest{ 851 description 852 "The selected VN Member when multi-src 853 and/or mult-destination is enabled."; 854 leaf selected-vn-member{ 855 type leafref { 856 path "/actn-state/vn/vn-list/vn-id"; 857 } 858 description 859 "The selected VN Member along the set 860 of source and destination configured 861 with multi-source and/or multi-destination"; 862 } 863 } 864 container vn-topology-ref{ 865 description 866 "An optional reference to the TE Topology 867 Model where the abstract nodes and links 868 of the Topology can be found"; 869 uses tet:te-topology-ref; 870 } 872 uses service-metric; 874 leaf admin-status { 875 type identityref { 876 base te-types:state-type; 878 } 879 description "VN administrative state."; 880 } 881 leaf oper-status { 882 type identityref { 883 base te-types:state-type; 884 } 885 description "VN operational state."; 886 } 888 }//vn-list 889 }//vn 890 }//actn-state 891 /* 892 * Notifications - TBD 893 */ 894 /* 895 * RPC 896 */ 897 rpc vn-compute{ 898 description 899 "The VN computation without actual 900 instantiation"; 901 input { 902 list vn-member-list{ 903 key "vn-member-id"; 904 description 905 "List of VN-members in a VN"; 906 uses vn-member; 907 } 908 uses service-metric; 909 } 910 output { 911 list vn-member-list{ 912 key "vn-member-id"; 913 description 914 "List of VN-members in a VN"; 915 uses vn-member; 916 uses metrics; 917 leaf oper-status { 918 type identityref { 919 base te-types:state-type; 920 } 921 description 922 "VN-member operational state."; 924 } 925 } 926 container multi-src-dest{ 927 description 928 "The selected VN Member when multi-src 929 and/or mult-destination is enabled."; 930 leaf selected-vn-member-id{ 931 type uint32; 932 description 933 "The selected VN Member-id from the 934 input"; 935 } 936 } 937 } 938 } 939 } 941 943 5. Security Considerations 945 TDB 947 6. IANA Considerations 949 TDB 951 7. Acknowledgments 953 This document was prepared using 2-Word-v2.0.template.dot. 955 8. References 957 8.1. Normative References 959 [TE-TOPO] X. Liu, et al., "YANG Data Model for TE Topologies", work 960 in progress: draft-ietf-teas-yang-te-topo. 962 [TE-tunnel] T. Saad, et al., "A YANG Data Model for Traffic 963 Engineering Tunnels and Interfaces", work in progress: 964 draft-ietf-teas-yang-te. 966 [Service-YANG] Q. Wu, W. Liu and A. Farrel, "Service Models 967 Explained", draft-wu-opsawg-service-model-explained, work 968 in progress. 970 8.2. Informative References 972 [RFC7926] A. Farrel (Ed.), "Problem Statement and Architecture for 973 Information Exchange between Interconnected Traffic- 974 Engineered Networks", RFC 7926, July 2016. 976 [ACTN-REQ] Lee, et al., "Requirements for Abstraction and Control of 977 TE Networks", work in progress: draft-ietf-teas-actn- 978 requirements. 980 [ACTN-FWK] D. Ceccarelli, Y. Lee [Editors], "Framework for 981 Abstraction and Control of Traffic Engineered Networks", 982 work in progress: draft-ceccarelli-teas-actn-framework. 984 9. Contributors 986 Contributor's Addresses 988 Haomian Zheng 989 Huawei Technologies 990 Email: zhenghaomian@huawei.com 992 Xian Zhang 993 Huawei Technologies 994 Email: zhang.xian@huawei.com 995 Sergio Belotti 996 Nokia 997 Email: sergio.belotti@nokia.com 999 Authors' Addresses 1001 Young Lee (ed.) 1002 Huawei Technologies 1003 Email: leeyoung@huawei.com 1005 Dhruv Dhody 1006 Huawei Technologies 1007 Email: dhruv.ietf@gmail.com 1009 Daniele Ceccarelli 1010 Ericsson 1011 Torshamnsgatan,48 1012 Stockholm, Sweden 1013 Email: daniele.ceccarelli@ericsson.com 1015 Takuya Miyasaka 1016 KDDI 1017 Email: ta-miyasaka@kddi.com 1019 Peter Park 1020 KT 1021 Email: peter.park@kt.com 1023 Bin Yeong Yoon 1024 ETRI 1025 Email: byyun@etri.re.kr