idnits 2.17.1 draft-ietf-teas-actn-pm-telemetry-autonomics-04.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 (November 1, 2020) is 1264 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 203, but not defined == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-09 == 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: May 5, 2021 S. Karunanithi 6 Huawei Technologies 7 R. Vilalta 8 CTTC 9 D. King 10 Lancaster University 11 D. Ceccarelli 12 Ericsson 13 November 1, 2020 15 YANG models for VN/TE Performance Monitoring Telemetry and Scaling 16 Intent Autonomics 17 draft-ietf-teas-actn-pm-telemetry-autonomics-04 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 May 5, 2021. 48 Copyright Notice 50 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . 12 78 7. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 15 79 7.1. ietf-te-kpi-telemetry model . . . . . . . . . . . . . . . 15 80 7.2. ietf-vn-kpi-telemetry model . . . . . . . . . . . . . . . 21 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 27 86 11.2. Informative References . . . . . . . . . . . . . . . . . 29 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 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 1.1. Terminology 149 Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used 150 in this document. 152 Key Performance Data: This refers to a set of data the customer is 153 interested in monitoring for their instantiated VNs or TE-tunnels. 154 Key performance data and key performance indicators are inter- 155 exchangeable in this draft. 157 Scaling: This refers to the network ability to re-shape its own 158 resources. Scale out refers to improve network performance by 159 increasing the allocated resources, while scale in refers to decrease 160 the allocated resources, typically because the existing resources are 161 unnecessary. 163 Scaling Intent: To declare scaling conditions, scaling intent is 164 used. Specifically, scaling intent refers to the intent expressed by 165 the client that allows the client to program/configure conditions of 166 their key performance data either for scaling out or scaling in. 167 Various conditions can be set for scaling intent on either VN or TE- 168 tunnel level. 170 Network Autonomics: This refers to the network automation capability 171 that allows client to initiate scaling intent mechanisms and provides 172 the client with the status of the adjusted network resources based on 173 the client's scaling intent in an automated fashion. 175 1.1.1. Requirements Language 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 179 "OPTIONAL" in this document are to be interpreted as described in BCP 180 14 [RFC2119] [RFC8174] when, and only when, they appear in all 181 capitals, as shown here. 183 1.2. Tree diagram 185 A simplified graphical representation of the data model is used in 186 Section 5 of this this document. The meaning of the symbols in these 187 diagrams is defined in [RFC8340]. 189 1.3. Prefixes in Data Node Names 191 In this document, names of data nodes and other data model objects 192 are prefixed using the standard prefix associated with the 193 corresponding YANG imported modules, as shown in Table 1. 195 +----------+-----------------------+------------------------------+ 196 | Prefix | YANG module | Reference | 197 +----------+-----------------------+------------------------------+ 198 | inet | ietf-inet-types | [RFC6991] | 199 | te | ietf-te | [I-D.ietf-teas-yang-te] | 200 | te-types | ietf-te-types | [RFC8776] | 201 | te-tel | ietf-te-kpi-telemetry | [RFCXXXX] | 202 | vn | ietf-vn | [I-D.ietf-teas-actn-vn-yang] | 203 | vn-tel | ietf-vn-kpi-telemetry | [RFCXXXX] | 204 +----------+-----------------------+------------------------------+ 206 Table 1: Prefixes and corresponding YANG modules 208 Note: The RFC Editor will replace XXXX with the number assigned to 209 the RFC once this draft becomes an RFC. 211 Further, the following additional documents are refrenced in the 212 model defined in this document - 214 o [RFC7471] - OSPF Traffic Engineering (TE) Metric Extensions. 216 o [RFC8570] - IS-IS Traffic Engineering (TE) Metric Extensions. 218 o [RFC7823] - Performance-Based Path Selection for Explicitly Routed 219 Label Switched Paths (LSPs) Using TE Metric Extensions. 221 2. Use-Cases 223 [I-D.xu-actn-perf-dynamic-service-control] describes use-cases 224 relevant to this draft. It introduces the dynamic creation, 225 modification and optimization of services based on the performance 226 monitoring. Figure 1 shows a high-level workflows for dynamic 227 service control based on traffic monitoring. 229 +----------------------------------------------+ 230 | Client +-----------------------------+ | 231 | | Dynamic Service Control APP | | 232 | +-----------------------------+ | 233 +----------------------------------------------+ 234 1.Traffic| /|\4.Traffic | /|\ 235 Monitor& | | Monitor | | 8.Traffic 236 Optimize | | Result 5.Service | | modify & 237 Policy | | modify& | | optimize 238 \|/ | optimize Req.\|/ | result 239 +----------------------------------------------+ 240 | Orchestrator | 241 | +-------------------------------+ | 242 | |Dynamic Service Control Agent | | 243 | +-------------------------------+ | 244 | +---------------+ +-------------------+ | 245 | | Flow Optimize | | vConnection Agent | | 246 | +---------------+ +-------------------+ | 247 +----------------------------------------------+ 248 2. Path | /|\3.Traffic | /|\ 249 Monitor | | Monitor | |7.Path 250 Request | | Result 6.Path | | modify & 251 | | modify& | | optimize 252 \|/ | optimize Req.\|/ | result 253 +----------------------------------------------+ 254 | Network SDN Controller | 255 | +----------------------+ +-----------------+| 256 | | Network Provisioning | |Abstract Topology|| 257 | +----------------------+ +-----------------+| 258 | +------------------+ +--------------------+ | 259 | |Network Monitoring| |Physical Topology DB| | 260 | +------------------+ +--------------------+ | 261 +----------------------------------------------+ 263 Figure 1: Workflows for dynamic service control based on traffic 264 monitoring 266 Some of the key points from 267 [I-D.xu-actn-perf-dynamic-service-control] are as follows: 269 o Network traffic monitoring is important to facilitate automatic 270 discovery of the imbalance of network traffic, and initiate the 271 network optimization, thus helping the network operator or the 272 virtual network service provider to use the network more 273 efficiently and save the Capital Expense (CAPEX) and the Operating 274 Expense (OPEX). 276 o Customer services have various Service Level Agreement (SLA) 277 requirements, such as service availability, latency, latency 278 jitter, packet loss rate, Bit Error Rate (BER), etc. The 279 transport network can satisfy service availability and BER 280 requirements by providing different protection and restoration 281 mechanisms. However, for other performance parameters, there are 282 no such mechanisms. In order to provide high quality services 283 according to customer SLA, one possible solution is to measure the 284 SLA related performance parameters, and dynamically provision and 285 optimize services based on the performance monitoring results. 287 o Performance monitoring in a large scale network could generate a 288 huge amount of performance information. Therefore, the 289 appropriate way to deliver the information in the client and 290 network interfaces should be carefully considered. 292 3. Design of the Data Models 294 The YANG models developed in this document describe two models: 296 (i) TE KPI Telemetry Model which provides the TE-Tunnel level of 297 performance monitoring mechanism and scaling intent mechanism 298 that allows scale in/out programming by the customer. (See 299 Section 3.1 & Section 7.1 for details). 301 (ii) VN KPI Telemetry Model which provides the VN level of the 302 aggregated performance monitoring mechanism and scaling intent 303 mechanism that allows scale in/out programming by the customer 304 (See Section 3.2 & Section 7.2 for details). 306 3.1. TE KPI Telemetry Model 308 This module describes performance telemetry for TE-tunnel model. The 309 telemetry data is augmented to tunnel state. This module also allows 310 autonomic traffic engineering scaling intent configuration mechanism 311 on the TE-tunnel level. Various conditions can be set for auto- 312 scaling based on the telemetry data (See Section 5 for details) 314 The TE KPI Telemetry Model augments the TE-Tunnel Model to enhance TE 315 performance monitoring capability. This monitoring capability will 316 facilitate proactive re-optimization and reconfiguration of TEs based 317 on the performance monitoring data collected via the TE KPI Telemetry 318 YANG model. 320 +------------+ +--------------+ 321 | TE-Tunnel | | TE KPI | 322 | Model |<---------| Telemetry | 323 +------------+ augments | Model | 324 +--------------+ 326 3.2. VN KPI Telemetry Model 328 This module describes performance telemetry for VN model. The 329 telemetry data is augmented both at the VN Level as well as 330 individual VN member level. This module also allows autonomic 331 traffic engineering scaling intent configuration mechanism on the VN 332 level. Scale in/out criteria might be used for network autonomics in 333 order the controller to react to a certain set of variations in 334 monitored parameters (See Section 4 for illustrations). 336 Moreover, this module also provides mechanism to define aggregated 337 telemetry parameters as a grouping of underlying VN level telemetry 338 parameters. Grouping operation (such as maximum, mean) could be set 339 at the time of configuration. For example, if maximum grouping 340 operation is used for delay at the VN level, the VN telemetry data is 341 reported as the maximum {delay_vn_member_1, delay_vn_member_2,.. 342 delay_vn_member_N}. Thus, this telemetry abstraction mechanism allows 343 the grouping of a certain common set of telemetry values under a 344 grouping operation. This can be done at the VN-member level to 345 suggest how the E2E telemetry be inferred from the per domain tunnel 346 created and monitored by PNCs. One proposed example is the 347 following: 349 +------------------------------------------------------------+ 350 | Client | 351 | | 352 +------------------------------------------------------------+ 353 1.Client sets the | /|\ 2. Orchestrator pushes: 354 grouping op, and | | 355 subscribes to the | | VN level telemetry for 356 VN level telemetry for | | - VN Utilized-bw-percentage 357 Delay and | | (Minimum across VN Members) 358 Utilized-bw-pecentage | | - VN Delay (Maximum across VN 359 \|/ | Members) 360 +------------------------------------------------------------+ 361 | Orchestrator | 362 | | 363 +------------------------------------------------------------+ 365 The VN Telemetry Model augments the basic VN model to enhance VN 366 monitoring capability. This monitoring capability will facilitate 367 proactive re-optimization and reconfiguration of VNs based on the 368 performance monitoring data collected via the VN Telemetry YANG 369 model. 371 +----------+ +--------------+ 372 | VN | augments | VN | 373 | Model |<---------| Telemetry | 374 +----------+ | Model | 375 +--------------+ 377 4. Autonomic Scaling Intent Mechanism 379 Scaling intent configuration mechanism allows the client to configure 380 automatic scale-in and scale-out mechanisms on both the TE-tunnel and 381 the VN level. Various conditions can be set for auto- scaling based 382 on the PM telemetry data. 384 There are a number of parameters involved in the mechanism: 386 o scale-out-intent or scale-in-intent: whether to scale-out or 387 scale-in. 389 o performance-type: performance metric type (e.g., one-way-delay, 390 one-way-delay-min, one-way-delay-max, two-way-delay, two-way- 391 delay-min, two-way-delay-max, utilized bandwidth, etc.) 393 o threshold-value: the threshold value for a certain performance- 394 type that triggers scale-in or scale-out. 396 o scaling-operation-type: in case where scaling condition can be set 397 with one or more performance types, then scaling-operation-type 398 (AND, OR, MIN, MAX, etc.) is applied to these selected performance 399 types and its threshold values. 401 o Threshold-time: the duration for which the criteria MUST hold 402 true. 404 o Cooldown-time: the duration after a scaling action has been 405 triggered, for which there will be no further operation. 407 The following tree is a part of ietf-te-kpi-telemetry tree whose 408 model is presented in full detail in Sections 6 & 7. 410 module: ietf-te-kpi-telemetry 411 augment /te:te/te:tunnels/te:tunnel: 412 +--rw te-scaling-intent 413 | +--rw scale-in-intent 414 | | +--rw threshold-time? uint32 415 | | +--rw cooldown-time? uint32 416 | | +--rw scaling-condition* [performance-type] 417 | | +--rw performance-type identityref 418 | | +--rw threshold-value? string 419 | | +--rw scale-in-operation-type? 420 | | scaling-criteria-operation 421 | +--rw scale-out-intent 422 | +--rw threshold-time? uint32 423 | +--rw cooldown-time? uint32 424 | +--rw scaling-condition* [performance-type] 425 | +--rw performance-type identityref 426 | +--rw threshold-value? string 427 | +--rw scale-out-operation-type? 428 | scaling-criteria-operation 430 Let say the client wants to set the scaling out operation based on 431 two performance-types (e.g., two-way-delay and utilized-bandwidth for 432 a te-tunnel), it can be done as follows: 434 o Set Threshold-time: x (sec) (duration for which the criteria must 435 hold true) 437 o Set Cooldown-time: y (sec) (the duration after a scaling action 438 has been triggered, for which there will be no further operation) 440 o Set AND for the scale-out-operation-type 442 In the scaling condition's list, the following two components can be 443 set: 445 List 1: Scaling Condition for Two-way-delay 447 o performance type: Two-way-delay 449 o threshold-value: z milli-seconds 451 List 2: Scaling Condition for Utilized bandwidth 453 o performance type: Utilized bandwidth 455 o threshold-value: w megabytes 457 5. Notification 459 This model does not define specific notifications. To enable 460 notifications, the mechanism defined in [RFC8641] and [RFC8640] can 461 be used. This mechanism currently allows the user to: 463 o Subscribe to notifications on a per client basis. 465 o Specify subtree filters or xpath filters so that only interested 466 contents will be sent. 468 o Specify either periodic or on-demand notifications. 470 5.1. YANG Push Subscription Examples 472 [RFC8641] allows subscriber applications to request a continuous, 473 customized stream of updates from a YANG datastore. 475 Below example shows the way for a client to subscribe to the 476 telemetry information for a particular tunnel (Tunnel1). The 477 telemetry parameter that the client is interested in is one-way- 478 delay. 480 482 484 485 486 487 488 Tunnel1 489 490 491 493 494 495 496 497 498 499 500 500 501 encode-xml 502 503 505 This example shows the way for a client to subscribe to the telemetry 506 information for all VNs. The telemetry parameter that the client is 507 interested in is one-way-delay and one-way-utilized- bandwidth. 509 511 513 514 515 516 517 518 519 521 522 523 524 525 526 527 528 500 529 530 532 6. YANG Data Tree 534 module: ietf-te-kpi-telemetry 535 augment /te:te/te:tunnels/te:tunnel: 536 +--rw te-scaling-intent 537 | +--rw scale-in-intent 538 | | +--rw threshold-time? uint32 539 | | +--rw cooldown-time? uint32 540 | | +--rw scaling-condition* [performance-type] 541 | | +--rw performance-type identityref 542 | | +--rw threshold-value? string 543 | | +--rw scale-in-operation-type? 544 | | scaling-criteria-operation 545 | +--rw scale-out-intent 546 | +--rw threshold-time? uint32 547 | +--rw cooldown-time? uint32 548 | +--rw scaling-condition* [performance-type] 549 | +--rw performance-type identityref 550 | +--rw threshold-value? string 551 | +--rw scale-out-operation-type? 552 | scaling-criteria-operation 553 +--ro te-telemetry 554 +--ro id? telemetry-id 555 +--ro performance-metrics-one-way 556 | +--ro one-way-delay? uint32 557 | +--ro one-way-delay-normality? 558 | | te-types:performance-metrics-normality 559 | +--ro one-way-residual-bandwidth? 560 | | rt-types:bandwidth-ieee-float32 561 | +--ro one-way-residual-bandwidth-normality? 562 | | te-types:performance-metrics-normality 563 | +--ro one-way-available-bandwidth? 564 | | rt-types:bandwidth-ieee-float32 565 | +--ro one-way-available-bandwidth-normality? 566 | | te-types:performance-metrics-normality 567 | +--ro one-way-utilized-bandwidth? 568 | | rt-types:bandwidth-ieee-float32 569 | +--ro one-way-utilized-bandwidth-normality? 570 | te-types:performance-metrics-normality 571 +--ro performance-metrics-two-way 572 +--ro two-way-delay? uint32 573 +--ro two-way-delay-normality? 574 te-types:performance-metrics-normality 576 module: ietf-vn-kpi-telemetry 577 augment /vn:vn/vn:vn-list: 578 +--rw vn-scaling-intent 579 | +--rw scale-in-intent 580 | | +--rw threshold-time? uint32 581 | | +--rw cooldown-time? uint32 582 | | +--rw scaling-condition* [performance-type] 583 | | +--rw performance-type identityref 584 | | +--rw threshold-value? string 585 | | +--rw scale-in-operation-type? 586 | | scaling-criteria-operation 587 | +--rw scale-out-intent 588 | +--rw threshold-time? uint32 589 | +--rw cooldown-time? uint32 590 | +--rw scaling-condition* [performance-type] 591 | +--rw performance-type identityref 592 | +--rw threshold-value? string 593 | +--rw scale-out-operation-type? 594 | scaling-criteria-operation 595 +--ro vn-telemetry 596 +--ro performance-metrics-one-way 597 | +--ro one-way-delay? uint32 598 | +--ro one-way-delay-normality? 599 | | te-types:performance-metrics-normality 600 | +--ro one-way-residual-bandwidth? 601 | | rt-types:bandwidth-ieee-float32 602 | +--ro one-way-residual-bandwidth-normality? 603 | | te-types:performance-metrics-normality 604 | +--ro one-way-available-bandwidth? 605 | | rt-types:bandwidth-ieee-float32 606 | +--ro one-way-available-bandwidth-normality? 607 | | te-types:performance-metrics-normality 608 | +--ro one-way-utilized-bandwidth? 609 | | rt-types:bandwidth-ieee-float32 610 | +--ro one-way-utilized-bandwidth-normality? 611 | te-types:performance-metrics-normality 612 +--ro performance-metrics-two-way 613 | +--ro two-way-delay? uint32 614 | +--ro two-way-delay-normality? 615 | te-types:performance-metrics-normality 616 +--ro grouping-operation? grouping-operation 617 augment /vn:vn/vn:vn-list/vn:vn-member-list: 618 +--ro vn-member-telemetry 619 +--ro performance-metrics-one-way 620 | +--ro one-way-delay? uint32 621 | +--ro one-way-delay-normality? 622 | | te-types:performance-metrics-normality 623 | +--ro one-way-residual-bandwidth? 624 | | rt-types:bandwidth-ieee-float32 625 | +--ro one-way-residual-bandwidth-normality? 626 | | te-types:performance-metrics-normality 627 | +--ro one-way-available-bandwidth? 628 | | rt-types:bandwidth-ieee-float32 629 | +--ro one-way-available-bandwidth-normality? 630 | | te-types:performance-metrics-normality 631 | +--ro one-way-utilized-bandwidth? 632 | | rt-types:bandwidth-ieee-float32 633 | +--ro one-way-utilized-bandwidth-normality? 634 | te-types:performance-metrics-normality 635 +--ro performance-metrics-two-way 636 | +--ro two-way-delay? uint32 637 | +--ro two-way-delay-normality? 638 | te-types:performance-metrics-normality 639 +--ro te-grouped-params* 640 | -> /te:te/tunnels/tunnel/te-kpi:te-telemetry/id 641 +--ro grouping-operation? grouping-operation 643 7. YANG Data Model 645 7.1. ietf-te-kpi-telemetry model 647 The YANG code is as follows: 649 file "ietf-te-kpi-telemetry@2020-11-02.yang" 650 module ietf-te-kpi-telemetry { 651 yang-version 1.1; 652 namespace "urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry"; 653 prefix te-tel; 655 /* Import inet-types */ 657 import ietf-inet-types { 658 prefix inet; 659 reference 660 "RFC 6991: Common YANG Data Types"; 661 } 663 /* Import TE */ 665 import ietf-te { 666 prefix te; 667 reference 668 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 669 Engineering Tunnels and Interfaces"; 670 } 672 /* Import TE Common types */ 674 import ietf-te-types { 675 prefix te-types; 676 reference 677 "RFC 8776: Common YANG Data Types for Traffic Engineering"; 678 } 680 organization 681 "IETF Traffic Engineering Architecture and Signaling (TEAS) 682 Working Group"; 683 contact 684 "WG Web: 685 WG List: 686 Editor: Young Lee 687 Dhruv Dhody "; 688 description 689 "This module describes YANG data model for performance 690 monitoring telemetry for te tunnels. 692 Copyright (c) 2020 IETF Trust and the persons identified as 693 authors of the code. All rights reserved. 695 Redistribution and use in source and binary forms, with or 696 without modification, is permitted pursuant to, and subject to 697 the license terms contained in, the Simplified BSD License set 698 forth in Section 4.c of the IETF Trust's Legal Provisions 699 Relating to IETF Documents 700 (https://trustee.ietf.org/license-info). 702 This version of this YANG module is part of RFC XXXX; see the 703 RFC itself for full legal notices. 705 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 706 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 707 'MAY', and 'OPTIONAL' in this document are to be interpreted as 708 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 709 they appear in all capitals, as shown here."; 711 /* Note: The RFC Editor will replace XXXX with the number 712 assigned to the RFC once draft-ietf-teas-pm-telemetry- 713 autonomics becomes an RFC.*/ 715 revision 2020-11-02 { 716 description 717 "Initial revision."; 718 reference 719 "RFC XXXX: YANG models for VN/TE Performance Monitoring 720 Telemetry and Scaling Intent Autonomics"; 721 } 723 identity telemetry-param-type { 724 description 725 "Base identity for telemetry param types"; 726 } 728 identity one-way-delay { 729 base telemetry-param-type; 730 description 731 "To specify average Delay in one (forward) direction. 733 At the VN level, it is the max delay of the VN-members."; 734 reference 735 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions. 736 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions. 737 RFC 7823: Performance-Based Path Selection for Explicitly 738 Routed Label Switched Paths (LSPs) Using TE Metric 739 Extensions"; 741 } 743 identity two-way-delay { 744 base telemetry-param-type; 745 description 746 "To specify average Delay in both (forward and reverse) 747 directions. 749 At the VN level, it is the max delay of the VN-members."; 750 reference 751 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions. 752 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions. 753 RFC 7823: Performance-Based Path Selection for Explicitly 754 Routed Label Switched Paths (LSPs) Using TE Metric 755 Extensions"; 756 } 758 identity one-way-delay-variation { 759 base telemetry-param-type; 760 description 761 "To specify average Delay Variation in one (forward) direction. 763 At the VN level, it is the max delay variation of the 764 VN-members."; 765 reference 766 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions. 767 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions. 768 RFC 7823: Performance-Based Path Selection for Explicitly 769 Routed Label Switched Paths (LSPs) Using TE Metric 770 Extensions"; 771 } 773 identity two-way-delay-variation { 774 base telemetry-param-type; 775 description 776 "To specify average Delay Variation in both (forward and reverse) 777 directions. 779 At the VN level, it is the max delay variation of the 780 VN-members."; 781 reference 782 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions. 783 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions. 784 RFC 7823: Performance-Based Path Selection for Explicitly 785 Routed Label Switched Paths (LSPs) Using TE Metric 786 Extensions"; 787 } 788 identity utilized-bandwidth { 789 base telemetry-param-type; 790 description 791 "To specify utilized bandwidth over the specified source 792 and destination."; 793 reference 794 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions. 795 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions. 796 RFC 7823: Performance-Based Path Selection for Explicitly 797 Routed Label Switched Paths (LSPs) Using TE Metric 798 Extensions"; 799 } 801 identity utilized-percentage { 802 base telemetry-param-type; 803 description 804 "To specify utilization percentage of the entity 805 (e.g., tunnel, link, etc.)"; 806 } 808 /* Typedef */ 810 typedef telemetry-id { 811 type inet:uri; 812 description 813 "Identifier for telemetry data. The precise 814 structure of the telemetry-id will be up to the 815 implementation. The identifier SHOULD be chosen 816 such that the same telemetry data will always be 817 identified through the same identifier, even if 818 the data model is instantiated in separate 819 datastores."; 820 } 822 typedef scaling-criteria-operation { 823 type enumeration { 824 enum AND { 825 description 826 "AND operation"; 827 } 828 enum OR { 829 description 830 "OR operation"; 831 } 832 } 833 description 834 "Operations to analize list of scaling criterias"; 835 } 836 grouping scaling-duration { 837 description 838 "Base scaling criteria durations"; 839 leaf threshold-time { 840 type uint32; 841 units "seconds"; 842 description 843 "The duration for which the criteria must hold true"; 844 } 845 leaf cooldown-time { 846 type uint32; 847 units "seconds"; 848 description 849 "The duration after a scaling-in/scaling-out action has been 850 triggered, for which there will be no further operation"; 851 } 852 } 854 grouping scaling-criteria { 855 description 856 "Grouping for scaling criteria"; 857 leaf performance-type { 858 type identityref { 859 base telemetry-param-type; 860 } 861 description 862 "Reference to the tunnel level telemetry type"; 863 } 864 leaf threshold-value { 865 type string; 866 description 867 "Scaling threshold for the telemetry parameter type"; 868 } 869 } 871 grouping scaling-in-intent { 872 description 873 "Basic scaling in intent"; 874 uses scaling-duration; 875 list scaling-condition { 876 key "performance-type"; 877 description 878 "Scaling conditions"; 879 uses scaling-criteria; 880 leaf scale-in-operation-type { 881 type scaling-criteria-operation; 882 default "AND"; 883 description 884 "Operation to be applied to check between scaling criterias 885 to check if the scale in threshold condition has been met. 886 Defaults to AND"; 887 } 888 } 889 } 891 grouping scaling-out-intent { 892 description 893 "Basic scaling out intent"; 894 uses scaling-duration; 895 list scaling-condition { 896 key "performance-type"; 897 description 898 "Scaling conditions"; 899 uses scaling-criteria; 900 leaf scale-out-operation-type { 901 type scaling-criteria-operation; 902 default "OR"; 903 description 904 "Operation to be applied to check between scaling criterias 905 to check if the scale out threshold condition has been met. 906 Defauls to OR"; 907 } 908 } 909 } 911 augment "/te:te/te:tunnels/te:tunnel" { 912 description 913 "Augmentation parameters for config scaling-criteria TE 914 tunnel topologies. Scale in/out criteria might be used 915 for network autonomics in order the controller to react 916 to a certain set of monitored params."; 917 container te-scaling-intent { 918 description 919 "The scaling intent"; 920 container scale-in-intent { 921 description 922 "scale-in"; 923 uses scaling-in-intent; 924 } 925 container scale-out-intent { 926 description 927 "scale-out"; 928 uses scaling-out-intent; 929 } 930 } 931 container te-telemetry { 932 config false; 933 description 934 "Telemetry Data"; 935 leaf id { 936 type telemetry-id; 937 description 938 "ID of telemetry data used for easy reference"; 939 } 940 uses te-types:performance-metrics-attributes; 941 } 942 } 943 } 945 947 7.2. ietf-vn-kpi-telemetry model 949 The YANG code is as follows: 951 file "ietf-vn-kpi-telemetry@2020-11-02.yang" 952 module ietf-vn-kpi-telemetry { 953 yang-version 1.1; 954 namespace "urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry"; 955 prefix vn-kpi; 957 /* Import VN */ 959 import ietf-vn { 960 prefix vn; 961 reference 962 "I-D.ietf-teas-actn-vn-yang: A YANG Data Model for VN 963 Operation"; 964 } 966 /* Import TE */ 968 import ietf-te { 969 prefix te; 970 reference 971 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 972 Engineering Tunnels and Interfaces"; 973 } 975 /* Import TE Common types */ 977 import ietf-te-types { 978 prefix te-types; 979 reference 980 "RFC 8776: Common YANG Data Types for Traffic Engineering"; 981 } 983 /* Import TE KPI */ 985 import ietf-te-kpi-telemetry { 986 prefix te-kpi; 987 reference 988 "RFC XXXX: YANG models for VN/TE Performance Monitoring 989 Telemetry and Scaling Intent Autonomics"; 990 } 992 /* Note: The RFC Editor will replace XXXX with the number 993 assigned to this draft.*/ 995 organization 996 "IETF Traffic Engineering Architecture and Signaling (TEAS) 997 Working Group"; 998 contact 999 "WG Web: 1000 WG List: 1001 Editor: Young Lee 1002 Dhruv Dhody "; 1003 description 1004 "This module describes YANG data models for performance 1005 monitoring telemetry for Virtual Network (VN). 1007 Copyright (c) 2020 IETF Trust and the persons identified as 1008 authors of the code. All rights reserved. 1010 Redistribution and use in source and binary forms, with or 1011 without modification, is permitted pursuant to, and subject to 1012 the license terms contained in, the Simplified BSD License set 1013 forth in Section 4.c of the IETF Trust's Legal Provisions 1014 Relating to IETF Documents 1015 (https://trustee.ietf.org/license-info). 1017 This version of this YANG module is part of RFC XXXX; see the 1018 RFC itself for full legal notices. 1020 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1021 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1022 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1023 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1024 they appear in all capitals, as shown here."; 1026 /* Note: The RFC Editor will replace XXXX with the number 1027 assigned to the RFC once draft-lee-teas-pm-telemetry- 1028 autonomics becomes an RFC.*/ 1030 revision 2020-11-02 { 1031 description 1032 "Initial revision."; 1033 reference 1034 "RFC XXXX: YANG models for VN/TE Performance Monitoring 1035 Telemetry and Scaling Intent Autonomics"; 1036 } 1038 typedef grouping-operation { 1039 type enumeration { 1040 enum MINIMUM { 1041 description 1042 "Select the minimum param"; 1043 } 1044 enum MAXIMUM { 1045 description 1046 "Select the maximum param"; 1047 } 1048 enum MEAN { 1049 description 1050 "Select the MEAN of the params"; 1051 } 1052 enum STD_DEV { 1053 description 1054 "Select the standard deviation of the monitored params"; 1055 } 1056 enum AND { 1057 description 1058 "Select the AND of the params"; 1059 } 1060 enum OR { 1061 description 1062 "Select the OR of the params"; 1063 } 1064 } 1065 description 1066 "Operations to analize list of monitored params"; 1067 } 1069 grouping vn-telemetry-param { 1070 description 1071 "augment of te-kpi:telemetry-param for VN specific params"; 1072 leaf-list te-grouped-params { 1073 type leafref { 1074 path 1075 "/te:te/te:tunnels/te:tunnel/te-kpi:te-telemetry/te-kpi:id"; 1077 } 1078 description 1079 "Allows the definition of a vn-telemetry param 1080 as a grouping of underlying TE params"; 1081 } 1082 leaf grouping-operation { 1083 type grouping-operation; 1084 description 1085 "describes the operation to apply to 1086 te-grouped-params"; 1087 } 1088 } 1090 augment "/vn:vn/vn:vn-list" { 1091 description 1092 "Augmentation parameters for state TE VN topologies."; 1093 container vn-scaling-intent { 1094 description 1095 "scaling intent"; 1096 container scale-in-intent { 1097 description 1098 "VN scale-in"; 1099 uses te-kpi:scaling-in-intent; 1100 } 1101 container scale-out-intent { 1102 description 1103 "VN scale-out"; 1104 uses te-kpi:scaling-out-intent; 1105 } 1106 } 1107 container vn-telemetry { 1108 config false; 1109 description 1110 "VN telemetry params"; 1111 uses te-types:performance-metrics-attributes; 1112 leaf grouping-operation { 1113 type grouping-operation; 1114 description 1115 "describes the operation to apply to the VN-members"; 1116 } 1117 } 1118 } 1120 augment "/vn:vn/vn:vn-list/vn:vn-member-list" { 1121 description 1122 "Augmentation parameters for state TE vn member topologies."; 1123 container vn-member-telemetry { 1124 config false; 1125 description 1126 "VN member telemetry params"; 1127 uses te-types:performance-metrics-attributes; 1128 uses vn-telemetry-param; 1129 } 1130 } 1131 } 1133 1135 8. Security Considerations 1137 The YANG module specified in this document defines a schema for data 1138 that is designed to be accessed via network management protocols such 1139 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1140 is the secure transport layer, and the mandatory-to-implement secure 1141 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1142 is HTTPS, and the mandatory-to-implement secure transport is TLS 1143 [RFC8446]. 1145 The NETCONF access control model [RFC8341] provides the means to 1146 restrict access for particular NETCONF users to a preconfigured 1147 subset of all available NETCONF protocol operations and content. The 1148 NETCONF Protocol over Secure Shell (SSH) [RFC6242] describes a method 1149 for invoking and running NETCONF within a Secure Shell (SSH) session 1150 as an SSH subsystem. The Network Configuration Access Control Model 1151 (NACM) [RFC8341] provides the means to restrict access for particular 1152 NETCONF or RESTCONF users to a preconfigured subset of all available 1153 NETCONF or RESTCONF protocol operations and content. 1155 A number of configuration data nodes defined in this document are 1156 writable/deletable (i.e., "config true"). These data nodes may be 1157 considered sensitive or vulnerable in some network environments. 1159 There are a number of data nodes defined in this YANG module that are 1160 writable/creatable/deletable (i.e., config true, which is the 1161 default). These data nodes may be considered sensitive or vulnerable 1162 in some network environments. Write operations (e.g., edit-config) 1163 to these data nodes without proper protection can have a negative 1164 effect on network operations. These are the subtrees and data nodes 1165 and their sensitivity/vulnerability: 1167 o /te:te/te:tunnels/te:tunnel/te-scaling-intent/scale-in-intent 1169 o /te:te/te:tunnels/te:tunnel/te-scaling-intent/scale-out-intent 1171 o /vn:vn/vn:vn-list/vn-scaling-intent/scale-in-intent 1172 o /vn:vn/vn:vn-list/vn-scaling-intent/scale-out-intent 1174 9. IANA Considerations 1176 This document registers the following namespace URIs in the IETF XML 1177 registry [RFC3688]: 1179 -------------------------------------------------------------------- 1180 URI: urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry 1181 Registrant Contact: The IESG. 1182 XML: N/A, the requested URI is an XML namespace. 1183 -------------------------------------------------------------------- 1185 -------------------------------------------------------------------- 1186 URI: urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry 1187 Registrant Contact: The IESG. 1188 XML: N/A, the requested URI is an XML namespace. 1189 -------------------------------------------------------------------- 1191 This document registers the following YANG modules in the YANG 1192 Module. 1194 Names registry [RFC7950]: 1196 -------------------------------------------------------------------- 1197 name: ietf-te-kpi-telemetry 1198 namespace: urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry 1199 prefix: te-tel 1200 reference: RFC XXXX (TBD) 1201 -------------------------------------------------------------------- 1203 -------------------------------------------------------------------- 1204 name: ietf-vn-kpi-telemetry 1205 namespace: urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry 1206 prefix: vn-tel 1207 reference: RFC XXXX (TBD) 1208 -------------------------------------------------------------------- 1210 10. Acknowledgements 1212 We thank Rakesh Gandhi, Tarek Saad, Igor Bryskin and Kenichi Ogaki 1213 for useful discussions and their suggestions for this work. 1215 11. References 1216 11.1. Normative References 1218 [I-D.ietf-teas-actn-vn-yang] 1219 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 1220 Yoon, "A YANG Data Model for VN Operation", draft-ietf- 1221 teas-actn-vn-yang-09 (work in progress), July 2020. 1223 [I-D.ietf-teas-yang-te] 1224 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1225 "A YANG Data Model for Traffic Engineering Tunnels, Label 1226 Switched Paths and Interfaces", draft-ietf-teas-yang-te-25 1227 (work in progress), July 2020. 1229 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1230 Requirement Levels", BCP 14, RFC 2119, 1231 DOI 10.17487/RFC2119, March 1997, 1232 . 1234 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1235 DOI 10.17487/RFC3688, January 2004, 1236 . 1238 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1239 and A. Bierman, Ed., "Network Configuration Protocol 1240 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1241 . 1243 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1244 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1245 . 1247 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1248 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1249 . 1251 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 1252 Ceccarelli, D., and X. Zhang, "Problem Statement and 1253 Architecture for Information Exchange between 1254 Interconnected Traffic-Engineered Networks", BCP 206, 1255 RFC 7926, DOI 10.17487/RFC7926, July 2016, 1256 . 1258 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1259 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1260 . 1262 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1263 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1264 . 1266 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1267 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1268 May 2017, . 1270 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, 1271 "Extensions to the Path Computation Element Communication 1272 Protocol (PCEP) to Compute Service-Aware Label Switched 1273 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 1274 2017, . 1276 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1277 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1278 . 1280 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1281 Access Control Model", STD 91, RFC 8341, 1282 DOI 10.17487/RFC8341, March 2018, 1283 . 1285 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1286 and R. Wilton, "Network Management Datastore Architecture 1287 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1288 . 1290 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1291 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1292 . 1294 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1295 E., and A. Tripathy, "Dynamic Subscription to YANG Events 1296 and Datastores over NETCONF", RFC 8640, 1297 DOI 10.17487/RFC8640, September 2019, 1298 . 1300 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1301 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1302 September 2019, . 1304 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1305 "Common YANG Data Types for Traffic Engineering", 1306 RFC 8776, DOI 10.17487/RFC8776, June 2020, 1307 . 1309 11.2. Informative References 1311 [I-D.xu-actn-perf-dynamic-service-control] 1312 Xu, Y., Zhang, G., Cheng, W., and z. 1313 zhenghaomian@huawei.com, "Use Cases and Requirements of 1314 Dynamic Service Control based on Performance Monitoring in 1315 ACTN Architecture", draft-xu-actn-perf-dynamic-service- 1316 control-03 (work in progress), April 2015. 1318 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1319 Previdi, "OSPF Traffic Engineering (TE) Metric 1320 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1321 . 1323 [RFC7823] Atlas, A., Drake, J., Giacalone, S., and S. Previdi, 1324 "Performance-Based Path Selection for Explicitly Routed 1325 Label Switched Paths (LSPs) Using TE Metric Extensions", 1326 RFC 7823, DOI 10.17487/RFC7823, May 2016, 1327 . 1329 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1330 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1331 . 1333 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1334 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1335 DOI 10.17487/RFC8453, August 2018, 1336 . 1338 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 1339 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 1340 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 1341 2019, . 1343 Authors' Addresses 1345 Young Lee (editor) 1346 Samsung Electronics 1348 Email: younglee.tx@gmail.com 1349 Dhruv Dhody (editor) 1350 Huawei Technologies 1351 Divyashree Techno Park, Whitefield 1352 Bangalore, Karnataka 560066 1353 India 1355 Email: dhruv.ietf@gmail.com 1357 Satish Karunanithi 1358 Huawei Technologies 1359 Divyashree Techno Park, Whitefield 1360 Bangalore, Karnataka 560066 1361 India 1363 Email: satish.karunanithi@gmail.com 1365 Ricard Vilalta 1366 CTTC 1367 Centre Tecnologic de Telecomunicacions de Catalunya (CTTC/CERCA) 1368 Barcelona 1369 Spain 1371 Email: ricard.vilalta@cttc.es 1373 Daniel King 1374 Lancaster University 1376 Email: d.king@lancaster.ac.uk 1378 Daniele Ceccarelli 1379 Ericsson 1380 Torshamnsgatan,48 1381 Stockholm, Sweden 1383 Email: daniele.ceccarelli@ericsson.com