idnits 2.17.1
draft-lee-teas-actn-pm-telemetry-autonomics-08.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== The page length should not exceed 58 lines per page, but there was 2
longer pages, the longest (page 10) being 61 lines
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 21 instances of too long lines in the document, the longest
one being 17 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 374 has weird spacing: '...lemetry xmlns...'
-- The document date (October 5, 2018) is 2027 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'TE-tunnel' is mentioned on line 140, but not defined
== Missing Reference: 'TE-Types' is mentioned on line 141, but not defined
== Missing Reference: 'This I-D' is mentioned on line 142, but not defined
== Missing Reference: 'I-D.ietf-netconf-yang-push' is mentioned on line
311, but not defined
== Missing Reference: 'I-D.ietf-netconf-rfc5277bis' is mentioned on line
312, but not defined
== Missing Reference: 'RFC6241' is mentioned on line 905, but not defined
== Missing Reference: 'RFC6536' is mentioned on line 906, but not defined
** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341)
== Unused Reference: 'RFC4110' is defined on line 924, but no explicit
reference was found in the text
== Unused Reference: 'Netconf' is defined on line 940, but no explicit
reference was found in the text
== Unused Reference: 'Restconf' is defined on line 944, but no explicit
reference was found in the text
== Unused Reference: 'ACTN-Frame' is defined on line 956, but no explicit
reference was found in the text
== Unused Reference: 'TE-Topology' is defined on line 960, but no explicit
reference was found in the text
== Unused Reference: 'TE-Tunnel' is defined on line 963, but no explicit
reference was found in the text
== Unused Reference: 'L3SM-YANG' is defined on line 970, but no explicit
reference was found in the text
** Downref: Normative reference to an Informational draft:
draft-ietf-teas-actn-framework (ref. 'ACTN-Frame')
-- Possible downref: Normative reference to a draft: ref. 'ACTN-PERF'
Summary: 3 errors (**), 0 flaws (~~), 17 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 TEAS Working Group Y. Lee (Editor)
2 Internet Draft Dhruv Dhody
3 Intended Status: Standard Track Satish Karunanithi
4 Expires: April 6, 2019 Huawei
5 Ricard Vilalta
6 CTTC
7 Daniel King
8 Lancaster University
9 Daniele Ceccarelli
10 Ericsson
12 October 5, 2018
14 YANG models for ACTN TE Performance Monitoring Telemetry and Network
15 Autonomics
17 draft-lee-teas-actn-pm-telemetry-autonomics-08
19 Status of this Memo
21 This Internet-Draft is submitted to IETF in full conformance with
22 the provisions of BCP 78 and BCP 79.
24 Internet-Drafts are working documents of the Internet Engineering
25 Task Force (IETF), its areas, and its working groups. Note that
26 other groups may also distribute working documents as Internet-
27 Drafts.
29 Internet-Drafts are draft documents valid for a maximum of six
30 months and may be updated, replaced, or obsoleted by other documents
31 at any time. It is inappropriate to use Internet-Drafts as
32 reference material or to cite them other than as "work in progress."
34 The list of current Internet-Drafts can be accessed at
35 http://www.ietf.org/ietf/1id-abstracts.txt
37 The list of Internet-Draft Shadow Directories can be accessed at
38 http://www.ietf.org/shadow.html.
40 This Internet-Draft will expire on April 6, 2019.
42 Copyright Notice
44 Copyright (c) 2018 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (http://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with
52 respect to this document. Code Components extracted from this
53 document must include Simplified BSD License text as described in
54 Section 4.e of the Trust Legal Provisions and are provided without
55 warranty as described in the Simplified BSD License.
57 Abstract
59 Abstraction and Control of TE Networks (ACTN) refers to the set of
60 virtual network operations needed to operate, control and manage
61 large-scale multi-domain, multi-layer and multi-vendor TE networks,
62 so as to facilitate network programmability, automation, efficient
63 resource sharing.
65 This document provides YANG data models that describe Key
66 Performance Indicator (KPI) telemetry and network autonomics for TE-
67 tunnels and ACTN VNs.
69 Table of Contents
71 1. Introduction...................................................3
72 1.1. Terminology...............................................3
73 1.2. Tree Structure - Legend...................................3
74 2. Use-Cases......................................................4
75 3. Design of the Data Models......................................5
76 3.1. TE KPI Telemetry Model....................................6
77 3.2. ACTN TE KPI Telemetry Model...............................6
78 4. Notification...................................................8
79 4.1. YANG Push Subscription Examples...........................8
80 5. YANG Data Tree.................................................9
81 6. Yang Data Model...............................................11
82 6.1. ietf-te-kpi-telemetry model..............................11
83 6.2. ietf-actn-te-kpi-telemetry model.........................17
84 7. Security Considerations.......................................21
85 8. IANA Considerations...........................................21
86 9. Acknowledgements..............................................21
87 10. References...................................................21
88 10.1. Informative References..................................21
89 10.2. Normative References....................................22
90 11. Contributors.................................................23
91 Authors' Addresses...............................................23
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] describes how customers or end to end orchestrators can
110 request and/or instantiate a generic virtual network service. [ACTN-
111 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 1.1. Terminology
124 1.2. Tree Structure - Legend
126 A simplified graphical representation of the data model is used in
127 Section 5 of this this document. The meaning of the symbols in
128 these diagrams is defined in [RFC8342].
130 1.3. Prefixes in Data Node Names
132 In this document, names of data nodes and other data model objects
133 are prefixed using the standard prefix associated with the
134 corresponding YANG imported modules, as shown in Table 1.
136 +---------+------------------------------+-----------------+
137 | Prefix | YANG module | Reference |
138 +---------+------------------------------+-----------------+
139 | rt | ietf-routing-types | [Routing-Types] |
140 | te | ietf-te | [TE-tunnel] |
141 | te-types| ietf-te-types | [TE-Types] |
142 | te-kpi | ietf-te-kpi-telemetry | [This I-D] |
143 | vn | ietf-actn-vn | [ACTN-VN] |
144 | actn-tel| ietf-actn-te-kpi-telemetry | {This I-D] |
145 +---------+------------------------------+-----------------+
147 Table 1: Prefixes and corresponding YANG modules
149 2. Use-Cases
151 [ACTN-PERF] describes use-cases relevant to this draft. It
152 introduces the dynamic creation, modification and optimization of
153 services based on the performance monitoring in the Abstraction and
154 Control of Transport Networks (ACTN) architecture. Figure 1 shows a
155 high-level workflows for dynamic service control based on traffic
156 monitoring.
158 Some of the key points from [ACTN-PERF] are as follows:
160 . Network traffic monitoring is important to facilitate automatic
161 discovery of the imbalance of network traffic, and initiate the
162 network optimization, thus helping the network operator or the
163 virtual network service provider to use the network more
164 efficiently and save CAPEX/OPEX.
165 . Customer services have various SLA requirements, such as
166 service availability, latency, latency jitter, packet loss
167 rate, BER, etc. The transport network can satisfy service
168 availability and BER requirements by providing different
169 protection and restoration mechanisms. However, for other
170 performance parameters, there are no such mechanisms. In order
171 to provide high quality services according to customer SLA, one
172 possible solution is to measure the service SLA related
173 performance parameters, and dynamically provision and optimize
174 services based on the performance monitoring results.
175 . Performance monitoring in a large scale network could generate
176 a huge amount of performance information. Therefore, the
177 appropriate way to deliver the information in CMI and MPI
178 interfaces should be carefully considered.
180 +-------------------------------------------+
181 | CNC +-----------------------------+ |
182 | | Dynamic Service Control APP | |
183 | +-----------------------------+ |
184 +-------------------------------------------+
185 1.Traffic| /|\4.Traffic | /|\
186 Monitor& | | Monitor | | 8.Traffic
187 Optimize | | Result 5.Service | | modify &
188 Policy | | modify& | | optimize
189 \|/ | optimize Req.\|/ | result
190 +------------------------------------------------+
191 | MDSC +-------------------------------+ |
192 | |Dynamic Service Control Agent | |
193 | +-------------------------------+ |
194 | +---------------+ +-------------------+ |
195 | | Flow Optimize | | vConnection Agent | |
196 | +---------------+ +-------------------+ |
197 +------------------------------------------------+
198 2. Path | /|\3.Traffic | |
199 Monitor | | Monitor | |7.Path
200 Request | | Result 6.Path | | modify &
201 | | modify& | | optimize
202 \|/ | optimize Req.\|/ | result
203 +-------------------------------------------------------+
204 | PNC +----------------------+ +----------------------+ |
205 | | Network Provisioning | |Abstract Topology Gen.| |
206 | +----------------------+ +----------------------+ |
207 | +------------------+ +--------------------+ |
208 | |Network Monitoring| |Physical Topology DB| |
209 | +------------------+ +--------------------+ |
210 +-------------------------------------------------------+
212 Figure 1 Workflows for dynamic service control based on traffic
213 monitoring
215 3. Design of the Data Models
217 The YANG models developed in this document describe two models:
219 (i) TE KPI Telemetry Model which provides the TE-Tunnel level of
220 performance monitoring mechanism (See Section 4 for details)
222 (ii) ACTN TE KPI Telemetry Model which provides the VN level of the
223 aggregated performance monitoring mechanism (See Section 5
224 for details)
226 The models include -
228 (i) Performance Telemetry details as measured during the last
229 interval, ex delay.
231 (ii) Scaling Intent based on with TE/VN could be scaled in/out.
233 [Editor's Note - Need to decide if scaling and telemetry can be in
234 the same model as per the current draft.]
236 3.1. TE KPI Telemetry Model
238 This module describes performance telemetry for TE-tunnel model. The
239 telemetry data is augmented to tunnel state. This module also
240 allows autonomic traffic engineering scaling intent configuration
241 mechanism on the TE-tunnel level. Various conditions can be set for
242 auto-scaling based on the telemetry data.
244 The TE KPI Telemetry Model augments the TE-Tunnel Model to enhance
245 TE performance monitoring capability. This monitoring capability
246 will facilitate proactive re-optimization and reconfiguration of TEs
247 based on the performance monitoring data collected via the TE KPI
248 Telemetry YANG model.
250 +------------+ +--------------+
251 | TE-Tunnel | | TE KPI |
252 | Model |<---------| Telemetry |
253 +------------+ augments | Model |
254 +--------------+
256 3.2. ACTN TE KPI Telemetry Model
258 This module describes performance telemetry for ACTN VN model. The
259 telemetry data is augmented both at the VN Level as well as
260 individual VN member level. This module also allows autonomic
261 traffic engineering scaling intent configuration mechanism on the VN
262 level. Scale in/out criteria might be used for network autonomics in
263 order the controller to react to a certain set of variations in
264 monitored parameters.
266 Moreover, this module also provides mechanism to define aggregated
267 telemetry parameters as a grouping of underlying VN level telemetry
268 parameters. Grouping operation (such as maximum, mean) could be set
269 at the time of configuration. For example, if maximum grouping
270 operation is used for delay at the VN level, the VN telemetry data
271 is reported as the maximum {delay_vn_member_1, delay_vn_member_2,..
272 delay_vn_member_N}. Thus, this telemetry abstraction mechanism
273 allows the grouping of a certain common set of telemetry values
274 under a grouping operation. This can be done at the VN-member level
275 to suggest how the E2E telemetry be inferred from the per domain
276 tunnel created and monitored by PNCs. One proposed example is the
277 following:
279 +------------------------------------------------------------+
280 | CNC |
281 | |
282 +------------------------------------------------------------+
284 1.CNC sets the | /|\ 2. MDSC gets VN Telemetry
285 grouping op, and | |
286 subscribes to the | | VN KPI TELEMETRY (VN Level)
287 VN level telemetry for | | VN Utilized-bw-percentage:
288 Delay and | | Minimum across VN Members
289 Utilized-bw-pecentage | | VN Delay: Maximum across VN
290 \|/ | Members
291 +------------------------------------------------------------+
292 | MDSC |
293 | |
294 +------------------------------------------------------------+
296 The ACTN VN TE-Telemetry Model augments the basic ACTN VN model to
297 enhance VN monitoring capability. This monitoring capability will
298 facilitate proactive re-optimization and reconfiguration of VNs
299 based on the performance monitoring data collected via the ACTN VN
300 Telemetry YANG model.
302 +----------+ +--------------+
303 | ACTN VN | augments | ACTN |
304 | Model |<---------| TE-Telemetry |
305 +----------+ | Model |
306 +--------------+
308 4. Notification
310 This model does not define specific notifications. To enable
311 notifications, the mechanism defined in [I-D.ietf-netconf-yang-push]
312 and [I-D.ietf-netconf-rfc5277bis] can be used. This mechanism
313 currently allows the user to:
315 . Subscribe notifications on a per client basis.
317 . Specify subtree filters or xpath filters so that only interested
318 contents will be sent.
320 . Specify either periodic or on-demand notifications.
322 4.1. YANG Push Subscription Examples
324 Below example shows the way for a client to subscribe for the
325 telemetry information for a particular tunnel (Tunnel1). The
326 telemetry parameter that the client is interested in is the utilized
327 bandwidth percentage.
329
331
333
334
335
336
337 Tunnel1
338
339
340
342
345
346
347
349
350
351
352 500
353 encode-xml
354
355
357 This example shows the way for a client to subscribe for the
358 telemetry information for all VNs. The telemetry parameter that the
359 client is interested in is one-way delay and utilized bandwidth
360 percentage.
362
364
366
367
369
370
371
372
373
376
377
380
381
382
383
384
385 500
386
387
389 5. YANG Data Tree
390 module: ietf-te-kpi-telemetry
391 augment /te:te/te:tunnels/te:tunnel:
392 +-rw te-scaling-intent
393 | +-rw scale-in-intent
394 | | +-rw threshold-time? uint32
395 | | +-rw cooldown-time? uint32
396 | | +-rw scale-in-operation-type? scaling-criteria-operation
397 | | +-rw scale-out-operation-type? scaling-criteria-operation
398 | | +-rw scaling-condition* [performance-type]
399 | | +-rw performance-type identityref
400 | | +-rw te-telemetry-tunnel-ref? -> /te:te/tunnels/tunnel/name
401 | +-rw scale-out-intent
402 | +-rw threshold-time? uint32
403 | +-rw cooldown-time? uint32
404 | +-rw scale-in-operation-type? scaling-criteria-operation
405 | +-rw scale-out-operation-type? scaling-criteria-operation
406 | +-rw scaling-condition* [performance-type]
407 | +-rw performance-type identityref
408 | +-rw te-telemetry-tunnel-ref? -> /te:te/tunnels/tunnel/name
409 +-ro te-telemetry
410 +-ro id? string
411 +-ro performance-metric-one-way
412 | +-ro one-way-delay? uint32
413 | +-ro one-way-min-delay? uint32
414 | +-ro one-way-max-delay? uint32
415 | +-ro one-way-delay-variation? uint32
416 | +-ro one-way-packet-loss? decimal64
417 | +-ro one-way-residual-bandwidth? rt-types:bandwidth-ieee-float32
418 | +-ro one-way-available-bandwidth? rt-types:bandwidth-ieee-float32
419 | +-ro one-way-utilized-bandwidth? rt-types:bandwidth-ieee-float32
420 +-ro performance-metric-two-way
421 | +-ro two-way-delay? uint32
422 | +-ro two-way-min-delay? uint32
423 | +-ro two-way-max-delay? uint32
424 | +-ro two-way-delay-variation? uint32
425 | +-ro two-way-packet-loss? decimal64
426 +-ro te-ref? -> /te:te/tunnels/tunnel/name
428 module: ietf-actn-te-kpi-telemetry
429 augment /vn:actn/vn:vn/vn:vn-list:
430 +-rw vn-scaling-intent
431 | +-rw scale-in-intent
432 | | +-rw threshold-time? uint32
433 | | +-rw cooldown-time? uint32
434 | | +-rw scale-in-operation-type? scaling-criteria-operation
435 | | +-rw scale-out-operation-type? scaling-criteria-operation
436 | | +-rw scaling-condition* [performance-type]
437 | | +-rw performance-type identityref
438 | | +-rw te-telemetry-tunnel-ref? -> /te:te/tunnels/tunnel/name
439 | +-rw scale-out-intent
440 | +-rw threshold-time? uint32
441 | +-rw cooldown-time? uint32
442 | +-rw scale-in-operation-type? scaling-criteria-operation
443 | +-rw scale-out-operation-type? scaling-criteria-operation
444 | +-rw scaling-condition* [performance-type]
445 | +-rw performance-type identityref
446 | +-rw te-telemetry-tunnel-ref? -> /te:te/tunnels/tunnel/name
447 +-ro vn-telemetry
448 +-ro performance-metric-one-way
449 | +-ro one-way-delay? uint32
450 | +-ro one-way-min-delay? uint32
451 | +-ro one-way-max-delay? uint32
452 | +-ro one-way-delay-variation? uint32
453 | +-ro one-way-packet-loss? decimal64
454 | +-ro one-way-residual-bandwidth? rt-types:bandwidth-ieee-float32
455 | +-ro one-way-available-bandwidth? rt-types:bandwidth-ieee-float32
456 | +-ro one-way-utilized-bandwidth? rt-types:bandwidth-ieee-float32
457 +-ro performance-metric-two-way
458 | +-ro two-way-delay? uint32
459 | +-ro two-way-min-delay? uint32
460 | +-ro two-way-max-delay? uint32
461 | +-ro two-way-delay-variation? uint32
462 | +-ro two-way-packet-loss? decimal64
463 +-ro grouping-operation? grouping-operation
464 augment /vn:actn/vn:vn/vn:vn-list/vn:vn-member-list:
465 +-ro vn-member-telemetry
466 +-ro performance-metric-one-way
467 | +-ro one-way-delay? uint32
468 | +-ro one-way-min-delay? uint32
469 | +-ro one-way-max-delay? uint32
470 | +-ro one-way-delay-variation? uint32
471 | +-ro one-way-packet-loss? decimal64
472 | +-ro one-way-residual-bandwidth? rt-types:bandwidth-ieee-float32
473 | +-ro one-way-available-bandwidth? rt-types:bandwidth-ieee-float32
474 | +-ro one-way-utilized-bandwidth? rt-types:bandwidth-ieee-float32
475 +-ro performance-metric-two-way
476 | +-ro two-way-delay? uint32
477 | +-ro two-way-min-delay? uint32
478 | +-ro two-way-max-delay? uint32
479 | +-ro two-way-delay-variation? uint32
480 | +-ro two-way-packet-loss? decimal64
481 +-ro te-grouped-params* -> /te:te/tunnels/tunnel/te-kpi:te-telemetry/id
482 +-ro grouping-operation? grouping-operation
484 6. Yang Data Model
486 6.1. ietf-te-kpi-telemetry model
488 The YANG code is as follows:
490 file "ietf-te-kpi-telemetry@2018-10-05.yang"
492 module ietf-te-kpi-telemetry {
493 namespace "urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry";
495 prefix "te-tel";
497 import ietf-te {
498 prefix "te";
499 }
501 import ietf-te-types {
502 prefix "te-types";
503 }
505 import ietf-routing-types {
506 prefix "rt-types";
507 }
509 organization
510 "IETF Traffic Engineering Architecture and Signaling (TEAS)
511 Working Group";
513 contact
514 "Editor: Young Lee
515 Editor: Dhruv Dhody
516 Editor: Ricard Vilalta
517 Editor: Satish Karunanithi ";
519 description
520 "This module describes telemetry for teas tunnel model";
522 revision 2018-10-05 {
523 description
524 "Initial revision. This YANG file defines
525 the reusable base types for TE telemetry.";
526 reference
527 "Derived from earlier versions of base YANG files";
528 }
530 /*
531 * Identities
532 */
534 identity telemetry-param-type {
535 description
536 "Base identity for telemetry param types";
538 }
540 identity one-way-delay {
541 base telemetry-param-type;
542 description
543 "To specify average Delay in one (forward)
544 direction";
545 }
547 identity two-way-delay {
548 base telemetry-param-type;
549 description
550 "To specify average Delay in both (forward and reverse)
551 directions";
552 }
554 identity one-way-delay-variation {
555 base telemetry-param-type;
556 description
557 "To specify average Delay Variation in one (forward) direction";
558 }
560 identity two-way-delay-variation {
561 base telemetry-param-type;
562 description
563 "To specify average Delay Variation in both (forward and reverse)
564 directions";
565 }
567 identity one-way-packet-loss {
568 base telemetry-param-type;
569 description
570 "To specify packet loss in one (forward) direction.";
571 }
573 identity two-way-packet-loss {
574 base telemetry-param-type;
575 description
576 "To specify packet loss in in both (forward and reverse)
577 directions";
578 }
580 identity utilized-bandwidth {
581 base telemetry-param-type;
582 description
583 "To specify utilized bandwidth over the specified source
584 and destination.";
585 }
587 identity utilized-percentage {
588 base telemetry-param-type;
589 description
590 "To specify utilization percentage of the entity
591 (e.g., tunnel, link, etc.)";
592 }
593 /*
594 * Enums
595 */
596 typedef scaling-criteria-operation {
597 type enumeration {
598 enum AND {
599 description
600 "AND operation";
601 }
602 enum OR {
603 description
604 "OR operation";
605 }
606 }
607 description
608 "Operations to analize list of scaling criterias";
609 }
611 /*
612 * Groupings
613 */
615 grouping scaling-duration {
616 description
617 "Base scaling criteria durations";
618 leaf threshold-time {
619 type uint32;
620 units "seconds";
621 description
622 "The duration for which the criteria must hold true";
623 }
624 leaf cooldown-time {
625 type uint32;
626 units "seconds";
627 description
628 "The duration after a scaling-in/scaling-out action has been
629 triggered, for which there will be no further operation";
630 }
631 }
633 grouping scaling-criteria {
634 description
635 "Grouping for scaling criteria";
636 leaf performance-type {
637 type identityref {
638 base telemetry-param-type;
639 }
640 description
641 "Reference to the tunnel level telemetry type";
642 }
644 leaf te-telemetry-tunnel-ref {
645 type leafref {
646 path "/te:te/te:tunnels/te:tunnel/te:name";
647 }
648 description
649 "Reference to tunnel";
650 }
651 }
653 grouping scaling-intent {
654 description
655 "Basic sclaing intent";
657 uses scaling-duration;
659 leaf scale-in-operation-type {
660 type scaling-criteria-operation;
661 default AND;
662 description
663 "Operation to be applied to check between scaling criterias to
664 check if the scale in threshold condition has been met.
665 Defaults to AND";
666 }
667 leaf scale-out-operation-type {
668 type scaling-criteria-operation;
669 default OR;
670 description
671 "Operation to be applied to check between scaling criterias to
672 check if the scale out threshold condition has been met.
673 Defauls to OR";
674 }
676 list scaling-condition {
677 key "performance-type";
678 description
679 "Scaling conditions";
680 uses scaling-criteria;
681 }
683 }
685 /*
686 * Augments
687 */
689 augment "/te:te/te:tunnels/te:tunnel" {
691 description
692 "Augmentation parameters for config scaling-criteria
693 TE tunnel topologies. Scale in/out criteria might be used
694 for network autonomics in order the controller
695 to react to a certain set of monitored params.";
697 container te-scaling-intent {
698 description
699 "scaling intent";
701 container scale-in-intent{
702 description
703 "scale-in";
704 uses scaling-intent;
705 }
706 container scale-out-intent{
707 description
708 "scale-out";
709 uses scaling-intent;
710 }
711 }
713 container te-telemetry {
714 config false;
715 description
716 "telemetry params";
717 leaf id {
718 type string;
719 description "Id of telemetry param";
720 }
722 uses te-types:performance-metric-container;
724 leaf te-ref{
725 type leafref{ path
726 '/te:te/te:tunnels/te:tunnel/te:name'; }
727 description "Reference to measured te tunnel";
728 }
729 }
731 }
733 }
735
737 6.2. ietf-actn-te-kpi-telemetry model
739 The YANG code is as follows:
741 file "ietf-actn-te-kpi-telemetry@2018-10-05.yang"
743 module ietf-actn-te-kpi-telemetry {
745 namespace "urn:ietf:params:xml:ns:yang:ietf-actn-te-kpi-telemetry";
747 prefix "actn-tel";
749 import ietf-actn-vn {
750 prefix "vn";
751 }
753 import ietf-te {
754 prefix "te";
755 }
757 import ietf-te-types {
758 prefix "te-types";
759 }
761 import ietf-te-kpi-telemetry {
762 prefix "te-kpi";
763 }
765 organization
766 "IETF Traffic Engineering Architecture and Signaling (TEAS)
767 Working Group";
769 contact
770 "Editor: Young Lee
771 Editor: Dhruv Dhody
772 Editor: Ricard Vilalta
773 Editor: Satish Karunanithi ";
775 description
776 "This module describes telemetry for actn vn model";
778 revision 2018-10-05 {
779 description
780 "Initial revision. This YANG file defines
781 the ACTN VN telemetry.";
782 reference
783 "Derived from earlier versions of base YANG files";
784 }
786 /*
787 * Typedefs
788 */
790 typedef grouping-operation {
792 type enumeration {
793 enum MINIMUM {
794 description "Select the minimum param";
795 }
796 enum MAXIMUM {
797 description "Select the maximum param";
798 }
799 enum MEAN {
800 description "Select the MEAN of the params";
801 }
802 enum STD_DEV {
803 description "Select the standard deviation
804 of the monitored params";
805 }
806 enum AND {
807 description "Select the AND of the params";
808 }
809 enum OR {
810 description "Select the OR of the params";
811 }
812 }
813 description
814 "Operations to analyze list of monitored params";
815 }
817 /*
818 * Groupings
819 */
821 grouping vn-telemetry-param {
822 description "augment of te-kpi:telemetry-param for VN specific params";
824 leaf-list te-grouped-params {
825 type leafref{
826 path '/te:te/te:tunnels/te:tunnel/'+
827 'te-kpi:te-telemetry/te-kpi:id';
828 }
829 description
830 "Allows the definition of a vn-telemetry param
831 as a grouping of underlying TE params";
832 }
834 leaf grouping-operation {
835 type grouping-operation;
836 description
837 "describes the operation to apply to
838 te-grouped-params";
839 }
841 }
843 /*
844 * Augments
845 */
847 augment "/vn:actn/vn:vn/vn:vn-list" {
849 description
850 "Augmentation parameters for state TE VN topologies.";
852 container vn-scaling-intent {
853 description
854 "scaling intent";
856 container scale-in-intent{
857 description
858 "VN scale-in";
859 uses te-kpi:scaling-intent;
860 }
861 container scale-out-intent{
862 description
863 "VN scale-out";
864 uses te-kpi:scaling-intent;
865 }
866 }
867 container vn-telemetry {
868 config false;
869 description
870 "VN telemetry params";
872 uses te-types:performance-metric-container;
874 leaf grouping-operation {
875 type grouping-operation;
876 description "describes the operation to apply to the VN-members";
877 }
878 }
879 }
881 /*
882 * VN-member augment
883 */
884 augment "/vn:actn/vn:vn/vn:vn-list/vn:vn-member-list" {
885 description
886 "Augmentation parameters for state TE vn member topologies.";
887 container vn-member-telemetry {
888 config false;
889 description
890 "VN member telemetry params";
892 uses te-types:performance-metric-container;
894 uses vn-telemetry-param;
896 }
897 }
898 }
899
901 7. Security Considerations
903 The configuration, state, and action data defined in this document
904 are designed to be accessed via a management protocol with a secure
905 transport layer, such as NETCONF [RFC6241]. The NETCONF access
906 control model [RFC6536] provides the means to restrict access for
907 particular NETCONF users to a preconfigured subset of all available
908 NETCONF protocol operations and content.
910 A number of configuration data nodes defined in this document are
911 writable/deletable (i.e., "config true") These data nodes may be
912 considered sensitive or vulnerable in some network environments.
914 8. IANA Considerations
916 TDB
918 9. Acknowledgements
920 10. References
922 10.1. Informative References
924 [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3
925 Provider-Provisioned Virtual Private Networks (PPVPNs)",
926 RFC 4110, July 2005.
928 [RFC6020] M. Bjorklund, Ed., "YANG - A Data Modeling Language for
929 the Network Configuration Protocol (NETCONF)", RFC 6020,
930 October 2010.
932 [Service-YANG] Q. Wu, W. Liu and A. Farrel, "Service Models
933 Explained", draft-wu-opsawg-service-model-explained, work
934 in progress.
936 [Netmod-Yang-Model-Classification] D. Bogdanovic, B. Claise, and C.
937 Moberg, "YANG Module Classification", draft-ietf-netmod-
938 yang-model-classification, work in progress.
940 [Netconf] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
941 and A. Bierman, Ed., "Network Configuration Protocol
942 (NETCONF)", RFC 6241.
944 [Restconf] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF
945 Protocol", draft-ietf-netconf-restconf, work in progress.
947 [Routing-Types] X. Liu, et al, "Routing Area Common YANG Data
948 Types", draft-ietf-rtgwg-routing-types, work in progress.
950 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
951 and R. Wilton, "Network Management Datastore Architecture
952 (NMDA)", RFC 8342, March 2018,
954 10.2. Normative References
956 [ACTN-Frame] D. Cecarelli and Y. Lee, "Framework for Abstraction and
957 Control of Traffic Engineered Networks", draft-ietf-teas-
958 actn-framework, work in progress.
960 [TE-Topology] X. Liu, et al., "YANG Data Model for TE Topologies",
961 draft-ietf-teas-yang-te-topo, work in progress.
963 [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic
964 Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
965 te, work in progress.
967 [ACTN-VN] Y. Lee (Editor), "A Yang Data Model for ACTN VN
968 Operation", draft-lee-teas-actn-vn-yang, work in progress.
970 [L3SM-YANG] S. Litkowski, L.Tomotaki, and K. Ogaki, "YANG Data Model
971 for L3VPN service delivery", draft-ietf-l3sm-l3vpn-
972 service-model, work in progress.
974 [PCEP-Service-Aware] D. Dhody, et al., "Extensions to the Path
975 Computation Element Communication Protocol (PCEP) to
976 compute service aware Label Switched Path (LSP)", draft-
977 ietf-pce-pcep-service-aware, work in progress.
979 [ACTN-PERF] Y. XU, et al., "Use Cases and Requirements of Dynamic
980 Service Control based on Performance Monitoring in ACTN
981 Architecture", draft-xu-actn-perf-dynamic-service-control-
982 03, work in progress.
984 11. Contributors
986 Authors' Addresses
988 Young Lee
989 Huawei Technologies
990 5340 Legacy Drive Suite 173
991 Plano, TX 75024, USA
993 Email: leeyoung@huawei.com
995 Dhruv Dhody
996 Huawei Technology
997 Leela Palace
998 Bangalore, Karnataka 560008
999 India
1001 Email: dhruv.dhody@huawei.com
1003 Satish Karunanithi
1004 Huawei Technology
1005 Leela Palace
1006 Bangalore, Karnataka 560008
1007 India
1009 Email: satish.karunanithi@gmail.com
1010 Ricard Vilalta
1011 Centre Tecnologic de Telecomunicacions de Catalunya (CTTC/CERCA)
1012 Av. Carl Friedrich Gauss 7
1013 08860 - Castelldefels
1014 Barcelona (Spain)
1015 Email: ricard.vilalta@cttc.es
1017 Daniel King
1018 Lancaster University
1020 Email: d.king@lancaster.ac.uk
1022 Daniele Ceccarelli
1023 Ericsson
1024 Torshamnsgatan,48
1025 Stockholm, Sweden
1027 Email: daniele.ceccarelli@ericsson.com