idnits 2.17.1 draft-lee-teas-actn-pm-telemetry-autonomics-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 2 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 345 has weird spacing: '...lemetry xmlns...' == Line 373 has weird spacing: '... rw for c...' == Line 374 has weird spacing: '... ro for n...' == Line 410 has weird spacing: '...ce-type ide...' == Line 417 has weird spacing: '...ce-type ide...' == (2 more instances...) -- The document date (July 3, 2017) is 2490 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ACTN-Applicability' is mentioned on line 111, but not defined == Missing Reference: 'I-D.ietf-netconf-yang-push' is mentioned on line 284, but not defined == Missing Reference: 'I-D.ietf-netconf-rfc5277bis' is mentioned on line 285, but not defined == Missing Reference: 'I-D.ietf-netmod-rfc6087bis' is mentioned on line 364, but not defined ** Obsolete undefined reference: RFC 6087 (Obsoleted by RFC 8407) == Missing Reference: 'RFC6241' is mentioned on line 978, but not defined == Missing Reference: 'RFC6536' is mentioned on line 979, but not defined ** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341) == Unused Reference: 'RFC4110' is defined on line 997, but no explicit reference was found in the text == Unused Reference: 'Netconf' is defined on line 1013, but no explicit reference was found in the text == Unused Reference: 'Restconf' is defined on line 1017, but no explicit reference was found in the text == Unused Reference: 'ACTN-Frame' is defined on line 1022, but no explicit reference was found in the text == Unused Reference: 'TE-Topology' is defined on line 1026, but no explicit reference was found in the text == Unused Reference: 'TE-Tunnel' is defined on line 1029, but no explicit reference was found in the text == Unused Reference: 'L3SM-YANG' is defined on line 1036, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-teas-actn-framework (ref. 'ACTN-Frame') ** Downref: Normative reference to an Proposed Standard draft: draft-ietf-teas-yang-te-topo (ref. 'TE-Topology') ** Downref: Normative reference to an Proposed Standard draft: draft-ietf-teas-yang-te (ref. 'TE-Tunnel') ** Downref: Normative reference to an Proposed Standard draft: draft-lee-teas-actn-vn-yang (ref. 'ACTN-VN-YANG') ** Downref: Normative reference to an Proposed Standard draft: draft-ietf-l3sm-l3vpn-service-model (ref. 'L3SM-YANG') ** Downref: Normative reference to an Proposed Standard draft: draft-ietf-pce-pcep-service-aware (ref. 'PCEP-Service-Aware') -- Possible downref: Normative reference to a draft: ref. 'ACTN-PERF' Summary: 9 errors (**), 0 flaws (~~), 20 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS WG Young Lee 2 Internet Draft Dhruv Dhody 3 Intended Status: standard Satish Karunanithi 4 Huawei 5 Ricard Vilalta 6 CTTC 7 Daniel King 8 Lancaster University 9 Daniele Ceccarelli 10 Ericsson 12 Expires: January 2, 2018 14 July 3, 2017 16 YANG models for ACTN TE Performance Monitoring Telemetry and Network 17 Autonomics 19 draft-lee-teas-actn-pm-telemetry-autonomics-03 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with 24 the provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as 34 reference material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on January 3, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with 54 respect to this document. Code Components extracted from this 55 document must include Simplified BSD License text as described in 56 Section 4.e of the Trust Legal Provisions and are provided without 57 warranty as described in the Simplified BSD License. 59 Abstract 61 Abstraction and Control of TE Networks (ACTN) refers to the set of 62 virtual network operations needed to operate, control and manage 63 large-scale multi-domain, multi-layer and multi-vendor TE networks, 64 so as to facilitate network programmability, automation, efficient 65 resource sharing. 67 This document provides YANG data models that describe Key 68 Performance Indicator (KPI) telemetry and network autonomics for TE- 69 tunnels and ACTN VNs. 71 Table of Contents 73 1. Introduction...................................................3 74 2. Use-Cases......................................................3 75 3. Design of the Data Models......................................5 76 TE KPI Telemetry Model.........................................6 77 ACTN TE KPI Telemetry Model....................................7 78 4. Notification...................................................8 79 YANG Push Subscription Examples................................8 80 5. YANG Data Tree................................................10 81 6. Yang Data Model...............................................12 82 ietf-te-kpi-telemetry model...................................12 83 ietf-actn-te-kpi-telemetry model..............................19 84 7. Security Considerations.......................................23 85 8. IANA Considerations...........................................23 86 9. Acknowledgements..............................................23 87 10. References...................................................23 88 Informative References........................................23 89 Normative References..........................................24 90 11. Contributors.................................................24 91 Authors' Addresses...............................................25 93 1. Introduction 95 Abstraction and Control of TE Networks (ACTN) describes a method for 96 operating a Traffic Engineered (TE) network (such as an MPLS-TE 97 network or a layer 1/0 transport network) to provide connectivity 98 and virtual network services for customers of the TE network [ACTN- 99 Frame]. The services provided can be optimized to meet the 100 requirements (such as traffic patterns, quality, and reliability) of 101 the applications hosted by the customers. Data models are a 102 representation of objects that can be configured or monitored within 103 a system. Within the IETF, YANG [RFC6020] is the language of choice 104 for documenting data models, and YANG models have been produced to 105 allow configuration or modeling of a variety of network devices, 106 protocol instances, and network services. YANG data models have been 107 classified in [Netmod-Yang-Model-Classification] and [Service-YANG]. 109 [ACTN-VN-YANG] describes how customers or end to end orchestrators 110 can request and/or instantiate a generic virtual network service. 111 [ACTN-Applicability] describes a connection between IETF YANG model 112 classifications to ACTN interfaces. In particular, it describes the 113 customer service model can be mapped into the CMI (CNC-MDSC 114 Interface) of the ACTN architecture. 116 The YANG model on the ACTN CMI is known as customer service model in 117 [Service-YANG]. [PCEP-Service-Aware] describes key network 118 performance data to be considered for end-to-end path computation in 119 TE networks. Key performance indicator is a term that describes 120 critical performance data that may affect VN/TE service. 122 2. Use-Cases 124 [ACTN-PERF] describes use-cases relevant to this draft. It 125 introduces the dynamic creation, modification and optimization of 126 services based on the performance monitoring in the Abstraction and 127 Control of Transport Networks (ACTN) architecture. Figure 1 shows a 128 high-level workflows for dynamic service control based on traffic 129 monitoring. 131 Some of the key points from [ACTN-PERF] are as follows: 133 . Network traffic monitoring is important to facilitate automatic 134 discovery of the imbalance of network traffic, and initiate the 135 network optimization, thus helping the network operator or the 136 virtual network service provider to use the network more 137 efficiently and save CAPEX/OPEX. 138 . Customer services have various SLA requirements, such as 139 service availability, latency, latency jitter, packet loss 140 rate, BER, etc. The transport network can satisfy service 141 availability and BER requirements by providing different 142 protection and restoration mechanisms. However, for other 143 performance parameters, there are no such mechanisms. In order 144 to provide high quality services according to customer SLA, one 145 possible solution is to measure the service SLA related 146 performance parameters, and dynamically provision and optimize 147 services based on the performance monitoring results. 148 . Performance monitoring in a large scale network could generate 149 a huge amount of performance information. Therefore, the 150 appropriate way to deliver the information in CMI and MPI 151 interfaces should be carefully considered. 153 +-------------------------------------------+ 154 | CNC +-----------------------------+ | 155 | | Dynamic Service Control APP | | 156 | +-----------------------------+ | 157 +-------------------------------------------+ 158 1.Traffic| /|\4.Traffic | /|\ 159 Monitor& | | Monitor | | 8.Traffic 160 Optimize | | Result 5.Service | | modify & 161 Policy | | modify& | | optimize 162 \|/ | optimize Req.\|/ | result 163 +------------------------------------------------+ 164 | MDSC +-------------------------------+ | 165 | |Dynamic Service Control Agent | | 166 | +-------------------------------+ | 167 | +---------------+ +-------------------+ | 168 | | Flow Optimize | | vConnection Agent | | 169 | +---------------+ +-------------------+ | 170 +------------------------------------------------+ 171 2. Path | /|\3.Traffic | | 172 Monitor | | Monitor | |7.Path 173 Request | | Result 6.Path | | modify & 174 | | modify& | | optimize 175 \|/ | optimize Req.\|/ | result 176 +-------------------------------------------------------+ 177 | PNC +----------------------+ +----------------------+ | 178 | | Network Provisioning | |Abstract Topology Gen.| | 179 | +----------------------+ +----------------------+ | 180 | +------------------+ +--------------------+ | 181 | |Network Monitoring| |Physical Topology DB| | 182 | +------------------+ +--------------------+ | 183 +-------------------------------------------------------+ 185 Figure 1 Workflows for dynamic service control based on traffic 186 monitoring 188 3. Design of the Data Models 190 The YANG models developed in this document describe two models: 192 (i) TE KPI Telemetry Model which provides the TE-Tunnel level of 193 performance monitoring mechanism (See Section 2.1 for 194 details) 196 (ii) ACTN TE KPI Telemetry Model which provides the VN level of the 197 aggregated performance monitoring mechanism (See Section 2.2 198 for details) 200 The models include - 202 (i) Performance Telemetry details as measured during the last 203 interval, ex delay. 205 (ii) Scaling Intent based on with TE/VN could be scaled in/out. 207 [Editor's Note - Need to decide if scaling and telemetry can be in 208 the same model as per the current draft.] 210 TE KPI Telemetry Model 212 This module describes performance telemetry for TE-tunnel model. The 213 telemetry data is augmented to tunnel state. This module also 214 allows autonomic traffic engineering scaling intent configuration 215 mechanism on the TE-tunnel level. Various conditions can be set for 216 auto-scaling based on the telemetry data. 218 The TE KPI Telemetry Model augments the TE-Tunnel Model to enhance 219 TE performance monitoring capability. This monitoring capability 220 will facilitate proactive re-optimization and reconfiguration of TEs 221 based on the performance monitoring data collected via the TE KPI 222 Telemetry YANG model. 224 +------------+ +--------------+ 225 | TE-Tunnel | | TE KPI | 226 | Model |<---------| Telemetry | 227 +------------+ augments | Model | 228 +--------------+ 230 ACTN TE KPI Telemetry Model 232 This module describes performance telemetry for ACTN VN model. The 233 telemetry data is augmented both at the VN Level as well as 234 individual VN member level. This module also allows autonomic 235 traffic engineering scaling intent configuration mechanism on the VN 236 level. Scale in/out criteria might be used for network autonomics in 237 order the controller to react to a certain set of variations in 238 monitored parameters. 240 Moreover, this module also provides mechanism to define aggregated 241 telemetry parameters as a grouping of underlying VN level telemetry 242 parameters. Grouping operation (such as maximum, mean) could be set 243 at the time of configuration. For example, if maximum grouping 244 operation is used for delay at the VN level, the VN telemetry data 245 is reported as the maximum {delay_vn_member_1, delay_vn_member_2, .. 246 delay_vn_member_N}. Thus, this telemetry abstraction mechanism 247 allows the grouping of a certain common set of telemetry values 248 under a grouping operation. This can be done at the VN-member level 249 to suggest how the E2E telemetry be inferred from the per domain 250 tunnel created and monitored by PNCs. One proposed example is the 251 following: 253 +------------------------------------------------------------+ 254 | CNC | 255 | | 256 +------------------------------------------------------------+ 257 1.CNC sets the | /|\ 2. MDSC gets VN Telemetry 258 grouping op, and | | 259 subscribes to the | | VN KPI TELEMETRY (VN Level) 260 VN level telemetry | | VN Bandwidth Utilization: Minimum 261 for delay and | | across VN members 262 bandwidth util | | VN Delay: Maximum across VN 263 \|/ | Members 264 +------------------------------------------------------------+ 265 | MDSC | 266 | | 267 +------------------------------------------------------------+ 269 The ACTN VN TE-Telemetry Model augments the basic ACTN VN model to 270 enhance VN monitoring capability. This monitoring capability will 271 facilitate proactive re-optimization and reconfiguration of VNs 272 based on the performance monitoring data collected via the ACTN VN 273 Telemetry YANG model. 275 +----------+ +--------------+ 276 | ACTN VN | augments | ACTN | 277 | Model |<---------| TE-Telemetry | 278 +----------+ | Model | 279 +--------------+ 281 4. Notification 283 This model does not define specific notifications. To enable 284 notifications, the mechanism defined in [I-D.ietf-netconf-yang-push] 285 and [I-D.ietf-netconf-rfc5277bis] can be used. This mechanism 286 currently allows the user to: 288 . Subscribe notifications on a per client basis. 290 . Specify subtree filters or xpath filters so that only interested 291 contents will be sent. 293 . Specify either periodic or on-demand notifications. 295 YANG Push Subscription Examples 297 Below example shows the way for a client to subscribe for the 298 telemetry information for a particular tunnel (Tunnel1). The 299 telemetry parameter that the client is interested in is the utilized 300 bandwidth. 302 304 306 307 308 309 310 Tunnel1 311 312 313 315 318 319 320 321 322 323 324 500 325 encode-xml 326 327 329 This example shows the way for a client to subscribe for the 330 telemetry information for all VNs. The telemetry parameter that the 331 client is interested in is packet-loss and utilized bandwidth. 333 335 337 338 340 341 342 343 344 347 348 351 352 353 354 355 356 500 357 358 360 5. YANG Data Tree 362 A graphical representation of the complete data tree is presented 363 here. The meaning of the symbols in these diagrams is as follows 364 and as per [I-D.ietf-netmod-rfc6087bis]. Each node is printed as: 365 367 is one of: 368 + for current 369 x for deprecated 370 o for obsolete 372 is one of: 373 rw for configuration data 374 ro for non-configuration data 375 -x for rpcs and actions 376 -n for notifications 378 is the name of the node 379 () means that the node is a choice node 380 :() means that the node is a case node 382 If the node is augmented into the tree from another module, 383 its name is printed as :. 385 is one of: 386 ? for an optional leaf, choice, anydata or anyxml 387 ! for a presence container 388 * for a leaf-list or list 389 [] for a list's keys 391 is the name of the type for leafs and leaf-lists 393 If the type is a leafref, the type is printed as "-> 394 TARGET", 396 where TARGET is either the leafref path, with prefixed 397 removed if possible. 399 is the list of features this node depends on, 400 printed within curly brackets and a question mark "{...}? 402 module: ietf-te-kpi-telemetry 403 augment /te:te/te:tunnels/te:tunnel/te:config: 404 +--rw te-scaling-intent 405 +--rw scale-in 406 | +--rw scale-in-operation-type? 407 | | scaling-criteria-operation 408 | +--rw threshold-time? uint32 409 | +--rw scale-in-condition* [performance-type] 410 | +--rw performance-type identityref 411 | +--rw performance-data? binary 412 +--rw scale-down 413 +--rw cooldown-time? uint32 414 +--rw scale-out-operation-type? 415 | scaling-criteria-operation 416 +--rw scale-out-condition* [performance-type] 417 +--rw performance-type identityref 418 +--rw performance-data? binary 419 augment /te:te/te:tunnels/te:tunnel/te:state: 420 +--ro te-telemetry 421 +--ro data 422 +--ro one-way-delay? uint32 423 +--ro two-way-delay? uint32 424 +--ro one-way-delay-min? uint32 425 +--ro one-way-delay-max? uint32 426 +--ro two-way-delay-min? uint32 427 +--ro two-way-delay-max? uint32 428 +--ro one-way-delay-variation? uint32 429 +--ro two-way-delay-variation? uint32 430 +--ro utilized-bandwidth? te-types:te-bandwidth 432 module: ietf-actn-te-kpi-telemetry 433 augment /actn-vn:actn/actn-vn:vn/actn-vn:vn-list: 434 +--rw vn-telemetry 435 | +--rw grouping-op 436 | | +--rw delay-op? identityref 437 | | +--rw delay-variation-op? identityref 438 | | +--rw utilized-bandwidth-op? identityref 439 | +--ro data 440 | +--ro one-way-delay? uint32 441 | +--ro two-way-delay? uint32 442 | +--ro one-way-delay-min? uint32 443 | +--ro one-way-delay-max? uint32 444 | +--ro two-way-delay-min? uint32 445 | +--ro two-way-delay-max? uint32 446 | +--ro one-way-delay-variation? uint32 447 | +--ro two-way-delay-variation? uint32 448 | +--ro utilized-bandwidth? te-types:te-bandwidth 449 +--rw vn-scaling-intent 450 +--rw scale-in 451 | +--rw scale-in-operation-type? 452 | | scaling-criteria-operation 453 | +--rw threshold-time? uint32 454 | +--rw scale-in-condition* [performance-type] 455 | +--rw performance-type identityref 456 | +--rw performance-data? binary 457 +--rw scale-down 458 +--rw cooldown-time? uint32 459 +--rw scale-out-operation-type? 460 | scaling-criteria-operation 461 +--rw scale-out-condition* [performance-type] 462 +--rw performance-type identityref 463 +--rw performance-data? binary 464 augment /actn-vn:actn/actn-vn:vn/actn-vn:vn-list/actn-vn:vn-member-list: 465 +--rw vn-telemetry 466 +--rw grouping-op 467 | +--rw delay-op? identityref 468 | +--rw delay-variation-op? identityref 469 | +--rw utilized-bandwidth-op? identityref 470 +--ro data 471 +--ro one-way-delay? uint32 472 +--ro two-way-delay? uint32 473 +--ro one-way-delay-min? uint32 474 +--ro one-way-delay-max? uint32 475 +--ro two-way-delay-min? uint32 476 +--ro two-way-delay-max? uint32 477 +--ro one-way-delay-variation? uint32 478 +--ro two-way-delay-variation? uint32 479 +--ro utilized-bandwidth? te-types:te-bandwidth 481 6. Yang Data Model 483 ietf-te-kpi-telemetry model 485 The YANG code is as follows: 487 file "ietf-te-kpi-telemetry@2017-07-03.yang" 489 module ietf-te-kpi-telemetry { 490 namespace "urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry"; 491 prefix "te-tel"; 493 import ietf-te { 494 prefix "te"; 495 } 497 import ietf-te-types { 498 prefix "te-types"; 499 } 501 organization 502 "IETF Traffic Engineering Architecture and Signaling (TEAS) 503 Working Group"; 505 contact 506 "Editor: Young Lee 507 Editor: Dhruv Dhody 508 Editor: Ricard Vilalta 509 Editor: Satish Karunanithi "; 510 description 511 "This module describes telemetry for teas tunnel model"; 513 revision 2017-07-03 { 514 description 515 "Initial revision. This YANG file defines 516 the reusable base types for TE telemetry."; 517 reference 518 "xxx"; 519 } 521 /* 522 * Identities 523 */ 525 identity telemetry-param-type { 526 description 527 "Base identity for telemetry param types"; 528 } 530 identity one-way-delay { 531 base telemetry-param-type; 532 description 533 "To specify average Delay in one (forward) direction"; 534 } 535 identity two-way-delay { 536 base telemetry-param-type; 537 description 538 "To specify average Delay in both (forward and reverse) 539 directions"; 540 } 542 identity one-way-delay-variation { 543 base telemetry-param-type; 544 description 545 "To specify average Delay Variation in one (forward) 546 direction"; 547 } 549 identity two-way-delay-variation { 550 base telemetry-param-type; 551 description 552 "To specify average Delay Variation in both (forward 553 and reverse) directions"; 554 } 556 identity utilized-bandwidth { 557 base telemetry-param-type; 558 description 559 "To specify utilized bandwidth over the specified source 560 and destination."; 561 } 563 /* 564 * Enums 565 */ 566 typedef scaling-criteria-operation { 567 type enumeration { 568 enum AND { 569 description 570 "AND operation"; 571 } 572 enum OR { 573 description 574 "OR operation"; 575 } 576 } 577 description 578 "Operations to analize list of scaling criterias"; 579 } 581 /* 582 * Groupings 583 */ 585 grouping telemetry-delay { 586 description 587 "Base telemetry delay parameters"; 588 leaf one-way-delay { 589 type uint32; 590 units "microseconds"; 591 description 592 "To specify average Delay in one (forward) direction 593 during the measurement interval"; 594 } 595 leaf two-way-delay { 596 type uint32; 597 units "microseconds"; 598 description 599 "To specify average Delay in both (forward and reverse) 600 directions during the measurement interval"; 601 } 603 leaf one-way-delay-min { 604 type uint32; 605 units "microseconds"; 606 description 607 "To specify minimum Delay in one (forward) direction 608 during the measurement interval"; 609 } 610 leaf one-way-delay-max { 611 type uint32; 612 units "microseconds"; 613 description 614 "To specify maximum Delay in one (forward) direction 615 during the measurement interval"; 616 } 618 leaf two-way-delay-min { 619 type uint32; 620 units "microseconds"; 621 description 622 "To specify minimum Delay in both (forward and reverse) 623 directions during the measurement interval"; 624 } 626 leaf two-way-delay-max { 627 type uint32; 628 units "microseconds"; 629 description 630 "To specify maximum Delay in both (forward and reverse) 631 directions during the measurement interval"; 632 } 634 } 635 grouping telemetry-delay-variance { 637 description 638 "Base telemetry delay variance parameters"; 639 leaf one-way-delay-variation { 640 type uint32; 641 units "microseconds"; 642 description 643 "To specify average Delay Variation in one (forward) 644 direction during the measurement interval"; 645 } 647 leaf two-way-delay-variation { 648 type uint32; 649 units "microseconds"; 650 description 651 "To specify average Delay Variation in both 652 (forward and reverse) directions during the 653 measurement interval"; 654 } 655 } 657 grouping telemetry-bandwidth { 658 description 659 "Base telemetry bandwidth parameters"; 660 leaf utilized-bandwidth { 661 type te-types:te-bandwidth; 662 description 663 "To specify utilized bandwidth over the specified source 664 and destination in bytes per seconds."; 665 reference 666 "RFC 3471"; 667 } 668 } 670 grouping scaling-criteria { 671 description 672 "Grouping for scaling criteria"; 673 leaf performance-type { 674 type identityref { 675 base telemetry-param-type; 676 } 677 description 678 "Reference to the tunnel level telemetry type"; 679 } 681 leaf performance-data { 682 type binary; 683 description 684 "The encoding and meaning of this field is 685 based on the performance-type"; 686 } 687 } 688 grouping scaling-intent { 689 description 690 "Basic scaling intent"; 692 container scale-in { 693 description 694 "Basic scaling-in intent"; 696 leaf scale-in-operation-type { 697 type scaling-criteria-operation; 698 default AND; 699 description 700 "Operation to be applied to check between 701 scaling criterias to check if the scale in 702 threshold condition has been met. 703 Defaults to AND"; 704 } 706 leaf threshold-time { 707 type uint32; 708 units "seconds"; 709 description 710 "The duration for which the criteria must 711 hold true"; 712 } 714 list scale-in-condition { 715 key "performance-type"; 716 description 717 "Scaling conditions"; 718 uses scaling-criteria; 719 } 720 } 721 container scale-down { 722 description 723 "Basic scaling-out intent"; 724 leaf cooldown-time { 725 type uint32; 726 units "seconds"; 727 description 728 "The duration after a scaling-in/scaling-out action 729 has been triggered, for which there will be no 730 further operation"; 731 } 732 leaf scale-out-operation-type { 733 type scaling-criteria-operation; 734 default OR; 735 description 736 "Operation to be applied to check between 737 scaling criterias to check if the scale out 738 threshold condition has been met. 739 Defauls to OR"; 740 } 741 list scale-out-condition { 742 key "performance-type"; 743 description 744 "Scaling conditions"; 745 uses scaling-criteria; 746 } 748 } 750 } 752 grouping telemetry-param { 754 description 755 "Base telemetry parameters"; 756 container data { 757 config false; 758 description 759 "The telemetry data"; 761 uses telemetry-delay; 763 uses telemetry-delay-variance; 765 uses telemetry-bandwidth; 766 } 768 } 770 /* 771 * Augments 772 */ 773 augment "/te:te/te:tunnels/te:tunnel/te:config" { 775 description 776 "Augmentation parameters for config scaling-criteria 777 TE tunnel topologies. Scale in/out criteria might be 778 used for network autonomics in order the controller 779 to react to a certain set of monitored params."; 781 container te-scaling-intent { 782 description 783 "scaling intent"; 784 uses scaling-intent; 786 } 788 } 790 augment "/te:te/te:tunnels/te:tunnel/te:state" { 792 description 793 "Augmentation parameters for state TE tunnel 794 topologies."; 796 container te-telemetry { 797 description 798 "telemetry params"; 799 uses telemetry-param; 800 } 801 } 803 }//module 805 807 ietf-actn-te-kpi-telemetry model 809 The YANG code is as follows: 811 file "ietf-actn-te-kpi-telemetry@2017-07-03.yang" 813 module ietf-actn-te-kpi-telemetry { 815 namespace 816 "urn:ietf:params:xml:ns:yang:ietf-actn-te-kpi-telemetry"; 818 prefix "actn-tel"; 820 import ietf-actn-vn { 821 prefix "actn-vn"; 822 } 824 import ietf-te-kpi-telemetry { 825 prefix "te-kpi"; 826 } 827 organization 828 "IETF Traffic Engineering Architecture and Signaling (TEAS) 829 Working Group"; 831 contact 832 "Editor: Young Lee 833 Editor: Dhruv Dhody 834 Editor: Ricard Vilalta 835 Editor: Satish Karunanithi "; 837 description 838 "This module describes telemetry for actn vn model"; 840 revision 2017-07-03 { 841 description 842 "Initial revision. This YANG file defines 843 the reusable base types for ACTN VN telemetry."; 844 reference 845 "xxx"; 846 } 848 /* 849 * Identities 850 */ 852 identity grouping-operation { 853 description "Base identity for operations to analize list of monitored param"; 854 } 856 identity minimum-grouping-operation { 857 base grouping-operation; 858 description 859 "Select the minimum param"; 860 } 862 identity maximum-grouping-operation { 863 base grouping-operation; 864 description 865 "Select the maximum param"; 866 } 868 identity mean-grouping-operation { 869 base grouping-operation; 870 description 871 "Select the MEAN of the params"; 872 } 874 identity stddev-grouping-operation { 875 base grouping-operation; 876 description 877 "Select the STD deviation of the params"; 878 } 880 identity sum-grouping-operation { 881 base grouping-operation; 882 description 883 "Select the sum of the params"; 884 reference 885 "RFC 7823"; 886 } 888 /* 889 * Groupings 890 */ 891 grouping vn-telemetry-param { 892 description 893 "telemetry-parameter for VN"; 894 uses te-kpi:telemetry-param; 895 } 896 grouping telemetry-grouping-op { 897 description 898 "Config how the VN telemetry should be applied"; 899 container grouping-op { 900 description 901 "The grouping operations"; 902 leaf delay-op { 903 type identityref { 904 base grouping-operation; 905 } 906 default maximum-grouping-operation; 907 description 908 "The operation that should be applied on the 909 VN-member telemetry to get the VN telemetry"; 910 } 912 leaf delay-variation-op { 913 type identityref { 914 base grouping-operation; 915 } 916 default maximum-grouping-operation; 917 description 918 "The operation that should be applied on the 919 VN-member telemetry to get the VN telemetry"; 920 } 922 leaf utilized-bandwidth-op { 923 type identityref { 924 base grouping-operation; 926 } 927 default maximum-grouping-operation; 928 description 929 "The operation that should be applied on the 930 VN-member telemetry to get the VN telemetry"; 931 } 932 } 934 } 936 /* 937 * Augments 938 */ 939 augment "/actn-vn:actn/actn-vn:vn/actn-vn:vn-list" { 941 description 942 "Augmentation parameters for state TE VN topologies."; 944 container vn-telemetry { 945 description 946 "VN telemetry configurations"; 947 uses telemetry-grouping-op; 948 uses vn-telemetry-param; 949 } 950 container vn-scaling-intent { 951 description 952 "scaling intent"; 953 uses te-kpi:scaling-intent; 954 } 955 } 957 /* 958 * VN-member augment 959 */ 960 augment "/actn-vn:actn/actn-vn:vn/actn-vn:vn-list/" + 961 "actn-vn:vn-member-list" { 962 description 963 "Augmentation parameters for state TE vn member 964 topologies."; 965 container vn-telemetry { 966 description 967 "VN Member config"; 968 uses telemetry-grouping-op; 969 uses vn-telemetry-param; 970 } 971 } 972 } 973 974 7. Security Considerations 976 The configuration, state, and action data defined in this document 977 are designed to be accessed via a management protocol with a secure 978 transport layer, such as NETCONF [RFC6241]. The NETCONF access 979 control model [RFC6536] provides the means to restrict access for 980 particular NETCONF users to a preconfigured subset of all available 981 NETCONF protocol operations and content. 983 A number of configuration data nodes defined in this document are 984 writable/deletable (i.e., "config true") These data nodes may be 985 considered sensitive or vulnerable in some network environments. 987 8. IANA Considerations 989 TDB 991 9. Acknowledgements 993 10. References 995 Informative References 997 [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3 998 Provider-Provisioned Virtual Private Networks (PPVPNs)", 999 RFC 4110, July 2005. 1001 [RFC6020] M. Bjorklund, Ed., "YANG - A Data Modeling Language for 1002 the Network Configuration Protocol (NETCONF)", RFC 6020, 1003 October 2010. 1005 [Service-YANG] Q. Wu, W. Liu and A. Farrel, "Service Models 1006 Explained", draft-wu-opsawg-service-model-explained, work 1007 in progress. 1009 [Netmod-Yang-Model-Classification] D. Bogdanovic, B. Claise, and C. 1010 Moberg, "YANG Module Classification", draft-ietf-netmod- 1011 yang-model-classification, work in progress. 1013 [Netconf] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1014 and A. Bierman, Ed., "Network Configuration Protocol 1015 (NETCONF)", RFC 6241. 1017 [Restconf] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF 1018 Protocol", draft-ietf-netconf-restconf, work in progress. 1020 Normative References 1022 [ACTN-Frame] D. Cecarelli and Y. Lee, "Framework for Abstraction and 1023 Control of Traffic Engineered Networks", draft-ietf-teas- 1024 actn-framework, work in progress. 1026 [TE-Topology] X. Liu, et al., "YANG Data Model for TE Topologies", 1027 draft-ietf-teas-yang-te-topo, work in progress. 1029 [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic 1030 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 1031 te, work in progress. 1033 [ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN 1034 Operation", draft-lee-teas-actn-vn-yang, work in progress. 1036 [L3SM-YANG] S. Litkowski, L.Tomotaki, and K. Ogaki, "YANG Data Model 1037 for L3VPN service delivery", draft-ietf-l3sm-l3vpn- 1038 service-model, work in progress. 1040 [PCEP-Service-Aware] D. Dhody, et al., "Extensions to the Path 1041 Computation Element Communication Protocol (PCEP) to 1042 compute service aware Label Switched Path (LSP)", draft- 1043 ietf-pce-pcep-service-aware, work in progress. 1045 [ACTN-PERF] Y. XU, et al., "Use Cases and Requirements of Dynamic 1046 Service Control based on Performance Monitoring in ACTN 1047 Architecture", draft-xu-actn-perf-dynamic-service-control- 1048 03, work in progress. 1050 11. Contributors 1051 Authors' Addresses 1053 Young Lee 1054 Huawei Technologies 1055 5340 Legacy Drive Suite 173 1056 Plano, TX 75024, USA 1058 Email: leeyoung@huawei.com 1060 Dhruv Dhody 1061 Huawei Technology 1062 Leela Palace 1063 Bangalore, Karnataka 560008 1064 India 1066 Email: dhruv.dhody@huawei.com 1068 Satish Karunanithi 1069 Huawei Technology 1070 Leela Palace 1071 Bangalore, Karnataka 560008 1072 India 1074 Email: satish.karunanithi@gmail.com 1076 Ricard Vilalta 1077 Centre Tecnologic de Telecomunicacions de Catalunya (CTTC/CERCA) 1078 Av. Carl Friedrich Gauss 7 1079 08860 - Castelldefels 1080 Barcelona (Spain) 1081 Email: ricard.vilalta@cttc.es 1083 Daniel King 1084 Lancaster University 1086 Email: d.king@lancaster.ac.uk 1088 Daniele Ceccarelli 1089 Ericsson 1090 Torshamnsgatan,48 1091 Stockholm, Sweden 1093 Email: daniele.ceccarelli@ericsson.com