idnits 2.17.1 draft-lee-teas-actn-pm-telemetry-autonomics-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 10) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 21 instances of too long lines in the document, the longest one being 17 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 374 has weird spacing: '...lemetry xmlns...' -- The document date (October 5, 2018) is 2027 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: 'TE-tunnel' is mentioned on line 140, but not defined == Missing Reference: 'TE-Types' is mentioned on line 141, but not defined == Missing Reference: 'This I-D' is mentioned on line 142, but not defined == Missing Reference: 'I-D.ietf-netconf-yang-push' is mentioned on line 311, but not defined == Missing Reference: 'I-D.ietf-netconf-rfc5277bis' is mentioned on line 312, but not defined == Missing Reference: 'RFC6241' is mentioned on line 905, but not defined == Missing Reference: 'RFC6536' is mentioned on line 906, but not defined ** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341) == Unused Reference: 'RFC4110' is defined on line 924, but no explicit reference was found in the text == Unused Reference: 'Netconf' is defined on line 940, but no explicit reference was found in the text == Unused Reference: 'Restconf' is defined on line 944, but no explicit reference was found in the text == Unused Reference: 'ACTN-Frame' is defined on line 956, but no explicit reference was found in the text == Unused Reference: 'TE-Topology' is defined on line 960, but no explicit reference was found in the text == Unused Reference: 'TE-Tunnel' is defined on line 963, but no explicit reference was found in the text == Unused Reference: 'L3SM-YANG' is defined on line 970, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-teas-actn-framework (ref. 'ACTN-Frame') -- Possible downref: Normative reference to a draft: ref. 'ACTN-PERF' Summary: 3 errors (**), 0 flaws (~~), 17 warnings (==), 2 comments (--). 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 Satish Karunanithi 4 Expires: April 6, 2019 Huawei 5 Ricard Vilalta 6 CTTC 7 Daniel King 8 Lancaster University 9 Daniele Ceccarelli 10 Ericsson 12 October 5, 2018 14 YANG models for ACTN TE Performance Monitoring Telemetry and Network 15 Autonomics 17 draft-lee-teas-actn-pm-telemetry-autonomics-08 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with 22 the provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as 32 reference material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on April 6, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. Code Components extracted from this 53 document must include Simplified BSD License text as described in 54 Section 4.e of the Trust Legal Provisions and are provided without 55 warranty as described in the Simplified BSD License. 57 Abstract 59 Abstraction and Control of TE Networks (ACTN) refers to the set of 60 virtual network operations needed to operate, control and manage 61 large-scale multi-domain, multi-layer and multi-vendor TE networks, 62 so as to facilitate network programmability, automation, efficient 63 resource sharing. 65 This document provides YANG data models that describe Key 66 Performance Indicator (KPI) telemetry and network autonomics for TE- 67 tunnels and ACTN VNs. 69 Table of Contents 71 1. Introduction...................................................3 72 1.1. Terminology...............................................3 73 1.2. Tree Structure - Legend...................................3 74 2. Use-Cases......................................................4 75 3. Design of the Data Models......................................5 76 3.1. TE KPI Telemetry Model....................................6 77 3.2. ACTN TE KPI Telemetry Model...............................6 78 4. Notification...................................................8 79 4.1. YANG Push Subscription Examples...........................8 80 5. YANG Data Tree.................................................9 81 6. Yang Data Model...............................................11 82 6.1. ietf-te-kpi-telemetry model..............................11 83 6.2. ietf-actn-te-kpi-telemetry model.........................17 84 7. Security Considerations.......................................21 85 8. IANA Considerations...........................................21 86 9. Acknowledgements..............................................21 87 10. References...................................................21 88 10.1. Informative References..................................21 89 10.2. Normative References....................................22 90 11. Contributors.................................................23 91 Authors' Addresses...............................................23 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] describes how customers or end to end orchestrators can 110 request and/or instantiate a generic virtual network service. [ACTN- 111 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 1.1. Terminology 124 1.2. Tree Structure - Legend 126 A simplified graphical representation of the data model is used in 127 Section 5 of this this document. The meaning of the symbols in 128 these diagrams is defined in [RFC8342]. 130 1.3. Prefixes in Data Node Names 132 In this document, names of data nodes and other data model objects 133 are prefixed using the standard prefix associated with the 134 corresponding YANG imported modules, as shown in Table 1. 136 +---------+------------------------------+-----------------+ 137 | Prefix | YANG module | Reference | 138 +---------+------------------------------+-----------------+ 139 | rt | ietf-routing-types | [Routing-Types] | 140 | te | ietf-te | [TE-tunnel] | 141 | te-types| ietf-te-types | [TE-Types] | 142 | te-kpi | ietf-te-kpi-telemetry | [This I-D] | 143 | vn | ietf-actn-vn | [ACTN-VN] | 144 | actn-tel| ietf-actn-te-kpi-telemetry | {This I-D] | 145 +---------+------------------------------+-----------------+ 147 Table 1: Prefixes and corresponding YANG modules 149 2. Use-Cases 151 [ACTN-PERF] describes use-cases relevant to this draft. It 152 introduces the dynamic creation, modification and optimization of 153 services based on the performance monitoring in the Abstraction and 154 Control of Transport Networks (ACTN) architecture. Figure 1 shows a 155 high-level workflows for dynamic service control based on traffic 156 monitoring. 158 Some of the key points from [ACTN-PERF] are as follows: 160 . Network traffic monitoring is important to facilitate automatic 161 discovery of the imbalance of network traffic, and initiate the 162 network optimization, thus helping the network operator or the 163 virtual network service provider to use the network more 164 efficiently and save CAPEX/OPEX. 165 . Customer services have various SLA requirements, such as 166 service availability, latency, latency jitter, packet loss 167 rate, BER, etc. The transport network can satisfy service 168 availability and BER requirements by providing different 169 protection and restoration mechanisms. However, for other 170 performance parameters, there are no such mechanisms. In order 171 to provide high quality services according to customer SLA, one 172 possible solution is to measure the service SLA related 173 performance parameters, and dynamically provision and optimize 174 services based on the performance monitoring results. 175 . Performance monitoring in a large scale network could generate 176 a huge amount of performance information. Therefore, the 177 appropriate way to deliver the information in CMI and MPI 178 interfaces should be carefully considered. 180 +-------------------------------------------+ 181 | CNC +-----------------------------+ | 182 | | Dynamic Service Control APP | | 183 | +-----------------------------+ | 184 +-------------------------------------------+ 185 1.Traffic| /|\4.Traffic | /|\ 186 Monitor& | | Monitor | | 8.Traffic 187 Optimize | | Result 5.Service | | modify & 188 Policy | | modify& | | optimize 189 \|/ | optimize Req.\|/ | result 190 +------------------------------------------------+ 191 | MDSC +-------------------------------+ | 192 | |Dynamic Service Control Agent | | 193 | +-------------------------------+ | 194 | +---------------+ +-------------------+ | 195 | | Flow Optimize | | vConnection Agent | | 196 | +---------------+ +-------------------+ | 197 +------------------------------------------------+ 198 2. Path | /|\3.Traffic | | 199 Monitor | | Monitor | |7.Path 200 Request | | Result 6.Path | | modify & 201 | | modify& | | optimize 202 \|/ | optimize Req.\|/ | result 203 +-------------------------------------------------------+ 204 | PNC +----------------------+ +----------------------+ | 205 | | Network Provisioning | |Abstract Topology Gen.| | 206 | +----------------------+ +----------------------+ | 207 | +------------------+ +--------------------+ | 208 | |Network Monitoring| |Physical Topology DB| | 209 | +------------------+ +--------------------+ | 210 +-------------------------------------------------------+ 212 Figure 1 Workflows for dynamic service control based on traffic 213 monitoring 215 3. Design of the Data Models 217 The YANG models developed in this document describe two models: 219 (i) TE KPI Telemetry Model which provides the TE-Tunnel level of 220 performance monitoring mechanism (See Section 4 for details) 222 (ii) ACTN TE KPI Telemetry Model which provides the VN level of the 223 aggregated performance monitoring mechanism (See Section 5 224 for details) 226 The models include - 228 (i) Performance Telemetry details as measured during the last 229 interval, ex delay. 231 (ii) Scaling Intent based on with TE/VN could be scaled in/out. 233 [Editor's Note - Need to decide if scaling and telemetry can be in 234 the same model as per the current draft.] 236 3.1. TE KPI Telemetry Model 238 This module describes performance telemetry for TE-tunnel model. The 239 telemetry data is augmented to tunnel state. This module also 240 allows autonomic traffic engineering scaling intent configuration 241 mechanism on the TE-tunnel level. Various conditions can be set for 242 auto-scaling based on the telemetry data. 244 The TE KPI Telemetry Model augments the TE-Tunnel Model to enhance 245 TE performance monitoring capability. This monitoring capability 246 will facilitate proactive re-optimization and reconfiguration of TEs 247 based on the performance monitoring data collected via the TE KPI 248 Telemetry YANG model. 250 +------------+ +--------------+ 251 | TE-Tunnel | | TE KPI | 252 | Model |<---------| Telemetry | 253 +------------+ augments | Model | 254 +--------------+ 256 3.2. ACTN TE KPI Telemetry Model 258 This module describes performance telemetry for ACTN VN model. The 259 telemetry data is augmented both at the VN Level as well as 260 individual VN member level. This module also allows autonomic 261 traffic engineering scaling intent configuration mechanism on the VN 262 level. Scale in/out criteria might be used for network autonomics in 263 order the controller to react to a certain set of variations in 264 monitored parameters. 266 Moreover, this module also provides mechanism to define aggregated 267 telemetry parameters as a grouping of underlying VN level telemetry 268 parameters. Grouping operation (such as maximum, mean) could be set 269 at the time of configuration. For example, if maximum grouping 270 operation is used for delay at the VN level, the VN telemetry data 271 is reported as the maximum {delay_vn_member_1, delay_vn_member_2,.. 272 delay_vn_member_N}. Thus, this telemetry abstraction mechanism 273 allows the grouping of a certain common set of telemetry values 274 under a grouping operation. This can be done at the VN-member level 275 to suggest how the E2E telemetry be inferred from the per domain 276 tunnel created and monitored by PNCs. One proposed example is the 277 following: 279 +------------------------------------------------------------+ 280 | CNC | 281 | | 282 +------------------------------------------------------------+ 284 1.CNC sets the | /|\ 2. MDSC gets VN Telemetry 285 grouping op, and | | 286 subscribes to the | | VN KPI TELEMETRY (VN Level) 287 VN level telemetry for | | VN Utilized-bw-percentage: 288 Delay and | | Minimum across VN Members 289 Utilized-bw-pecentage | | VN Delay: Maximum across VN 290 \|/ | Members 291 +------------------------------------------------------------+ 292 | MDSC | 293 | | 294 +------------------------------------------------------------+ 296 The ACTN VN TE-Telemetry Model augments the basic ACTN VN model to 297 enhance VN monitoring capability. This monitoring capability will 298 facilitate proactive re-optimization and reconfiguration of VNs 299 based on the performance monitoring data collected via the ACTN VN 300 Telemetry YANG model. 302 +----------+ +--------------+ 303 | ACTN VN | augments | ACTN | 304 | Model |<---------| TE-Telemetry | 305 +----------+ | Model | 306 +--------------+ 308 4. Notification 310 This model does not define specific notifications. To enable 311 notifications, the mechanism defined in [I-D.ietf-netconf-yang-push] 312 and [I-D.ietf-netconf-rfc5277bis] can be used. This mechanism 313 currently allows the user to: 315 . Subscribe notifications on a per client basis. 317 . Specify subtree filters or xpath filters so that only interested 318 contents will be sent. 320 . Specify either periodic or on-demand notifications. 322 4.1. YANG Push Subscription Examples 324 Below example shows the way for a client to subscribe for the 325 telemetry information for a particular tunnel (Tunnel1). The 326 telemetry parameter that the client is interested in is the utilized 327 bandwidth percentage. 329 331 333 334 335 336 337 Tunnel1 338 339 340 342 345 346 347 349 350 351 352 500 353 encode-xml 354 355 357 This example shows the way for a client to subscribe for the 358 telemetry information for all VNs. The telemetry parameter that the 359 client is interested in is one-way delay and utilized bandwidth 360 percentage. 362 364 366 367 369 370 371 372 373 376 377 380 381 382 383 384 385 500 386 387 389 5. YANG Data Tree 390 module: ietf-te-kpi-telemetry 391 augment /te:te/te:tunnels/te:tunnel: 392 +-rw te-scaling-intent 393 | +-rw scale-in-intent 394 | | +-rw threshold-time? uint32 395 | | +-rw cooldown-time? uint32 396 | | +-rw scale-in-operation-type? scaling-criteria-operation 397 | | +-rw scale-out-operation-type? scaling-criteria-operation 398 | | +-rw scaling-condition* [performance-type] 399 | | +-rw performance-type identityref 400 | | +-rw te-telemetry-tunnel-ref? -> /te:te/tunnels/tunnel/name 401 | +-rw scale-out-intent 402 | +-rw threshold-time? uint32 403 | +-rw cooldown-time? uint32 404 | +-rw scale-in-operation-type? scaling-criteria-operation 405 | +-rw scale-out-operation-type? scaling-criteria-operation 406 | +-rw scaling-condition* [performance-type] 407 | +-rw performance-type identityref 408 | +-rw te-telemetry-tunnel-ref? -> /te:te/tunnels/tunnel/name 409 +-ro te-telemetry 410 +-ro id? string 411 +-ro performance-metric-one-way 412 | +-ro one-way-delay? uint32 413 | +-ro one-way-min-delay? uint32 414 | +-ro one-way-max-delay? uint32 415 | +-ro one-way-delay-variation? uint32 416 | +-ro one-way-packet-loss? decimal64 417 | +-ro one-way-residual-bandwidth? rt-types:bandwidth-ieee-float32 418 | +-ro one-way-available-bandwidth? rt-types:bandwidth-ieee-float32 419 | +-ro one-way-utilized-bandwidth? rt-types:bandwidth-ieee-float32 420 +-ro performance-metric-two-way 421 | +-ro two-way-delay? uint32 422 | +-ro two-way-min-delay? uint32 423 | +-ro two-way-max-delay? uint32 424 | +-ro two-way-delay-variation? uint32 425 | +-ro two-way-packet-loss? decimal64 426 +-ro te-ref? -> /te:te/tunnels/tunnel/name 428 module: ietf-actn-te-kpi-telemetry 429 augment /vn:actn/vn:vn/vn:vn-list: 430 +-rw vn-scaling-intent 431 | +-rw scale-in-intent 432 | | +-rw threshold-time? uint32 433 | | +-rw cooldown-time? uint32 434 | | +-rw scale-in-operation-type? scaling-criteria-operation 435 | | +-rw scale-out-operation-type? scaling-criteria-operation 436 | | +-rw scaling-condition* [performance-type] 437 | | +-rw performance-type identityref 438 | | +-rw te-telemetry-tunnel-ref? -> /te:te/tunnels/tunnel/name 439 | +-rw scale-out-intent 440 | +-rw threshold-time? uint32 441 | +-rw cooldown-time? uint32 442 | +-rw scale-in-operation-type? scaling-criteria-operation 443 | +-rw scale-out-operation-type? scaling-criteria-operation 444 | +-rw scaling-condition* [performance-type] 445 | +-rw performance-type identityref 446 | +-rw te-telemetry-tunnel-ref? -> /te:te/tunnels/tunnel/name 447 +-ro vn-telemetry 448 +-ro performance-metric-one-way 449 | +-ro one-way-delay? uint32 450 | +-ro one-way-min-delay? uint32 451 | +-ro one-way-max-delay? uint32 452 | +-ro one-way-delay-variation? uint32 453 | +-ro one-way-packet-loss? decimal64 454 | +-ro one-way-residual-bandwidth? rt-types:bandwidth-ieee-float32 455 | +-ro one-way-available-bandwidth? rt-types:bandwidth-ieee-float32 456 | +-ro one-way-utilized-bandwidth? rt-types:bandwidth-ieee-float32 457 +-ro performance-metric-two-way 458 | +-ro two-way-delay? uint32 459 | +-ro two-way-min-delay? uint32 460 | +-ro two-way-max-delay? uint32 461 | +-ro two-way-delay-variation? uint32 462 | +-ro two-way-packet-loss? decimal64 463 +-ro grouping-operation? grouping-operation 464 augment /vn:actn/vn:vn/vn:vn-list/vn:vn-member-list: 465 +-ro vn-member-telemetry 466 +-ro performance-metric-one-way 467 | +-ro one-way-delay? uint32 468 | +-ro one-way-min-delay? uint32 469 | +-ro one-way-max-delay? uint32 470 | +-ro one-way-delay-variation? uint32 471 | +-ro one-way-packet-loss? decimal64 472 | +-ro one-way-residual-bandwidth? rt-types:bandwidth-ieee-float32 473 | +-ro one-way-available-bandwidth? rt-types:bandwidth-ieee-float32 474 | +-ro one-way-utilized-bandwidth? rt-types:bandwidth-ieee-float32 475 +-ro performance-metric-two-way 476 | +-ro two-way-delay? uint32 477 | +-ro two-way-min-delay? uint32 478 | +-ro two-way-max-delay? uint32 479 | +-ro two-way-delay-variation? uint32 480 | +-ro two-way-packet-loss? decimal64 481 +-ro te-grouped-params* -> /te:te/tunnels/tunnel/te-kpi:te-telemetry/id 482 +-ro grouping-operation? grouping-operation 484 6. Yang Data Model 486 6.1. ietf-te-kpi-telemetry model 488 The YANG code is as follows: 490 file "ietf-te-kpi-telemetry@2018-10-05.yang" 492 module ietf-te-kpi-telemetry { 493 namespace "urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry"; 495 prefix "te-tel"; 497 import ietf-te { 498 prefix "te"; 499 } 501 import ietf-te-types { 502 prefix "te-types"; 503 } 505 import ietf-routing-types { 506 prefix "rt-types"; 507 } 509 organization 510 "IETF Traffic Engineering Architecture and Signaling (TEAS) 511 Working Group"; 513 contact 514 "Editor: Young Lee 515 Editor: Dhruv Dhody 516 Editor: Ricard Vilalta 517 Editor: Satish Karunanithi "; 519 description 520 "This module describes telemetry for teas tunnel model"; 522 revision 2018-10-05 { 523 description 524 "Initial revision. This YANG file defines 525 the reusable base types for TE telemetry."; 526 reference 527 "Derived from earlier versions of base YANG files"; 528 } 530 /* 531 * Identities 532 */ 534 identity telemetry-param-type { 535 description 536 "Base identity for telemetry param types"; 538 } 540 identity one-way-delay { 541 base telemetry-param-type; 542 description 543 "To specify average Delay in one (forward) 544 direction"; 545 } 547 identity two-way-delay { 548 base telemetry-param-type; 549 description 550 "To specify average Delay in both (forward and reverse) 551 directions"; 552 } 554 identity one-way-delay-variation { 555 base telemetry-param-type; 556 description 557 "To specify average Delay Variation in one (forward) direction"; 558 } 560 identity two-way-delay-variation { 561 base telemetry-param-type; 562 description 563 "To specify average Delay Variation in both (forward and reverse) 564 directions"; 565 } 567 identity one-way-packet-loss { 568 base telemetry-param-type; 569 description 570 "To specify packet loss in one (forward) direction."; 571 } 573 identity two-way-packet-loss { 574 base telemetry-param-type; 575 description 576 "To specify packet loss in in both (forward and reverse) 577 directions"; 578 } 580 identity utilized-bandwidth { 581 base telemetry-param-type; 582 description 583 "To specify utilized bandwidth over the specified source 584 and destination."; 585 } 587 identity utilized-percentage { 588 base telemetry-param-type; 589 description 590 "To specify utilization percentage of the entity 591 (e.g., tunnel, link, etc.)"; 592 } 593 /* 594 * Enums 595 */ 596 typedef scaling-criteria-operation { 597 type enumeration { 598 enum AND { 599 description 600 "AND operation"; 601 } 602 enum OR { 603 description 604 "OR operation"; 605 } 606 } 607 description 608 "Operations to analize list of scaling criterias"; 609 } 611 /* 612 * Groupings 613 */ 615 grouping scaling-duration { 616 description 617 "Base scaling criteria durations"; 618 leaf threshold-time { 619 type uint32; 620 units "seconds"; 621 description 622 "The duration for which the criteria must hold true"; 623 } 624 leaf cooldown-time { 625 type uint32; 626 units "seconds"; 627 description 628 "The duration after a scaling-in/scaling-out action has been 629 triggered, for which there will be no further operation"; 630 } 631 } 633 grouping scaling-criteria { 634 description 635 "Grouping for scaling criteria"; 636 leaf performance-type { 637 type identityref { 638 base telemetry-param-type; 639 } 640 description 641 "Reference to the tunnel level telemetry type"; 642 } 644 leaf te-telemetry-tunnel-ref { 645 type leafref { 646 path "/te:te/te:tunnels/te:tunnel/te:name"; 647 } 648 description 649 "Reference to tunnel"; 650 } 651 } 653 grouping scaling-intent { 654 description 655 "Basic sclaing intent"; 657 uses scaling-duration; 659 leaf scale-in-operation-type { 660 type scaling-criteria-operation; 661 default AND; 662 description 663 "Operation to be applied to check between scaling criterias to 664 check if the scale in threshold condition has been met. 665 Defaults to AND"; 666 } 667 leaf scale-out-operation-type { 668 type scaling-criteria-operation; 669 default OR; 670 description 671 "Operation to be applied to check between scaling criterias to 672 check if the scale out threshold condition has been met. 673 Defauls to OR"; 674 } 676 list scaling-condition { 677 key "performance-type"; 678 description 679 "Scaling conditions"; 680 uses scaling-criteria; 681 } 683 } 685 /* 686 * Augments 687 */ 689 augment "/te:te/te:tunnels/te:tunnel" { 691 description 692 "Augmentation parameters for config scaling-criteria 693 TE tunnel topologies. Scale in/out criteria might be used 694 for network autonomics in order the controller 695 to react to a certain set of monitored params."; 697 container te-scaling-intent { 698 description 699 "scaling intent"; 701 container scale-in-intent{ 702 description 703 "scale-in"; 704 uses scaling-intent; 705 } 706 container scale-out-intent{ 707 description 708 "scale-out"; 709 uses scaling-intent; 710 } 711 } 713 container te-telemetry { 714 config false; 715 description 716 "telemetry params"; 717 leaf id { 718 type string; 719 description "Id of telemetry param"; 720 } 722 uses te-types:performance-metric-container; 724 leaf te-ref{ 725 type leafref{ path 726 '/te:te/te:tunnels/te:tunnel/te:name'; } 727 description "Reference to measured te tunnel"; 728 } 729 } 731 } 733 } 735 737 6.2. ietf-actn-te-kpi-telemetry model 739 The YANG code is as follows: 741 file "ietf-actn-te-kpi-telemetry@2018-10-05.yang" 743 module ietf-actn-te-kpi-telemetry { 745 namespace "urn:ietf:params:xml:ns:yang:ietf-actn-te-kpi-telemetry"; 747 prefix "actn-tel"; 749 import ietf-actn-vn { 750 prefix "vn"; 751 } 753 import ietf-te { 754 prefix "te"; 755 } 757 import ietf-te-types { 758 prefix "te-types"; 759 } 761 import ietf-te-kpi-telemetry { 762 prefix "te-kpi"; 763 } 765 organization 766 "IETF Traffic Engineering Architecture and Signaling (TEAS) 767 Working Group"; 769 contact 770 "Editor: Young Lee 771 Editor: Dhruv Dhody 772 Editor: Ricard Vilalta 773 Editor: Satish Karunanithi "; 775 description 776 "This module describes telemetry for actn vn model"; 778 revision 2018-10-05 { 779 description 780 "Initial revision. This YANG file defines 781 the ACTN VN telemetry."; 782 reference 783 "Derived from earlier versions of base YANG files"; 784 } 786 /* 787 * Typedefs 788 */ 790 typedef grouping-operation { 792 type enumeration { 793 enum MINIMUM { 794 description "Select the minimum param"; 795 } 796 enum MAXIMUM { 797 description "Select the maximum param"; 798 } 799 enum MEAN { 800 description "Select the MEAN of the params"; 801 } 802 enum STD_DEV { 803 description "Select the standard deviation 804 of the monitored params"; 805 } 806 enum AND { 807 description "Select the AND of the params"; 808 } 809 enum OR { 810 description "Select the OR of the params"; 811 } 812 } 813 description 814 "Operations to analyze list of monitored params"; 815 } 817 /* 818 * Groupings 819 */ 821 grouping vn-telemetry-param { 822 description "augment of te-kpi:telemetry-param for VN specific params"; 824 leaf-list te-grouped-params { 825 type leafref{ 826 path '/te:te/te:tunnels/te:tunnel/'+ 827 'te-kpi:te-telemetry/te-kpi:id'; 828 } 829 description 830 "Allows the definition of a vn-telemetry param 831 as a grouping of underlying TE params"; 832 } 834 leaf grouping-operation { 835 type grouping-operation; 836 description 837 "describes the operation to apply to 838 te-grouped-params"; 839 } 841 } 843 /* 844 * Augments 845 */ 847 augment "/vn:actn/vn:vn/vn:vn-list" { 849 description 850 "Augmentation parameters for state TE VN topologies."; 852 container vn-scaling-intent { 853 description 854 "scaling intent"; 856 container scale-in-intent{ 857 description 858 "VN scale-in"; 859 uses te-kpi:scaling-intent; 860 } 861 container scale-out-intent{ 862 description 863 "VN scale-out"; 864 uses te-kpi:scaling-intent; 865 } 866 } 867 container vn-telemetry { 868 config false; 869 description 870 "VN telemetry params"; 872 uses te-types:performance-metric-container; 874 leaf grouping-operation { 875 type grouping-operation; 876 description "describes the operation to apply to the VN-members"; 877 } 878 } 879 } 881 /* 882 * VN-member augment 883 */ 884 augment "/vn:actn/vn:vn/vn:vn-list/vn:vn-member-list" { 885 description 886 "Augmentation parameters for state TE vn member topologies."; 887 container vn-member-telemetry { 888 config false; 889 description 890 "VN member telemetry params"; 892 uses te-types:performance-metric-container; 894 uses vn-telemetry-param; 896 } 897 } 898 } 899 901 7. Security Considerations 903 The configuration, state, and action data defined in this document 904 are designed to be accessed via a management protocol with a secure 905 transport layer, such as NETCONF [RFC6241]. The NETCONF access 906 control model [RFC6536] provides the means to restrict access for 907 particular NETCONF users to a preconfigured subset of all available 908 NETCONF protocol operations and content. 910 A number of configuration data nodes defined in this document are 911 writable/deletable (i.e., "config true") These data nodes may be 912 considered sensitive or vulnerable in some network environments. 914 8. IANA Considerations 916 TDB 918 9. Acknowledgements 920 10. References 922 10.1. Informative References 924 [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3 925 Provider-Provisioned Virtual Private Networks (PPVPNs)", 926 RFC 4110, July 2005. 928 [RFC6020] M. Bjorklund, Ed., "YANG - A Data Modeling Language for 929 the Network Configuration Protocol (NETCONF)", RFC 6020, 930 October 2010. 932 [Service-YANG] Q. Wu, W. Liu and A. Farrel, "Service Models 933 Explained", draft-wu-opsawg-service-model-explained, work 934 in progress. 936 [Netmod-Yang-Model-Classification] D. Bogdanovic, B. Claise, and C. 937 Moberg, "YANG Module Classification", draft-ietf-netmod- 938 yang-model-classification, work in progress. 940 [Netconf] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 941 and A. Bierman, Ed., "Network Configuration Protocol 942 (NETCONF)", RFC 6241. 944 [Restconf] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF 945 Protocol", draft-ietf-netconf-restconf, work in progress. 947 [Routing-Types] X. Liu, et al, "Routing Area Common YANG Data 948 Types", draft-ietf-rtgwg-routing-types, work in progress. 950 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 951 and R. Wilton, "Network Management Datastore Architecture 952 (NMDA)", RFC 8342, March 2018, 954 10.2. Normative References 956 [ACTN-Frame] D. Cecarelli and Y. Lee, "Framework for Abstraction and 957 Control of Traffic Engineered Networks", draft-ietf-teas- 958 actn-framework, work in progress. 960 [TE-Topology] X. Liu, et al., "YANG Data Model for TE Topologies", 961 draft-ietf-teas-yang-te-topo, work in progress. 963 [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic 964 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 965 te, work in progress. 967 [ACTN-VN] Y. Lee (Editor), "A Yang Data Model for ACTN VN 968 Operation", draft-lee-teas-actn-vn-yang, work in progress. 970 [L3SM-YANG] S. Litkowski, L.Tomotaki, and K. Ogaki, "YANG Data Model 971 for L3VPN service delivery", draft-ietf-l3sm-l3vpn- 972 service-model, work in progress. 974 [PCEP-Service-Aware] D. Dhody, et al., "Extensions to the Path 975 Computation Element Communication Protocol (PCEP) to 976 compute service aware Label Switched Path (LSP)", draft- 977 ietf-pce-pcep-service-aware, work in progress. 979 [ACTN-PERF] Y. XU, et al., "Use Cases and Requirements of Dynamic 980 Service Control based on Performance Monitoring in ACTN 981 Architecture", draft-xu-actn-perf-dynamic-service-control- 982 03, work in progress. 984 11. Contributors 986 Authors' Addresses 988 Young Lee 989 Huawei Technologies 990 5340 Legacy Drive Suite 173 991 Plano, TX 75024, USA 993 Email: leeyoung@huawei.com 995 Dhruv Dhody 996 Huawei Technology 997 Leela Palace 998 Bangalore, Karnataka 560008 999 India 1001 Email: dhruv.dhody@huawei.com 1003 Satish Karunanithi 1004 Huawei Technology 1005 Leela Palace 1006 Bangalore, Karnataka 560008 1007 India 1009 Email: satish.karunanithi@gmail.com 1010 Ricard Vilalta 1011 Centre Tecnologic de Telecomunicacions de Catalunya (CTTC/CERCA) 1012 Av. Carl Friedrich Gauss 7 1013 08860 - Castelldefels 1014 Barcelona (Spain) 1015 Email: ricard.vilalta@cttc.es 1017 Daniel King 1018 Lancaster University 1020 Email: d.king@lancaster.ac.uk 1022 Daniele Ceccarelli 1023 Ericsson 1024 Torshamnsgatan,48 1025 Stockholm, Sweden 1027 Email: daniele.ceccarelli@ericsson.com