idnits 2.17.00 (12 Aug 2021) /tmp/idnits59378/draft-ietf-teas-actn-pm-telemetry-autonomics-08.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 document date (7 March 2022) is 68 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 192, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-opsawg-yang-vpn-service-pm-03 Summary: 1 error (**), 0 flaws (~~), 2 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: 8 September 2022 S. Karunanithi 6 Huawei Technologies 7 R. Vilalta 8 CTTC 9 D. King 10 Lancaster University 11 D. Ceccarelli 12 Ericsson 13 7 March 2022 15 YANG models for Virtual Network (VN)/TE Performance Monitoring Telemetry 16 and Scaling Intent Autonomics 17 draft-ietf-teas-actn-pm-telemetry-autonomics-08 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 8 September 2022. 47 Copyright Notice 49 Copyright (c) 2022 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 Revised BSD License text as 58 described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Revised BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 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 3.3. VPN Service Performance Monitoring . . . . . . . . . . . 9 72 4. Autonomic Scaling Intent Mechanism . . . . . . . . . . . . . 10 73 5. Notification . . . . . . . . . . . . . . . . . . . . . . . . 12 74 5.1. YANG Push Subscription Examples . . . . . . . . . . . . . 12 75 5.2. Scaling Examples . . . . . . . . . . . . . . . . . . . . 14 76 6. YANG Data Tree . . . . . . . . . . . . . . . . . . . . . . . 17 77 7. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 20 78 7.1. ietf-te-telemetry model . . . . . . . . . . . . . . . . . 20 79 7.2. ietf-vn-telemetry model . . . . . . . . . . . . . . . . . 27 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 34 85 11.2. Informative References . . . . . . . . . . . . . . . . . 36 86 Appendix A. Out of Scope . . . . . . . . . . . . . . . . . . . . 37 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 89 1. Introduction 91 The YANG [RFC7950] model in [I-D.ietf-teas-actn-vn-yang] is used to 92 operate customer-driven Virtual Networks (VNs) during the computation 93 of VN, its instantiation, and its life-cycle service management and 94 operations. YANG model in [I-D.ietf-teas-yang-te] is used to operate 95 TE-tunnels during the tunnel instantiation, and its life-cycle 96 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. These can be mapped to the CMI (Customer Network Controller 110 (CNC)- Multi-Domain Service Coordinator (MSDC) interface) of ACTN 111 [RFC8453]. 113 [RFC8233] describes key network performance data to be considered for 114 end-to-end path computation in TE networks. The services provided 115 can be optimized to meet the requirements (such as traffic patterns, 116 quality, and reliability) of the applications hosted by the 117 customers. 119 This document provides YANG data models generically applicable to any 120 VN/TE-Tunnel service clients to provide an ability to program their 121 customized performance monitoring subscription and publication data 122 models and automatic scaling in/out intent data models. These models 123 can be utilized by a client network controller to initiate the 124 capabilities to a TE network controller communicating with the client 125 controller via a NETCONF [RFC8341] or a RESTCONF [RFC8040] interface. 127 The term performance monitoring is used in this document in a 128 different from how the term has been used in TE networks for many 129 years. Performance monitoring in this document refers to 130 subscription and publication of streaming telemetry data. 131 Subscription is initiated by the client (e.g., CNC) while publication 132 is provided by the network (e.g., MDSC/Provisioning Network 133 Controller (PNC)) based on the client's subscription. As the scope 134 of performance monitoring in this document is telemetry data on the 135 level of a client's VN or TE-tunnel, the entity interfacing to the 136 client (e.g., MDSC) has to provide VN or TE-tunnel level information. 138 This requires the controller to have the capability to derive VN or 139 TE-tunnel level performance data based on lower-level data collected 140 via PM counters in the Network Elements (NE). How the controller 141 entity derives such customized level data (i.e., VN or TE-tunnel 142 level) is out of the scope of this document. 144 The data model includes configuration and state data according to the 145 Network Management Datastore Architecture (NMDA) [RFC8342]. 147 1.1. Terminology 149 Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used 150 in this document. 152 Scaling: This refers to the network's ability to re-shape its own 153 resources. "Scale out" refers to improve network performance by 154 increasing the allocated resources, while "scale in" refers to 155 decreasing the allocated resources, typically because the existing 156 resources are unnecessary. 158 Scaling Intent: Scaling intent is used to declare scaling conditions. 159 Specifically, scaling intent refers to how the client programs or 160 configures conditions that will be applied to their key performance 161 data to trigger either scaling out or scaling in. Various conditions 162 can be set for scaling intent on either VN or TE-tunnel level. 164 Network Autonomics: This refers to the network automation capability 165 that allows a client to initiate scaling intent mechanisms and 166 provides the client with the status of the adjusted network resources 167 based on the client's scaling intent in an automated fashion. 169 1.2. Tree Diagram 171 A simplified graphical representation of the data model is used in 172 Section 4 and Section 6 of this document. The meaning of the symbols 173 in these diagrams is defined in [RFC8340]. 175 1.3. Prefixes in Data Node Names 177 In this document, names of data nodes and other data model objects 178 are prefixed using the standard prefix associated with the 179 corresponding YANG imported modules, as shown in Table 1. 181 +==========+===================+==============================+ 182 | Prefix | YANG module | Reference | 183 +==========+===================+==============================+ 184 | te | ietf-te | [I-D.ietf-teas-yang-te] | 185 +----------+-------------------+------------------------------+ 186 | te-types | ietf-te-types | [RFC8776] | 187 +----------+-------------------+------------------------------+ 188 | te-tel | ietf-te-telemetry | [RFCXXXX] | 189 +----------+-------------------+------------------------------+ 190 | vn | ietf-vn | [I-D.ietf-teas-actn-vn-yang] | 191 +----------+-------------------+------------------------------+ 192 | vn-tel | ietf-vn-telemetry | [RFCXXXX] | 193 +----------+-------------------+------------------------------+ 195 Table 1: Prefixes and corresponding YANG modules 197 Note: The RFC Editor is requested to replace XXXX with the number 198 assigned to the RFC once this draft becomes an RFC, and to remove 199 this note. 201 Further, the following additional documents are referenced in the 202 model defined in this document - 204 * [RFC7471] - OSPF Traffic Engineering (TE) Metric Extensions. 206 * [RFC8570] - IS-IS Traffic Engineering (TE) Metric Extensions. 208 * [RFC7823] - Performance-Based Path Selection for Explicitly Routed 209 Label Switched Paths (LSPs) Using TE Metric Extensions. 211 2. Use-Cases 213 There is a need for real-time (or semi-real-time) traffic monitoring 214 of the network to optimize the network and the traffic distribution. 215 Figure 1 shows the high-level workflow for dynamic service control 216 based on traffic monitoring. 218 +----------------------------------------------+ 219 | Client +-----------------------------+ | 220 | | Dynamic Service Control APP | | 221 | +-----------------------------+ | 222 +----------------------------------------------+ 223 1.Traffic| /|\4.Traffic | /|\ 224 Monitor &| | Monitor | | 8.Traffic 225 Optimize | | Result 5.Service | | modify & 226 Policy | | modify &| | optimize 227 \|/ | optimize Req.\|/ | result 228 +----------------------------------------------+ 229 | Orchestrator | 230 | +-------------------------------+ | 231 | |Dynamic Service Control Agent | | 232 | +-------------------------------+ | 233 | +---------------+ +-------------------+ | 234 | | Flow Optimize | | vConnection Agent | | 235 | +---------------+ +-------------------+ | 236 +----------------------------------------------+ 237 2. Path | /|\3.Traffic | /|\ 238 Monitor | | Monitor | |7.Path 239 Request | | Result 6.Path | | modify & 240 | | modify & | | optimize 241 \|/ | optimize Req.\|/ | result 242 +----------------------------------------------+ 243 | Network SDN Controller | 244 | +----------------------+ +-----------------+| 245 | | Network Provisioning | |Abstract Topology|| 246 | +----------------------+ +-----------------+| 247 | +------------------+ +--------------------+ | 248 | |Network Monitoring| |Physical Topology DB| | 249 | +------------------+ +--------------------+ | 250 +----------------------------------------------+ 252 APP: Application 253 DB: Database 254 Req: Request 256 Figure 1: Workflow for dynamic service control based on traffic 257 monitoring 259 Some of the key points are as follows: 261 * Network traffic monitoring is important to facilitate automatic 262 discovery of the imbalance of network traffic, and initiate 263 network optimization, thus helping the network operator or the 264 virtual network service provider to use the network more 265 efficiently and save Capital Expense (CAPEX) and Operating Expense 266 (OPEX). 268 * Customer services have various Service Level Agreement (SLA) 269 requirements, such as service availability, latency, jitter, 270 packet loss rate, Bit Error Rate (BER), etc. The TE network can 271 satisfy service availability and BER requirements by providing 272 different protection and restoration mechanisms. However, for 273 other SLA requirements, there are no such mechanisms. In order to 274 provide high quality services according to the customer SLA, one 275 possible solution is to measure the SLA related performance 276 parameters, and dynamically provision and optimize services based 277 on the performance monitoring results. 279 * Performance monitoring in a large scale network could generate a 280 huge amount of performance information. Therefore, the 281 appropriate way to deliver the information at the client and 282 network interfaces should be carefully considered. 284 3. Design of the Data Models 286 This document describes two YANG models: 288 (i) TE Telemetry Model which provides the TE-Tunnel level of 290 performance monitoring mechanism and scaling intent mechanism 291 that allows scale in/out programming by the customer. (See 292 Section 3.1 & Section 7.1 for details). 294 (ii) VN Telemetry Model which provides the VN level of the 296 aggregated performance monitoring mechanism and scaling intent 297 mechanism that allows scale in/out programming by the customer 298 (See Section 3.2 & Section 7.2 for details). 300 3.1. TE Telemetry Model 302 This model describes the performance telemetry for the TE tunnel. 303 The telemetry data is augmented to the TE tunnel. This model also 304 allows autonomic traffic engineering scaling intent configuration 305 mechanism on the TE-tunnel level. Various conditions can be set for 306 auto-scaling based on the telemetry data (See Section 5 for details) 307 As shown in Figure 2, the TE Telemetry Model augments the TE-Tunnel 308 Model to enhance TE performance monitoring capability. This 309 monitoring capability will facilitate re-optimization and 310 reconfiguration of TE tunnels based on the performance monitoring 311 data collected via the TE Telemetry YANG model. 313 +------------+ +--------------+ 314 | TE-Tunnel | | TE | 315 | Model |<---------| Telemetry | 316 +------------+ augments | Model | 317 +--------------+ 319 Figure 2: TE Telemetry Model Relationship 321 3.2. VN Telemetry Model 323 As shown in Figure 3, the VN Telemetry Model augments the basic VN 324 model to enhance VN monitoring capability. This monitoring 325 capability will facilitate re-optimization and reconfiguration of VNs 326 based on the performance monitoring data collected via the VN 327 Telemetry YANG model. This model also imports TE telemetry model to 328 reuse the groupings. 330 +----------+ +--------------+ 331 | VN | augments | VN | 332 | Model |<---------| Telemetry | 333 +----------+ | Model | 334 +--------------+ 335 | 336 | imports 337 v 338 +--------------+ 339 | TE | 340 | Telemetry | 341 | Model | 342 +--------------+ 344 Figure 3: VN Telemetry Model Relationships 346 This model describes the performance telemetry for the VN model. The 347 telemetry data is augmented to the VN model at the VN Level as well 348 as at the individual VN member level. This model also allows 349 autonomic traffic engineering scaling intent configuration mechanism 350 on the VN level. Scale in/out criteria might be used for network 351 autonomics in order for the controller to react to a certain set of 352 variations in monitored parameters (See Section 4 for illustrations). 354 Moreover, this model also provides a mechanism to define aggregated 355 VN telemetry parameters as a grouping of underlying VN-member level 356 telemetry parameters. This is unique to the VN model as a VN is made 357 up of multiple VN-members and further each VN-member could be set 358 across multiple TE tunnels. Grouping operation (such as maximum, 359 mean) could be set at the time of configuration. For example, if 360 "maximum" grouping operation is used for delay at the VN level, the 361 VN telemetry data is reported as the maximum of {delay_vn_member_1, 362 delay_vn_member_2,.. delay_vn_member_N}. Thus, this telemetry 363 aggregation mechanism allows the aggregation (or grouping) of a 364 certain common set of telemetry values under a grouping operation. 365 This can also be done at the VN-member level to suggest how the end- 366 to-end (E2E) telemetry be inferred from the per domain tunnels 367 created and monitored by PNCs. The Figure 4 provides an example 368 interaction. 370 +------------------------------------------------------------+ 371 | Client | 372 | | 373 +------------------------------------------------------------+ 374 1.Client sets the | /|\ 2. Orchestrator pushes: 375 grouping op, and | | 376 subscribes to the | | VN level telemetry for 377 VN level telemetry for | | - VN Utilized-bw-percentage 378 Delay and | | (Minimum across VN Members) 379 Utilized-bw-pecentage | | - VN Delay (Maximum across VN 380 \|/ | Members) 381 +------------------------------------------------------------+ 382 | Orchestrator | 383 | | 384 +------------------------------------------------------------+ 386 Figure 4: TE Telemetry Model Interactions 388 3.3. VPN Service Performance Monitoring 390 The YANG model in [I-D.ietf-opsawg-yang-vpn-service-pm] provides 391 network performance monitoring (PM) and VPN service performance 392 monitoring that can be used to monitor and manage network performance 393 on the topology at higher layer or the service topology between VPN 394 sites. Thus the YANG models in this document could be used along 395 side with ietf-network-vpn-pm to understand and correlate the 396 performance monitoring at the VPN service and the underlying TE 397 level. 399 4. Autonomic Scaling Intent Mechanism 401 The scaling intent configuration mechanism allows the client to 402 configure automatic scale-in and scale-out mechanisms on both the TE- 403 tunnel and the VN level. Various conditions can be set for auto- 404 scaling based on the PM telemetry data. 406 There are a number of parameters involved in the mechanism: 408 * scale-out-intent or scale-in-intent: whether to scale-out or 409 scale-in. 411 * performance-type: performance metric type (e.g., one-way-delay, 412 one-way-delay-min, one-way-delay-max, two-way-delay, two-way- 413 delay-min, two-way-delay-max, utilized bandwidth, etc.) 415 * threshold-value: the threshold value for a certain performance- 416 type that triggers scale-in or scale-out. 418 * scaling-operation-type: in case where scaling condition can be set 419 with one or more performance types, then scaling-operation-type 420 (AND, OR, MIN, MAX, etc.) is applied to these selected performance 421 types and its threshold values. 423 * Threshold-time: the duration for which the criteria needs to hold 424 true. 426 * Cooldown-time: the duration after a scaling action has been 427 triggered, for which there will be no further operation. 429 The tree in Figure 5 is a part of ietf-te-telemetry tree whose model 430 is presented in full detail in Sections 6 & 7. 432 module: ietf-te-telemetry 433 augment /te:te/te:tunnels/te:tunnel: 434 +--rw te-scaling-intent 435 | +--rw scale-in-intent 436 | | +--rw threshold-time? uint32 437 | | +--rw cooldown-time? uint32 438 | | +--rw scaling-condition* [performance-type] 439 | | | +--rw performance-type identityref 440 | | | +--rw threshold-value? string 441 | | | +--rw scale-in-operation-type? 442 | | | scaling-criteria-operation 443 | | +--rw scale-in-op? identityref 444 | | +--rw scale? string 445 | +--rw scale-out-intent 446 | +--rw threshold-time? uint32 447 | +--rw cooldown-time? uint32 448 | +--rw scaling-condition* [performance-type] 449 | | +--rw performance-type identityref 450 | | +--rw threshold-value? string 451 | | +--rw scale-out-operation-type? 452 | | scaling-criteria-operation 453 | +--rw scale-out-op? identityref 454 | +--rw scale? string 456 Figure 5: The scaling intent 458 Let's say the client wants to set the scaling out operation based on 459 two performance-types (e.g., two-way-delay and utilized-bandwidth for 460 a te-tunnel), it can be done as follows: 462 * Set Threshold-time: x (sec) (duration for which the criteria must 463 hold true) 465 * Set Cooldown-time: y (sec) (the duration after a scaling action 466 has been triggered, for which there will be no further operation) 468 * Set AND for the scale-out-operation-type 470 In the scaling condition's list, the following two components can be 471 set: 473 List 1: Scaling Condition for Two-way-delay 475 * performance type: Two-way-delay 477 * threshold-value: z milli-seconds 479 List 2: Scaling Condition for Utilized bandwidth 480 * performance type: Utilized bandwidth 482 * threshold-value: w megabytes 484 5. Notification 486 This model does not define specific notifications. To enable 487 notifications, the mechanism defined in [RFC8641] and [RFC8640] can 488 be used. This mechanism currently allows the user to: 490 * Subscribe to notifications on a per client basis. 492 * Specify subtree filters or xpath filters so that only interested 493 contents will be sent. 495 * Specify either periodic or on-demand notifications. 497 5.1. YANG Push Subscription Examples 499 [RFC8641] allows subscriber applications to request a continuous, 500 customized stream of updates from a YANG datastore. 502 The example in Figure 6 shows the way for a client to subscribe to 503 the telemetry information for a particular tunnel (Tunnel1). The 504 telemetry parameter that the client is interested in is one-way- 505 delay. 507 509 511 512 513 514 515 Tunnel1 516 518 519 520 521 522 523 524 525 526 500 527 encode-xml 528 529 531 Figure 6: TE Tunnel Subscription Example 533 The example in Figure 7 shows the way for a client to subscribe to 534 the telemetry information for all VNs. The telemetry parameter that 535 the client is interested in is one-way-delay and one-way-utilized- 536 bandwidth. 538 540 542 543 544 545 546 548 549 550 551 552 553 554 555 556 557 558 500 559 560 562 Figure 7: VN Subscription Example 564 5.2. Scaling Examples 566 The example in Figure 8 shows the way to configure a TE tunnel with 567 the scaling-out intent to re-optimize when the the scaling condition 568 of two-way-delay crossing 100 milliseconds (100000 microseconds) for 569 a threshold of 1 min (60000 milliseconds). 571 572 573 574 575 576 577 578 579 Tunnel1 580 583 584 585 60000 586 587 588 589 two-way-delay 590 591 592 100000 593 594 595 re-optimize 596 597 598 599 600 601 602 603 604 606 Figure 8: TE Tunnel Scaling Example 608 The example in Figure 9 shows the way to configure a VN with the 609 scaling-in intent to reduce bandwidth when the the scaling condition 610 of two-way-delay crossing 100 milliseconds (100000 microseconds) for 611 a threshold of 1 min (60000 milliseconds). 613 614 615 616 617 618 619 620 VN1 621 624 625 60000 626 627 628 utilized-percentage 629 630 631 50 632 633 634 scale-capacity-down 635 636 637 638 639 640 641 642 644 Figure 9: VN Scaling Example 646 The example in Figure 10 shows the way to configure a grouping 647 operation at the VN level to require that the VN level one-way-delay 648 needs to be the reported as the max of the one-way-delay at the VN- 649 member level, where as the utilized-percentage is the mean. 651 652 653 654 655 656 657 658 VN1 659 662 663 664 one-way-delay 665 666 667 maximum 668 669 670 671 672 utilized-percentage 673 674 675 mean 676 677 678 679 680 681 682 684 Figure 10: VN Grouping Operation Example 686 6. YANG Data Tree 687 module: ietf-te-telemetry 688 augment /te:te/te:tunnels/te:tunnel: 689 +--rw te-scaling-intent 690 | +--rw scale-in-intent 691 | | +--rw threshold-time? uint32 692 | | +--rw cooldown-time? uint32 693 | | +--rw scaling-condition* [performance-type] 694 | | | +--rw performance-type identityref 695 | | | +--rw threshold-value? string 696 | | | +--rw scale-in-operation-type? 697 | | | scaling-criteria-operation 698 | | +--rw scale-in-op? identityref 699 | | +--rw scale? string 700 | +--rw scale-out-intent 701 | +--rw threshold-time? uint32 702 | +--rw cooldown-time? uint32 703 | +--rw scaling-condition* [performance-type] 704 | | +--rw performance-type identityref 705 | | +--rw threshold-value? string 706 | | +--rw scale-out-operation-type? 707 | | scaling-criteria-operation 708 | +--rw scale-out-op? identityref 709 | +--rw scale? string 710 +--ro te-telemetry 711 +--ro id? telemetry-id 712 +--ro performance-metrics-one-way 713 | +--ro one-way-delay? uint32 714 | +--ro one-way-delay-normality? 715 | | te-types:performance-metrics-normality 716 | +--ro one-way-residual-bandwidth? 717 | | rt-types:bandwidth-ieee-float32 718 | +--ro one-way-residual-bandwidth-normality? 719 | | te-types:performance-metrics-normality 720 | +--ro one-way-available-bandwidth? 721 | | rt-types:bandwidth-ieee-float32 722 | +--ro one-way-available-bandwidth-normality? 723 | | te-types:performance-metrics-normality 724 | +--ro one-way-utilized-bandwidth? 725 | | rt-types:bandwidth-ieee-float32 726 | +--ro one-way-utilized-bandwidth-normality? 727 | te-types:performance-metrics-normality 728 +--ro performance-metrics-two-way 729 +--ro two-way-delay? uint32 730 +--ro two-way-delay-normality? 731 te-types:performance-metrics-normality 733 Figure 11: ietf-te-telemetry YANG model tree 735 module: ietf-vn-telemetry 736 augment /vn:virtual-network/vn:vn: 737 +--rw vn-scaling-intent 738 | +--rw scale-in-intent 739 | | +--rw threshold-time? uint32 740 | | +--rw cooldown-time? uint32 741 | | +--rw scaling-condition* [performance-type] 742 | | | +--rw performance-type identityref 743 | | | +--rw threshold-value? string 744 | | | +--rw scale-in-operation-type? 745 | | | scaling-criteria-operation 746 | | +--rw scale-in-op? identityref 747 | | +--rw scale? string 748 | +--rw scale-out-intent 749 | +--rw threshold-time? uint32 750 | +--rw cooldown-time? uint32 751 | +--rw scaling-condition* [performance-type] 752 | | +--rw performance-type identityref 753 | | +--rw threshold-value? string 754 | | +--rw scale-out-operation-type? 755 | | scaling-criteria-operation 756 | +--rw scale-out-op? identityref 757 | +--rw scale? string 758 +--rw vn-telemetry 759 +--ro params 760 | +--ro performance-metrics-one-way 761 | | +--ro one-way-delay? uint32 762 | | +--ro one-way-delay-normality? 763 | | | te-types:performance-metrics-normality 764 | | +--ro one-way-residual-bandwidth? 765 | | | rt-types:bandwidth-ieee-float32 766 | | +--ro one-way-residual-bandwidth-normality? 767 | | | te-types:performance-metrics-normality 768 | | +--ro one-way-available-bandwidth? 769 | | | rt-types:bandwidth-ieee-float32 770 | | +--ro one-way-available-bandwidth-normality? 771 | | | te-types:performance-metrics-normality 772 | | +--ro one-way-utilized-bandwidth? 773 | | | rt-types:bandwidth-ieee-float32 774 | | +--ro one-way-utilized-bandwidth-normality? 775 | | te-types:performance-metrics-normality 776 | +--ro performance-metrics-two-way 777 | +--ro two-way-delay? uint32 778 | +--ro two-way-delay-normality? 779 | te-types:performance-metrics-normality 780 +--rw operation* [performance-type] 781 +--rw performance-type identityref 782 +--rw grouping-operation? identityref 784 augment /vn:virtual-network/vn:vn/vn:vn-member: 785 +--rw vn-member-telemetry 786 +--ro params 787 | +--ro performance-metrics-one-way 788 | | +--ro one-way-delay? uint32 789 | | +--ro one-way-delay-normality? 790 | | | te-types:performance-metrics-normality 791 | | +--ro one-way-residual-bandwidth? 792 | | | rt-types:bandwidth-ieee-float32 793 | | +--ro one-way-residual-bandwidth-normality? 794 | | | te-types:performance-metrics-normality 795 | | +--ro one-way-available-bandwidth? 796 | | | rt-types:bandwidth-ieee-float32 797 | | +--ro one-way-available-bandwidth-normality? 798 | | | te-types:performance-metrics-normality 799 | | +--ro one-way-utilized-bandwidth? 800 | | | rt-types:bandwidth-ieee-float32 801 | | +--ro one-way-utilized-bandwidth-normality? 802 | | te-types:performance-metrics-normality 803 | +--ro performance-metrics-two-way 804 | | +--ro two-way-delay? uint32 805 | | +--ro two-way-delay-normality? 806 | | te-types:performance-metrics-normality 807 | +--ro te-grouped-params* 808 | -> /te:te/tunnels/tunnel/te-tel:te-telemetry/id 809 +--rw operation* [performance-type] 810 +--rw performance-type identityref 811 +--rw grouping-operation? identityref 813 Figure 12: ietf-vn-telemetry YANG model tree 815 7. YANG Data Model 817 7.1. ietf-te-telemetry model 819 The YANG code is as follows: 821 file "ietf-te-telemetry@2022-03-07.yang" 822 module ietf-te-telemetry { 823 yang-version 1.1; 824 namespace "urn:ietf:params:xml:ns:yang:ietf-te-telemetry"; 825 prefix te-tel; 827 /* Import TE */ 829 import ietf-te { 830 prefix te; 831 reference 832 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 833 Engineering Tunnels and Interfaces"; 834 } 836 /* Import TE Common types */ 838 import ietf-te-types { 839 prefix te-types; 840 reference 841 "RFC 8776: Common YANG Data Types for Traffic Engineering"; 842 } 844 organization 845 "IETF Traffic Engineering Architecture and Signaling (TEAS) 846 Working Group"; 847 contact 848 "WG Web: 849 WG List: 850 Editor: Young Lee 851 Dhruv Dhody "; 852 description 853 "This module describes YANG data model for performance 854 monitoring telemetry for te tunnels. 856 Copyright (c) 2022 IETF Trust and the persons identified as 857 authors of the code. All rights reserved. 859 Redistribution and use in source and binary forms, with or 860 without modification, is permitted pursuant to, and subject to 861 the license terms contained in, the Revised BSD License set 862 forth in Section 4.c of the IETF Trust's Legal Provisions 863 Relating to IETF Documents 864 (https://trustee.ietf.org/license-info). 866 This version of this YANG module is part of RFC XXXX; see the 867 RFC itself for full legal notices."; 869 /* Note: The RFC Editor will replace XXXX with the number 870 assigned to the RFC once draft-ietf-teas-pm-telemetry- 871 autonomics becomes an RFC.*/ 873 revision 2022-03-07 { 874 description 875 "Initial revision."; 876 reference 877 "RFC XXXX: YANG models for VN/TE Performance Monitoring 878 Telemetry and Scaling Intent Autonomics"; 879 } 880 identity telemetry-param-type { 881 description 882 "Base identity for telemetry param types"; 883 } 885 identity one-way-delay { 886 base telemetry-param-type; 887 description 888 "To specify average Delay in one (forward) direction. 890 At the VN level, it is the max delay of the VN-members. 892 The threshold-value for this type is interpreted as 893 microseconds."; 894 reference 895 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions. 896 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions. 897 RFC 7823: Performance-Based Path Selection for Explicitly 898 Routed Label Switched Paths (LSPs) Using TE Metric 899 Extensions"; 900 } 902 identity two-way-delay { 903 base telemetry-param-type; 904 description 905 "To specify average Delay in both (forward and reverse) 906 directions. 908 At the VN level, it is the max delay of the VN-members. 910 The threshold-value for this type is interpreted as 911 microseconds."; 912 reference 913 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions. 914 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions. 915 RFC 7823: Performance-Based Path Selection for Explicitly 916 Routed Label Switched Paths (LSPs) Using TE Metric 917 Extensions"; 918 } 920 identity one-way-delay-variation { 921 base telemetry-param-type; 922 description 923 "To specify average Delay Variation in one (forward) direction. 925 At the VN level, it is the max delay variation of the 926 VN-members. 928 The threshold-value for this type is interpreted as 929 microseconds."; 930 reference 931 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions. 932 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions. 933 RFC 7823: Performance-Based Path Selection for Explicitly 934 Routed Label Switched Paths (LSPs) Using TE Metric 935 Extensions"; 936 } 938 identity two-way-delay-variation { 939 base telemetry-param-type; 940 description 941 "To specify average Delay Variation in both (forward and 942 reverse) directions. 944 At the VN level, it is the max delay variation of the 945 VN-members. 947 The threshold-value for this type is interpreted as 948 microseconds."; 949 reference 950 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions. 951 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions. 952 RFC 7823: Performance-Based Path Selection for Explicitly 953 Routed Label Switched Paths (LSPs) Using TE Metric 954 Extensions"; 955 } 957 identity utilized-bandwidth { 958 base telemetry-param-type; 959 description 960 "To specify utilized bandwidth over the specified source 961 and destination. 963 The threshold-value for this type is interpreted as 964 bytes per second."; 965 reference 966 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions. 967 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions. 968 RFC 7823: Performance-Based Path Selection for Explicitly 969 Routed Label Switched Paths (LSPs) Using TE Metric 970 Extensions"; 971 } 973 identity utilized-percentage { 974 base telemetry-param-type; 975 description 976 "To specify utilization percentage of the entity 977 (e.g., tunnel, link, etc.)"; 978 } 980 identity scale-op { 981 description 982 "Base identity for scaling operation"; 983 } 985 identity scale-capacity-up { 986 base scale-op; 987 description 988 "Scale up the bandwidth capacity"; 989 } 991 identity scale-capacity-down { 992 base scale-op; 993 description 994 "Scale down the bandwidth capacity"; 995 } 997 /* Typedef */ 999 typedef telemetry-id { 1000 type string; 1001 description 1002 "Identifier for the telemetry data."; 1003 } 1005 typedef scaling-criteria-operation { 1006 type enumeration { 1007 enum AND { 1008 description 1009 "AND operation"; 1010 } 1011 enum OR { 1012 description 1013 "OR operation"; 1014 } 1015 } 1016 description 1017 "Operations to analize list of scaling criterias"; 1018 } 1020 grouping scaling-duration { 1021 description 1022 "Base scaling criteria durations"; 1023 leaf threshold-time { 1024 type uint32; 1025 units "seconds"; 1026 description 1027 "The duration for which the criteria must hold true"; 1028 } 1029 leaf cooldown-time { 1030 type uint32; 1031 units "seconds"; 1032 description 1033 "The duration after a scaling-in/scaling-out action has been 1034 triggered, for which there will be no further operation"; 1035 } 1036 } 1038 grouping scaling-criteria { 1039 description 1040 "Grouping for scaling criteria"; 1041 leaf performance-type { 1042 type identityref { 1043 base telemetry-param-type; 1044 } 1045 description 1046 "Reference to the tunnel level telemetry type"; 1047 } 1048 leaf threshold-value { 1049 type string; 1050 description 1051 "Scaling threshold for the telemetry parameter type."; 1052 } 1053 } 1055 grouping scaling-in-intent { 1056 description 1057 "Basic scaling in intent"; 1058 uses scaling-duration; 1059 list scaling-condition { 1060 key "performance-type"; 1061 description 1062 "Scaling conditions"; 1063 uses scaling-criteria; 1064 leaf scale-in-operation-type { 1065 type scaling-criteria-operation; 1066 default "AND"; 1067 description 1068 "Operation to be applied to check between scaling criterias 1069 to check if the scale in threshold condition has been met. 1070 Defaults to AND"; 1071 } 1073 } 1074 leaf scale-in-op { 1075 type identityref { 1076 base scale-op; 1077 } 1078 default "scale-capacity-down"; 1079 description 1080 "The scaling operation to be performed when scaling condition 1081 is met"; 1082 } 1083 leaf scale { 1084 type string; 1085 description 1086 "Additional scaling-by information to be interpritted as per 1087 the scale-in-op."; 1088 } 1089 } 1091 grouping scaling-out-intent { 1092 description 1093 "Basic scaling out intent"; 1094 uses scaling-duration; 1095 list scaling-condition { 1096 key "performance-type"; 1097 description 1098 "Scaling conditions"; 1099 uses scaling-criteria; 1100 leaf scale-out-operation-type { 1101 type scaling-criteria-operation; 1102 default "OR"; 1103 description 1104 "Operation to be applied to check between scaling criterias 1105 to check if the scale out threshold condition has been met. 1106 Defauls to OR"; 1107 } 1108 } 1109 leaf scale-out-op { 1110 type identityref { 1111 base scale-op; 1112 } 1113 default "scale-capacity-up"; 1114 description 1115 "The scaling operation to be performed when scaling condition 1116 is met"; 1117 } 1118 leaf scale { 1119 type string; 1120 description 1121 "Additional scaling-by information to be interpritted as per 1122 the scale-out-op."; 1123 } 1124 } 1126 augment "/te:te/te:tunnels/te:tunnel" { 1127 description 1128 "Augmentation parameters for config scaling-criteria TE 1129 tunnel topologies. Scale in/out criteria might be used 1130 for network autonomics in order the controller to react 1131 to a certain set of monitored params."; 1132 container te-scaling-intent { 1133 description 1134 "The scaling intent"; 1135 container scale-in-intent { 1136 description 1137 "scale-in"; 1138 uses scaling-in-intent; 1139 } 1140 container scale-out-intent { 1141 description 1142 "scale-out"; 1143 uses scaling-out-intent; 1144 } 1145 } 1146 container te-telemetry { 1147 config false; 1148 description 1149 "Telemetry Data"; 1150 leaf id { 1151 type telemetry-id; 1152 description 1153 "ID of telemetry data used for easy reference"; 1154 } 1155 uses te-types:performance-metrics-attributes; 1156 } 1157 } 1158 } 1159 1161 7.2. ietf-vn-telemetry model 1163 The YANG code is as follows: 1165 file "ietf-vn-telemetry@2022-03-07.yang" 1166 module ietf-vn-telemetry { 1167 yang-version 1.1; 1168 namespace "urn:ietf:params:xml:ns:yang:ietf-vn-telemetry"; 1169 prefix vn-tel; 1171 /* Import VN */ 1173 import ietf-vn { 1174 prefix vn; 1175 reference 1176 "I-D.ietf-teas-actn-vn-yang: A YANG Data Model for VN 1177 Operation"; 1178 } 1180 /* Import TE */ 1182 import ietf-te { 1183 prefix te; 1184 reference 1185 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic 1186 Engineering Tunnels and Interfaces"; 1187 } 1189 /* Import TE Common types */ 1191 import ietf-te-types { 1192 prefix te-types; 1193 reference 1194 "RFC 8776: Common YANG Data Types for Traffic Engineering"; 1195 } 1197 /* Import TE Telemetry */ 1199 import ietf-te-telemetry { 1200 prefix te-tel; 1201 reference 1202 "RFC XXXX: YANG models for VN/TE Performance Monitoring 1203 Telemetry and Scaling Intent Autonomics"; 1204 } 1206 /* Note: The RFC Editor will replace XXXX with the number 1207 assigned to this draft.*/ 1209 organization 1210 "IETF Traffic Engineering Architecture and Signaling (TEAS) 1211 Working Group"; 1212 contact 1213 "WG Web: 1214 WG List: 1215 Editor: Young Lee 1216 Dhruv Dhody "; 1217 description 1218 "This module describes YANG data models for performance 1219 monitoring telemetry for Virtual Network (VN). 1221 Copyright (c) 2022 IETF Trust and the persons identified as 1222 authors of the code. All rights reserved. 1224 Redistribution and use in source and binary forms, with or 1225 without modification, is permitted pursuant to, and subject to 1226 the license terms contained in, the Revised BSD License set 1227 forth in Section 4.c of the IETF Trust's Legal Provisions 1228 Relating to IETF Documents 1229 (https://trustee.ietf.org/license-info). 1231 This version of this YANG module is part of RFC XXXX; see the 1232 RFC itself for full legal notices."; 1234 /* Note: The RFC Editor will replace XXXX with the number 1235 assigned to the RFC once draft-lee-teas-pm-telemetry- 1236 autonomics becomes an RFC.*/ 1238 revision 2022-03-07 { 1239 description 1240 "Initial revision."; 1241 reference 1242 "RFC XXXX: YANG models for VN/TE Performance Monitoring 1243 Telemetry and Scaling Intent Autonomics"; 1244 } 1246 identity grouping-op { 1247 description 1248 "Base identity for grouping-operation"; 1249 } 1251 identity minimum { 1252 base grouping-op; 1253 description 1254 "Select the minimum of the monitored parameters"; 1255 } 1257 identity maximum { 1258 base grouping-op; 1259 description 1260 "The maximum of the monitored parameters"; 1262 } 1264 identity mean { 1265 base grouping-op; 1266 description 1267 "The mean of the monitored parameters"; 1268 } 1270 identity standard-deviation { 1271 base grouping-op; 1272 description 1273 "The standard deviation of the monitored parameters"; 1274 } 1276 identity sum { 1277 base grouping-op; 1278 description 1279 "The sum of the monitored parameters"; 1280 } 1282 identity and { 1283 base grouping-op; 1284 description 1285 "Logical AND operation"; 1286 } 1288 identity or { 1289 base grouping-op; 1290 description 1291 "Logical OR operation"; 1292 } 1294 grouping grouping-operation { 1295 list operation { 1296 key "performance-type"; 1297 leaf performance-type { 1298 type identityref { 1299 base te-tel:telemetry-param-type; 1300 } 1301 description 1302 "Reference to the tunnel level telemetry type"; 1303 } 1304 leaf grouping-operation { 1305 type identityref { 1306 base grouping-op; 1307 } 1308 description 1309 "describes the operation to apply to the te-grouped-params"; 1311 } 1312 description 1313 "Grouping operation for each performance-type"; 1314 } 1315 description 1316 "Grouping operation for each performance-type"; 1317 } 1319 augment "/vn:virtual-network/vn:vn" { 1320 description 1321 "Augmentation parameters for state TE VN topologies."; 1322 container vn-scaling-intent { 1323 description 1324 "scaling intent"; 1325 container scale-in-intent { 1326 description 1327 "VN scale-in"; 1328 uses te-tel:scaling-in-intent; 1329 } 1330 container scale-out-intent { 1331 description 1332 "VN scale-out"; 1333 uses te-tel:scaling-out-intent; 1334 } 1335 } 1336 container vn-telemetry { 1337 description 1338 "VN telemetry params"; 1339 container params { 1340 config false; 1341 description 1342 "Read-only telemetry parameters"; 1343 uses te-types:performance-metrics-attributes; 1344 } 1345 uses grouping-operation; 1346 } 1347 } 1349 augment "/vn:virtual-network/vn:vn/vn:vn-member" { 1350 description 1351 "Augmentation parameters for state TE vn member topologies."; 1352 container vn-member-telemetry { 1353 description 1354 "VN member telemetry params"; 1355 container params { 1356 config false; 1357 description 1358 "Read-only telemetry parameters"; 1360 uses te-types:performance-metrics-attributes; 1361 leaf-list te-grouped-params { 1362 type leafref { 1363 path "/te:te/te:tunnels/te:tunnel/" 1364 + "te-tel:te-telemetry/te-tel:id"; 1365 } 1366 description 1367 "A list of underlying TE parameters that form the 1368 VN-member"; 1369 } 1370 } 1371 uses grouping-operation; 1372 } 1373 } 1374 } 1375 1377 8. Security Considerations 1379 The YANG modules specified in this document defines a schema for data 1380 that is designed to be accessed via network management protocols such 1381 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1382 is the secure transport layer, and the mandatory-to-implement secure 1383 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1384 is HTTPS, and the mandatory-to-implement secure transport is TLS 1385 [RFC8446]. 1387 The Network Configuration Access Control Model (NACM) [RFC8341] 1388 provides the means to restrict access for particular NETCONF or 1389 RESTCONF users to a preconfigured subset of all available NETCONF or 1390 RESTCONF protocol operations and content. 1392 There are a number of data nodes defined in this YANG module that are 1393 writable/creatable/deletable (i.e., config true, which is the 1394 default). These data nodes may be considered sensitive or vulnerable 1395 in some network environments. Write operations (e.g., edit-config) 1396 to these data nodes without proper protection can have a negative 1397 effect on network operations. These are the subtrees with the write 1398 operation that can be exploited to impact the network monitoring. An 1399 incorrect condition could cause frequent scaling operation to be 1400 executed causing harm to the network: 1402 * /te:te/te:tunnels/te:tunnel/te-scaling-intent/scale-in-intent 1404 * /te:te/te:tunnels/te:tunnel/te-scaling-intent/scale-out-intent 1406 * /vn:virtual-network/vn:vn/vn-scaling-intent/scale-in-intent 1407 * /vn:virtual-network/vn:vn/vn-scaling-intent/scale-out-intent 1409 Further, following are the subtrees with the write operation that can 1410 be exploited by setting an incorrect grouping operation for the VN 1411 operation impacting the network monitoring: 1413 * /vn:virtual-network/vn:vn/vn-telemetry/operation 1415 * /vn:virtual-network/vn:vn/vn:vn-member/vn-member-telemetry/ 1416 operation 1418 Some of the readable data nodes in this YANG module may be considered 1419 sensitive or vulnerable in some network environments. It is thus 1420 important to control read access (e.g., via get, get-config, or 1421 notification) to these data nodes. These are the subtrees with the 1422 read operations that can be exploited to learn real-time (and 1423 sensitive) telemetry information about the TE tunnels and VN: 1425 * /te:te/te:tunnels/te:tunnel/te-telemetry 1427 * /vn:virtual-network/vn:vn/vn-telemetry 1429 * /vn:virtual-network/vn:vn/vn:vn-member/vn-member-telemetry 1431 9. IANA Considerations 1433 This document registers the following namespace URIs in the IETF XML 1434 registry [RFC3688]: 1436 -------------------------------------------------------------------- 1437 URI: urn:ietf:params:xml:ns:yang:ietf-te-telemetry 1438 Registrant Contact: The IESG. 1439 XML: N/A, the requested URI is an XML namespace. 1440 -------------------------------------------------------------------- 1442 -------------------------------------------------------------------- 1443 URI: urn:ietf:params:xml:ns:yang:ietf-vn-telemetry 1444 Registrant Contact: The IESG. 1445 XML: N/A, the requested URI is an XML namespace. 1446 -------------------------------------------------------------------- 1448 This document registers the following YANG modules in the YANG Module 1449 registry. 1451 Names registry [RFC7950]: 1453 -------------------------------------------------------------------- 1454 name: ietf-te-telemetry 1455 namespace: urn:ietf:params:xml:ns:yang:ietf-te-telemetry 1456 prefix: te-tel 1457 reference: RFC XXXX 1458 -------------------------------------------------------------------- 1460 -------------------------------------------------------------------- 1461 name: ietf-vn-telemetry 1462 namespace: urn:ietf:params:xml:ns:yang:ietf-vn-telemetry 1463 prefix: vn-tel 1464 reference: RFC XXXX 1465 -------------------------------------------------------------------- 1467 10. Acknowledgements 1469 We thank Adrian Farrel, Rakesh Gandhi, Tarek Saad, Igor Bryskin, 1470 Kenichi Ogaki, and Greg Mirsky for useful discussions and their 1471 suggestions for this work. 1473 11. References 1475 11.1. Normative References 1477 [I-D.ietf-teas-actn-vn-yang] 1478 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. Y. 1479 Yoon, "A YANG Data Model for VN Operation", Work in 1480 Progress, Internet-Draft, draft-ietf-teas-actn-vn-yang-14, 1481 7 March 2022, . 1484 [I-D.ietf-teas-yang-te] 1485 Saad, T., Gandhi, R., Liu, X., Beeram, V. P., Bryskin, I., 1486 and O. G. D. Dios, "A YANG Data Model for Traffic 1487 Engineering Tunnels, Label Switched Paths and Interfaces", 1488 Work in Progress, Internet-Draft, draft-ietf-teas-yang-te- 1489 29, 7 February 2022, 1490 . 1493 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1494 DOI 10.17487/RFC3688, January 2004, 1495 . 1497 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1498 and A. Bierman, Ed., "Network Configuration Protocol 1499 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1500 . 1502 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1503 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1504 . 1506 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 1507 Ceccarelli, D., and X. Zhang, "Problem Statement and 1508 Architecture for Information Exchange between 1509 Interconnected Traffic-Engineered Networks", BCP 206, 1510 RFC 7926, DOI 10.17487/RFC7926, July 2016, 1511 . 1513 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1514 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1515 . 1517 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1518 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1519 . 1521 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, 1522 "Extensions to the Path Computation Element Communication 1523 Protocol (PCEP) to Compute Service-Aware Label Switched 1524 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 1525 2017, . 1527 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1528 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1529 . 1531 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1532 Access Control Model", STD 91, RFC 8341, 1533 DOI 10.17487/RFC8341, March 2018, 1534 . 1536 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1537 and R. Wilton, "Network Management Datastore Architecture 1538 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1539 . 1541 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1542 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1543 . 1545 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1546 E., and A. Tripathy, "Dynamic Subscription to YANG Events 1547 and Datastores over NETCONF", RFC 8640, 1548 DOI 10.17487/RFC8640, September 2019, 1549 . 1551 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1552 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1553 September 2019, . 1555 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 1556 "Common YANG Data Types for Traffic Engineering", 1557 RFC 8776, DOI 10.17487/RFC8776, June 2020, 1558 . 1560 11.2. Informative References 1562 [I-D.ietf-opsawg-yang-vpn-service-pm] 1563 Wu, B., Wu, Q., Boucadair, M., Dios, O. G. D., and B. Wen, 1564 "A YANG Model for Network and VPN Service Performance 1565 Monitoring", Work in Progress, Internet-Draft, draft-ietf- 1566 opsawg-yang-vpn-service-pm-03, 29 January 2022, 1567 . 1570 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1571 Previdi, "OSPF Traffic Engineering (TE) Metric 1572 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1573 . 1575 [RFC7823] Atlas, A., Drake, J., Giacalone, S., and S. Previdi, 1576 "Performance-Based Path Selection for Explicitly Routed 1577 Label Switched Paths (LSPs) Using TE Metric Extensions", 1578 RFC 7823, DOI 10.17487/RFC7823, May 2016, 1579 . 1581 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1582 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1583 . 1585 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1586 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1587 DOI 10.17487/RFC8453, August 2018, 1588 . 1590 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 1591 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 1592 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 1593 2019, . 1595 Appendix A. Out of Scope 1597 This document exclusively focus on performance monitoring telemetry 1598 and scaling intent mechanisms of the underlying transport (TE-tunnels 1599 and Virtual Networks (VNs)). The performance monitoring of the 1600 services is out of scope. See Section 3.3 for details about VPN 1601 performance monitoring. Similarly performance monitoring of IETF 1602 network slices could be developed and it is clearly out of scope of 1603 this document. 1605 Authors' Addresses 1607 Young Lee (editor) 1608 Samsung Electronics 1609 Email: younglee.tx@gmail.com 1611 Dhruv Dhody (editor) 1612 Huawei Technologies 1613 Divyashree Techno Park, Whitefield 1614 Bangalore 560066 1615 Karnataka 1616 India 1617 Email: dhruv.ietf@gmail.com 1619 Satish Karunanithi 1620 Huawei Technologies 1621 Divyashree Techno Park, Whitefield 1622 Bangalore 560066 1623 Karnataka 1624 India 1625 Email: satish.karunanithi@gmail.com 1627 Ricard Vilalta 1628 CTTC 1629 Centre Tecnologic de Telecomunicacions de Catalunya (CTTC/CERCA) 1630 Barcelona 1631 Spain 1632 Email: ricard.vilalta@cttc.es 1634 Daniel King 1635 Lancaster University 1636 Email: d.king@lancaster.ac.uk 1637 Daniele Ceccarelli 1638 Ericsson 1639 Torshamnsgatan,48 1640 Stockholm, Sweden 1641 Email: daniele.ceccarelli@ericsson.com