< 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/ |