idnits 2.17.1
draft-lee-teas-actn-pm-telemetry-autonomics-11.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 2
longer pages, the longest (page 12) being 61 lines
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 35 instances of too long lines in the document, the longest
one being 23 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 435 has weird spacing: '...lemetry xmlns...'
-- The document date (March 6, 2019) is 1878 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 153, but not defined
-- Duplicate reference: draft-ietf-netconf-yang-push, mentioned in
'Event-Notification', was also mentioned in 'Yang-Push'.
Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 TEAS Working Group Y. Lee (Editor)
2 Internet Draft Dhruv Dhody
3 Intended Status: Standard Track Satish Karunanithi
4 Expires: September 6, 2019 Huawei
5 Ricard Vilalta
6 CTTC
7 Daniel King
8 Lancaster University
9 Daniele Ceccarelli
10 Ericsson
12 March 6, 2019
14 YANG models for ACTN & TE Performance Monitoring Telemetry and Network
15 Autonomics
17 draft-lee-teas-actn-pm-telemetry-autonomics-11
19 Status of this Memo
21 This Internet-Draft is submitted to IETF in full conformance with
22 the provisions of BCP 78 and BCP 79.
24 Internet-Drafts are working documents of the Internet Engineering
25 Task Force (IETF), its areas, and its working groups. Note that
26 other groups may also distribute working documents as Internet-
27 Drafts.
29 Internet-Drafts are draft documents valid for a maximum of six
30 months and may be updated, replaced, or obsoleted by other documents
31 at any time. It is inappropriate to use Internet-Drafts as
32 reference material or to cite them other than as "work in progress."
34 The list of current Internet-Drafts can be accessed at
35 http://www.ietf.org/ietf/1id-abstracts.txt
37 The list of Internet-Draft Shadow Directories can be accessed at
38 http://www.ietf.org/shadow.html.
40 This Internet-Draft will expire on September 6, 2019.
42 Copyright Notice
44 Copyright (c) 2019 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (http://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with
52 respect to this document. Code Components extracted from this
53 document must include Simplified BSD License text as described in
54 Section 4.e of the Trust Legal Provisions and are provided without
55 warranty as described in the Simplified BSD License.
57 Abstract
59 Abstraction and Control of TE Networks (ACTN) refers to the set of
60 virtual network operations needed to operate, control and manage
61 large-scale multi-domain, multi-layer and multi-vendor TE networks,
62 so as to facilitate network programmability, automation, efficient
63 resource sharing.
65 This document provides YANG data models that describe Key
66 Performance Indicator (KPI) telemetry and network autonomics for TE-
67 tunnels and ACTN VNs.
69 Table of Contents
71 1. Introduction...................................................3
72 1.1. Terminology...............................................3
73 1.2. Tree diagram..............................................4
74 1.3. Prefixes in Data Node Names...............................4
75 2. Use-Cases......................................................4
76 3. Design of the Data Models......................................6
77 3.1. TE KPI Telemetry Model....................................7
78 3.2. ACTN TE KPI Telemetry Model...............................7
79 4. Scaling Intent Illustration....................................9
80 5. Notification..................................................10
81 5.1. YANG Push Subscription Examples..........................10
82 6. YANG Data Tree................................................11
83 7. Yang Data Model...............................................13
84 7.1. ietf-te-kpi-telemetry model..............................13
85 7.2. ietf-actn-te-kpi-telemetry model.........................18
86 8. Security Considerations.......................................21
87 9. IANA Considerations...........................................21
88 10. Acknowledgements.............................................22
89 11. References...................................................22
90 11.1. Informative References..................................22
91 11.2. Normative References....................................23
92 12. Contributors.................................................24
93 Authors' Addresses...............................................24
95 1. Introduction
97 Abstraction and Control of TE Networks (ACTN) describes a method for
98 operating a Traffic Engineered (TE) network (such as an MPLS-TE
99 network or a layer 1/0 transport network) to provide connectivity
100 and virtual network services for customers of the TE network
101 [RFC8453]. The services provided can be optimized to meet the
102 requirements (such as traffic patterns, quality, and reliability) of
103 the applications hosted by the customers. Data models are a
104 representation of objects that can be configured or monitored within
105 a system. Within the IETF, YANG [RFC6020] is the language of choice
106 for documenting data models, and YANG models have been produced to
107 allow configuration or modeling of a variety of network devices,
108 protocol instances, and network services. YANG data models have been
109 classified in [RFC8199] and [RFC8309].
111 [ACTN-VN] describes how customers or end to end orchestrators can
112 request and/or instantiate a generic virtual network service. [ACTN-
113 Applicability] describes a connection between IETF YANG model
114 classifications to ACTN interfaces. In particular, it describes the
115 customer service model can be mapped into the CMI (CNC-MDSC
116 Interface) of the ACTN architecture.
118 The YANG model on the ACTN CMI is known as customer service model in
119 [RFC8309]. [RFC8233] describes key network performance data to be
120 considered for end-to-end path computation in TE networks. Key
121 performance indicator is a term that describes critical performance
122 data that may affect VN/TE service.
124 This document provides TE KPI Telemetry Model which provides the TE-
125 Tunnel level of performance monitoring model and the scaling
126 mechanisms. It also provides ACTN VN TE KPI Telemetry Model which
127 provides the VN level of the aggregated performance monitoring model
128 and the scaling mechanisms.
130 1.1. Terminology
132 Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used
133 in this document.
135 1.2. Tree diagram
137 A simplified graphical representation of the data model is used in
138 Section 5 of this this document. The meaning of the symbols in
139 these diagrams is defined in [RFC8340].
141 1.3. Prefixes in Data Node Names
143 In this document, names of data nodes and other data model objects
144 are prefixed using the standard prefix associated with the
145 corresponding YANG imported modules, as shown in Table 1.
147 +---------+------------------------------+-----------------+
148 | Prefix | YANG module | Reference |
149 +---------+------------------------------+-----------------+
150 | rt | ietf-routing-types | [RFC8294] |
151 | te | ietf-te | [TE-Tunnel] |
152 | te-types| ietf-te-types | [TE-Types] |
153 | te-kpi | ietf-te-kpi-telemetry | [This I-D] |
154 | vn | ietf-vn | [ACTN-VN] |
155 | actn-tel| ietf-actn-te-kpi-telemetry | {This I-D] |
156 +---------+------------------------------+-----------------+
158 Table 1: Prefixes and corresponding YANG modules
160 2. Use-Cases
162 [ACTN-PERF] describes use-cases relevant to this draft. It
163 introduces the dynamic creation, modification and optimization of
164 services based on the performance monitoring in the Abstraction and
165 Control of Transport Networks (ACTN) architecture. Figure 1 shows a
166 high-level workflows for dynamic service control based on traffic
167 monitoring.
169 Some of the key points from [ACTN-PERF] are as follows:
171 . Network traffic monitoring is important to facilitate automatic
172 discovery of the imbalance of network traffic, and initiate the
173 network optimization, thus helping the network operator or the
174 virtual network service provider to use the network more
175 efficiently and save CAPEX/OPEX.
176 . Customer services have various SLA requirements, such as
177 service availability, latency, latency jitter, packet loss
178 rate, BER, etc. The transport network can satisfy service
179 availability and BER requirements by providing different
180 protection and restoration mechanisms. However, for other
181 performance parameters, there are no such mechanisms. In order
182 to provide high quality services according to customer SLA, one
183 possible solution is to measure the service SLA related
184 performance parameters, and dynamically provision and optimize
185 services based on the performance monitoring results.
186 . Performance monitoring in a large scale network could generate
187 a huge amount of performance information. Therefore, the
188 appropriate way to deliver the information in CMI and MPI
189 interfaces should be carefully considered.
191 +-------------------------------------------+
192 | CNC +-----------------------------+ |
193 | | Dynamic Service Control APP | |
194 | +-----------------------------+ |
195 +-------------------------------------------+
196 1.Traffic| /|\4.Traffic | /|\
197 Monitor& | | Monitor | | 8.Traffic
198 Optimize | | Result 5.Service | | modify &
199 Policy | | modify& | | optimize
200 \|/ | optimize Req.\|/ | result
201 +------------------------------------------------+
202 | MDSC +-------------------------------+ |
203 | |Dynamic Service Control Agent | |
204 | +-------------------------------+ |
205 | +---------------+ +-------------------+ |
206 | | Flow Optimize | | vConnection Agent | |
207 | +---------------+ +-------------------+ |
208 +------------------------------------------------+
209 2. Path | /|\3.Traffic | |
210 Monitor | | Monitor | |7.Path
211 Request | | Result 6.Path | | modify &
212 | | modify& | | optimize
213 \|/ | optimize Req.\|/ | result
214 +-------------------------------------------------------+
215 | PNC +----------------------+ +----------------------+ |
216 | | Network Provisioning | |Abstract Topology Gen.| |
217 | +----------------------+ +----------------------+ |
218 | +------------------+ +--------------------+ |
219 | |Network Monitoring| |Physical Topology DB| |
220 | +------------------+ +--------------------+ |
221 +-------------------------------------------------------+
223 Figure 1 Workflows for dynamic service control based on traffic
224 monitoring
226 3. Design of the Data Models
228 The YANG models developed in this document describe two models:
230 (i) TE KPI Telemetry Model which provides the TE-Tunnel level of
231 performance monitoring mechanism (See Section 3.1 & 7.1 for
232 details).
234 (ii) ACTN TE KPI Telemetry Model which provides the VN level of the
235 aggregated performance monitoring mechanism (See Section 3.2
236 & 7.2 for details).
238 The models include -
240 (i) Performance Telemetry details as measured during the last
241 interval, e.g., delay.
243 (ii) Scaling Intent based on with TE/VN could be scaled in/out (See
244 Section 4 for an illustration).
246 3.1. TE KPI Telemetry Model
248 This module describes performance telemetry for TE-tunnel model. The
249 telemetry data is augmented to tunnel state. This module also
250 allows autonomic traffic engineering scaling intent configuration
251 mechanism on the TE-tunnel level. Various conditions can be set for
252 auto-scaling based on the telemetry data (See Section 5 for details)
254 The TE KPI Telemetry Model augments the TE-Tunnel Model to enhance
255 TE performance monitoring capability. This monitoring capability
256 will facilitate proactive re-optimization and reconfiguration of TEs
257 based on the performance monitoring data collected via the TE KPI
258 Telemetry YANG model.
260 +------------+ +--------------+
261 | TE-Tunnel | | TE KPI |
262 | Model |<---------| Telemetry |
263 +------------+ augments | Model |
264 +--------------+
266 3.2. ACTN TE KPI Telemetry Model
268 This module describes performance telemetry for ACTN VN model. The
269 telemetry data is augmented both at the VN Level as well as
270 individual VN member level. This module also allows autonomic
271 traffic engineering scaling intent configuration mechanism on the VN
272 level. Scale in/out criteria might be used for network autonomics in
273 order the controller to react to a certain set of variations in
274 monitored parameters (See Section 4 for illustrations).
276 Moreover, this module also provides mechanism to define aggregated
277 telemetry parameters as a grouping of underlying VN level telemetry
278 parameters. Grouping operation (such as maximum, mean) could be set
279 at the time of configuration. For example, if maximum grouping
280 operation is used for delay at the VN level, the VN telemetry data
281 is reported as the maximum {delay_vn_member_1, delay_vn_member_2,..
282 delay_vn_member_N}. Thus, this telemetry abstraction mechanism
283 allows the grouping of a certain common set of telemetry values
284 under a grouping operation. This can be done at the VN-member level
285 to suggest how the E2E telemetry be inferred from the per domain
286 tunnel created and monitored by PNCs. One proposed example is the
287 following:
289 +------------------------------------------------------------+
290 | CNC |
291 | |
292 +------------------------------------------------------------+
294 1.CNC sets the | /|\ 2. MDSC gets VN Telemetry
295 grouping op, and | |
296 subscribes to the | | VN KPI TELEMETRY (VN Level)
297 VN level telemetry for | | VN Utilized-bw-percentage:
298 Delay and | | Minimum across VN Members
299 Utilized-bw-pecentage | | VN Delay: Maximum across VN
300 \|/ | Members
301 +------------------------------------------------------------+
302 | MDSC |
303 | |
304 +------------------------------------------------------------+
306 The ACTN VN TE-Telemetry Model augments the basic ACTN VN model to
307 enhance VN monitoring capability. This monitoring capability will
308 facilitate proactive re-optimization and reconfiguration of VNs
309 based on the performance monitoring data collected via the ACTN VN
310 Telemetry YANG model.
312 +----------+ +--------------+
313 | ACTN VN | augments | ACTN |
314 | Model |<---------| TE-Telemetry |
315 +----------+ | Model |
316 +--------------+
318 4. Scaling Intent Illustration
320 The following tree is a part of ietf-te-kpi-telemetry tree whose
321 model is presented in full detail in Sections 6 & 7.
323 module: ietf-te-kpi-telemetry
324 augment /te:te/te:tunnels/te:tunnel:
325 +-rw te-scaling-intent
326 | +-rw scale-in-intent
327 | | +-rw threshold-time? uint32
328 | | +-rw cooldown-time? uint32
329 | | +-rw scale-in-operation-type? scaling-criteria-operation
330 | | +-rw scaling-condition* [performance-type]
331 | | +-rw performance-type identityref
332 | | +-rw threshold-value? string
333 | | +-rw te-telemetry-tunnel-ref? -> /te:te/tunnels/tunnel/name
334 | +-rw scale-out-intent
335 | +-rw threshold-time? uint32
336 | +-rw cooldown-time? uint32
337 | +-rw scale-out-operation-type? scaling-criteria-operation
338 | +-rw scaling-condition* [performance-type]
339 | +-rw performance-type identityref
340 | +-rw threshold-value? string
341 | +-rw te-telemetry-tunnel-ref? -> /te:te/tunnels/tunnel/name
343 Scaling intent configuration mechanism allows the client to
344 configure automatic scale-in and scale-out mechanisms on both the
345 TE-tunnel and the VN level. Various conditions can be set for auto-
346 scaling based on the PM telemetry data.
348 For example, if the client were to set scale-out-intent (as the
349 above tree), it can specify the threshold-time and cooldown-time to
350 which the scaling intent would apply. Threshold time refers to the
351 duration for which the criteria must hold true. Cooldown time refers
352 to the duration after a scaling action has been triggered, for which
353 there will be no further operation.
355 Performance type can be any type as defined in performance-type
356 (e.g., one-way-delay, one-way-delay-min, one-way-delay-max, two-way-
357 delay, two-way-delay-min, two-way-delay-max, utilized bandwidth,
358 etc.). Scaling condition can be set with one or more performance
359 types. When multiple performance types are set, then scaling-
360 operation-type (AND or OR) is applied to these selected performance
361 types and its threshold values.
363 Let say the client wants to set the scaling out operation based on
364 two performance-types (e.g., two-way-delay and utilized-bandwidth
365 for a te-tunnel), it can be done as follows:
367 . Two-way-delay threshold: 300 mileseconds
368 . Utilized bandwidth: 300 megabytes
370 By setting AND for the scale-out-operation-type, the two criteria
371 have to meet at the same time to trigger scale-out operation.
373 5. Notification
375 This model does not define specific notifications. To enable
376 notifications, the mechanism defined in [Yang-Push]
377 and [Event-Notification] can be used. This mechanism currently
378 allows the user to:
380 . Subscribe notifications on a per client basis.
382 . Specify subtree filters or xpath filters so that only interested
383 contents will be sent.
385 . Specify either periodic or on-demand notifications.
387 5.1. YANG Push Subscription Examples
389 Below example shows the way for a client to subscribe for the
390 telemetry information for a particular tunnel (Tunnel1). The
391 telemetry parameter that the client is interested in is one-way-
392 delay.
394
396
398
399
400
401
402 Tunnel1
403
404
405
407
409
410
411
412
413
414
415 500
416 encode-xml
417
418
420 This example shows the way for a client to subscribe for the
421 telemetry information for all VNs. The telemetry parameter that the
422 client is interested in is one-way-delay and one-way-utilized-
423 bandwidth.
425
427
429
430
431
432
433
434
435
437
438
439
440
441
442
443
444 500
445
446
448 6. YANG Data Tree
450 module: ietf-te-kpi-telemetry
451 augment /te:te/te:tunnels/te:tunnel:
452 +-rw te-scaling-intent
453 | +-rw scale-in-intent
454 | | +-rw threshold-time? uint32
455 | | +-rw cooldown-time? uint32
456 | | +-rw scale-in-operation-type? scaling-criteria-operation
457 | | +-rw scaling-condition* [performance-type]
458 | | +-rw performance-type identityref
459 | | +-rw threshold-value? string
460 | | +-rw te-telemetry-tunnel-ref? -> /te:te/tunnels/tunnel/name
461 | +-rw scale-out-intent
462 | +-rw threshold-time? uint32
463 | +-rw cooldown-time? uint32
464 | +-rw scale-out-operation-type? scaling-criteria-operation
465 | +-rw scaling-condition* [performance-type]
466 | +-rw performance-type identityref
467 | +-rw threshold-value? string
468 | +-rw te-telemetry-tunnel-ref? -> /te:te/tunnels/tunnel/name
469 +-ro te-telemetry
470 +-ro id? string
471 +-ro performance-metrics-one-way
472 | +-ro one-way-delay? uint32
473 | +-ro one-way-delay-normality? te-types:performance-metrics-normality
474 | +-ro one-way-residual-bandwidth? rt-types:bandwidth-ieee-float32
475 | +-ro one-way-residual-bandwidth-normality? te-types:performance-metrics-normality
476 | +-ro one-way-available-bandwidth? rt-types:bandwidth-ieee-float32
477 | +-ro one-way-available-bandwidth-normality? te-types:performance-metrics-normality
478 | +-ro one-way-utilized-bandwidth? rt-types:bandwidth-ieee-float32
479 | +-ro one-way-utilized-bandwidth-normality? te-types:performance-metrics-normality
480 +-ro performance-metrics-two-way
481 | +-ro two-way-delay? uint32
482 | +-ro two-way-delay-normality? te-types:performance-metrics-normality
483 +-ro te-ref? -> /te:te/tunnels/tunnel/name
485 module: ietf-actn-te-kpi-telemetry
486 augment /vn:vn/vn:vn-list:
487 +--rw vn-scaling-intent
488 | +--rw scale-in-intent
489 | | +--rw threshold-time? uint32
490 | | +--rw cooldown-time? uint32
491 | | +--rw scale-in-operation-type? scaling-criteria-operation
492 | | +--rw scaling-condition* [performance-type]
493 | | +--rw performance-type identityref
494 | | +--rw threshold-value? string
495 | | +--rw te-telemetry-tunnel-ref? -> /te:te/tunnels/tunnel/name
496 | +--rw scale-out-intent
497 | +--rw threshold-time? uint32
498 | +--rw cooldown-time? uint32
499 | +--rw scale-out-operation-type? scaling-criteria-operation
500 | +--rw scaling-condition* [performance-type]
501 | +--rw performance-type identityref
502 | +--rw threshold-value? string
503 | +--rw te-telemetry-tunnel-ref? -> /te:te/tunnels/tunnel/name
504 +--ro vn-telemetry
505 +--ro performance-metrics-one-way
506 | +--ro one-way-delay? uint32
507 | +--ro one-way-delay-normality? te-types:performance-metrics-normality
508 | +--ro one-way-residual-bandwidth? rt-types:bandwidth-ieee-float32
509 | +--ro one-way-residual-bandwidth-normality? te-types:performance-metrics-normality
510 | +--ro one-way-available-bandwidth? rt-types:bandwidth-ieee-float32
511 | +--ro one-way-available-bandwidth-normality? te-types:performance-metrics-normality
512 | +--ro one-way-utilized-bandwidth? rt-types:bandwidth-ieee-float32
513 | +--ro one-way-utilized-bandwidth-normality? te-types:performance-metrics-normality
514 +--ro performance-metrics-two-way
515 | +--ro two-way-delay? uint32
516 | +--ro two-way-delay-normality? te-types:performance-metrics-normality
517 +--ro grouping-operation? grouping-operation
518 augment /vn:vn/vn:vn-list/vn:vn-member-list:
519 +--ro vn-member-telemetry
520 +--ro performance-metrics-one-way
521 | +--ro one-way-delay? uint32
522 | +--ro one-way-delay-normality? te-types:performance-metrics-normality
523 | +--ro one-way-residual-bandwidth? rt-types:bandwidth-ieee-float32
524 | +--ro one-way-residual-bandwidth-normality? te-types:performance-metrics-normality
525 | +--ro one-way-available-bandwidth? rt-types:bandwidth-ieee-float32
526 | +--ro one-way-available-bandwidth-normality? te-types:performance-metrics-normality
527 | +--ro one-way-utilized-bandwidth? rt-types:bandwidth-ieee-float32
528 | +--ro one-way-utilized-bandwidth-normality? te-types:performance-metrics-normality
529 +--ro performance-metrics-two-way
530 | +--ro two-way-delay? uint32
531 | +--ro two-way-delay-normality? te-types:performance-metrics-normality
532 +--ro te-grouped-params* -> /te:te/tunnels/tunnel/te-kpi:te-telemetry/id
533 +--ro grouping-operation? grouping-operation
535 7. Yang Data Model
537 7.1. ietf-te-kpi-telemetry model
539 The YANG code is as follows:
541 file "ietf-te-kpi-telemetry@2019-03-06.yang"
543 module ietf-te-kpi-telemetry {
544 namespace "urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry";
545 prefix te-tel;
547 import ietf-te {
548 prefix te;
549 }
550 import ietf-te-types {
551 prefix te-types;
552 }
553 import ietf-routing-types {
554 prefix rt-types;
555 }
557 organization
558 "IETF Traffic Engineering Architecture and Signaling (TEAS)
559 Working Group";
560 contact
561 "Editor: Young Lee
562 Editor: Dhruv Dhody
563 Editor: Ricard Vilalta
564 Editor: Satish Karunanithi ";
565 description
566 "This module describes telemetry for teas tunnel model";
568 revision 2019-03-06 {
569 description
570 "Initial revision. This YANG file defines
571 the reusable base types for TE telemetry.";
572 reference "Derived from earlier versions of base YANG files";
573 }
575 identity telemetry-param-type {
576 description
577 "Base identity for telemetry param types";
578 }
580 identity one-way-delay {
581 base telemetry-param-type;
582 description
583 "To specify average Delay in one (forward)
584 direction";
585 }
587 identity two-way-delay {
588 base telemetry-param-type;
589 description
590 "To specify average Delay in both (forward and reverse)
591 directions";
592 }
594 identity one-way-delay-variation {
595 base telemetry-param-type;
596 description
597 "To specify average Delay Variation in one (forward) direction";
598 }
600 identity two-way-delay-variation {
601 base telemetry-param-type;
602 description
603 "To specify average Delay Variation in both (forward and reverse)
604 directions";
605 }
607 identity utilized-bandwidth {
608 base telemetry-param-type;
609 description
610 "To specify utilized bandwidth over the specified source
611 and destination.";
612 }
614 identity utilized-percentage {
615 base telemetry-param-type;
616 description
617 "To specify utilization percentage of the entity
618 (e.g., tunnel, link, etc.)";
619 }
621 typedef scaling-criteria-operation {
622 type enumeration {
623 enum AND {
624 description
625 "AND operation";
626 }
627 enum OR {
628 description
629 "OR operation";
630 }
631 }
632 description
633 "Operations to analize list of scaling criterias";
634 }
636 grouping scaling-duration {
637 description
638 "Base scaling criteria durations";
639 leaf threshold-time {
640 type uint32;
641 units "seconds";
642 description
643 "The duration for which the criteria must hold true";
644 }
645 leaf cooldown-time {
646 type uint32;
647 units "seconds";
648 description
649 "The duration after a scaling-in/scaling-out action has been
650 triggered, for which there will be no further operation";
651 }
652 }
654 grouping scaling-criteria {
655 description
656 "Grouping for scaling criteria";
657 leaf performance-type {
658 type identityref {
659 base telemetry-param-type;
660 }
661 description
662 "Reference to the tunnel level telemetry type";
663 }
664 leaf threshold-value {
665 type string;
666 description
667 "Scaling threshold for the telemetry parameter type";
668 }
669 leaf te-telemetry-tunnel-ref {
670 type leafref {
671 path "/te:te/te:tunnels/te:tunnel/te:name";
672 }
673 description
674 "Reference to tunnel";
675 }
676 }
678 grouping scaling-in-intent {
679 description
680 "Basic scaling in intent";
681 uses scaling-duration;
682 leaf scale-in-operation-type {
683 type scaling-criteria-operation;
684 default "AND";
685 description
686 "Operation to be applied to check between
687 scaling criterias to check if the scale in
688 threshold condition has been met.
689 Defaults to AND";
690 }
691 list scaling-condition {
692 key "performance-type";
693 description
694 "Scaling conditions";
695 uses scaling-criteria;
696 }
697 }
699 grouping scaling-out-intent {
700 description
701 "Basic scaling out intent";
703 uses scaling-duration;
704 leaf scale-out-operation-type {
705 type scaling-criteria-operation;
706 default "OR";
707 description
708 "Operation to be applied to check between
709 scaling criterias to check if the scale out
710 threshold condition has been met.
711 Defauls to OR";
712 }
713 list scaling-condition {
714 key "performance-type";
715 description
716 "Scaling conditions";
717 uses scaling-criteria;
718 }
719 }
721 augment "/te:te/te:tunnels/te:tunnel" {
722 description
723 "Augmentation parameters for config scaling-criteria
724 TE tunnel topologies. Scale in/out criteria might be used
725 for network autonomics in order the controller
726 to react to a certain set of monitored params.";
727 container te-scaling-intent {
728 description
729 "scaling intent";
730 container scale-in-intent {
731 description
732 "scale-in";
733 uses scaling-in-intent;
734 }
735 container scale-out-intent {
736 description
737 "scale-out";
738 uses scaling-out-intent;
739 }
740 }
741 container te-telemetry {
742 config false;
743 description
744 "telemetry params";
745 leaf id {
746 type string;
747 description
748 "Id of telemetry param";
749 }
750 uses te-types:performance-metrics-attributes;
751 leaf te-ref {
752 type leafref {
753 path "/te:te/te:tunnels/te:tunnel/te:name";
754 }
755 description
756 "Reference to measured te tunnel";
757 }
758 }
759 }
760 }
762
764 7.2. ietf-actn-te-kpi-telemetry model
766 The YANG code is as follows:
768 file "ietf-actn-te-kpi-telemetry@2019-03-06.yang"
770 module ietf-actn-te-kpi-telemetry {
771 namespace "urn:ietf:params:xml:ns:yang:ietf-actn-te-kpi-telemetry";
772 prefix actn-tel;
774 import ietf-vn {
775 prefix vn;
776 }
777 import ietf-te {
778 prefix te;
779 }
780 import ietf-te-types {
781 prefix te-types;
782 }
783 import ietf-te-kpi-telemetry {
784 prefix te-kpi;
785 }
787 organization
788 "IETF Traffic Engineering Architecture and Signaling (TEAS)
789 Working Group";
790 contact
791 "Editor: Young Lee
792 Editor: Dhruv Dhody
793 Editor: Ricard Vilalta
794 Editor: Satish Karunanithi ";
795 description
796 "This module describes telemetry for actn vn model";
798 revision 2019-03-06 {
799 description
800 "Initial revision. This YANG file defines
801 the ACTN VN telemetry.";
802 reference "Derived from earlier versions of base YANG files";
803 }
805 typedef grouping-operation {
806 type enumeration {
807 enum MINIMUM {
808 description
809 "Select the minimum param";
810 }
811 enum MAXIMUM {
812 description
813 "Select the maximum param";
814 }
815 enum MEAN {
816 description
817 "Select the MEAN of the params";
818 }
819 enum STD_DEV {
820 description
821 "Select the standard deviation of the
822 monitored params";
823 }
824 enum AND {
825 description
826 "Select the AND of the params";
827 }
828 enum OR {
829 description
830 "Select the OR of the params";
831 }
832 }
833 description
834 "Operations to analize list of monitored params";
835 }
837 grouping vn-telemetry-param {
838 description
839 "augment of te-kpi:telemetry-param for VN specific params";
840 leaf-list te-grouped-params {
841 type leafref {
842 path "/te:te/te:tunnels/te:tunnel/te-kpi:te-telemetry/te-kpi:id";
843 }
844 description
845 "Allows the definition of a vn-telemetry param
846 as a grouping of underlying TE params";
847 }
848 leaf grouping-operation {
849 type grouping-operation;
850 description
851 "describes the operation to apply to
852 te-grouped-params";
853 }
854 }
856 augment "/vn:vn/vn:vn-list" {
857 description
858 "Augmentation parameters for state TE VN topologies.";
859 container vn-scaling-intent {
860 description
861 "scaling intent";
862 container scale-in-intent {
863 description
864 "VN scale-in";
865 uses te-kpi:scaling-in-intent;
866 }
867 container scale-out-intent {
868 description
869 "VN scale-out";
870 uses te-kpi:scaling-out-intent;
871 }
872 }
873 container vn-telemetry {
874 config false;
875 description
876 "VN telemetry params";
877 uses te-types:performance-metrics-attributes;
878 leaf grouping-operation {
879 type grouping-operation;
880 description
881 "describes the operation to apply to the VN-members";
882 }
883 }
884 }
885 augment "/vn:vn/vn:vn-list/vn:vn-member-list" {
886 description
887 "Augmentation parameters for state TE vn member topologies.";
889 container vn-member-telemetry {
890 config false;
891 description
892 "VN member telemetry params";
893 uses te-types:performance-metrics-attributes;
894 uses vn-telemetry-param;
895 }
896 }
897 }
899
901 8. Security Considerations
903 The configuration, state, and action data defined in this document
904 are designed to be accessed via a management protocol with a secure
905 transport layer, such as NETCONF [RFC6241]. The NETCONF access
906 control model [RFC8341] provides the means to restrict access for
907 particular NETCONF users to a preconfigured subset of all available
908 NETCONF protocol operations and content.
910 A number of configuration data nodes defined in this document are
911 writable/deletable (i.e., "config true") These data nodes may be
912 considered sensitive or vulnerable in some network environments.
914 9. IANA Considerations
916 This document registers the following namespace URIs in the IETF XML
917 registry [RFC3688]:
919 --------------------------------------------------------------------
920 URI: urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry
921 Registrant Contact: The IESG.
922 XML: N/A, the requested URI is an XML namespace.
923 --------------------------------------------------------------------
925 --------------------------------------------------------------------
926 URI: urn:ietf:params:xml:ns:yang:ietf-actn-te-kpi-telemetry
927 Registrant Contact: The IESG.
928 XML: N/A, the requested URI is an XML namespace.
929 --------------------------------------------------------------------
930 This document registers the following YANG modules in the YANG
931 Module.
933 Names registry [RFC7950]:
935 --------------------------------------------------------------------
936 name: ietf-te-kpi-telemetry
937 namespace: urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry
938 reference: RFC XXXX (TDB)
939 --------------------------------------------------------------------
941 --------------------------------------------------------------------
942 name: ietf-actn-te-kpi-telemetry
943 namespace: urn:ietf:params:xml:ns:yang:ietf-actn-te-kpi-telemetry
944 reference: RFC XXXX (TDB)
945 --------------------------------------------------------------------
947 10. Acknowledgements
949 We thank Rakesh Gandhi, Tarek Saad and Igor Bryskin for useful
950 discussions and their suggestions for this work.
952 11. References
954 11.1. Informative References
956 [RFC3688] M. Mealling, "The IETF XML Registry", RFC 3688, January
957 2004.
959 [RFC7950] M. Bjorklund, Ed., "The YANG 1.1 Data Modeling Language",
960 August 2016.
962 [RFC6020] M. Bjorklund, Ed., "YANG - A Data Modeling Language for
963 the Network Configuration Protocol (NETCONF)", RFC 6020,
964 October 2010.
966 [RFC8199] D. Bogdanovic, B. Claise, and C. Moberg, "YANG Module
967 Classification", RFC 8199, July 2017.
969 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
970 and A. Bierman, Ed., "Network Configuration Protocol
971 (NETCONF)", RFC 6241.
973 [RFC8294] X. Liu, et al, "Routing Area Common YANG Data Types", RFC
974 8294, December 2017.
976 [RFC7926] A. Farrel (Ed.), "Problem Statement and Architecture for
977 Information Exchange between Interconnected Traffic-
978 Engineered Networks", RFC 7926, July 2016.
980 [RFC8309] Q. Wu, W. Cheng, and A. Farrel. "Service Models
981 Explained", RFC 8309, January 2018.
983 [RFC8340] M. Bjorklund and L. Berger (Editors), "YANG Tree
984 Diagrams", RFC 8340, March 2018.
986 [Yang-Push] A. Clemm, et al, "Subscription to YANG Datastores",
987 draft-ietf-netconf-yang-push, work in progress.
989 [Event-Notification] E. Voit, et al, "Subscription to YANG
990 Datastores", draft-ietf-netconf-yang-push, work in
991 progress.
993 [ACTN-PERF] Y. XU, et al., "Use Cases and Requirements of Dynamic
994 Service Control based on Performance Monitoring in ACTN
995 Architecture", draft-xu-actn-perf-dynamic-service-control,
996 work in progress.
998 [RFC8341] A. Bierman, M. Bjorklund, "Network Configuration Access
999 Control Model", RFC 8341, March 2018.
1001 [RFC8453] D. Ceccarelli and Y. Lee (Editors), "Framework for
1002 Abstraction and Control of Traffic Engineered Networks",
1003 RFC 8453, August 2018.
1005 11.2. Normative References
1007 [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic
1008 Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
1009 te, work in progress.
1011 [TE-Types] T. Saad, et.al, "Traffic Engineering Common YANG Types",
1012 draft-ietf-teas-yang-te-types, work in progress.
1014 [ACTN-VN] Y. Lee (Editor), "A Yang Data Model for ACTN VN
1015 Operation", draft-lee-teas-actn-vn-yang, work in progress.
1017 [RFC8233] D. Dhody, et al., "Extensions to the Path Computation
1018 Element Communication Protocol (PCEP) to compute service
1019 aware Label Switched Path (LSP)", RFC 8233, September
1020 2017.
1022 12. Contributors
1024 Authors' Addresses
1026 Young Lee
1027 Huawei Technologies
1028 5340 Legacy Drive Suite 173
1029 Plano, TX 75024, USA
1031 Email: leeyoung@huawei.com
1033 Dhruv Dhody
1034 Huawei Technology
1035 Leela Palace
1036 Bangalore, Karnataka 560008
1037 India
1039 Email: dhruv.dhody@huawei.com
1041 Satish Karunanithi
1042 Huawei Technology
1043 Leela Palace
1044 Bangalore, Karnataka 560008
1045 India
1047 Email: satish.karunanithi@gmail.com
1049 Ricard Vilalta
1050 Centre Tecnologic de Telecomunicacions de Catalunya (CTTC/CERCA)
1051 Av. Carl Friedrich Gauss 7
1052 08860 - Castelldefels
1053 Barcelona (Spain)
1054 Email: ricard.vilalta@cttc.es
1056 Daniel King
1057 Lancaster University
1059 Email: d.king@lancaster.ac.uk
1061 Daniele Ceccarelli
1062 Ericsson
1063 Torshamnsgatan,48
1064 Stockholm, Sweden
1066 Email: daniele.ceccarelli@ericsson.com