idnits 2.17.1
draft-ietf-teas-actn-pm-telemetry-autonomics-05.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (February 19, 2021) is 1161 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 205, but not defined
== Outdated reference: A later version (-24) exists of
draft-ietf-teas-actn-vn-yang-10
== Outdated reference: A later version (-36) exists of
draft-ietf-teas-yang-te-25
Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 TEAS Working Group Y. Lee, Ed.
3 Internet-Draft Samsung Electronics
4 Intended status: Standards Track D. Dhody, Ed.
5 Expires: August 23, 2021 S. Karunanithi
6 Huawei Technologies
7 R. Vilalta
8 CTTC
9 D. King
10 Lancaster University
11 D. Ceccarelli
12 Ericsson
13 February 19, 2021
15 YANG models for VN/TE Performance Monitoring Telemetry and Scaling
16 Intent Autonomics
17 draft-ietf-teas-actn-pm-telemetry-autonomics-05
19 Abstract
21 This document provides YANG data models that describe performance
22 monitoring telemetry and scaling intent mechanism for TE-tunnels and
23 Virtual Networks (VN).
25 The models presented in this draft allow customers to subscribe to
26 and monitor their key performance data of their interest on the level
27 of TE-tunnel or VN. The models also provide customers with the
28 ability to program autonomic scaling intent mechanism on the level of
29 TE-tunnel as well as VN.
31 Status of This Memo
33 This Internet-Draft is submitted in full conformance with the
34 provisions of BCP 78 and BCP 79.
36 Internet-Drafts are working documents of the Internet Engineering
37 Task Force (IETF). Note that other groups may also distribute
38 working documents as Internet-Drafts. The list of current Internet-
39 Drafts is at https://datatracker.ietf.org/drafts/current/.
41 Internet-Drafts are draft documents valid for a maximum of six months
42 and may be updated, replaced, or obsoleted by other documents at any
43 time. It is inappropriate to use Internet-Drafts as reference
44 material or to cite them other than as "work in progress."
46 This Internet-Draft will expire on August 23, 2021.
48 Copyright Notice
50 Copyright (c) 2021 IETF Trust and the persons identified as the
51 document authors. All rights reserved.
53 This document is subject to BCP 78 and the IETF Trust's Legal
54 Provisions Relating to IETF Documents
55 (https://trustee.ietf.org/license-info) in effect on the date of
56 publication of this document. Please review these documents
57 carefully, as they describe your rights and restrictions with respect
58 to this document. Code Components extracted from this document must
59 include Simplified BSD License text as described in Section 4.e of
60 the Trust Legal Provisions and are provided without warranty as
61 described in the Simplified BSD License.
63 Table of Contents
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
67 1.1.1. Requirements Language . . . . . . . . . . . . . . . . 4
68 1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 4
69 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5
70 2. Use-Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
71 3. Design of the Data Models . . . . . . . . . . . . . . . . . . 7
72 3.1. TE KPI Telemetry Model . . . . . . . . . . . . . . . . . 7
73 3.2. VN KPI Telemetry Model . . . . . . . . . . . . . . . . . 8
74 4. Autonomic Scaling Intent Mechanism . . . . . . . . . . . . . 9
75 5. Notification . . . . . . . . . . . . . . . . . . . . . . . . 11
76 5.1. YANG Push Subscription Examples . . . . . . . . . . . . . 11
77 6. YANG Data Tree . . . . . . . . . . . . . . . . . . . . . . . 13
78 7. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 16
79 7.1. ietf-te-kpi-telemetry model . . . . . . . . . . . . . . . 16
80 7.2. ietf-vn-kpi-telemetry model . . . . . . . . . . . . . . . 23
81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
85 11.1. Normative References . . . . . . . . . . . . . . . . . . 28
86 11.2. Informative References . . . . . . . . . . . . . . . . . 30
87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
89 1. Introduction
91 The YANG [RFC7950] model discussed in [I-D.ietf-teas-actn-vn-yang] is
92 used to operate customer-driven Virtual Networks (VNs) during the VN
93 instantiation, VN computation, and its life-cycle service management
94 and operations. YANG model discussed in [I-D.ietf-teas-yang-te] is
95 used to operate TE-tunnels during the tunnel instantiation, and its
96 life-cycle management and operations.
98 The models presented in this draft allow the applications hosted by
99 the customers to subscribe to and monitor their key performance data
100 of their interest on the level of VN [I-D.ietf-teas-actn-vn-yang] or
101 TE-tunnel [I-D.ietf-teas-yang-te]. The key characteristic of the
102 models presented in this document is a top-down programmability that
103 allows the applications hosted by the customers to subscribe to and
104 monitor key performance data of their interest and autonomic scaling
105 intent mechanism on the level of VN as well as TE-tunnel.
107 According to the classification of [RFC8309], the YANG data models
108 presented in this document can be classified as customer service
109 models, which is mapped to CMI (Customer Network Controller (CNC)-
110 Multi-Domain Service Coordinator (MSDC) interface) of ACTN [RFC8453].
112 [RFC8233] describes key network performance data to be considered for
113 end-to-end path computation in TE networks. Key performance
114 indicator (KPI) is a term that describes critical performance data
115 that may affect VN/TE-tunnel service. The services provided can be
116 optimized to meet the requirements (such as traffic patterns,
117 quality, and reliability) of the applications hosted by the
118 customers.
120 This document provides YANG data models generically applicable to any
121 VN/TE-Tunnel service clients to provide an ability to program their
122 customized performance monitoring subscription and publication data
123 models and automatic scaling in/out intent data models. These models
124 can be utilized by a client network controller to initiate these
125 capability to a transport network controller communicating with the
126 client controller via a NETCONF [RFC8341] or a RESTCONF [RFC8040]
127 interface.
129 The term performance monitoring being used in this document is
130 different from the term that has been used in transport networks for
131 many years. Performance monitoring in this document refers to
132 subscription and publication of streaming telemetry data.
133 Subscription is initiated by the client (e.g., CNC) while publication
134 is provided by the network (e.g., MDSC/PNC) based on the client's
135 subscription. As the scope of performance monitoring in this
136 document is telemetry data on the level of client's VN or TE- tunnel,
137 the entity interfacing the client (e.g., MDSC) has to provide VN or
138 TE-tunnel level information. This would require controller
139 capability to derive VN or TE-tunnel level performance data based on
140 lower-level data collected via PM counters in the Network Elements
141 (NE). How the controller entity derives such customized level data
142 (i.e., VN or TE-tunnel level) is out of the scope of this document.
144 The data model includes configuration and state data according to the
145 new Network Management Datastore Architecture [RFC8342].
147 [Editor's Note: A suggestion is made to remove the word KPI from the
148 name of the model. Further discussion is needed.]
150 1.1. Terminology
152 Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used
153 in this document.
155 Key Performance Data: This refers to a set of data the customer is
156 interested in monitoring for their instantiated VNs or TE-tunnels.
157 Key performance data and key performance indicators are inter-
158 exchangeable in this draft.
160 Scaling: This refers to the network ability to re-shape its own
161 resources. Scale out refers to improve network performance by
162 increasing the allocated resources, while scale in refers to decrease
163 the allocated resources, typically because the existing resources are
164 unnecessary.
166 Scaling Intent: To declare scaling conditions, scaling intent is
167 used. Specifically, scaling intent refers to the intent expressed by
168 the client that allows the client to program/configure conditions of
169 their key performance data either for scaling out or scaling in.
170 Various conditions can be set for scaling intent on either VN or TE-
171 tunnel level.
173 Network Autonomics: This refers to the network automation capability
174 that allows client to initiate scaling intent mechanisms and provides
175 the client with the status of the adjusted network resources based on
176 the client's scaling intent in an automated fashion.
178 1.1.1. Requirements Language
180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
182 "OPTIONAL" in this document are to be interpreted as described in BCP
183 14 [RFC2119] [RFC8174] when, and only when, they appear in all
184 capitals, as shown here.
186 1.2. Tree diagram
188 A simplified graphical representation of the data model is used in
189 Section 5 of this this document. The meaning of the symbols in these
190 diagrams is defined in [RFC8340].
192 1.3. Prefixes in Data Node Names
194 In this document, names of data nodes and other data model objects
195 are prefixed using the standard prefix associated with the
196 corresponding YANG imported modules, as shown in Table 1.
198 +----------+-----------------------+------------------------------+
199 | Prefix | YANG module | Reference |
200 +----------+-----------------------+------------------------------+
201 | te | ietf-te | [I-D.ietf-teas-yang-te] |
202 | te-types | ietf-te-types | [RFC8776] |
203 | te-tel | ietf-te-kpi-telemetry | [RFCXXXX] |
204 | vn | ietf-vn | [I-D.ietf-teas-actn-vn-yang] |
205 | vn-tel | ietf-vn-kpi-telemetry | [RFCXXXX] |
206 +----------+-----------------------+------------------------------+
208 Table 1: Prefixes and corresponding YANG modules
210 Note: The RFC Editor will replace XXXX with the number assigned to
211 the RFC once this draft becomes an RFC.
213 Further, the following additional documents are refrenced in the
214 model defined in this document -
216 o [RFC7471] - OSPF Traffic Engineering (TE) Metric Extensions.
218 o [RFC8570] - IS-IS Traffic Engineering (TE) Metric Extensions.
220 o [RFC7823] - Performance-Based Path Selection for Explicitly Routed
221 Label Switched Paths (LSPs) Using TE Metric Extensions.
223 2. Use-Cases
225 [I-D.xu-actn-perf-dynamic-service-control] describes use-cases
226 relevant to this draft. It introduces the dynamic creation,
227 modification and optimization of services based on the performance
228 monitoring. Figure 1 shows a high-level workflows for dynamic
229 service control based on traffic monitoring.
231 +----------------------------------------------+
232 | Client +-----------------------------+ |
233 | | Dynamic Service Control APP | |
234 | +-----------------------------+ |
235 +----------------------------------------------+
236 1.Traffic| /|\4.Traffic | /|\
237 Monitor& | | Monitor | | 8.Traffic
238 Optimize | | Result 5.Service | | modify &
239 Policy | | modify& | | optimize
240 \|/ | optimize Req.\|/ | result
241 +----------------------------------------------+
242 | Orchestrator |
243 | +-------------------------------+ |
244 | |Dynamic Service Control Agent | |
245 | +-------------------------------+ |
246 | +---------------+ +-------------------+ |
247 | | Flow Optimize | | vConnection Agent | |
248 | +---------------+ +-------------------+ |
249 +----------------------------------------------+
250 2. Path | /|\3.Traffic | /|\
251 Monitor | | Monitor | |7.Path
252 Request | | Result 6.Path | | modify &
253 | | modify& | | optimize
254 \|/ | optimize Req.\|/ | result
255 +----------------------------------------------+
256 | Network SDN Controller |
257 | +----------------------+ +-----------------+|
258 | | Network Provisioning | |Abstract Topology||
259 | +----------------------+ +-----------------+|
260 | +------------------+ +--------------------+ |
261 | |Network Monitoring| |Physical Topology DB| |
262 | +------------------+ +--------------------+ |
263 +----------------------------------------------+
265 Figure 1: Workflows for dynamic service control based on traffic
266 monitoring
268 Some of the key points from
269 [I-D.xu-actn-perf-dynamic-service-control] are as follows:
271 o Network traffic monitoring is important to facilitate automatic
272 discovery of the imbalance of network traffic, and initiate the
273 network optimization, thus helping the network operator or the
274 virtual network service provider to use the network more
275 efficiently and save the Capital Expense (CAPEX) and the Operating
276 Expense (OPEX).
278 o Customer services have various Service Level Agreement (SLA)
279 requirements, such as service availability, latency, latency
280 jitter, packet loss rate, Bit Error Rate (BER), etc. The
281 transport network can satisfy service availability and BER
282 requirements by providing different protection and restoration
283 mechanisms. However, for other performance parameters, there are
284 no such mechanisms. In order to provide high quality services
285 according to customer SLA, one possible solution is to measure the
286 SLA related performance parameters, and dynamically provision and
287 optimize services based on the performance monitoring results.
289 o Performance monitoring in a large scale network could generate a
290 huge amount of performance information. Therefore, the
291 appropriate way to deliver the information in the client and
292 network interfaces should be carefully considered.
294 3. Design of the Data Models
296 The YANG models developed in this document describe two models:
298 (i) TE KPI Telemetry Model which provides the TE-Tunnel level of
299 performance monitoring mechanism and scaling intent mechanism
300 that allows scale in/out programming by the customer. (See
301 Section 3.1 & Section 7.1 for details).
303 (ii) VN KPI Telemetry Model which provides the VN level of the
304 aggregated performance monitoring mechanism and scaling intent
305 mechanism that allows scale in/out programming by the customer
306 (See Section 3.2 & Section 7.2 for details).
308 3.1. TE KPI Telemetry Model
310 This module describes performance telemetry for TE-tunnel model. The
311 telemetry data is augmented to tunnel state. This module also allows
312 autonomic traffic engineering scaling intent configuration mechanism
313 on the TE-tunnel level. Various conditions can be set for auto-
314 scaling based on the telemetry data (See Section 5 for details)
316 The TE KPI Telemetry Model augments the TE-Tunnel Model to enhance TE
317 performance monitoring capability. This monitoring capability will
318 facilitate proactive re-optimization and reconfiguration of TEs based
319 on the performance monitoring data collected via the TE KPI Telemetry
320 YANG model.
322 +------------+ +--------------+
323 | TE-Tunnel | | TE KPI |
324 | Model |<---------| Telemetry |
325 +------------+ augments | Model |
326 +--------------+
328 3.2. VN KPI Telemetry Model
330 This module describes performance telemetry for VN model. The
331 telemetry data is augmented both at the VN Level as well as
332 individual VN member level. This module also allows autonomic
333 traffic engineering scaling intent configuration mechanism on the VN
334 level. Scale in/out criteria might be used for network autonomics in
335 order the controller to react to a certain set of variations in
336 monitored parameters (See Section 4 for illustrations).
338 Moreover, this module also provides mechanism to define aggregated
339 telemetry parameters as a grouping of underlying VN level telemetry
340 parameters. Grouping operation (such as maximum, mean) could be set
341 at the time of configuration. For example, if maximum grouping
342 operation is used for delay at the VN level, the VN telemetry data is
343 reported as the maximum {delay_vn_member_1, delay_vn_member_2,..
344 delay_vn_member_N}. Thus, this telemetry abstraction mechanism allows
345 the grouping of a certain common set of telemetry values under a
346 grouping operation. This can be done at the VN-member level to
347 suggest how the E2E telemetry be inferred from the per domain tunnel
348 created and monitored by PNCs. One proposed example is the
349 following:
351 +------------------------------------------------------------+
352 | Client |
353 | |
354 +------------------------------------------------------------+
355 1.Client sets the | /|\ 2. Orchestrator pushes:
356 grouping op, and | |
357 subscribes to the | | VN level telemetry for
358 VN level telemetry for | | - VN Utilized-bw-percentage
359 Delay and | | (Minimum across VN Members)
360 Utilized-bw-pecentage | | - VN Delay (Maximum across VN
361 \|/ | Members)
362 +------------------------------------------------------------+
363 | Orchestrator |
364 | |
365 +------------------------------------------------------------+
367 The VN Telemetry Model augments the basic VN model to enhance VN
368 monitoring capability. This monitoring capability will facilitate
369 proactive re-optimization and reconfiguration of VNs based on the
370 performance monitoring data collected via the VN Telemetry YANG
371 model.
373 +----------+ +--------------+
374 | VN | augments | VN |
375 | Model |<---------| Telemetry |
376 +----------+ | Model |
377 +--------------+
379 4. Autonomic Scaling Intent Mechanism
381 Scaling intent configuration mechanism allows the client to configure
382 automatic scale-in and scale-out mechanisms on both the TE-tunnel and
383 the VN level. Various conditions can be set for auto- scaling based
384 on the PM telemetry data.
386 There are a number of parameters involved in the mechanism:
388 o scale-out-intent or scale-in-intent: whether to scale-out or
389 scale-in.
391 o performance-type: performance metric type (e.g., one-way-delay,
392 one-way-delay-min, one-way-delay-max, two-way-delay, two-way-
393 delay-min, two-way-delay-max, utilized bandwidth, etc.)
395 o threshold-value: the threshold value for a certain performance-
396 type that triggers scale-in or scale-out.
398 o scaling-operation-type: in case where scaling condition can be set
399 with one or more performance types, then scaling-operation-type
400 (AND, OR, MIN, MAX, etc.) is applied to these selected performance
401 types and its threshold values.
403 o Threshold-time: the duration for which the criteria MUST hold
404 true.
406 o Cooldown-time: the duration after a scaling action has been
407 triggered, for which there will be no further operation.
409 The following tree is a part of ietf-te-kpi-telemetry tree whose
410 model is presented in full detail in Sections 6 & 7.
412 module: ietf-te-kpi-telemetry
413 augment /te:te/te:tunnels/te:tunnel:
414 +--rw te-scaling-intent
415 | +--rw scale-in-intent
416 | | +--rw threshold-time? uint32
417 | | +--rw cooldown-time? uint32
418 | | +--rw scaling-condition* [performance-type]
419 | | | +--rw performance-type identityref
420 | | | +--rw threshold-value? string
421 | | | +--rw scale-in-operation-type?
422 | | | scaling-criteria-operation
423 | | +--rw scale-in-op? identityref
424 | | +--rw scale? string
425 | +--rw scale-out-intent
426 | +--rw threshold-time? uint32
427 | +--rw cooldown-time? uint32
428 | +--rw scaling-condition* [performance-type]
429 | | +--rw performance-type identityref
430 | | +--rw threshold-value? string
431 | | +--rw scale-out-operation-type?
432 | | scaling-criteria-operation
433 | +--rw scale-out-op? identityref
434 | +--rw scale? string
436 Let say the client wants to set the scaling out operation based on
437 two performance-types (e.g., two-way-delay and utilized-bandwidth for
438 a te-tunnel), it can be done as follows:
440 o Set Threshold-time: x (sec) (duration for which the criteria must
441 hold true)
443 o Set Cooldown-time: y (sec) (the duration after a scaling action
444 has been triggered, for which there will be no further operation)
446 o Set AND for the scale-out-operation-type
448 In the scaling condition's list, the following two components can be
449 set:
451 List 1: Scaling Condition for Two-way-delay
453 o performance type: Two-way-delay
455 o threshold-value: z milli-seconds
457 List 2: Scaling Condition for Utilized bandwidth
459 o performance type: Utilized bandwidth
460 o threshold-value: w megabytes
462 5. Notification
464 This model does not define specific notifications. To enable
465 notifications, the mechanism defined in [RFC8641] and [RFC8640] can
466 be used. This mechanism currently allows the user to:
468 o Subscribe to notifications on a per client basis.
470 o Specify subtree filters or xpath filters so that only interested
471 contents will be sent.
473 o Specify either periodic or on-demand notifications.
475 5.1. YANG Push Subscription Examples
477 [RFC8641] allows subscriber applications to request a continuous,
478 customized stream of updates from a YANG datastore.
480 Below example shows the way for a client to subscribe to the
481 telemetry information for a particular tunnel (Tunnel1). The
482 telemetry parameter that the client is interested in is one-way-
483 delay.
485
487
489
490
491
492
493 Tunnel1
494
495
496
498
499
500
501
502
503
504
505 500
506 encode-xml
507
508
510 This example shows the way for a client to subscribe to the telemetry
511 information for all VNs. The telemetry parameter that the client is
512 interested in is one-way-delay and one-way-utilized- bandwidth.
514
516
518
519
520
521
522
523
524
526
527
528
529
530
531
532
533 500
534
535
537 6. YANG Data Tree
539 module: ietf-te-kpi-telemetry
540 augment /te:te/te:tunnels/te:tunnel:
541 +--rw te-scaling-intent
542 | +--rw scale-in-intent
543 | | +--rw threshold-time? uint32
544 | | +--rw cooldown-time? uint32
545 | | +--rw scaling-condition* [performance-type]
546 | | | +--rw performance-type identityref
547 | | | +--rw threshold-value? string
548 | | | +--rw scale-in-operation-type?
549 | | | scaling-criteria-operation
550 | | +--rw scale-in-op? identityref
551 | | +--rw scale? string
552 | +--rw scale-out-intent
553 | +--rw threshold-time? uint32
554 | +--rw cooldown-time? uint32
555 | +--rw scaling-condition* [performance-type]
556 | | +--rw performance-type identityref
557 | | +--rw threshold-value? string
558 | | +--rw scale-out-operation-type?
559 | | scaling-criteria-operation
560 | +--rw scale-out-op? identityref
561 | +--rw scale? string
562 +--ro te-telemetry
563 +--ro id? telemetry-id
564 +--ro performance-metrics-one-way
565 | +--ro one-way-delay? uint32
566 | +--ro one-way-delay-normality?
567 | | te-types:performance-metrics-normality
568 | +--ro one-way-residual-bandwidth?
569 | | rt-types:bandwidth-ieee-float32
570 | +--ro one-way-residual-bandwidth-normality?
571 | | te-types:performance-metrics-normality
572 | +--ro one-way-available-bandwidth?
573 | | rt-types:bandwidth-ieee-float32
574 | +--ro one-way-available-bandwidth-normality?
575 | | te-types:performance-metrics-normality
576 | +--ro one-way-utilized-bandwidth?
577 | | rt-types:bandwidth-ieee-float32
578 | +--ro one-way-utilized-bandwidth-normality?
579 | te-types:performance-metrics-normality
580 +--ro performance-metrics-two-way
581 +--ro two-way-delay? uint32
582 +--ro two-way-delay-normality?
583 te-types:performance-metrics-normality
585 module: ietf-vn-kpi-telemetry
586 augment /vn:vn/vn:vn:
587 +--rw vn-scaling-intent
588 | +--rw scale-in-intent
589 | | +--rw threshold-time? uint32
590 | | +--rw cooldown-time? uint32
591 | | +--rw scaling-condition* [performance-type]
592 | | | +--rw performance-type identityref
593 | | | +--rw threshold-value? string
594 | | | +--rw scale-in-operation-type?
595 | | | scaling-criteria-operation
596 | | +--rw scale-in-op? identityref
597 | | +--rw scale? string
598 | +--rw scale-out-intent
599 | +--rw threshold-time? uint32
600 | +--rw cooldown-time? uint32
601 | +--rw scaling-condition* [performance-type]
602 | | +--rw performance-type identityref
603 | | +--rw threshold-value? string
604 | | +--rw scale-out-operation-type?
605 | | scaling-criteria-operation
606 | +--rw scale-out-op? identityref
607 | +--rw scale? string
608 +--ro vn-telemetry
609 +--ro performance-metrics-one-way
610 | +--ro one-way-delay? uint32
611 | +--ro one-way-delay-normality?
612 | | te-types:performance-metrics-normality
613 | +--ro one-way-residual-bandwidth?
614 | | rt-types:bandwidth-ieee-float32
615 | +--ro one-way-residual-bandwidth-normality?
616 | | te-types:performance-metrics-normality
617 | +--ro one-way-available-bandwidth?
618 | | rt-types:bandwidth-ieee-float32
619 | +--ro one-way-available-bandwidth-normality?
620 | | te-types:performance-metrics-normality
621 | +--ro one-way-utilized-bandwidth?
622 | | rt-types:bandwidth-ieee-float32
623 | +--ro one-way-utilized-bandwidth-normality?
624 | te-types:performance-metrics-normality
625 +--ro performance-metrics-two-way
626 | +--ro two-way-delay? uint32
627 | +--ro two-way-delay-normality?
628 | te-types:performance-metrics-normality
629 +--ro grouping-operation? grouping-operation
630 augment /vn:vn/vn:vn/vn:vn-member:
631 +--ro vn-member-telemetry
632 +--ro performance-metrics-one-way
633 | +--ro one-way-delay? uint32
634 | +--ro one-way-delay-normality?
635 | | te-types:performance-metrics-normality
636 | +--ro one-way-residual-bandwidth?
637 | | rt-types:bandwidth-ieee-float32
638 | +--ro one-way-residual-bandwidth-normality?
639 | | te-types:performance-metrics-normality
640 | +--ro one-way-available-bandwidth?
641 | | rt-types:bandwidth-ieee-float32
642 | +--ro one-way-available-bandwidth-normality?
643 | | te-types:performance-metrics-normality
644 | +--ro one-way-utilized-bandwidth?
645 | | rt-types:bandwidth-ieee-float32
646 | +--ro one-way-utilized-bandwidth-normality?
647 | te-types:performance-metrics-normality
648 +--ro performance-metrics-two-way
649 | +--ro two-way-delay? uint32
650 | +--ro two-way-delay-normality?
651 | te-types:performance-metrics-normality
652 +--ro te-grouped-params*
653 | -> /te:te/tunnels/tunnel/te-kpi:te-telemetry/id
654 +--ro grouping-operation? grouping-operation
656 7. YANG Data Model
658 7.1. ietf-te-kpi-telemetry model
660 The YANG code is as follows:
662 file "ietf-te-kpi-telemetry@2021-02-19.yang"
663 module ietf-te-kpi-telemetry {
664 yang-version 1.1;
665 namespace "urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry";
666 prefix te-tel;
668 /* Import TE */
670 import ietf-te {
671 prefix te;
672 reference
673 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic
674 Engineering Tunnels and Interfaces";
675 }
677 /* Import TE Common types */
679 import ietf-te-types {
680 prefix te-types;
681 reference
682 "RFC 8776: Common YANG Data Types for Traffic Engineering";
683 }
685 organization
686 "IETF Traffic Engineering Architecture and Signaling (TEAS)
687 Working Group";
688 contact
689 "WG Web:
690 WG List:
691 Editor: Young Lee
692 Dhruv Dhody ";
693 description
694 "This module describes YANG data model for performance
695 monitoring telemetry for te tunnels.
696 Copyright (c) 2021 IETF Trust and the persons identified as
697 authors of the code. All rights reserved.
699 Redistribution and use in source and binary forms, with or
700 without modification, is permitted pursuant to, and subject to
701 the license terms contained in, the Simplified BSD License set
702 forth in Section 4.c of the IETF Trust's Legal Provisions
703 Relating to IETF Documents
704 (https://trustee.ietf.org/license-info).
706 This version of this YANG module is part of RFC XXXX; see the
707 RFC itself for full legal notices.
709 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
710 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
711 'MAY', and 'OPTIONAL' in this document are to be interpreted as
712 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
713 they appear in all capitals, as shown here.";
715 /* Note: The RFC Editor will replace XXXX with the number
716 assigned to the RFC once draft-ietf-teas-pm-telemetry-
717 autonomics becomes an RFC.*/
719 revision 2021-02-19 {
720 description
721 "Initial revision.";
722 reference
723 "RFC XXXX: YANG models for VN/TE Performance Monitoring
724 Telemetry and Scaling Intent Autonomics";
725 }
727 identity telemetry-param-type {
728 description
729 "Base identity for telemetry param types";
730 }
732 identity one-way-delay {
733 base telemetry-param-type;
734 description
735 "To specify average Delay in one (forward) direction.
737 At the VN level, it is the max delay of the VN-members.";
738 reference
739 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions.
740 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions.
741 RFC 7823: Performance-Based Path Selection for Explicitly
742 Routed Label Switched Paths (LSPs) Using TE Metric
743 Extensions";
744 }
746 identity two-way-delay {
747 base telemetry-param-type;
748 description
749 "To specify average Delay in both (forward and reverse)
750 directions.
752 At the VN level, it is the max delay of the VN-members.";
753 reference
754 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions.
755 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions.
756 RFC 7823: Performance-Based Path Selection for Explicitly
757 Routed Label Switched Paths (LSPs) Using TE Metric
758 Extensions";
759 }
761 identity one-way-delay-variation {
762 base telemetry-param-type;
763 description
764 "To specify average Delay Variation in one (forward) direction.
766 At the VN level, it is the max delay variation of the
767 VN-members.";
768 reference
769 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions.
770 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions.
771 RFC 7823: Performance-Based Path Selection for Explicitly
772 Routed Label Switched Paths (LSPs) Using TE Metric
773 Extensions";
774 }
776 identity two-way-delay-variation {
777 base telemetry-param-type;
778 description
779 "To specify average Delay Variation in both (forward and reverse)
780 directions.
782 At the VN level, it is the max delay variation of the
783 VN-members.";
784 reference
785 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions.
786 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions.
787 RFC 7823: Performance-Based Path Selection for Explicitly
788 Routed Label Switched Paths (LSPs) Using TE Metric
789 Extensions";
790 }
792 identity utilized-bandwidth {
793 base telemetry-param-type;
794 description
795 "To specify utilized bandwidth over the specified source
796 and destination.";
797 reference
798 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions.
799 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions.
800 RFC 7823: Performance-Based Path Selection for Explicitly
801 Routed Label Switched Paths (LSPs) Using TE Metric
802 Extensions";
803 }
805 identity utilized-percentage {
806 base telemetry-param-type;
807 description
808 "To specify utilization percentage of the entity
809 (e.g., tunnel, link, etc.)";
810 }
812 identity scale-op {
813 description
814 "Base identity for scaling operation";
815 }
817 identity scale-capacity-up {
818 base scale-op;
819 description
820 "Scale up the bandwidth capacity";
821 }
823 identity scale-capacity-down {
824 base scale-op;
825 description
826 "Scale down the bandwidth capacity";
827 }
829 /* Typedef */
831 typedef telemetry-id {
832 type string;
833 description
834 "Identifier for the telemetry data.";
835 }
837 typedef scaling-criteria-operation {
838 type enumeration {
839 enum AND {
840 description
841 "AND operation";
842 }
843 enum OR {
844 description
845 "OR operation";
846 }
847 }
848 description
849 "Operations to analize list of scaling criterias";
850 }
852 grouping scaling-duration {
853 description
854 "Base scaling criteria durations";
855 leaf threshold-time {
856 type uint32;
857 units "seconds";
858 description
859 "The duration for which the criteria must hold true";
860 }
861 leaf cooldown-time {
862 type uint32;
863 units "seconds";
864 description
865 "The duration after a scaling-in/scaling-out action has been
866 triggered, for which there will be no further operation";
867 }
868 }
870 grouping scaling-criteria {
871 description
872 "Grouping for scaling criteria";
873 leaf performance-type {
874 type identityref {
875 base telemetry-param-type;
876 }
877 description
878 "Reference to the tunnel level telemetry type";
879 }
880 leaf threshold-value {
881 type string;
882 description
883 "Scaling threshold for the telemetry parameter type";
884 }
885 }
887 grouping scaling-in-intent {
888 description
889 "Basic scaling in intent";
890 uses scaling-duration;
891 list scaling-condition {
892 key "performance-type";
893 description
894 "Scaling conditions";
895 uses scaling-criteria;
896 leaf scale-in-operation-type {
897 type scaling-criteria-operation;
898 default "AND";
899 description
900 "Operation to be applied to check between scaling criterias
901 to check if the scale in threshold condition has been met.
902 Defaults to AND";
903 }
904 }
905 leaf scale-in-op {
906 type identityref {
907 base scale-op;
908 }
909 default "scale-capacity-down";
910 description
911 "The scaling operation to be performed when scaling condition
912 is met";
913 }
914 leaf scale {
915 type string;
916 description
917 "Additional scaling-by information to be interpritted as per
918 the scale-in-op.";
919 }
920 }
922 grouping scaling-out-intent {
923 description
924 "Basic scaling out intent";
925 uses scaling-duration;
926 list scaling-condition {
927 key "performance-type";
928 description
929 "Scaling conditions";
930 uses scaling-criteria;
931 leaf scale-out-operation-type {
932 type scaling-criteria-operation;
933 default "OR";
934 description
935 "Operation to be applied to check between scaling criterias
936 to check if the scale out threshold condition has been met.
937 Defauls to OR";
938 }
940 }
941 leaf scale-out-op {
942 type identityref {
943 base scale-op;
944 }
945 default "scale-capacity-up";
946 description
947 "The scaling operation to be performed when scaling condition
948 is met";
949 }
950 leaf scale {
951 type string;
952 description
953 "Additional scaling-by information to be interpritted as per
954 the scale-out-op.";
955 }
956 }
958 augment "/te:te/te:tunnels/te:tunnel" {
959 description
960 "Augmentation parameters for config scaling-criteria TE
961 tunnel topologies. Scale in/out criteria might be used
962 for network autonomics in order the controller to react
963 to a certain set of monitored params.";
964 container te-scaling-intent {
965 description
966 "The scaling intent";
967 container scale-in-intent {
968 description
969 "scale-in";
970 uses scaling-in-intent;
971 }
972 container scale-out-intent {
973 description
974 "scale-out";
975 uses scaling-out-intent;
976 }
977 }
978 container te-telemetry {
979 config false;
980 description
981 "Telemetry Data";
982 leaf id {
983 type telemetry-id;
984 description
985 "ID of telemetry data used for easy reference";
986 }
987 uses te-types:performance-metrics-attributes;
989 }
990 }
991 }
993
995 7.2. ietf-vn-kpi-telemetry model
997 The YANG code is as follows:
999 file "ietf-vn-kpi-telemetry@2021-02-19.yang"
1000 module ietf-vn-kpi-telemetry {
1001 yang-version 1.1;
1002 namespace "urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry";
1003 prefix vn-kpi;
1005 /* Import VN */
1007 import ietf-vn {
1008 prefix vn;
1009 reference
1010 "I-D.ietf-teas-actn-vn-yang: A YANG Data Model for VN
1011 Operation";
1012 }
1014 /* Import TE */
1016 import ietf-te {
1017 prefix te;
1018 reference
1019 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic
1020 Engineering Tunnels and Interfaces";
1021 }
1023 /* Import TE Common types */
1025 import ietf-te-types {
1026 prefix te-types;
1027 reference
1028 "RFC 8776: Common YANG Data Types for Traffic Engineering";
1029 }
1031 /* Import TE KPI */
1033 import ietf-te-kpi-telemetry {
1034 prefix te-kpi;
1035 reference
1036 "RFC XXXX: YANG models for VN/TE Performance Monitoring
1037 Telemetry and Scaling Intent Autonomics";
1038 }
1040 /* Note: The RFC Editor will replace XXXX with the number
1041 assigned to this draft.*/
1043 organization
1044 "IETF Traffic Engineering Architecture and Signaling (TEAS)
1045 Working Group";
1046 contact
1047 "WG Web:
1048 WG List:
1049 Editor: Young Lee
1050 Dhruv Dhody ";
1051 description
1052 "This module describes YANG data models for performance
1053 monitoring telemetry for Virtual Network (VN).
1055 Copyright (c) 2021 IETF Trust and the persons identified as
1056 authors of the code. All rights reserved.
1058 Redistribution and use in source and binary forms, with or
1059 without modification, is permitted pursuant to, and subject to
1060 the license terms contained in, the Simplified BSD License set
1061 forth in Section 4.c of the IETF Trust's Legal Provisions
1062 Relating to IETF Documents
1063 (https://trustee.ietf.org/license-info).
1065 This version of this YANG module is part of RFC XXXX; see the
1066 RFC itself for full legal notices.
1068 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
1069 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
1070 'MAY', and 'OPTIONAL' in this document are to be interpreted as
1071 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
1072 they appear in all capitals, as shown here.";
1074 /* Note: The RFC Editor will replace XXXX with the number
1075 assigned to the RFC once draft-lee-teas-pm-telemetry-
1076 autonomics becomes an RFC.*/
1078 revision 2021-02-19 {
1079 description
1080 "Initial revision.";
1081 reference
1082 "RFC XXXX: YANG models for VN/TE Performance Monitoring
1083 Telemetry and Scaling Intent Autonomics";
1084 }
1085 typedef grouping-operation {
1086 type enumeration {
1087 enum MINIMUM {
1088 description
1089 "Select the minimum param";
1090 }
1091 enum MAXIMUM {
1092 description
1093 "Select the maximum param";
1094 }
1095 enum MEAN {
1096 description
1097 "Select the MEAN of the params";
1098 }
1099 enum STD_DEV {
1100 description
1101 "Select the standard deviation of the monitored params";
1102 }
1103 enum AND {
1104 description
1105 "Select the AND of the params";
1106 }
1107 enum OR {
1108 description
1109 "Select the OR of the params";
1110 }
1111 }
1112 description
1113 "Operations to analize list of monitored params";
1114 }
1116 grouping vn-telemetry-param {
1117 description
1118 "augment of te-kpi:telemetry-param for VN specific params";
1119 leaf-list te-grouped-params {
1120 type leafref {
1121 path
1122 "/te:te/te:tunnels/te:tunnel/te-kpi:te-telemetry/te-kpi:id";
1123 }
1124 description
1125 "Allows the definition of a vn-telemetry param
1126 as a grouping of underlying TE params";
1127 }
1128 leaf grouping-operation {
1129 type grouping-operation;
1130 description
1131 "describes the operation to apply to
1132 te-grouped-params";
1134 }
1135 }
1137 augment "/vn:vn/vn:vn" {
1138 description
1139 "Augmentation parameters for state TE VN topologies.";
1140 container vn-scaling-intent {
1141 description
1142 "scaling intent";
1143 container scale-in-intent {
1144 description
1145 "VN scale-in";
1146 uses te-kpi:scaling-in-intent;
1147 }
1148 container scale-out-intent {
1149 description
1150 "VN scale-out";
1151 uses te-kpi:scaling-out-intent;
1152 }
1153 }
1154 container vn-telemetry {
1155 config false;
1156 description
1157 "VN telemetry params";
1158 uses te-types:performance-metrics-attributes;
1159 leaf grouping-operation {
1160 type grouping-operation;
1161 description
1162 "describes the operation to apply to the VN-members";
1163 }
1164 }
1165 }
1167 augment "/vn:vn/vn:vn/vn:vn-member" {
1168 description
1169 "Augmentation parameters for state TE vn member topologies.";
1170 container vn-member-telemetry {
1171 config false;
1172 description
1173 "VN member telemetry params";
1174 uses te-types:performance-metrics-attributes;
1175 uses vn-telemetry-param;
1176 }
1177 }
1178 }
1180
1182 8. Security Considerations
1184 The YANG module specified in this document defines a schema for data
1185 that is designed to be accessed via network management protocols such
1186 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
1187 is the secure transport layer, and the mandatory-to-implement secure
1188 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
1189 is HTTPS, and the mandatory-to-implement secure transport is TLS
1190 [RFC8446].
1192 The NETCONF access control model [RFC8341] provides the means to
1193 restrict access for particular NETCONF users to a preconfigured
1194 subset of all available NETCONF protocol operations and content. The
1195 NETCONF Protocol over Secure Shell (SSH) [RFC6242] describes a method
1196 for invoking and running NETCONF within a Secure Shell (SSH) session
1197 as an SSH subsystem. The Network Configuration Access Control Model
1198 (NACM) [RFC8341] provides the means to restrict access for particular
1199 NETCONF or RESTCONF users to a preconfigured subset of all available
1200 NETCONF or RESTCONF protocol operations and content.
1202 A number of configuration data nodes defined in this document are
1203 writable/deletable (i.e., "config true"). These data nodes may be
1204 considered sensitive or vulnerable in some network environments.
1206 There are a number of data nodes defined in this YANG module that are
1207 writable/creatable/deletable (i.e., config true, which is the
1208 default). These data nodes may be considered sensitive or vulnerable
1209 in some network environments. Write operations (e.g., edit-config)
1210 to these data nodes without proper protection can have a negative
1211 effect on network operations. These are the subtrees and data nodes
1212 and their sensitivity/vulnerability:
1214 o /te:te/te:tunnels/te:tunnel/te-scaling-intent/scale-in-intent
1216 o /te:te/te:tunnels/te:tunnel/te-scaling-intent/scale-out-intent
1218 o /vn:vn/vn:vn/vn-scaling-intent/scale-in-intent
1220 o /vn:vn/vn:vn/vn-scaling-intent/scale-out-intent
1222 9. IANA Considerations
1224 This document registers the following namespace URIs in the IETF XML
1225 registry [RFC3688]:
1227 --------------------------------------------------------------------
1228 URI: urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry
1229 Registrant Contact: The IESG.
1230 XML: N/A, the requested URI is an XML namespace.
1231 --------------------------------------------------------------------
1233 --------------------------------------------------------------------
1234 URI: urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry
1235 Registrant Contact: The IESG.
1236 XML: N/A, the requested URI is an XML namespace.
1237 --------------------------------------------------------------------
1239 This document registers the following YANG modules in the YANG
1240 Module.
1242 Names registry [RFC7950]:
1244 --------------------------------------------------------------------
1245 name: ietf-te-kpi-telemetry
1246 namespace: urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry
1247 prefix: te-tel
1248 reference: RFC XXXX
1249 --------------------------------------------------------------------
1251 --------------------------------------------------------------------
1252 name: ietf-vn-kpi-telemetry
1253 namespace: urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry
1254 prefix: vn-tel
1255 reference: RFC XXXX
1256 --------------------------------------------------------------------
1258 10. Acknowledgements
1260 We thank Rakesh Gandhi, Tarek Saad, Igor Bryskin and Kenichi Ogaki
1261 for useful discussions and their suggestions for this work.
1263 11. References
1265 11.1. Normative References
1267 [I-D.ietf-teas-actn-vn-yang]
1268 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B.
1269 Yoon, "A YANG Data Model for VN Operation", draft-ietf-
1270 teas-actn-vn-yang-10 (work in progress), November 2020.
1272 [I-D.ietf-teas-yang-te]
1273 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
1274 "A YANG Data Model for Traffic Engineering Tunnels, Label
1275 Switched Paths and Interfaces", draft-ietf-teas-yang-te-25
1276 (work in progress), July 2020.
1278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1279 Requirement Levels", BCP 14, RFC 2119,
1280 DOI 10.17487/RFC2119, March 1997,
1281 .
1283 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1284 DOI 10.17487/RFC3688, January 2004,
1285 .
1287 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
1288 and A. Bierman, Ed., "Network Configuration Protocol
1289 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
1290 .
1292 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
1293 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
1294 .
1296 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G.,
1297 Ceccarelli, D., and X. Zhang, "Problem Statement and
1298 Architecture for Information Exchange between
1299 Interconnected Traffic-Engineered Networks", BCP 206,
1300 RFC 7926, DOI 10.17487/RFC7926, July 2016,
1301 .
1303 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
1304 RFC 7950, DOI 10.17487/RFC7950, August 2016,
1305 .
1307 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
1308 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
1309 .
1311 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1312 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1313 May 2017, .
1315 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki,
1316 "Extensions to the Path Computation Element Communication
1317 Protocol (PCEP) to Compute Service-Aware Label Switched
1318 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September
1319 2017, .
1321 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
1322 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
1323 .
1325 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
1326 Access Control Model", STD 91, RFC 8341,
1327 DOI 10.17487/RFC8341, March 2018,
1328 .
1330 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
1331 and R. Wilton, "Network Management Datastore Architecture
1332 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
1333 .
1335 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
1336 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
1337 .
1339 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
1340 E., and A. Tripathy, "Dynamic Subscription to YANG Events
1341 and Datastores over NETCONF", RFC 8640,
1342 DOI 10.17487/RFC8640, September 2019,
1343 .
1345 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
1346 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
1347 September 2019, .
1349 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
1350 "Common YANG Data Types for Traffic Engineering",
1351 RFC 8776, DOI 10.17487/RFC8776, June 2020,
1352 .
1354 11.2. Informative References
1356 [I-D.xu-actn-perf-dynamic-service-control]
1357 Xu, Y., Zhang, G., Cheng, W., and z.
1358 zhenghaomian@huawei.com, "Use Cases and Requirements of
1359 Dynamic Service Control based on Performance Monitoring in
1360 ACTN Architecture", draft-xu-actn-perf-dynamic-service-
1361 control-03 (work in progress), April 2015.
1363 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
1364 Previdi, "OSPF Traffic Engineering (TE) Metric
1365 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
1366 .
1368 [RFC7823] Atlas, A., Drake, J., Giacalone, S., and S. Previdi,
1369 "Performance-Based Path Selection for Explicitly Routed
1370 Label Switched Paths (LSPs) Using TE Metric Extensions",
1371 RFC 7823, DOI 10.17487/RFC7823, May 2016,
1372 .
1374 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
1375 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
1376 .
1378 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
1379 Abstraction and Control of TE Networks (ACTN)", RFC 8453,
1380 DOI 10.17487/RFC8453, August 2018,
1381 .
1383 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
1384 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
1385 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
1386 2019, .
1388 Authors' Addresses
1390 Young Lee (editor)
1391 Samsung Electronics
1393 Email: younglee.tx@gmail.com
1395 Dhruv Dhody (editor)
1396 Huawei Technologies
1397 Divyashree Techno Park, Whitefield
1398 Bangalore, Karnataka 560066
1399 India
1401 Email: dhruv.ietf@gmail.com
1403 Satish Karunanithi
1404 Huawei Technologies
1405 Divyashree Techno Park, Whitefield
1406 Bangalore, Karnataka 560066
1407 India
1409 Email: satish.karunanithi@gmail.com
1410 Ricard Vilalta
1411 CTTC
1412 Centre Tecnologic de Telecomunicacions de Catalunya (CTTC/CERCA)
1413 Barcelona
1414 Spain
1416 Email: ricard.vilalta@cttc.es
1418 Daniel King
1419 Lancaster University
1421 Email: d.king@lancaster.ac.uk
1423 Daniele Ceccarelli
1424 Ericsson
1425 Torshamnsgatan,48
1426 Stockholm, Sweden
1428 Email: daniele.ceccarelli@ericsson.com