idnits 2.17.1 draft-ietf-teas-actn-pm-telemetry-autonomics-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 19, 2021) is 1161 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: 'RFCXXXX' is mentioned on line 205, but not defined == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-10 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-25 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group Y. Lee, Ed. 3 Internet-Draft Samsung Electronics 4 Intended status: Standards Track D. Dhody, Ed. 5 Expires: August 23, 2021 S. Karunanithi 6 Huawei Technologies 7 R. Vilalta 8 CTTC 9 D. King 10 Lancaster University 11 D. Ceccarelli 12 Ericsson 13 February 19, 2021 15 YANG models for VN/TE Performance Monitoring Telemetry and Scaling 16 Intent Autonomics 17 draft-ietf-teas-actn-pm-telemetry-autonomics-05 19 Abstract 21 This document provides YANG data models that describe performance 22 monitoring telemetry and scaling intent mechanism for TE-tunnels and 23 Virtual Networks (VN). 25 The models presented in this draft allow customers to subscribe to 26 and monitor their key performance data of their interest on the level 27 of TE-tunnel or VN. The models also provide customers with the 28 ability to program autonomic scaling intent mechanism on the level of 29 TE-tunnel as well as VN. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 23, 2021. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1.1. Requirements Language . . . . . . . . . . . . . . . . 4 68 1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 4 69 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5 70 2. Use-Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Design of the Data Models . . . . . . . . . . . . . . . . . . 7 72 3.1. TE KPI Telemetry Model . . . . . . . . . . . . . . . . . 7 73 3.2. VN KPI Telemetry Model . . . . . . . . . . . . . . . . . 8 74 4. Autonomic Scaling Intent Mechanism . . . . . . . . . . . . . 9 75 5. Notification . . . . . . . . . . . . . . . . . . . . . . . . 11 76 5.1. YANG Push Subscription Examples . . . . . . . . . . . . . 11 77 6. YANG Data Tree . . . . . . . . . . . . . . . . . . . . . . . 13 78 7. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 16 79 7.1. ietf-te-kpi-telemetry model . . . . . . . . . . . . . . . 16 80 7.2. ietf-vn-kpi-telemetry model . . . . . . . . . . . . . . . 23 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 28 86 11.2. Informative References . . . . . . . . . . . . . . . . . 30 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 89 1. Introduction 91 The YANG [RFC7950] model discussed in [I-D.ietf-teas-actn-vn-yang] is 92 used to operate customer-driven Virtual Networks (VNs) during the VN 93 instantiation, VN computation, and its life-cycle service management 94 and operations. YANG model discussed in [I-D.ietf-teas-yang-te] is 95 used to operate TE-tunnels during the tunnel instantiation, and its 96 life-cycle management and operations. 98 The models presented in this draft allow the applications hosted by 99 the customers to subscribe to and monitor their key performance data 100 of their interest on the level of VN [I-D.ietf-teas-actn-vn-yang] or 101 TE-tunnel [I-D.ietf-teas-yang-te]. The key characteristic of the 102 models presented in this document is a top-down programmability that 103 allows the applications hosted by the customers to subscribe to and 104 monitor key performance data of their interest and autonomic scaling 105 intent mechanism on the level of VN as well as TE-tunnel. 107 According to the classification of [RFC8309], the YANG data models 108 presented in this document can be classified as customer service 109 models, which is mapped to CMI (Customer Network Controller (CNC)- 110 Multi-Domain Service Coordinator (MSDC) interface) of ACTN [RFC8453]. 112 [RFC8233] describes key network performance data to be considered for 113 end-to-end path computation in TE networks. Key performance 114 indicator (KPI) is a term that describes critical performance data 115 that may affect VN/TE-tunnel service. The services provided can be 116 optimized to meet the requirements (such as traffic patterns, 117 quality, and reliability) of the applications hosted by the 118 customers. 120 This document provides YANG data models generically applicable to any 121 VN/TE-Tunnel service clients to provide an ability to program their 122 customized performance monitoring subscription and publication data 123 models and automatic scaling in/out intent data models. These models 124 can be utilized by a client network controller to initiate these 125 capability to a transport network controller communicating with the 126 client controller via a NETCONF [RFC8341] or a RESTCONF [RFC8040] 127 interface. 129 The term performance monitoring being used in this document is 130 different from the term that has been used in transport networks for 131 many years. Performance monitoring in this document refers to 132 subscription and publication of streaming telemetry data. 133 Subscription is initiated by the client (e.g., CNC) while publication 134 is provided by the network (e.g., MDSC/PNC) based on the client's 135 subscription. As the scope of performance monitoring in this 136 document is telemetry data on the level of client's VN or TE- tunnel, 137 the entity interfacing the client (e.g., MDSC) has to provide VN or 138 TE-tunnel level information. This would require controller 139 capability to derive VN or TE-tunnel level performance data based on 140 lower-level data collected via PM counters in the Network Elements 141 (NE). How the controller entity derives such customized level data 142 (i.e., VN or TE-tunnel level) is out of the scope of this document. 144 The data model includes configuration and state data according to the 145 new Network Management Datastore Architecture [RFC8342]. 147 [Editor's Note: A suggestion is made to remove the word KPI from the 148 name of the model. Further discussion is needed.] 150 1.1. Terminology 152 Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used 153 in this document. 155 Key Performance Data: This refers to a set of data the customer is 156 interested in monitoring for their instantiated VNs or TE-tunnels. 157 Key performance data and key performance indicators are inter- 158 exchangeable in this draft. 160 Scaling: This refers to the network ability to re-shape its own 161 resources. Scale out refers to improve network performance by 162 increasing the allocated resources, while scale in refers to decrease 163 the allocated resources, typically because the existing resources are 164 unnecessary. 166 Scaling Intent: To declare scaling conditions, scaling intent is 167 used. Specifically, scaling intent refers to the intent expressed by 168 the client that allows the client to program/configure conditions of 169 their key performance data either for scaling out or scaling in. 170 Various conditions can be set for scaling intent on either VN or TE- 171 tunnel level. 173 Network Autonomics: This refers to the network automation capability 174 that allows client to initiate scaling intent mechanisms and provides 175 the client with the status of the adjusted network resources based on 176 the client's scaling intent in an automated fashion. 178 1.1.1. Requirements Language 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 182 "OPTIONAL" in this document are to be interpreted as described in BCP 183 14 [RFC2119] [RFC8174] when, and only when, they appear in all 184 capitals, as shown here. 186 1.2. Tree diagram 188 A simplified graphical representation of the data model is used in 189 Section 5 of this this document. The meaning of the symbols in these 190 diagrams is defined in [RFC8340]. 192 1.3. Prefixes in Data Node Names 194 In this document, names of data nodes and other data model objects 195 are prefixed using the standard prefix associated with the 196 corresponding YANG imported modules, as shown in Table 1. 198 +----------+-----------------------+------------------------------+ 199 | Prefix | YANG module | Reference | 200 +----------+-----------------------+------------------------------+ 201 | te | ietf-te | [I-D.ietf-teas-yang-te] | 202 | te-types | ietf-te-types | [RFC8776] | 203 | te-tel | ietf-te-kpi-telemetry | [RFCXXXX] | 204 | vn | ietf-vn | [I-D.ietf-teas-actn-vn-yang] | 205 | vn-tel | ietf-vn-kpi-telemetry | [RFCXXXX] | 206 +----------+-----------------------+------------------------------+ 208 Table 1: Prefixes and corresponding YANG modules 210 Note: The RFC Editor will replace XXXX with the number assigned to 211 the RFC once this draft becomes an RFC. 213 Further, the following additional documents are refrenced in the 214 model defined in this document - 216 o [RFC7471] - OSPF Traffic Engineering (TE) Metric Extensions. 218 o [RFC8570] - IS-IS Traffic Engineering (TE) Metric Extensions. 220 o [RFC7823] - Performance-Based Path Selection for Explicitly Routed 221 Label Switched Paths (LSPs) Using TE Metric Extensions. 223 2. Use-Cases 225 [I-D.xu-actn-perf-dynamic-service-control] describes use-cases 226 relevant to this draft. It introduces the dynamic creation, 227 modification and optimization of services based on the performance 228 monitoring. Figure 1 shows a high-level workflows for dynamic 229 service control based on traffic monitoring. 231 +----------------------------------------------+ 232 | Client +-----------------------------+ | 233 | | Dynamic Service Control APP | | 234 | +-----------------------------+ | 235 +----------------------------------------------+ 236 1.Traffic| /|\4.Traffic | /|\ 237 Monitor& | | Monitor | | 8.Traffic 238 Optimize | | Result 5.Service | | modify & 239 Policy | | modify& | | optimize 240 \|/ | optimize Req.\|/ | result 241 +----------------------------------------------+ 242 | Orchestrator | 243 | +-------------------------------+ | 244 | |Dynamic Service Control Agent | | 245 | +-------------------------------+ | 246 | +---------------+ +-------------------+ | 247 | | Flow Optimize | | vConnection Agent | | 248 | +---------------+ +-------------------+ | 249 +----------------------------------------------+ 250 2. Path | /|\3.Traffic | /|\ 251 Monitor | | Monitor | |7.Path 252 Request | | Result 6.Path | | modify & 253 | | modify& | | optimize 254 \|/ | optimize Req.\|/ | result 255 +----------------------------------------------+ 256 | Network SDN Controller | 257 | +----------------------+ +-----------------+| 258 | | Network Provisioning | |Abstract Topology|| 259 | +----------------------+ +-----------------+| 260 | +------------------+ +--------------------+ | 261 | |Network Monitoring| |Physical Topology DB| | 262 | +------------------+ +--------------------+ | 263 +----------------------------------------------+ 265 Figure 1: Workflows for dynamic service control based on traffic 266 monitoring 268 Some of the key points from 269 [I-D.xu-actn-perf-dynamic-service-control] are as follows: 271 o Network traffic monitoring is important to facilitate automatic 272 discovery of the imbalance of network traffic, and initiate the 273 network optimization, thus helping the network operator or the 274 virtual network service provider to use the network more 275 efficiently and save the Capital Expense (CAPEX) and the Operating 276 Expense (OPEX). 278 o Customer services have various Service Level Agreement (SLA) 279 requirements, such as service availability, latency, latency 280 jitter, packet loss rate, Bit Error Rate (BER), etc. The 281 transport network can satisfy service availability and BER 282 requirements by providing different protection and restoration 283 mechanisms. However, for other performance parameters, there are 284 no such mechanisms. In order to provide high quality services 285 according to customer SLA, one possible solution is to measure the 286 SLA related performance parameters, and dynamically provision and 287 optimize services based on the performance monitoring results. 289 o Performance monitoring in a large scale network could generate a 290 huge amount of performance information. Therefore, the 291 appropriate way to deliver the information in the client and 292 network interfaces should be carefully considered. 294 3. Design of the Data Models 296 The YANG models developed in this document describe two models: 298 (i) TE KPI Telemetry Model which provides the TE-Tunnel level of 299 performance monitoring mechanism and scaling intent mechanism 300 that allows scale in/out programming by the customer. (See 301 Section 3.1 & Section 7.1 for details). 303 (ii) VN KPI Telemetry Model which provides the VN level of the 304 aggregated performance monitoring mechanism and scaling intent 305 mechanism that allows scale in/out programming by the customer 306 (See Section 3.2 & Section 7.2 for details). 308 3.1. TE KPI Telemetry Model 310 This module describes performance telemetry for TE-tunnel model. The 311 telemetry data is augmented to tunnel state. This module also allows 312 autonomic traffic engineering scaling intent configuration mechanism 313 on the TE-tunnel level. Various conditions can be set for auto- 314 scaling based on the telemetry data (See Section 5 for details) 316 The TE KPI Telemetry Model augments the TE-Tunnel Model to enhance TE 317 performance monitoring capability. This monitoring capability will 318 facilitate proactive re-optimization and reconfiguration of TEs based 319 on the performance monitoring data collected via the TE KPI Telemetry 320 YANG model. 322 +------------+ +--------------+ 323 | TE-Tunnel | | TE KPI | 324 | Model |<---------| Telemetry | 325 +------------+ augments | Model | 326 +--------------+ 328 3.2. VN KPI Telemetry Model 330 This module describes performance telemetry for VN model. The 331 telemetry data is augmented both at the VN Level as well as 332 individual VN member level. This module also allows autonomic 333 traffic engineering scaling intent configuration mechanism on the VN 334 level. Scale in/out criteria might be used for network autonomics in 335 order the controller to react to a certain set of variations in 336 monitored parameters (See Section 4 for illustrations). 338 Moreover, this module also provides mechanism to define aggregated 339 telemetry parameters as a grouping of underlying VN level telemetry 340 parameters. Grouping operation (such as maximum, mean) could be set 341 at the time of configuration. For example, if maximum grouping 342 operation is used for delay at the VN level, the VN telemetry data is 343 reported as the maximum {delay_vn_member_1, delay_vn_member_2,.. 344 delay_vn_member_N}. Thus, this telemetry abstraction mechanism allows 345 the grouping of a certain common set of telemetry values under a 346 grouping operation. This can be done at the VN-member level to 347 suggest how the E2E telemetry be inferred from the per domain tunnel 348 created and monitored by PNCs. One proposed example is the 349 following: 351 +------------------------------------------------------------+ 352 | Client | 353 | | 354 +------------------------------------------------------------+ 355 1.Client sets the | /|\ 2. Orchestrator pushes: 356 grouping op, and | | 357 subscribes to the | | VN level telemetry for 358 VN level telemetry for | | - VN Utilized-bw-percentage 359 Delay and | | (Minimum across VN Members) 360 Utilized-bw-pecentage | | - VN Delay (Maximum across VN 361 \|/ | Members) 362 +------------------------------------------------------------+ 363 | Orchestrator | 364 | | 365 +------------------------------------------------------------+ 367 The VN Telemetry Model augments the basic VN model to enhance VN 368 monitoring capability. This monitoring capability will facilitate 369 proactive re-optimization and reconfiguration of VNs based on the 370 performance monitoring data collected via the VN Telemetry YANG 371 model. 373 +----------+ +--------------+ 374 | VN | augments | VN | 375 | Model |<---------| Telemetry | 376 +----------+ | Model | 377 +--------------+ 379 4. Autonomic Scaling Intent Mechanism 381 Scaling intent configuration mechanism allows the client to configure 382 automatic scale-in and scale-out mechanisms on both the TE-tunnel and 383 the VN level. Various conditions can be set for auto- scaling based 384 on the PM telemetry data. 386 There are a number of parameters involved in the mechanism: 388 o scale-out-intent or scale-in-intent: whether to scale-out or 389 scale-in. 391 o performance-type: performance metric type (e.g., one-way-delay, 392 one-way-delay-min, one-way-delay-max, two-way-delay, two-way- 393 delay-min, two-way-delay-max, utilized bandwidth, etc.) 395 o threshold-value: the threshold value for a certain performance- 396 type that triggers scale-in or scale-out. 398 o scaling-operation-type: in case where scaling condition can be set 399 with one or more performance types, then scaling-operation-type 400 (AND, OR, MIN, MAX, etc.) is applied to these selected performance 401 types and its threshold values. 403 o Threshold-time: the duration for which the criteria MUST hold 404 true. 406 o Cooldown-time: the duration after a scaling action has been 407 triggered, for which there will be no further operation. 409 The following tree is a part of ietf-te-kpi-telemetry tree whose 410 model is presented in full detail in Sections 6 & 7. 412 module: ietf-te-kpi-telemetry 413 augment /te:te/te:tunnels/te:tunnel: 414 +--rw te-scaling-intent 415 | +--rw scale-in-intent 416 | | +--rw threshold-time? uint32 417 | | +--rw cooldown-time? uint32 418 | | +--rw scaling-condition* [performance-type] 419 | | | +--rw performance-type identityref 420 | | | +--rw threshold-value? string 421 | | | +--rw scale-in-operation-type? 422 | | | scaling-criteria-operation 423 | | +--rw scale-in-op? identityref 424 | | +--rw scale? string 425 | +--rw scale-out-intent 426 | +--rw threshold-time? uint32 427 | +--rw cooldown-time? uint32 428 | +--rw scaling-condition* [performance-type] 429 | | +--rw performance-type identityref 430 | | +--rw threshold-value? string 431 | | +--rw scale-out-operation-type? 432 | | scaling-criteria-operation 433 | +--rw scale-out-op? identityref 434 | +--rw scale? string 436 Let say the client wants to set the scaling out operation based on 437 two performance-types (e.g., two-way-delay and utilized-bandwidth for 438 a te-tunnel), it can be done as follows: 440 o Set Threshold-time: x (sec) (duration for which the criteria must 441 hold true) 443 o Set Cooldown-time: y (sec) (the duration after a scaling action 444 has been triggered, for which there will be no further operation) 446 o Set AND for the scale-out-operation-type 448 In the scaling condition's list, the following two components can be 449 set: 451 List 1: Scaling Condition for Two-way-delay 453 o performance type: Two-way-delay 455 o threshold-value: z milli-seconds 457 List 2: Scaling Condition for Utilized bandwidth 459 o performance type: Utilized bandwidth 460 o threshold-value: w megabytes 462 5. Notification 464 This model does not define specific notifications. To enable 465 notifications, the mechanism defined in [RFC8641] and [RFC8640] can 466 be used. This mechanism currently allows the user to: 468 o Subscribe to notifications on a per client basis. 470 o Specify subtree filters or xpath filters so that only interested 471 contents will be sent. 473 o Specify either periodic or on-demand notifications. 475 5.1. YANG Push Subscription Examples 477 [RFC8641] allows subscriber applications to request a continuous, 478 customized stream of updates from a YANG datastore. 480 Below example shows the way for a client to subscribe to the 481 telemetry information for a particular tunnel (Tunnel1). The 482 telemetry parameter that the client is interested in is one-way- 483 delay. 485 487 489 490 491 492 493 Tunnel1 494 495 496 498 499 500 501 502 503 504 505 500 506 encode-xml 507 508 510 This example shows the way for a client to subscribe to the telemetry 511 information for all VNs. The telemetry parameter that the client is 512 interested in is one-way-delay and one-way-utilized- bandwidth. 514 516 518 519 520 521 522 523 524 526 527 528 529 530 531 532 533 500 534 535 537 6. YANG Data Tree 539 module: ietf-te-kpi-telemetry 540 augment /te:te/te:tunnels/te:tunnel: 541 +--rw te-scaling-intent 542 | +--rw scale-in-intent 543 | | +--rw threshold-time? uint32 544 | | +--rw cooldown-time? uint32 545 | | +--rw scaling-condition* [performance-type] 546 | | | +--rw performance-type identityref 547 | | | +--rw threshold-value? string 548 | | | +--rw scale-in-operation-type? 549 | | | scaling-criteria-operation 550 | | +--rw scale-in-op? identityref 551 | | +--rw scale? string 552 | +--rw scale-out-intent 553 | +--rw threshold-time? uint32 554 | +--rw cooldown-time? uint32 555 | +--rw scaling-condition* [performance-type] 556 | | +--rw performance-type identityref 557 | | +--rw threshold-value? string 558 | | +--rw scale-out-operation-type? 559 | | scaling-criteria-operation 560 | +--rw scale-out-op? identityref 561 | +--rw scale? string 562 +--ro te-telemetry 563 +--ro id? telemetry-id 564 +--ro performance-metrics-one-way 565 | +--ro one-way-delay? uint32 566 | +--ro one-way-delay-normality? 567 | | te-types:performance-metrics-normality 568 | +--ro one-way-residual-bandwidth? 569 | | rt-types:bandwidth-ieee-float32 570 | +--ro one-way-residual-bandwidth-normality? 571 | | te-types:performance-metrics-normality 572 | +--ro one-way-available-bandwidth? 573 | | rt-types:bandwidth-ieee-float32 574 | +--ro one-way-available-bandwidth-normality? 575 | | te-types:performance-metrics-normality 576 | +--ro one-way-utilized-bandwidth? 577 | | rt-types:bandwidth-ieee-float32 578 | +--ro one-way-utilized-bandwidth-normality? 579 | te-types:performance-metrics-normality 580 +--ro performance-metrics-two-way 581 +--ro two-way-delay? uint32 582 +--ro two-way-delay-normality? 583 te-types:performance-metrics-normality 585 module: ietf-vn-kpi-telemetry 586 augment /vn:vn/vn:vn: 587 +--rw vn-scaling-intent 588 | +--rw scale-in-intent 589 | | +--rw threshold-time? uint32 590 | | +--rw cooldown-time? uint32 591 | | +--rw scaling-condition* [performance-type] 592 | | | +--rw performance-type identityref 593 | | | +--rw threshold-value? string 594 | | | +--rw scale-in-operation-type? 595 | | | scaling-criteria-operation 596 | | +--rw scale-in-op? identityref 597 | | +--rw scale? string 598 | +--rw scale-out-intent 599 | +--rw threshold-time? uint32 600 | +--rw cooldown-time? uint32 601 | +--rw scaling-condition* [performance-type] 602 | | +--rw performance-type identityref 603 | | +--rw threshold-value? string 604 | | +--rw scale-out-operation-type? 605 | | scaling-criteria-operation 606 | +--rw scale-out-op? identityref 607 | +--rw scale? string 608 +--ro vn-telemetry 609 +--ro performance-metrics-one-way 610 | +--ro one-way-delay? uint32 611 | +--ro one-way-delay-normality? 612 | | te-types:performance-metrics-normality 613 | +--ro one-way-residual-bandwidth? 614 | | rt-types:bandwidth-ieee-float32 615 | +--ro one-way-residual-bandwidth-normality? 616 | | te-types:performance-metrics-normality 617 | +--ro one-way-available-bandwidth? 618 | | rt-types:bandwidth-ieee-float32 619 | +--ro one-way-available-bandwidth-normality? 620 | | te-types:performance-metrics-normality 621 | +--ro one-way-utilized-bandwidth? 622 | | rt-types:bandwidth-ieee-float32 623 | +--ro one-way-utilized-bandwidth-normality? 624 | te-types:performance-metrics-normality 625 +--ro performance-metrics-two-way 626 | +--ro two-way-delay? uint32 627 | +--ro two-way-delay-normality? 628 | te-types:performance-metrics-normality 629 +--ro grouping-operation? grouping-operation 630 augment /vn:vn/vn:vn/vn:vn-member: 631 +--ro vn-member-telemetry 632 +--ro performance-metrics-one-way 633 | +--ro one-way-delay? uint32 634 | +--ro one-way-delay-normality? 635 | | te-types:performance-metrics-normality 636 | +--ro one-way-residual-bandwidth? 637 | | rt-types:bandwidth-ieee-float32 638 | +--ro one-way-residual-bandwidth-normality? 639 | | te-types:performance-metrics-normality 640 | +--ro one-way-available-bandwidth? 641 | | rt-types:bandwidth-ieee-float32 642 | +--ro one-way-available-bandwidth-normality? 643 | | te-types:performance-metrics-normality 644 | +--ro one-way-utilized-bandwidth? 645 | | rt-types:bandwidth-ieee-float32 646 | +--ro one-way-utilized-bandwidth-normality? 647 | te-types:performance-metrics-normality 648 +--ro performance-metrics-two-way 649 | +--ro two-way-delay? uint32 650 | +--ro two-way-delay-normality? 651 | te-types:performance-metrics-normality 652 +--ro te-grouped-params* 653 | -> /te:te/tunnels/tunnel/te-kpi:te-telemetry/id 654 +--ro grouping-operation? grouping-operation 656 7. YANG Data Model 658 7.1. ietf-te-kpi-telemetry model 660 The YANG code is as follows: 662 file "ietf-te-kpi-telemetry@2021-02-19.yang" 663 module ietf-te-kpi-telemetry { 664 yang-version 1.1; 665 namespace "urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry"; 666 prefix te-tel; 668 /* Import TE */ 670 import ietf-te { 671 prefix te; 672 reference 673 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 674 Engineering Tunnels and Interfaces"; 675 } 677 /* Import TE Common types */ 679 import ietf-te-types { 680 prefix te-types; 681 reference 682 "RFC 8776: Common YANG Data Types for Traffic Engineering"; 683 } 685 organization 686 "IETF Traffic Engineering Architecture and Signaling (TEAS) 687 Working Group"; 688 contact 689 "WG Web: 690 WG List: 691 Editor: Young Lee 692 Dhruv Dhody "; 693 description 694 "This module describes YANG data model for performance 695 monitoring telemetry for te tunnels. 696 Copyright (c) 2021 IETF Trust and the persons identified as 697 authors of the code. All rights reserved. 699 Redistribution and use in source and binary forms, with or 700 without modification, is permitted pursuant to, and subject to 701 the license terms contained in, the Simplified BSD License set 702 forth in Section 4.c of the IETF Trust's Legal Provisions 703 Relating to IETF Documents 704 (https://trustee.ietf.org/license-info). 706 This version of this YANG module is part of RFC XXXX; see the 707 RFC itself for full legal notices. 709 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 710 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 711 'MAY', and 'OPTIONAL' in this document are to be interpreted as 712 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 713 they appear in all capitals, as shown here."; 715 /* Note: The RFC Editor will replace XXXX with the number 716 assigned to the RFC once draft-ietf-teas-pm-telemetry- 717 autonomics becomes an RFC.*/ 719 revision 2021-02-19 { 720 description 721 "Initial revision."; 722 reference 723 "RFC XXXX: YANG models for VN/TE Performance Monitoring 724 Telemetry and Scaling Intent Autonomics"; 725 } 727 identity telemetry-param-type { 728 description 729 "Base identity for telemetry param types"; 730 } 732 identity one-way-delay { 733 base telemetry-param-type; 734 description 735 "To specify average Delay in one (forward) direction. 737 At the VN level, it is the max delay of the VN-members."; 738 reference 739 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions. 740 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions. 741 RFC 7823: Performance-Based Path Selection for Explicitly 742 Routed Label Switched Paths (LSPs) Using TE Metric 743 Extensions"; 744 } 746 identity two-way-delay { 747 base telemetry-param-type; 748 description 749 "To specify average Delay in both (forward and reverse) 750 directions. 752 At the VN level, it is the max delay of the VN-members."; 753 reference 754 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions. 755 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions. 756 RFC 7823: Performance-Based Path Selection for Explicitly 757 Routed Label Switched Paths (LSPs) Using TE Metric 758 Extensions"; 759 } 761 identity one-way-delay-variation { 762 base telemetry-param-type; 763 description 764 "To specify average Delay Variation in one (forward) direction. 766 At the VN level, it is the max delay variation of the 767 VN-members."; 768 reference 769 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions. 770 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions. 771 RFC 7823: Performance-Based Path Selection for Explicitly 772 Routed Label Switched Paths (LSPs) Using TE Metric 773 Extensions"; 774 } 776 identity two-way-delay-variation { 777 base telemetry-param-type; 778 description 779 "To specify average Delay Variation in both (forward and reverse) 780 directions. 782 At the VN level, it is the max delay variation of the 783 VN-members."; 784 reference 785 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions. 786 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions. 787 RFC 7823: Performance-Based Path Selection for Explicitly 788 Routed Label Switched Paths (LSPs) Using TE Metric 789 Extensions"; 790 } 792 identity utilized-bandwidth { 793 base telemetry-param-type; 794 description 795 "To specify utilized bandwidth over the specified source 796 and destination."; 797 reference 798 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions. 799 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions. 800 RFC 7823: Performance-Based Path Selection for Explicitly 801 Routed Label Switched Paths (LSPs) Using TE Metric 802 Extensions"; 803 } 805 identity utilized-percentage { 806 base telemetry-param-type; 807 description 808 "To specify utilization percentage of the entity 809 (e.g., tunnel, link, etc.)"; 810 } 812 identity scale-op { 813 description 814 "Base identity for scaling operation"; 815 } 817 identity scale-capacity-up { 818 base scale-op; 819 description 820 "Scale up the bandwidth capacity"; 821 } 823 identity scale-capacity-down { 824 base scale-op; 825 description 826 "Scale down the bandwidth capacity"; 827 } 829 /* Typedef */ 831 typedef telemetry-id { 832 type string; 833 description 834 "Identifier for the telemetry data."; 835 } 837 typedef scaling-criteria-operation { 838 type enumeration { 839 enum AND { 840 description 841 "AND operation"; 842 } 843 enum OR { 844 description 845 "OR operation"; 846 } 847 } 848 description 849 "Operations to analize list of scaling criterias"; 850 } 852 grouping scaling-duration { 853 description 854 "Base scaling criteria durations"; 855 leaf threshold-time { 856 type uint32; 857 units "seconds"; 858 description 859 "The duration for which the criteria must hold true"; 860 } 861 leaf cooldown-time { 862 type uint32; 863 units "seconds"; 864 description 865 "The duration after a scaling-in/scaling-out action has been 866 triggered, for which there will be no further operation"; 867 } 868 } 870 grouping scaling-criteria { 871 description 872 "Grouping for scaling criteria"; 873 leaf performance-type { 874 type identityref { 875 base telemetry-param-type; 876 } 877 description 878 "Reference to the tunnel level telemetry type"; 879 } 880 leaf threshold-value { 881 type string; 882 description 883 "Scaling threshold for the telemetry parameter type"; 884 } 885 } 887 grouping scaling-in-intent { 888 description 889 "Basic scaling in intent"; 890 uses scaling-duration; 891 list scaling-condition { 892 key "performance-type"; 893 description 894 "Scaling conditions"; 895 uses scaling-criteria; 896 leaf scale-in-operation-type { 897 type scaling-criteria-operation; 898 default "AND"; 899 description 900 "Operation to be applied to check between scaling criterias 901 to check if the scale in threshold condition has been met. 902 Defaults to AND"; 903 } 904 } 905 leaf scale-in-op { 906 type identityref { 907 base scale-op; 908 } 909 default "scale-capacity-down"; 910 description 911 "The scaling operation to be performed when scaling condition 912 is met"; 913 } 914 leaf scale { 915 type string; 916 description 917 "Additional scaling-by information to be interpritted as per 918 the scale-in-op."; 919 } 920 } 922 grouping scaling-out-intent { 923 description 924 "Basic scaling out intent"; 925 uses scaling-duration; 926 list scaling-condition { 927 key "performance-type"; 928 description 929 "Scaling conditions"; 930 uses scaling-criteria; 931 leaf scale-out-operation-type { 932 type scaling-criteria-operation; 933 default "OR"; 934 description 935 "Operation to be applied to check between scaling criterias 936 to check if the scale out threshold condition has been met. 937 Defauls to OR"; 938 } 940 } 941 leaf scale-out-op { 942 type identityref { 943 base scale-op; 944 } 945 default "scale-capacity-up"; 946 description 947 "The scaling operation to be performed when scaling condition 948 is met"; 949 } 950 leaf scale { 951 type string; 952 description 953 "Additional scaling-by information to be interpritted as per 954 the scale-out-op."; 955 } 956 } 958 augment "/te:te/te:tunnels/te:tunnel" { 959 description 960 "Augmentation parameters for config scaling-criteria TE 961 tunnel topologies. Scale in/out criteria might be used 962 for network autonomics in order the controller to react 963 to a certain set of monitored params."; 964 container te-scaling-intent { 965 description 966 "The scaling intent"; 967 container scale-in-intent { 968 description 969 "scale-in"; 970 uses scaling-in-intent; 971 } 972 container scale-out-intent { 973 description 974 "scale-out"; 975 uses scaling-out-intent; 976 } 977 } 978 container te-telemetry { 979 config false; 980 description 981 "Telemetry Data"; 982 leaf id { 983 type telemetry-id; 984 description 985 "ID of telemetry data used for easy reference"; 986 } 987 uses te-types:performance-metrics-attributes; 989 } 990 } 991 } 993 995 7.2. ietf-vn-kpi-telemetry model 997 The YANG code is as follows: 999 file "ietf-vn-kpi-telemetry@2021-02-19.yang" 1000 module ietf-vn-kpi-telemetry { 1001 yang-version 1.1; 1002 namespace "urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry"; 1003 prefix vn-kpi; 1005 /* Import VN */ 1007 import ietf-vn { 1008 prefix vn; 1009 reference 1010 "I-D.ietf-teas-actn-vn-yang: A YANG Data Model for VN 1011 Operation"; 1012 } 1014 /* Import TE */ 1016 import ietf-te { 1017 prefix te; 1018 reference 1019 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 1020 Engineering Tunnels and Interfaces"; 1021 } 1023 /* Import TE Common types */ 1025 import ietf-te-types { 1026 prefix te-types; 1027 reference 1028 "RFC 8776: Common YANG Data Types for Traffic Engineering"; 1029 } 1031 /* Import TE KPI */ 1033 import ietf-te-kpi-telemetry { 1034 prefix te-kpi; 1035 reference 1036 "RFC XXXX: YANG models for VN/TE Performance Monitoring 1037 Telemetry and Scaling Intent Autonomics"; 1038 } 1040 /* Note: The RFC Editor will replace XXXX with the number 1041 assigned to this draft.*/ 1043 organization 1044 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1045 Working Group"; 1046 contact 1047 "WG Web: 1048 WG List: 1049 Editor: Young Lee 1050 Dhruv Dhody "; 1051 description 1052 "This module describes YANG data models for performance 1053 monitoring telemetry for Virtual Network (VN). 1055 Copyright (c) 2021 IETF Trust and the persons identified as 1056 authors of the code. All rights reserved. 1058 Redistribution and use in source and binary forms, with or 1059 without modification, is permitted pursuant to, and subject to 1060 the license terms contained in, the Simplified BSD License set 1061 forth in Section 4.c of the IETF Trust's Legal Provisions 1062 Relating to IETF Documents 1063 (https://trustee.ietf.org/license-info). 1065 This version of this YANG module is part of RFC XXXX; see the 1066 RFC itself for full legal notices. 1068 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1069 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1070 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1071 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1072 they appear in all capitals, as shown here."; 1074 /* Note: The RFC Editor will replace XXXX with the number 1075 assigned to the RFC once draft-lee-teas-pm-telemetry- 1076 autonomics becomes an RFC.*/ 1078 revision 2021-02-19 { 1079 description 1080 "Initial revision."; 1081 reference 1082 "RFC XXXX: YANG models for VN/TE Performance Monitoring 1083 Telemetry and Scaling Intent Autonomics"; 1084 } 1085 typedef grouping-operation { 1086 type enumeration { 1087 enum MINIMUM { 1088 description 1089 "Select the minimum param"; 1090 } 1091 enum MAXIMUM { 1092 description 1093 "Select the maximum param"; 1094 } 1095 enum MEAN { 1096 description 1097 "Select the MEAN of the params"; 1098 } 1099 enum STD_DEV { 1100 description 1101 "Select the standard deviation of the monitored params"; 1102 } 1103 enum AND { 1104 description 1105 "Select the AND of the params"; 1106 } 1107 enum OR { 1108 description 1109 "Select the OR of the params"; 1110 } 1111 } 1112 description 1113 "Operations to analize list of monitored params"; 1114 } 1116 grouping vn-telemetry-param { 1117 description 1118 "augment of te-kpi:telemetry-param for VN specific params"; 1119 leaf-list te-grouped-params { 1120 type leafref { 1121 path 1122 "/te:te/te:tunnels/te:tunnel/te-kpi:te-telemetry/te-kpi:id"; 1123 } 1124 description 1125 "Allows the definition of a vn-telemetry param 1126 as a grouping of underlying TE params"; 1127 } 1128 leaf grouping-operation { 1129 type grouping-operation; 1130 description 1131 "describes the operation to apply to 1132 te-grouped-params"; 1134 } 1135 } 1137 augment "/vn:vn/vn:vn" { 1138 description 1139 "Augmentation parameters for state TE VN topologies."; 1140 container vn-scaling-intent { 1141 description 1142 "scaling intent"; 1143 container scale-in-intent { 1144 description 1145 "VN scale-in"; 1146 uses te-kpi:scaling-in-intent; 1147 } 1148 container scale-out-intent { 1149 description 1150 "VN scale-out"; 1151 uses te-kpi:scaling-out-intent; 1152 } 1153 } 1154 container vn-telemetry { 1155 config false; 1156 description 1157 "VN telemetry params"; 1158 uses te-types:performance-metrics-attributes; 1159 leaf grouping-operation { 1160 type grouping-operation; 1161 description 1162 "describes the operation to apply to the VN-members"; 1163 } 1164 } 1165 } 1167 augment "/vn:vn/vn:vn/vn:vn-member" { 1168 description 1169 "Augmentation parameters for state TE vn member topologies."; 1170 container vn-member-telemetry { 1171 config false; 1172 description 1173 "VN member telemetry params"; 1174 uses te-types:performance-metrics-attributes; 1175 uses vn-telemetry-param; 1176 } 1177 } 1178 } 1180 1182 8. Security Considerations 1184 The YANG module specified in this document defines a schema for data 1185 that is designed to be accessed via network management protocols such 1186 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1187 is the secure transport layer, and the mandatory-to-implement secure 1188 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1189 is HTTPS, and the mandatory-to-implement secure transport is TLS 1190 [RFC8446]. 1192 The NETCONF access control model [RFC8341] provides the means to 1193 restrict access for particular NETCONF users to a preconfigured 1194 subset of all available NETCONF protocol operations and content. The 1195 NETCONF Protocol over Secure Shell (SSH) [RFC6242] describes a method 1196 for invoking and running NETCONF within a Secure Shell (SSH) session 1197 as an SSH subsystem. The Network Configuration Access Control Model 1198 (NACM) [RFC8341] provides the means to restrict access for particular 1199 NETCONF or RESTCONF users to a preconfigured subset of all available 1200 NETCONF or RESTCONF protocol operations and content. 1202 A number of configuration data nodes defined in this document are 1203 writable/deletable (i.e., "config true"). These data nodes may be 1204 considered sensitive or vulnerable in some network environments. 1206 There are a number of data nodes defined in this YANG module that are 1207 writable/creatable/deletable (i.e., config true, which is the 1208 default). These data nodes may be considered sensitive or vulnerable 1209 in some network environments. Write operations (e.g., edit-config) 1210 to these data nodes without proper protection can have a negative 1211 effect on network operations. These are the subtrees and data nodes 1212 and their sensitivity/vulnerability: 1214 o /te:te/te:tunnels/te:tunnel/te-scaling-intent/scale-in-intent 1216 o /te:te/te:tunnels/te:tunnel/te-scaling-intent/scale-out-intent 1218 o /vn:vn/vn:vn/vn-scaling-intent/scale-in-intent 1220 o /vn:vn/vn:vn/vn-scaling-intent/scale-out-intent 1222 9. IANA Considerations 1224 This document registers the following namespace URIs in the IETF XML 1225 registry [RFC3688]: 1227 -------------------------------------------------------------------- 1228 URI: urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry 1229 Registrant Contact: The IESG. 1230 XML: N/A, the requested URI is an XML namespace. 1231 -------------------------------------------------------------------- 1233 -------------------------------------------------------------------- 1234 URI: urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry 1235 Registrant Contact: The IESG. 1236 XML: N/A, the requested URI is an XML namespace. 1237 -------------------------------------------------------------------- 1239 This document registers the following YANG modules in the YANG 1240 Module. 1242 Names registry [RFC7950]: 1244 -------------------------------------------------------------------- 1245 name: ietf-te-kpi-telemetry 1246 namespace: urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry 1247 prefix: te-tel 1248 reference: RFC XXXX 1249 -------------------------------------------------------------------- 1251 -------------------------------------------------------------------- 1252 name: ietf-vn-kpi-telemetry 1253 namespace: urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry 1254 prefix: vn-tel 1255 reference: RFC XXXX 1256 -------------------------------------------------------------------- 1258 10. Acknowledgements 1260 We thank Rakesh Gandhi, Tarek Saad, Igor Bryskin and Kenichi Ogaki 1261 for useful discussions and their suggestions for this work. 1263 11. References 1265 11.1. Normative References 1267 [I-D.ietf-teas-actn-vn-yang] 1268 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 1269 Yoon, "A YANG Data Model for VN Operation", draft-ietf- 1270 teas-actn-vn-yang-10 (work in progress), November 2020. 1272 [I-D.ietf-teas-yang-te] 1273 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1274 "A YANG Data Model for Traffic Engineering Tunnels, Label 1275 Switched Paths and Interfaces", draft-ietf-teas-yang-te-25 1276 (work in progress), July 2020. 1278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1279 Requirement Levels", BCP 14, RFC 2119, 1280 DOI 10.17487/RFC2119, March 1997, 1281 . 1283 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1284 DOI 10.17487/RFC3688, January 2004, 1285 . 1287 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1288 and A. Bierman, Ed., "Network Configuration Protocol 1289 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1290 . 1292 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1293 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1294 . 1296 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 1297 Ceccarelli, D., and X. Zhang, "Problem Statement and 1298 Architecture for Information Exchange between 1299 Interconnected Traffic-Engineered Networks", BCP 206, 1300 RFC 7926, DOI 10.17487/RFC7926, July 2016, 1301 . 1303 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1304 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1305 . 1307 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1308 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1309 . 1311 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1312 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1313 May 2017, . 1315 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, 1316 "Extensions to the Path Computation Element Communication 1317 Protocol (PCEP) to Compute Service-Aware Label Switched 1318 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 1319 2017, . 1321 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1322 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1323 . 1325 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1326 Access Control Model", STD 91, RFC 8341, 1327 DOI 10.17487/RFC8341, March 2018, 1328 . 1330 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1331 and R. Wilton, "Network Management Datastore Architecture 1332 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1333 . 1335 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1336 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1337 . 1339 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1340 E., and A. Tripathy, "Dynamic Subscription to YANG Events 1341 and Datastores over NETCONF", RFC 8640, 1342 DOI 10.17487/RFC8640, September 2019, 1343 . 1345 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1346 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1347 September 2019, . 1349 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1350 "Common YANG Data Types for Traffic Engineering", 1351 RFC 8776, DOI 10.17487/RFC8776, June 2020, 1352 . 1354 11.2. Informative References 1356 [I-D.xu-actn-perf-dynamic-service-control] 1357 Xu, Y., Zhang, G., Cheng, W., and z. 1358 zhenghaomian@huawei.com, "Use Cases and Requirements of 1359 Dynamic Service Control based on Performance Monitoring in 1360 ACTN Architecture", draft-xu-actn-perf-dynamic-service- 1361 control-03 (work in progress), April 2015. 1363 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1364 Previdi, "OSPF Traffic Engineering (TE) Metric 1365 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1366 . 1368 [RFC7823] Atlas, A., Drake, J., Giacalone, S., and S. Previdi, 1369 "Performance-Based Path Selection for Explicitly Routed 1370 Label Switched Paths (LSPs) Using TE Metric Extensions", 1371 RFC 7823, DOI 10.17487/RFC7823, May 2016, 1372 . 1374 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1375 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1376 . 1378 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1379 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1380 DOI 10.17487/RFC8453, August 2018, 1381 . 1383 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 1384 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 1385 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 1386 2019, . 1388 Authors' Addresses 1390 Young Lee (editor) 1391 Samsung Electronics 1393 Email: younglee.tx@gmail.com 1395 Dhruv Dhody (editor) 1396 Huawei Technologies 1397 Divyashree Techno Park, Whitefield 1398 Bangalore, Karnataka 560066 1399 India 1401 Email: dhruv.ietf@gmail.com 1403 Satish Karunanithi 1404 Huawei Technologies 1405 Divyashree Techno Park, Whitefield 1406 Bangalore, Karnataka 560066 1407 India 1409 Email: satish.karunanithi@gmail.com 1410 Ricard Vilalta 1411 CTTC 1412 Centre Tecnologic de Telecomunicacions de Catalunya (CTTC/CERCA) 1413 Barcelona 1414 Spain 1416 Email: ricard.vilalta@cttc.es 1418 Daniel King 1419 Lancaster University 1421 Email: d.king@lancaster.ac.uk 1423 Daniele Ceccarelli 1424 Ericsson 1425 Torshamnsgatan,48 1426 Stockholm, Sweden 1428 Email: daniele.ceccarelli@ericsson.com