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