idnits 2.17.1 draft-ietf-teas-actn-pm-telemetry-autonomics-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (July 13, 2020) is 1375 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-08 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-23 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: January 14, 2021 S. Karunanithi 6 Huawei Technologies 7 R. Vilalta 8 CTTC 9 D. King 10 Lancaster University 11 D. Ceccarelli 12 Ericsson 13 July 13, 2020 15 YANG models for VN/TE Performance Monitoring Telemetry and Scaling 16 Intent Autonomics 17 draft-ietf-teas-actn-pm-telemetry-autonomics-03 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 January 14, 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 . . . . . . . . . . . . . . . . . . . . . 25 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 26 86 11.2. Informative References . . . . . . . . . . . . . . . . . 28 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-07-13.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 "I-D.ietf-teas-yang-te-types: Traffic Engineering Common 678 YANG Types"; 679 } 681 organization 682 "IETF Traffic Engineering Architecture and Signaling (TEAS) 683 Working Group"; 684 contact 685 "WG Web: 686 WG List: 687 Editor: Young Lee 688 Dhruv Dhody "; 689 description 690 "This module describes YANG data model for performance 691 monitoring telemetry for te tunnels. 693 Copyright (c) 2020 IETF Trust and the persons identified as 694 authors of the code. All rights reserved. 696 Redistribution and use in source and binary forms, with or 697 without modification, is permitted pursuant to, and subject to 698 the license terms contained in, the Simplified BSD License set 699 forth in Section 4.c of the IETF Trust's Legal Provisions 700 Relating to IETF Documents 701 (https://trustee.ietf.org/license-info). 703 This version of this YANG module is part of RFC XXXX; see the 704 RFC itself for full legal notices. 706 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 707 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 708 'MAY', and 'OPTIONAL' in this document are to be interpreted as 709 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 710 they appear in all capitals, as shown here."; 712 /* Note: The RFC Editor will replace XXXX with the number 713 assigned to the RFC once draft-ietf-teas-pm-telemetry- 714 autonomics becomes an RFC.*/ 716 revision 2020-03-08 { 717 description 718 "Initial revision."; 719 reference 720 "RFC XXXX: YANG models for VN/TE Performance Monitoring 721 Telemetry and Scaling Intent Autonomics"; 722 } 724 identity telemetry-param-type { 725 description 726 "Base identity for telemetry param types"; 727 } 729 identity one-way-delay { 730 base telemetry-param-type; 731 description 732 "To specify average Delay in one (forward) 733 direction"; 734 reference 735 "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions. 736 RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions. 737 RFC7823: Performance-Based Path Selection for Explicitly 738 Routed Label Switched Paths (LSPs) Using TE Metric 739 Extensions"; 740 } 742 identity two-way-delay { 743 base telemetry-param-type; 744 description 745 "To specify average Delay in both (forward and reverse) 746 directions"; 747 reference 748 "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions. 749 RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions. 750 RFC7823: Performance-Based Path Selection for Explicitly 751 Routed Label Switched Paths (LSPs) Using TE Metric 752 Extensions"; 753 } 755 identity one-way-delay-variation { 756 base telemetry-param-type; 757 description 758 "To specify average Delay Variation in one (forward) direction"; 759 reference 760 "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions. 761 RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions. 762 RFC7823: Performance-Based Path Selection for Explicitly 763 Routed Label Switched Paths (LSPs) Using TE Metric 764 Extensions"; 765 } 767 identity two-way-delay-variation { 768 base telemetry-param-type; 769 description 770 "To specify average Delay Variation in both (forward and reverse) 771 directions"; 772 reference 773 "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions. 774 RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions. 775 RFC7823: Performance-Based Path Selection for Explicitly 776 Routed Label Switched Paths (LSPs) Using TE Metric 777 Extensions"; 778 } 780 identity utilized-bandwidth { 781 base telemetry-param-type; 782 description 783 "To specify utilized bandwidth over the specified source 784 and destination."; 785 reference 786 "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions. 788 RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions. 789 RFC7823: Performance-Based Path Selection for Explicitly 790 Routed Label Switched Paths (LSPs) Using TE Metric 791 Extensions"; 792 } 794 identity utilized-percentage { 795 base telemetry-param-type; 796 description 797 "To specify utilization percentage of the entity 798 (e.g., tunnel, link, etc.)"; 799 } 801 /* Typedef */ 803 typedef telemetry-id { 804 type inet:uri; 805 description 806 "Identifier for telemetry data. The precise 807 structure of the telemetry-id will be up to the 808 implementation. The identifier SHOULD be chosen 809 such that the same telemetry data will always be 810 identified through the same identifier, even if 811 the data model is instantiated in separate 812 datastores."; 813 } 815 typedef scaling-criteria-operation { 816 type enumeration { 817 enum AND { 818 description 819 "AND operation"; 820 } 821 enum OR { 822 description 823 "OR operation"; 824 } 825 } 826 description 827 "Operations to analize list of scaling criterias"; 828 } 830 grouping scaling-duration { 831 description 832 "Base scaling criteria durations"; 833 leaf threshold-time { 834 type uint32; 835 units "seconds"; 836 description 837 "The duration for which the criteria must hold true"; 838 } 839 leaf cooldown-time { 840 type uint32; 841 units "seconds"; 842 description 843 "The duration after a scaling-in/scaling-out action has been 844 triggered, for which there will be no further operation"; 845 } 846 } 848 grouping scaling-criteria { 849 description 850 "Grouping for scaling criteria"; 851 leaf performance-type { 852 type identityref { 853 base telemetry-param-type; 854 } 855 description 856 "Reference to the tunnel level telemetry type"; 857 } 858 leaf threshold-value { 859 type string; 860 description 861 "Scaling threshold for the telemetry parameter type"; 862 } 863 } 865 grouping scaling-in-intent { 866 description 867 "Basic scaling in intent"; 868 uses scaling-duration; 869 list scaling-condition { 870 key "performance-type"; 871 description 872 "Scaling conditions"; 873 uses scaling-criteria; 874 leaf scale-in-operation-type { 875 type scaling-criteria-operation; 876 default "AND"; 877 description 878 "Operation to be applied to check between scaling criterias 879 to check if the scale in threshold condition has been met. 880 Defaults to AND"; 881 } 882 } 883 } 884 grouping scaling-out-intent { 885 description 886 "Basic scaling out intent"; 887 uses scaling-duration; 888 list scaling-condition { 889 key "performance-type"; 890 description 891 "Scaling conditions"; 892 uses scaling-criteria; 893 leaf scale-out-operation-type { 894 type scaling-criteria-operation; 895 default "OR"; 896 description 897 "Operation to be applied to check between scaling criterias 898 to check if the scale out threshold condition has been met. 899 Defauls to OR"; 900 } 901 } 902 } 904 augment "/te:te/te:tunnels/te:tunnel" { 905 description 906 "Augmentation parameters for config scaling-criteria TE 907 tunnel topologies. Scale in/out criteria might be used 908 for network autonomics in order the controller to react 909 to a certain set of monitored params."; 910 container te-scaling-intent { 911 description 912 "The scaling intent"; 913 container scale-in-intent { 914 description 915 "scale-in"; 916 uses scaling-in-intent; 917 } 918 container scale-out-intent { 919 description 920 "scale-out"; 921 uses scaling-out-intent; 922 } 923 } 924 container te-telemetry { 925 config false; 926 description 927 "Telemetry Data"; 928 leaf id { 929 type telemetry-id; 930 description 931 "ID of telemetry data used for easy reference"; 933 } 934 uses te-types:performance-metrics-attributes; 935 } 936 } 937 } 939 941 7.2. ietf-vn-kpi-telemetry model 943 The YANG code is as follows: 945 file "ietf-vn-kpi-telemetry@2020-07-13.yang" 946 module ietf-vn-kpi-telemetry { 947 yang-version 1.1; 948 namespace "urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry"; 949 prefix vn-kpi; 951 /* Import VN */ 953 import ietf-vn { 954 prefix vn; 955 reference 956 "I-D.ietf-teas-actn-vn-yang: A YANG Data Model for VN 957 Operation"; 958 } 960 /* Import TE */ 962 import ietf-te { 963 prefix te; 964 reference 965 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 966 Engineering Tunnels and Interfaces"; 967 } 969 /* Import TE Common types */ 971 import ietf-te-types { 972 prefix te-types; 973 reference 974 "RFC 8776: Common YANG Data Types for Traffic Engineering"; 975 } 977 /* Import TE KPI */ 979 import ietf-te-kpi-telemetry { 980 prefix te-kpi; 981 reference 982 "RFC XXXX: YANG models for VN/TE Performance Monitoring 983 Telemetry and Scaling Intent Autonomics"; 984 } 986 /* Note: The RFC Editor will replace XXXX with the number 987 assigned to this draft.*/ 989 organization 990 "IETF Traffic Engineering Architecture and Signaling (TEAS) 991 Working Group"; 992 contact 993 "WG Web: 994 WG List: 995 Editor: Young Lee 996 Dhruv Dhody "; 997 description 998 "This module describes YANG data models for performance 999 monitoring telemetry for Virtual Network (VN). 1001 Copyright (c) 2020 IETF Trust and the persons identified as 1002 authors of the code. All rights reserved. 1004 Redistribution and use in source and binary forms, with or 1005 without modification, is permitted pursuant to, and subject to 1006 the license terms contained in, the Simplified BSD License set 1007 forth in Section 4.c of the IETF Trust's Legal Provisions 1008 Relating to IETF Documents 1009 (https://trustee.ietf.org/license-info). 1011 This version of this YANG module is part of RFC XXXX; see the 1012 RFC itself for full legal notices. 1014 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1015 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1016 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1017 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1018 they appear in all capitals, as shown here."; 1020 /* Note: The RFC Editor will replace XXXX with the number 1021 assigned to the RFC once draft-lee-teas-pm-telemetry- 1022 autonomics becomes an RFC.*/ 1024 revision 2020-07-13 { 1025 description 1026 "Initial revision."; 1027 reference 1028 "RFC XXXX: YANG models for VN/TE Performance Monitoring 1029 Telemetry and Scaling Intent Autonomics"; 1030 } 1032 typedef grouping-operation { 1033 type enumeration { 1034 enum MINIMUM { 1035 description 1036 "Select the minimum param"; 1037 } 1038 enum MAXIMUM { 1039 description 1040 "Select the maximum param"; 1041 } 1042 enum MEAN { 1043 description 1044 "Select the MEAN of the params"; 1045 } 1046 enum STD_DEV { 1047 description 1048 "Select the standard deviation of the monitored params"; 1049 } 1050 enum AND { 1051 description 1052 "Select the AND of the params"; 1053 } 1054 enum OR { 1055 description 1056 "Select the OR of the params"; 1057 } 1058 } 1059 description 1060 "Operations to analize list of monitored params"; 1061 } 1063 grouping vn-telemetry-param { 1064 description 1065 "augment of te-kpi:telemetry-param for VN specific params"; 1066 leaf-list te-grouped-params { 1067 type leafref { 1068 path 1069 "/te:te/te:tunnels/te:tunnel/te-kpi:te-telemetry/te-kpi:id"; 1070 } 1071 description 1072 "Allows the definition of a vn-telemetry param 1073 as a grouping of underlying TE params"; 1074 } 1075 leaf grouping-operation { 1076 type grouping-operation; 1077 description 1078 "describes the operation to apply to 1079 te-grouped-params"; 1080 } 1081 } 1083 augment "/vn:vn/vn:vn-list" { 1084 description 1085 "Augmentation parameters for state TE VN topologies."; 1086 container vn-scaling-intent { 1087 description 1088 "scaling intent"; 1089 container scale-in-intent { 1090 description 1091 "VN scale-in"; 1092 uses te-kpi:scaling-in-intent; 1093 } 1094 container scale-out-intent { 1095 description 1096 "VN scale-out"; 1097 uses te-kpi:scaling-out-intent; 1098 } 1099 } 1100 container vn-telemetry { 1101 config false; 1102 description 1103 "VN telemetry params"; 1104 uses te-types:performance-metrics-attributes; 1105 leaf grouping-operation { 1106 type grouping-operation; 1107 description 1108 "describes the operation to apply to the VN-members"; 1109 } 1110 } 1111 } 1113 augment "/vn:vn/vn:vn-list/vn:vn-member-list" { 1114 description 1115 "Augmentation parameters for state TE vn member topologies."; 1116 container vn-member-telemetry { 1117 config false; 1118 description 1119 "VN member telemetry params"; 1120 uses te-types:performance-metrics-attributes; 1121 uses vn-telemetry-param; 1122 } 1123 } 1124 } 1125 1127 8. Security Considerations 1129 The YANG module specified in this document defines a schema for data 1130 that is designed to be accessed via network management protocols such 1131 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1132 is the secure transport layer, and the mandatory-to-implement secure 1133 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1134 is HTTPS, and the mandatory-to-implement secure transport is TLS 1135 [RFC8446]. 1137 The NETCONF access control model [RFC8341] provides the means to 1138 restrict access for particular NETCONF users to a preconfigured 1139 subset of all available NETCONF protocol operations and content. The 1140 NETCONF Protocol over Secure Shell (SSH) [RFC6242] describes a method 1141 for invoking and running NETCONF within a Secure Shell (SSH) session 1142 as an SSH subsystem. The Network Configuration Access Control Model 1143 (NACM) [RFC8341] provides the means to restrict access for particular 1144 NETCONF or RESTCONF users to a preconfigured subset of all available 1145 NETCONF or RESTCONF protocol operations and content. 1147 A number of configuration data nodes defined in this document are 1148 writable/deletable (i.e., "config true"). These data nodes may be 1149 considered sensitive or vulnerable in some network environments. 1151 There are a number of data nodes defined in this YANG module that are 1152 writable/creatable/deletable (i.e., config true, which is the 1153 default). These data nodes may be considered sensitive or vulnerable 1154 in some network environments. Write operations (e.g., edit-config) 1155 to these data nodes without proper protection can have a negative 1156 effect on network operations. These are the subtrees and data nodes 1157 and their sensitivity/vulnerability: 1159 o /te:te/te:tunnels/te:tunnel/te-scaling-intent/scale-in-intent 1161 o /te:te/te:tunnels/te:tunnel/te-scaling-intent/scale-out-intent 1163 o /vn:vn/vn:vn-list/vn-scaling-intent/scale-in-intent 1165 o /vn:vn/vn:vn-list/vn-scaling-intent/scale-out-intent 1167 9. IANA Considerations 1169 This document registers the following namespace URIs in the IETF XML 1170 registry [RFC3688]: 1172 -------------------------------------------------------------------- 1173 URI: urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry 1174 Registrant Contact: The IESG. 1175 XML: N/A, the requested URI is an XML namespace. 1176 -------------------------------------------------------------------- 1178 -------------------------------------------------------------------- 1179 URI: urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry 1180 Registrant Contact: The IESG. 1181 XML: N/A, the requested URI is an XML namespace. 1182 -------------------------------------------------------------------- 1184 This document registers the following YANG modules in the YANG 1185 Module. 1187 Names registry [RFC7950]: 1189 -------------------------------------------------------------------- 1190 name: ietf-te-kpi-telemetry 1191 namespace: urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry 1192 prefix: te-tel 1193 reference: RFC XXXX (TDB) 1194 -------------------------------------------------------------------- 1196 -------------------------------------------------------------------- 1197 name: ietf-vn-kpi-telemetry 1198 namespace: urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry 1199 prefix: vn-tel 1200 reference: RFC XXXX (TDB) 1201 -------------------------------------------------------------------- 1203 10. Acknowledgements 1205 We thank Rakesh Gandhi, Tarek Saad, Igor Bryskin and Kenichi Ogaki 1206 for useful discussions and their suggestions for this work. 1208 11. References 1210 11.1. Normative References 1212 [I-D.ietf-teas-actn-vn-yang] 1213 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. 1214 Yoon, "A Yang Data Model for VN Operation", draft-ietf- 1215 teas-actn-vn-yang-08 (work in progress), March 2020. 1217 [I-D.ietf-teas-yang-te] 1218 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1219 "A YANG Data Model for Traffic Engineering Tunnels and 1220 Interfaces", draft-ietf-teas-yang-te-23 (work in 1221 progress), March 2020. 1223 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1224 Requirement Levels", BCP 14, RFC 2119, 1225 DOI 10.17487/RFC2119, March 1997, 1226 . 1228 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1229 DOI 10.17487/RFC3688, January 2004, 1230 . 1232 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1233 and A. Bierman, Ed., "Network Configuration Protocol 1234 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1235 . 1237 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1238 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1239 . 1241 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1242 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1243 . 1245 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 1246 Ceccarelli, D., and X. Zhang, "Problem Statement and 1247 Architecture for Information Exchange between 1248 Interconnected Traffic-Engineered Networks", BCP 206, 1249 RFC 7926, DOI 10.17487/RFC7926, July 2016, 1250 . 1252 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1253 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1254 . 1256 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1257 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1258 . 1260 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1261 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1262 May 2017, . 1264 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, 1265 "Extensions to the Path Computation Element Communication 1266 Protocol (PCEP) to Compute Service-Aware Label Switched 1267 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 1268 2017, . 1270 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1271 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1272 . 1274 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1275 Access Control Model", STD 91, RFC 8341, 1276 DOI 10.17487/RFC8341, March 2018, 1277 . 1279 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1280 and R. Wilton, "Network Management Datastore Architecture 1281 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1282 . 1284 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1285 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1286 . 1288 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1289 E., and A. Tripathy, "Dynamic Subscription to YANG Events 1290 and Datastores over NETCONF", RFC 8640, 1291 DOI 10.17487/RFC8640, September 2019, 1292 . 1294 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1295 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1296 September 2019, . 1298 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1299 "Common YANG Data Types for Traffic Engineering", 1300 RFC 8776, DOI 10.17487/RFC8776, June 2020, 1301 . 1303 11.2. Informative References 1305 [I-D.xu-actn-perf-dynamic-service-control] 1306 Xu, Y., Zhang, G., Cheng, W., and z. 1307 zhenghaomian@huawei.com, "Use Cases and Requirements of 1308 Dynamic Service Control based on Performance Monitoring in 1309 ACTN Architecture", draft-xu-actn-perf-dynamic-service- 1310 control-03 (work in progress), April 2015. 1312 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1313 Previdi, "OSPF Traffic Engineering (TE) Metric 1314 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1315 . 1317 [RFC7823] Atlas, A., Drake, J., Giacalone, S., and S. Previdi, 1318 "Performance-Based Path Selection for Explicitly Routed 1319 Label Switched Paths (LSPs) Using TE Metric Extensions", 1320 RFC 7823, DOI 10.17487/RFC7823, May 2016, 1321 . 1323 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1324 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1325 . 1327 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1328 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1329 DOI 10.17487/RFC8453, August 2018, 1330 . 1332 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 1333 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 1334 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 1335 2019, . 1337 Authors' Addresses 1339 Young Lee (editor) 1340 Samsung Electronics 1342 Email: younglee.tx@gmail.com 1344 Dhruv Dhody (editor) 1345 Huawei Technologies 1346 Divyashree Techno Park, Whitefield 1347 Bangalore, Karnataka 560066 1348 India 1350 Email: dhruv.ietf@gmail.com 1351 Satish Karunanithi 1352 Huawei Technologies 1353 Divyashree Techno Park, Whitefield 1354 Bangalore, Karnataka 560066 1355 India 1357 Email: satish.karunanithi@gmail.com 1359 Ricard Vilalta 1360 CTTC 1361 Centre Tecnologic de Telecomunicacions de Catalunya (CTTC/CERCA) 1362 Barcelona 1363 Spain 1365 Email: ricard.vilalta@cttc.es 1367 Daniel King 1368 Lancaster University 1370 Email: d.king@lancaster.ac.uk 1372 Daniele Ceccarelli 1373 Ericsson 1374 Torshamnsgatan,48 1375 Stockholm, Sweden 1377 Email: daniele.ceccarelli@ericsson.com