idnits 2.17.1 draft-ietf-teas-actn-pm-telemetry-autonomics-06.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 August 2021) is 968 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 189, but not defined == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-12 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-27 Summary: 1 error (**), 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: 26 February 2022 S. Karunanithi 6 Huawei Technologies 7 R. Vilalta 8 CTTC 9 D. King 10 Lancaster University 11 D. Ceccarelli 12 Ericsson 13 25 August 2021 15 YANG models for VN/TE Performance Monitoring Telemetry and Scaling 16 Intent Autonomics 17 draft-ietf-teas-actn-pm-telemetry-autonomics-06 19 Abstract 21 This document provides YANG data models that describe performance 22 monitoring telemetry and scaling intent mechanisms for TE-tunnels and 23 Virtual Networks (VNs). 25 The models presented in this document allow customers to subscribe to 26 and monitor the key performance data of the TE-tunnel or the VN. The 27 models also provide customers with the ability to program autonomic 28 scaling intent mechanisms on the level of TE-tunnel as well as VN. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 26 February 2022. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4 66 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4 67 2. Use-Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Design of the Data Models . . . . . . . . . . . . . . . . . . 7 69 3.1. TE Telemetry Model . . . . . . . . . . . . . . . . . . . 7 70 3.2. VN Telemetry Model . . . . . . . . . . . . . . . . . . . 8 71 4. Autonomic Scaling Intent Mechanism . . . . . . . . . . . . . 9 72 5. Notification . . . . . . . . . . . . . . . . . . . . . . . . 11 73 5.1. YANG Push Subscription Examples . . . . . . . . . . . . . 11 74 5.2. Scaling Examples . . . . . . . . . . . . . . . . . . . . 13 75 6. YANG Data Tree . . . . . . . . . . . . . . . . . . . . . . . 16 76 7. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 19 77 7.1. ietf-te-telemetry model . . . . . . . . . . . . . . . . . 19 78 7.2. ietf-vn-telemetry model . . . . . . . . . . . . . . . . . 26 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 83 11.1. Normative References . . . . . . . . . . . . . . . . . . 33 84 11.2. Informative References . . . . . . . . . . . . . . . . . 35 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 87 1. Introduction 89 The YANG [RFC7950] model in [I-D.ietf-teas-actn-vn-yang] is used to 90 operate customer-driven Virtual Networks (VNs) during the computation 91 of VN, its instantiation, and its life-cycle service management and 92 operations. YANG model in [I-D.ietf-teas-yang-te] is used to operate 93 TE-tunnels during the tunnel instantiation, and its life-cycle 94 management and operations. 96 The models presented in this draft allow the applications hosted by 97 the customers to subscribe to and monitor their key performance data 98 of their interest on the level of VN [I-D.ietf-teas-actn-vn-yang] or 99 TE-tunnel [I-D.ietf-teas-yang-te]. The key characteristic of the 100 models presented in this document is a top-down programmability that 101 allows the applications hosted by the customers to subscribe to and 102 monitor key performance data of their interest and autonomic scaling 103 intent mechanism on the level of VN as well as TE-tunnel. 105 According to the classification of [RFC8309], the YANG data models 106 presented in this document can be classified as customer service 107 models. These can be mapped to the CMI (Customer Network Controller 108 (CNC)- Multi-Domain Service Coordinator (MSDC) interface) of ACTN 109 [RFC8453]. 111 [RFC8233] describes key network performance data to be considered for 112 end-to-end path computation in TE networks. The services provided 113 can be optimized to meet the requirements (such as traffic patterns, 114 quality, and reliability) of the applications hosted by the 115 customers. 117 This document provides YANG data models generically applicable to any 118 VN/TE-Tunnel service clients to provide an ability to program their 119 customized performance monitoring subscription and publication data 120 models and automatic scaling in/out intent data models. These models 121 can be utilized by a client network controller to initiate the 122 capabilities to a TE network controller communicating with the client 123 controller via a NETCONF [RFC8341] or a RESTCONF [RFC8040] interface. 125 The term performance monitoring is used in this document in a 126 different from how the term has been used in TE networks for many 127 years. Performance monitoring in this document refers to 128 subscription and publication of streaming telemetry data. 129 Subscription is initiated by the client (e.g., CNC) while publication 130 is provided by the network (e.g., MDSC/Provisioning Network 131 Controller (PNC)) based on the client's subscription. As the scope 132 of performance monitoring in this document is telemetry data on the 133 level of a client's VN or TE-tunnel, the entity interfacing to the 134 client (e.g., MDSC) has to provide VN or TE-tunnel level information. 135 This requires the controller to have the capability to derive VN or 136 TE-tunnel level performance data based on lower-level data collected 137 via PM counters in the Network Elements (NE). How the controller 138 entity derives such customized level data (i.e., VN or TE-tunnel 139 level) is out of the scope of this document. 141 The data model includes configuration and state data according to the 142 Network Management Datastore Architecture (NMDA) [RFC8342]. 144 1.1. Terminology 146 Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used 147 in this document. 149 Scaling: This refers to the network's ability to re-shape its own 150 resources. "Scale out" refers to improve network performance by 151 increasing the allocated resources, while "scale in" refers to 152 decreasing the allocated resources, typically because the existing 153 resources are unnecessary. 155 Scaling Intent: Scaling intent is used to declare scaling conditions. 156 Specifically, scaling intent refers to how the client programs or 157 configures conditions that will be applied to their key performance 158 data to trigger either scaling out or scaling in. Various conditions 159 can be set for scaling intent on either VN or TE-tunnel level. 161 Network Autonomics: This refers to the network automation capability 162 that allows a client to initiate scaling intent mechanisms and 163 provides the client with the status of the adjusted network resources 164 based on the client's scaling intent in an automated fashion. 166 1.2. Tree Diagram 168 A simplified graphical representation of the data model is used in 169 Section 4 and Section 6 of this document. The meaning of the symbols 170 in these diagrams is defined in [RFC8340]. 172 1.3. Prefixes in Data Node Names 174 In this document, names of data nodes and other data model objects 175 are prefixed using the standard prefix associated with the 176 corresponding YANG imported modules, as shown in Table 1. 178 +==========+===================+==============================+ 179 | Prefix | YANG module | Reference | 180 +==========+===================+==============================+ 181 | te | ietf-te | [I-D.ietf-teas-yang-te] | 182 +----------+-------------------+------------------------------+ 183 | te-types | ietf-te-types | [RFC8776] | 184 +----------+-------------------+------------------------------+ 185 | te-tel | ietf-te-telemetry | [RFCXXXX] | 186 +----------+-------------------+------------------------------+ 187 | vn | ietf-vn | [I-D.ietf-teas-actn-vn-yang] | 188 +----------+-------------------+------------------------------+ 189 | vn-tel | ietf-vn-telemetry | [RFCXXXX] | 190 +----------+-------------------+------------------------------+ 192 Table 1: Prefixes and corresponding YANG modules 194 Note: The RFC Editor is requested to replace XXXX with the number 195 assigned to the RFC once this draft becomes an RFC, and to remove 196 this note. 198 Further, the following additional documents are referenced in the 199 model defined in this document - 201 * [RFC7471] - OSPF Traffic Engineering (TE) Metric Extensions. 203 * [RFC8570] - IS-IS Traffic Engineering (TE) Metric Extensions. 205 * [RFC7823] - Performance-Based Path Selection for Explicitly Routed 206 Label Switched Paths (LSPs) Using TE Metric Extensions. 208 2. Use-Cases 210 There is a need for real-time (or semi-real-time) traffic monitoring 211 of the network to optimize the network and the traffic distribution. 212 Figure 1 shows the high-level workflow for dynamic service control 213 based on traffic monitoring. 215 +----------------------------------------------+ 216 | Client +-----------------------------+ | 217 | | Dynamic Service Control APP | | 218 | +-----------------------------+ | 219 +----------------------------------------------+ 220 1.Traffic| /|\4.Traffic | /|\ 221 Monitor &| | Monitor | | 8.Traffic 222 Optimize | | Result 5.Service | | modify & 223 Policy | | modify &| | optimize 224 \|/ | optimize Req.\|/ | result 225 +----------------------------------------------+ 226 | Orchestrator | 227 | +-------------------------------+ | 228 | |Dynamic Service Control Agent | | 229 | +-------------------------------+ | 230 | +---------------+ +-------------------+ | 231 | | Flow Optimize | | vConnection Agent | | 232 | +---------------+ +-------------------+ | 233 +----------------------------------------------+ 234 2. Path | /|\3.Traffic | /|\ 235 Monitor | | Monitor | |7.Path 236 Request | | Result 6.Path | | modify & 237 | | modify & | | optimize 238 \|/ | optimize Req.\|/ | result 239 +----------------------------------------------+ 240 | Network SDN Controller | 241 | +----------------------+ +-----------------+| 242 | | Network Provisioning | |Abstract Topology|| 243 | +----------------------+ +-----------------+| 244 | +------------------+ +--------------------+ | 245 | |Network Monitoring| |Physical Topology DB| | 246 | +------------------+ +--------------------+ | 247 +----------------------------------------------+ 249 APP: Application 250 DB: Database 251 Req: Request 253 Figure 1: Workflow for dynamic service control based on traffic 254 monitoring 256 Some of the key points are as follows: 258 * Network traffic monitoring is important to facilitate automatic 259 discovery of the imbalance of network traffic, and initiate 260 network optimization, thus helping the network operator or the 261 virtual network service provider to use the network more 262 efficiently and save Capital Expense (CAPEX) and Operating Expense 263 (OPEX). 265 * Customer services have various Service Level Agreement (SLA) 266 requirements, such as service availability, latency, jitter, 267 packet loss rate, Bit Error Rate (BER), etc. The TE network can 268 satisfy service availability and BER requirements by providing 269 different protection and restoration mechanisms. However, for 270 other SLA requirements, there are no such mechanisms. In order to 271 provide high quality services according to the customer SLA, one 272 possible solution is to measure the SLA related performance 273 parameters, and dynamically provision and optimize services based 274 on the performance monitoring results. 276 * Performance monitoring in a large scale network could generate a 277 huge amount of performance information. Therefore, the 278 appropriate way to deliver the information at the client and 279 network interfaces should be carefully considered. 281 3. Design of the Data Models 283 This document describes two YANG models: 285 (i) TE Telemetry Model which provides the TE-Tunnel level of 287 performance monitoring mechanism and scaling intent mechanism 288 that allows scale in/out programming by the customer. (See 289 Section 3.1 & Section 7.1 for details). 291 (ii) VN Telemetry Model which provides the VN level of the 293 aggregated performance monitoring mechanism and scaling intent 294 mechanism that allows scale in/out programming by the customer 295 (See Section 3.2 & Section 7.2 for details). 297 3.1. TE Telemetry Model 299 This model describes the performance telemetry for the TE tunnel. 300 The telemetry data is augmented to the TE tunnel. This model also 301 allows autonomic traffic engineering scaling intent configuration 302 mechanism on the TE-tunnel level. Various conditions can be set for 303 auto-scaling based on the telemetry data (See Section 5 for details) 304 As shown in Figure 2, the TE Telemetry Model augments the TE-Tunnel 305 Model to enhance TE performance monitoring capability. This 306 monitoring capability will facilitate proactive re-optimization and 307 reconfiguration of TE tunnels based on the performance monitoring 308 data collected via the TE Telemetry YANG model. 310 +------------+ +--------------+ 311 | TE-Tunnel | | TE | 312 | Model |<---------| Telemetry | 313 +------------+ augments | Model | 314 +--------------+ 316 Figure 2: TE Telemetry Model Relationship 318 3.2. VN Telemetry Model 320 As shown in Figure 3, the VN Telemetry Model augments the basic VN 321 model to enhance VN monitoring capability. This monitoring 322 capability will facilitate proactive re-optimization and 323 reconfiguration of VNs based on the performance monitoring data 324 collected via the VN Telemetry YANG model. This model also imports 325 TE telemetry model to reuse the groupings. 327 +----------+ +--------------+ 328 | VN | augments | VN | 329 | Model |<---------| Telemetry | 330 +----------+ | Model | 331 +--------------+ 332 | 333 | imports 334 v 335 +--------------+ 336 | TE | 337 | Telemetry | 338 | Model | 339 +--------------+ 341 Figure 3: VN Telemetry Model Relationships 343 This model describes the performance telemetry for the VN model. The 344 telemetry data is augmented to the VN model at the VN Level as well 345 as at the individual VN member level. This model also allows 346 autonomic traffic engineering scaling intent configuration mechanism 347 on the VN level. Scale in/out criteria might be used for network 348 autonomics in order for the controller to react to a certain set of 349 variations in monitored parameters (See Section 4 for illustrations). 351 Moreover, this model also provides a mechanism to define aggregated 352 VN telemetry parameters as a grouping of underlying VN-member level 353 telemetry parameters. This is unique to the VN model as a VN is made 354 up of multiple VN-members and further each VN-member could be set 355 across multiple TE tunnels. Grouping operation (such as maximum, 356 mean) could be set at the time of configuration. For example, if 357 "maximum" grouping operation is used for delay at the VN level, the 358 VN telemetry data is reported as the maximum of {delay_vn_member_1, 359 delay_vn_member_2,.. delay_vn_member_N}. Thus, this telemetry 360 aggregation mechanism allows the aggregation (or grouping) of a 361 certain common set of telemetry values under a grouping operation. 362 This can also be done at the VN-member level to suggest how the end- 363 to-end (E2E) telemetry be inferred from the per domain tunnels 364 created and monitored by PNCs. The Figure 4 provides an example 365 interaction. 367 +------------------------------------------------------------+ 368 | Client | 369 | | 370 +------------------------------------------------------------+ 371 1.Client sets the | /|\ 2. Orchestrator pushes: 372 grouping op, and | | 373 subscribes to the | | VN level telemetry for 374 VN level telemetry for | | - VN Utilized-bw-percentage 375 Delay and | | (Minimum across VN Members) 376 Utilized-bw-pecentage | | - VN Delay (Maximum across VN 377 \|/ | Members) 378 +------------------------------------------------------------+ 379 | Orchestrator | 380 | | 381 +------------------------------------------------------------+ 383 Figure 4: TE Telemetry Model Interactions 385 4. Autonomic Scaling Intent Mechanism 387 The scaling intent configuration mechanism allows the client to 388 configure automatic scale-in and scale-out mechanisms on both the TE- 389 tunnel and the VN level. Various conditions can be set for auto- 390 scaling based on the PM telemetry data. 392 There are a number of parameters involved in the mechanism: 394 * scale-out-intent or scale-in-intent: whether to scale-out or 395 scale-in. 397 * performance-type: performance metric type (e.g., one-way-delay, 398 one-way-delay-min, one-way-delay-max, two-way-delay, two-way- 399 delay-min, two-way-delay-max, utilized bandwidth, etc.) 401 * threshold-value: the threshold value for a certain performance- 402 type that triggers scale-in or scale-out. 404 * scaling-operation-type: in case where scaling condition can be set 405 with one or more performance types, then scaling-operation-type 406 (AND, OR, MIN, MAX, etc.) is applied to these selected performance 407 types and its threshold values. 409 * Threshold-time: the duration for which the criteria needs to hold 410 true. 412 * Cooldown-time: the duration after a scaling action has been 413 triggered, for which there will be no further operation. 415 The tree in Figure 5 is a part of ietf-te-telemetry tree whose model 416 is presented in full detail in Sections 6 & 7. 418 module: ietf-te-telemetry 419 augment /te:te/te:tunnels/te:tunnel: 420 +--rw te-scaling-intent 421 | +--rw scale-in-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-in-operation-type? 428 | | | scaling-criteria-operation 429 | | +--rw scale-in-op? identityref 430 | | +--rw scale? string 431 | +--rw scale-out-intent 432 | +--rw threshold-time? uint32 433 | +--rw cooldown-time? uint32 434 | +--rw scaling-condition* [performance-type] 435 | | +--rw performance-type identityref 436 | | +--rw threshold-value? string 437 | | +--rw scale-out-operation-type? 438 | | scaling-criteria-operation 439 | +--rw scale-out-op? identityref 440 | +--rw scale? string 442 Figure 5: The scaling intent 444 Let's say the client wants to set the scaling out operation based on 445 two performance-types (e.g., two-way-delay and utilized-bandwidth for 446 a te-tunnel), it can be done as follows: 448 * Set Threshold-time: x (sec) (duration for which the criteria must 449 hold true) 451 * Set Cooldown-time: y (sec) (the duration after a scaling action 452 has been triggered, for which there will be no further operation) 454 * Set AND for the scale-out-operation-type 456 In the scaling condition's list, the following two components can be 457 set: 459 List 1: Scaling Condition for Two-way-delay 461 * performance type: Two-way-delay 463 * threshold-value: z milli-seconds 465 List 2: Scaling Condition for Utilized bandwidth 467 * performance type: Utilized bandwidth 469 * threshold-value: w megabytes 471 5. Notification 473 This model does not define specific notifications. To enable 474 notifications, the mechanism defined in [RFC8641] and [RFC8640] can 475 be used. This mechanism currently allows the user to: 477 * Subscribe to notifications on a per client basis. 479 * Specify subtree filters or xpath filters so that only interested 480 contents will be sent. 482 * Specify either periodic or on-demand notifications. 484 5.1. YANG Push Subscription Examples 486 [RFC8641] allows subscriber applications to request a continuous, 487 customized stream of updates from a YANG datastore. 489 The example in Figure 6 shows the way for a client to subscribe to 490 the telemetry information for a particular tunnel (Tunnel1). The 491 telemetry parameter that the client is interested in is one-way- 492 delay. 494 496 498 499 500 501 502 Tunnel1 503 505 506 507 508 509 510 511 512 513 500 514 encode-xml 515 516 518 Figure 6: TE Tunnel Subscription Example 520 The example in Figure 7 shows the way for a client to subscribe to 521 the telemetry information for all VNs. The telemetry parameter that 522 the client is interested in is one-way-delay and one-way-utilized- 523 bandwidth. 525 527 529 530 531 532 533 535 536 537 538 539 540 541 542 543 544 545 500 546 547 549 Figure 7: VN Subscription Example 551 5.2. Scaling Examples 553 The example in Figure 8 shows the way to configure a TE tunnel with 554 the scaling-out intent to re-optimize when the the scaling condition 555 of two-way-delay crossing 100 milliseconds (100000 microseconds) for 556 a threshold of 1 min (60000 milliseconds). 558 559 560 561 562 563 564 565 566 Tunnel1 567 570 571 572 60000 573 574 575 576 two-way-delay 577 578 579 100000 580 581 582 re-optimize 583 584 585 586 587 588 589 590 591 593 Figure 8: TE Tunnel Scaling Example 595 The example in Figure 9 shows the way to configure a VN with the 596 scaling-in intent to reduce bandwidth when the the scaling condition 597 of two-way-delay crossing 100 milliseconds (100000 microseconds) for 598 a threshold of 1 min (60000 milliseconds). 600 601 602 603 604 605 606 607 VN1 608 611 612 60000 613 614 615 utilized-percentage 616 617 618 50 619 620 621 scale-capacity-down 622 623 624 625 626 627 628 629 631 Figure 9: VN Scaling Example 633 The example in Figure 10 shows the way to configure a grouping 634 operation at the VN level to require that the VN level one-way-delay 635 needs to be the reported as the max of the one-way-delay at the VN- 636 member level, where as the utilized-percentage is the mean. 638 639 640 641 642 643 644 645 VN1 646 649 650 651 one-way-delay 652 653 654 maximum 655 656 657 658 659 utilized-percentage 660 661 662 mean 663 664 665 666 667 668 669 671 Figure 10: VN Grouping Operation Example 673 6. YANG Data Tree 674 module: ietf-te-telemetry 675 augment /te:te/te:tunnels/te:tunnel: 676 +--rw te-scaling-intent 677 | +--rw scale-in-intent 678 | | +--rw threshold-time? uint32 679 | | +--rw cooldown-time? uint32 680 | | +--rw scaling-condition* [performance-type] 681 | | | +--rw performance-type identityref 682 | | | +--rw threshold-value? string 683 | | | +--rw scale-in-operation-type? 684 | | | scaling-criteria-operation 685 | | +--rw scale-in-op? identityref 686 | | +--rw scale? string 687 | +--rw scale-out-intent 688 | +--rw threshold-time? uint32 689 | +--rw cooldown-time? uint32 690 | +--rw scaling-condition* [performance-type] 691 | | +--rw performance-type identityref 692 | | +--rw threshold-value? string 693 | | +--rw scale-out-operation-type? 694 | | scaling-criteria-operation 695 | +--rw scale-out-op? identityref 696 | +--rw scale? string 697 +--ro te-telemetry 698 +--ro id? telemetry-id 699 +--ro performance-metrics-one-way 700 | +--ro one-way-delay? uint32 701 | +--ro one-way-delay-normality? 702 | | te-types:performance-metrics-normality 703 | +--ro one-way-residual-bandwidth? 704 | | rt-types:bandwidth-ieee-float32 705 | +--ro one-way-residual-bandwidth-normality? 706 | | te-types:performance-metrics-normality 707 | +--ro one-way-available-bandwidth? 708 | | rt-types:bandwidth-ieee-float32 709 | +--ro one-way-available-bandwidth-normality? 710 | | te-types:performance-metrics-normality 711 | +--ro one-way-utilized-bandwidth? 712 | | rt-types:bandwidth-ieee-float32 713 | +--ro one-way-utilized-bandwidth-normality? 714 | te-types:performance-metrics-normality 715 +--ro performance-metrics-two-way 716 +--ro two-way-delay? uint32 717 +--ro two-way-delay-normality? 718 te-types:performance-metrics-normality 720 Figure 11: ietf-te-telemetry YANG model tree 722 module: ietf-vn-telemetry 723 augment /vn:virtual-network/vn:vn: 724 +--rw vn-scaling-intent 725 | +--rw scale-in-intent 726 | | +--rw threshold-time? uint32 727 | | +--rw cooldown-time? uint32 728 | | +--rw scaling-condition* [performance-type] 729 | | | +--rw performance-type identityref 730 | | | +--rw threshold-value? string 731 | | | +--rw scale-in-operation-type? 732 | | | scaling-criteria-operation 733 | | +--rw scale-in-op? identityref 734 | | +--rw scale? string 735 | +--rw scale-out-intent 736 | +--rw threshold-time? uint32 737 | +--rw cooldown-time? uint32 738 | +--rw scaling-condition* [performance-type] 739 | | +--rw performance-type identityref 740 | | +--rw threshold-value? string 741 | | +--rw scale-out-operation-type? 742 | | scaling-criteria-operation 743 | +--rw scale-out-op? identityref 744 | +--rw scale? string 745 +--rw vn-telemetry 746 +--ro params 747 | +--ro performance-metrics-one-way 748 | | +--ro one-way-delay? uint32 749 | | +--ro one-way-delay-normality? 750 | | | te-types:performance-metrics-normality 751 | | +--ro one-way-residual-bandwidth? 752 | | | rt-types:bandwidth-ieee-float32 753 | | +--ro one-way-residual-bandwidth-normality? 754 | | | te-types:performance-metrics-normality 755 | | +--ro one-way-available-bandwidth? 756 | | | rt-types:bandwidth-ieee-float32 757 | | +--ro one-way-available-bandwidth-normality? 758 | | | te-types:performance-metrics-normality 759 | | +--ro one-way-utilized-bandwidth? 760 | | | rt-types:bandwidth-ieee-float32 761 | | +--ro one-way-utilized-bandwidth-normality? 762 | | te-types:performance-metrics-normality 763 | +--ro performance-metrics-two-way 764 | +--ro two-way-delay? uint32 765 | +--ro two-way-delay-normality? 766 | te-types:performance-metrics-normality 767 +--rw operation* [performance-type] 768 +--rw performance-type identityref 769 +--rw grouping-operation? identityref 771 augment /vn:virtual-network/vn:vn/vn:vn-member: 772 +--rw vn-member-telemetry 773 +--ro params 774 | +--ro performance-metrics-one-way 775 | | +--ro one-way-delay? uint32 776 | | +--ro one-way-delay-normality? 777 | | | te-types:performance-metrics-normality 778 | | +--ro one-way-residual-bandwidth? 779 | | | rt-types:bandwidth-ieee-float32 780 | | +--ro one-way-residual-bandwidth-normality? 781 | | | te-types:performance-metrics-normality 782 | | +--ro one-way-available-bandwidth? 783 | | | rt-types:bandwidth-ieee-float32 784 | | +--ro one-way-available-bandwidth-normality? 785 | | | te-types:performance-metrics-normality 786 | | +--ro one-way-utilized-bandwidth? 787 | | | rt-types:bandwidth-ieee-float32 788 | | +--ro one-way-utilized-bandwidth-normality? 789 | | te-types:performance-metrics-normality 790 | +--ro performance-metrics-two-way 791 | | +--ro two-way-delay? uint32 792 | | +--ro two-way-delay-normality? 793 | | te-types:performance-metrics-normality 794 | +--ro te-grouped-params* 795 | -> /te:te/tunnels/tunnel/te-tel:te-telemetry/id 796 +--rw operation* [performance-type] 797 +--rw performance-type identityref 798 +--rw grouping-operation? identityref 800 Figure 12: ietf-vn-telemetry YANG model tree 802 7. YANG Data Model 804 7.1. ietf-te-telemetry model 806 The YANG code is as follows: 808 file "ietf-te-telemetry@2021-08-25.yang" 809 module ietf-te-telemetry { 810 yang-version 1.1; 811 namespace "urn:ietf:params:xml:ns:yang:ietf-te-telemetry"; 812 prefix te-tel; 814 /* Import TE */ 816 import ietf-te { 817 prefix te; 818 reference 819 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 820 Engineering Tunnels and Interfaces"; 821 } 823 /* Import TE Common types */ 825 import ietf-te-types { 826 prefix te-types; 827 reference 828 "RFC 8776: Common YANG Data Types for Traffic Engineering"; 829 } 831 organization 832 "IETF Traffic Engineering Architecture and Signaling (TEAS) 833 Working Group"; 834 contact 835 "WG Web: 836 WG List: 837 Editor: Young Lee 838 Dhruv Dhody "; 839 description 840 "This module describes YANG data model for performance 841 monitoring telemetry for te tunnels. 842 Copyright (c) 2021 IETF Trust and the persons identified as 843 authors of the code. All rights reserved. 844 Redistribution and use in source and binary forms, with or 845 without modification, is permitted pursuant to, and subject to 846 the license terms contained in, the Simplified BSD License set 847 forth in Section 4.c of the IETF Trust's Legal Provisions 848 Relating to IETF Documents 849 (https://trustee.ietf.org/license-info). 851 This version of this YANG module is part of RFC XXXX; see the 852 RFC itself for full legal notices."; 854 /* Note: The RFC Editor will replace XXXX with the number 855 assigned to the RFC once draft-ietf-teas-pm-telemetry- 856 autonomics becomes an RFC.*/ 858 revision 2021-08-25 { 859 description 860 "Initial revision."; 861 reference 862 "RFC XXXX: YANG models for VN/TE Performance Monitoring 863 Telemetry and Scaling Intent Autonomics"; 864 } 866 identity telemetry-param-type { 867 description 868 "Base identity for telemetry param types"; 869 } 871 identity one-way-delay { 872 base telemetry-param-type; 873 description 874 "To specify average Delay in one (forward) direction. 876 At the VN level, it is the max delay of the VN-members. 878 The threshold-value for this type is interpreted as 879 microseconds."; 880 reference 881 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions. 882 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions. 883 RFC 7823: Performance-Based Path Selection for Explicitly 884 Routed Label Switched Paths (LSPs) Using TE Metric 885 Extensions"; 886 } 888 identity two-way-delay { 889 base telemetry-param-type; 890 description 891 "To specify average Delay in both (forward and reverse) 892 directions. 894 At the VN level, it is the max delay of the VN-members. 896 The threshold-value for this type is interpreted as 897 microseconds."; 898 reference 899 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions. 900 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions. 901 RFC 7823: Performance-Based Path Selection for Explicitly 902 Routed Label Switched Paths (LSPs) Using TE Metric 903 Extensions"; 904 } 906 identity one-way-delay-variation { 907 base telemetry-param-type; 908 description 909 "To specify average Delay Variation in one (forward) direction. 911 At the VN level, it is the max delay variation of the 912 VN-members. 914 The threshold-value for this type is interpreted as 915 microseconds."; 916 reference 917 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions. 918 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions. 919 RFC 7823: Performance-Based Path Selection for Explicitly 920 Routed Label Switched Paths (LSPs) Using TE Metric 921 Extensions"; 922 } 924 identity two-way-delay-variation { 925 base telemetry-param-type; 926 description 927 "To specify average Delay Variation in both (forward and 928 reverse) directions. 930 At the VN level, it is the max delay variation of the 931 VN-members. 933 The threshold-value for this type is interpreted as 934 microseconds."; 935 reference 936 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions. 937 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions. 938 RFC 7823: Performance-Based Path Selection for Explicitly 939 Routed Label Switched Paths (LSPs) Using TE Metric 940 Extensions"; 941 } 943 identity utilized-bandwidth { 944 base telemetry-param-type; 945 description 946 "To specify utilized bandwidth over the specified source 947 and destination. 949 The threshold-value for this type is interpreted as 950 bytes per second."; 951 reference 952 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions. 953 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions. 954 RFC 7823: Performance-Based Path Selection for Explicitly 955 Routed Label Switched Paths (LSPs) Using TE Metric 956 Extensions"; 957 } 959 identity utilized-percentage { 960 base telemetry-param-type; 961 description 962 "To specify utilization percentage of the entity 963 (e.g., tunnel, link, etc.)"; 964 } 966 identity scale-op { 967 description 968 "Base identity for scaling operation"; 969 } 971 identity scale-capacity-up { 972 base scale-op; 973 description 974 "Scale up the bandwidth capacity"; 975 } 977 identity scale-capacity-down { 978 base scale-op; 979 description 980 "Scale down the bandwidth capacity"; 981 } 983 /* Typedef */ 985 typedef telemetry-id { 986 type string; 987 description 988 "Identifier for the telemetry data."; 989 } 991 typedef scaling-criteria-operation { 992 type enumeration { 993 enum AND { 994 description 995 "AND operation"; 996 } 997 enum OR { 998 description 999 "OR operation"; 1000 } 1001 } 1002 description 1003 "Operations to analize list of scaling criterias"; 1004 } 1006 grouping scaling-duration { 1007 description 1008 "Base scaling criteria durations"; 1009 leaf threshold-time { 1010 type uint32; 1011 units "seconds"; 1012 description 1013 "The duration for which the criteria must hold true"; 1014 } 1015 leaf cooldown-time { 1016 type uint32; 1017 units "seconds"; 1018 description 1019 "The duration after a scaling-in/scaling-out action has been 1020 triggered, for which there will be no further operation"; 1021 } 1022 } 1024 grouping scaling-criteria { 1025 description 1026 "Grouping for scaling criteria"; 1027 leaf performance-type { 1028 type identityref { 1029 base telemetry-param-type; 1030 } 1031 description 1032 "Reference to the tunnel level telemetry type"; 1033 } 1034 leaf threshold-value { 1035 type string; 1036 description 1037 "Scaling threshold for the telemetry parameter type."; 1038 } 1039 } 1041 grouping scaling-in-intent { 1042 description 1043 "Basic scaling in intent"; 1044 uses scaling-duration; 1045 list scaling-condition { 1046 key "performance-type"; 1047 description 1048 "Scaling conditions"; 1049 uses scaling-criteria; 1050 leaf scale-in-operation-type { 1051 type scaling-criteria-operation; 1052 default "AND"; 1053 description 1054 "Operation to be applied to check between scaling criterias 1055 to check if the scale in threshold condition has been met. 1056 Defaults to AND"; 1057 } 1059 } 1060 leaf scale-in-op { 1061 type identityref { 1062 base scale-op; 1063 } 1064 default "scale-capacity-down"; 1065 description 1066 "The scaling operation to be performed when scaling condition 1067 is met"; 1068 } 1069 leaf scale { 1070 type string; 1071 description 1072 "Additional scaling-by information to be interpritted as per 1073 the scale-in-op."; 1074 } 1075 } 1077 grouping scaling-out-intent { 1078 description 1079 "Basic scaling out intent"; 1080 uses scaling-duration; 1081 list scaling-condition { 1082 key "performance-type"; 1083 description 1084 "Scaling conditions"; 1085 uses scaling-criteria; 1086 leaf scale-out-operation-type { 1087 type scaling-criteria-operation; 1088 default "OR"; 1089 description 1090 "Operation to be applied to check between scaling criterias 1091 to check if the scale out threshold condition has been met. 1092 Defauls to OR"; 1093 } 1094 } 1095 leaf scale-out-op { 1096 type identityref { 1097 base scale-op; 1098 } 1099 default "scale-capacity-up"; 1100 description 1101 "The scaling operation to be performed when scaling condition 1102 is met"; 1103 } 1104 leaf scale { 1105 type string; 1106 description 1107 "Additional scaling-by information to be interpritted as per 1108 the scale-out-op."; 1109 } 1110 } 1112 augment "/te:te/te:tunnels/te:tunnel" { 1113 description 1114 "Augmentation parameters for config scaling-criteria TE 1115 tunnel topologies. Scale in/out criteria might be used 1116 for network autonomics in order the controller to react 1117 to a certain set of monitored params."; 1118 container te-scaling-intent { 1119 description 1120 "The scaling intent"; 1121 container scale-in-intent { 1122 description 1123 "scale-in"; 1124 uses scaling-in-intent; 1125 } 1126 container scale-out-intent { 1127 description 1128 "scale-out"; 1129 uses scaling-out-intent; 1130 } 1131 } 1132 container te-telemetry { 1133 config false; 1134 description 1135 "Telemetry Data"; 1136 leaf id { 1137 type telemetry-id; 1138 description 1139 "ID of telemetry data used for easy reference"; 1140 } 1141 uses te-types:performance-metrics-attributes; 1142 } 1143 } 1144 } 1145 1147 7.2. ietf-vn-telemetry model 1149 The YANG code is as follows: 1151 file "ietf-vn-telemetry@2021-08-25.yang" 1152 module ietf-vn-telemetry { 1153 yang-version 1.1; 1154 namespace "urn:ietf:params:xml:ns:yang:ietf-vn-telemetry"; 1155 prefix vn-tel; 1157 /* Import VN */ 1159 import ietf-vn { 1160 prefix vn; 1161 reference 1162 "I-D.ietf-teas-actn-vn-yang: A YANG Data Model for VN 1163 Operation"; 1164 } 1166 /* Import TE */ 1168 import ietf-te { 1169 prefix te; 1170 reference 1171 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 1172 Engineering Tunnels and Interfaces"; 1173 } 1175 /* Import TE Common types */ 1177 import ietf-te-types { 1178 prefix te-types; 1179 reference 1180 "RFC 8776: Common YANG Data Types for Traffic Engineering"; 1181 } 1183 /* Import TE Telemetry */ 1185 import ietf-te-telemetry { 1186 prefix te-tel; 1187 reference 1188 "RFC XXXX: YANG models for VN/TE Performance Monitoring 1189 Telemetry and Scaling Intent Autonomics"; 1190 } 1192 /* Note: The RFC Editor will replace XXXX with the number 1193 assigned to this draft.*/ 1195 organization 1196 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1197 Working Group"; 1198 contact 1199 "WG Web: 1200 WG List: 1201 Editor: Young Lee 1202 Dhruv Dhody "; 1203 description 1204 "This module describes YANG data models for performance 1205 monitoring telemetry for Virtual Network (VN). 1207 Copyright (c) 2021 IETF Trust and the persons identified as 1208 authors of the code. All rights reserved. 1210 Redistribution and use in source and binary forms, with or 1211 without modification, is permitted pursuant to, and subject to 1212 the license terms contained in, the Simplified BSD License set 1213 forth in Section 4.c of the IETF Trust's Legal Provisions 1214 Relating to IETF Documents 1215 (https://trustee.ietf.org/license-info). 1217 This version of this YANG module is part of RFC XXXX; see the 1218 RFC itself for full legal notices."; 1220 /* Note: The RFC Editor will replace XXXX with the number 1221 assigned to the RFC once draft-lee-teas-pm-telemetry- 1222 autonomics becomes an RFC.*/ 1224 revision 2021-08-25 { 1225 description 1226 "Initial revision."; 1227 reference 1228 "RFC XXXX: YANG models for VN/TE Performance Monitoring 1229 Telemetry and Scaling Intent Autonomics"; 1230 } 1232 identity grouping-op { 1233 description 1234 "Base identity for grouping-operation"; 1235 } 1237 identity minimum { 1238 base grouping-op; 1239 description 1240 "Select the minimum of the monitored parameters"; 1241 } 1243 identity maximum { 1244 base grouping-op; 1245 description 1246 "The maximum of the monitored parameters"; 1248 } 1250 identity mean { 1251 base grouping-op; 1252 description 1253 "The mean of the monitored parameters"; 1254 } 1256 identity standard-deviation { 1257 base grouping-op; 1258 description 1259 "The standard deviation of the monitored parameters"; 1260 } 1262 identity sum { 1263 base grouping-op; 1264 description 1265 "The sum of the monitored parameters"; 1266 } 1268 identity and { 1269 base grouping-op; 1270 description 1271 "Logical AND operation"; 1272 } 1274 identity or { 1275 base grouping-op; 1276 description 1277 "Logical OR operation"; 1278 } 1280 grouping grouping-operation { 1281 list operation { 1282 key "performance-type"; 1283 leaf performance-type { 1284 type identityref { 1285 base te-tel:telemetry-param-type; 1286 } 1287 description 1288 "Reference to the tunnel level telemetry type"; 1289 } 1290 leaf grouping-operation { 1291 type identityref { 1292 base grouping-op; 1293 } 1294 description 1295 "describes the operation to apply to the te-grouped-params"; 1297 } 1298 description 1299 "Grouping operation for each performance-type"; 1300 } 1301 description 1302 "Grouping operation for each performance-type"; 1303 } 1305 augment "/vn:virtual-network/vn:vn" { 1306 description 1307 "Augmentation parameters for state TE VN topologies."; 1308 container vn-scaling-intent { 1309 description 1310 "scaling intent"; 1311 container scale-in-intent { 1312 description 1313 "VN scale-in"; 1314 uses te-tel:scaling-in-intent; 1315 } 1316 container scale-out-intent { 1317 description 1318 "VN scale-out"; 1319 uses te-tel:scaling-out-intent; 1320 } 1321 } 1322 container vn-telemetry { 1323 description 1324 "VN telemetry params"; 1325 container params { 1326 config false; 1327 description 1328 "Read-only telemetry parameters"; 1329 uses te-types:performance-metrics-attributes; 1330 } 1331 uses grouping-operation; 1332 } 1333 } 1335 augment "/vn:virtual-network/vn:vn/vn:vn-member" { 1336 description 1337 "Augmentation parameters for state TE vn member topologies."; 1338 container vn-member-telemetry { 1339 description 1340 "VN member telemetry params"; 1341 container params { 1342 config false; 1343 description 1344 "Read-only telemetry parameters"; 1346 uses te-types:performance-metrics-attributes; 1347 leaf-list te-grouped-params { 1348 type leafref { 1349 path 1350 "/te:te/te:tunnels/te:tunnel/" + 1351 "te-tel:te-telemetry/te-tel:id"; 1352 } 1353 description 1354 "A list of underlying TE parameters that form the 1355 VN-member"; 1356 } 1357 } 1358 uses grouping-operation; 1359 } 1360 } 1361 } 1362 1364 8. Security Considerations 1366 The YANG modules specified in this document defines a schema for data 1367 that is designed to be accessed via network management protocols such 1368 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1369 is the secure transport layer, and the mandatory-to-implement secure 1370 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1371 is HTTPS, and the mandatory-to-implement secure transport is TLS 1372 [RFC8446]. 1374 The Network Configuration Access Control Model (NACM) [RFC8341] 1375 provides the means to restrict access for particular NETCONF or 1376 RESTCONF users to a preconfigured subset of all available NETCONF or 1377 RESTCONF protocol operations and content. 1379 There are a number of data nodes defined in this YANG module that are 1380 writable/creatable/deletable (i.e., config true, which is the 1381 default). These data nodes may be considered sensitive or vulnerable 1382 in some network environments. Write operations (e.g., edit-config) 1383 to these data nodes without proper protection can have a negative 1384 effect on network operations. These are the subtrees with the write 1385 operation that can be exploited to impact the network monitoring. An 1386 incorrect condition could cause frequent scaling operation to be 1387 executed causing harm to the network: 1389 * /te:te/te:tunnels/te:tunnel/te-scaling-intent/scale-in-intent 1391 * /te:te/te:tunnels/te:tunnel/te-scaling-intent/scale-out-intent 1393 * /vn:virtual-network/vn:vn/vn-scaling-intent/scale-in-intent 1394 * /vn:virtual-network/vn:vn/vn-scaling-intent/scale-out-intent 1396 Further, following are the subtrees with the write operation that can 1397 be exploited by setting an incorrect grouping operation for the VN 1398 operation impacting the network monitoring: 1400 * /vn:virtual-network/vn:vn/vn-telemetry/operation 1402 * /vn:virtual-network/vn:vn/vn:vn-member/vn-member-telemetry/ 1403 operation 1405 Some of the readable data nodes in this YANG module may be considered 1406 sensitive or vulnerable in some network environments. It is thus 1407 important to control read access (e.g., via get, get-config, or 1408 notification) to these data nodes. These are the subtrees with the 1409 read operations that can be exploited to learn real-time (and 1410 sensitive) telemetry information about the TE tunnels and VN: 1412 * /te:te/te:tunnels/te:tunnel/te-telemetry 1414 * /vn:virtual-network/vn:vn/vn-telemetry 1416 * /vn:virtual-network/vn:vn/vn:vn-member/vn-member-telemetry 1418 9. IANA Considerations 1420 This document registers the following namespace URIs in the IETF XML 1421 registry [RFC3688]: 1423 -------------------------------------------------------------------- 1424 URI: urn:ietf:params:xml:ns:yang:ietf-te-telemetry 1425 Registrant Contact: The IESG. 1426 XML: N/A, the requested URI is an XML namespace. 1427 -------------------------------------------------------------------- 1429 -------------------------------------------------------------------- 1430 URI: urn:ietf:params:xml:ns:yang:ietf-vn-telemetry 1431 Registrant Contact: The IESG. 1432 XML: N/A, the requested URI is an XML namespace. 1433 -------------------------------------------------------------------- 1435 This document registers the following YANG modules in the YANG Module 1436 registry. 1438 Names registry [RFC7950]: 1440 -------------------------------------------------------------------- 1441 name: ietf-te-telemetry 1442 namespace: urn:ietf:params:xml:ns:yang:ietf-te-telemetry 1443 prefix: te-tel 1444 reference: RFC XXXX 1445 -------------------------------------------------------------------- 1447 -------------------------------------------------------------------- 1448 name: ietf-vn-telemetry 1449 namespace: urn:ietf:params:xml:ns:yang:ietf-vn-telemetry 1450 prefix: vn-tel 1451 reference: RFC XXXX 1452 -------------------------------------------------------------------- 1454 10. Acknowledgements 1456 We thank Adrian Farrel, Rakesh Gandhi, Tarek Saad, Igor Bryskin and 1457 Kenichi Ogaki for useful discussions and their suggestions for this 1458 work. 1460 11. References 1462 11.1. Normative References 1464 [I-D.ietf-teas-actn-vn-yang] 1465 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. Y. 1466 Yoon, "A YANG Data Model for VN Operation", Work in 1467 Progress, Internet-Draft, draft-ietf-teas-actn-vn-yang-12, 1468 25 August 2021, . 1471 [I-D.ietf-teas-yang-te] 1472 Saad, T., Gandhi, R., Liu, X., Beeram, V. P., Bryskin, I., 1473 and O. G. D. Dios, "A YANG Data Model for Traffic 1474 Engineering Tunnels, Label Switched Paths and Interfaces", 1475 Work in Progress, Internet-Draft, draft-ietf-teas-yang-te- 1476 27, 8 July 2021, . 1479 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1480 DOI 10.17487/RFC3688, January 2004, 1481 . 1483 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1484 and A. Bierman, Ed., "Network Configuration Protocol 1485 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1486 . 1488 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1489 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1490 . 1492 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 1493 Ceccarelli, D., and X. Zhang, "Problem Statement and 1494 Architecture for Information Exchange between 1495 Interconnected Traffic-Engineered Networks", BCP 206, 1496 RFC 7926, DOI 10.17487/RFC7926, July 2016, 1497 . 1499 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1500 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1501 . 1503 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1504 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1505 . 1507 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, 1508 "Extensions to the Path Computation Element Communication 1509 Protocol (PCEP) to Compute Service-Aware Label Switched 1510 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 1511 2017, . 1513 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1514 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1515 . 1517 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1518 Access Control Model", STD 91, RFC 8341, 1519 DOI 10.17487/RFC8341, March 2018, 1520 . 1522 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1523 and R. Wilton, "Network Management Datastore Architecture 1524 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1525 . 1527 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1528 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1529 . 1531 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1532 E., and A. Tripathy, "Dynamic Subscription to YANG Events 1533 and Datastores over NETCONF", RFC 8640, 1534 DOI 10.17487/RFC8640, September 2019, 1535 . 1537 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1538 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1539 September 2019, . 1541 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1542 "Common YANG Data Types for Traffic Engineering", 1543 RFC 8776, DOI 10.17487/RFC8776, June 2020, 1544 . 1546 11.2. Informative References 1548 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1549 Previdi, "OSPF Traffic Engineering (TE) Metric 1550 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1551 . 1553 [RFC7823] Atlas, A., Drake, J., Giacalone, S., and S. Previdi, 1554 "Performance-Based Path Selection for Explicitly Routed 1555 Label Switched Paths (LSPs) Using TE Metric Extensions", 1556 RFC 7823, DOI 10.17487/RFC7823, May 2016, 1557 . 1559 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1560 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1561 . 1563 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1564 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1565 DOI 10.17487/RFC8453, August 2018, 1566 . 1568 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 1569 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 1570 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 1571 2019, . 1573 Authors' Addresses 1575 Young Lee (editor) 1576 Samsung Electronics 1578 Email: younglee.tx@gmail.com 1580 Dhruv Dhody (editor) 1581 Huawei Technologies 1582 Divyashree Techno Park, Whitefield 1583 Bangalore 560066 1584 Karnataka 1585 India 1587 Email: dhruv.ietf@gmail.com 1589 Satish Karunanithi 1590 Huawei Technologies 1591 Divyashree Techno Park, Whitefield 1592 Bangalore 560066 1593 Karnataka 1594 India 1596 Email: satish.karunanithi@gmail.com 1598 Ricard Vilalta 1599 CTTC 1600 Centre Tecnologic de Telecomunicacions de Catalunya (CTTC/CERCA) 1601 Barcelona 1602 Spain 1604 Email: ricard.vilalta@cttc.es 1606 Daniel King 1607 Lancaster University 1609 Email: d.king@lancaster.ac.uk 1611 Daniele Ceccarelli 1612 Ericsson 1613 Torshamnsgatan,48 1614 Stockholm, Sweden 1616 Email: daniele.ceccarelli@ericsson.com