idnits 2.17.1
draft-lee-teas-actn-pm-telemetry-autonomics-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
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 8 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 (March 13, 2017) is 2601 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 1100, but not defined
== Missing Reference: 'RFC6536' is mentioned on line 1101, but not defined
** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341)
== Unused Reference: 'RFC4110' is defined on line 1119, but no explicit
reference was found in the text
== Unused Reference: 'Netconf' is defined on line 1135, but no explicit
reference was found in the text
== Unused Reference: 'Restconf' is defined on line 1139, but no explicit
reference was found in the text
== Unused Reference: 'ACTN-Frame' is defined on line 1144, but no explicit
reference was found in the text
== Unused Reference: 'TE-Topology' is defined on line 1148, but no explicit
reference was found in the text
== Unused Reference: 'TE-Tunnel' is defined on line 1151, but no explicit
reference was found in the text
== Unused Reference: 'L3SM-YANG' is defined on line 1158, 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 March 13, 2017
16 YANG models for ACTN TE Performance Monitoring Telemetry and Network
17 Autonomics
19 draft-lee-teas-actn-pm-telemetry-autonomics-00
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 13, 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..............................21
84 7. Security Considerations.......................................26
85 8. IANA Considerations...........................................26
86 9. Acknowledgements..............................................26
87 10. References...................................................26
88 Informative References........................................26
89 Normative References..........................................27
90 11. Contributors.................................................27
91 Authors' Addresses...............................................28
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 one-way-packet-loss? decimal64
431 +--ro two-way-packet-loss? decimal64
432 +--ro utilized-bandwidth? rt:bandwidth-ieee-float32
434 module: ietf-actn-te-kpi-telemetry
435 augment /actn-vn:actn/actn-vn:vn/actn-vn:vn-list:
436 +--rw vn-telemetry
437 | +--rw grouping-op
438 | +--rw delay-op? grouping-operation
439 | +--rw delay-variation-op? grouping-operation
440 | +--rw packet-loss-op? grouping-operation
441 | +--rw utilized-bandwidth-op? grouping-operation
442 +--rw vn-scaling-intent
443 +--rw scale-in
444 | +--rw scale-in-operation-type?
445 | | scaling-criteria-operation
446 | +--rw threshold-time? uint32
447 | +--rw scale-in-condition* [performance-type]
448 | +--rw performance-type identityref
449 | +--rw performance-data? binary
450 +--rw scale-down
451 +--rw cooldown-time? uint32
452 +--rw scale-out-operation-type?
453 | scaling-criteria-operation
454 +--rw scale-out-condition* [performance-type]
455 +--rw performance-type identityref
456 +--rw performance-data? binary
457 augment /actn-vn:actn-state/actn-vn:vn/actn-vn:vn-list:
458 +--ro vn-telemetry
459 | +--ro grouping-op
460 | | +--ro delay-op? grouping-operation
461 | | +--ro delay-variation-op? grouping-operation
462 | | +--ro packet-loss-op? grouping-operation
463 | | +--ro utilized-bandwidth-op? grouping-operation
464 | +--ro data
465 | +--ro one-way-delay? uint32
466 | +--ro two-way-delay? uint32
467 | +--ro one-way-delay-min? uint32
468 | +--ro one-way-delay-max? uint32
469 | +--ro two-way-delay-min? uint32
470 | +--ro two-way-delay-max? uint32
471 | +--ro one-way-delay-variation? uint32
472 | +--ro two-way-delay-variation? uint32
473 | +--ro one-way-packet-loss? decimal64
474 | +--ro two-way-packet-loss? decimal64
475 | +--ro utilized-bandwidth? rt:bandwidth-ieee-float32
476 +--ro vn-scaling-intent
477 +--ro scale-in
478 | +--ro scale-in-operation-type?
479 | | scaling-criteria-operation
480 | +--ro threshold-time? uint32
481 | +--ro scale-in-condition* [performance-type]
482 | +--ro performance-type identityref
483 | +--ro performance-data? binary
484 +--ro scale-down
485 +--ro cooldown-time? uint32
486 +--ro scale-out-operation-type?
487 | scaling-criteria-operation
488 +--ro scale-out-condition* [performance-type]
489 +--ro performance-type identityref
490 +--ro performance-data? binary
491 augment /actn-vn:actn/actn-vn:vn/actn-vn:vn-list/actn-vn:vn-member-list:
492 +--rw vn-telemetry
493 +--rw grouping-op
494 +--rw delay-op? grouping-operation
495 +--rw delay-variation-op? grouping-operation
496 +--rw packet-loss-op? grouping-operation
497 +--rw utilized-bandwidth-op? grouping-operation
498 augment /actn-vn:actn-state/actn-vn:vn/actn-vn:vn-list/actn-vn:vn-member-list:
499 +--ro vn-telemetry
500 +--ro grouping-op
501 | +--ro delay-op? grouping-operation
502 | +--ro delay-variation-op? grouping-operation
503 | +--ro packet-loss-op? grouping-operation
504 | +--ro utilized-bandwidth-op? grouping-operation
505 +--ro data
506 +--ro one-way-delay? uint32
507 +--ro two-way-delay? uint32
508 +--ro one-way-delay-min? uint32
509 +--ro one-way-delay-max? uint32
510 +--ro two-way-delay-min? uint32
511 +--ro two-way-delay-max? uint32
512 +--ro one-way-delay-variation? uint32
513 +--ro two-way-delay-variation? uint32
514 +--ro one-way-packet-loss? decimal64
515 +--ro two-way-packet-loss? decimal64
516 +--ro utilized-bandwidth? rt:bandwidth-ieee-float32
518 6. Yang Data Model
520 ietf-te-kpi-telemetry model
522 The YANG code is as follows:
524 file "ietf-te-kpi-telemetry@2017-03-13.yang"
526 module ietf-te-kpi-telemetry {
527 namespace "urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry";
529 prefix "te-tel";
531 import ietf-te {
532 prefix "te";
533 }
535 import ietf-routing-types {
536 prefix "rt";
538 }
540 organization
541 "IETF Traffic Engineering Architecture and Signaling (TEAS)
542 Working Group";
544 contact
545 "Editor: Young Lee
546 Editor: Dhruv Dhody
547 Editor: Ricard Vilalta
548 Editor: Satish Karunanithi ";
550 description
551 "This module describes telemetry for teas tunnel model";
553 revision 2017-03-13 {
554 description
555 "Initial revision. This YANG file defines
556 the reusable base types for TE telemetry.";
557 reference
558 "Derived from earlier versions of base YANG files";
559 }
561 /*
562 * Identities
563 */
565 identity telemetry-param-type {
566 description
567 "Base identity for telemetry param types";
568 }
570 identity one-way-delay {
571 base telemetry-param-type;
572 description
573 "To specify average Delay in one (forward) direction";
574 }
576 identity two-way-delay {
577 base telemetry-param-type;
578 description
579 "To specify average Delay in both (forward and reverse)
580 directions";
581 }
583 identity one-way-delay-variation {
584 base telemetry-param-type;
585 description
586 "To specify average Delay Variation in one (forward)
587 direction";
588 }
590 identity two-way-delay-variation {
591 base telemetry-param-type;
592 description
593 "To specify average Delay Variation in both (forward
594 and reverse) directions";
595 }
597 identity one-way-packet-loss {
598 base telemetry-param-type;
599 description
600 "To specify packet loss in one (forward) direction.";
601 }
603 identity two-way-packet-loss {
604 base telemetry-param-type;
605 description
606 "To specify packet loss in in both (forward and reverse)
607 directions";
608 }
610 identity utilized-bandwidth {
611 base telemetry-param-type;
612 description
613 "To specify utilized bandwidth over the specified source
614 and destination.";
615 }
617 /*
618 * Enums
619 */
620 typedef scaling-criteria-operation {
621 type enumeration {
622 enum AND {
623 description
624 "AND operation";
625 }
626 enum OR {
627 description
628 "OR operation";
629 }
630 }
631 description
632 "Operations to analize list of scaling criterias";
633 }
635 /*
636 * Groupings
637 */
639 grouping telemetry-delay {
640 description
641 "Base telemetry delay parameters";
643 leaf one-way-delay {
644 type uint32;
645 units "microseconds";
646 description
647 "To specify average Delay in one (forward) direction
648 during the measurement interval";
649 }
651 leaf two-way-delay {
652 type uint32;
653 units "microseconds";
654 description
655 "To specify average Delay in both (forward and reverse)
656 directions during the measurement interval";
657 }
659 leaf one-way-delay-min {
660 type uint32;
661 units "microseconds";
662 description
663 "To specify minimum Delay in one (forward) direction
664 during the measurement interval";
665 }
667 leaf one-way-delay-max {
668 type uint32;
669 units "microseconds";
670 description
671 "To specify maximum Delay in one (forward) direction
672 during the measurement interval";
673 }
675 leaf two-way-delay-min {
676 type uint32;
677 units "microseconds";
678 description
679 "To specify minimum Delay in both (forward and reverse)
680 directions during the measurement interval";
681 }
683 leaf two-way-delay-max {
684 type uint32;
685 units "microseconds";
686 description
687 "To specify maximum Delay in both (forward and reverse)
688 directions during the measurement interval";
689 }
691 }
693 grouping telemetry-delay-variance {
695 description
696 "Base telemetry delay variance parameters";
697 leaf one-way-delay-variation {
698 type uint32;
699 units "microseconds";
700 description
701 "To specify average Delay Variation in one (forward)
702 direction during the measurement interval";
703 }
705 leaf two-way-delay-variation {
706 type uint32;
707 units "microseconds";
708 description
709 "To specify average Delay Variation in both
710 (forward and reverse) directions during the
711 measurement interval";
712 }
714 }
716 grouping telemetry-packet-loss {
718 description
719 "Base telemetry packet loss parameters";
720 leaf one-way-packet-loss {
721 type decimal64 {
722 fraction-digits 4;
723 range "0.0000..100.0000";
724 }
725 units "percent";
726 description
727 "To specify packet loss in one (forward) direction.";
728 }
730 leaf two-way-packet-loss {
731 type decimal64 {
732 fraction-digits 4;
733 range "0.0000..100.0000";
734 }
735 units "percent";
736 description
737 "To specify packet loss in in both (forward and reverse)
738 directions";
739 }
740 }
742 grouping telemetry-bandwidth {
743 description
744 "Base telemetry bandwidth parameters";
745 leaf utilized-bandwidth {
746 type rt:bandwidth-ieee-float32;
747 description
748 "To specify utilized bandwidth over the specified source
749 and destination in bytes per seconds.";
750 reference
751 "RFC 3471";
752 }
753 }
755 grouping scaling-criteria {
756 description
757 "Grouping for scaling criteria";
758 leaf performance-type {
759 type identityref {
760 base telemetry-param-type;
761 }
762 description
763 "Reference to the tunnel level telemetry type";
764 }
766 leaf performance-data {
767 type binary;
768 description
769 "The encoding and meaning of this field is
770 based on the performance-type";
771 }
772 }
774 grouping scaling-intent {
775 description
776 "Basic scaling intent";
778 container scale-in {
779 description
780 "Basic scaling-in intent";
782 leaf scale-in-operation-type {
783 type scaling-criteria-operation;
784 default AND;
785 description
786 "Operation to be applied to check between
787 scaling criterias to check if the scale in
788 threshold condition has been met.
789 Defaults to AND";
790 }
792 leaf threshold-time {
793 type uint32;
794 units "seconds";
795 description
796 "The duration for which the criteria must
797 hold true";
798 }
800 list scale-in-condition {
801 key "performance-type";
802 description
803 "Scaling conditions";
804 uses scaling-criteria;
805 }
806 }
807 container scale-down {
808 description
809 "Basic scaling-out intent";
810 leaf cooldown-time {
811 type uint32;
812 units "seconds";
813 description
814 "The duration after a scaling-in/scaling-out action
815 has been triggered, for which there will be no
816 further operation";
817 }
818 leaf scale-out-operation-type {
819 type scaling-criteria-operation;
820 default OR;
821 description
822 "Operation to be applied to check between
823 scaling criterias to check if the scale out
824 threshold condition has been met.
825 Defauls to OR";
826 }
827 list scale-out-condition {
828 key "performance-type";
829 description
830 "Scaling conditions";
831 uses scaling-criteria;
832 }
834 }
836 }
838 grouping telemetry-param {
840 description
841 "Base telemetry parameters";
842 container data {
843 description
844 "The telemetry data";
846 uses telemetry-delay;
848 uses telemetry-delay-variance;
850 uses telemetry-packet-loss;
852 uses telemetry-bandwidth;
853 }
855 }
857 /*
858 * Augments
859 */
860 augment "/te:te/te:tunnels/te:tunnel/te:config" {
862 description
863 "Augmentation parameters for config scaling-criteria
864 TE tunnel topologies. Scale in/out criteria might be
865 used for network autonomics in order the controller
866 to react to a certain set of monitored params.";
868 container te-scaling-intent {
869 description
870 "scaling intent";
871 uses scaling-intent;
873 }
875 }
877 augment "/te:te/te:tunnels/te:tunnel/te:state" {
879 description
880 "Augmentation parameters for state TE tunnel
881 topologies.";
883 container te-telemetry {
884 description
885 "telemetry params";
886 uses telemetry-param;
887 }
888 }
890 }//module
892
894 ietf-actn-te-kpi-telemetry model
896 The YANG code is as follows:
898 file "ietf-actn-te-kpi-telemetry@2017-03-13.yang"
900 module ietf-actn-te-kpi-telemetry {
902 namespace
903 "urn:ietf:params:xml:ns:yang:ietf-actn-te-kpi-telemetry";
905 prefix "actn-tel";
907 import ietf-actn-vn {
908 prefix "actn-vn";
909 }
911 import ietf-te-kpi-telemetry {
912 prefix "te-kpi";
913 }
915 organization
916 "IETF Traffic Engineering Architecture and Signaling (TEAS)
917 Working Group";
919 contact
920 "Editor: Young Lee
921 Editor: Dhruv Dhody
922 Editor: Ricard Vilalta
923 Editor: Satish Karunanithi ";
925 description
926 "This module describes telemetry for actn vn model";
928 revision 2017-03-13 {
929 description
930 "Initial revision. This YANG file defines
931 the ACTN VN telemetry.";
932 reference
933 "Derived from earlier versions of base YANG files";
934 }
936 /*
937 * Typedefs
938 */
940 typedef grouping-operation {
941 type enumeration {
942 enum MINIMUM {
943 description
944 "Select the minimum param";
946 }
947 enum MAXIMUM {
948 description
949 "Select the maximum param";
950 }
951 enum MEAN {
952 description
953 "Select the MEAN of the params";
954 }
955 enum STD_DEV {
956 description
957 "Select the standard deviation of the
958 monitored params";
959 }
960 enum SUM {
961 description
962 "Select the sum of the monitored params";
963 reference
964 "RFC 7823";
965 }
966 enum LOSS_PERCENT {
967 description
968 "Select the packet loss percentage
969 calulation";
970 reference
971 "RFC 7823";
972 }
973 }
974 description
975 "Operations to analize list of monitored params";
976 }
978 /*
979 * Groupings
980 */
981 grouping vn-telemetry-param {
982 description
983 "telemetry-parameter for VN";
984 uses te-kpi:telemetry-param;
985 }
987 grouping telemetry-grouping-op {
988 description
989 "Config how the VN telemetry should be applied";
990 container grouping-op {
991 description
992 "The grouping operations";
993 leaf delay-op {
994 type grouping-operation;
995 default MAXIMUM;
996 description
997 "The operation that should be applied on the
998 VN-member telemetry to get the VN telemetry";
999 }
1001 leaf delay-variation-op {
1002 type grouping-operation;
1003 default MAXIMUM;
1004 description
1005 "The operation that should be applied on the
1006 VN-member telemetry to get the VN telemetry";
1007 }
1009 leaf packet-loss-op {
1010 type grouping-operation;
1011 default MAXIMUM;
1012 description
1013 "The operation that should be applied on the
1014 VN-member telemetry to get the VN telemetry";
1015 }
1017 leaf utilized-bandwidth-op {
1018 type grouping-operation;
1019 default MAXIMUM;
1020 description
1021 "The operation that should be applied on the
1022 VN-member telemetry to get the VN telemetry";
1023 }
1024 }
1026 }
1028 /*
1029 * Augments
1030 */
1031 augment "/actn-vn:actn/actn-vn:vn/actn-vn:vn-list" {
1033 description
1034 "Augmentation parameters for state TE VN topologies.";
1036 container vn-telemetry {
1037 description
1038 "VN telemetry configurations";
1039 uses telemetry-grouping-op;
1040 }
1041 container vn-scaling-intent {
1042 description
1043 "scaling intent";
1044 uses te-kpi:scaling-intent;
1045 }
1046 }
1047 augment "/actn-vn:actn-state/actn-vn:vn/actn-vn:vn-list" {
1049 description
1050 "Augmentation parameters for state TE VN topologies.";
1052 container vn-telemetry {
1053 description
1054 "VN telemetry params";
1055 uses telemetry-grouping-op;
1056 uses vn-telemetry-param;
1057 }
1058 container vn-scaling-intent {
1059 description
1060 "scaling intent";
1061 uses te-kpi:scaling-intent;
1062 }
1063 }
1065 /*
1066 * VN-member augment
1067 */
1068 augment "/actn-vn:actn/actn-vn:vn/actn-vn:vn-list/" +
1069 "actn-vn:vn-member-list" {
1070 description
1071 "Augmentation parameters for state TE vn member
1072 topologies.";
1073 container vn-telemetry {
1074 description
1075 "VN Member config";
1076 uses telemetry-grouping-op;
1077 }
1078 }
1079 augment "/actn-vn:actn-state/actn-vn:vn/actn-vn:vn-list/" +
1080 "actn-vn:vn-member-list" {
1081 description
1082 "Augmentation parameters for state TE vn member
1083 topologies.";
1084 container vn-telemetry {
1085 description
1086 "VN telemetry params";
1087 uses telemetry-grouping-op;
1088 uses vn-telemetry-param;
1089 }
1090 }
1092 }
1094
1096 7. Security Considerations
1098 The configuration, state, and action data defined in this document
1099 are designed to be accessed via a management protocol with a secure
1100 transport layer, such as NETCONF [RFC6241]. The NETCONF access
1101 control model [RFC6536] provides the means to restrict access for
1102 particular NETCONF users to a preconfigured subset of all available
1103 NETCONF protocol operations and content.
1105 A number of configuration data nodes defined in this document are
1106 writable/deletable (i.e., "config true") These data nodes may be
1107 considered sensitive or vulnerable in some network environments.
1109 8. IANA Considerations
1111 TDB
1113 9. Acknowledgements
1115 10. References
1117 Informative References
1119 [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3
1120 Provider-Provisioned Virtual Private Networks (PPVPNs)",
1121 RFC 4110, July 2005.
1123 [RFC6020] M. Bjorklund, Ed., "YANG - A Data Modeling Language for
1124 the Network Configuration Protocol (NETCONF)", RFC 6020,
1125 October 2010.
1127 [Service-YANG] Q. Wu, W. Liu and A. Farrel, "Service Models
1128 Explained", draft-wu-opsawg-service-model-explained, work
1129 in progress.
1131 [Netmod-Yang-Model-Classification] D. Bogdanovic, B. Claise, and C.
1132 Moberg, "YANG Module Classification", draft-ietf-netmod-
1133 yang-model-classification, work in progress.
1135 [Netconf] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
1136 and A. Bierman, Ed., "Network Configuration Protocol
1137 (NETCONF)", RFC 6241.
1139 [Restconf] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF
1140 Protocol", draft-ietf-netconf-restconf, work in progress.
1142 Normative References
1144 [ACTN-Frame] D. Cecarelli and Y. Lee, "Framework for Abstraction and
1145 Control of Traffic Engineered Networks", draft-ietf-teas-
1146 actn-framework, work in progress.
1148 [TE-Topology] X. Liu, et al., "YANG Data Model for TE Topologies",
1149 draft-ietf-teas-yang-te-topo, work in progress.
1151 [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic
1152 Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
1153 te, work in progress.
1155 [ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN
1156 Operation", draft-lee-teas-actn-vn-yang, work in progress.
1158 [L3SM-YANG] S. Litkowski, L.Tomotaki, and K. Ogaki, "YANG Data Model
1159 for L3VPN service delivery", draft-ietf-l3sm-l3vpn-
1160 service-model, work in progress.
1162 [PCEP-Service-Aware] D. Dhody, et al., "Extensions to the Path
1163 Computation Element Communication Protocol (PCEP) to
1164 compute service aware Label Switched Path (LSP)", draft-
1165 ietf-pce-pcep-service-aware, work in progress.
1167 [ACTN-PERF] Y. XU, et al., "Use Cases and Requirements of Dynamic
1168 Service Control based on Performance Monitoring in ACTN
1169 Architecture", draft-xu-actn-perf-dynamic-service-control-
1170 03, work in progress.
1172 11. Contributors
1173 Authors' Addresses
1175 Young Lee
1176 Huawei Technologies
1177 5340 Legacy Drive Suite 173
1178 Plano, TX 75024, USA
1180 Email: leeyoung@huawei.com
1182 Dhruv Dhody
1183 Huawei Technology
1184 Leela Palace
1185 Bangalore, Karnataka 560008
1186 India
1188 Email: dhruv.dhody@huawei.com
1190 Satish Karunanithi
1191 Huawei Technology
1192 Leela Palace
1193 Bangalore, Karnataka 560008
1194 India
1196 Email: satish.karunanithi@gmail.com
1198 Ricard Vilalta
1199 Centre Tecnologic de Telecomunicacions de Catalunya (CTTC/CERCA)
1200 Av. Carl Friedrich Gauss 7
1201 08860 - Castelldefels
1202 Barcelona (Spain)
1203 Email: ricard.vilalta@cttc.es
1205 Daniel King
1206 Lancaster University
1208 Email: d.king@lancaster.ac.uk
1210 Daniele Ceccarelli
1211 Ericsson
1212 Torshamnsgatan,48
1213 Stockholm, Sweden
1215 Email: daniele.ceccarelli@ericsson.com