< draft-lee-teas-actn-pm-telemetry-autonomics-11.txt   draft-lee-teas-actn-pm-telemetry-autonomics-12.txt >
TEAS Working Group Y. Lee (Editor) TEAS Working Group Y. Lee (Editor)
Internet Draft Dhruv Dhody Internet Draft Dhruv Dhody
Intended Status: Standard Track Satish Karunanithi Intended Status: Standard Track Satish Karunanithi
Expires: September 6, 2019 Huawei Expires: October 2, 2019 Huawei
Ricard Vilalta Ricard Vilalta
CTTC CTTC
Daniel King Daniel King
Lancaster University Lancaster University
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
March 6, 2019 April 2, 2019
YANG models for ACTN & TE Performance Monitoring Telemetry and Network YANG models for VN & TE Performance Monitoring Telemetry and Scaling
Autonomics Intent Autonomics
draft-lee-teas-actn-pm-telemetry-autonomics-11 draft-lee-teas-actn-pm-telemetry-autonomics-12
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 41 skipping to change at page 1, line 44
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 6, 2019. This Internet-Draft will expire on October 2, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
skipping to change at page 2, line 13 skipping to change at page 2, line 19
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Abstract Abstract
Abstraction and Control of TE Networks (ACTN) refers to the set of This document provides YANG data models that describe performance
virtual network operations needed to operate, control and manage monitoring telemetry and scaling intent mechanism for TE-tunnels and
large-scale multi-domain, multi-layer and multi-vendor TE networks, Virtual Networks (VN).
so as to facilitate network programmability, automation, efficient
resource sharing.
This document provides YANG data models that describe Key The models presented in this draft allow customers to subscribe and
Performance Indicator (KPI) telemetry and network autonomics for TE- monitor their key performance data of their interest on the level of
tunnels and ACTN VNs. TE-tunnel or VN. The models also provide customers with the ability
to program autonomic scaling intent mechanism on the level of TE-
tunnel as well as VN.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Terminology...............................................3 1.1. Terminology...............................................4
1.2. Tree diagram..............................................4 1.2. Tree diagram..............................................4
1.3. Prefixes in Data Node Names...............................4 1.3. Prefixes in Data Node Names...............................4
2. Use-Cases......................................................4 2. Use-Cases......................................................4
3. Design of the Data Models......................................6 3. Design of the Data Models......................................6
3.1. TE KPI Telemetry Model....................................7 3.1. TE KPI Telemetry Model....................................6
3.2. ACTN TE KPI Telemetry Model...............................7 3.2. VN KPI Telemetry Model....................................7
4. Scaling Intent Illustration....................................9 4. Autonomic Scaling Intent Mechanism.............................8
5. Notification..................................................10 5. Notification..................................................10
5.1. YANG Push Subscription Examples..........................10 5.1. YANG Push Subscription Examples..........................10
6. YANG Data Tree................................................11 6. YANG Data Tree................................................11
7. Yang Data Model...............................................13 7. Yang Data Model...............................................13
7.1. ietf-te-kpi-telemetry model..............................13 7.1. ietf-te-kpi-telemetry model..............................13
7.2. ietf-actn-te-kpi-telemetry model.........................18 7.2. ietf-vn-kpi-telemetry model..............................18
8. Security Considerations.......................................21 8. Security Considerations.......................................21
9. IANA Considerations...........................................21 9. IANA Considerations...........................................21
10. Acknowledgements.............................................22 10. Acknowledgements.............................................22
11. References...................................................22 11. References...................................................22
11.1. Informative References..................................22 11.1. Informative References..................................22
11.2. Normative References....................................23 11.2. Normative References....................................23
12. Contributors.................................................24 12. Contributors.................................................24
Authors' Addresses...............................................24 Authors' Addresses...............................................24
1. Introduction 1. Introduction
Abstraction and Control of TE Networks (ACTN) describes a method for The YANG model discussed in [VN] is used to operate customer-driven
operating a Traffic Engineered (TE) network (such as an MPLS-TE VNs during the VN instantiation, VN computation, and its life-cycle
network or a layer 1/0 transport network) to provide connectivity service management and operations. YANG model discussed in [TE-
and virtual network services for customers of the TE network Tunnel] is used to operate TE-tunnels during the tunnel
[RFC8453]. The services provided can be optimized to meet the instantiation, and its life-cycle management and operations.
requirements (such as traffic patterns, quality, and reliability) of
the applications hosted by the customers. Data models are a
representation of objects that can be configured or monitored within
a system. Within the IETF, YANG [RFC6020] is the language of choice
for documenting data models, and YANG models have been produced to
allow configuration or modeling of a variety of network devices,
protocol instances, and network services. YANG data models have been
classified in [RFC8199] and [RFC8309].
[ACTN-VN] describes how customers or end to end orchestrators can The models presented in this draft allow the applications hosted by
request and/or instantiate a generic virtual network service. [ACTN- the customers to subscribe and monitor their key performance data of
Applicability] describes a connection between IETF YANG model their interest on the level of VN [VN] or TE-tunnel [TE-Tunnel]. The
classifications to ACTN interfaces. In particular, it describes the key characteristic of the models presented in this document is a
customer service model can be mapped into the CMI (CNC-MDSC top-down programmability that allows the applications hosted by the
Interface) of the ACTN architecture. customers to subscribe and monitor key performance data of their
interest and autonomic scaling intent mechanism on the level of VN
as well as TE-tunnel.
The YANG model on the ACTN CMI is known as customer service model in According to the classification of [RFC8309], the YANG data models
[RFC8309]. [RFC8233] describes key network performance data to be presented in this document can be classified as customer service
considered for end-to-end path computation in TE networks. Key models, which is mapped to CMI (Customer Network Controller (CNC)-
performance indicator is a term that describes critical performance Multi-Domain Service Coordinator (MSDC) interface) of ACTN
data that may affect VN/TE service. [RFC8453].
This document provides TE KPI Telemetry Model which provides the TE- [RFC8233] describes key network performance data to be considered
Tunnel level of performance monitoring model and the scaling for end-to-end path computation in TE networks. Key performance
mechanisms. It also provides ACTN VN TE KPI Telemetry Model which indicator is a term that describes critical performance data that
provides the VN level of the aggregated performance monitoring model may affect VN/TE-tunnel service. The services provided can be
and the scaling mechanisms. optimized to meet the requirements (such as traffic patterns,
quality, and reliability) of the applications hosted by the
customers.
This document provides YANG data models generically applicable to
any VN/TE-Tunnel service clients to provide an ability to program
their customized performance monitoring subscription and publication
data models and automatic scaling in/out intent data models. These
models can be utilized by a client network controller to initiate
these capability to a transport network controller communicating
with the client controller via a NETCONF [RFC8341] or a RESTCONF
[RFC8040] interface.
The data model includes configuration and state data according to
the new Network Management Datastore Architecture [RFC8342].
1.1. Terminology 1.1. Terminology
Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used
in this document. in this document.
1.2. Tree diagram 1.2. Tree diagram
A simplified graphical representation of the data model is used in A simplified graphical representation of the data model is used in
Section 5 of this this document. The meaning of the symbols in Section 5 of this this document. The meaning of the symbols in
skipping to change at page 4, line 24 skipping to change at page 4, line 32
are prefixed using the standard prefix associated with the are prefixed using the standard prefix associated with the
corresponding YANG imported modules, as shown in Table 1. corresponding YANG imported modules, as shown in Table 1.
+---------+------------------------------+-----------------+ +---------+------------------------------+-----------------+
| Prefix | YANG module | Reference | | Prefix | YANG module | Reference |
+---------+------------------------------+-----------------+ +---------+------------------------------+-----------------+
| rt | ietf-routing-types | [RFC8294] | | rt | ietf-routing-types | [RFC8294] |
| te | ietf-te | [TE-Tunnel] | | te | ietf-te | [TE-Tunnel] |
| te-types| ietf-te-types | [TE-Types] | | te-types| ietf-te-types | [TE-Types] |
| te-kpi | ietf-te-kpi-telemetry | [This I-D] | | te-kpi | ietf-te-kpi-telemetry | [This I-D] |
| vn | ietf-vn | [ACTN-VN] | | vn | ietf-vn | [VN] |
| actn-tel| ietf-actn-te-kpi-telemetry | {This I-D] | | vn-tel | ietf-vn-kpi-telemetry | [This I-D] |
+---------+------------------------------+-----------------+ +---------+------------------------------+-----------------+
Table 1: Prefixes and corresponding YANG modules Table 1: Prefixes and corresponding YANG modules
2. Use-Cases 2. Use-Cases
[ACTN-PERF] describes use-cases relevant to this draft. It [PERF] describes use-cases relevant to this draft. It introduces the
introduces the dynamic creation, modification and optimization of dynamic creation, modification and optimization of services based on
services based on the performance monitoring in the Abstraction and the performance monitoring. Figure 1 shows a high-level workflows
Control of Transport Networks (ACTN) architecture. Figure 1 shows a for dynamic service control based on traffic monitoring.
high-level workflows for dynamic service control based on traffic
monitoring.
Some of the key points from [ACTN-PERF] are as follows: +----------------------------------------------+
| Client +-----------------------------+ |
| | Dynamic Service Control APP | |
| +-----------------------------+ |
+----------------------------------------------+
1.Traffic| /|\4.Traffic | /|\
Monitor& | | Monitor | | 8.Traffic
Optimize | | Result 5.Service | | modify &
Policy | | modify& | | optimize
\|/ | optimize Req.\|/ | result
+----------------------------------------------+
| Orchestrator |
| +-------------------------------+ |
| |Dynamic Service Control Agent | |
| +-------------------------------+ |
| +---------------+ +-------------------+ |
| | Flow Optimize | | vConnection Agent | |
| +---------------+ +-------------------+ |
+----------------------------------------------+
2. Path | /|\3.Traffic | /|\
Monitor | | Monitor | |7.Path
Request | | Result 6.Path | | modify &
| | modify& | | optimize
\|/ | optimize Req.\|/ | result
+----------------------------------------------+
| Network SDN Controller |
| +----------------------+ +-----------------+|
| | Network Provisioning | |Abstract Topology||
| +----------------------+ +-----------------+|
| +------------------+ +--------------------+ |
| |Network Monitoring| |Physical Topology DB| |
| +------------------+ +--------------------+ |
+----------------------------------------------+
Figure 1 Workflows for dynamic service control based on traffic
monitoring
Some of the key points from [PERF] are as follows:
. Network traffic monitoring is important to facilitate automatic . Network traffic monitoring is important to facilitate automatic
discovery of the imbalance of network traffic, and initiate the discovery of the imbalance of network traffic, and initiate the
network optimization, thus helping the network operator or the network optimization, thus helping the network operator or the
virtual network service provider to use the network more virtual network service provider to use the network more
efficiently and save CAPEX/OPEX. efficiently and save CAPEX/OPEX.
. Customer services have various SLA requirements, such as . Customer services have various SLA requirements, such as
service availability, latency, latency jitter, packet loss service availability, latency, latency jitter, packet loss
rate, BER, etc. The transport network can satisfy service rate, BER, etc. The transport network can satisfy service
availability and BER requirements by providing different availability and BER requirements by providing different
protection and restoration mechanisms. However, for other protection and restoration mechanisms. However, for other
performance parameters, there are no such mechanisms. In order performance parameters, there are no such mechanisms. In order
to provide high quality services according to customer SLA, one to provide high quality services according to customer SLA, one
possible solution is to measure the service SLA related possible solution is to measure the service SLA related
performance parameters, and dynamically provision and optimize performance parameters, and dynamically provision and optimize
services based on the performance monitoring results. services based on the performance monitoring results.
skipping to change at page 5, line 12 skipping to change at page 6, line 17
rate, BER, etc. The transport network can satisfy service rate, BER, etc. The transport network can satisfy service
availability and BER requirements by providing different availability and BER requirements by providing different
protection and restoration mechanisms. However, for other protection and restoration mechanisms. However, for other
performance parameters, there are no such mechanisms. In order performance parameters, there are no such mechanisms. In order
to provide high quality services according to customer SLA, one to provide high quality services according to customer SLA, one
possible solution is to measure the service SLA related possible solution is to measure the service SLA related
performance parameters, and dynamically provision and optimize performance parameters, and dynamically provision and optimize
services based on the performance monitoring results. services based on the performance monitoring results.
. Performance monitoring in a large scale network could generate . Performance monitoring in a large scale network could generate
a huge amount of performance information. Therefore, the a huge amount of performance information. Therefore, the
appropriate way to deliver the information in CMI and MPI appropriate way to deliver the information in the client and
interfaces should be carefully considered. network interfaces should be carefully considered.
+-------------------------------------------+
| CNC +-----------------------------+ |
| | Dynamic Service Control APP | |
| +-----------------------------+ |
+-------------------------------------------+
1.Traffic| /|\4.Traffic | /|\
Monitor& | | Monitor | | 8.Traffic
Optimize | | Result 5.Service | | modify &
Policy | | modify& | | optimize
\|/ | optimize Req.\|/ | result
+------------------------------------------------+
| MDSC +-------------------------------+ |
| |Dynamic Service Control Agent | |
| +-------------------------------+ |
| +---------------+ +-------------------+ |
| | Flow Optimize | | vConnection Agent | |
| +---------------+ +-------------------+ |
+------------------------------------------------+
2. Path | /|\3.Traffic | |
Monitor | | Monitor | |7.Path
Request | | Result 6.Path | | modify &
| | modify& | | optimize
\|/ | optimize Req.\|/ | result
+-------------------------------------------------------+
| PNC +----------------------+ +----------------------+ |
| | Network Provisioning | |Abstract Topology Gen.| |
| +----------------------+ +----------------------+ |
| +------------------+ +--------------------+ |
| |Network Monitoring| |Physical Topology DB| |
| +------------------+ +--------------------+ |
+-------------------------------------------------------+
Figure 1 Workflows for dynamic service control based on traffic
monitoring
3. Design of the Data Models 3. Design of the Data Models
The YANG models developed in this document describe two models: The YANG models developed in this document describe two models:
(i) TE KPI Telemetry Model which provides the TE-Tunnel level of (i) TE KPI Telemetry Model which provides the TE-Tunnel level of
performance monitoring mechanism (See Section 3.1 & 7.1 for performance monitoring mechanism and scaling intent mechanism
details). that allows scale in/out programming by the customer. (See
Section 3.1 & 7.1 for details).
(ii) ACTN TE KPI Telemetry Model which provides the VN level of the
aggregated performance monitoring mechanism (See Section 3.2
& 7.2 for details).
The models include -
(i) Performance Telemetry details as measured during the last
interval, e.g., delay.
(ii) Scaling Intent based on with TE/VN could be scaled in/out (See (ii) VN KPI Telemetry Model which provides the VN level of the
Section 4 for an illustration). aggregated performance monitoring mechanism and scaling
intent mechanism that allows scale in/out programming by the
customer (See Section 3.2 & 7.2 for details).
3.1. TE KPI Telemetry Model 3.1. TE KPI Telemetry Model
This module describes performance telemetry for TE-tunnel model. The This module describes performance telemetry for TE-tunnel model. The
telemetry data is augmented to tunnel state. This module also telemetry data is augmented to tunnel state. This module also
allows autonomic traffic engineering scaling intent configuration allows autonomic traffic engineering scaling intent configuration
mechanism on the TE-tunnel level. Various conditions can be set for mechanism on the TE-tunnel level. Various conditions can be set for
auto-scaling based on the telemetry data (See Section 5 for details) auto-scaling based on the telemetry data (See Section 5 for details)
The TE KPI Telemetry Model augments the TE-Tunnel Model to enhance The TE KPI Telemetry Model augments the TE-Tunnel Model to enhance
skipping to change at page 7, line 37 skipping to change at page 7, line 13
will facilitate proactive re-optimization and reconfiguration of TEs will facilitate proactive re-optimization and reconfiguration of TEs
based on the performance monitoring data collected via the TE KPI based on the performance monitoring data collected via the TE KPI
Telemetry YANG model. Telemetry YANG model.
+------------+ +--------------+ +------------+ +--------------+
| TE-Tunnel | | TE KPI | | TE-Tunnel | | TE KPI |
| Model |<---------| Telemetry | | Model |<---------| Telemetry |
+------------+ augments | Model | +------------+ augments | Model |
+--------------+ +--------------+
3.2. ACTN TE KPI Telemetry Model 3.2. VN KPI Telemetry Model
This module describes performance telemetry for ACTN VN model. The This module describes performance telemetry for VN model. The
telemetry data is augmented both at the VN Level as well as telemetry data is augmented both at the VN Level as well as
individual VN member level. This module also allows autonomic individual VN member level. This module also allows autonomic
traffic engineering scaling intent configuration mechanism on the VN traffic engineering scaling intent configuration mechanism on the VN
level. Scale in/out criteria might be used for network autonomics in level. Scale in/out criteria might be used for network autonomics in
order the controller to react to a certain set of variations in order the controller to react to a certain set of variations in
monitored parameters (See Section 4 for illustrations). monitored parameters (See Section 4 for illustrations).
Moreover, this module also provides mechanism to define aggregated Moreover, this module also provides mechanism to define aggregated
telemetry parameters as a grouping of underlying VN level telemetry telemetry parameters as a grouping of underlying VN level telemetry
parameters. Grouping operation (such as maximum, mean) could be set parameters. Grouping operation (such as maximum, mean) could be set
skipping to change at page 8, line 21 skipping to change at page 8, line 6
operation is used for delay at the VN level, the VN telemetry data operation is used for delay at the VN level, the VN telemetry data
is reported as the maximum {delay_vn_member_1, delay_vn_member_2,.. is reported as the maximum {delay_vn_member_1, delay_vn_member_2,..
delay_vn_member_N}. Thus, this telemetry abstraction mechanism delay_vn_member_N}. Thus, this telemetry abstraction mechanism
allows the grouping of a certain common set of telemetry values allows the grouping of a certain common set of telemetry values
under a grouping operation. This can be done at the VN-member level under a grouping operation. This can be done at the VN-member level
to suggest how the E2E telemetry be inferred from the per domain to suggest how the E2E telemetry be inferred from the per domain
tunnel created and monitored by PNCs. One proposed example is the tunnel created and monitored by PNCs. One proposed example is the
following: following:
+------------------------------------------------------------+ +------------------------------------------------------------+
| CNC | | Client |
| | | |
+------------------------------------------------------------+ +------------------------------------------------------------+
1.CNC sets the | /|\ 2. MDSC gets VN Telemetry 1.Client sets the | /|\ 2. Orchestrator pushes:
grouping op, and | | grouping op, and | |
subscribes to the | | VN KPI TELEMETRY (VN Level) subscribes to the | | VN level telemetry for
VN level telemetry for | | VN Utilized-bw-percentage: VN level telemetry for | | - VN Utilized-bw-percentage
Delay and | | Minimum across VN Members Delay and | | (Minimum across VN Members)
Utilized-bw-pecentage | | VN Delay: Maximum across VN Utilized-bw-pecentage | | - VN Delay (Maximum across VN
\|/ | Members \|/ | Members)
+------------------------------------------------------------+ +------------------------------------------------------------+
| MDSC | | Orchestrator |
| | | |
+------------------------------------------------------------+ +------------------------------------------------------------+
The ACTN VN TE-Telemetry Model augments the basic ACTN VN model to The VN Telemetry Model augments the basic VN model to enhance VN
enhance VN monitoring capability. This monitoring capability will monitoring capability. This monitoring capability will facilitate
facilitate proactive re-optimization and reconfiguration of VNs proactive re-optimization and reconfiguration of VNs based on the
based on the performance monitoring data collected via the ACTN VN performance monitoring data collected via the VN Telemetry YANG
Telemetry YANG model. model.
+----------+ +--------------+ +----------+ +--------------+
| ACTN VN | augments | ACTN | | VN | augments | VN |
| Model |<---------| TE-Telemetry | | Model |<---------| Telemetry |
+----------+ | Model | +----------+ | Model |
+--------------+ +--------------+
4. Scaling Intent Illustration 4. Autonomic Scaling Intent Mechanism
Scaling intent configuration mechanism allows the client to
configure automatic scale-in and scale-out mechanisms on both the
TE-tunnel and the VN level. Various conditions can be set for auto-
scaling based on the PM telemetry data.
There are a number of parameters involved in the mechanism:
. scale-out-intent or scale-in-intent: whether to scale-out or
scale-in.
. performance-type: performance metric type (e.g., one-way-delay,
one-way-delay-min, one-way-delay-max, two-way-delay, two-way-
delay-min, two-way-delay-max, utilized bandwidth, etc.)
. threshold-value: the threshold value for a certain performance-
type that triggers scale-in or scale-out.
. scaling-operation-type: in case where scaling condition can be
set with one or more performance types, then scaling-operation-
type (AND, OR, MIN, MAX, etc.) is applied to these selected
performance types and its threshold values.
. Threshold-time: the duration for which the criteria must hold
true.
. Cooldown-time: the duration after a scaling action has been
triggered, for which there will be no further operation.
The following tree is a part of ietf-te-kpi-telemetry tree whose The following tree is a part of ietf-te-kpi-telemetry tree whose
model is presented in full detail in Sections 6 & 7. model is presented in full detail in Sections 6 & 7.
module: ietf-te-kpi-telemetry module: ietf-te-kpi-telemetry
augment /te:te/te:tunnels/te:tunnel: augment /te:te/te:tunnels/te:tunnel:
+-rw te-scaling-intent +-rw te-scaling-intent
| +-rw scale-in-intent | +-rw scale-in-intent
| | +-rw threshold-time? uint32 | | +-rw threshold-time? uint32
| | +-rw cooldown-time? uint32 | | +-rw cooldown-time? uint32
skipping to change at page 9, line 30 skipping to change at page 9, line 39
| | +-rw te-telemetry-tunnel-ref? -> /te:te/tunnels/tunnel/name | | +-rw te-telemetry-tunnel-ref? -> /te:te/tunnels/tunnel/name
| +-rw scale-out-intent | +-rw scale-out-intent
| +-rw threshold-time? uint32 | +-rw threshold-time? uint32
| +-rw cooldown-time? uint32 | +-rw cooldown-time? uint32
| +-rw scale-out-operation-type? scaling-criteria-operation | +-rw scale-out-operation-type? scaling-criteria-operation
| +-rw scaling-condition* [performance-type] | +-rw scaling-condition* [performance-type]
| +-rw performance-type identityref | +-rw performance-type identityref
| +-rw threshold-value? string | +-rw threshold-value? string
| +-rw te-telemetry-tunnel-ref? -> /te:te/tunnels/tunnel/name | +-rw te-telemetry-tunnel-ref? -> /te:te/tunnels/tunnel/name
Scaling intent configuration mechanism allows the client to
configure automatic scale-in and scale-out mechanisms on both the
TE-tunnel and the VN level. Various conditions can be set for auto-
scaling based on the PM telemetry data.
For example, if the client were to set scale-out-intent (as the
above tree), it can specify the threshold-time and cooldown-time to
which the scaling intent would apply. Threshold time refers to the
duration for which the criteria must hold true. Cooldown time refers
to the duration after a scaling action has been triggered, for which
there will be no further operation.
Performance type can be any type as defined in performance-type
(e.g., one-way-delay, one-way-delay-min, one-way-delay-max, two-way-
delay, two-way-delay-min, two-way-delay-max, utilized bandwidth,
etc.). Scaling condition can be set with one or more performance
types. When multiple performance types are set, then scaling-
operation-type (AND or OR) is applied to these selected performance
types and its threshold values.
Let say the client wants to set the scaling out operation based on Let say the client wants to set the scaling out operation based on
two performance-types (e.g., two-way-delay and utilized-bandwidth two performance-types (e.g., two-way-delay and utilized-bandwidth
for a te-tunnel), it can be done as follows: for a te-tunnel), it can be done as follows:
. Two-way-delay threshold: 300 mileseconds . Set Threshold-time: 3600 (sec) (duration for which the
. Utilized bandwidth: 300 megabytes criteria must hold true)
. Set Cooldown-time: 60 (sec) (the duration after a scaling
action has been triggered, for which there will be no further
operation)
. Set AND for the scale-out-operation-type
By setting AND for the scale-out-operation-type, the two criteria In the scaling condition's list, the following two components can be
have to meet at the same time to trigger scale-out operation. set:
List 1: Scaling Condition for Two-way-delay
. performance type: Two-way-delay
. threshold-value: 300 mile-seconds
List 2: Scaling Condition for Utilized bandwidth
. performance type: Utilized bandwidth
. threshold-value: 300 megabytes
5. Notification 5. Notification
This model does not define specific notifications. To enable This model does not define specific notifications. To enable
notifications, the mechanism defined in [Yang-Push] notifications, the mechanism defined in [YANG-PUSH]
and [Event-Notification] can be used. This mechanism currently and [Event-Notification] can be used. This mechanism currently
allows the user to: allows the user to:
. Subscribe notifications on a per client basis. . Subscribe notifications on a per client basis.
. Specify subtree filters or xpath filters so that only interested . Specify subtree filters or xpath filters so that only interested
contents will be sent. contents will be sent.
. Specify either periodic or on-demand notifications. . Specify either periodic or on-demand notifications.
5.1. YANG Push Subscription Examples 5.1. YANG Push Subscription Examples
[YANG-PUSH] allows subscriber applications to request a continuous,
customized stream of updates from a YANG datastore.
Below example shows the way for a client to subscribe for the Below example shows the way for a client to subscribe for the
telemetry information for a particular tunnel (Tunnel1). The telemetry information for a particular tunnel (Tunnel1). The
telemetry parameter that the client is interested in is one-way- telemetry parameter that the client is interested in is one-way-
delay. delay.
<netconf:rpc netconf:message-id="101" <netconf:rpc netconf:message-id="101"
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
<establish-subscription <establish-subscription
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0"> xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
<filter netconf:type="subtree"> <filter netconf:type="subtree">
skipping to change at page 12, line 28 skipping to change at page 12, line 38
| +-ro one-way-residual-bandwidth-normality? te-types:performance-metrics-normality | +-ro one-way-residual-bandwidth-normality? te-types:performance-metrics-normality
| +-ro one-way-available-bandwidth? rt-types:bandwidth-ieee-float32 | +-ro one-way-available-bandwidth? rt-types:bandwidth-ieee-float32
| +-ro one-way-available-bandwidth-normality? te-types:performance-metrics-normality | +-ro one-way-available-bandwidth-normality? te-types:performance-metrics-normality
| +-ro one-way-utilized-bandwidth? rt-types:bandwidth-ieee-float32 | +-ro one-way-utilized-bandwidth? rt-types:bandwidth-ieee-float32
| +-ro one-way-utilized-bandwidth-normality? te-types:performance-metrics-normality | +-ro one-way-utilized-bandwidth-normality? te-types:performance-metrics-normality
+-ro performance-metrics-two-way +-ro performance-metrics-two-way
| +-ro two-way-delay? uint32 | +-ro two-way-delay? uint32
| +-ro two-way-delay-normality? te-types:performance-metrics-normality | +-ro two-way-delay-normality? te-types:performance-metrics-normality
+-ro te-ref? -> /te:te/tunnels/tunnel/name +-ro te-ref? -> /te:te/tunnels/tunnel/name
module: ietf-actn-te-kpi-telemetry module: ietf-vn-kpi-telemetry
augment /vn:vn/vn:vn-list: augment /vn:vn/vn:vn-list:
+--rw vn-scaling-intent +--rw vn-scaling-intent
| +--rw scale-in-intent | +--rw scale-in-intent
| | +--rw threshold-time? uint32 | | +--rw threshold-time? uint32
| | +--rw cooldown-time? uint32 | | +--rw cooldown-time? uint32
| | +--rw scale-in-operation-type? scaling-criteria-operation | | +--rw scale-in-operation-type? scaling-criteria-operation
| | +--rw scaling-condition* [performance-type] | | +--rw scaling-condition* [performance-type]
| | +--rw performance-type identityref | | +--rw performance-type identityref
| | +--rw threshold-value? string | | +--rw threshold-value? string
| | +--rw te-telemetry-tunnel-ref? -> /te:te/tunnels/tunnel/name | | +--rw te-telemetry-tunnel-ref? -> /te:te/tunnels/tunnel/name
skipping to change at page 13, line 31 skipping to change at page 13, line 40
| +--ro two-way-delay-normality? te-types:performance-metrics-normality | +--ro two-way-delay-normality? te-types:performance-metrics-normality
+--ro te-grouped-params* -> /te:te/tunnels/tunnel/te-kpi:te-telemetry/id +--ro te-grouped-params* -> /te:te/tunnels/tunnel/te-kpi:te-telemetry/id
+--ro grouping-operation? grouping-operation +--ro grouping-operation? grouping-operation
7. Yang Data Model 7. Yang Data Model
7.1. ietf-te-kpi-telemetry model 7.1. ietf-te-kpi-telemetry model
The YANG code is as follows: The YANG code is as follows:
<CODE BEGINS> file "ietf-te-kpi-telemetry@2019-03-06.yang" <CODE BEGINS> file "ietf-te-kpi-telemetry@2019-04-02.yang"
module ietf-te-kpi-telemetry { module ietf-te-kpi-telemetry {
namespace "urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry"; namespace "urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry";
prefix te-tel; prefix te-tel;
import ietf-te { import ietf-te {
prefix te; prefix te;
} }
import ietf-te-types { import ietf-te-types {
prefix te-types; prefix te-types;
} }
import ietf-routing-types {
prefix rt-types;
}
organization organization
"IETF Traffic Engineering Architecture and Signaling (TEAS) "IETF Traffic Engineering Architecture and Signaling (TEAS)
Working Group"; Working Group";
contact contact
"Editor: Young Lee <leeyoung@huawei.com> "Editor: Young Lee <leeyoung@huawei.com>
Editor: Dhruv Dhody <dhruv.ietf@gmail.com> Editor: Dhruv Dhody <dhruv.ietf@gmail.com>
Editor: Ricard Vilalta <ricard.vilalta@cttc.es> Editor: Ricard Vilalta <ricard.vilalta@cttc.es>
Editor: Satish Karunanithi <satish.karunanithi@gmail.com>"; Editor: Satish Karunanithi <satish.karunanithi@gmail.com>";
description description
"This module describes telemetry for teas tunnel model"; "This module describes telemetry for teas tunnel model";
revision 2019-03-06 { revision 2019-04-02 {
description description
"Initial revision. This YANG file defines "Initial revision. This YANG file defines
the reusable base types for TE telemetry."; the reusable base types for TE telemetry.";
reference "Derived from earlier versions of base YANG files"; reference "Derived from earlier versions of base YANG files";
} }
identity telemetry-param-type { identity telemetry-param-type {
description description
"Base identity for telemetry param types"; "Base identity for telemetry param types";
} }
skipping to change at page 18, line 18 skipping to change at page 18, line 24
} }
description description
"Reference to measured te tunnel"; "Reference to measured te tunnel";
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
7.2. ietf-actn-te-kpi-telemetry model 7.2. ietf-vn-kpi-telemetry model
The YANG code is as follows: The YANG code is as follows:
<CODE BEGINS> file "ietf-actn-te-kpi-telemetry@2019-03-06.yang" <CODE BEGINS> file "ietf-vn-kpi-telemetry@2019-03-27.yang"
module ietf-actn-te-kpi-telemetry { module ietf-vn-kpi-telemetry {
namespace "urn:ietf:params:xml:ns:yang:ietf-actn-te-kpi-telemetry"; namespace "urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry";
prefix actn-tel; prefix actn-tel;
import ietf-vn { import ietf-vn {
prefix vn; prefix vn;
} }
import ietf-te { import ietf-te {
prefix te; prefix te;
} }
import ietf-te-types { import ietf-te-types {
prefix te-types; prefix te-types;
skipping to change at page 19, line 8 skipping to change at page 19, line 13
"IETF Traffic Engineering Architecture and Signaling (TEAS) "IETF Traffic Engineering Architecture and Signaling (TEAS)
Working Group"; Working Group";
contact contact
"Editor: Young Lee <leeyoung@huawei.com> "Editor: Young Lee <leeyoung@huawei.com>
Editor: Dhruv Dhody <dhruv.ietf@gmail.com> Editor: Dhruv Dhody <dhruv.ietf@gmail.com>
Editor: Ricard Vilalta <ricard.vilalta@cttc.es> Editor: Ricard Vilalta <ricard.vilalta@cttc.es>
Editor: Satish Karunanithi <satish.karunanithi@gmail.com>"; Editor: Satish Karunanithi <satish.karunanithi@gmail.com>";
description description
"This module describes telemetry for actn vn model"; "This module describes telemetry for actn vn model";
revision 2019-03-06 { revision 2019-03-27 {
description description
"Initial revision. This YANG file defines "Initial revision. This YANG file defines
the ACTN VN telemetry."; the ACTN VN telemetry.";
reference "Derived from earlier versions of base YANG files"; reference "Derived from earlier versions of base YANG files";
} }
typedef grouping-operation { typedef grouping-operation {
type enumeration { type enumeration {
enum MINIMUM { enum MINIMUM {
description description
skipping to change at page 21, line 42 skipping to change at page 21, line 47
This document registers the following namespace URIs in the IETF XML This document registers the following namespace URIs in the IETF XML
registry [RFC3688]: registry [RFC3688]:
-------------------------------------------------------------------- --------------------------------------------------------------------
URI: urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry URI: urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
-------------------------------------------------------------------- --------------------------------------------------------------------
-------------------------------------------------------------------- --------------------------------------------------------------------
URI: urn:ietf:params:xml:ns:yang:ietf-actn-te-kpi-telemetry URI: urn:ietf:params:xml:ns:yang:ietf-kpi-telemetry
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
-------------------------------------------------------------------- --------------------------------------------------------------------
This document registers the following YANG modules in the YANG This document registers the following YANG modules in the YANG
Module. Module.
Names registry [RFC7950]: Names registry [RFC7950]:
-------------------------------------------------------------------- --------------------------------------------------------------------
name: ietf-te-kpi-telemetry name: ietf-te-kpi-telemetry
namespace: urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry namespace: urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry
reference: RFC XXXX (TDB) reference: RFC XXXX (TDB)
-------------------------------------------------------------------- --------------------------------------------------------------------
skipping to change at page 22, line 16 skipping to change at page 22, line 20
Names registry [RFC7950]: Names registry [RFC7950]:
-------------------------------------------------------------------- --------------------------------------------------------------------
name: ietf-te-kpi-telemetry name: ietf-te-kpi-telemetry
namespace: urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry namespace: urn:ietf:params:xml:ns:yang:ietf-te-kpi-telemetry
reference: RFC XXXX (TDB) reference: RFC XXXX (TDB)
-------------------------------------------------------------------- --------------------------------------------------------------------
-------------------------------------------------------------------- --------------------------------------------------------------------
name: ietf-actn-te-kpi-telemetry name: ietf-vn-kpi-telemetry
namespace: urn:ietf:params:xml:ns:yang:ietf-actn-te-kpi-telemetry namespace: urn:ietf:params:xml:ns:yang:ietf-vn-kpi-telemetry
reference: RFC XXXX (TDB) reference: RFC XXXX (TDB)
-------------------------------------------------------------------- --------------------------------------------------------------------
10. Acknowledgements 10. Acknowledgements
We thank Rakesh Gandhi, Tarek Saad and Igor Bryskin for useful We thank Rakesh Gandhi, Tarek Saad and Igor Bryskin for useful
discussions and their suggestions for this work. discussions and their suggestions for this work.
11. References 11. References
skipping to change at page 23, line 18 skipping to change at page 23, line 22
[RFC7926] A. Farrel (Ed.), "Problem Statement and Architecture for [RFC7926] A. Farrel (Ed.), "Problem Statement and Architecture for
Information Exchange between Interconnected Traffic- Information Exchange between Interconnected Traffic-
Engineered Networks", RFC 7926, July 2016. Engineered Networks", RFC 7926, July 2016.
[RFC8309] Q. Wu, W. Cheng, and A. Farrel. "Service Models [RFC8309] Q. Wu, W. Cheng, and A. Farrel. "Service Models
Explained", RFC 8309, January 2018. Explained", RFC 8309, January 2018.
[RFC8340] M. Bjorklund and L. Berger (Editors), "YANG Tree [RFC8340] M. Bjorklund and L. Berger (Editors), "YANG Tree
Diagrams", RFC 8340, March 2018. Diagrams", RFC 8340, March 2018.
[Yang-Push] A. Clemm, et al, "Subscription to YANG Datastores", [YANG-PUSH] A. Clemm, et al, "Subscription to YANG Datastores",
draft-ietf-netconf-yang-push, work in progress. draft-ietf-netconf-yang-push, work in progress.
[Event-Notification] E. Voit, et al, "Subscription to YANG [Event-Notification] E. Voit, et al, "Subscription to YANG
Datastores", draft-ietf-netconf-yang-push, work in Datastores", draft-ietf-netconf-yang-push, work in
progress. progress.
[ACTN-PERF] Y. XU, et al., "Use Cases and Requirements of Dynamic [PERF] Y. XU, et al., "Use Cases and Requirements of Dynamic Service
Service Control based on Performance Monitoring in ACTN Control based on Performance Monitoring in ACTN
Architecture", draft-xu-actn-perf-dynamic-service-control, Architecture", draft-xu-actn-perf-dynamic-service-control,
work in progress. work in progress.
[RFC8341] A. Bierman, M. Bjorklund, "Network Configuration Access [RFC8341] A. Bierman, M. Bjorklund, "Network Configuration Access
Control Model", RFC 8341, March 2018. Control Model", RFC 8341, March 2018.
[RFC8453] D. Ceccarelli and Y. Lee (Editors), "Framework for [RFC8453] D. Ceccarelli and Y. Lee (Editors), "Framework for
Abstraction and Control of Traffic Engineered Networks", Abstraction and Control of Traffic Engineered Networks",
RFC 8453, August 2018. RFC 8453, August 2018.
11.2. Normative References 11.2. Normative References
[TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic
Engineering Tunnels and Interfaces", draft-ietf-teas-yang- Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
te, work in progress. te, work in progress.
[TE-Types] T. Saad, et.al, "Traffic Engineering Common YANG Types", [TE-Types] T. Saad, et.al, "Traffic Engineering Common YANG Types",
draft-ietf-teas-yang-te-types, work in progress. draft-ietf-teas-yang-te-types, work in progress.
[ACTN-VN] Y. Lee (Editor), "A Yang Data Model for ACTN VN [VN] Y. Lee (Editor), "A Yang Data Model for ACTN VN Operation",
Operation", draft-lee-teas-actn-vn-yang, work in progress. draft-lee-teas-actn-vn-yang, work in progress.
[RFC8233] D. Dhody, et al., "Extensions to the Path Computation [RFC8233] D. Dhody, et al., "Extensions to the Path Computation
Element Communication Protocol (PCEP) to compute service Element Communication Protocol (PCEP) to compute service
aware Label Switched Path (LSP)", RFC 8233, September aware Label Switched Path (LSP)", RFC 8233, September
2017. 2017.
12. Contributors 12. Contributors
Authors' Addresses Authors' Addresses
Young Lee Young Lee (Editor)
Huawei Technologies Huawei Technologies
5340 Legacy Drive Suite 173 5340 Legacy Drive Suite 173
Plano, TX 75024, USA Plano, TX 75024, USA
Email: leeyoung@huawei.com Email: leeyoung@huawei.com
Dhruv Dhody Dhruv Dhody
Huawei Technology Huawei Technology
Leela Palace Leela Palace
Bangalore, Karnataka 560008 Bangalore, Karnataka 560008
 End of changes. 56 change blocks. 
175 lines changed or deleted 198 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/