idnits 2.17.1
draft-lee-teas-actn-pm-telemetry-autonomics-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 2 instances of too long lines in the document, the longest one
being 14 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 345 has weird spacing: '...lemetry xmlns...'
== Line 373 has weird spacing: '... rw for c...'
== Line 374 has weird spacing: '... ro for n...'
== Line 410 has weird spacing: '...ce-type ide...'
== Line 417 has weird spacing: '...ce-type ide...'
== (2 more instances...)
-- The document date (July 3, 2017) is 2490 days in the past. Is this
intentional?
Checking references for intended status: Full Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'ACTN-Applicability' is mentioned on line 111, but
not defined
== Missing Reference: 'I-D.ietf-netconf-yang-push' is mentioned on line
284, but not defined
== Missing Reference: 'I-D.ietf-netconf-rfc5277bis' is mentioned on line
285, but not defined
== Missing Reference: 'I-D.ietf-netmod-rfc6087bis' is mentioned on line
364, but not defined
** Obsolete undefined reference: RFC 6087 (Obsoleted by RFC 8407)
== Missing Reference: 'RFC6241' is mentioned on line 978, but not defined
== Missing Reference: 'RFC6536' is mentioned on line 979, but not defined
** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341)
== Unused Reference: 'RFC4110' is defined on line 997, but no explicit
reference was found in the text
== Unused Reference: 'Netconf' is defined on line 1013, but no explicit
reference was found in the text
== Unused Reference: 'Restconf' is defined on line 1017, but no explicit
reference was found in the text
== Unused Reference: 'ACTN-Frame' is defined on line 1022, but no explicit
reference was found in the text
== Unused Reference: 'TE-Topology' is defined on line 1026, but no explicit
reference was found in the text
== Unused Reference: 'TE-Tunnel' is defined on line 1029, but no explicit
reference was found in the text
== Unused Reference: 'L3SM-YANG' is defined on line 1036, but no explicit
reference was found in the text
** Downref: Normative reference to an Informational draft:
draft-ietf-teas-actn-framework (ref. 'ACTN-Frame')
** Downref: Normative reference to an Proposed Standard draft:
draft-ietf-teas-yang-te-topo (ref. 'TE-Topology')
** Downref: Normative reference to an Proposed Standard draft:
draft-ietf-teas-yang-te (ref. 'TE-Tunnel')
** Downref: Normative reference to an Proposed Standard draft:
draft-lee-teas-actn-vn-yang (ref. 'ACTN-VN-YANG')
** Downref: Normative reference to an Proposed Standard draft:
draft-ietf-l3sm-l3vpn-service-model (ref. 'L3SM-YANG')
** Downref: Normative reference to an Proposed Standard draft:
draft-ietf-pce-pcep-service-aware (ref. 'PCEP-Service-Aware')
-- Possible downref: Normative reference to a draft: ref. 'ACTN-PERF'
Summary: 9 errors (**), 0 flaws (~~), 20 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 TEAS WG Young Lee
2 Internet Draft Dhruv Dhody
3 Intended Status: standard Satish Karunanithi
4 Huawei
5 Ricard Vilalta
6 CTTC
7 Daniel King
8 Lancaster University
9 Daniele Ceccarelli
10 Ericsson
12 Expires: January 2, 2018
14 July 3, 2017
16 YANG models for ACTN TE Performance Monitoring Telemetry and Network
17 Autonomics
19 draft-lee-teas-actn-pm-telemetry-autonomics-03
21 Status of this Memo
23 This Internet-Draft is submitted to IETF in full conformance with
24 the provisions of BCP 78 and BCP 79.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF), its areas, and its working groups. Note that
28 other groups may also distribute working documents as Internet-
29 Drafts.
31 Internet-Drafts are draft documents valid for a maximum of six
32 months and may be updated, replaced, or obsoleted by other documents
33 at any time. It is inappropriate to use Internet-Drafts as
34 reference material or to cite them other than as "work in progress."
36 The list of current Internet-Drafts can be accessed at
37 http://www.ietf.org/ietf/1id-abstracts.txt
39 The list of Internet-Draft Shadow Directories can be accessed at
40 http://www.ietf.org/shadow.html.
42 This Internet-Draft will expire on January 3, 2018.
44 Copyright Notice
46 Copyright (c) 2017 IETF Trust and the persons identified as the
47 document authors. All rights reserved.
49 This document is subject to BCP 78 and the IETF Trust's Legal
50 Provisions Relating to IETF Documents
51 (http://trustee.ietf.org/license-info) in effect on the date of
52 publication of this document. Please review these documents
53 carefully, as they describe your rights and restrictions with
54 respect to this document. Code Components extracted from this
55 document must include Simplified BSD License text as described in
56 Section 4.e of the Trust Legal Provisions and are provided without
57 warranty as described in the Simplified BSD License.
59 Abstract
61 Abstraction and Control of TE Networks (ACTN) refers to the set of
62 virtual network operations needed to operate, control and manage
63 large-scale multi-domain, multi-layer and multi-vendor TE networks,
64 so as to facilitate network programmability, automation, efficient
65 resource sharing.
67 This document provides YANG data models that describe Key
68 Performance Indicator (KPI) telemetry and network autonomics for TE-
69 tunnels and ACTN VNs.
71 Table of Contents
73 1. Introduction...................................................3
74 2. Use-Cases......................................................3
75 3. Design of the Data Models......................................5
76 TE KPI Telemetry Model.........................................6
77 ACTN TE KPI Telemetry Model....................................7
78 4. Notification...................................................8
79 YANG Push Subscription Examples................................8
80 5. YANG Data Tree................................................10
81 6. Yang Data Model...............................................12
82 ietf-te-kpi-telemetry model...................................12
83 ietf-actn-te-kpi-telemetry model..............................19
84 7. Security Considerations.......................................23
85 8. IANA Considerations...........................................23
86 9. Acknowledgements..............................................23
87 10. References...................................................23
88 Informative References........................................23
89 Normative References..........................................24
90 11. Contributors.................................................24
91 Authors' Addresses...............................................25
93 1. Introduction
95 Abstraction and Control of TE Networks (ACTN) describes a method for
96 operating a Traffic Engineered (TE) network (such as an MPLS-TE
97 network or a layer 1/0 transport network) to provide connectivity
98 and virtual network services for customers of the TE network [ACTN-
99 Frame]. The services provided can be optimized to meet the
100 requirements (such as traffic patterns, quality, and reliability) of
101 the applications hosted by the customers. Data models are a
102 representation of objects that can be configured or monitored within
103 a system. Within the IETF, YANG [RFC6020] is the language of choice
104 for documenting data models, and YANG models have been produced to
105 allow configuration or modeling of a variety of network devices,
106 protocol instances, and network services. YANG data models have been
107 classified in [Netmod-Yang-Model-Classification] and [Service-YANG].
109 [ACTN-VN-YANG] describes how customers or end to end orchestrators
110 can request and/or instantiate a generic virtual network service.
111 [ACTN-Applicability] describes a connection between IETF YANG model
112 classifications to ACTN interfaces. In particular, it describes the
113 customer service model can be mapped into the CMI (CNC-MDSC
114 Interface) of the ACTN architecture.
116 The YANG model on the ACTN CMI is known as customer service model in
117 [Service-YANG]. [PCEP-Service-Aware] describes key network
118 performance data to be considered for end-to-end path computation in
119 TE networks. Key performance indicator is a term that describes
120 critical performance data that may affect VN/TE service.
122 2. Use-Cases
124 [ACTN-PERF] describes use-cases relevant to this draft. It
125 introduces the dynamic creation, modification and optimization of
126 services based on the performance monitoring in the Abstraction and
127 Control of Transport Networks (ACTN) architecture. Figure 1 shows a
128 high-level workflows for dynamic service control based on traffic
129 monitoring.
131 Some of the key points from [ACTN-PERF] are as follows:
133 . Network traffic monitoring is important to facilitate automatic
134 discovery of the imbalance of network traffic, and initiate the
135 network optimization, thus helping the network operator or the
136 virtual network service provider to use the network more
137 efficiently and save CAPEX/OPEX.
138 . Customer services have various SLA requirements, such as
139 service availability, latency, latency jitter, packet loss
140 rate, BER, etc. The transport network can satisfy service
141 availability and BER requirements by providing different
142 protection and restoration mechanisms. However, for other
143 performance parameters, there are no such mechanisms. In order
144 to provide high quality services according to customer SLA, one
145 possible solution is to measure the service SLA related
146 performance parameters, and dynamically provision and optimize
147 services based on the performance monitoring results.
148 . Performance monitoring in a large scale network could generate
149 a huge amount of performance information. Therefore, the
150 appropriate way to deliver the information in CMI and MPI
151 interfaces should be carefully considered.
153 +-------------------------------------------+
154 | CNC +-----------------------------+ |
155 | | Dynamic Service Control APP | |
156 | +-----------------------------+ |
157 +-------------------------------------------+
158 1.Traffic| /|\4.Traffic | /|\
159 Monitor& | | Monitor | | 8.Traffic
160 Optimize | | Result 5.Service | | modify &
161 Policy | | modify& | | optimize
162 \|/ | optimize Req.\|/ | result
163 +------------------------------------------------+
164 | MDSC +-------------------------------+ |
165 | |Dynamic Service Control Agent | |
166 | +-------------------------------+ |
167 | +---------------+ +-------------------+ |
168 | | Flow Optimize | | vConnection Agent | |
169 | +---------------+ +-------------------+ |
170 +------------------------------------------------+
171 2. Path | /|\3.Traffic | |
172 Monitor | | Monitor | |7.Path
173 Request | | Result 6.Path | | modify &
174 | | modify& | | optimize
175 \|/ | optimize Req.\|/ | result
176 +-------------------------------------------------------+
177 | PNC +----------------------+ +----------------------+ |
178 | | Network Provisioning | |Abstract Topology Gen.| |
179 | +----------------------+ +----------------------+ |
180 | +------------------+ +--------------------+ |
181 | |Network Monitoring| |Physical Topology DB| |
182 | +------------------+ +--------------------+ |
183 +-------------------------------------------------------+
185 Figure 1 Workflows for dynamic service control based on traffic
186 monitoring
188 3. Design of the Data Models
190 The YANG models developed in this document describe two models:
192 (i) TE KPI Telemetry Model which provides the TE-Tunnel level of
193 performance monitoring mechanism (See Section 2.1 for
194 details)
196 (ii) ACTN TE KPI Telemetry Model which provides the VN level of the
197 aggregated performance monitoring mechanism (See Section 2.2
198 for details)
200 The models include -
202 (i) Performance Telemetry details as measured during the last
203 interval, ex delay.
205 (ii) Scaling Intent based on with TE/VN could be scaled in/out.
207 [Editor's Note - Need to decide if scaling and telemetry can be in
208 the same model as per the current draft.]
210 TE KPI Telemetry Model
212 This module describes performance telemetry for TE-tunnel model. The
213 telemetry data is augmented to tunnel state. This module also
214 allows autonomic traffic engineering scaling intent configuration
215 mechanism on the TE-tunnel level. Various conditions can be set for
216 auto-scaling based on the telemetry data.
218 The TE KPI Telemetry Model augments the TE-Tunnel Model to enhance
219 TE performance monitoring capability. This monitoring capability
220 will facilitate proactive re-optimization and reconfiguration of TEs
221 based on the performance monitoring data collected via the TE KPI
222 Telemetry YANG model.
224 +------------+ +--------------+
225 | TE-Tunnel | | TE KPI |
226 | Model |<---------| Telemetry |
227 +------------+ augments | Model |
228 +--------------+
230 ACTN TE KPI Telemetry Model
232 This module describes performance telemetry for ACTN VN model. The
233 telemetry data is augmented both at the VN Level as well as
234 individual VN member level. This module also allows autonomic
235 traffic engineering scaling intent configuration mechanism on the VN
236 level. Scale in/out criteria might be used for network autonomics in
237 order the controller to react to a certain set of variations in
238 monitored parameters.
240 Moreover, this module also provides mechanism to define aggregated
241 telemetry parameters as a grouping of underlying VN level telemetry
242 parameters. Grouping operation (such as maximum, mean) could be set
243 at the time of configuration. For example, if maximum grouping
244 operation is used for delay at the VN level, the VN telemetry data
245 is reported as the maximum {delay_vn_member_1, delay_vn_member_2, ..
246 delay_vn_member_N}. Thus, this telemetry abstraction mechanism
247 allows the grouping of a certain common set of telemetry values
248 under a grouping operation. This can be done at the VN-member level
249 to suggest how the E2E telemetry be inferred from the per domain
250 tunnel created and monitored by PNCs. One proposed example is the
251 following:
253 +------------------------------------------------------------+
254 | CNC |
255 | |
256 +------------------------------------------------------------+
257 1.CNC sets the | /|\ 2. MDSC gets VN Telemetry
258 grouping op, and | |
259 subscribes to the | | VN KPI TELEMETRY (VN Level)
260 VN level telemetry | | VN Bandwidth Utilization: Minimum
261 for delay and | | across VN members
262 bandwidth util | | VN Delay: Maximum across VN
263 \|/ | Members
264 +------------------------------------------------------------+
265 | MDSC |
266 | |
267 +------------------------------------------------------------+
269 The ACTN VN TE-Telemetry Model augments the basic ACTN VN model to
270 enhance VN monitoring capability. This monitoring capability will
271 facilitate proactive re-optimization and reconfiguration of VNs
272 based on the performance monitoring data collected via the ACTN VN
273 Telemetry YANG model.
275 +----------+ +--------------+
276 | ACTN VN | augments | ACTN |
277 | Model |<---------| TE-Telemetry |
278 +----------+ | Model |
279 +--------------+
281 4. Notification
283 This model does not define specific notifications. To enable
284 notifications, the mechanism defined in [I-D.ietf-netconf-yang-push]
285 and [I-D.ietf-netconf-rfc5277bis] can be used. This mechanism
286 currently allows the user to:
288 . Subscribe notifications on a per client basis.
290 . Specify subtree filters or xpath filters so that only interested
291 contents will be sent.
293 . Specify either periodic or on-demand notifications.
295 YANG Push Subscription Examples
297 Below example shows the way for a client to subscribe for the
298 telemetry information for a particular tunnel (Tunnel1). The
299 telemetry parameter that the client is interested in is the utilized
300 bandwidth.
302
304
306
307
308
309
310 Tunnel1
311
312
313
315
318
319
320
321
322
323
324 500
325 encode-xml
326
327
329 This example shows the way for a client to subscribe for the
330 telemetry information for all VNs. The telemetry parameter that the
331 client is interested in is packet-loss and utilized bandwidth.
333
335
337
338
340
341
342
343
344
347
348
351
352
353
354
355
356 500
357
358
360 5. YANG Data Tree
362 A graphical representation of the complete data tree is presented
363 here. The meaning of the symbols in these diagrams is as follows
364 and as per [I-D.ietf-netmod-rfc6087bis]. Each node is printed as:
365
367 is one of:
368 + for current
369 x for deprecated
370 o for obsolete
372 is one of:
373 rw for configuration data
374 ro for non-configuration data
375 -x for rpcs and actions
376 -n for notifications
378 is the name of the node
379 () means that the node is a choice node
380 :() means that the node is a case node
382 If the node is augmented into the tree from another module,
383 its name is printed as :.
385 is one of:
386 ? for an optional leaf, choice, anydata or anyxml
387 ! for a presence container
388 * for a leaf-list or list
389 [] for a list's keys
391 is the name of the type for leafs and leaf-lists
393 If the type is a leafref, the type is printed as "->
394 TARGET",
396 where TARGET is either the leafref path, with prefixed
397 removed if possible.
399 is the list of features this node depends on,
400 printed within curly brackets and a question mark "{...}?
402 module: ietf-te-kpi-telemetry
403 augment /te:te/te:tunnels/te:tunnel/te:config:
404 +--rw te-scaling-intent
405 +--rw scale-in
406 | +--rw scale-in-operation-type?
407 | | scaling-criteria-operation
408 | +--rw threshold-time? uint32
409 | +--rw scale-in-condition* [performance-type]
410 | +--rw performance-type identityref
411 | +--rw performance-data? binary
412 +--rw scale-down
413 +--rw cooldown-time? uint32
414 +--rw scale-out-operation-type?
415 | scaling-criteria-operation
416 +--rw scale-out-condition* [performance-type]
417 +--rw performance-type identityref
418 +--rw performance-data? binary
419 augment /te:te/te:tunnels/te:tunnel/te:state:
420 +--ro te-telemetry
421 +--ro data
422 +--ro one-way-delay? uint32
423 +--ro two-way-delay? uint32
424 +--ro one-way-delay-min? uint32
425 +--ro one-way-delay-max? uint32
426 +--ro two-way-delay-min? uint32
427 +--ro two-way-delay-max? uint32
428 +--ro one-way-delay-variation? uint32
429 +--ro two-way-delay-variation? uint32
430 +--ro utilized-bandwidth? te-types:te-bandwidth
432 module: ietf-actn-te-kpi-telemetry
433 augment /actn-vn:actn/actn-vn:vn/actn-vn:vn-list:
434 +--rw vn-telemetry
435 | +--rw grouping-op
436 | | +--rw delay-op? identityref
437 | | +--rw delay-variation-op? identityref
438 | | +--rw utilized-bandwidth-op? identityref
439 | +--ro data
440 | +--ro one-way-delay? uint32
441 | +--ro two-way-delay? uint32
442 | +--ro one-way-delay-min? uint32
443 | +--ro one-way-delay-max? uint32
444 | +--ro two-way-delay-min? uint32
445 | +--ro two-way-delay-max? uint32
446 | +--ro one-way-delay-variation? uint32
447 | +--ro two-way-delay-variation? uint32
448 | +--ro utilized-bandwidth? te-types:te-bandwidth
449 +--rw vn-scaling-intent
450 +--rw scale-in
451 | +--rw scale-in-operation-type?
452 | | scaling-criteria-operation
453 | +--rw threshold-time? uint32
454 | +--rw scale-in-condition* [performance-type]
455 | +--rw performance-type identityref
456 | +--rw performance-data? binary
457 +--rw scale-down
458 +--rw cooldown-time? uint32
459 +--rw scale-out-operation-type?
460 | scaling-criteria-operation
461 +--rw scale-out-condition* [performance-type]
462 +--rw performance-type identityref
463 +--rw performance-data? binary
464 augment /actn-vn:actn/actn-vn:vn/actn-vn:vn-list/actn-vn:vn-member-list:
465 +--rw vn-telemetry
466 +--rw grouping-op
467 | +--rw delay-op? identityref
468 | +--rw delay-variation-op? identityref
469 | +--rw utilized-bandwidth-op? identityref
470 +--ro data
471 +--ro one-way-delay? uint32
472 +--ro two-way-delay? uint32
473 +--ro one-way-delay-min? uint32
474 +--ro one-way-delay-max? uint32
475 +--ro two-way-delay-min? uint32
476 +--ro two-way-delay-max? uint32
477 +--ro one-way-delay-variation? uint32
478 +--ro two-way-delay-variation? uint32
479 +--ro utilized-bandwidth? te-types:te-bandwidth
481 6. Yang Data Model
483 ietf-te-kpi-telemetry model
485 The YANG code is as follows:
487 file "ietf-te-kpi-telemetry@2017-07-03.yang"
489 module ietf-te-kpi-telemetry {
490 namespace "urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry";
491 prefix "te-tel";
493 import ietf-te {
494 prefix "te";
495 }
497 import ietf-te-types {
498 prefix "te-types";
499 }
501 organization
502 "IETF Traffic Engineering Architecture and Signaling (TEAS)
503 Working Group";
505 contact
506 "Editor: Young Lee
507 Editor: Dhruv Dhody
508 Editor: Ricard Vilalta
509 Editor: Satish Karunanithi ";
510 description
511 "This module describes telemetry for teas tunnel model";
513 revision 2017-07-03 {
514 description
515 "Initial revision. This YANG file defines
516 the reusable base types for TE telemetry.";
517 reference
518 "xxx";
519 }
521 /*
522 * Identities
523 */
525 identity telemetry-param-type {
526 description
527 "Base identity for telemetry param types";
528 }
530 identity one-way-delay {
531 base telemetry-param-type;
532 description
533 "To specify average Delay in one (forward) direction";
534 }
535 identity two-way-delay {
536 base telemetry-param-type;
537 description
538 "To specify average Delay in both (forward and reverse)
539 directions";
540 }
542 identity one-way-delay-variation {
543 base telemetry-param-type;
544 description
545 "To specify average Delay Variation in one (forward)
546 direction";
547 }
549 identity two-way-delay-variation {
550 base telemetry-param-type;
551 description
552 "To specify average Delay Variation in both (forward
553 and reverse) directions";
554 }
556 identity utilized-bandwidth {
557 base telemetry-param-type;
558 description
559 "To specify utilized bandwidth over the specified source
560 and destination.";
561 }
563 /*
564 * Enums
565 */
566 typedef scaling-criteria-operation {
567 type enumeration {
568 enum AND {
569 description
570 "AND operation";
571 }
572 enum OR {
573 description
574 "OR operation";
575 }
576 }
577 description
578 "Operations to analize list of scaling criterias";
579 }
581 /*
582 * Groupings
583 */
585 grouping telemetry-delay {
586 description
587 "Base telemetry delay parameters";
588 leaf one-way-delay {
589 type uint32;
590 units "microseconds";
591 description
592 "To specify average Delay in one (forward) direction
593 during the measurement interval";
594 }
595 leaf two-way-delay {
596 type uint32;
597 units "microseconds";
598 description
599 "To specify average Delay in both (forward and reverse)
600 directions during the measurement interval";
601 }
603 leaf one-way-delay-min {
604 type uint32;
605 units "microseconds";
606 description
607 "To specify minimum Delay in one (forward) direction
608 during the measurement interval";
609 }
610 leaf one-way-delay-max {
611 type uint32;
612 units "microseconds";
613 description
614 "To specify maximum Delay in one (forward) direction
615 during the measurement interval";
616 }
618 leaf two-way-delay-min {
619 type uint32;
620 units "microseconds";
621 description
622 "To specify minimum Delay in both (forward and reverse)
623 directions during the measurement interval";
624 }
626 leaf two-way-delay-max {
627 type uint32;
628 units "microseconds";
629 description
630 "To specify maximum Delay in both (forward and reverse)
631 directions during the measurement interval";
632 }
634 }
635 grouping telemetry-delay-variance {
637 description
638 "Base telemetry delay variance parameters";
639 leaf one-way-delay-variation {
640 type uint32;
641 units "microseconds";
642 description
643 "To specify average Delay Variation in one (forward)
644 direction during the measurement interval";
645 }
647 leaf two-way-delay-variation {
648 type uint32;
649 units "microseconds";
650 description
651 "To specify average Delay Variation in both
652 (forward and reverse) directions during the
653 measurement interval";
654 }
655 }
657 grouping telemetry-bandwidth {
658 description
659 "Base telemetry bandwidth parameters";
660 leaf utilized-bandwidth {
661 type te-types:te-bandwidth;
662 description
663 "To specify utilized bandwidth over the specified source
664 and destination in bytes per seconds.";
665 reference
666 "RFC 3471";
667 }
668 }
670 grouping scaling-criteria {
671 description
672 "Grouping for scaling criteria";
673 leaf performance-type {
674 type identityref {
675 base telemetry-param-type;
676 }
677 description
678 "Reference to the tunnel level telemetry type";
679 }
681 leaf performance-data {
682 type binary;
683 description
684 "The encoding and meaning of this field is
685 based on the performance-type";
686 }
687 }
688 grouping scaling-intent {
689 description
690 "Basic scaling intent";
692 container scale-in {
693 description
694 "Basic scaling-in intent";
696 leaf scale-in-operation-type {
697 type scaling-criteria-operation;
698 default AND;
699 description
700 "Operation to be applied to check between
701 scaling criterias to check if the scale in
702 threshold condition has been met.
703 Defaults to AND";
704 }
706 leaf threshold-time {
707 type uint32;
708 units "seconds";
709 description
710 "The duration for which the criteria must
711 hold true";
712 }
714 list scale-in-condition {
715 key "performance-type";
716 description
717 "Scaling conditions";
718 uses scaling-criteria;
719 }
720 }
721 container scale-down {
722 description
723 "Basic scaling-out intent";
724 leaf cooldown-time {
725 type uint32;
726 units "seconds";
727 description
728 "The duration after a scaling-in/scaling-out action
729 has been triggered, for which there will be no
730 further operation";
731 }
732 leaf scale-out-operation-type {
733 type scaling-criteria-operation;
734 default OR;
735 description
736 "Operation to be applied to check between
737 scaling criterias to check if the scale out
738 threshold condition has been met.
739 Defauls to OR";
740 }
741 list scale-out-condition {
742 key "performance-type";
743 description
744 "Scaling conditions";
745 uses scaling-criteria;
746 }
748 }
750 }
752 grouping telemetry-param {
754 description
755 "Base telemetry parameters";
756 container data {
757 config false;
758 description
759 "The telemetry data";
761 uses telemetry-delay;
763 uses telemetry-delay-variance;
765 uses telemetry-bandwidth;
766 }
768 }
770 /*
771 * Augments
772 */
773 augment "/te:te/te:tunnels/te:tunnel/te:config" {
775 description
776 "Augmentation parameters for config scaling-criteria
777 TE tunnel topologies. Scale in/out criteria might be
778 used for network autonomics in order the controller
779 to react to a certain set of monitored params.";
781 container te-scaling-intent {
782 description
783 "scaling intent";
784 uses scaling-intent;
786 }
788 }
790 augment "/te:te/te:tunnels/te:tunnel/te:state" {
792 description
793 "Augmentation parameters for state TE tunnel
794 topologies.";
796 container te-telemetry {
797 description
798 "telemetry params";
799 uses telemetry-param;
800 }
801 }
803 }//module
805
807 ietf-actn-te-kpi-telemetry model
809 The YANG code is as follows:
811 file "ietf-actn-te-kpi-telemetry@2017-07-03.yang"
813 module ietf-actn-te-kpi-telemetry {
815 namespace
816 "urn:ietf:params:xml:ns:yang:ietf-actn-te-kpi-telemetry";
818 prefix "actn-tel";
820 import ietf-actn-vn {
821 prefix "actn-vn";
822 }
824 import ietf-te-kpi-telemetry {
825 prefix "te-kpi";
826 }
827 organization
828 "IETF Traffic Engineering Architecture and Signaling (TEAS)
829 Working Group";
831 contact
832 "Editor: Young Lee
833 Editor: Dhruv Dhody
834 Editor: Ricard Vilalta
835 Editor: Satish Karunanithi ";
837 description
838 "This module describes telemetry for actn vn model";
840 revision 2017-07-03 {
841 description
842 "Initial revision. This YANG file defines
843 the reusable base types for ACTN VN telemetry.";
844 reference
845 "xxx";
846 }
848 /*
849 * Identities
850 */
852 identity grouping-operation {
853 description "Base identity for operations to analize list of monitored param";
854 }
856 identity minimum-grouping-operation {
857 base grouping-operation;
858 description
859 "Select the minimum param";
860 }
862 identity maximum-grouping-operation {
863 base grouping-operation;
864 description
865 "Select the maximum param";
866 }
868 identity mean-grouping-operation {
869 base grouping-operation;
870 description
871 "Select the MEAN of the params";
872 }
874 identity stddev-grouping-operation {
875 base grouping-operation;
876 description
877 "Select the STD deviation of the params";
878 }
880 identity sum-grouping-operation {
881 base grouping-operation;
882 description
883 "Select the sum of the params";
884 reference
885 "RFC 7823";
886 }
888 /*
889 * Groupings
890 */
891 grouping vn-telemetry-param {
892 description
893 "telemetry-parameter for VN";
894 uses te-kpi:telemetry-param;
895 }
896 grouping telemetry-grouping-op {
897 description
898 "Config how the VN telemetry should be applied";
899 container grouping-op {
900 description
901 "The grouping operations";
902 leaf delay-op {
903 type identityref {
904 base grouping-operation;
905 }
906 default maximum-grouping-operation;
907 description
908 "The operation that should be applied on the
909 VN-member telemetry to get the VN telemetry";
910 }
912 leaf delay-variation-op {
913 type identityref {
914 base grouping-operation;
915 }
916 default maximum-grouping-operation;
917 description
918 "The operation that should be applied on the
919 VN-member telemetry to get the VN telemetry";
920 }
922 leaf utilized-bandwidth-op {
923 type identityref {
924 base grouping-operation;
926 }
927 default maximum-grouping-operation;
928 description
929 "The operation that should be applied on the
930 VN-member telemetry to get the VN telemetry";
931 }
932 }
934 }
936 /*
937 * Augments
938 */
939 augment "/actn-vn:actn/actn-vn:vn/actn-vn:vn-list" {
941 description
942 "Augmentation parameters for state TE VN topologies.";
944 container vn-telemetry {
945 description
946 "VN telemetry configurations";
947 uses telemetry-grouping-op;
948 uses vn-telemetry-param;
949 }
950 container vn-scaling-intent {
951 description
952 "scaling intent";
953 uses te-kpi:scaling-intent;
954 }
955 }
957 /*
958 * VN-member augment
959 */
960 augment "/actn-vn:actn/actn-vn:vn/actn-vn:vn-list/" +
961 "actn-vn:vn-member-list" {
962 description
963 "Augmentation parameters for state TE vn member
964 topologies.";
965 container vn-telemetry {
966 description
967 "VN Member config";
968 uses telemetry-grouping-op;
969 uses vn-telemetry-param;
970 }
971 }
972 }
973
974 7. Security Considerations
976 The configuration, state, and action data defined in this document
977 are designed to be accessed via a management protocol with a secure
978 transport layer, such as NETCONF [RFC6241]. The NETCONF access
979 control model [RFC6536] provides the means to restrict access for
980 particular NETCONF users to a preconfigured subset of all available
981 NETCONF protocol operations and content.
983 A number of configuration data nodes defined in this document are
984 writable/deletable (i.e., "config true") These data nodes may be
985 considered sensitive or vulnerable in some network environments.
987 8. IANA Considerations
989 TDB
991 9. Acknowledgements
993 10. References
995 Informative References
997 [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3
998 Provider-Provisioned Virtual Private Networks (PPVPNs)",
999 RFC 4110, July 2005.
1001 [RFC6020] M. Bjorklund, Ed., "YANG - A Data Modeling Language for
1002 the Network Configuration Protocol (NETCONF)", RFC 6020,
1003 October 2010.
1005 [Service-YANG] Q. Wu, W. Liu and A. Farrel, "Service Models
1006 Explained", draft-wu-opsawg-service-model-explained, work
1007 in progress.
1009 [Netmod-Yang-Model-Classification] D. Bogdanovic, B. Claise, and C.
1010 Moberg, "YANG Module Classification", draft-ietf-netmod-
1011 yang-model-classification, work in progress.
1013 [Netconf] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
1014 and A. Bierman, Ed., "Network Configuration Protocol
1015 (NETCONF)", RFC 6241.
1017 [Restconf] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF
1018 Protocol", draft-ietf-netconf-restconf, work in progress.
1020 Normative References
1022 [ACTN-Frame] D. Cecarelli and Y. Lee, "Framework for Abstraction and
1023 Control of Traffic Engineered Networks", draft-ietf-teas-
1024 actn-framework, work in progress.
1026 [TE-Topology] X. Liu, et al., "YANG Data Model for TE Topologies",
1027 draft-ietf-teas-yang-te-topo, work in progress.
1029 [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic
1030 Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
1031 te, work in progress.
1033 [ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN
1034 Operation", draft-lee-teas-actn-vn-yang, work in progress.
1036 [L3SM-YANG] S. Litkowski, L.Tomotaki, and K. Ogaki, "YANG Data Model
1037 for L3VPN service delivery", draft-ietf-l3sm-l3vpn-
1038 service-model, work in progress.
1040 [PCEP-Service-Aware] D. Dhody, et al., "Extensions to the Path
1041 Computation Element Communication Protocol (PCEP) to
1042 compute service aware Label Switched Path (LSP)", draft-
1043 ietf-pce-pcep-service-aware, work in progress.
1045 [ACTN-PERF] Y. XU, et al., "Use Cases and Requirements of Dynamic
1046 Service Control based on Performance Monitoring in ACTN
1047 Architecture", draft-xu-actn-perf-dynamic-service-control-
1048 03, work in progress.
1050 11. Contributors
1051 Authors' Addresses
1053 Young Lee
1054 Huawei Technologies
1055 5340 Legacy Drive Suite 173
1056 Plano, TX 75024, USA
1058 Email: leeyoung@huawei.com
1060 Dhruv Dhody
1061 Huawei Technology
1062 Leela Palace
1063 Bangalore, Karnataka 560008
1064 India
1066 Email: dhruv.dhody@huawei.com
1068 Satish Karunanithi
1069 Huawei Technology
1070 Leela Palace
1071 Bangalore, Karnataka 560008
1072 India
1074 Email: satish.karunanithi@gmail.com
1076 Ricard Vilalta
1077 Centre Tecnologic de Telecomunicacions de Catalunya (CTTC/CERCA)
1078 Av. Carl Friedrich Gauss 7
1079 08860 - Castelldefels
1080 Barcelona (Spain)
1081 Email: ricard.vilalta@cttc.es
1083 Daniel King
1084 Lancaster University
1086 Email: d.king@lancaster.ac.uk
1088 Daniele Ceccarelli
1089 Ericsson
1090 Torshamnsgatan,48
1091 Stockholm, Sweden
1093 Email: daniele.ceccarelli@ericsson.com