draft-ietf-opsawg-yang-vpn-service-pm-06.txt   draft-ietf-opsawg-yang-vpn-service-pm-07.txt 
OPSAWG Working Group B. Wu, Ed. OPSAWG Working Group B. Wu, Ed.
Internet-Draft Q. Wu, Ed. Internet-Draft Q. Wu, Ed.
Intended status: Standards Track Huawei Intended status: Standards Track Huawei
Expires: 16 October 2022 M. Boucadair, Ed. Expires: 27 October 2022 M. Boucadair, Ed.
Orange Orange
O. Gonzalez de Dios O. Gonzalez de Dios
Telefonica Telefonica
B. Wen B. Wen
Comcast Comcast
14 April 2022 25 April 2022
A YANG Model for Network and VPN Service Performance Monitoring A YANG Model for Network and VPN Service Performance Monitoring
draft-ietf-opsawg-yang-vpn-service-pm-06 draft-ietf-opsawg-yang-vpn-service-pm-07
Abstract Abstract
The data model for network topologies defined in RFC 8345 introduces The data model for network topologies defined in RFC 8345 introduces
vertical layering relationships between networks that can be vertical layering relationships between networks that can be
augmented to cover network and service topologies. This document augmented to cover network and service topologies. This document
defines a YANG module for performance monitoring (PM) of both defines a YANG module for performance monitoring (PM) of both
networks and VPN services that can be used to monitor and manage networks and VPN services that can be used to monitor and manage
network performance on the topology at higher layer or the service network performance on the topology at higher layer or the service
topology between VPN sites. topology between VPN sites.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 16 October 2022. This Internet-Draft will expire on 27 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 25 skipping to change at page 2, line 25
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Network and VPN Service Performance Monitoring Model Usage . 4 3. Network and VPN Service Performance Monitoring Model Usage . 4
3.1. Collecting Data via Pub/Sub Mechanism . . . . . . . . . . 5 3.1. Collecting Data via Pub/Sub Mechanism . . . . . . . . . . 5
3.2. Collecting Data On-demand . . . . . . . . . . . . . . . . 6 3.2. Collecting Data On-demand . . . . . . . . . . . . . . . . 6
4. Description of The Data Model . . . . . . . . . . . . . . . . 6 4. Description of The Data Model . . . . . . . . . . . . . . . . 6
4.1. Layering Relationship between Multiple Layers of 4.1. Layering Relationship between Multiple Layers of
Topology . . . . . . . . . . . . . . . . . . . . . . . . 6 Topology . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Network Level . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Network Level . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Node Level . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Node Level . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Link and Termination Point Level . . . . . . . . . . . . 10 4.4. Link and Termination Point Level . . . . . . . . . . . . 10
5. Network and VPN Service Performance Monitoring YANG Module . 14 5. Network and VPN Service Performance Monitoring YANG Module . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.1. Normative References . . . . . . . . . . . . . . . . . . 31 10.1. Normative References . . . . . . . . . . . . . . . . . . 31
10.2. Informative References . . . . . . . . . . . . . . . . . 33 10.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Illustrating Examples . . . . . . . . . . . . . . . 35 Appendix A. Illustrative Examples . . . . . . . . . . . . . . . 35
A.1. VPN Performance Subscription Example . . . . . . . . . . 35 A.1. VPN Performance Subscription Example . . . . . . . . . . 35
A.2. Example of VPN Performance Snapshot . . . . . . . . . . . 36 A.2. Example of VPN Performance Snapshot . . . . . . . . . . . 36
A.3. Example of Percentile Monitoring . . . . . . . . . . . . 38 A.3. Example of Percentile Monitoring . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
[RFC8969] describes a framework for automating service and network [RFC8969] describes a framework for automating service and network
management with YANG models. It defines that the performance management with YANG [RFC6020] models. It defines that the
measurement telemetry model to be tied with the service, such as performance measurement telemetry model should be tied to the
Layer 3 VPN and Layer 2 VPN, or network models to monitor the overall services (such as a Layer 3 VPN or Layer 2 VPN) or to the network
network performance or Service Level Agreement (SLA). models to monitor the overall network performance and the Service
Level Agreements (SLAs).
The performance of VPN services is associated with the performance The performance of VPN services is associated with the performance
changes of the underlay network that carries VPN services, such as changes of the underlay network that carries VPN services, such as
the delay of the underlay tunnels and the packet loss status of the the delay of the underlay tunnels and the packet loss status of the
device interfaces. Additionally, the integration of Layer 2/Layer 3 device interfaces. Additionally, the integration of Layer 2/Layer 3
VPN performance and network performance data enables the orchestrator VPN performance and network performance data enables the orchestrator
to subscribe to VPN service performance in a unified manner. to subscribe to VPN service performance in a unified manner.
Therefore, this document defines a YANG module for both network and Therefore, this document defines a YANG module for both network and
VPN service performance monitoring (PM). The module can be used to VPN service performance monitoring (PM). The module can be used to
monitor and manage network performance on the topology level or the monitor and manage network performance on the topology level or the
skipping to change at page 4, line 8 skipping to change at page 4, line 11
L2VPN Layer 2 Virtual Private Network L2VPN Layer 2 Virtual Private Network
L3VPN Layer 3 Virtual Private Network L3VPN Layer 3 Virtual Private Network
L2NM L2VPN Network Model L2NM L2VPN Network Model
L3NM L3VPN Network Model L3NM L3VPN Network Model
MPLS Multiprotocol Label Switching MPLS Multiprotocol Label Switching
OAM Operations, Administration, and Maintenance OAM Operations, Administration, and Maintenance
OWAMP One-Way Active Measurement Protocol OWAMP One-Way Active Measurement Protocol
PE Provider Edge PE Provider Edge
PM Performance Monitoring PM Performance Monitoring
SLA Service Level Agreements SLA Service Level Agreement
TP Termination Point, as defined in [RFC8345] section 4.2
TWAMP Two-Way Active Measurement Protocol TWAMP Two-Way Active Measurement Protocol
VPLS Virtual Private LAN Service VPLS Virtual Private LAN Service
VPN Virtual Private Network VPN Virtual Private Network
3. Network and VPN Service Performance Monitoring Model Usage 3. Network and VPN Service Performance Monitoring Model Usage
Models are key for automating network management operations. Models are key for automating network management operations.
According to [RFC8969], together with service and network models, According to [RFC8969], together with service and network models,
performance measurement telemetry models are needed to monitor performance measurement telemetry models are needed to monitor
network performance to meet specific service requirements (typically network performance to meet specific service requirements (typically
skipping to change at page 5, line 7 skipping to change at page 5, line 11
As shown in Figure 1, in the context of the layering model As shown in Figure 1, in the context of the layering model
architecture described in [RFC8309], the network and VPN service architecture described in [RFC8309], the network and VPN service
performance monitoring (PM) model can be used to expose a set of performance monitoring (PM) model can be used to expose a set of
performance information to the above layer. Such information can be performance information to the above layer. Such information can be
used by an orchestrator to subscribe to performance data. The used by an orchestrator to subscribe to performance data. The
network controller will then notify the orchestrator about network controller will then notify the orchestrator about
corresponding parameter changes. corresponding parameter changes.
Before using the model, the controller needs to establish complete Before using the model, the controller needs to establish complete
topology visibility of the network and VPN. For example, the topology visibility of the network and VPN. For example, the
controller can use information from [RFC8345], [I-D.ietf-opsawg-sap] controller can use network information from [RFC8345],
or VPN instances. Then the controller derives network or VPN level [I-D.ietf-opsawg-sap] or VPN information from [RFC9182],
performance data by aggregating (and filtering) lower-level data [I-D.ietf-opsawg-l2nm]. Then the controller derives network or VPN
collected via monitoring counters of the involved devices. level performance data by aggregating (and filtering) lower-level
data collected via monitoring counters of the involved devices.
The network or VPN performance data can be based on different The network or VPN performance data can be based on different
sources. For example, the performance monitoring data per link in sources. For example, the performance monitoring data per link in
the underlying network can be collected using a network performance the underlying network can be collected using a network performance
measurement method such as One-Way Active Measurement Protocol measurement method such as One-Way Active Measurement Protocol
(OWAMP) [RFC4656], Two-Way Active Measurement Protocol (TWAMP) (OWAMP) [RFC4656], Two-Way Active Measurement Protocol (TWAMP)
[RFC5357], and Multiprotocol Label Switching (MPLS) Loss and Delay [RFC5357], and Multiprotocol Label Switching (MPLS) Loss and Delay
Measurement [RFC6374]. The performance monitoring information Measurement [RFC6374]. The performance monitoring information
reflecting the quality of the network or VPN service (e.g., end-to- reflecting the quality of the network or VPN service (e.g., end-to-
end network performance data between source node and destination node end network performance data between source node and destination node
skipping to change at page 5, line 45 skipping to change at page 5, line 50
using the tagging methods defined in [I-D.ietf-netmod-node-tags]. using the tagging methods defined in [I-D.ietf-netmod-node-tags].
3.1. Collecting Data via Pub/Sub Mechanism 3.1. Collecting Data via Pub/Sub Mechanism
Some applications such as service-assurance applications, which must Some applications such as service-assurance applications, which must
maintain a continuous view of operational data and state, can use the maintain a continuous view of operational data and state, can use the
subscription model specified in [RFC8641] to subscribe to the subscription model specified in [RFC8641] to subscribe to the
specific network performance data or VPN service performance data specific network performance data or VPN service performance data
they are interested in, at the data source. For example, network or they are interested in, at the data source. For example, network or
VPN topology updates may be obtained through on-change notifications VPN topology updates may be obtained through on-change notifications
[RFC8641]. For dynamic-changing PM data, various notifications can [RFC8641]. For dynamic PM data, various notifications can be
be specified to obtain more complete data. A periodic notification specified to obtain more complete data. A periodic notification
[RFC8641] can be specified to obtain real-time performance data, a [RFC8641] can be specified to obtain real-time performance data, a
replay notification defined in [RFC5277] or [RFC8639] can be replay notification defined in [RFC5277] or [RFC8639] can be
specified to obtain historical data, or alarm notifications [RFC8632] specified to obtain historical data, or alarm notifications [RFC8632]
can be specified to get alarms for the metrics which exceed or fall can be specified to get alarms for the metrics which exceed or fall
below the performance threshold. below the performance threshold.
The data source can, then, use the network and VPN service assurance The data source can, then, use the network and VPN service assurance
model defined in this document and the YANG Push model [RFC8641] to model defined in this document and the YANG Push model [RFC8641] to
distribute specific telemetry data to target recipients. distribute specific telemetry data to target recipients.
skipping to change at page 6, line 21 skipping to change at page 6, line 27
To obtain a snapshot of a large amount of performance data from a To obtain a snapshot of a large amount of performance data from a
network topology or VPN network, service-assurance applications may network topology or VPN network, service-assurance applications may
retrieve information using the network and VPN service PM model retrieve information using the network and VPN service PM model
through a NETCONF [RFC6241] or a RESTCONF [RFC8040] interface. For through a NETCONF [RFC6241] or a RESTCONF [RFC8040] interface. For
example, a specified "link-id" of a VPN can be used as a filter in a example, a specified "link-id" of a VPN can be used as a filter in a
RESTCONF GET request to retrieve per-link VPN PM data. RESTCONF GET request to retrieve per-link VPN PM data.
4. Description of The Data Model 4. Description of The Data Model
This document defines the YANG module, "ietf-network-vpn-pm", which This document defines the YANG module, "ietf-network-vpn-pm", which
is an augmentation to the "ietf-network" and "ietf-network-topology". is an augmentation to the "ietf-network" and "ietf-network-topology"
modules.
The performance monitoring data augments the service topology as The performance monitoring data augments the service topology as
shown in Figure 2. shown in Figure 2.
+----------------------+ +-----------------------+ +----------------------+ +---------------------+
|ietf-network | |Network and VPN Service| |ietf-network | | |
|ietf-network-topology |<---------|Performance Monitoring | |ietf-network-topology |<---------| ietf-network-vpn-pm |
+----------------------+ augments | Model | +----------------------+ augments | |
+-----------------------+ +---------------------+
Figure 2: Module Augmentation Figure 2: Module Augmentation
4.1. Layering Relationship between Multiple Layers of Topology 4.1. Layering Relationship between Multiple Layers of Topology
[RFC8345] defines a YANG data model for network/service topologies [RFC8345] defines a YANG data model for network/service topologies
and inventories. The service topology described in [RFC8345] and inventories. The service topology described in [RFC8345]
includes the virtual topology for a service layer above Layer 1 (L1), includes the virtual topology for a service layer above Layer 1 (L1),
Layer 2 (L2), and Layer 3 (L3). This service topology has the Layer 2 (L2), and Layer 3 (L3). This service topology has the
generic topology elements of node, link, and terminating point. One generic topology elements of node, link, and terminating point. One
typical example of a service topology is described in Figure 3 of typical example of a service topology is described in Figure 3 of
[RFC8345]: two VPN service topologies instantiated over a common L3 [RFC8345]: two VPN service topologies instantiated over a common L3
topology. Each VPN service topology is mapped onto a subset of nodes topology. Each VPN service topology is mapped onto a subset of nodes
from the common L3 topology. from the common L3 topology.
Figure 3 illustrates an example of a topology that maps between the Figure 3 illustrates an example of a topology that maps between the
VPN service topology and an underlying network: VPN service topology and an underlying network:
VPN 1 VPN 2 VPN 1 VPN 2
+-----------------------+ +---------------------+ +------------------------+ +------------------------+
/ / / / / / / /
/S1C_[VN3]::: / /S2A S2B / / S1C_[VN3]::: / / /
/ \ ::::: / / _[VN1]______[VN3]_ / / \ ::::: / / S2A_[VN1]____[VN3]_S2B /
/ \ : / / : : / Overlay / \ ::: / / : : / Overlay
/ \ :: : : : : : : / / \ :::::::::::: : : /
/S1B_[VN2]____[VN1]_S1A / / : : : / / S1B_[VN2]____[VN1]_S1A / / : : /
+--------:-------:------+ +---:----:----------:-+ +---------:-------:------+ +-------:-:----------:---+
: : :: : : : : : : :::::::::::: : :
: : : : : : : : : :
Site-1A : +-------:--: ----- -------- : -------:-----+ Site-1C Site-1A : +-------:-:------------------:-------:-----+ Site-1C
[CE1]___: /__ ___ [N1]__________________ [N2]__ :___ /__[CE3] [CE1]___:_/_______[N1]___________________[N2]___:____/__[CE3]
:/ / / \ _____/ / : / :/ / / \ _____// : /
[CE5]___ : ___ / / \ _____/ / :: / [CE5]_____:_______/ / \ _____/ / :: /
Site-2A /: / \ / / : / Site-2A /: / \ / / :: /
/ : [N5] / : / Underlay Network / : [N5] / :: / Underlay Network
/ : / __/ \__ / : / / : / __/ \__ / :: /
/ : / ___/ \__ / : / / : / ___/ \__ /:: /
Site-1B / : / ___/ \ / : / Site-2B Site-1B / : / ___/ \ /: / Site-2B
[CE2]_ /________[N4]_________________ [N3]:::_____/____[CE4] [CE2]__/________[N4]__________________[N3]________/____[CE4]
+------------------------------------------+ / /
+------------------------------------------+
Legend: Legend:
N:node VN:VPN-Node S:Site N:Node VN:VPN-Node S:Site CE:Customer Edge
__ Link __ Link within a network layer
: Mapping between networks : Mapping between network layers
Figure 3: Example of Topology Mapping Between VPN Service Figure 3: Example of Topology Mapping Between VPN Service
Topology and Underlying Network Topology and Underlying Network
As shown in Figure 3, two VPN services topologies are both built on As shown in Figure 3, two VPN services topologies are built on top of
top of one common underlying physical network: one common underlying physical network:
VPN 1: This service topology supports hub-spoke communications for VPN 1: This service topology supports hub-spoke communications for
'customer 1' connecting the customer's access at three sites: 'customer 1' connecting the customer's access at three sites:
'Site-1A', 'Site-1B', and 'Site-1C'. These sites are connected to 'Site-1A', 'Site-1B', and 'Site-1C'. These sites are connected to
nodes that are mapped to node 1 (N1), node 2 (N2), and node 4 (N4) nodes that are mapped to node 1 (N1), node 2 (N2), and node 4 (N4)
in the underlying physical network. 'Site-1A' plays the role of in the underlying physical network. 'Site-1A' plays the role of
hub while 'Site-1B' and 'Site-1C' are configured as spoke. hub while 'Site-1B' and 'Site-1C' are configured as spoke.
VPN 2: This service supports any-to-any communications for 'customer VPN 2: This service supports any-to-any communications for 'customer
2' connecting the customer's access at two sites: 'Site-2A' and 2' connecting the customer's access at two sites: 'Site-2A' and
'Site-2B'. These sites are connected to nodes that are mapped to 'Site-2B'. These sites are connected to nodes that are mapped to
nodes 1 (N1) and node 3 (N3)5 in the underlying physical network. nodes 1 (N1) and node 3 (N3)5 in the underlying physical network.
'Site-2A' and 'Site-2B' have 'any-to-any' role. 'Site-2A' and 'Site-2B' have 'any-to-any' role.
Apart from the association between the VPN topology and the underlay Apart from the association between the VPN topology and the underlay
topology, VPN Network PM can also provide the performance status of topology, VPN Network PM can also provide the performance status of
the underlay network and VPN services. For example, network PM can the underlay network and VPN services. For example, network PM can
provide link PM statistics and port statistics. VPN PM can provides provide link PM statistics and port statistics. VPN PM can provide
statistics on VPN access interfaces, the number of current VRF routes statistics on VPN access interfaces, the number of current VRF routes
or L2VPN MAC entry of VPN nodes, and performance statistics on the or L2VPN MAC entry of VPN nodes, and performance statistics on the
logical point-to-point link between source and destination VPN nodes logical point-to-point link between source and destination VPN nodes
or between source and destination VPN access interfaces. Figure 4 or between source and destination VPN access interfaces. Figure 4
illustrates an example of VPN PM and the difference between two VPN illustrates an example of VPN PM and the difference between two VPN
PM measurement methods. One is the VPN tunnel PM and the other is PM measurement methods. One is the VPN tunnel PM and the other is
inter-VPN-access interface PM. inter-VPN-access interface PM.
+-----------------------------------------------------+ +-----------------------------------------------------+
| | | |
skipping to change at page 8, line 40 skipping to change at page 8, line 44
+-----------------------------------------------------+ +-----------------------------------------------------+
| | | |
| | | |
+----+ | TP+-----+ Link +---+ Link +-----+TP | +----+ +----+ | TP+-----+ Link +---+ Link +-----+TP | +----+
| CE4+-+----------+ N1 +-------+-N2+-------+ N3 +----------+-+CE5 | | CE4+-+----------+ N1 +-------+-N2+-------+ N3 +----------+-+CE5 |
+----+ | 1-1+-----+1-2 2-1+---+2-2 3-1+-----+3-2 | +----+ +----+ | 1-1+-----+1-2 2-1+---+2-2 3-1+-----+3-2 | +----+
| | | |
| | | |
+-----------------------------------------------------+ +-----------------------------------------------------+
Legend: Legend:
N:node VN:VPN-Node N:node VN:VPN-Node TP:Termination Point
-:Link -:Link
Figure 4: An Example of VPN PM Figure 4: An Example of VPN PM
4.2. Network Level 4.2. Network Level
For network performance monitoring, the container of "networks" in For network performance monitoring, the container of "networks" in
[RFC8345] does not need to be extended. [RFC8345] does not need to be extended.
For VPN service performance monitoring, the container "service-type" For VPN service performance monitoring, the container "service-type"
is defined to indicate the VPN type, e.g., L3VPN or Virtual Private is defined to indicate the VPN type, e.g., L3VPN or Virtual Private
LAN Service (VPLS). The values are taken from [RFC9181]. When a LAN Service (VPLS). The values are taken from [RFC9181]. When a
network topology instance contains the L3VPN or other L2VPN network network topology instance contains the L3VPN or other L2VPN network
type, it represents a VPN instance that can perform performance type, it represents a VPN instance that can perform performance
monitoring. monitoring.
The tree in Figure 5 is a part of ietf-network-vpn-pm tree. It The tree in Figure 5 is a part of ietf-network-vpn-pm tree. It
defines the following set of network level attributes: defines the following set of network level attributes:
"vpn-id": Refers to an identifier of VPN service defined in "vpn-id": Refers to an identifier of VPN service defined in
[RFC9181]). This identifier is used to correlate the performance [RFC9181]. This identifier is used to correlate the performance
status with the network service configuration. status with the network service configuration.
"vpn-service-topology": Indicates the type of the VPN topology. "vpn-service-topology": Indicates the type of the VPN topology.
This model supports "any-to-any", "Hub and Spoke" (where Hubs can This model supports "any-to-any", "Hub and Spoke" (where Hubs can
exchange traffic), and "Hub and Spoke disjoint" (where Hubs cannot exchange traffic), and "Hub and Spoke disjoint" (where Hubs cannot
exchange traffic) that are taken from [RFC9181]. These VPN exchange traffic) that are taken from [RFC9181]. These VPN
topology types can be used to describe how VPN sites communicate topology types can be used to describe how VPN sites communicate
with each other. with each other.
module: ietf-network-vpn-pm module: ietf-network-vpn-pm
skipping to change at page 10, line 16 skipping to change at page 10, line 24
attribute: attribute:
"role": Defines the role in a particular VPN service topology. The "role": Defines the role in a particular VPN service topology. The
roles are taken from [RFC9181] (e.g., any-to-any-role, spoke-role, roles are taken from [RFC9181] (e.g., any-to-any-role, spoke-role,
hub-role). hub-role).
augment /nw:networks/nw:network/nw:node: augment /nw:networks/nw:network/nw:node:
+--rw pm-attributes +--rw pm-attributes
+--rw node-type? identityref +--rw node-type? identityref
+--ro entry-summary +--ro entry-summary
| +--ro ipv4 | +--ro ipv4-num
| | +--ro maximum-routes? uint32 | | +--ro maximum-routes? uint32
| | +--ro total-active-routes? uint32 | | +--ro total-active-routes? uint32
| +--ro ipv6 | +--ro ipv6-num
| | +--ro maximum-routes? uint32 | | +--ro maximum-routes? uint32
| | +--ro total-active-routes? uint32 | | +--ro total-active-routes? uint32
| +--ro mac-num | +--ro mac-num
| +--ro mac-num-limit? uint32 | +--ro mac-num-limit? uint32
| +--ro total-active-mac-num? uint32 | +--ro total-active-mac-num? uint32
+--rw role? identityref +--rw role? identityref
Figure 6: Node Level YANG Tree of the Hierarchies Figure 6: Node Level YANG Tree of the Hierarchies
4.4. Link and Termination Point Level 4.4. Link and Termination Point Level
The tree in Figure 7 is the link and termination point (TP) part of The tree in Figure 7 is the link and termination point (TP) part of
ietf-network-vpn-pm tree. ietf-network-vpn-pm tree.
The 'links' are classified into two types: topology link defined in The 'links' are classified into two types: topology link defined in
[RFC8345] and abstract link of a VPN between PEs. [RFC8345] and abstract link of a VPN between PEs defined in this
module.
The performance data of a link is a collection of counters that The performance data of a link is a collection of counters and gauges
report the performance status. that report the performance status.
augment /nw:networks/nw:network/nt:link: augment /nw:networks/nw:network/nt:link:
+--rw pm-attributes +--rw pm-attributes
+--rw low-percentile? percentile +--rw low-percentile? percentile
+--rw intermediate-percentile? percentile +--rw intermediate-percentile? percentile
+--rw high-percentile? percentile +--rw high-percentile? percentile
+--rw measurement-interval? uint32 +--rw measurement-interval? uint32
+--ro start-time? yang:date-and-time +--ro start-time? yang:date-and-time
+--ro end-time? yang:date-and-time +--ro end-time? yang:date-and-time
+--ro pm-source? identityref +--ro pm-source? identityref
skipping to change at page 14, line 13 skipping to change at page 14, line 20
VPN PM type ("vpn-pm-type"): Indicates the VPN performance type, VPN PM type ("vpn-pm-type"): Indicates the VPN performance type,
which can be inter-vpn-access-interface PM or VPN underlay-tunnel which can be inter-vpn-access-interface PM or VPN underlay-tunnel
PM. These two methods are common VPN measurement methods. The PM. These two methods are common VPN measurement methods. The
inter-VPN-access-interface PM is to monitor the performance of inter-VPN-access-interface PM is to monitor the performance of
logical point-to-point connections between a source and a logical point-to-point connections between a source and a
destination VPN access interfaces. And the underlay-tunnel PM is destination VPN access interfaces. And the underlay-tunnel PM is
to monitor the performance of underlay tunnels of VPNs. The to monitor the performance of underlay tunnels of VPNs. The
inter-VPN-access-interface PM includes PE-PE monitoring. inter-VPN-access-interface PM includes PE-PE monitoring.
Therefore, only one of the two methods is needed , and the model Therefore, only one of the two methods is needed , and the model
defines "choice" to indicate these two methods, which also allows defines "choice" to indicate these two methods, which also allows
other methods to be extended. other methods to be extended. The inter-VPN-access-interface PM
is defined as an empty leaf, which is not bound to a specific VPN
access interface. The source or destination VPN access interface
of the measurement can be augmented as needed.
VPN underlay transport type ("vpn-underlay-transport-type"): Indicat VPN underlay transport type ("vpn-underlay-transport-type"): Indicat
es the abstract link protocol-type of a VPN, such as GRE or IP-in- es the abstract link protocol-type of a VPN, such as GRE or IP-in-
IP. The leaf refers to an identifier of the "underlay-transport" IP. The leaf refers to an identifier of the "underlay-transport"
defined in [RFC9181], which describes the transport technology to defined in [RFC9181], which describes the transport technology to
carry the traffic of the VPN service. carry the traffic of the VPN service.
For the data nodes of 'termination-point' depicted in Figure 7, the For the data nodes of 'termination-point' depicted in Figure 7, the
module defines the following minimal set of statistics: module defines the following minimal set of statistics:
skipping to change at page 14, line 44 skipping to change at page 15, line 10
network access defined in [RFC9182] or [I-D.ietf-opsawg-l2nm]. network access defined in [RFC9182] or [I-D.ietf-opsawg-l2nm].
When multiple VPN network accesses are created using the same When multiple VPN network accesses are created using the same
physical port, finer-grained metrics can be monitored. If a TP is physical port, finer-grained metrics can be monitored. If a TP is
associated with only a single VPN, this list is not required. associated with only a single VPN, this list is not required.
5. Network and VPN Service Performance Monitoring YANG Module 5. Network and VPN Service Performance Monitoring YANG Module
The "ietf-network-vpn-pm" module uses types defined in [RFC8345], The "ietf-network-vpn-pm" module uses types defined in [RFC8345],
[RFC6991], [RFC8532], and [RFC9181]. [RFC6991], [RFC8532], and [RFC9181].
<CODE BEGINS> file "ietf-network-vpn-pm@2022-04-08.yang" <CODE BEGINS> file "ietf-network-vpn-pm@2022-04-25.yang"
module ietf-network-vpn-pm { module ietf-network-vpn-pm {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm"; namespace "urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm";
prefix nvp; prefix nvp;
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference reference
"RFC 6991: Common YANG Types"; "RFC 6991: Common YANG Types";
} }
skipping to change at page 16, line 24 skipping to change at page 16, line 37
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices."; for full legal notices.";
// RFC Ed.: update the date below with the date of RFC // RFC Ed.: update the date below with the date of RFC
// publication and remove this note. // publication and remove this note.
// RFC Ed.: replace XXXX with actual RFC number and remove // RFC Ed.: replace XXXX with actual RFC number and remove
// this note. // this note.
revision 2022-04-08 { revision 2022-04-25 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: A YANG Model for Network and VPN Service "RFC XXXX: A YANG Model for Network and VPN Service
Performance Monitoring"; Performance Monitoring";
} }
identity node-type { identity node-type {
description description
"Base identity for node type"; "Base identity for node type";
skipping to change at page 18, line 39 skipping to change at page 19, line 4
if the percentile is set to 95.00 and if the percentile is set to 95.00 and
the 95th percentile one-way delay is 2 milliseconds, the 95th percentile one-way delay is 2 milliseconds,
then the 95 percent of the sample value then the 95 percent of the sample value
is less than or equal to 2 milliseconds."; is less than or equal to 2 milliseconds.";
} }
grouping entry-summary { grouping entry-summary {
description description
"Entry summary grouping used for network topology "Entry summary grouping used for network topology
augmentation."; augmentation.";
container entry-summary { container entry-summary {
config false; config false;
description description
"Container for VPN or network entry summary."; "Container for VPN or network entry summary.";
container ipv4 { container ipv4-num {
leaf maximum-routes { leaf maximum-routes {
type uint32; type uint32;
description description
"Indicates the maximum number of IPv4 routes "Indicates the maximum number of IPv4 routes
for the VPN."; for the VPN.";
} }
leaf total-active-routes { leaf total-active-routes {
type uint32; type uint32;
description description
"Indicates total active IPv4 routes for the VPN."; "Indicates total active IPv4 routes for the VPN.";
} }
description description
"IPv4-specific parameters."; "IPv4-specific parameters.";
} }
container ipv6 { container ipv6-num {
leaf maximum-routes { leaf maximum-routes {
type uint32; type uint32;
description description
"Indicates the maximum number of IPv6 routes "Indicates the maximum number of IPv6 routes
for the VPN."; for the VPN.";
} }
leaf total-active-routes { leaf total-active-routes {
type uint32; type uint32;
description description
"Indicates total active IPv6 routes for the VPN."; "Indicates total active IPv6 routes for the VPN.";
skipping to change at page 27, line 43 skipping to change at page 28, line 9
"Augments the network topology link with VPN service "Augments the network topology link with VPN service
performance monitoring attributes."; performance monitoring attributes.";
choice vpn-pm-type { choice vpn-pm-type {
description description
"The VPN PM type of this logical point-to-point "The VPN PM type of this logical point-to-point
unidirectional VPN link."; unidirectional VPN link.";
case inter-vpn-access-interface { case inter-vpn-access-interface {
leaf inter-vpn-access-interface { leaf inter-vpn-access-interface {
type empty; type empty;
description description
"This is a placeholder for inter-vpn-access-interface PM. "This is a placeholder for inter-vpn-access-interface PM,
There is no technology to be defined."; which is not bound to a specific VPN access interface.
The source or destination VPN access interface
of the measurement can be augmented as needed.";
} }
} }
case underlay-tunnel { case underlay-tunnel {
leaf vpn-underlay-transport-type { leaf vpn-underlay-transport-type {
type identityref { type identityref {
base vpn-common:protocol-type; base vpn-common:protocol-type;
} }
config false; config false;
description description
"The leaf indicates the underlay transport type of "The leaf indicates the underlay transport type of
skipping to change at page 31, line 38 skipping to change at page 31, line 48
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393, Metric for IP Performance Metrics (IPPM)", RFC 3393,
DOI 10.17487/RFC3393, November 2002, DOI 10.17487/RFC3393, November 2002,
<https://www.rfc-editor.org/info/rfc3393>. <https://www.rfc-editor.org/info/rfc3393>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026,
DOI 10.17487/RFC4026, March 2005,
<https://www.rfc-editor.org/info/rfc4026>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
<https://www.rfc-editor.org/info/rfc4656>. <https://www.rfc-editor.org/info/rfc4656>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, DOI 10.17487/RFC5357, October 2008, RFC 5357, DOI 10.17487/RFC5357, October 2008,
<https://www.rfc-editor.org/info/rfc5357>. <https://www.rfc-editor.org/info/rfc5357>.
skipping to change at page 33, line 5 skipping to change at page 33, line 26
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S. [RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S.
Raghavan, "Generic YANG Data Model for the Management of Raghavan, "Generic YANG Data Model for the Management of
Operations, Administration, and Maintenance (OAM) Operations, Administration, and Maintenance (OAM)
Protocols That Use Connectionless Communications", Protocols That Use Connectionless Communications",
RFC 8532, DOI 10.17487/RFC8532, April 2019, RFC 8532, DOI 10.17487/RFC8532, April 2019,
<https://www.rfc-editor.org/info/rfc8532>. <https://www.rfc-editor.org/info/rfc8532>.
[RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and
C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of
IGP Traffic Engineering Performance Metric Extensions",
RFC 8571, DOI 10.17487/RFC8571, March 2019,
<https://www.rfc-editor.org/info/rfc8571>.
[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
September 2019, <https://www.rfc-editor.org/info/rfc8641>. September 2019, <https://www.rfc-editor.org/info/rfc8641>.
[RFC9181] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., [RFC9181] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M.,
Ed., and Q. Wu, "A Common YANG Data Model for Layer 2 and Ed., and Q. Wu, "A Common YANG Data Model for Layer 2 and
Layer 3 VPNs", RFC 9181, DOI 10.17487/RFC9181, February Layer 3 VPNs", RFC 9181, DOI 10.17487/RFC9181, February
2022, <https://www.rfc-editor.org/info/rfc9181>. 2022, <https://www.rfc-editor.org/info/rfc9181>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-netmod-node-tags] [I-D.ietf-netmod-node-tags]
Wu, Q., Claise, B., Liu, P., Du, Z., and M. Boucadair, Wu, Q., Claise, B., Liu, P., Du, Z., and M. Boucadair,
"Self-Describing Data Object Tags in YANG Data Models", "Self-Describing Data Object Tags in YANG Data Models",
Work in Progress, Internet-Draft, draft-ietf-netmod-node- Work in Progress, Internet-Draft, draft-ietf-netmod-node-
tags-06, 21 February 2022, tags-06, 21 February 2022,
<https://www.ietf.org/archive/id/draft-ietf-netmod-node- <https://www.ietf.org/archive/id/draft-ietf-netmod-node-
tags-06.txt>. tags-06.txt>.
[I-D.ietf-opsawg-l2nm] [I-D.ietf-opsawg-l2nm]
Barguil, S., Dios, O. G. D., Boucadair, M., and L. A. Boucadair, M., Dios, O. G. D., Barguil, S., and L. A.
Munoz, "A Layer 2 VPN Network YANG Model", Work in Munoz, "A YANG Network Data Model for Layer 2 VPNs", Work
Progress, Internet-Draft, draft-ietf-opsawg-l2nm-12, 22 in Progress, Internet-Draft, draft-ietf-opsawg-l2nm-13, 14
November 2021, <https://www.ietf.org/archive/id/draft- April 2022, <https://www.ietf.org/archive/id/draft-ietf-
ietf-opsawg-l2nm-12.txt>. opsawg-l2nm-13.txt>.
[I-D.ietf-opsawg-sap] [I-D.ietf-opsawg-sap]
Boucadair, M., Dios, O. G. D., Barguil, S., Wu, Q., and V. Boucadair, M., Dios, O. G. D., Barguil, S., Wu, Q., and V.
Lopez, "A Network YANG Model for Service Attachment Points Lopez, "A Network YANG Model for Service Attachment Points
(SAPs)", Work in Progress, Internet-Draft, draft-ietf- (SAPs)", Work in Progress, Internet-Draft, draft-ietf-
opsawg-sap-04, 11 April 2022, opsawg-sap-04, 11 April 2022,
<https://www.ietf.org/archive/id/draft-ietf-opsawg-sap- <https://www.ietf.org/archive/id/draft-ietf-opsawg-sap-
04.txt>. 04.txt>.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026,
DOI 10.17487/RFC4026, March 2005,
<https://www.rfc-editor.org/info/rfc4026>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008,
<https://www.rfc-editor.org/info/rfc5277>. <https://www.rfc-editor.org/info/rfc5277>.
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
Previdi, "OSPF Traffic Engineering (TE) Metric Previdi, "OSPF Traffic Engineering (TE) Metric
Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
<https://www.rfc-editor.org/info/rfc7471>. <https://www.rfc-editor.org/info/rfc7471>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
skipping to change at page 34, line 27 skipping to change at page 34, line 46
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>. <https://www.rfc-editor.org/info/rfc8309>.
[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
2019, <https://www.rfc-editor.org/info/rfc8570>. 2019, <https://www.rfc-editor.org/info/rfc8570>.
[RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and
C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of
IGP Traffic Engineering Performance Metric Extensions",
RFC 8571, DOI 10.17487/RFC8571, March 2019,
<https://www.rfc-editor.org/info/rfc8571>.
[RFC8632] Vallin, S. and M. Bjorklund, "A YANG Data Model for Alarm [RFC8632] Vallin, S. and M. Bjorklund, "A YANG Data Model for Alarm
Management", RFC 8632, DOI 10.17487/RFC8632, September Management", RFC 8632, DOI 10.17487/RFC8632, September
2019, <https://www.rfc-editor.org/info/rfc8632>. 2019, <https://www.rfc-editor.org/info/rfc8632>.
[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
E., and A. Tripathy, "Subscription to YANG Notifications", E., and A. Tripathy, "Subscription to YANG Notifications",
RFC 8639, DOI 10.17487/RFC8639, September 2019, RFC 8639, DOI 10.17487/RFC8639, September 2019,
<https://www.rfc-editor.org/info/rfc8639>. <https://www.rfc-editor.org/info/rfc8639>.
[RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and
L. Geng, "A Framework for Automating Service and Network L. Geng, "A Framework for Automating Service and Network
Management with YANG", RFC 8969, DOI 10.17487/RFC8969, Management with YANG", RFC 8969, DOI 10.17487/RFC8969,
January 2021, <https://www.rfc-editor.org/info/rfc8969>. January 2021, <https://www.rfc-editor.org/info/rfc8969>.
[RFC9182] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., [RFC9182] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M.,
Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model
for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182, for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182,
February 2022, <https://www.rfc-editor.org/info/rfc9182>. February 2022, <https://www.rfc-editor.org/info/rfc9182>.
Appendix A. Illustrating Examples Appendix A. Illustrative Examples
A.1. VPN Performance Subscription Example A.1. VPN Performance Subscription Example
The example shown in Figure 8 illustrates how a client subscribes to The example shown in Figure 8 illustrates how a client subscribes to
the performance monitoring information between nodes ('node-id') A the performance monitoring information between nodes ('node-id') A
and B in the L3 network topology. The performance monitoring and B in the L3 network topology. The performance monitoring
parameter that the client is interested in is end-to-end loss. parameter that the client is interested in is end-to-end loss.
POST /restconf/operations POST /restconf/operations
/ietf-subscribed-notifications:establish-subscription /ietf-subscribed-notifications:establish-subscription
{ {
"ietf-subscribed-notifications:input":{ "ietf-subscribed-notifications:input":{
"stream-subtree-filter":{ "stream-subtree-filter":{
"ietf-network:networks":{ "ietf-network:networks":{
"network":{ "network":{
"network-id":"l3-network", "network-id":"foo:l3-network",
"ietf-network-vpn-pm:service-type":{ "ietf-network-vpn-pm:service-type":{
"ietf-vpn-common:l3vpn":{} "ietf-vpn-common:l3vpn":{}
}, },
"node":[ "node":[
{ {
"node-id":"A", "node-id":"A",
"ietf-network-vpn-pm:pm-attributes":{ "ietf-network-vpn-pm:pm-attributes":{
"node-type":"PE" "node-type":"PE"
}, },
"termination-point":{ "termination-point":{
skipping to change at page 38, line 13 skipping to change at page 38, line 13
Figure 9 Figure 9
A.3. Example of Percentile Monitoring A.3. Example of Percentile Monitoring
The following shows an example of a percentile measurement for a VPN The following shows an example of a percentile measurement for a VPN
link. link.
{ {
"ietf-network-topology:link": [ "ietf-network-topology:link": [
{ {
"link-id": "vpn1-link1", "link-id": "foo:vpn1-link1",
"source": { "source": {
"source-node": "vpn-node1" "source-node": "vpn-node1"
}, },
"destination": { "destination": {
"dest-node": "vpn-node3" "dest-node": "vpn-node3"
}, },
"ietf-network-vpn-pm:pm-attributes": { "ietf-network-vpn-pm:pm-attributes": {
"low-percentile": "20.00", "low-percentile": "20.00",
"intermediate-percentile": "50.00", "intermediate-percentile": "50.00",
"high-percentile": "90.00", "high-percentile": "90.00",
 End of changes. 39 change blocks. 
90 lines changed or deleted 103 lines changed or added

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