idnits 2.17.1
draft-lee-teas-actn-pm-telemetry-autonomics-01.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 4 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...'
== (4 more instances...)
-- The document date (June 20, 2017) is 2499 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 1049, but not defined
== Missing Reference: 'RFC6536' is mentioned on line 1050, but not defined
** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341)
== Unused Reference: 'RFC4110' is defined on line 1068, but no explicit
reference was found in the text
== Unused Reference: 'Netconf' is defined on line 1084, but no explicit
reference was found in the text
== Unused Reference: 'Restconf' is defined on line 1088, but no explicit
reference was found in the text
== Unused Reference: 'ACTN-Frame' is defined on line 1093, but no explicit
reference was found in the text
== Unused Reference: 'TE-Topology' is defined on line 1097, but no explicit
reference was found in the text
== Unused Reference: 'TE-Tunnel' is defined on line 1100, but no explicit
reference was found in the text
== Unused Reference: 'L3SM-YANG' is defined on line 1107, 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: September 2017
14 June 20, 2017
16 YANG models for ACTN TE Performance Monitoring Telemetry and Network
17 Autonomics
19 draft-lee-teas-actn-pm-telemetry-autonomics-01
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 September 20, 2017.
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...............................................13
82 ietf-te-kpi-telemetry model...................................13
83 ietf-actn-te-kpi-telemetry model..............................20
84 7. Security Considerations.......................................24
85 8. IANA Considerations...........................................25
86 9. Acknowledgements..............................................25
87 10. References...................................................25
88 Informative References........................................25
89 Normative References..........................................25
90 11. Contributors.................................................26
91 Authors' Addresses...............................................26
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? rt:bandwidth-ieee-float32
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? grouping-operation
437 | +--rw delay-variation-op? grouping-operation
438 | +--rw utilized-bandwidth-op? grouping-operation
439 +--rw vn-scaling-intent
440 +--rw scale-in
441 | +--rw scale-in-operation-type?
442 | | scaling-criteria-operation
443 | +--rw threshold-time? uint32
444 | +--rw scale-in-condition* [performance-type]
445 | +--rw performance-type identityref
446 | +--rw performance-data? binary
447 +--rw scale-down
448 +--rw cooldown-time? uint32
449 +--rw scale-out-operation-type?
450 | scaling-criteria-operation
451 +--rw scale-out-condition* [performance-type]
452 +--rw performance-type identityref
453 +--rw performance-data? binary
454 augment /actn-vn:actn-state/actn-vn:vn/actn-vn:vn-list:
455 +--ro vn-telemetry
456 | +--ro grouping-op
457 | | +--ro delay-op? identityref
458 | | +--ro delay-variation-op? identityref
459 | | +--ro utilized-bandwidth-op? identityref
460 | +--ro data
461 | +--ro one-way-delay? uint32
462 | +--ro two-way-delay? uint32
463 | +--ro one-way-delay-min? uint32
464 | +--ro one-way-delay-max? uint32
465 | +--ro two-way-delay-min? uint32
466 | +--ro two-way-delay-max? uint32
467 | +--ro one-way-delay-variation? uint32
468 | +--ro two-way-delay-variation? uint32
469 | +--ro utilized-bandwidth? rt:bandwidth-ieee-float32
470 +--ro vn-scaling-intent
471 +--ro scale-in
472 | +--ro scale-in-operation-type?
473 | | scaling-criteria-operation
474 | +--ro threshold-time? uint32
475 | +--ro scale-in-condition* [performance-type]
476 | +--ro performance-type identityref
477 | +--ro performance-data? binary
478 +--ro scale-down
479 +--ro cooldown-time? uint32
480 +--ro scale-out-operation-type?
481 | scaling-criteria-operation
482 +--ro scale-out-condition* [performance-type]
483 +--ro performance-type identityref
484 +--ro performance-data? binary
485 augment /actn-vn:actn/actn-vn:vn/actn-vn:vn-list/actn-vn:vn-member-list:
486 +--rw vn-telemetry
487 +--rw grouping-op
488 +--rw delay-op? identityref
489 +--rw delay-variation-op? identityref
490 +--rw utilized-bandwidth-op? identityref
491 augment /actn-vn:actn-state/actn-vn:vn/actn-vn:vn-list/actn-vn:vn-member-list:
492 +--ro vn-telemetry
493 +--ro grouping-op
494 | +--ro delay-op? identityref
495 | +--ro delay-variation-op? identityref
496 | +--ro utilized-bandwidth-op? identityref
497 +--ro data
498 +--ro one-way-delay? uint32
499 +--ro two-way-delay? uint32
500 +--ro one-way-delay-min? uint32
501 +--ro one-way-delay-max? uint32
502 +--ro two-way-delay-min? uint32
503 +--ro two-way-delay-max? uint32
504 +--ro one-way-delay-variation? uint32
505 +--ro two-way-delay-variation? uint32
506 +--ro utilized-bandwidth? rt:bandwidth-ieee-float32
508 6. Yang Data Model
510 ietf-te-kpi-telemetry model
512 The YANG code is as follows:
514 file "ietf-te-kpi-telemetry@2017-06-20.yang"
516 module ietf-te-kpi-telemetry {
517 namespace "urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry";
519 prefix "te-tel";
521 import ietf-te {
522 prefix "te";
523 }
525 import ietf-te-topology {
526 prefix "tet";
527 }
529 organization
530 "IETF Traffic Engineering Architecture and Signaling (TEAS)
531 Working Group";
533 contact
534 "Editor: Young Lee
535 Editor: Dhruv Dhody
536 Editor: Ricard Vilalta
537 Editor: Satish Karunanithi ";
539 description
540 "This module describes telemetry for teas tunnel model";
542 revision 2017-06-20 {
543 description
544 "Initial revision. This YANG file defines
545 the reusable base types for TE telemetry.";
546 reference
547 "Derived from earlier versions of base YANG files";
548 }
550 revision 2017-03-13 {
551 description
552 "Removed references to technology specific kpi.";
553 reference
554 "draft-lee-teas-actn-pm-telemetry-autonomics-00";
555 }
557 /*
558 * Identities
559 */
561 identity telemetry-param-type {
562 description
563 "Base identity for telemetry param types";
564 }
566 identity one-way-delay {
567 base telemetry-param-type;
568 description
569 "To specify average Delay in one (forward) direction";
570 }
571 identity two-way-delay {
572 base telemetry-param-type;
573 description
574 "To specify average Delay in both (forward and reverse)
575 directions";
576 }
578 identity one-way-delay-variation {
579 base telemetry-param-type;
580 description
581 "To specify average Delay Variation in one (forward)
582 direction";
583 }
585 identity two-way-delay-variation {
586 base telemetry-param-type;
587 description
588 "To specify average Delay Variation in both (forward
589 and reverse) directions";
590 }
592 identity utilized-bandwidth {
593 base telemetry-param-type;
594 description
595 "To specify utilized bandwidth over the specified source
596 and destination.";
597 }
599 /*
600 * Enums
601 */
602 typedef scaling-criteria-operation {
603 type enumeration {
604 enum AND {
605 description
606 "AND operation";
607 }
608 enum OR {
609 description
610 "OR operation";
611 }
612 }
613 description
614 "Operations to analize list of scaling criterias";
615 }
617 /*
618 * Groupings
619 */
621 grouping telemetry-delay {
622 description
623 "Base telemetry delay parameters";
625 leaf one-way-delay {
626 type uint32;
627 units "microseconds";
628 description
629 "To specify average Delay in one (forward) direction
630 during the measurement interval";
631 }
632 leaf two-way-delay {
633 type uint32;
634 units "microseconds";
635 description
636 "To specify average Delay in both (forward and reverse)
637 directions during the measurement interval";
638 }
640 leaf one-way-delay-min {
641 type uint32;
642 units "microseconds";
643 description
644 "To specify minimum Delay in one (forward) direction
645 during the measurement interval";
646 }
647 leaf one-way-delay-max {
648 type uint32;
649 units "microseconds";
650 description
651 "To specify maximum Delay in one (forward) direction
652 during the measurement interval";
653 }
655 leaf two-way-delay-min {
656 type uint32;
657 units "microseconds";
658 description
659 "To specify minimum Delay in both (forward and reverse)
660 directions during the measurement interval";
661 }
663 leaf two-way-delay-max {
664 type uint32;
665 units "microseconds";
666 description
667 "To specify maximum Delay in both (forward and reverse)
668 directions during the measurement interval";
669 }
671 }
673 grouping telemetry-delay-variance {
675 description
676 "Base telemetry delay variance parameters";
677 leaf one-way-delay-variation {
678 type uint32;
679 units "microseconds";
680 description
681 "To specify average Delay Variation in one (forward)
682 direction during the measurement interval";
683 }
685 leaf two-way-delay-variation {
686 type uint32;
687 units "microseconds";
688 description
689 "To specify average Delay Variation in both
690 (forward and reverse) directions during the
691 measurement interval";
692 }
693 }
695 grouping telemetry-bandwidth {
696 description
697 "Base telemetry bandwidth parameters";
698 leaf utilized-bandwidth {
699 type tet:te-bandwidth;
700 description
701 "To specify utilized bandwidth over the specified source
702 and destination in bytes per seconds.";
703 reference
704 "RFC 3471";
705 }
706 }
708 grouping scaling-criteria {
709 description
710 "Grouping for scaling criteria";
711 leaf performance-type {
712 type identityref {
713 base telemetry-param-type;
714 }
715 description
716 "Reference to the tunnel level telemetry type";
717 }
719 leaf performance-data {
720 type binary;
721 description
722 "The encoding and meaning of this field is
723 based on the performance-type";
724 }
725 }
726 grouping scaling-intent {
727 description
728 "Basic scaling intent";
730 container scale-in {
731 description
732 "Basic scaling-in intent";
734 leaf scale-in-operation-type {
735 type scaling-criteria-operation;
736 default AND;
737 description
738 "Operation to be applied to check between
739 scaling criterias to check if the scale in
740 threshold condition has been met.
741 Defaults to AND";
742 }
744 leaf threshold-time {
745 type uint32;
746 units "seconds";
747 description
748 "The duration for which the criteria must
749 hold true";
750 }
752 list scale-in-condition {
753 key "performance-type";
754 description
755 "Scaling conditions";
756 uses scaling-criteria;
757 }
758 }
759 container scale-down {
760 description
761 "Basic scaling-out intent";
762 leaf cooldown-time {
763 type uint32;
764 units "seconds";
765 description
766 "The duration after a scaling-in/scaling-out action
767 has been triggered, for which there will be no
768 further operation";
769 }
770 leaf scale-out-operation-type {
771 type scaling-criteria-operation;
772 default OR;
773 description
774 "Operation to be applied to check between
775 scaling criterias to check if the scale out
776 threshold condition has been met.
777 Defauls to OR";
778 }
779 list scale-out-condition {
780 key "performance-type";
781 description
782 "Scaling conditions";
783 uses scaling-criteria;
784 }
786 }
788 }
790 grouping telemetry-param {
792 description
793 "Base telemetry parameters";
794 container data {
795 description
796 "The telemetry data";
798 uses telemetry-delay;
800 uses telemetry-delay-variance;
802 uses telemetry-bandwidth;
803 }
805 }
807 /*
808 * Augments
809 */
810 augment "/te:te/te:tunnels/te:tunnel/te:config" {
812 description
813 "Augmentation parameters for config scaling-criteria
814 TE tunnel topologies. Scale in/out criteria might be
815 used for network autonomics in order the controller
816 to react to a certain set of monitored params.";
818 container te-scaling-intent {
819 description
820 "scaling intent";
821 uses scaling-intent;
823 }
825 }
827 augment "/te:te/te:tunnels/te:tunnel/te:state" {
829 description
830 "Augmentation parameters for state TE tunnel
831 topologies.";
833 container te-telemetry {
834 description
835 "telemetry params";
836 uses telemetry-param;
837 }
838 }
840 }//module
842
844 ietf-actn-te-kpi-telemetry model
846 The YANG code is as follows:
848 file "ietf-actn-te-kpi-telemetry@2017-06-20.yang"
850 module ietf-actn-te-kpi-telemetry {
852 namespace
853 "urn:ietf:params:xml:ns:yang:ietf-actn-te-kpi-telemetry";
855 prefix "actn-tel";
857 import ietf-actn-vn {
858 prefix "actn-vn";
859 }
861 import ietf-te-kpi-telemetry {
862 prefix "te-kpi";
863 }
865 organization
866 "IETF Traffic Engineering Architecture and Signaling (TEAS)
867 Working Group";
869 contact
870 "Editor: Young Lee
871 Editor: Dhruv Dhody
872 Editor: Ricard Vilalta
873 Editor: Satish Karunanithi ";
875 description
876 "This module describes telemetry for actn vn model";
878 revision 2017-06-20 {
879 description
880 "Removed references to technology specific kpi.";
881 reference
882 "draft-lee-teas-actn-pm-telemetry-autonomics-01";
883 }
885 revision 2017-03-13 {
886 description
887 "Initial revision. This YANG file defines
888 the ACTN VN telemetry.";
889 reference
890 "Derived from earlier versions of base YANG files";
891 }
893 /*
894 * Identities
895 */
897 identity grouping-operation {
898 description "Base identity for operations to analize list of monitored param";
899 }
901 identity minimum-grouping-operation {
902 base grouping-operation;
903 description
904 "Select the minimum param";
905 }
907 identity maximum-grouping-operation {
908 base grouping-operation;
909 description
910 "Select the maximum param";
911 }
913 identity mean-grouping-operation {
914 base grouping-operation;
915 description
916 "Select the MEAN of the params";
917 }
919 identity stddev-grouping-operation {
920 base grouping-operation;
921 description
922 "Select the STD deviation of the params";
923 }
925 identity sum-grouping-operation {
926 base grouping-operation;
927 description
928 "Select the sum of the params";
929 reference
930 "RFC 7823";
931 }
933 /*
934 * Groupings
935 */
936 grouping vn-telemetry-param {
937 description
938 "telemetry-parameter for VN";
939 uses te-kpi:telemetry-param;
940 }
941 grouping telemetry-grouping-op {
942 description
943 "Config how the VN telemetry should be applied";
944 container grouping-op {
945 description
946 "The grouping operations";
947 leaf delay-op {
948 type identityref {
949 base grouping-operation;
950 }
951 default maximum-grouping-operation;
952 description
953 "The operation that should be applied on the
954 VN-member telemetry to get the VN telemetry";
955 }
956 leaf delay-variation-op {
957 type identityref {
958 base grouping-operation;
959 }
960 default maximum-grouping-operation;
961 description
962 "The operation that should be applied on the
963 VN-member telemetry to get the VN telemetry";
964 }
966 leaf utilized-bandwidth-op {
967 type identityref {
968 base grouping-operation;
969 }
970 default maximum-grouping-operation;
971 description
972 "The operation that should be applied on the
973 VN-member telemetry to get the VN telemetry";
974 }
975 }
977 }
979 /*
980 * Augments
981 */
982 augment "/actn-vn:actn/actn-vn:vn/actn-vn:vn-list" {
984 description
985 "Augmentation parameters for state TE VN topologies.";
987 container vn-telemetry {
988 description
989 "VN telemetry configurations";
990 uses telemetry-grouping-op;
991 }
992 container vn-scaling-intent {
993 description
994 "scaling intent";
995 uses te-kpi:scaling-intent;
996 }
997 }
998 augment "/actn-vn:actn-state/actn-vn:vn/actn-vn:vn-list" {
1000 description
1001 "Augmentation parameters for state TE VN topologies.";
1003 container vn-telemetry {
1004 description
1005 "VN telemetry params";
1006 uses telemetry-grouping-op;
1007 uses vn-telemetry-param;
1008 }
1009 container vn-scaling-intent {
1010 description
1011 "scaling intent";
1012 uses te-kpi:scaling-intent;
1013 }
1014 }
1016 /*
1017 * VN-member augment
1018 */
1019 augment "/actn-vn:actn/actn-vn:vn/actn-vn:vn-list/" +
1020 "actn-vn:vn-member-list" {
1021 description
1022 "Augmentation parameters for state TE vn member
1023 topologies.";
1024 container vn-telemetry {
1025 description
1026 "VN Member config";
1027 uses telemetry-grouping-op;
1028 }
1029 }
1030 augment "/actn-vn:actn-state/actn-vn:vn/actn-vn:vn-list/" +
1031 "actn-vn:vn-member-list" {
1032 description
1033 "Augmentation parameters for state TE vn member
1034 topologies.";
1035 container vn-telemetry {
1036 description
1037 "VN telemetry params";
1038 uses telemetry-grouping-op;
1039 uses vn-telemetry-param;
1040 }
1041 }
1042 }
1043
1045 7. Security Considerations
1047 The configuration, state, and action data defined in this document
1048 are designed to be accessed via a management protocol with a secure
1049 transport layer, such as NETCONF [RFC6241]. The NETCONF access
1050 control model [RFC6536] provides the means to restrict access for
1051 particular NETCONF users to a preconfigured subset of all available
1052 NETCONF protocol operations and content.
1054 A number of configuration data nodes defined in this document are
1055 writable/deletable (i.e., "config true") These data nodes may be
1056 considered sensitive or vulnerable in some network environments.
1058 8. IANA Considerations
1060 TDB
1062 9. Acknowledgements
1064 10. References
1066 Informative References
1068 [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3
1069 Provider-Provisioned Virtual Private Networks (PPVPNs)",
1070 RFC 4110, July 2005.
1072 [RFC6020] M. Bjorklund, Ed., "YANG - A Data Modeling Language for
1073 the Network Configuration Protocol (NETCONF)", RFC 6020,
1074 October 2010.
1076 [Service-YANG] Q. Wu, W. Liu and A. Farrel, "Service Models
1077 Explained", draft-wu-opsawg-service-model-explained, work
1078 in progress.
1080 [Netmod-Yang-Model-Classification] D. Bogdanovic, B. Claise, and C.
1081 Moberg, "YANG Module Classification", draft-ietf-netmod-
1082 yang-model-classification, work in progress.
1084 [Netconf] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
1085 and A. Bierman, Ed., "Network Configuration Protocol
1086 (NETCONF)", RFC 6241.
1088 [Restconf] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF
1089 Protocol", draft-ietf-netconf-restconf, work in progress.
1091 Normative References
1093 [ACTN-Frame] D. Cecarelli and Y. Lee, "Framework for Abstraction and
1094 Control of Traffic Engineered Networks", draft-ietf-teas-
1095 actn-framework, work in progress.
1097 [TE-Topology] X. Liu, et al., "YANG Data Model for TE Topologies",
1098 draft-ietf-teas-yang-te-topo, work in progress.
1100 [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic
1101 Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
1102 te, work in progress.
1104 [ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN
1105 Operation", draft-lee-teas-actn-vn-yang, work in progress.
1107 [L3SM-YANG] S. Litkowski, L.Tomotaki, and K. Ogaki, "YANG Data Model
1108 for L3VPN service delivery", draft-ietf-l3sm-l3vpn-
1109 service-model, work in progress.
1111 [PCEP-Service-Aware] D. Dhody, et al., "Extensions to the Path
1112 Computation Element Communication Protocol (PCEP) to
1113 compute service aware Label Switched Path (LSP)", draft-
1114 ietf-pce-pcep-service-aware, work in progress.
1116 [ACTN-PERF] Y. XU, et al., "Use Cases and Requirements of Dynamic
1117 Service Control based on Performance Monitoring in ACTN
1118 Architecture", draft-xu-actn-perf-dynamic-service-control-
1119 03, work in progress.
1121 11. Contributors
1123 Authors' Addresses
1125 Young Lee
1126 Huawei Technologies
1127 5340 Legacy Drive Suite 173
1128 Plano, TX 75024, USA
1130 Email: leeyoung@huawei.com
1132 Dhruv Dhody
1133 Huawei Technology
1134 Leela Palace
1135 Bangalore, Karnataka 560008
1136 India
1137 Email: dhruv.dhody@huawei.com
1139 Satish Karunanithi
1140 Huawei Technology
1141 Leela Palace
1142 Bangalore, Karnataka 560008
1143 India
1145 Email: satish.karunanithi@gmail.com
1147 Ricard Vilalta
1148 Centre Tecnologic de Telecomunicacions de Catalunya (CTTC/CERCA)
1149 Av. Carl Friedrich Gauss 7
1150 08860 - Castelldefels
1151 Barcelona (Spain)
1152 Email: ricard.vilalta@cttc.es
1154 Daniel King
1155 Lancaster University
1157 Email: d.king@lancaster.ac.uk
1159 Daniele Ceccarelli
1160 Ericsson
1161 Torshamnsgatan,48
1162 Stockholm, Sweden
1164 Email: daniele.ceccarelli@ericsson.com