idnits 2.17.1 draft-ietf-teas-actn-pm-telemetry-autonomics-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 14) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 1, 2019) is 1761 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: 'This I-D' is mentioned on line 208, but not defined == Unused Reference: 'RFC7471' is defined on line 1243, but no explicit reference was found in the text == Unused Reference: 'RFC7823' is defined on line 1247, but no explicit reference was found in the text == Unused Reference: 'RFC8570' is defined on line 1277, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 6 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 Futurewei 3 Intended Status: Standard Track 4 Expires: January 1, 2020 Dhruv Dhody 5 ` Satish Karunanithi 6 Huawei 8 Ricard Vilalta 9 CTTC 11 Daniel King 12 Lancaster University 14 Daniele Ceccarelli 15 Ericsson 17 July 1, 2019 19 YANG models for VN & TE Performance Monitoring Telemetry and Scaling 20 Intent Autonomics 22 draft-ietf-teas-actn-pm-telemetry-autonomics-00 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with 27 the provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as 37 reference material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on January 1, 2020. 47 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with 56 respect to this document. Code Components extracted from this 57 document must include Simplified BSD License text as described in 58 Section 4.e of the Trust Legal Provisions and are provided without 59 warranty as described in the Simplified BSD License. 61 Abstract 63 This document provides YANG data models that describe performance 64 monitoring telemetry and scaling intent mechanism for TE-tunnels and 65 Virtual Networks (VN). 67 The models presented in this draft allow customers to subscribe to 68 and monitor their key performance data of their interest on the 69 level of TE-tunnel or VN. The models also provide customers with the 70 ability to program autonomic scaling intent mechanism on the level 71 of TE-tunnel as well as VN. 73 Table of Contents 75 1. Introduction...................................................3 76 1.1. Terminology...............................................4 77 1.2. Tree diagram..............................................5 78 1.3. Prefixes in Data Node Names...............................5 79 2. Use-Cases......................................................5 80 3. Design of the Data Models......................................7 81 3.1. TE KPI Telemetry Model....................................7 82 3.2. VN KPI Telemetry Model....................................8 83 4. Autonomic Scaling Intent Mechanism.............................9 84 5. Notification..................................................11 85 5.1. YANG Push Subscription Examples..........................11 86 6. YANG Data Tree................................................13 87 7. Yang Data Model...............................................15 88 7.1. ietf-te-kpi-telemetry model..............................15 89 7.2. ietf-vn-kpi-telemetry model..............................21 91 8. Security Considerations.......................................25 92 9. IANA Considerations...........................................26 93 10. Acknowledgements.............................................27 94 11. References...................................................27 95 11.1. Normative References....................................27 96 11.2. Informative References..................................28 97 12. Contributors.................................................29 98 Authors' Addresses...............................................29 100 1. Introduction 102 The YANG model discussed in [VN] is used to operate customer-driven 103 Virtual Networks (VNs) during the VN instantiation, VN computation, 104 and its life-cycle service management and operations. YANG model 105 discussed in [TE-Tunnel] is used to operate TE-tunnels during the 106 tunnel instantiation, and its life-cycle management and operations. 108 The models presented in this draft allow the applications hosted by 109 the customers to subscribe to and monitor their key performance data 110 of their interest on the level of VN [VN] or TE-tunnel [TE-Tunnel]. 111 The key characteristic of the models presented in this document is a 112 top-down programmability that allows the applications hosted by the 113 customers to subscribe to and monitor key performance data of their 114 interest and autonomic scaling intent mechanism on the level of VN 115 as well as TE-tunnel. 117 According to the classification of [RFC8309], the YANG data models 118 presented in this document can be classified as customer service 119 models, which is mapped to CMI (Customer Network Controller (CNC)- 120 Multi-Domain Service Coordinator (MSDC) interface) of ACTN 121 [RFC8453]. 123 [RFC8233] describes key network performance data to be considered 124 for end-to-end path computation in TE networks. Key performance 125 indicator (KPI) is a term that describes critical performance data 126 that may affect VN/TE-tunnel service. The services provided can be 127 optimized to meet the requirements (such as traffic patterns, 128 quality, and reliability) of the applications hosted by the 129 customers. 131 This document provides YANG data models generically applicable to 132 any VN/TE-Tunnel service clients to provide an ability to program 133 their customized performance monitoring subscription and publication 134 data models and automatic scaling in/out intent data models. These 135 models can be utilized by a client network controller to initiate 136 these capability to a transport network controller communicating 137 with the client controller via a NETCONF [RFC8341] or a RESTCONF 138 [RFC8040] interface. 140 The term performance monitoring being used in this document is 141 different from the term that has been used in transport networks for 142 many years. Performance monitoring in this document refers to 143 subscription and publication of streaming telemetry data. 144 Subscription is initiated by the client (e.g., CNC) while 145 publication is provided by the network (e.g., MDSC/PNC) based on the 146 client's subscription. As the scope of performance monitoring in 147 this document is telemetry data on the level of client's VN or TE- 148 tunnel, the entity interfacing the client (e.g., MDSC) has to 149 provide VN or TE-tunnel level information. This would require 150 controller capability to derive VN or TE-tunnel level performance 151 data based on lower-level data collected via PM counters in the 152 Network Elements (NE). How the controller entity derives such 153 customized level data (i.e., VN or TE-tunnel level) is out of the 154 scope of this document. 156 The data model includes configuration and state data according to 157 the new Network Management Datastore Architecture [RFC8342]. 159 1.1. Terminology 161 Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used 162 in this document. 164 Key Performance Data: This refers to a set of data the customer is 165 interested in monitoring for their instantiated VNs or TE-tunnels. 166 Key performance data and key performance indicators are inter- 167 exchangeable in this draft. 169 Scaling: This refers to the network ability to re-shape its own 170 resources. Scale out refers to improve network performance by 171 increasing the allocated resources, while scale in refers to 172 decrease the allocated resources, typically because the existing 173 resources are unnecessary. 175 Scaling Intent: To declare scaling conditions, scaling intent is 176 used. Specifically, scaling intent refers to the intent expressed by 177 the client that allows the client to program/configure conditions of 178 their key performance data either for scaling out or scaling in. 179 Various conditions can be set for scaling intent on either VN or TE- 180 tunnel level. 182 Network Autonomics: This refers to the network automation capability 183 that allows client to initiate scaling intent mechanisms and 184 provides the client with the status of the adjusted network 185 resources based on the client's scaling intent in an automated 186 fashion. 188 1.2. Tree diagram 190 A simplified graphical representation of the data model is used in 191 Section 5 of this this document. The meaning of the symbols in 192 these diagrams is defined in [RFC8340]. 194 1.3. Prefixes in Data Node Names 196 In this document, names of data nodes and other data model objects 197 are prefixed using the standard prefix associated with the 198 corresponding YANG imported modules, as shown in Table 1. 200 +---------+------------------------------+-----------------+ 201 | Prefix | YANG module | Reference | 202 +---------+------------------------------+-----------------+ 203 | rt | ietf-routing-types | [RFC8294] | 204 | te | ietf-te | [TE-Tunnel] | 205 | te-types| ietf-te-types | [TE-Types] | 206 | te-tel | ietf-te-kpi-telemetry | [This I-D] | 207 | vn | ietf-vn | [VN] | 208 | vn-tel | ietf-vn-kpi-telemetry | [This I-D] | 209 +---------+------------------------------+-----------------+ 211 Table 1: Prefixes and corresponding YANG modules 213 2. Use-Cases 215 [PERF] describes use-cases relevant to this draft. It introduces the 216 dynamic creation, modification and optimization of services based on 217 the performance monitoring. Figure 1 shows a high-level workflows 218 for dynamic service control based on traffic monitoring. 220 +----------------------------------------------+ 221 | Client +-----------------------------+ | 222 | | Dynamic Service Control APP | | 223 | +-----------------------------+ | 224 +----------------------------------------------+ 225 1.Traffic| /|\4.Traffic | /|\ 226 Monitor& | | Monitor | | 8.Traffic 227 Optimize | | Result 5.Service | | modify & 228 Policy | | modify& | | optimize 229 \|/ | optimize Req.\|/ | result 230 +----------------------------------------------+ 231 | Orchestrator | 232 | +-------------------------------+ | 233 | |Dynamic Service Control Agent | | 234 | +-------------------------------+ | 235 | +---------------+ +-------------------+ | 236 | | Flow Optimize | | vConnection Agent | | 237 | +---------------+ +-------------------+ | 238 +----------------------------------------------+ 239 2. Path | /|\3.Traffic | /|\ 240 Monitor | | Monitor | |7.Path 241 Request | | Result 6.Path | | modify & 242 | | modify& | | optimize 243 \|/ | optimize Req.\|/ | result 244 +----------------------------------------------+ 245 | Network SDN Controller | 246 | +----------------------+ +-----------------+| 247 | | Network Provisioning | |Abstract Topology|| 248 | +----------------------+ +-----------------+| 249 | +------------------+ +--------------------+ | 250 | |Network Monitoring| |Physical Topology DB| | 251 | +------------------+ +--------------------+ | 252 +----------------------------------------------+ 254 Figure 1 Workflows for dynamic service control based on traffic 255 monitoring 257 Some of the key points from [PERF] are as follows: 259 . Network traffic monitoring is important to facilitate automatic 260 discovery of the imbalance of network traffic, and initiate the 261 network optimization, thus helping the network operator or the 262 virtual network service provider to use the network more 263 efficiently and save the Capital Expense (CAPEX) and the 264 Operating Expense (OPEX). 266 . Customer services have various Service Level Agreement (SLA) 267 requirements, such as service availability, latency, latency 268 jitter, packet loss rate, Bit Error Rate (BER), etc. The 269 transport network can satisfy service availability and BER 270 requirements by providing different protection and restoration 271 mechanisms. However, for other performance parameters, there 272 are no such mechanisms. In order to provide high quality 273 services according to customer SLA, one possible solution is to 274 measure the SLA related performance parameters, and dynamically 275 provision and optimize services based on the performance 276 monitoring results. 277 . Performance monitoring in a large scale network could generate 278 a huge amount of performance information. Therefore, the 279 appropriate way to deliver the information in the client and 280 network interfaces should be carefully considered. 282 3. Design of the Data Models 284 The YANG models developed in this document describe two models: 286 (i) TE KPI Telemetry Model which provides the TE-Tunnel level of 287 performance monitoring mechanism and scaling intent mechanism 288 that allows scale in/out programming by the customer. (See 289 Section 3.1 & 7.1 for details). 291 (ii) VN KPI Telemetry Model which provides the VN level of the 292 aggregated performance monitoring mechanism and scaling 293 intent mechanism that allows scale in/out programming by the 294 customer (See Section 3.2 & 7.2 for details). 296 3.1. TE KPI Telemetry Model 298 This module describes performance telemetry for TE-tunnel model. The 299 telemetry data is augmented to tunnel state. This module also 300 allows autonomic traffic engineering scaling intent configuration 301 mechanism on the TE-tunnel level. Various conditions can be set for 302 auto-scaling based on the telemetry data (See Section 5 for details) 304 The TE KPI Telemetry Model augments the TE-Tunnel Model to enhance 305 TE performance monitoring capability. This monitoring capability 306 will facilitate proactive re-optimization and reconfiguration of TEs 307 based on the performance monitoring data collected via the TE KPI 308 Telemetry YANG model. 310 +------------+ +--------------+ 311 | TE-Tunnel | | TE KPI | 312 | Model |<---------| Telemetry | 313 +------------+ augments | Model | 314 +--------------+ 316 3.2. VN KPI Telemetry Model 318 This module describes performance telemetry for VN model. The 319 telemetry data is augmented both at the VN Level as well as 320 individual VN member level. This module also allows autonomic 321 traffic engineering scaling intent configuration mechanism on the VN 322 level. Scale in/out criteria might be used for network autonomics in 323 order the controller to react to a certain set of variations in 324 monitored parameters (See Section 4 for illustrations). 326 Moreover, this module also provides mechanism to define aggregated 327 telemetry parameters as a grouping of underlying VN level telemetry 328 parameters. Grouping operation (such as maximum, mean) could be set 329 at the time of configuration. For example, if maximum grouping 330 operation is used for delay at the VN level, the VN telemetry data 331 is reported as the maximum {delay_vn_member_1, delay_vn_member_2,.. 332 delay_vn_member_N}. Thus, this telemetry abstraction mechanism 333 allows the grouping of a certain common set of telemetry values 334 under a grouping operation. This can be done at the VN-member level 335 to suggest how the E2E telemetry be inferred from the per domain 336 tunnel created and monitored by PNCs. One proposed example is the 337 following: 339 +------------------------------------------------------------+ 340 | Client | 341 | | 342 +------------------------------------------------------------+ 344 1.Client sets the | /|\ 2. Orchestrator pushes: 345 grouping op, and | | 346 subscribes to the | | VN level telemetry for 347 VN level telemetry for | | - VN Utilized-bw-percentage 348 Delay and | | (Minimum across VN Members) 349 Utilized-bw-pecentage | | - VN Delay (Maximum across VN 350 \|/ | Members) 351 +------------------------------------------------------------+ 352 | Orchestrator | 353 | | 354 +------------------------------------------------------------+ 356 The VN Telemetry Model augments the basic VN model to enhance VN 357 monitoring capability. This monitoring capability will facilitate 358 proactive re-optimization and reconfiguration of VNs based on the 359 performance monitoring data collected via the VN Telemetry YANG 360 model. 362 +----------+ +--------------+ 363 | VN | augments | VN | 364 | Model |<---------| Telemetry | 365 +----------+ | Model | 366 +--------------+ 368 4. Autonomic Scaling Intent Mechanism 370 Scaling intent configuration mechanism allows the client to 371 configure automatic scale-in and scale-out mechanisms on both the 372 TE-tunnel and the VN level. Various conditions can be set for auto- 373 scaling based on the PM telemetry data. 375 There are a number of parameters involved in the mechanism: 377 . scale-out-intent or scale-in-intent: whether to scale-out or 378 scale-in. 379 . performance-type: performance metric type (e.g., one-way-delay, 380 one-way-delay-min, one-way-delay-max, two-way-delay, two-way- 381 delay-min, two-way-delay-max, utilized bandwidth, etc.) 383 . threshold-value: the threshold value for a certain performance- 384 type that triggers scale-in or scale-out. 385 . scaling-operation-type: in case where scaling condition can be 386 set with one or more performance types, then scaling-operation- 387 type (AND, OR, MIN, MAX, etc.) is applied to these selected 388 performance types and its threshold values. 389 . Threshold-time: the duration for which the criteria must hold 390 true. 391 . Cooldown-time: the duration after a scaling action has been 392 triggered, for which there will be no further operation. 394 The following tree is a part of ietf-te-kpi-telemetry tree whose 395 model is presented in full detail in Sections 6 & 7. 397 module: ietf-te-kpi-telemetry 398 augment /te:te/te:tunnels/te:tunnel: 399 +-rw te-scaling-intent 400 | +-rw scale-in-intent 401 | | +-rw threshold-time? uint32 402 | | +-rw cooldown-time? uint32 403 | | +-rw scale-in-operation-type? scaling-criteria-operation 404 | | +-rw scaling-condition* [performance-type] 405 | | +-rw performance-type identityref 406 | | +-rw threshold-value? string 407 | | +-rw te-telemetry-tunnel-ref? 408 -> /te:te/tunnels/tunnel/name 409 | +-rw scale-out-intent 410 | +-rw threshold-time? uint32 411 | +-rw cooldown-time? uint32 412 | +-rw scale-out-operation-type? scaling-criteria-operation 413 | +-rw scaling-condition* [performance-type] 414 | +-rw performance-type identityref 415 | +-rw threshold-value? string 416 | +-rw te-telemetry-tunnel-ref? 417 -> /te:te/tunnels/tunnel/name 419 Let say the client wants to set the scaling out operation based on 420 two performance-types (e.g., two-way-delay and utilized-bandwidth 421 for a te-tunnel), it can be done as follows: 423 . Set Threshold-time: x (sec) (duration for which the criteria 424 must hold true) 426 . Set Cooldown-time: y (sec) (the duration after a scaling 427 action has been triggered, for which there will be no further 428 operation) 429 . Set AND for the scale-out-operation-type 431 In the scaling condition's list, the following two components can be 432 set: 434 List 1: Scaling Condition for Two-way-delay 436 . performance type: Two-way-delay 437 . threshold-value: z milli-seconds 439 List 2: Scaling Condition for Utilized bandwidth 441 . performance type: Utilized bandwidth 442 . threshold-value: w megabytes 444 5. Notification 446 This model does not define specific notifications. To enable 447 notifications, the mechanism defined in [YANG-PUSH] 448 and [Event-Notification] can be used. This mechanism currently 449 allows the user to: 451 . Subscribe to notifications on a per client basis. 453 . Specify subtree filters or xpath filters so that only interested 454 contents will be sent. 456 . Specify either periodic or on-demand notifications. 458 5.1. YANG Push Subscription Examples 460 [YANG-PUSH] allows subscriber applications to request a continuous, 461 customized stream of updates from a YANG datastore. 463 Below example shows the way for a client to subscribe to the 464 telemetry information for a particular tunnel (Tunnel1). The 465 telemetry parameter that the client is interested in is one-way- 466 delay. 468 470 472 473 474 475 476 Tunnel1 477 478 479 481 482 483 484 485 486 487 488 500 489 encode-xml 490 491 493 This example shows the way for a client to subscribe to the 494 telemetry information for all VNs. The telemetry parameter that the 495 client is interested in is one-way-delay and one-way-utilized- 496 bandwidth. 498 500 502 503 504 505 506 507 508 510 511 512 513 514 515 516 517 500 518 519 521 6. YANG Data Tree 523 module: ietf-te-kpi-telemetry 524 augment /te:te/te:tunnels/te:tunnel: 525 +--rw te-scaling-intent 526 | +--rw scale-in-intent 527 | | +--rw threshold-time? uint32 528 | | +--rw cooldown-time? uint32 529 | | +--rw scale-in-operation-type? scaling-criteria-operation 530 | | +--rw scaling-condition* [performance-type] 531 | | +--rw performance-type identityref 532 | | +--rw threshold-value? string 533 | | +--rw te-telemetry-tunnel-ref? 534 | | -> /te:te/tunnels/tunnel/name 535 | +--rw scale-out-intent 536 | +--rw threshold-time? uint32 537 | +--rw cooldown-time? uint32 538 | +--rw scale-out-operation-type? scaling-criteria-operation 539 | +--rw scaling-condition* [performance-type] 540 | +--rw performance-type identityref 541 | +--rw threshold-value? string 542 | +--rw te-telemetry-tunnel-ref? 543 | -> /te:te/tunnels/tunnel/name 544 +--ro te-telemetry 545 +--ro id? string 546 +--ro performance-metrics-one-way 547 | +--ro one-way-delay? uint32 548 | +--ro one-way-delay-normality? 549 | | te-types:performance-metrics-normality 550 | +--ro one-way-residual-bandwidth? 551 | | rt-types:bandwidth-ieee-float32 552 | +--ro one-way-residual-bandwidth-normality? 553 | | te-types:performance-metrics-normality 554 | +--ro one-way-available-bandwidth? 555 | | rt-types:bandwidth-ieee-float32 556 | +--ro one-way-available-bandwidth-normality? 557 | | te-types:performance-metrics-normality 558 | +--ro one-way-utilized-bandwidth? 559 | | rt-types:bandwidth-ieee-float32 560 | +--ro one-way-utilized-bandwidth-normality? 561 | te-types:performance-metrics-normality 562 +--ro performance-metrics-two-way 563 | +--ro two-way-delay? uint32 564 | +--ro two-way-delay-normality? 565 | te-types:performance-metrics-normality 566 +--ro te-ref? 567 -> /te:te/tunnels/tunnel/name 569 module: ietf-vn-kpi-telemetry 570 augment /vn:vn/vn:vn-list: 572 +--rw vn-scaling-intent 573 | +--rw scale-in-intent 574 | | +--rw threshold-time? uint32 575 | | +--rw cooldown-time? uint32 576 | | +--rw scale-in-operation-type? scaling-criteria-operation 577 | | +--rw scaling-condition* [performance-type] 578 | | +--rw performance-type identityref 579 | | +--rw threshold-value? string 580 | | +--rw te-telemetry-tunnel-ref? 581 | | -> /te:te/tunnels/tunnel/name 582 | +--rw scale-out-intent 583 | +--rw threshold-time? uint32 584 | +--rw cooldown-time? uint32 585 | +--rw scale-out-operation-type? scaling-criteria-operation 586 | +--rw scaling-condition* [performance-type] 587 | +--rw performance-type identityref 588 | +--rw threshold-value? string 589 | +--rw te-telemetry-tunnel-ref? 590 | -> /te:te/tunnels/tunnel/name 591 +--ro vn-telemetry 592 +--ro performance-metrics-one-way 593 | +--ro one-way-delay? uint32 594 | +--ro one-way-delay-normality? 595 | | te-types:performance-metrics-normality 596 | +--ro one-way-residual-bandwidth? 597 | | rt-types:bandwidth-ieee-float32 598 | +--ro one-way-residual-bandwidth-normality? 599 | | te-types:performance-metrics-normality 600 | +--ro one-way-available-bandwidth? 601 | | rt-types:bandwidth-ieee-float32 602 | +--ro one-way-available-bandwidth-normality? 603 | | te-types:performance-metrics-normality 604 | +--ro one-way-utilized-bandwidth? 605 | | rt-types:bandwidth-ieee-float32 606 | +--ro one-way-utilized-bandwidth-normality? 607 | te-types:performance-metrics-normality 608 +--ro performance-metrics-two-way 609 | +--ro two-way-delay? uint32 610 | +--ro two-way-delay-normality? 611 | te-types:performance-metrics-normality 612 +--ro grouping-operation? grouping-operation 613 augment /vn:vn/vn:vn-list/vn:vn-member-list: 614 +--ro vn-member-telemetry 615 +--ro performance-metrics-one-way 616 | +--ro one-way-delay? uint32 617 | +--ro one-way-delay-normality? 618 | | te-types:performance-metrics-normality 619 | +--ro one-way-residual-bandwidth? 620 | | rt-types:bandwidth-ieee-float32 621 | +--ro one-way-residual-bandwidth-normality? 622 | | te-types:performance-metrics-normality 623 | +--ro one-way-available-bandwidth? 624 | | rt-types:bandwidth-ieee-float32 625 | +--ro one-way-available-bandwidth-normality? 626 | | te-types:performance-metrics-normality 627 | +--ro one-way-utilized-bandwidth? 628 | | rt-types:bandwidth-ieee-float32 629 | +--ro one-way-utilized-bandwidth-normality? 630 | te-types:performance-metrics-normality 631 +--ro performance-metrics-two-way 632 | +--ro two-way-delay? uint32 633 | +--ro two-way-delay-normality? 634 | te-types:performance-metrics-normality 635 +--ro te-grouped-params* 636 | -> /te:te/tunnels/tunnel/te-kpi:te-telemetry/id 637 +--ro grouping-operation? grouping-operation 639 7. Yang Data Model 641 7.1. ietf-te-kpi-telemetry model 643 The YANG code is as follows: 645 file "ietf-te-kpi-telemetry@2019-04-18.yang" 647 module ietf-te-kpi-telemetry { 648 yang-version 1.1; 649 namespace "urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry"; 650 prefix te-tel; 652 import ietf-te { 653 prefix te; 654 reference 655 "RFC YYYY: A YANG Data Model for Traffic Engineering 656 Tunnels and Interfaces"; 657 } 659 /* Note: The RFC Editor will replace YYYY with the number 660 assigned to the RFC once draft-ietf-teas-yang-te 661 becomes an RFC.*/ 663 import ietf-te-types { 664 prefix te-types; 665 reference 666 "RFC YYYY: Traffic Engineering Common YANG Types"; 667 } 669 /* Note: The RFC Editor will replace YYYY with the number 670 assigned to the RFC once draft-ietf-teas-yang-te-types 671 becomes an RFC.*/ 673 organization 674 "IETF Traffic Engineering Architecture and Signaling (TEAS) 675 Working Group"; 676 contact 677 "Editor: Young Lee 678 Editor: Dhruv Dhody 679 Editor: Ricard Vilalta 680 Editor: Satish Karunanithi "; 681 description 682 "This module describes YANG data model for performance 683 monitoring telemetry for te tunnels. 685 Copyright (c) 2019 IETF Trust and the persons identified 686 as authors of the code. All rights reserved. 688 Redistribution and use in source and binary forms, with 689 or without modification, is permitted pursuant to, and 690 subject to the license terms contained in, the Simplified 691 BSD License set forth in Section 4.c of the IETF Trust's 692 Legal Provisions Relating to IETF Documents 693 (http://trustee.ietf.org/license-info). 695 This version of this YANG module is part of RFC XXXX; see 696 the RFC itself for full legal notices."; 698 /* Note: The RFC Editor will replace XXXX with the number 699 assigned to the RFC once draft-lee-teas-pm-telemetry- 700 autonomics becomes an RFC.*/ 702 revision 2019-04-18 { 703 description 704 "Initial revision. This YANG file defines 705 a YANG model for TE telemetry."; 706 reference "Derived from earlier versions of base YANG files"; 707 } 709 identity telemetry-param-type { 710 description 711 "Base identity for telemetry param types"; 712 } 714 identity one-way-delay { 715 base telemetry-param-type; 716 description 717 "To specify average Delay in one (forward) 718 direction"; 720 reference 721 "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions. 722 RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions. 723 RFC7823: Performance-Based Path Selection for Explicitly 724 Routed Label Switched Paths (LSPs) Using TE Metric 725 Extensions"; 726 } 728 identity two-way-delay { 729 base telemetry-param-type; 730 description 731 "To specify average Delay in both (forward and reverse) 732 directions"; 733 reference 734 "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions. 735 RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions. 736 RFC7823: Performance-Based Path Selection for Explicitly 737 Routed Label Switched Paths (LSPs) Using TE Metric 738 Extensions"; 739 } 741 identity one-way-delay-variation { 742 base telemetry-param-type; 743 description 744 "To specify average Delay Variation in one (forward) direction"; 745 reference 746 "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions. 747 RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions. 748 RFC7823: Performance-Based Path Selection for Explicitly 749 Routed Label Switched Paths (LSPs) Using TE Metric 750 Extensions"; 751 } 753 identity two-way-delay-variation { 754 base telemetry-param-type; 755 description 756 "To specify average Delay Variation in both (forward and reverse) 757 directions"; 758 reference 759 "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions. 760 RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions. 761 RFC7823: Performance-Based Path Selection for Explicitly 762 Routed Label Switched Paths (LSPs) Using TE Metric 763 Extensions"; 764 } 766 identity utilized-bandwidth { 767 base telemetry-param-type; 768 description 769 "To specify utilized bandwidth over the specified source 770 and destination."; 771 reference 772 "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions. 773 RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions. 774 RFC7823: Performance-Based Path Selection for Explicitly 775 Routed Label Switched Paths (LSPs) Using TE Metric 776 Extensions"; 777 } 779 identity utilized-percentage { 780 base telemetry-param-type; 781 description 782 "To specify utilization percentage of the entity 783 (e.g., tunnel, link, etc.)"; 784 } 786 typedef scaling-criteria-operation { 787 type enumeration { 788 enum AND { 789 description 790 "AND operation"; 791 } 792 enum OR { 793 description 794 "OR operation"; 795 } 796 } 797 description 798 "Operations to analize list of scaling criterias"; 799 } 801 grouping scaling-duration { 802 description 803 "Base scaling criteria durations"; 804 leaf threshold-time { 805 type uint32; 806 units "seconds"; 807 description 808 "The duration for which the criteria must hold true"; 809 } 810 leaf cooldown-time { 811 type uint32; 812 units "seconds"; 813 description 814 "The duration after a scaling-in/scaling-out action has been 815 triggered, for which there will be no further operation"; 816 } 817 } 819 grouping scaling-criteria { 820 description 821 "Grouping for scaling criteria"; 822 leaf performance-type { 823 type identityref { 824 base telemetry-param-type; 825 } 826 description 827 "Reference to the tunnel level telemetry type"; 828 } 829 leaf threshold-value { 830 type string; 831 description 832 "Scaling threshold for the telemetry parameter type"; 833 } 834 leaf te-telemetry-tunnel-ref { 835 type leafref { 836 path "/te:te/te:tunnels/te:tunnel/te:name"; 837 } 838 description 839 "Reference to tunnel"; 840 } 841 } 843 grouping scaling-in-intent { 844 description 845 "Basic scaling in intent"; 846 uses scaling-duration; 847 leaf scale-in-operation-type { 848 type scaling-criteria-operation; 849 default "AND"; 850 description 851 "Operation to be applied to check between 852 scaling criterias to check if the scale in 853 threshold condition has been met. 854 Defaults to AND"; 855 } 856 list scaling-condition { 857 key "performance-type"; 858 description 859 "Scaling conditions"; 860 uses scaling-criteria; 862 } 863 } 865 grouping scaling-out-intent { 866 description 867 "Basic scaling out intent"; 868 uses scaling-duration; 869 leaf scale-out-operation-type { 870 type scaling-criteria-operation; 871 default "OR"; 872 description 873 "Operation to be applied to check between 874 scaling criterias to check if the scale out 875 threshold condition has been met. 876 Defauls to OR"; 877 } 878 list scaling-condition { 879 key "performance-type"; 880 description 881 "Scaling conditions"; 882 uses scaling-criteria; 883 } 884 } 886 augment "/te:te/te:tunnels/te:tunnel" { 887 description 888 "Augmentation parameters for config scaling-criteria 889 TE tunnel topologies. Scale in/out criteria might be used 890 for network autonomics in order the controller 891 to react to a certain set of monitored params."; 892 container te-scaling-intent { 893 description 894 "scaling intent"; 895 container scale-in-intent { 896 description 897 "scale-in"; 898 uses scaling-in-intent; 899 } 900 container scale-out-intent { 901 description 902 "scale-out"; 903 uses scaling-out-intent; 904 } 905 } 906 container te-telemetry { 907 config false; 908 description 909 "telemetry params"; 910 leaf id { 911 type string; 912 description 913 "Id of telemetry param"; 914 } 915 uses te-types:performance-metrics-attributes; 916 leaf te-ref { 917 type leafref { 918 path "/te:te/te:tunnels/te:tunnel/te:name"; 919 } 920 description 921 "Reference to measured te tunnel"; 922 } 923 } 924 } 925 } 926 928 7.2. ietf-vn-kpi-telemetry model 930 The YANG code is as follows: 932 file "ietf-vn-kpi-telemetry@2019-04-18.yang" 934 module ietf-vn-kpi-telemetry { 935 yang-version 1.1; 936 namespace "urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry"; 937 prefix vn-tel; 939 import ietf-vn { 940 prefix vn; 941 reference 942 "RFC YYYY: A YANG Data Model for VN Operation"; 943 } 945 /* Note: The RFC Editor will replace YYYY with the number 946 assigned to the RFC once draft-ietf-teas-actn-vn-yang 947 becomes an RFC.*/ 949 import ietf-te { 950 prefix te; 951 reference 952 "RFC YYYY: A YANG Data Model for Traffic Engineering 953 Tunnels and Interfaces"; 954 } 956 /* Note: The RFC Editor will replace YYYY with the number 957 assigned to the RFC once draft-ietf-teas-yang-te 958 becomes an RFC.*/ 960 import ietf-te-types { 961 prefix te-types; 962 reference 963 "RFC YYYY: Traffic Engineering Common YANG Types"; 964 } 966 /* Note: The RFC Editor will replace YYYY with the number 967 assigned to the RFC once draft-ietf-teas-yang-te-types 968 becomes an RFC.*/ 970 import ietf-te-kpi-telemetry { 971 prefix te-kpi; 972 reference 973 "RFC YYYY: YANG models for VN & TE Performance Monitoring 974 Telemetry and Scaling Intent Autonomics"; 975 } 977 /* Note: The RFC Editor will replace YYYY with the number 978 assigned to the RFC once draft-lee-teas-actn-pm-telemetry 979 -autonomics becomes an RFC.*/ 981 organization 982 "IETF Traffic Engineering Architecture and Signaling (TEAS) 983 Working Group"; 984 contact 985 "Editor: Young Lee 986 Editor: Dhruv Dhody 987 Editor: Ricard Vilalta 988 Editor: Satish Karunanithi "; 990 description 991 "This module describes YANG data models for performance 992 monitoring telemetry for vn. 994 Copyright (c) 2019 IETF Trust and the persons identified 995 as authors of the code. All rights reserved. 997 Redistribution and use in source and binary forms, with 998 or without modification, is permitted pursuant to, and 999 subject to the license terms contained in, the Simplified 1000 BSD License set forth in Section 4.c of the IETF Trust's 1001 Legal Provisions Relating to IETF Documents 1002 (http://trustee.ietf.org/license-info). 1004 This version of this YANG module is part of RFC XXXX; see 1005 the RFC itself for full legal notices."; 1007 /* Note: The RFC Editor will replace XXXX with the number 1008 assigned to the RFC once draft-lee-teas-pm-telemetry- 1009 autonomics becomes an RFC.*/ 1011 revision 2019-04-18 { 1012 description 1013 "Initial revision. This YANG file defines 1014 the VN telemetry."; 1015 reference "Derived from earlier versions of base YANG files"; 1016 } 1018 typedef grouping-operation { 1019 type enumeration { 1020 enum MINIMUM { 1021 description 1022 "Select the minimum param"; 1023 } 1024 enum MAXIMUM { 1025 description 1026 "Select the maximum param"; 1027 } 1028 enum MEAN { 1029 description 1030 "Select the MEAN of the params"; 1031 } 1032 enum STD_DEV { 1033 description 1034 "Select the standard deviation of the 1035 monitored params"; 1036 } 1037 enum AND { 1038 description 1039 "Select the AND of the params"; 1040 } 1041 enum OR { 1042 description 1043 "Select the OR of the params"; 1044 } 1045 } 1046 description 1047 "Operations to analize list of monitored params"; 1048 } 1050 grouping vn-telemetry-param { 1051 description 1052 "augment of te-kpi:telemetry-param for VN specific params"; 1053 leaf-list te-grouped-params { 1054 type leafref { 1055 path "/te:te/te:tunnels/te:tunnel/te-kpi:te-telemetry/te-kpi:id"; 1056 } 1057 description 1058 "Allows the definition of a vn-telemetry param 1059 as a grouping of underlying TE params"; 1060 } 1061 leaf grouping-operation { 1062 type grouping-operation; 1063 description 1064 "describes the operation to apply to 1065 te-grouped-params"; 1066 } 1067 } 1069 augment "/vn:vn/vn:vn-list" { 1070 description 1071 "Augmentation parameters for state TE VN topologies."; 1072 container vn-scaling-intent { 1073 description 1074 "scaling intent"; 1075 container scale-in-intent { 1076 description 1077 "VN scale-in"; 1078 uses te-kpi:scaling-in-intent; 1079 } 1080 container scale-out-intent { 1081 description 1082 "VN scale-out"; 1083 uses te-kpi:scaling-out-intent; 1084 } 1085 } 1086 container vn-telemetry { 1087 config false; 1088 description 1089 "VN telemetry params"; 1090 uses te-types:performance-metrics-attributes; 1091 leaf grouping-operation { 1092 type grouping-operation; 1093 description 1094 "describes the operation to apply to the VN-members"; 1095 } 1096 } 1097 } 1098 augment "/vn:vn/vn:vn-list/vn:vn-member-list" { 1099 description 1100 "Augmentation parameters for state TE vn member topologies."; 1101 container vn-member-telemetry { 1102 config false; 1103 description 1104 "VN member telemetry params"; 1105 uses te-types:performance-metrics-attributes; 1106 uses vn-telemetry-param; 1107 } 1108 } 1109 } 1110 1112 8. Security Considerations 1114 The YANG module specified in this document defines a schema for data 1115 that is designed to be accessed via network management protocols 1116 such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF 1117 layer is the secure transport layer, and the mandatory-to-implement 1118 secure transport is Secure Shell (SSH) [RFC6242]. The lowest 1119 RESTCONF layer is HTTPS, and the mandatory-to-implement secure 1120 transport is TLS [RFC8446]. 1122 The NETCONF access control model [RFC8341] provides the means to 1123 restrict access for particular NETCONF users to a preconfigured 1124 subset of all available NETCONF protocol operations and content. The 1125 NETCONF Protocol over Secure Shell (SSH) [RFC6242] describes a 1126 method for invoking and running NETCONF within a Secure Shell (SSH) 1127 session as an SSH subsystem. The Network Configuration Access 1128 Control Model (NACM) [RFC8341] provides the means to restrict access 1129 for particular NETCONF or RESTCONF users to a preconfigured subset 1130 of all available NETCONF or RESTCONF protocol operations and 1131 content. 1133 A number of configuration data nodes defined in this document are 1134 writable/deletable (i.e., "config true"). These data nodes may be 1135 considered sensitive or vulnerable in some network environments. 1137 There are a number of data nodes defined in this YANG module that 1138 are writable/creatable/deletable (i.e., config true, which is the 1139 default). These data nodes may be considered sensitive or 1140 vulnerable in some network environments. Write operations (e.g., 1141 edit-config) to these data nodes without proper protection can have 1142 a negative effect on network operations. These are the subtrees and 1143 data nodes and their sensitivity/vulnerability: 1145 /te:te/te:tunnels/te:tunnel/te-scaling-intent/scale-in-intent 1146 /te:te/te:tunnels/te:tunnel/te-scaling-intent/scale-out-intent 1148 /vn:vn/vn:vn-list/vn-scaling-intent/scale-in-intent 1149 /vn:vn/vn:vn-list/vn-scaling-intent/scale-out-intent 1151 9. IANA Considerations 1153 This document registers the following namespace URIs in the IETF XML 1154 registry [RFC3688]: 1156 -------------------------------------------------------------------- 1157 URI: urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry 1158 Registrant Contact: The IESG. 1159 XML: N/A, the requested URI is an XML namespace. 1160 -------------------------------------------------------------------- 1162 -------------------------------------------------------------------- 1163 URI: urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry 1164 Registrant Contact: The IESG. 1165 XML: N/A, the requested URI is an XML namespace. 1166 -------------------------------------------------------------------- 1168 This document registers the following YANG modules in the YANG 1169 Module. 1171 Names registry [RFC7950]: 1173 -------------------------------------------------------------------- 1174 name: ietf-te-kpi-telemetry 1175 namespace: urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry 1176 prefix: te-tel 1177 reference: RFC XXXX (TDB) 1178 -------------------------------------------------------------------- 1180 -------------------------------------------------------------------- 1181 name: ietf-vn-kpi-telemetry 1182 namespace: urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry 1183 prefix: vn-tel 1184 reference: RFC XXXX (TDB) 1185 -------------------------------------------------------------------- 1187 10. Acknowledgements 1189 We thank Rakesh Gandhi, Tarek Saad and Igor Bryskin for useful 1190 discussions and their suggestions for this work. 1192 11. References 1194 11.1. Normative References 1196 [RFC6242] M. Wasserman, "Using the NETCONF Protocol over Secure 1197 Shell (SSH)", RFC 6242, June 2011. 1199 [RFC7926] A. Farrel (Ed.), "Problem Statement and Architecture for 1200 Information Exchange between Interconnected Traffic- 1201 Engineered Networks", RFC 7926, July 2016. 1203 [RFC7950] M. Bjorklund, Ed., "The YANG 1.1 Data Modeling Language", 1204 August 2016. 1206 [RFC8040] A. Bierman, M. Bjorklund, K. Watsen, "RESTCONF Protocol", 1207 RFC 8040, January 2017. 1209 [RFC8233] D. Dhody, et al., "Extensions to the Path Computation 1210 Element Communication Protocol (PCEP) to compute service 1211 aware Label Switched Path (LSP)", RFC 8233, September 1212 2017. 1214 [RFC8341] A. Bierman, M. Bjorklund, "Network Configuration Access 1215 Control Model", RFC 8341, March 2018. 1217 [RFC8342] M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. 1218 Wilton, "Network Management Datastore Architecture 1219 (NMDA)", RFC 8342, March 2018. 1221 [RFC8446] E. Rescorla, "The Transport Layer Security (TLS) Protocol 1222 Version 1.3", RFC8446, August 2018. 1224 [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic 1225 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 1226 te, work in progress. 1228 [TE-Types] T. Saad, et.al, "Traffic Engineering Common YANG Types", 1229 draft-ietf-teas-yang-te-types, work in progress. 1231 [VN] Y. Lee (Editor), "A Yang Data Model for ACTN VN Operation", 1232 draft-lee-teas-actn-vn-yang, work in progress. 1234 11.2. Informative References 1236 [RFC3688] M. Mealling, "The IETF XML Registry", RFC 3688, January 1237 2004. 1239 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1240 and A. Bierman, Ed., "Network Configuration Protocol 1241 (NETCONF)", RFC 6241. 1243 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1244 Previdi, "OSPF Traffic Engineering (TE) Metric 1245 Extensions", RFC 7471, March 2015. 1247 [RFC7823] Atlas, A., Drake, J., Giacalone, S., and S. 1248 Previdi,"Performance-Based Path Selection for Explicitly 1249 Routed Label Switched Paths (LSPs) Using TE Metric 1250 Extensions", RFC 7823, May 2016. 1252 [RFC8294] X. Liu, et al, "Routing Area Common YANG Data Types", RFC 1253 8294, December 2017. 1255 [RFC8340] M. Bjorklund and L. Berger (Editors), "YANG Tree 1256 Diagrams", RFC 8340, March 2018. 1258 [YANG-PUSH] A. Clemm, et al, "Subscription to YANG Datastores", 1259 draft-ietf-netconf-yang-push, work in progress. 1261 [Event-Notification] E. Voit, et al, "Dynamic subscription to YANG 1262 Events and Datastores over NETCONF", draft-ietf-netconf- 1263 netconf-event-notifications, work in progress. 1265 [PERF] Y. XU, et al., "Use Cases and Requirements of Dynamic Service 1266 Control based on Performance Monitoring in ACTN 1267 Architecture", draft-xu-actn-perf-dynamic-service-control, 1268 work in progress. 1270 [RFC8309] Q. Wu, W. Cheng, and A. Farrel. "Service Models 1271 Explained", RFC 8309, January 2018. 1273 [RFC8453] D. Ceccarelli and Y. Lee (Editors), "Framework for 1274 Abstraction and Control of Traffic Engineered Networks", 1275 RFC 8453, August 2018. 1277 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 1278 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 1279 Metric Extensions", RFC 8570, March 2019. 1281 12. Contributors 1283 Authors' Addresses 1285 Young Lee 1286 Futurewei Technologies 1287 5340 Legacy Drive Suite 173 1288 Plano, TX 75024, USA 1290 Email: younglee.tx@gmail.com 1292 Dhruv Dhody 1293 Huawei Technology 1294 Leela Palace 1295 Bangalore, Karnataka 560008 1296 India 1298 Email: dhruv.dhody@huawei.com 1300 Satish Karunanithi 1301 Huawei Technology 1302 Leela Palace 1303 Bangalore, Karnataka 560008 1304 India 1306 Email: satish.karunanithi@gmail.com 1307 Ricard Vilalta 1308 Centre Tecnologic de Telecomunicacions de Catalunya (CTTC/CERCA) 1309 Av. Carl Friedrich Gauss 7 1310 08860 - Castelldefels 1311 Barcelona (Spain) 1312 Email: ricard.vilalta@cttc.es 1314 Daniel King 1315 Lancaster University 1317 Email: d.king@lancaster.ac.uk 1319 Daniele Ceccarelli 1320 Ericsson 1321 Torshamnsgatan,48 1322 Stockholm, Sweden 1324 Email: daniele.ceccarelli@ericsson.com