idnits 2.17.1
draft-ietf-teas-actn-pm-telemetry-autonomics-03.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 (July 13, 2020) is 1375 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 203, but not defined
== Outdated reference: A later version (-24) exists of
draft-ietf-teas-actn-vn-yang-08
== Outdated reference: A later version (-36) exists of
draft-ietf-teas-yang-te-23
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: January 14, 2021 S. Karunanithi
6 Huawei Technologies
7 R. Vilalta
8 CTTC
9 D. King
10 Lancaster University
11 D. Ceccarelli
12 Ericsson
13 July 13, 2020
15 YANG models for VN/TE Performance Monitoring Telemetry and Scaling
16 Intent Autonomics
17 draft-ietf-teas-actn-pm-telemetry-autonomics-03
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 January 14, 2021.
48 Copyright Notice
50 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . 12
78 7. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 15
79 7.1. ietf-te-kpi-telemetry model . . . . . . . . . . . . . . . 15
80 7.2. ietf-vn-kpi-telemetry model . . . . . . . . . . . . . . . 21
81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
85 11.1. Normative References . . . . . . . . . . . . . . . . . . 26
86 11.2. Informative References . . . . . . . . . . . . . . . . . 28
87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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 1.1. Terminology
149 Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used
150 in this document.
152 Key Performance Data: This refers to a set of data the customer is
153 interested in monitoring for their instantiated VNs or TE-tunnels.
154 Key performance data and key performance indicators are inter-
155 exchangeable in this draft.
157 Scaling: This refers to the network ability to re-shape its own
158 resources. Scale out refers to improve network performance by
159 increasing the allocated resources, while scale in refers to decrease
160 the allocated resources, typically because the existing resources are
161 unnecessary.
163 Scaling Intent: To declare scaling conditions, scaling intent is
164 used. Specifically, scaling intent refers to the intent expressed by
165 the client that allows the client to program/configure conditions of
166 their key performance data either for scaling out or scaling in.
167 Various conditions can be set for scaling intent on either VN or TE-
168 tunnel level.
170 Network Autonomics: This refers to the network automation capability
171 that allows client to initiate scaling intent mechanisms and provides
172 the client with the status of the adjusted network resources based on
173 the client's scaling intent in an automated fashion.
175 1.1.1. Requirements Language
177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
179 "OPTIONAL" in this document are to be interpreted as described in BCP
180 14 [RFC2119] [RFC8174] when, and only when, they appear in all
181 capitals, as shown here.
183 1.2. Tree diagram
185 A simplified graphical representation of the data model is used in
186 Section 5 of this this document. The meaning of the symbols in these
187 diagrams is defined in [RFC8340].
189 1.3. Prefixes in Data Node Names
191 In this document, names of data nodes and other data model objects
192 are prefixed using the standard prefix associated with the
193 corresponding YANG imported modules, as shown in Table 1.
195 +----------+-----------------------+------------------------------+
196 | Prefix | YANG module | Reference |
197 +----------+-----------------------+------------------------------+
198 | inet | ietf-inet-types | [RFC6991] |
199 | te | ietf-te | [I-D.ietf-teas-yang-te] |
200 | te-types | ietf-te-types | [RFC8776] |
201 | te-tel | ietf-te-kpi-telemetry | [RFCXXXX] |
202 | vn | ietf-vn | [I-D.ietf-teas-actn-vn-yang] |
203 | vn-tel | ietf-vn-kpi-telemetry | [RFCXXXX] |
204 +----------+-----------------------+------------------------------+
206 Table 1: Prefixes and corresponding YANG modules
208 Note: The RFC Editor will replace XXXX with the number assigned to
209 the RFC once this draft becomes an RFC.
211 Further, the following additional documents are refrenced in the
212 model defined in this document -
214 o [RFC7471] - OSPF Traffic Engineering (TE) Metric Extensions.
216 o [RFC8570] - IS-IS Traffic Engineering (TE) Metric Extensions.
218 o [RFC7823] - Performance-Based Path Selection for Explicitly Routed
219 Label Switched Paths (LSPs) Using TE Metric Extensions.
221 2. Use-Cases
223 [I-D.xu-actn-perf-dynamic-service-control] describes use-cases
224 relevant to this draft. It introduces the dynamic creation,
225 modification and optimization of services based on the performance
226 monitoring. Figure 1 shows a high-level workflows for dynamic
227 service control based on traffic monitoring.
229 +----------------------------------------------+
230 | Client +-----------------------------+ |
231 | | Dynamic Service Control APP | |
232 | +-----------------------------+ |
233 +----------------------------------------------+
234 1.Traffic| /|\4.Traffic | /|\
235 Monitor& | | Monitor | | 8.Traffic
236 Optimize | | Result 5.Service | | modify &
237 Policy | | modify& | | optimize
238 \|/ | optimize Req.\|/ | result
239 +----------------------------------------------+
240 | Orchestrator |
241 | +-------------------------------+ |
242 | |Dynamic Service Control Agent | |
243 | +-------------------------------+ |
244 | +---------------+ +-------------------+ |
245 | | Flow Optimize | | vConnection Agent | |
246 | +---------------+ +-------------------+ |
247 +----------------------------------------------+
248 2. Path | /|\3.Traffic | /|\
249 Monitor | | Monitor | |7.Path
250 Request | | Result 6.Path | | modify &
251 | | modify& | | optimize
252 \|/ | optimize Req.\|/ | result
253 +----------------------------------------------+
254 | Network SDN Controller |
255 | +----------------------+ +-----------------+|
256 | | Network Provisioning | |Abstract Topology||
257 | +----------------------+ +-----------------+|
258 | +------------------+ +--------------------+ |
259 | |Network Monitoring| |Physical Topology DB| |
260 | +------------------+ +--------------------+ |
261 +----------------------------------------------+
263 Figure 1: Workflows for dynamic service control based on traffic
264 monitoring
266 Some of the key points from
267 [I-D.xu-actn-perf-dynamic-service-control] are as follows:
269 o Network traffic monitoring is important to facilitate automatic
270 discovery of the imbalance of network traffic, and initiate the
271 network optimization, thus helping the network operator or the
272 virtual network service provider to use the network more
273 efficiently and save the Capital Expense (CAPEX) and the Operating
274 Expense (OPEX).
276 o Customer services have various Service Level Agreement (SLA)
277 requirements, such as service availability, latency, latency
278 jitter, packet loss rate, Bit Error Rate (BER), etc. The
279 transport network can satisfy service availability and BER
280 requirements by providing different protection and restoration
281 mechanisms. However, for other performance parameters, there are
282 no such mechanisms. In order to provide high quality services
283 according to customer SLA, one possible solution is to measure the
284 SLA related performance parameters, and dynamically provision and
285 optimize services based on the performance monitoring results.
287 o Performance monitoring in a large scale network could generate a
288 huge amount of performance information. Therefore, the
289 appropriate way to deliver the information in the client and
290 network interfaces should be carefully considered.
292 3. Design of the Data Models
294 The YANG models developed in this document describe two models:
296 (i) TE KPI Telemetry Model which provides the TE-Tunnel level of
297 performance monitoring mechanism and scaling intent mechanism
298 that allows scale in/out programming by the customer. (See
299 Section 3.1 & Section 7.1 for details).
301 (ii) VN KPI Telemetry Model which provides the VN level of the
302 aggregated performance monitoring mechanism and scaling intent
303 mechanism that allows scale in/out programming by the customer
304 (See Section 3.2 & Section 7.2 for details).
306 3.1. TE KPI Telemetry Model
308 This module describes performance telemetry for TE-tunnel model. The
309 telemetry data is augmented to tunnel state. This module also allows
310 autonomic traffic engineering scaling intent configuration mechanism
311 on the TE-tunnel level. Various conditions can be set for auto-
312 scaling based on the telemetry data (See Section 5 for details)
314 The TE KPI Telemetry Model augments the TE-Tunnel Model to enhance TE
315 performance monitoring capability. This monitoring capability will
316 facilitate proactive re-optimization and reconfiguration of TEs based
317 on the performance monitoring data collected via the TE KPI Telemetry
318 YANG model.
320 +------------+ +--------------+
321 | TE-Tunnel | | TE KPI |
322 | Model |<---------| Telemetry |
323 +------------+ augments | Model |
324 +--------------+
326 3.2. VN KPI Telemetry Model
328 This module describes performance telemetry for VN model. The
329 telemetry data is augmented both at the VN Level as well as
330 individual VN member level. This module also allows autonomic
331 traffic engineering scaling intent configuration mechanism on the VN
332 level. Scale in/out criteria might be used for network autonomics in
333 order the controller to react to a certain set of variations in
334 monitored parameters (See Section 4 for illustrations).
336 Moreover, this module also provides mechanism to define aggregated
337 telemetry parameters as a grouping of underlying VN level telemetry
338 parameters. Grouping operation (such as maximum, mean) could be set
339 at the time of configuration. For example, if maximum grouping
340 operation is used for delay at the VN level, the VN telemetry data is
341 reported as the maximum {delay_vn_member_1, delay_vn_member_2,..
342 delay_vn_member_N}. Thus, this telemetry abstraction mechanism allows
343 the grouping of a certain common set of telemetry values under a
344 grouping operation. This can be done at the VN-member level to
345 suggest how the E2E telemetry be inferred from the per domain tunnel
346 created and monitored by PNCs. One proposed example is the
347 following:
349 +------------------------------------------------------------+
350 | Client |
351 | |
352 +------------------------------------------------------------+
353 1.Client sets the | /|\ 2. Orchestrator pushes:
354 grouping op, and | |
355 subscribes to the | | VN level telemetry for
356 VN level telemetry for | | - VN Utilized-bw-percentage
357 Delay and | | (Minimum across VN Members)
358 Utilized-bw-pecentage | | - VN Delay (Maximum across VN
359 \|/ | Members)
360 +------------------------------------------------------------+
361 | Orchestrator |
362 | |
363 +------------------------------------------------------------+
365 The VN Telemetry Model augments the basic VN model to enhance VN
366 monitoring capability. This monitoring capability will facilitate
367 proactive re-optimization and reconfiguration of VNs based on the
368 performance monitoring data collected via the VN Telemetry YANG
369 model.
371 +----------+ +--------------+
372 | VN | augments | VN |
373 | Model |<---------| Telemetry |
374 +----------+ | Model |
375 +--------------+
377 4. Autonomic Scaling Intent Mechanism
379 Scaling intent configuration mechanism allows the client to configure
380 automatic scale-in and scale-out mechanisms on both the TE-tunnel and
381 the VN level. Various conditions can be set for auto- scaling based
382 on the PM telemetry data.
384 There are a number of parameters involved in the mechanism:
386 o scale-out-intent or scale-in-intent: whether to scale-out or
387 scale-in.
389 o performance-type: performance metric type (e.g., one-way-delay,
390 one-way-delay-min, one-way-delay-max, two-way-delay, two-way-
391 delay-min, two-way-delay-max, utilized bandwidth, etc.)
393 o threshold-value: the threshold value for a certain performance-
394 type that triggers scale-in or scale-out.
396 o scaling-operation-type: in case where scaling condition can be set
397 with one or more performance types, then scaling-operation-type
398 (AND, OR, MIN, MAX, etc.) is applied to these selected performance
399 types and its threshold values.
401 o Threshold-time: the duration for which the criteria MUST hold
402 true.
404 o Cooldown-time: the duration after a scaling action has been
405 triggered, for which there will be no further operation.
407 The following tree is a part of ietf-te-kpi-telemetry tree whose
408 model is presented in full detail in Sections 6 & 7.
410 module: ietf-te-kpi-telemetry
411 augment /te:te/te:tunnels/te:tunnel:
412 +--rw te-scaling-intent
413 | +--rw scale-in-intent
414 | | +--rw threshold-time? uint32
415 | | +--rw cooldown-time? uint32
416 | | +--rw scaling-condition* [performance-type]
417 | | +--rw performance-type identityref
418 | | +--rw threshold-value? string
419 | | +--rw scale-in-operation-type?
420 | | scaling-criteria-operation
421 | +--rw scale-out-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-out-operation-type?
428 | scaling-criteria-operation
430 Let say the client wants to set the scaling out operation based on
431 two performance-types (e.g., two-way-delay and utilized-bandwidth for
432 a te-tunnel), it can be done as follows:
434 o Set Threshold-time: x (sec) (duration for which the criteria must
435 hold true)
437 o Set Cooldown-time: y (sec) (the duration after a scaling action
438 has been triggered, for which there will be no further operation)
440 o Set AND for the scale-out-operation-type
442 In the scaling condition's list, the following two components can be
443 set:
445 List 1: Scaling Condition for Two-way-delay
447 o performance type: Two-way-delay
449 o threshold-value: z milli-seconds
451 List 2: Scaling Condition for Utilized bandwidth
453 o performance type: Utilized bandwidth
455 o threshold-value: w megabytes
457 5. Notification
459 This model does not define specific notifications. To enable
460 notifications, the mechanism defined in [RFC8641] and [RFC8640] can
461 be used. This mechanism currently allows the user to:
463 o Subscribe to notifications on a per client basis.
465 o Specify subtree filters or xpath filters so that only interested
466 contents will be sent.
468 o Specify either periodic or on-demand notifications.
470 5.1. YANG Push Subscription Examples
472 [RFC8641] allows subscriber applications to request a continuous,
473 customized stream of updates from a YANG datastore.
475 Below example shows the way for a client to subscribe to the
476 telemetry information for a particular tunnel (Tunnel1). The
477 telemetry parameter that the client is interested in is one-way-
478 delay.
480
482
484
485
486
487
488 Tunnel1
489
490
491
493
494
495
496
497
498
499
500 500
501 encode-xml
502
503
505 This example shows the way for a client to subscribe to the telemetry
506 information for all VNs. The telemetry parameter that the client is
507 interested in is one-way-delay and one-way-utilized- bandwidth.
509
511
513
514
515
516
517
518
519
521
522
523
524
525
526
527
528 500
529
530
532 6. YANG Data Tree
534 module: ietf-te-kpi-telemetry
535 augment /te:te/te:tunnels/te:tunnel:
536 +--rw te-scaling-intent
537 | +--rw scale-in-intent
538 | | +--rw threshold-time? uint32
539 | | +--rw cooldown-time? uint32
540 | | +--rw scaling-condition* [performance-type]
541 | | +--rw performance-type identityref
542 | | +--rw threshold-value? string
543 | | +--rw scale-in-operation-type?
544 | | scaling-criteria-operation
545 | +--rw scale-out-intent
546 | +--rw threshold-time? uint32
547 | +--rw cooldown-time? uint32
548 | +--rw scaling-condition* [performance-type]
549 | +--rw performance-type identityref
550 | +--rw threshold-value? string
551 | +--rw scale-out-operation-type?
552 | scaling-criteria-operation
553 +--ro te-telemetry
554 +--ro id? telemetry-id
555 +--ro performance-metrics-one-way
556 | +--ro one-way-delay? uint32
557 | +--ro one-way-delay-normality?
558 | | te-types:performance-metrics-normality
559 | +--ro one-way-residual-bandwidth?
560 | | rt-types:bandwidth-ieee-float32
561 | +--ro one-way-residual-bandwidth-normality?
562 | | te-types:performance-metrics-normality
563 | +--ro one-way-available-bandwidth?
564 | | rt-types:bandwidth-ieee-float32
565 | +--ro one-way-available-bandwidth-normality?
566 | | te-types:performance-metrics-normality
567 | +--ro one-way-utilized-bandwidth?
568 | | rt-types:bandwidth-ieee-float32
569 | +--ro one-way-utilized-bandwidth-normality?
570 | te-types:performance-metrics-normality
571 +--ro performance-metrics-two-way
572 +--ro two-way-delay? uint32
573 +--ro two-way-delay-normality?
574 te-types:performance-metrics-normality
576 module: ietf-vn-kpi-telemetry
577 augment /vn:vn/vn:vn-list:
578 +--rw vn-scaling-intent
579 | +--rw scale-in-intent
580 | | +--rw threshold-time? uint32
581 | | +--rw cooldown-time? uint32
582 | | +--rw scaling-condition* [performance-type]
583 | | +--rw performance-type identityref
584 | | +--rw threshold-value? string
585 | | +--rw scale-in-operation-type?
586 | | scaling-criteria-operation
587 | +--rw scale-out-intent
588 | +--rw threshold-time? uint32
589 | +--rw cooldown-time? uint32
590 | +--rw scaling-condition* [performance-type]
591 | +--rw performance-type identityref
592 | +--rw threshold-value? string
593 | +--rw scale-out-operation-type?
594 | scaling-criteria-operation
595 +--ro vn-telemetry
596 +--ro performance-metrics-one-way
597 | +--ro one-way-delay? uint32
598 | +--ro one-way-delay-normality?
599 | | te-types:performance-metrics-normality
600 | +--ro one-way-residual-bandwidth?
601 | | rt-types:bandwidth-ieee-float32
602 | +--ro one-way-residual-bandwidth-normality?
603 | | te-types:performance-metrics-normality
604 | +--ro one-way-available-bandwidth?
605 | | rt-types:bandwidth-ieee-float32
606 | +--ro one-way-available-bandwidth-normality?
607 | | te-types:performance-metrics-normality
608 | +--ro one-way-utilized-bandwidth?
609 | | rt-types:bandwidth-ieee-float32
610 | +--ro one-way-utilized-bandwidth-normality?
611 | te-types:performance-metrics-normality
612 +--ro performance-metrics-two-way
613 | +--ro two-way-delay? uint32
614 | +--ro two-way-delay-normality?
615 | te-types:performance-metrics-normality
616 +--ro grouping-operation? grouping-operation
617 augment /vn:vn/vn:vn-list/vn:vn-member-list:
618 +--ro vn-member-telemetry
619 +--ro performance-metrics-one-way
620 | +--ro one-way-delay? uint32
621 | +--ro one-way-delay-normality?
622 | | te-types:performance-metrics-normality
623 | +--ro one-way-residual-bandwidth?
624 | | rt-types:bandwidth-ieee-float32
625 | +--ro one-way-residual-bandwidth-normality?
626 | | te-types:performance-metrics-normality
627 | +--ro one-way-available-bandwidth?
628 | | rt-types:bandwidth-ieee-float32
629 | +--ro one-way-available-bandwidth-normality?
630 | | te-types:performance-metrics-normality
631 | +--ro one-way-utilized-bandwidth?
632 | | rt-types:bandwidth-ieee-float32
633 | +--ro one-way-utilized-bandwidth-normality?
634 | te-types:performance-metrics-normality
635 +--ro performance-metrics-two-way
636 | +--ro two-way-delay? uint32
637 | +--ro two-way-delay-normality?
638 | te-types:performance-metrics-normality
639 +--ro te-grouped-params*
640 | -> /te:te/tunnels/tunnel/te-kpi:te-telemetry/id
641 +--ro grouping-operation? grouping-operation
643 7. YANG Data Model
645 7.1. ietf-te-kpi-telemetry model
647 The YANG code is as follows:
649 file "ietf-te-kpi-telemetry@2020-07-13.yang"
650 module ietf-te-kpi-telemetry {
651 yang-version 1.1;
652 namespace "urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry";
653 prefix te-tel;
655 /* Import inet-types */
657 import ietf-inet-types {
658 prefix inet;
659 reference
660 "RFC 6991: Common YANG Data Types";
661 }
663 /* Import TE */
665 import ietf-te {
666 prefix te;
667 reference
668 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic
669 Engineering Tunnels and Interfaces";
670 }
672 /* Import TE Common types */
674 import ietf-te-types {
675 prefix te-types;
676 reference
677 "I-D.ietf-teas-yang-te-types: Traffic Engineering Common
678 YANG Types";
679 }
681 organization
682 "IETF Traffic Engineering Architecture and Signaling (TEAS)
683 Working Group";
684 contact
685 "WG Web:
686 WG List:
687 Editor: Young Lee
688 Dhruv Dhody ";
689 description
690 "This module describes YANG data model for performance
691 monitoring telemetry for te tunnels.
693 Copyright (c) 2020 IETF Trust and the persons identified as
694 authors of the code. All rights reserved.
696 Redistribution and use in source and binary forms, with or
697 without modification, is permitted pursuant to, and subject to
698 the license terms contained in, the Simplified BSD License set
699 forth in Section 4.c of the IETF Trust's Legal Provisions
700 Relating to IETF Documents
701 (https://trustee.ietf.org/license-info).
703 This version of this YANG module is part of RFC XXXX; see the
704 RFC itself for full legal notices.
706 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
707 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
708 'MAY', and 'OPTIONAL' in this document are to be interpreted as
709 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
710 they appear in all capitals, as shown here.";
712 /* Note: The RFC Editor will replace XXXX with the number
713 assigned to the RFC once draft-ietf-teas-pm-telemetry-
714 autonomics becomes an RFC.*/
716 revision 2020-03-08 {
717 description
718 "Initial revision.";
719 reference
720 "RFC XXXX: YANG models for VN/TE Performance Monitoring
721 Telemetry and Scaling Intent Autonomics";
722 }
724 identity telemetry-param-type {
725 description
726 "Base identity for telemetry param types";
727 }
729 identity one-way-delay {
730 base telemetry-param-type;
731 description
732 "To specify average Delay in one (forward)
733 direction";
734 reference
735 "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions.
736 RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions.
737 RFC7823: Performance-Based Path Selection for Explicitly
738 Routed Label Switched Paths (LSPs) Using TE Metric
739 Extensions";
740 }
742 identity two-way-delay {
743 base telemetry-param-type;
744 description
745 "To specify average Delay in both (forward and reverse)
746 directions";
747 reference
748 "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions.
749 RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions.
750 RFC7823: Performance-Based Path Selection for Explicitly
751 Routed Label Switched Paths (LSPs) Using TE Metric
752 Extensions";
753 }
755 identity one-way-delay-variation {
756 base telemetry-param-type;
757 description
758 "To specify average Delay Variation in one (forward) direction";
759 reference
760 "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions.
761 RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions.
762 RFC7823: Performance-Based Path Selection for Explicitly
763 Routed Label Switched Paths (LSPs) Using TE Metric
764 Extensions";
765 }
767 identity two-way-delay-variation {
768 base telemetry-param-type;
769 description
770 "To specify average Delay Variation in both (forward and reverse)
771 directions";
772 reference
773 "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions.
774 RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions.
775 RFC7823: Performance-Based Path Selection for Explicitly
776 Routed Label Switched Paths (LSPs) Using TE Metric
777 Extensions";
778 }
780 identity utilized-bandwidth {
781 base telemetry-param-type;
782 description
783 "To specify utilized bandwidth over the specified source
784 and destination.";
785 reference
786 "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions.
788 RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions.
789 RFC7823: Performance-Based Path Selection for Explicitly
790 Routed Label Switched Paths (LSPs) Using TE Metric
791 Extensions";
792 }
794 identity utilized-percentage {
795 base telemetry-param-type;
796 description
797 "To specify utilization percentage of the entity
798 (e.g., tunnel, link, etc.)";
799 }
801 /* Typedef */
803 typedef telemetry-id {
804 type inet:uri;
805 description
806 "Identifier for telemetry data. The precise
807 structure of the telemetry-id will be up to the
808 implementation. The identifier SHOULD be chosen
809 such that the same telemetry data will always be
810 identified through the same identifier, even if
811 the data model is instantiated in separate
812 datastores.";
813 }
815 typedef scaling-criteria-operation {
816 type enumeration {
817 enum AND {
818 description
819 "AND operation";
820 }
821 enum OR {
822 description
823 "OR operation";
824 }
825 }
826 description
827 "Operations to analize list of scaling criterias";
828 }
830 grouping scaling-duration {
831 description
832 "Base scaling criteria durations";
833 leaf threshold-time {
834 type uint32;
835 units "seconds";
836 description
837 "The duration for which the criteria must hold true";
838 }
839 leaf cooldown-time {
840 type uint32;
841 units "seconds";
842 description
843 "The duration after a scaling-in/scaling-out action has been
844 triggered, for which there will be no further operation";
845 }
846 }
848 grouping scaling-criteria {
849 description
850 "Grouping for scaling criteria";
851 leaf performance-type {
852 type identityref {
853 base telemetry-param-type;
854 }
855 description
856 "Reference to the tunnel level telemetry type";
857 }
858 leaf threshold-value {
859 type string;
860 description
861 "Scaling threshold for the telemetry parameter type";
862 }
863 }
865 grouping scaling-in-intent {
866 description
867 "Basic scaling in intent";
868 uses scaling-duration;
869 list scaling-condition {
870 key "performance-type";
871 description
872 "Scaling conditions";
873 uses scaling-criteria;
874 leaf scale-in-operation-type {
875 type scaling-criteria-operation;
876 default "AND";
877 description
878 "Operation to be applied to check between scaling criterias
879 to check if the scale in threshold condition has been met.
880 Defaults to AND";
881 }
882 }
883 }
884 grouping scaling-out-intent {
885 description
886 "Basic scaling out intent";
887 uses scaling-duration;
888 list scaling-condition {
889 key "performance-type";
890 description
891 "Scaling conditions";
892 uses scaling-criteria;
893 leaf scale-out-operation-type {
894 type scaling-criteria-operation;
895 default "OR";
896 description
897 "Operation to be applied to check between scaling criterias
898 to check if the scale out threshold condition has been met.
899 Defauls to OR";
900 }
901 }
902 }
904 augment "/te:te/te:tunnels/te:tunnel" {
905 description
906 "Augmentation parameters for config scaling-criteria TE
907 tunnel topologies. Scale in/out criteria might be used
908 for network autonomics in order the controller to react
909 to a certain set of monitored params.";
910 container te-scaling-intent {
911 description
912 "The scaling intent";
913 container scale-in-intent {
914 description
915 "scale-in";
916 uses scaling-in-intent;
917 }
918 container scale-out-intent {
919 description
920 "scale-out";
921 uses scaling-out-intent;
922 }
923 }
924 container te-telemetry {
925 config false;
926 description
927 "Telemetry Data";
928 leaf id {
929 type telemetry-id;
930 description
931 "ID of telemetry data used for easy reference";
933 }
934 uses te-types:performance-metrics-attributes;
935 }
936 }
937 }
939
941 7.2. ietf-vn-kpi-telemetry model
943 The YANG code is as follows:
945 file "ietf-vn-kpi-telemetry@2020-07-13.yang"
946 module ietf-vn-kpi-telemetry {
947 yang-version 1.1;
948 namespace "urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry";
949 prefix vn-kpi;
951 /* Import VN */
953 import ietf-vn {
954 prefix vn;
955 reference
956 "I-D.ietf-teas-actn-vn-yang: A YANG Data Model for VN
957 Operation";
958 }
960 /* Import TE */
962 import ietf-te {
963 prefix te;
964 reference
965 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic
966 Engineering Tunnels and Interfaces";
967 }
969 /* Import TE Common types */
971 import ietf-te-types {
972 prefix te-types;
973 reference
974 "RFC 8776: Common YANG Data Types for Traffic Engineering";
975 }
977 /* Import TE KPI */
979 import ietf-te-kpi-telemetry {
980 prefix te-kpi;
981 reference
982 "RFC XXXX: YANG models for VN/TE Performance Monitoring
983 Telemetry and Scaling Intent Autonomics";
984 }
986 /* Note: The RFC Editor will replace XXXX with the number
987 assigned to this draft.*/
989 organization
990 "IETF Traffic Engineering Architecture and Signaling (TEAS)
991 Working Group";
992 contact
993 "WG Web:
994 WG List:
995 Editor: Young Lee
996 Dhruv Dhody ";
997 description
998 "This module describes YANG data models for performance
999 monitoring telemetry for Virtual Network (VN).
1001 Copyright (c) 2020 IETF Trust and the persons identified as
1002 authors of the code. All rights reserved.
1004 Redistribution and use in source and binary forms, with or
1005 without modification, is permitted pursuant to, and subject to
1006 the license terms contained in, the Simplified BSD License set
1007 forth in Section 4.c of the IETF Trust's Legal Provisions
1008 Relating to IETF Documents
1009 (https://trustee.ietf.org/license-info).
1011 This version of this YANG module is part of RFC XXXX; see the
1012 RFC itself for full legal notices.
1014 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
1015 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
1016 'MAY', and 'OPTIONAL' in this document are to be interpreted as
1017 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
1018 they appear in all capitals, as shown here.";
1020 /* Note: The RFC Editor will replace XXXX with the number
1021 assigned to the RFC once draft-lee-teas-pm-telemetry-
1022 autonomics becomes an RFC.*/
1024 revision 2020-07-13 {
1025 description
1026 "Initial revision.";
1027 reference
1028 "RFC XXXX: YANG models for VN/TE Performance Monitoring
1029 Telemetry and Scaling Intent Autonomics";
1030 }
1032 typedef grouping-operation {
1033 type enumeration {
1034 enum MINIMUM {
1035 description
1036 "Select the minimum param";
1037 }
1038 enum MAXIMUM {
1039 description
1040 "Select the maximum param";
1041 }
1042 enum MEAN {
1043 description
1044 "Select the MEAN of the params";
1045 }
1046 enum STD_DEV {
1047 description
1048 "Select the standard deviation of the monitored params";
1049 }
1050 enum AND {
1051 description
1052 "Select the AND of the params";
1053 }
1054 enum OR {
1055 description
1056 "Select the OR of the params";
1057 }
1058 }
1059 description
1060 "Operations to analize list of monitored params";
1061 }
1063 grouping vn-telemetry-param {
1064 description
1065 "augment of te-kpi:telemetry-param for VN specific params";
1066 leaf-list te-grouped-params {
1067 type leafref {
1068 path
1069 "/te:te/te:tunnels/te:tunnel/te-kpi:te-telemetry/te-kpi:id";
1070 }
1071 description
1072 "Allows the definition of a vn-telemetry param
1073 as a grouping of underlying TE params";
1074 }
1075 leaf grouping-operation {
1076 type grouping-operation;
1077 description
1078 "describes the operation to apply to
1079 te-grouped-params";
1080 }
1081 }
1083 augment "/vn:vn/vn:vn-list" {
1084 description
1085 "Augmentation parameters for state TE VN topologies.";
1086 container vn-scaling-intent {
1087 description
1088 "scaling intent";
1089 container scale-in-intent {
1090 description
1091 "VN scale-in";
1092 uses te-kpi:scaling-in-intent;
1093 }
1094 container scale-out-intent {
1095 description
1096 "VN scale-out";
1097 uses te-kpi:scaling-out-intent;
1098 }
1099 }
1100 container vn-telemetry {
1101 config false;
1102 description
1103 "VN telemetry params";
1104 uses te-types:performance-metrics-attributes;
1105 leaf grouping-operation {
1106 type grouping-operation;
1107 description
1108 "describes the operation to apply to the VN-members";
1109 }
1110 }
1111 }
1113 augment "/vn:vn/vn:vn-list/vn:vn-member-list" {
1114 description
1115 "Augmentation parameters for state TE vn member topologies.";
1116 container vn-member-telemetry {
1117 config false;
1118 description
1119 "VN member telemetry params";
1120 uses te-types:performance-metrics-attributes;
1121 uses vn-telemetry-param;
1122 }
1123 }
1124 }
1125
1127 8. Security Considerations
1129 The YANG module specified in this document defines a schema for data
1130 that is designed to be accessed via network management protocols such
1131 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
1132 is the secure transport layer, and the mandatory-to-implement secure
1133 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
1134 is HTTPS, and the mandatory-to-implement secure transport is TLS
1135 [RFC8446].
1137 The NETCONF access control model [RFC8341] provides the means to
1138 restrict access for particular NETCONF users to a preconfigured
1139 subset of all available NETCONF protocol operations and content. The
1140 NETCONF Protocol over Secure Shell (SSH) [RFC6242] describes a method
1141 for invoking and running NETCONF within a Secure Shell (SSH) session
1142 as an SSH subsystem. The Network Configuration Access Control Model
1143 (NACM) [RFC8341] provides the means to restrict access for particular
1144 NETCONF or RESTCONF users to a preconfigured subset of all available
1145 NETCONF or RESTCONF protocol operations and content.
1147 A number of configuration data nodes defined in this document are
1148 writable/deletable (i.e., "config true"). These data nodes may be
1149 considered sensitive or vulnerable in some network environments.
1151 There are a number of data nodes defined in this YANG module that are
1152 writable/creatable/deletable (i.e., config true, which is the
1153 default). These data nodes may be considered sensitive or vulnerable
1154 in some network environments. Write operations (e.g., edit-config)
1155 to these data nodes without proper protection can have a negative
1156 effect on network operations. These are the subtrees and data nodes
1157 and their sensitivity/vulnerability:
1159 o /te:te/te:tunnels/te:tunnel/te-scaling-intent/scale-in-intent
1161 o /te:te/te:tunnels/te:tunnel/te-scaling-intent/scale-out-intent
1163 o /vn:vn/vn:vn-list/vn-scaling-intent/scale-in-intent
1165 o /vn:vn/vn:vn-list/vn-scaling-intent/scale-out-intent
1167 9. IANA Considerations
1169 This document registers the following namespace URIs in the IETF XML
1170 registry [RFC3688]:
1172 --------------------------------------------------------------------
1173 URI: urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry
1174 Registrant Contact: The IESG.
1175 XML: N/A, the requested URI is an XML namespace.
1176 --------------------------------------------------------------------
1178 --------------------------------------------------------------------
1179 URI: urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry
1180 Registrant Contact: The IESG.
1181 XML: N/A, the requested URI is an XML namespace.
1182 --------------------------------------------------------------------
1184 This document registers the following YANG modules in the YANG
1185 Module.
1187 Names registry [RFC7950]:
1189 --------------------------------------------------------------------
1190 name: ietf-te-kpi-telemetry
1191 namespace: urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry
1192 prefix: te-tel
1193 reference: RFC XXXX (TDB)
1194 --------------------------------------------------------------------
1196 --------------------------------------------------------------------
1197 name: ietf-vn-kpi-telemetry
1198 namespace: urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry
1199 prefix: vn-tel
1200 reference: RFC XXXX (TDB)
1201 --------------------------------------------------------------------
1203 10. Acknowledgements
1205 We thank Rakesh Gandhi, Tarek Saad, Igor Bryskin and Kenichi Ogaki
1206 for useful discussions and their suggestions for this work.
1208 11. References
1210 11.1. Normative References
1212 [I-D.ietf-teas-actn-vn-yang]
1213 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B.
1214 Yoon, "A Yang Data Model for VN Operation", draft-ietf-
1215 teas-actn-vn-yang-08 (work in progress), March 2020.
1217 [I-D.ietf-teas-yang-te]
1218 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
1219 "A YANG Data Model for Traffic Engineering Tunnels and
1220 Interfaces", draft-ietf-teas-yang-te-23 (work in
1221 progress), March 2020.
1223 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1224 Requirement Levels", BCP 14, RFC 2119,
1225 DOI 10.17487/RFC2119, March 1997,
1226 .
1228 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1229 DOI 10.17487/RFC3688, January 2004,
1230 .
1232 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
1233 and A. Bierman, Ed., "Network Configuration Protocol
1234 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
1235 .
1237 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
1238 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
1239 .
1241 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
1242 RFC 6991, DOI 10.17487/RFC6991, July 2013,
1243 .
1245 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G.,
1246 Ceccarelli, D., and X. Zhang, "Problem Statement and
1247 Architecture for Information Exchange between
1248 Interconnected Traffic-Engineered Networks", BCP 206,
1249 RFC 7926, DOI 10.17487/RFC7926, July 2016,
1250 .
1252 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
1253 RFC 7950, DOI 10.17487/RFC7950, August 2016,
1254 .
1256 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
1257 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
1258 .
1260 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1261 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1262 May 2017, .
1264 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki,
1265 "Extensions to the Path Computation Element Communication
1266 Protocol (PCEP) to Compute Service-Aware Label Switched
1267 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September
1268 2017, .
1270 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
1271 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
1272 .
1274 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
1275 Access Control Model", STD 91, RFC 8341,
1276 DOI 10.17487/RFC8341, March 2018,
1277 .
1279 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
1280 and R. Wilton, "Network Management Datastore Architecture
1281 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
1282 .
1284 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
1285 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
1286 .
1288 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
1289 E., and A. Tripathy, "Dynamic Subscription to YANG Events
1290 and Datastores over NETCONF", RFC 8640,
1291 DOI 10.17487/RFC8640, September 2019,
1292 .
1294 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
1295 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
1296 September 2019, .
1298 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
1299 "Common YANG Data Types for Traffic Engineering",
1300 RFC 8776, DOI 10.17487/RFC8776, June 2020,
1301 .
1303 11.2. Informative References
1305 [I-D.xu-actn-perf-dynamic-service-control]
1306 Xu, Y., Zhang, G., Cheng, W., and z.
1307 zhenghaomian@huawei.com, "Use Cases and Requirements of
1308 Dynamic Service Control based on Performance Monitoring in
1309 ACTN Architecture", draft-xu-actn-perf-dynamic-service-
1310 control-03 (work in progress), April 2015.
1312 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
1313 Previdi, "OSPF Traffic Engineering (TE) Metric
1314 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
1315 .
1317 [RFC7823] Atlas, A., Drake, J., Giacalone, S., and S. Previdi,
1318 "Performance-Based Path Selection for Explicitly Routed
1319 Label Switched Paths (LSPs) Using TE Metric Extensions",
1320 RFC 7823, DOI 10.17487/RFC7823, May 2016,
1321 .
1323 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
1324 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
1325 .
1327 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
1328 Abstraction and Control of TE Networks (ACTN)", RFC 8453,
1329 DOI 10.17487/RFC8453, August 2018,
1330 .
1332 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
1333 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
1334 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
1335 2019, .
1337 Authors' Addresses
1339 Young Lee (editor)
1340 Samsung Electronics
1342 Email: younglee.tx@gmail.com
1344 Dhruv Dhody (editor)
1345 Huawei Technologies
1346 Divyashree Techno Park, Whitefield
1347 Bangalore, Karnataka 560066
1348 India
1350 Email: dhruv.ietf@gmail.com
1351 Satish Karunanithi
1352 Huawei Technologies
1353 Divyashree Techno Park, Whitefield
1354 Bangalore, Karnataka 560066
1355 India
1357 Email: satish.karunanithi@gmail.com
1359 Ricard Vilalta
1360 CTTC
1361 Centre Tecnologic de Telecomunicacions de Catalunya (CTTC/CERCA)
1362 Barcelona
1363 Spain
1365 Email: ricard.vilalta@cttc.es
1367 Daniel King
1368 Lancaster University
1370 Email: d.king@lancaster.ac.uk
1372 Daniele Ceccarelli
1373 Ericsson
1374 Torshamnsgatan,48
1375 Stockholm, Sweden
1377 Email: daniele.ceccarelli@ericsson.com