idnits 2.17.1
draft-ietf-teas-actn-pm-telemetry-autonomics-04.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 (November 1, 2020) is 1264 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-09
== 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: May 5, 2021 S. Karunanithi
6 Huawei Technologies
7 R. Vilalta
8 CTTC
9 D. King
10 Lancaster University
11 D. Ceccarelli
12 Ericsson
13 November 1, 2020
15 YANG models for VN/TE Performance Monitoring Telemetry and Scaling
16 Intent Autonomics
17 draft-ietf-teas-actn-pm-telemetry-autonomics-04
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 May 5, 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 . . . . . . . . . . . . . . . . . . . . . 26
83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
85 11.1. Normative References . . . . . . . . . . . . . . . . . . 27
86 11.2. Informative References . . . . . . . . . . . . . . . . . 29
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-11-02.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 "RFC 8776: Common YANG Data Types for Traffic Engineering";
678 }
680 organization
681 "IETF Traffic Engineering Architecture and Signaling (TEAS)
682 Working Group";
683 contact
684 "WG Web:
685 WG List:
686 Editor: Young Lee
687 Dhruv Dhody ";
688 description
689 "This module describes YANG data model for performance
690 monitoring telemetry for te tunnels.
692 Copyright (c) 2020 IETF Trust and the persons identified as
693 authors of the code. All rights reserved.
695 Redistribution and use in source and binary forms, with or
696 without modification, is permitted pursuant to, and subject to
697 the license terms contained in, the Simplified BSD License set
698 forth in Section 4.c of the IETF Trust's Legal Provisions
699 Relating to IETF Documents
700 (https://trustee.ietf.org/license-info).
702 This version of this YANG module is part of RFC XXXX; see the
703 RFC itself for full legal notices.
705 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
706 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
707 'MAY', and 'OPTIONAL' in this document are to be interpreted as
708 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
709 they appear in all capitals, as shown here.";
711 /* Note: The RFC Editor will replace XXXX with the number
712 assigned to the RFC once draft-ietf-teas-pm-telemetry-
713 autonomics becomes an RFC.*/
715 revision 2020-11-02 {
716 description
717 "Initial revision.";
718 reference
719 "RFC XXXX: YANG models for VN/TE Performance Monitoring
720 Telemetry and Scaling Intent Autonomics";
721 }
723 identity telemetry-param-type {
724 description
725 "Base identity for telemetry param types";
726 }
728 identity one-way-delay {
729 base telemetry-param-type;
730 description
731 "To specify average Delay in one (forward) direction.
733 At the VN level, it is the max delay of the VN-members.";
734 reference
735 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions.
736 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions.
737 RFC 7823: Performance-Based Path Selection for Explicitly
738 Routed Label Switched Paths (LSPs) Using TE Metric
739 Extensions";
741 }
743 identity two-way-delay {
744 base telemetry-param-type;
745 description
746 "To specify average Delay in both (forward and reverse)
747 directions.
749 At the VN level, it is the max delay of the VN-members.";
750 reference
751 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions.
752 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions.
753 RFC 7823: Performance-Based Path Selection for Explicitly
754 Routed Label Switched Paths (LSPs) Using TE Metric
755 Extensions";
756 }
758 identity one-way-delay-variation {
759 base telemetry-param-type;
760 description
761 "To specify average Delay Variation in one (forward) direction.
763 At the VN level, it is the max delay variation of the
764 VN-members.";
765 reference
766 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions.
767 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions.
768 RFC 7823: Performance-Based Path Selection for Explicitly
769 Routed Label Switched Paths (LSPs) Using TE Metric
770 Extensions";
771 }
773 identity two-way-delay-variation {
774 base telemetry-param-type;
775 description
776 "To specify average Delay Variation in both (forward and reverse)
777 directions.
779 At the VN level, it is the max delay variation of the
780 VN-members.";
781 reference
782 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions.
783 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions.
784 RFC 7823: Performance-Based Path Selection for Explicitly
785 Routed Label Switched Paths (LSPs) Using TE Metric
786 Extensions";
787 }
788 identity utilized-bandwidth {
789 base telemetry-param-type;
790 description
791 "To specify utilized bandwidth over the specified source
792 and destination.";
793 reference
794 "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions.
795 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions.
796 RFC 7823: Performance-Based Path Selection for Explicitly
797 Routed Label Switched Paths (LSPs) Using TE Metric
798 Extensions";
799 }
801 identity utilized-percentage {
802 base telemetry-param-type;
803 description
804 "To specify utilization percentage of the entity
805 (e.g., tunnel, link, etc.)";
806 }
808 /* Typedef */
810 typedef telemetry-id {
811 type inet:uri;
812 description
813 "Identifier for telemetry data. The precise
814 structure of the telemetry-id will be up to the
815 implementation. The identifier SHOULD be chosen
816 such that the same telemetry data will always be
817 identified through the same identifier, even if
818 the data model is instantiated in separate
819 datastores.";
820 }
822 typedef scaling-criteria-operation {
823 type enumeration {
824 enum AND {
825 description
826 "AND operation";
827 }
828 enum OR {
829 description
830 "OR operation";
831 }
832 }
833 description
834 "Operations to analize list of scaling criterias";
835 }
836 grouping scaling-duration {
837 description
838 "Base scaling criteria durations";
839 leaf threshold-time {
840 type uint32;
841 units "seconds";
842 description
843 "The duration for which the criteria must hold true";
844 }
845 leaf cooldown-time {
846 type uint32;
847 units "seconds";
848 description
849 "The duration after a scaling-in/scaling-out action has been
850 triggered, for which there will be no further operation";
851 }
852 }
854 grouping scaling-criteria {
855 description
856 "Grouping for scaling criteria";
857 leaf performance-type {
858 type identityref {
859 base telemetry-param-type;
860 }
861 description
862 "Reference to the tunnel level telemetry type";
863 }
864 leaf threshold-value {
865 type string;
866 description
867 "Scaling threshold for the telemetry parameter type";
868 }
869 }
871 grouping scaling-in-intent {
872 description
873 "Basic scaling in intent";
874 uses scaling-duration;
875 list scaling-condition {
876 key "performance-type";
877 description
878 "Scaling conditions";
879 uses scaling-criteria;
880 leaf scale-in-operation-type {
881 type scaling-criteria-operation;
882 default "AND";
883 description
884 "Operation to be applied to check between scaling criterias
885 to check if the scale in threshold condition has been met.
886 Defaults to AND";
887 }
888 }
889 }
891 grouping scaling-out-intent {
892 description
893 "Basic scaling out intent";
894 uses scaling-duration;
895 list scaling-condition {
896 key "performance-type";
897 description
898 "Scaling conditions";
899 uses scaling-criteria;
900 leaf scale-out-operation-type {
901 type scaling-criteria-operation;
902 default "OR";
903 description
904 "Operation to be applied to check between scaling criterias
905 to check if the scale out threshold condition has been met.
906 Defauls to OR";
907 }
908 }
909 }
911 augment "/te:te/te:tunnels/te:tunnel" {
912 description
913 "Augmentation parameters for config scaling-criteria TE
914 tunnel topologies. Scale in/out criteria might be used
915 for network autonomics in order the controller to react
916 to a certain set of monitored params.";
917 container te-scaling-intent {
918 description
919 "The scaling intent";
920 container scale-in-intent {
921 description
922 "scale-in";
923 uses scaling-in-intent;
924 }
925 container scale-out-intent {
926 description
927 "scale-out";
928 uses scaling-out-intent;
929 }
930 }
931 container te-telemetry {
932 config false;
933 description
934 "Telemetry Data";
935 leaf id {
936 type telemetry-id;
937 description
938 "ID of telemetry data used for easy reference";
939 }
940 uses te-types:performance-metrics-attributes;
941 }
942 }
943 }
945
947 7.2. ietf-vn-kpi-telemetry model
949 The YANG code is as follows:
951 file "ietf-vn-kpi-telemetry@2020-11-02.yang"
952 module ietf-vn-kpi-telemetry {
953 yang-version 1.1;
954 namespace "urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry";
955 prefix vn-kpi;
957 /* Import VN */
959 import ietf-vn {
960 prefix vn;
961 reference
962 "I-D.ietf-teas-actn-vn-yang: A YANG Data Model for VN
963 Operation";
964 }
966 /* Import TE */
968 import ietf-te {
969 prefix te;
970 reference
971 "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic
972 Engineering Tunnels and Interfaces";
973 }
975 /* Import TE Common types */
977 import ietf-te-types {
978 prefix te-types;
979 reference
980 "RFC 8776: Common YANG Data Types for Traffic Engineering";
981 }
983 /* Import TE KPI */
985 import ietf-te-kpi-telemetry {
986 prefix te-kpi;
987 reference
988 "RFC XXXX: YANG models for VN/TE Performance Monitoring
989 Telemetry and Scaling Intent Autonomics";
990 }
992 /* Note: The RFC Editor will replace XXXX with the number
993 assigned to this draft.*/
995 organization
996 "IETF Traffic Engineering Architecture and Signaling (TEAS)
997 Working Group";
998 contact
999 "WG Web:
1000 WG List:
1001 Editor: Young Lee
1002 Dhruv Dhody ";
1003 description
1004 "This module describes YANG data models for performance
1005 monitoring telemetry for Virtual Network (VN).
1007 Copyright (c) 2020 IETF Trust and the persons identified as
1008 authors of the code. All rights reserved.
1010 Redistribution and use in source and binary forms, with or
1011 without modification, is permitted pursuant to, and subject to
1012 the license terms contained in, the Simplified BSD License set
1013 forth in Section 4.c of the IETF Trust's Legal Provisions
1014 Relating to IETF Documents
1015 (https://trustee.ietf.org/license-info).
1017 This version of this YANG module is part of RFC XXXX; see the
1018 RFC itself for full legal notices.
1020 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
1021 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
1022 'MAY', and 'OPTIONAL' in this document are to be interpreted as
1023 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
1024 they appear in all capitals, as shown here.";
1026 /* Note: The RFC Editor will replace XXXX with the number
1027 assigned to the RFC once draft-lee-teas-pm-telemetry-
1028 autonomics becomes an RFC.*/
1030 revision 2020-11-02 {
1031 description
1032 "Initial revision.";
1033 reference
1034 "RFC XXXX: YANG models for VN/TE Performance Monitoring
1035 Telemetry and Scaling Intent Autonomics";
1036 }
1038 typedef grouping-operation {
1039 type enumeration {
1040 enum MINIMUM {
1041 description
1042 "Select the minimum param";
1043 }
1044 enum MAXIMUM {
1045 description
1046 "Select the maximum param";
1047 }
1048 enum MEAN {
1049 description
1050 "Select the MEAN of the params";
1051 }
1052 enum STD_DEV {
1053 description
1054 "Select the standard deviation of the monitored params";
1055 }
1056 enum AND {
1057 description
1058 "Select the AND of the params";
1059 }
1060 enum OR {
1061 description
1062 "Select the OR of the params";
1063 }
1064 }
1065 description
1066 "Operations to analize list of monitored params";
1067 }
1069 grouping vn-telemetry-param {
1070 description
1071 "augment of te-kpi:telemetry-param for VN specific params";
1072 leaf-list te-grouped-params {
1073 type leafref {
1074 path
1075 "/te:te/te:tunnels/te:tunnel/te-kpi:te-telemetry/te-kpi:id";
1077 }
1078 description
1079 "Allows the definition of a vn-telemetry param
1080 as a grouping of underlying TE params";
1081 }
1082 leaf grouping-operation {
1083 type grouping-operation;
1084 description
1085 "describes the operation to apply to
1086 te-grouped-params";
1087 }
1088 }
1090 augment "/vn:vn/vn:vn-list" {
1091 description
1092 "Augmentation parameters for state TE VN topologies.";
1093 container vn-scaling-intent {
1094 description
1095 "scaling intent";
1096 container scale-in-intent {
1097 description
1098 "VN scale-in";
1099 uses te-kpi:scaling-in-intent;
1100 }
1101 container scale-out-intent {
1102 description
1103 "VN scale-out";
1104 uses te-kpi:scaling-out-intent;
1105 }
1106 }
1107 container vn-telemetry {
1108 config false;
1109 description
1110 "VN telemetry params";
1111 uses te-types:performance-metrics-attributes;
1112 leaf grouping-operation {
1113 type grouping-operation;
1114 description
1115 "describes the operation to apply to the VN-members";
1116 }
1117 }
1118 }
1120 augment "/vn:vn/vn:vn-list/vn:vn-member-list" {
1121 description
1122 "Augmentation parameters for state TE vn member topologies.";
1123 container vn-member-telemetry {
1124 config false;
1125 description
1126 "VN member telemetry params";
1127 uses te-types:performance-metrics-attributes;
1128 uses vn-telemetry-param;
1129 }
1130 }
1131 }
1133
1135 8. Security Considerations
1137 The YANG module specified in this document defines a schema for data
1138 that is designed to be accessed via network management protocols such
1139 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
1140 is the secure transport layer, and the mandatory-to-implement secure
1141 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
1142 is HTTPS, and the mandatory-to-implement secure transport is TLS
1143 [RFC8446].
1145 The NETCONF access control model [RFC8341] provides the means to
1146 restrict access for particular NETCONF users to a preconfigured
1147 subset of all available NETCONF protocol operations and content. The
1148 NETCONF Protocol over Secure Shell (SSH) [RFC6242] describes a method
1149 for invoking and running NETCONF within a Secure Shell (SSH) session
1150 as an SSH subsystem. The Network Configuration Access Control Model
1151 (NACM) [RFC8341] provides the means to restrict access for particular
1152 NETCONF or RESTCONF users to a preconfigured subset of all available
1153 NETCONF or RESTCONF protocol operations and content.
1155 A number of configuration data nodes defined in this document are
1156 writable/deletable (i.e., "config true"). These data nodes may be
1157 considered sensitive or vulnerable in some network environments.
1159 There are a number of data nodes defined in this YANG module that are
1160 writable/creatable/deletable (i.e., config true, which is the
1161 default). These data nodes may be considered sensitive or vulnerable
1162 in some network environments. Write operations (e.g., edit-config)
1163 to these data nodes without proper protection can have a negative
1164 effect on network operations. These are the subtrees and data nodes
1165 and their sensitivity/vulnerability:
1167 o /te:te/te:tunnels/te:tunnel/te-scaling-intent/scale-in-intent
1169 o /te:te/te:tunnels/te:tunnel/te-scaling-intent/scale-out-intent
1171 o /vn:vn/vn:vn-list/vn-scaling-intent/scale-in-intent
1172 o /vn:vn/vn:vn-list/vn-scaling-intent/scale-out-intent
1174 9. IANA Considerations
1176 This document registers the following namespace URIs in the IETF XML
1177 registry [RFC3688]:
1179 --------------------------------------------------------------------
1180 URI: urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry
1181 Registrant Contact: The IESG.
1182 XML: N/A, the requested URI is an XML namespace.
1183 --------------------------------------------------------------------
1185 --------------------------------------------------------------------
1186 URI: urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry
1187 Registrant Contact: The IESG.
1188 XML: N/A, the requested URI is an XML namespace.
1189 --------------------------------------------------------------------
1191 This document registers the following YANG modules in the YANG
1192 Module.
1194 Names registry [RFC7950]:
1196 --------------------------------------------------------------------
1197 name: ietf-te-kpi-telemetry
1198 namespace: urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry
1199 prefix: te-tel
1200 reference: RFC XXXX (TBD)
1201 --------------------------------------------------------------------
1203 --------------------------------------------------------------------
1204 name: ietf-vn-kpi-telemetry
1205 namespace: urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry
1206 prefix: vn-tel
1207 reference: RFC XXXX (TBD)
1208 --------------------------------------------------------------------
1210 10. Acknowledgements
1212 We thank Rakesh Gandhi, Tarek Saad, Igor Bryskin and Kenichi Ogaki
1213 for useful discussions and their suggestions for this work.
1215 11. References
1216 11.1. Normative References
1218 [I-D.ietf-teas-actn-vn-yang]
1219 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B.
1220 Yoon, "A YANG Data Model for VN Operation", draft-ietf-
1221 teas-actn-vn-yang-09 (work in progress), July 2020.
1223 [I-D.ietf-teas-yang-te]
1224 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
1225 "A YANG Data Model for Traffic Engineering Tunnels, Label
1226 Switched Paths and Interfaces", draft-ietf-teas-yang-te-25
1227 (work in progress), July 2020.
1229 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1230 Requirement Levels", BCP 14, RFC 2119,
1231 DOI 10.17487/RFC2119, March 1997,
1232 .
1234 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1235 DOI 10.17487/RFC3688, January 2004,
1236 .
1238 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
1239 and A. Bierman, Ed., "Network Configuration Protocol
1240 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
1241 .
1243 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
1244 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
1245 .
1247 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
1248 RFC 6991, DOI 10.17487/RFC6991, July 2013,
1249 .
1251 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G.,
1252 Ceccarelli, D., and X. Zhang, "Problem Statement and
1253 Architecture for Information Exchange between
1254 Interconnected Traffic-Engineered Networks", BCP 206,
1255 RFC 7926, DOI 10.17487/RFC7926, July 2016,
1256 .
1258 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
1259 RFC 7950, DOI 10.17487/RFC7950, August 2016,
1260 .
1262 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
1263 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
1264 .
1266 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1267 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1268 May 2017, .
1270 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki,
1271 "Extensions to the Path Computation Element Communication
1272 Protocol (PCEP) to Compute Service-Aware Label Switched
1273 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September
1274 2017, .
1276 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
1277 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
1278 .
1280 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
1281 Access Control Model", STD 91, RFC 8341,
1282 DOI 10.17487/RFC8341, March 2018,
1283 .
1285 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
1286 and R. Wilton, "Network Management Datastore Architecture
1287 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
1288 .
1290 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
1291 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
1292 .
1294 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
1295 E., and A. Tripathy, "Dynamic Subscription to YANG Events
1296 and Datastores over NETCONF", RFC 8640,
1297 DOI 10.17487/RFC8640, September 2019,
1298 .
1300 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
1301 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
1302 September 2019, .
1304 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
1305 "Common YANG Data Types for Traffic Engineering",
1306 RFC 8776, DOI 10.17487/RFC8776, June 2020,
1307 .
1309 11.2. Informative References
1311 [I-D.xu-actn-perf-dynamic-service-control]
1312 Xu, Y., Zhang, G., Cheng, W., and z.
1313 zhenghaomian@huawei.com, "Use Cases and Requirements of
1314 Dynamic Service Control based on Performance Monitoring in
1315 ACTN Architecture", draft-xu-actn-perf-dynamic-service-
1316 control-03 (work in progress), April 2015.
1318 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
1319 Previdi, "OSPF Traffic Engineering (TE) Metric
1320 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
1321 .
1323 [RFC7823] Atlas, A., Drake, J., Giacalone, S., and S. Previdi,
1324 "Performance-Based Path Selection for Explicitly Routed
1325 Label Switched Paths (LSPs) Using TE Metric Extensions",
1326 RFC 7823, DOI 10.17487/RFC7823, May 2016,
1327 .
1329 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
1330 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
1331 .
1333 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
1334 Abstraction and Control of TE Networks (ACTN)", RFC 8453,
1335 DOI 10.17487/RFC8453, August 2018,
1336 .
1338 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
1339 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
1340 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
1341 2019, .
1343 Authors' Addresses
1345 Young Lee (editor)
1346 Samsung Electronics
1348 Email: younglee.tx@gmail.com
1349 Dhruv Dhody (editor)
1350 Huawei Technologies
1351 Divyashree Techno Park, Whitefield
1352 Bangalore, Karnataka 560066
1353 India
1355 Email: dhruv.ietf@gmail.com
1357 Satish Karunanithi
1358 Huawei Technologies
1359 Divyashree Techno Park, Whitefield
1360 Bangalore, Karnataka 560066
1361 India
1363 Email: satish.karunanithi@gmail.com
1365 Ricard Vilalta
1366 CTTC
1367 Centre Tecnologic de Telecomunicacions de Catalunya (CTTC/CERCA)
1368 Barcelona
1369 Spain
1371 Email: ricard.vilalta@cttc.es
1373 Daniel King
1374 Lancaster University
1376 Email: d.king@lancaster.ac.uk
1378 Daniele Ceccarelli
1379 Ericsson
1380 Torshamnsgatan,48
1381 Stockholm, Sweden
1383 Email: daniele.ceccarelli@ericsson.com