idnits 2.17.1
draft-ietf-teas-actn-pm-telemetry-autonomics-00.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:
----------------------------------------------------------------------------
== The page length should not exceed 58 lines per page, but there was 3
longer pages, the longest (page 14) being 61 lines
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There is 1 instance of too long lines in the document, the longest one
being 1 character in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (July 1, 2019) is 1761 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: 'This I-D' is mentioned on line 208, but not defined
== Unused Reference: 'RFC7471' is defined on line 1243, but no explicit
reference was found in the text
== Unused Reference: 'RFC7823' is defined on line 1247, but no explicit
reference was found in the text
== Unused Reference: 'RFC8570' is defined on line 1277, but no explicit
reference was found in the text
Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 TEAS Working Group Y. Lee (Editor)
2 Internet Draft Futurewei
3 Intended Status: Standard Track
4 Expires: January 1, 2020 Dhruv Dhody
5 ` Satish Karunanithi
6 Huawei
8 Ricard Vilalta
9 CTTC
11 Daniel King
12 Lancaster University
14 Daniele Ceccarelli
15 Ericsson
17 July 1, 2019
19 YANG models for VN & TE Performance Monitoring Telemetry and Scaling
20 Intent Autonomics
22 draft-ietf-teas-actn-pm-telemetry-autonomics-00
24 Status of this Memo
26 This Internet-Draft is submitted to IETF in full conformance with
27 the provisions of BCP 78 and BCP 79.
29 Internet-Drafts are working documents of the Internet Engineering
30 Task Force (IETF), its areas, and its working groups. Note that
31 other groups may also distribute working documents as Internet-
32 Drafts.
34 Internet-Drafts are draft documents valid for a maximum of six
35 months and may be updated, replaced, or obsoleted by other documents
36 at any time. It is inappropriate to use Internet-Drafts as
37 reference material or to cite them other than as "work in progress."
39 The list of current Internet-Drafts can be accessed at
40 http://www.ietf.org/ietf/1id-abstracts.txt
42 The list of Internet-Draft Shadow Directories can be accessed at
43 http://www.ietf.org/shadow.html.
45 This Internet-Draft will expire on January 1, 2020.
47 Copyright Notice
48 Copyright (c) 2019 IETF Trust and the persons identified as the
49 document authors. All rights reserved.
51 This document is subject to BCP 78 and the IETF Trust's Legal
52 Provisions Relating to IETF Documents
53 (http://trustee.ietf.org/license-info) in effect on the date of
54 publication of this document. Please review these documents
55 carefully, as they describe your rights and restrictions with
56 respect to this document. Code Components extracted from this
57 document must include Simplified BSD License text as described in
58 Section 4.e of the Trust Legal Provisions and are provided without
59 warranty as described in the Simplified BSD License.
61 Abstract
63 This document provides YANG data models that describe performance
64 monitoring telemetry and scaling intent mechanism for TE-tunnels and
65 Virtual Networks (VN).
67 The models presented in this draft allow customers to subscribe to
68 and monitor their key performance data of their interest on the
69 level of TE-tunnel or VN. The models also provide customers with the
70 ability to program autonomic scaling intent mechanism on the level
71 of TE-tunnel as well as VN.
73 Table of Contents
75 1. Introduction...................................................3
76 1.1. Terminology...............................................4
77 1.2. Tree diagram..............................................5
78 1.3. Prefixes in Data Node Names...............................5
79 2. Use-Cases......................................................5
80 3. Design of the Data Models......................................7
81 3.1. TE KPI Telemetry Model....................................7
82 3.2. VN KPI Telemetry Model....................................8
83 4. Autonomic Scaling Intent Mechanism.............................9
84 5. Notification..................................................11
85 5.1. YANG Push Subscription Examples..........................11
86 6. YANG Data Tree................................................13
87 7. Yang Data Model...............................................15
88 7.1. ietf-te-kpi-telemetry model..............................15
89 7.2. ietf-vn-kpi-telemetry model..............................21
91 8. Security Considerations.......................................25
92 9. IANA Considerations...........................................26
93 10. Acknowledgements.............................................27
94 11. References...................................................27
95 11.1. Normative References....................................27
96 11.2. Informative References..................................28
97 12. Contributors.................................................29
98 Authors' Addresses...............................................29
100 1. Introduction
102 The YANG model discussed in [VN] is used to operate customer-driven
103 Virtual Networks (VNs) during the VN instantiation, VN computation,
104 and its life-cycle service management and operations. YANG model
105 discussed in [TE-Tunnel] is used to operate TE-tunnels during the
106 tunnel instantiation, and its life-cycle management and operations.
108 The models presented in this draft allow the applications hosted by
109 the customers to subscribe to and monitor their key performance data
110 of their interest on the level of VN [VN] or TE-tunnel [TE-Tunnel].
111 The key characteristic of the models presented in this document is a
112 top-down programmability that allows the applications hosted by the
113 customers to subscribe to and monitor key performance data of their
114 interest and autonomic scaling intent mechanism on the level of VN
115 as well as TE-tunnel.
117 According to the classification of [RFC8309], the YANG data models
118 presented in this document can be classified as customer service
119 models, which is mapped to CMI (Customer Network Controller (CNC)-
120 Multi-Domain Service Coordinator (MSDC) interface) of ACTN
121 [RFC8453].
123 [RFC8233] describes key network performance data to be considered
124 for end-to-end path computation in TE networks. Key performance
125 indicator (KPI) is a term that describes critical performance data
126 that may affect VN/TE-tunnel service. The services provided can be
127 optimized to meet the requirements (such as traffic patterns,
128 quality, and reliability) of the applications hosted by the
129 customers.
131 This document provides YANG data models generically applicable to
132 any VN/TE-Tunnel service clients to provide an ability to program
133 their customized performance monitoring subscription and publication
134 data models and automatic scaling in/out intent data models. These
135 models can be utilized by a client network controller to initiate
136 these capability to a transport network controller communicating
137 with the client controller via a NETCONF [RFC8341] or a RESTCONF
138 [RFC8040] interface.
140 The term performance monitoring being used in this document is
141 different from the term that has been used in transport networks for
142 many years. Performance monitoring in this document refers to
143 subscription and publication of streaming telemetry data.
144 Subscription is initiated by the client (e.g., CNC) while
145 publication is provided by the network (e.g., MDSC/PNC) based on the
146 client's subscription. As the scope of performance monitoring in
147 this document is telemetry data on the level of client's VN or TE-
148 tunnel, the entity interfacing the client (e.g., MDSC) has to
149 provide VN or TE-tunnel level information. This would require
150 controller capability to derive VN or TE-tunnel level performance
151 data based on lower-level data collected via PM counters in the
152 Network Elements (NE). How the controller entity derives such
153 customized level data (i.e., VN or TE-tunnel level) is out of the
154 scope of this document.
156 The data model includes configuration and state data according to
157 the new Network Management Datastore Architecture [RFC8342].
159 1.1. Terminology
161 Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used
162 in this document.
164 Key Performance Data: This refers to a set of data the customer is
165 interested in monitoring for their instantiated VNs or TE-tunnels.
166 Key performance data and key performance indicators are inter-
167 exchangeable in this draft.
169 Scaling: This refers to the network ability to re-shape its own
170 resources. Scale out refers to improve network performance by
171 increasing the allocated resources, while scale in refers to
172 decrease the allocated resources, typically because the existing
173 resources are unnecessary.
175 Scaling Intent: To declare scaling conditions, scaling intent is
176 used. Specifically, scaling intent refers to the intent expressed by
177 the client that allows the client to program/configure conditions of
178 their key performance data either for scaling out or scaling in.
179 Various conditions can be set for scaling intent on either VN or TE-
180 tunnel level.
182 Network Autonomics: This refers to the network automation capability
183 that allows client to initiate scaling intent mechanisms and
184 provides the client with the status of the adjusted network
185 resources based on the client's scaling intent in an automated
186 fashion.
188 1.2. Tree diagram
190 A simplified graphical representation of the data model is used in
191 Section 5 of this this document. The meaning of the symbols in
192 these diagrams is defined in [RFC8340].
194 1.3. Prefixes in Data Node Names
196 In this document, names of data nodes and other data model objects
197 are prefixed using the standard prefix associated with the
198 corresponding YANG imported modules, as shown in Table 1.
200 +---------+------------------------------+-----------------+
201 | Prefix | YANG module | Reference |
202 +---------+------------------------------+-----------------+
203 | rt | ietf-routing-types | [RFC8294] |
204 | te | ietf-te | [TE-Tunnel] |
205 | te-types| ietf-te-types | [TE-Types] |
206 | te-tel | ietf-te-kpi-telemetry | [This I-D] |
207 | vn | ietf-vn | [VN] |
208 | vn-tel | ietf-vn-kpi-telemetry | [This I-D] |
209 +---------+------------------------------+-----------------+
211 Table 1: Prefixes and corresponding YANG modules
213 2. Use-Cases
215 [PERF] describes use-cases relevant to this draft. It introduces the
216 dynamic creation, modification and optimization of services based on
217 the performance monitoring. Figure 1 shows a high-level workflows
218 for dynamic service control based on traffic monitoring.
220 +----------------------------------------------+
221 | Client +-----------------------------+ |
222 | | Dynamic Service Control APP | |
223 | +-----------------------------+ |
224 +----------------------------------------------+
225 1.Traffic| /|\4.Traffic | /|\
226 Monitor& | | Monitor | | 8.Traffic
227 Optimize | | Result 5.Service | | modify &
228 Policy | | modify& | | optimize
229 \|/ | optimize Req.\|/ | result
230 +----------------------------------------------+
231 | Orchestrator |
232 | +-------------------------------+ |
233 | |Dynamic Service Control Agent | |
234 | +-------------------------------+ |
235 | +---------------+ +-------------------+ |
236 | | Flow Optimize | | vConnection Agent | |
237 | +---------------+ +-------------------+ |
238 +----------------------------------------------+
239 2. Path | /|\3.Traffic | /|\
240 Monitor | | Monitor | |7.Path
241 Request | | Result 6.Path | | modify &
242 | | modify& | | optimize
243 \|/ | optimize Req.\|/ | result
244 +----------------------------------------------+
245 | Network SDN Controller |
246 | +----------------------+ +-----------------+|
247 | | Network Provisioning | |Abstract Topology||
248 | +----------------------+ +-----------------+|
249 | +------------------+ +--------------------+ |
250 | |Network Monitoring| |Physical Topology DB| |
251 | +------------------+ +--------------------+ |
252 +----------------------------------------------+
254 Figure 1 Workflows for dynamic service control based on traffic
255 monitoring
257 Some of the key points from [PERF] are as follows:
259 . Network traffic monitoring is important to facilitate automatic
260 discovery of the imbalance of network traffic, and initiate the
261 network optimization, thus helping the network operator or the
262 virtual network service provider to use the network more
263 efficiently and save the Capital Expense (CAPEX) and the
264 Operating Expense (OPEX).
266 . Customer services have various Service Level Agreement (SLA)
267 requirements, such as service availability, latency, latency
268 jitter, packet loss rate, Bit Error Rate (BER), etc. The
269 transport network can satisfy service availability and BER
270 requirements by providing different protection and restoration
271 mechanisms. However, for other performance parameters, there
272 are no such mechanisms. In order to provide high quality
273 services according to customer SLA, one possible solution is to
274 measure the SLA related performance parameters, and dynamically
275 provision and optimize services based on the performance
276 monitoring results.
277 . Performance monitoring in a large scale network could generate
278 a huge amount of performance information. Therefore, the
279 appropriate way to deliver the information in the client and
280 network interfaces should be carefully considered.
282 3. Design of the Data Models
284 The YANG models developed in this document describe two models:
286 (i) TE KPI Telemetry Model which provides the TE-Tunnel level of
287 performance monitoring mechanism and scaling intent mechanism
288 that allows scale in/out programming by the customer. (See
289 Section 3.1 & 7.1 for details).
291 (ii) VN KPI Telemetry Model which provides the VN level of the
292 aggregated performance monitoring mechanism and scaling
293 intent mechanism that allows scale in/out programming by the
294 customer (See Section 3.2 & 7.2 for details).
296 3.1. TE KPI Telemetry Model
298 This module describes performance telemetry for TE-tunnel model. The
299 telemetry data is augmented to tunnel state. This module also
300 allows autonomic traffic engineering scaling intent configuration
301 mechanism on the TE-tunnel level. Various conditions can be set for
302 auto-scaling based on the telemetry data (See Section 5 for details)
304 The TE KPI Telemetry Model augments the TE-Tunnel Model to enhance
305 TE performance monitoring capability. This monitoring capability
306 will facilitate proactive re-optimization and reconfiguration of TEs
307 based on the performance monitoring data collected via the TE KPI
308 Telemetry YANG model.
310 +------------+ +--------------+
311 | TE-Tunnel | | TE KPI |
312 | Model |<---------| Telemetry |
313 +------------+ augments | Model |
314 +--------------+
316 3.2. VN KPI Telemetry Model
318 This module describes performance telemetry for VN model. The
319 telemetry data is augmented both at the VN Level as well as
320 individual VN member level. This module also allows autonomic
321 traffic engineering scaling intent configuration mechanism on the VN
322 level. Scale in/out criteria might be used for network autonomics in
323 order the controller to react to a certain set of variations in
324 monitored parameters (See Section 4 for illustrations).
326 Moreover, this module also provides mechanism to define aggregated
327 telemetry parameters as a grouping of underlying VN level telemetry
328 parameters. Grouping operation (such as maximum, mean) could be set
329 at the time of configuration. For example, if maximum grouping
330 operation is used for delay at the VN level, the VN telemetry data
331 is reported as the maximum {delay_vn_member_1, delay_vn_member_2,..
332 delay_vn_member_N}. Thus, this telemetry abstraction mechanism
333 allows the grouping of a certain common set of telemetry values
334 under a grouping operation. This can be done at the VN-member level
335 to suggest how the E2E telemetry be inferred from the per domain
336 tunnel created and monitored by PNCs. One proposed example is the
337 following:
339 +------------------------------------------------------------+
340 | Client |
341 | |
342 +------------------------------------------------------------+
344 1.Client sets the | /|\ 2. Orchestrator pushes:
345 grouping op, and | |
346 subscribes to the | | VN level telemetry for
347 VN level telemetry for | | - VN Utilized-bw-percentage
348 Delay and | | (Minimum across VN Members)
349 Utilized-bw-pecentage | | - VN Delay (Maximum across VN
350 \|/ | Members)
351 +------------------------------------------------------------+
352 | Orchestrator |
353 | |
354 +------------------------------------------------------------+
356 The VN Telemetry Model augments the basic VN model to enhance VN
357 monitoring capability. This monitoring capability will facilitate
358 proactive re-optimization and reconfiguration of VNs based on the
359 performance monitoring data collected via the VN Telemetry YANG
360 model.
362 +----------+ +--------------+
363 | VN | augments | VN |
364 | Model |<---------| Telemetry |
365 +----------+ | Model |
366 +--------------+
368 4. Autonomic Scaling Intent Mechanism
370 Scaling intent configuration mechanism allows the client to
371 configure automatic scale-in and scale-out mechanisms on both the
372 TE-tunnel and the VN level. Various conditions can be set for auto-
373 scaling based on the PM telemetry data.
375 There are a number of parameters involved in the mechanism:
377 . scale-out-intent or scale-in-intent: whether to scale-out or
378 scale-in.
379 . performance-type: performance metric type (e.g., one-way-delay,
380 one-way-delay-min, one-way-delay-max, two-way-delay, two-way-
381 delay-min, two-way-delay-max, utilized bandwidth, etc.)
383 . threshold-value: the threshold value for a certain performance-
384 type that triggers scale-in or scale-out.
385 . scaling-operation-type: in case where scaling condition can be
386 set with one or more performance types, then scaling-operation-
387 type (AND, OR, MIN, MAX, etc.) is applied to these selected
388 performance types and its threshold values.
389 . Threshold-time: the duration for which the criteria must hold
390 true.
391 . Cooldown-time: the duration after a scaling action has been
392 triggered, for which there will be no further operation.
394 The following tree is a part of ietf-te-kpi-telemetry tree whose
395 model is presented in full detail in Sections 6 & 7.
397 module: ietf-te-kpi-telemetry
398 augment /te:te/te:tunnels/te:tunnel:
399 +-rw te-scaling-intent
400 | +-rw scale-in-intent
401 | | +-rw threshold-time? uint32
402 | | +-rw cooldown-time? uint32
403 | | +-rw scale-in-operation-type? scaling-criteria-operation
404 | | +-rw scaling-condition* [performance-type]
405 | | +-rw performance-type identityref
406 | | +-rw threshold-value? string
407 | | +-rw te-telemetry-tunnel-ref?
408 -> /te:te/tunnels/tunnel/name
409 | +-rw scale-out-intent
410 | +-rw threshold-time? uint32
411 | +-rw cooldown-time? uint32
412 | +-rw scale-out-operation-type? scaling-criteria-operation
413 | +-rw scaling-condition* [performance-type]
414 | +-rw performance-type identityref
415 | +-rw threshold-value? string
416 | +-rw te-telemetry-tunnel-ref?
417 -> /te:te/tunnels/tunnel/name
419 Let say the client wants to set the scaling out operation based on
420 two performance-types (e.g., two-way-delay and utilized-bandwidth
421 for a te-tunnel), it can be done as follows:
423 . Set Threshold-time: x (sec) (duration for which the criteria
424 must hold true)
426 . Set Cooldown-time: y (sec) (the duration after a scaling
427 action has been triggered, for which there will be no further
428 operation)
429 . Set AND for the scale-out-operation-type
431 In the scaling condition's list, the following two components can be
432 set:
434 List 1: Scaling Condition for Two-way-delay
436 . performance type: Two-way-delay
437 . threshold-value: z milli-seconds
439 List 2: Scaling Condition for Utilized bandwidth
441 . performance type: Utilized bandwidth
442 . threshold-value: w megabytes
444 5. Notification
446 This model does not define specific notifications. To enable
447 notifications, the mechanism defined in [YANG-PUSH]
448 and [Event-Notification] can be used. This mechanism currently
449 allows the user to:
451 . Subscribe to notifications on a per client basis.
453 . Specify subtree filters or xpath filters so that only interested
454 contents will be sent.
456 . Specify either periodic or on-demand notifications.
458 5.1. YANG Push Subscription Examples
460 [YANG-PUSH] allows subscriber applications to request a continuous,
461 customized stream of updates from a YANG datastore.
463 Below example shows the way for a client to subscribe to the
464 telemetry information for a particular tunnel (Tunnel1). The
465 telemetry parameter that the client is interested in is one-way-
466 delay.
468
470
472
473
474
475
476 Tunnel1
477
478
479
481
482
483
484
485
486
487
488 500
489 encode-xml
490
491
493 This example shows the way for a client to subscribe to the
494 telemetry information for all VNs. The telemetry parameter that the
495 client is interested in is one-way-delay and one-way-utilized-
496 bandwidth.
498
500
502
503
504
505
506
507
508
510
511
512
513
514
515
516
517 500
518
519
521 6. YANG Data Tree
523 module: ietf-te-kpi-telemetry
524 augment /te:te/te:tunnels/te:tunnel:
525 +--rw te-scaling-intent
526 | +--rw scale-in-intent
527 | | +--rw threshold-time? uint32
528 | | +--rw cooldown-time? uint32
529 | | +--rw scale-in-operation-type? scaling-criteria-operation
530 | | +--rw scaling-condition* [performance-type]
531 | | +--rw performance-type identityref
532 | | +--rw threshold-value? string
533 | | +--rw te-telemetry-tunnel-ref?
534 | | -> /te:te/tunnels/tunnel/name
535 | +--rw scale-out-intent
536 | +--rw threshold-time? uint32
537 | +--rw cooldown-time? uint32
538 | +--rw scale-out-operation-type? scaling-criteria-operation
539 | +--rw scaling-condition* [performance-type]
540 | +--rw performance-type identityref
541 | +--rw threshold-value? string
542 | +--rw te-telemetry-tunnel-ref?
543 | -> /te:te/tunnels/tunnel/name
544 +--ro te-telemetry
545 +--ro id? string
546 +--ro performance-metrics-one-way
547 | +--ro one-way-delay? uint32
548 | +--ro one-way-delay-normality?
549 | | te-types:performance-metrics-normality
550 | +--ro one-way-residual-bandwidth?
551 | | rt-types:bandwidth-ieee-float32
552 | +--ro one-way-residual-bandwidth-normality?
553 | | te-types:performance-metrics-normality
554 | +--ro one-way-available-bandwidth?
555 | | rt-types:bandwidth-ieee-float32
556 | +--ro one-way-available-bandwidth-normality?
557 | | te-types:performance-metrics-normality
558 | +--ro one-way-utilized-bandwidth?
559 | | rt-types:bandwidth-ieee-float32
560 | +--ro one-way-utilized-bandwidth-normality?
561 | te-types:performance-metrics-normality
562 +--ro performance-metrics-two-way
563 | +--ro two-way-delay? uint32
564 | +--ro two-way-delay-normality?
565 | te-types:performance-metrics-normality
566 +--ro te-ref?
567 -> /te:te/tunnels/tunnel/name
569 module: ietf-vn-kpi-telemetry
570 augment /vn:vn/vn:vn-list:
572 +--rw vn-scaling-intent
573 | +--rw scale-in-intent
574 | | +--rw threshold-time? uint32
575 | | +--rw cooldown-time? uint32
576 | | +--rw scale-in-operation-type? scaling-criteria-operation
577 | | +--rw scaling-condition* [performance-type]
578 | | +--rw performance-type identityref
579 | | +--rw threshold-value? string
580 | | +--rw te-telemetry-tunnel-ref?
581 | | -> /te:te/tunnels/tunnel/name
582 | +--rw scale-out-intent
583 | +--rw threshold-time? uint32
584 | +--rw cooldown-time? uint32
585 | +--rw scale-out-operation-type? scaling-criteria-operation
586 | +--rw scaling-condition* [performance-type]
587 | +--rw performance-type identityref
588 | +--rw threshold-value? string
589 | +--rw te-telemetry-tunnel-ref?
590 | -> /te:te/tunnels/tunnel/name
591 +--ro vn-telemetry
592 +--ro performance-metrics-one-way
593 | +--ro one-way-delay? uint32
594 | +--ro one-way-delay-normality?
595 | | te-types:performance-metrics-normality
596 | +--ro one-way-residual-bandwidth?
597 | | rt-types:bandwidth-ieee-float32
598 | +--ro one-way-residual-bandwidth-normality?
599 | | te-types:performance-metrics-normality
600 | +--ro one-way-available-bandwidth?
601 | | rt-types:bandwidth-ieee-float32
602 | +--ro one-way-available-bandwidth-normality?
603 | | te-types:performance-metrics-normality
604 | +--ro one-way-utilized-bandwidth?
605 | | rt-types:bandwidth-ieee-float32
606 | +--ro one-way-utilized-bandwidth-normality?
607 | te-types:performance-metrics-normality
608 +--ro performance-metrics-two-way
609 | +--ro two-way-delay? uint32
610 | +--ro two-way-delay-normality?
611 | te-types:performance-metrics-normality
612 +--ro grouping-operation? grouping-operation
613 augment /vn:vn/vn:vn-list/vn:vn-member-list:
614 +--ro vn-member-telemetry
615 +--ro performance-metrics-one-way
616 | +--ro one-way-delay? uint32
617 | +--ro one-way-delay-normality?
618 | | te-types:performance-metrics-normality
619 | +--ro one-way-residual-bandwidth?
620 | | rt-types:bandwidth-ieee-float32
621 | +--ro one-way-residual-bandwidth-normality?
622 | | te-types:performance-metrics-normality
623 | +--ro one-way-available-bandwidth?
624 | | rt-types:bandwidth-ieee-float32
625 | +--ro one-way-available-bandwidth-normality?
626 | | te-types:performance-metrics-normality
627 | +--ro one-way-utilized-bandwidth?
628 | | rt-types:bandwidth-ieee-float32
629 | +--ro one-way-utilized-bandwidth-normality?
630 | te-types:performance-metrics-normality
631 +--ro performance-metrics-two-way
632 | +--ro two-way-delay? uint32
633 | +--ro two-way-delay-normality?
634 | te-types:performance-metrics-normality
635 +--ro te-grouped-params*
636 | -> /te:te/tunnels/tunnel/te-kpi:te-telemetry/id
637 +--ro grouping-operation? grouping-operation
639 7. Yang Data Model
641 7.1. ietf-te-kpi-telemetry model
643 The YANG code is as follows:
645 file "ietf-te-kpi-telemetry@2019-04-18.yang"
647 module ietf-te-kpi-telemetry {
648 yang-version 1.1;
649 namespace "urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry";
650 prefix te-tel;
652 import ietf-te {
653 prefix te;
654 reference
655 "RFC YYYY: A YANG Data Model for Traffic Engineering
656 Tunnels and Interfaces";
657 }
659 /* Note: The RFC Editor will replace YYYY with the number
660 assigned to the RFC once draft-ietf-teas-yang-te
661 becomes an RFC.*/
663 import ietf-te-types {
664 prefix te-types;
665 reference
666 "RFC YYYY: Traffic Engineering Common YANG Types";
667 }
669 /* Note: The RFC Editor will replace YYYY with the number
670 assigned to the RFC once draft-ietf-teas-yang-te-types
671 becomes an RFC.*/
673 organization
674 "IETF Traffic Engineering Architecture and Signaling (TEAS)
675 Working Group";
676 contact
677 "Editor: Young Lee
678 Editor: Dhruv Dhody
679 Editor: Ricard Vilalta
680 Editor: Satish Karunanithi ";
681 description
682 "This module describes YANG data model for performance
683 monitoring telemetry for te tunnels.
685 Copyright (c) 2019 IETF Trust and the persons identified
686 as authors of the code. All rights reserved.
688 Redistribution and use in source and binary forms, with
689 or without modification, is permitted pursuant to, and
690 subject to the license terms contained in, the Simplified
691 BSD License set forth in Section 4.c of the IETF Trust's
692 Legal Provisions Relating to IETF Documents
693 (http://trustee.ietf.org/license-info).
695 This version of this YANG module is part of RFC XXXX; see
696 the RFC itself for full legal notices.";
698 /* Note: The RFC Editor will replace XXXX with the number
699 assigned to the RFC once draft-lee-teas-pm-telemetry-
700 autonomics becomes an RFC.*/
702 revision 2019-04-18 {
703 description
704 "Initial revision. This YANG file defines
705 a YANG model for TE telemetry.";
706 reference "Derived from earlier versions of base YANG files";
707 }
709 identity telemetry-param-type {
710 description
711 "Base identity for telemetry param types";
712 }
714 identity one-way-delay {
715 base telemetry-param-type;
716 description
717 "To specify average Delay in one (forward)
718 direction";
720 reference
721 "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions.
722 RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions.
723 RFC7823: Performance-Based Path Selection for Explicitly
724 Routed Label Switched Paths (LSPs) Using TE Metric
725 Extensions";
726 }
728 identity two-way-delay {
729 base telemetry-param-type;
730 description
731 "To specify average Delay in both (forward and reverse)
732 directions";
733 reference
734 "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions.
735 RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions.
736 RFC7823: Performance-Based Path Selection for Explicitly
737 Routed Label Switched Paths (LSPs) Using TE Metric
738 Extensions";
739 }
741 identity one-way-delay-variation {
742 base telemetry-param-type;
743 description
744 "To specify average Delay Variation in one (forward) direction";
745 reference
746 "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions.
747 RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions.
748 RFC7823: Performance-Based Path Selection for Explicitly
749 Routed Label Switched Paths (LSPs) Using TE Metric
750 Extensions";
751 }
753 identity two-way-delay-variation {
754 base telemetry-param-type;
755 description
756 "To specify average Delay Variation in both (forward and reverse)
757 directions";
758 reference
759 "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions.
760 RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions.
761 RFC7823: Performance-Based Path Selection for Explicitly
762 Routed Label Switched Paths (LSPs) Using TE Metric
763 Extensions";
764 }
766 identity utilized-bandwidth {
767 base telemetry-param-type;
768 description
769 "To specify utilized bandwidth over the specified source
770 and destination.";
771 reference
772 "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions.
773 RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions.
774 RFC7823: Performance-Based Path Selection for Explicitly
775 Routed Label Switched Paths (LSPs) Using TE Metric
776 Extensions";
777 }
779 identity utilized-percentage {
780 base telemetry-param-type;
781 description
782 "To specify utilization percentage of the entity
783 (e.g., tunnel, link, etc.)";
784 }
786 typedef scaling-criteria-operation {
787 type enumeration {
788 enum AND {
789 description
790 "AND operation";
791 }
792 enum OR {
793 description
794 "OR operation";
795 }
796 }
797 description
798 "Operations to analize list of scaling criterias";
799 }
801 grouping scaling-duration {
802 description
803 "Base scaling criteria durations";
804 leaf threshold-time {
805 type uint32;
806 units "seconds";
807 description
808 "The duration for which the criteria must hold true";
809 }
810 leaf cooldown-time {
811 type uint32;
812 units "seconds";
813 description
814 "The duration after a scaling-in/scaling-out action has been
815 triggered, for which there will be no further operation";
816 }
817 }
819 grouping scaling-criteria {
820 description
821 "Grouping for scaling criteria";
822 leaf performance-type {
823 type identityref {
824 base telemetry-param-type;
825 }
826 description
827 "Reference to the tunnel level telemetry type";
828 }
829 leaf threshold-value {
830 type string;
831 description
832 "Scaling threshold for the telemetry parameter type";
833 }
834 leaf te-telemetry-tunnel-ref {
835 type leafref {
836 path "/te:te/te:tunnels/te:tunnel/te:name";
837 }
838 description
839 "Reference to tunnel";
840 }
841 }
843 grouping scaling-in-intent {
844 description
845 "Basic scaling in intent";
846 uses scaling-duration;
847 leaf scale-in-operation-type {
848 type scaling-criteria-operation;
849 default "AND";
850 description
851 "Operation to be applied to check between
852 scaling criterias to check if the scale in
853 threshold condition has been met.
854 Defaults to AND";
855 }
856 list scaling-condition {
857 key "performance-type";
858 description
859 "Scaling conditions";
860 uses scaling-criteria;
862 }
863 }
865 grouping scaling-out-intent {
866 description
867 "Basic scaling out intent";
868 uses scaling-duration;
869 leaf scale-out-operation-type {
870 type scaling-criteria-operation;
871 default "OR";
872 description
873 "Operation to be applied to check between
874 scaling criterias to check if the scale out
875 threshold condition has been met.
876 Defauls to OR";
877 }
878 list scaling-condition {
879 key "performance-type";
880 description
881 "Scaling conditions";
882 uses scaling-criteria;
883 }
884 }
886 augment "/te:te/te:tunnels/te:tunnel" {
887 description
888 "Augmentation parameters for config scaling-criteria
889 TE tunnel topologies. Scale in/out criteria might be used
890 for network autonomics in order the controller
891 to react to a certain set of monitored params.";
892 container te-scaling-intent {
893 description
894 "scaling intent";
895 container scale-in-intent {
896 description
897 "scale-in";
898 uses scaling-in-intent;
899 }
900 container scale-out-intent {
901 description
902 "scale-out";
903 uses scaling-out-intent;
904 }
905 }
906 container te-telemetry {
907 config false;
908 description
909 "telemetry params";
910 leaf id {
911 type string;
912 description
913 "Id of telemetry param";
914 }
915 uses te-types:performance-metrics-attributes;
916 leaf te-ref {
917 type leafref {
918 path "/te:te/te:tunnels/te:tunnel/te:name";
919 }
920 description
921 "Reference to measured te tunnel";
922 }
923 }
924 }
925 }
926
928 7.2. ietf-vn-kpi-telemetry model
930 The YANG code is as follows:
932 file "ietf-vn-kpi-telemetry@2019-04-18.yang"
934 module ietf-vn-kpi-telemetry {
935 yang-version 1.1;
936 namespace "urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry";
937 prefix vn-tel;
939 import ietf-vn {
940 prefix vn;
941 reference
942 "RFC YYYY: A YANG Data Model for VN Operation";
943 }
945 /* Note: The RFC Editor will replace YYYY with the number
946 assigned to the RFC once draft-ietf-teas-actn-vn-yang
947 becomes an RFC.*/
949 import ietf-te {
950 prefix te;
951 reference
952 "RFC YYYY: A YANG Data Model for Traffic Engineering
953 Tunnels and Interfaces";
954 }
956 /* Note: The RFC Editor will replace YYYY with the number
957 assigned to the RFC once draft-ietf-teas-yang-te
958 becomes an RFC.*/
960 import ietf-te-types {
961 prefix te-types;
962 reference
963 "RFC YYYY: Traffic Engineering Common YANG Types";
964 }
966 /* Note: The RFC Editor will replace YYYY with the number
967 assigned to the RFC once draft-ietf-teas-yang-te-types
968 becomes an RFC.*/
970 import ietf-te-kpi-telemetry {
971 prefix te-kpi;
972 reference
973 "RFC YYYY: YANG models for VN & TE Performance Monitoring
974 Telemetry and Scaling Intent Autonomics";
975 }
977 /* Note: The RFC Editor will replace YYYY with the number
978 assigned to the RFC once draft-lee-teas-actn-pm-telemetry
979 -autonomics becomes an RFC.*/
981 organization
982 "IETF Traffic Engineering Architecture and Signaling (TEAS)
983 Working Group";
984 contact
985 "Editor: Young Lee
986 Editor: Dhruv Dhody
987 Editor: Ricard Vilalta
988 Editor: Satish Karunanithi ";
990 description
991 "This module describes YANG data models for performance
992 monitoring telemetry for vn.
994 Copyright (c) 2019 IETF Trust and the persons identified
995 as authors of the code. All rights reserved.
997 Redistribution and use in source and binary forms, with
998 or without modification, is permitted pursuant to, and
999 subject to the license terms contained in, the Simplified
1000 BSD License set forth in Section 4.c of the IETF Trust's
1001 Legal Provisions Relating to IETF Documents
1002 (http://trustee.ietf.org/license-info).
1004 This version of this YANG module is part of RFC XXXX; see
1005 the RFC itself for full legal notices.";
1007 /* Note: The RFC Editor will replace XXXX with the number
1008 assigned to the RFC once draft-lee-teas-pm-telemetry-
1009 autonomics becomes an RFC.*/
1011 revision 2019-04-18 {
1012 description
1013 "Initial revision. This YANG file defines
1014 the VN telemetry.";
1015 reference "Derived from earlier versions of base YANG files";
1016 }
1018 typedef grouping-operation {
1019 type enumeration {
1020 enum MINIMUM {
1021 description
1022 "Select the minimum param";
1023 }
1024 enum MAXIMUM {
1025 description
1026 "Select the maximum param";
1027 }
1028 enum MEAN {
1029 description
1030 "Select the MEAN of the params";
1031 }
1032 enum STD_DEV {
1033 description
1034 "Select the standard deviation of the
1035 monitored params";
1036 }
1037 enum AND {
1038 description
1039 "Select the AND of the params";
1040 }
1041 enum OR {
1042 description
1043 "Select the OR of the params";
1044 }
1045 }
1046 description
1047 "Operations to analize list of monitored params";
1048 }
1050 grouping vn-telemetry-param {
1051 description
1052 "augment of te-kpi:telemetry-param for VN specific params";
1053 leaf-list te-grouped-params {
1054 type leafref {
1055 path "/te:te/te:tunnels/te:tunnel/te-kpi:te-telemetry/te-kpi:id";
1056 }
1057 description
1058 "Allows the definition of a vn-telemetry param
1059 as a grouping of underlying TE params";
1060 }
1061 leaf grouping-operation {
1062 type grouping-operation;
1063 description
1064 "describes the operation to apply to
1065 te-grouped-params";
1066 }
1067 }
1069 augment "/vn:vn/vn:vn-list" {
1070 description
1071 "Augmentation parameters for state TE VN topologies.";
1072 container vn-scaling-intent {
1073 description
1074 "scaling intent";
1075 container scale-in-intent {
1076 description
1077 "VN scale-in";
1078 uses te-kpi:scaling-in-intent;
1079 }
1080 container scale-out-intent {
1081 description
1082 "VN scale-out";
1083 uses te-kpi:scaling-out-intent;
1084 }
1085 }
1086 container vn-telemetry {
1087 config false;
1088 description
1089 "VN telemetry params";
1090 uses te-types:performance-metrics-attributes;
1091 leaf grouping-operation {
1092 type grouping-operation;
1093 description
1094 "describes the operation to apply to the VN-members";
1095 }
1096 }
1097 }
1098 augment "/vn:vn/vn:vn-list/vn:vn-member-list" {
1099 description
1100 "Augmentation parameters for state TE vn member topologies.";
1101 container vn-member-telemetry {
1102 config false;
1103 description
1104 "VN member telemetry params";
1105 uses te-types:performance-metrics-attributes;
1106 uses vn-telemetry-param;
1107 }
1108 }
1109 }
1110
1112 8. Security Considerations
1114 The YANG module specified in this document defines a schema for data
1115 that is designed to be accessed via network management protocols
1116 such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF
1117 layer is the secure transport layer, and the mandatory-to-implement
1118 secure transport is Secure Shell (SSH) [RFC6242]. The lowest
1119 RESTCONF layer is HTTPS, and the mandatory-to-implement secure
1120 transport is TLS [RFC8446].
1122 The NETCONF access control model [RFC8341] provides the means to
1123 restrict access for particular NETCONF users to a preconfigured
1124 subset of all available NETCONF protocol operations and content. The
1125 NETCONF Protocol over Secure Shell (SSH) [RFC6242] describes a
1126 method for invoking and running NETCONF within a Secure Shell (SSH)
1127 session as an SSH subsystem. The Network Configuration Access
1128 Control Model (NACM) [RFC8341] provides the means to restrict access
1129 for particular NETCONF or RESTCONF users to a preconfigured subset
1130 of all available NETCONF or RESTCONF protocol operations and
1131 content.
1133 A number of configuration data nodes defined in this document are
1134 writable/deletable (i.e., "config true"). These data nodes may be
1135 considered sensitive or vulnerable in some network environments.
1137 There are a number of data nodes defined in this YANG module that
1138 are writable/creatable/deletable (i.e., config true, which is the
1139 default). These data nodes may be considered sensitive or
1140 vulnerable in some network environments. Write operations (e.g.,
1141 edit-config) to these data nodes without proper protection can have
1142 a negative effect on network operations. These are the subtrees and
1143 data nodes and their sensitivity/vulnerability:
1145 /te:te/te:tunnels/te:tunnel/te-scaling-intent/scale-in-intent
1146 /te:te/te:tunnels/te:tunnel/te-scaling-intent/scale-out-intent
1148 /vn:vn/vn:vn-list/vn-scaling-intent/scale-in-intent
1149 /vn:vn/vn:vn-list/vn-scaling-intent/scale-out-intent
1151 9. IANA Considerations
1153 This document registers the following namespace URIs in the IETF XML
1154 registry [RFC3688]:
1156 --------------------------------------------------------------------
1157 URI: urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry
1158 Registrant Contact: The IESG.
1159 XML: N/A, the requested URI is an XML namespace.
1160 --------------------------------------------------------------------
1162 --------------------------------------------------------------------
1163 URI: urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry
1164 Registrant Contact: The IESG.
1165 XML: N/A, the requested URI is an XML namespace.
1166 --------------------------------------------------------------------
1168 This document registers the following YANG modules in the YANG
1169 Module.
1171 Names registry [RFC7950]:
1173 --------------------------------------------------------------------
1174 name: ietf-te-kpi-telemetry
1175 namespace: urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry
1176 prefix: te-tel
1177 reference: RFC XXXX (TDB)
1178 --------------------------------------------------------------------
1180 --------------------------------------------------------------------
1181 name: ietf-vn-kpi-telemetry
1182 namespace: urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry
1183 prefix: vn-tel
1184 reference: RFC XXXX (TDB)
1185 --------------------------------------------------------------------
1187 10. Acknowledgements
1189 We thank Rakesh Gandhi, Tarek Saad and Igor Bryskin for useful
1190 discussions and their suggestions for this work.
1192 11. References
1194 11.1. Normative References
1196 [RFC6242] M. Wasserman, "Using the NETCONF Protocol over Secure
1197 Shell (SSH)", RFC 6242, June 2011.
1199 [RFC7926] A. Farrel (Ed.), "Problem Statement and Architecture for
1200 Information Exchange between Interconnected Traffic-
1201 Engineered Networks", RFC 7926, July 2016.
1203 [RFC7950] M. Bjorklund, Ed., "The YANG 1.1 Data Modeling Language",
1204 August 2016.
1206 [RFC8040] A. Bierman, M. Bjorklund, K. Watsen, "RESTCONF Protocol",
1207 RFC 8040, January 2017.
1209 [RFC8233] D. Dhody, et al., "Extensions to the Path Computation
1210 Element Communication Protocol (PCEP) to compute service
1211 aware Label Switched Path (LSP)", RFC 8233, September
1212 2017.
1214 [RFC8341] A. Bierman, M. Bjorklund, "Network Configuration Access
1215 Control Model", RFC 8341, March 2018.
1217 [RFC8342] M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R.
1218 Wilton, "Network Management Datastore Architecture
1219 (NMDA)", RFC 8342, March 2018.
1221 [RFC8446] E. Rescorla, "The Transport Layer Security (TLS) Protocol
1222 Version 1.3", RFC8446, August 2018.
1224 [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic
1225 Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
1226 te, work in progress.
1228 [TE-Types] T. Saad, et.al, "Traffic Engineering Common YANG Types",
1229 draft-ietf-teas-yang-te-types, work in progress.
1231 [VN] Y. Lee (Editor), "A Yang Data Model for ACTN VN Operation",
1232 draft-lee-teas-actn-vn-yang, work in progress.
1234 11.2. Informative References
1236 [RFC3688] M. Mealling, "The IETF XML Registry", RFC 3688, January
1237 2004.
1239 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
1240 and A. Bierman, Ed., "Network Configuration Protocol
1241 (NETCONF)", RFC 6241.
1243 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
1244 Previdi, "OSPF Traffic Engineering (TE) Metric
1245 Extensions", RFC 7471, March 2015.
1247 [RFC7823] Atlas, A., Drake, J., Giacalone, S., and S.
1248 Previdi,"Performance-Based Path Selection for Explicitly
1249 Routed Label Switched Paths (LSPs) Using TE Metric
1250 Extensions", RFC 7823, May 2016.
1252 [RFC8294] X. Liu, et al, "Routing Area Common YANG Data Types", RFC
1253 8294, December 2017.
1255 [RFC8340] M. Bjorklund and L. Berger (Editors), "YANG Tree
1256 Diagrams", RFC 8340, March 2018.
1258 [YANG-PUSH] A. Clemm, et al, "Subscription to YANG Datastores",
1259 draft-ietf-netconf-yang-push, work in progress.
1261 [Event-Notification] E. Voit, et al, "Dynamic subscription to YANG
1262 Events and Datastores over NETCONF", draft-ietf-netconf-
1263 netconf-event-notifications, work in progress.
1265 [PERF] Y. XU, et al., "Use Cases and Requirements of Dynamic Service
1266 Control based on Performance Monitoring in ACTN
1267 Architecture", draft-xu-actn-perf-dynamic-service-control,
1268 work in progress.
1270 [RFC8309] Q. Wu, W. Cheng, and A. Farrel. "Service Models
1271 Explained", RFC 8309, January 2018.
1273 [RFC8453] D. Ceccarelli and Y. Lee (Editors), "Framework for
1274 Abstraction and Control of Traffic Engineered Networks",
1275 RFC 8453, August 2018.
1277 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
1278 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
1279 Metric Extensions", RFC 8570, March 2019.
1281 12. Contributors
1283 Authors' Addresses
1285 Young Lee
1286 Futurewei Technologies
1287 5340 Legacy Drive Suite 173
1288 Plano, TX 75024, USA
1290 Email: younglee.tx@gmail.com
1292 Dhruv Dhody
1293 Huawei Technology
1294 Leela Palace
1295 Bangalore, Karnataka 560008
1296 India
1298 Email: dhruv.dhody@huawei.com
1300 Satish Karunanithi
1301 Huawei Technology
1302 Leela Palace
1303 Bangalore, Karnataka 560008
1304 India
1306 Email: satish.karunanithi@gmail.com
1307 Ricard Vilalta
1308 Centre Tecnologic de Telecomunicacions de Catalunya (CTTC/CERCA)
1309 Av. Carl Friedrich Gauss 7
1310 08860 - Castelldefels
1311 Barcelona (Spain)
1312 Email: ricard.vilalta@cttc.es
1314 Daniel King
1315 Lancaster University
1317 Email: d.king@lancaster.ac.uk
1319 Daniele Ceccarelli
1320 Ericsson
1321 Torshamnsgatan,48
1322 Stockholm, Sweden
1324 Email: daniele.ceccarelli@ericsson.com