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