draft-ietf-opsawg-yang-vpn-service-pm-03.txt   draft-ietf-opsawg-yang-vpn-service-pm-04.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: 2 August 2022 M. Boucadair, Ed. Expires: 22 September 2022 M. Boucadair, Ed.
Orange Orange
O. Gonzalez de Dios O. Gonzalez de Dios
Telefonica Telefonica
B. Wen B. Wen
Comcast Comcast
29 January 2022 21 March 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-03 draft-ietf-opsawg-yang-vpn-service-pm-04
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 2 August 2022. This Internet-Draft will expire on 22 September 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 26 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Node Level . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Node Level . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Link and Termination Point Level . . . . . . . . . . . . 9 4.4. Link and Termination Point Level . . . . . . . . . . . . 10
5. Network and VPN Service Performance Monitoring YANG Module . 13 5. Network and VPN Service Performance Monitoring YANG Module . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.1. Normative References . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . 30
10.2. Informative References . . . . . . . . . . . . . . . . . 30 10.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Illustrating Examples . . . . . . . . . . . . . . . 32 Appendix A. Illustrating Examples . . . . . . . . . . . . . . . 34
A.1. VPN Performance Subscription Example . . . . . . . . . . 32 A.1. VPN Performance Subscription Example . . . . . . . . . . 34
A.2. Example of VPN Performance Snapshot . . . . . . . . . . . 33 A.2. Example of VPN Performance Snapshot . . . . . . . . . . . 35
A.3. Example of Percentile Monitoring . . . . . . . . . . . . 35 A.3. Example of Percentile Monitoring . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
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 proposes that the performance management with YANG models. It defines that the performance
measurement telemetry model to be tied with the service, such as measurement telemetry model to be tied with the service, such as
Layer 3 VPN and Layer 2 VPN, or network models to monitor the overall Layer 3 VPN and Layer 2 VPN, or network models to monitor the overall
network performance or Service Level Agreements (SLA). network performance or Service Level Agreement (SLA).
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 3, line 21 skipping to change at page 3, line 21
This document does not introduce new metrics for network performance This document does not introduce new metrics for network performance
or mechanisms for measuring network performance, but uses the or mechanisms for measuring network performance, but uses the
existing mechanisms and statistics to display the performance existing mechanisms and statistics to display the performance
monitoring statistics at the network and service layers. All these monitoring statistics at the network and service layers. All these
metrics are defined as unidirectional metrics. metrics are defined as unidirectional metrics.
The YANG module defined in this document is designed as an The YANG module defined in this document is designed as an
augmentation to the network topology YANG model defined in [RFC8345] augmentation to the network topology YANG model defined in [RFC8345]
and draws on relevant YANG types defined in [RFC6991], [RFC8345], and draws on relevant YANG types defined in [RFC6991], [RFC8345],
[RFC8532], and [I-D.ietf-opsawg-vpn-common]. [RFC8532], and [RFC9181].
Appendix A provides a set of examples to illustrate the use of the Appendix A provides a set of examples to illustrate the use of the
module. module.
2. Terminology 2. Terminology
The following terms are defined in [RFC7950] and are used in this The following terms are defined in [RFC7950] and are used in this
specification: specification:
* augment * augment
skipping to change at page 4, line 8 skipping to change at page 4, line 8
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
TE Traffic Engineering
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 5 skipping to change at page 4, line 43
+------+-+--------+ +------+-+--------+
| Network | | Network |
| Controller | | Controller |
+-------+---------+ +-------+---------+
| |
+-----------------------+------------------------+ +-----------------------+------------------------+
Network Network
Figure 1: Reference Architecture Figure 1: Reference Architecture
As shown in Figure 1, in the context of layering model architecture As shown in Figure 1, in the context of the layering model
described in [RFC8309], the network and VPN service performance architecture described in [RFC8309], the network and VPN service
monitoring (PM) model can be used to expose a set of performance performance monitoring (PM) model can be used to expose a set of
information to the above layer. Such information can be used by an performance information to the above layer. Such information can be
orchestrator to subscribe to performance data. The network used by an orchestrator to subscribe to performance data. The
controller will then notify the orchestrator about corresponding network controller will then notify the orchestrator about
parameter changes. corresponding parameter changes.
Before using the network and VPN service PM model, the mapping Before using the model, the controller needs to establish complete
between the VPN service topology and the underlying physical network topology visibility of the network and VPN. For example, the
should be set up. controller can use information from [RFC8345], [I-D.ietf-opsawg-sap]
or VPN instances. Then the controller derive network or VPN level
performance data by aggregating (and filtering) lower-level data
collected via monitoring counters of the involved devices.
The YANG module defined in this document is designed to derive VPN or The network or VPN performance data can be based on different
network level performance data based on lower-level data collected sources. For example, the performance monitoring data per link in
via monitoring counters of the involved devices. The performance the underlying network can be collected using a network performance
monitoring data per link in the underlying network can be collected measurement method such as One-Way Active Measurement Protocol
using a network performance measurement method such as One-Way Active (OWAMP) [RFC4656], Two-Way Active Measurement Protocol (TWAMP)
Measurement Protocol (OWAMP) [RFC4656], Two-Way Active Measurement [RFC5357], and Multiprotocol Label Switching (MPLS) Loss and Delay
Protocol (TWAMP) [RFC5357], and Multiprotocol Label Switching (MPLS) Measurement [RFC6374]. The performance monitoring information
Loss and Delay Measurement [RFC6374]. The performance monitoring reflecting the quality of the network or VPN service (e.g., end-to-
information reflecting the quality of the network or VPN service end network performance data between source node and destination node
(e.g., end-to-end network performance data between source node and in the network or between VPN sites) can be computed and aggregated,
destination node in the network or between VPN sites) can be computed for example, using the information from the Traffic Engineering
and aggregated, for example, using the information from the Traffic Database (TED), [RFC7471] [RFC8570] [RFC8571] or LMAP [RFC8194].
Engineering Database (TED), [RFC7471] [RFC8570] [RFC8571] or LMAP
[RFC8194].
The measurement and report intervals that are associated with these The measurement and report intervals that are associated with these
performance data usually depend on the configuration of the specific performance data usually depend on the configuration of the specific
measurement method or collection method or various combinations. measurement method or collection method or various combinations.
This document defines a network-wide measurement interval to align This document defines a network-wide measurement interval to align
measurement requirements for networks or VPN services. measurement requirements for networks or VPN services.
In addition, the amount of performance data collected from the In addition, the amount of performance data collected from the
devices can be huge. To avoid receiving a large amount of devices can be huge. To avoid receiving a large amount of
operational data of VPN instances, VPN interfaces, or tunnels, the operational data of VPN instances, VPN interfaces, or tunnels, the
network controller can specifically subscribe to metric-specific data network controller can specifically subscribe to metric-specific data
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 specific subscription model specified in [RFC8641] to subscribe to the
network performance data or VPN service performance data they are specific network performance data or VPN service performance data
interested in, at the data source. they are interested in, at the data source.
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.
3.2. Collecting Data On-demand 3.2. Collecting Data On-demand
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. 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
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".
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.
+----------------------+ +-----------------------+ +----------------------+ +-----------------------+
skipping to change at page 8, line 5 skipping to change at page 8, line 5
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
topology, VPN Network PM can also provide the performance status of
the underlay network and VPN services. For example, network PM can
provide link PM statistics and port statistics. VPN PM can provides
statistics on VPN access interfaces, the number of current VRF routes
or L2VPN MAC entry of VPN nodes, and performance statistics on the
logical point-to-point link between source and destination VPN nodes
or between source and destination VPN access interfaces. Figure 4
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
inter-VPN-access interface PM.
+-----------------------------------------------------+
| |
| VPN2 Link |
| |<-------------------->| |
| | | |
| VPN2+---+---+ +---+---+VPN2 |
| TP1| VN1 | Tunnel PM | VN3 |TP2 |
| ---+ PE A |==============| PE B +---- |
|vpn-access+-------+ +-------+ vpn-access|
|-interface| | -interface|
| |##############################| |
| |inter-vpn-access-interface PM | |
| |
+-----------------------------------------------------+
| |
| |
+----+ | TP+-----+ Link +---+ Link +-----+TP | +----+
| CE4+-+----------+ N1 +-------+-N2+-------+ N3 +----------+-+CE5 |
+----+ | 1-1+-----+1-2 2-1+---+2-2 3-1+-----+3-2 | +----+
| |
| |
+-----------------------------------------------------+
Legend:
N:node VN:VPN-Node
-:Link
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 LAN Service (VPLS). The values are taken from [RFC9181]. When a
[I-D.ietf-opsawg-vpn-common]. When a network topology instance network topology instance contains the L3VPN or other L2VPN network
contains the L3VPN or other L2VPN network type, it represents a VPN type, it represents a VPN instance that can perform performance
instance that can perform performance monitoring. monitoring.
The tree in Figure 4 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
[I-D.ietf-opsawg-vpn-common]). This identifier is used to [RFC9181]). This identifier is used to correlate the performance
correlate the performance status with the network service status with the network service configuration.
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 exchange traffic) that are taken from [RFC9181]. These VPN
[I-D.ietf-opsawg-vpn-common]. These VPN topology types can be topology types can be used to describe how VPN sites communicate
used to describe how VPN sites communicate with each other. with each other.
module: ietf-network-vpn-pm module: ietf-network-vpn-pm
augment /nw:networks/nw:network/nw:network-types: augment /nw:networks/nw:network/nw:network-types:
+--rw service-type! +--rw service-type!
+--rw service-type? identityref +--rw service-type? identityref
augment /nw:networks/nw:network: augment /nw:networks/nw:network:
+--rw vpn-pm-attributes +--rw vpn-pm-attributes
+--rw vpn-id? vpn-common:vpn-id +--rw vpn-id? vpn-common:vpn-id
+--rw vpn-service-topology? identityref +--rw vpn-service-topology? identityref
Figure 4: Network Level YANG Tree of the Hierarchies Figure 5: Network Level YANG Tree of the Hierarchies
4.3. Node Level 4.3. Node Level
The tree in Figure 5 is the node part of ietf-network-vpn-pm tree. The tree in Figure 6 is the node part of ietf-network-vpn-pm tree.
For network performance monitoring, a container of "pm-attributes" is For network performance monitoring, a container of "pm-attributes" is
augmented to the list of "node" that are defined in [RFC8345]. The augmented to the list of "node" that are defined in [RFC8345]. The
"node-type" indicates the device type of Provider Edge (PE), Provider container includes the following attributes:
(P) device, or Autonomous System Border Router (ASBR), so that the
performance metric between any two nodes each with specific node type
can be reported.
For VPN service performance monitoring, the model defines the
following minimal set of node level network topology attributes:
"role": Defines the role in a particular VPN service topology. The "node-type": Indicates the device type of Provider Edge (PE),
roles are taken from [I-D.ietf-opsawg-vpn-common] (e.g., any-to- Provider (P) device, or Autonomous System Border Router (ASBR), so
any-role, spoke-role, hub-role). that the performance metric between any two nodes each with
specific node type can be reported.
"vpn-summary-statistics": Lists a set of IPv4 statistics, IPv6 "entry-summary": Lists a set of IPv4 statistics, IPv6 statistics,
statistics, and MAC statistics. These statistics are specified and MAC statistics. The detailed statistics are specified
separately. separately.
For VPN service performance monitoring, the model defines one
attribute:
"role": Defines the role in a particular VPN service topology. The
roles are taken from [RFC9181] (e.g., any-to-any-role, spoke-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
+--rw role? identityref +--ro entry-summary
+--ro vpn-summary-statistics | +--ro ipv4
+--ro ipv4 | | +--ro maximum-routes? uint32
| +--ro maximum-routes? uint32 | | +--ro total-active-routes? uint32
| +--ro total-active-routes? uint32 | +--ro ipv6
+--ro ipv6 | | +--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
Figure 5: 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 6 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.
The performance data of a link is a collection of counters that The performance data of a link is a collection of counters that
report the performance status. 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
+--ro one-way-pm-statistics +--ro one-way-pm-statistics
| +--ro loss-statistics | +--ro loss-statistics
| | +--ro packet-loss-count? yang:counter64 | | +--ro packet-loss-count? yang:counter64
| | +--ro loss-ratio? percentage | | +--ro loss-ratio? percentage
| +--ro delay-statistics | +--ro delay-statistics
| | +--ro unit-value? identityref | | +--ro unit-value? identityref
| | +--ro min-delay-value? yang:gauge64 | | +--ro min-delay-value? yang:gauge64
| | +--ro max-delay-value? yang:gauge64 | | +--ro max-delay-value? yang:gauge64
| | +--ro low-delay-percentile? yang:gauge64 | | +--ro low-delay-percentile? yang:gauge64
| | +--ro intermediate-delay-percentile? yang:gauge64 | | +--ro intermediate-delay-percentile? yang:gauge64
| | +--ro high-delay-percentile? yang:gauge64 | | +--ro high-delay-percentile? yang:gauge64
| +--ro jitter-statistics | +--ro jitter-statistics
| +--ro unit-value? identityref | +--ro unit-value? identityref
| +--ro min-jitter-value? yang:gauge32 | +--ro min-jitter-value? yang:gauge32
| +--ro max-jitter-value? yang:gauge32 | +--ro max-jitter-value? yang:gauge32
| +--ro low-jitter-percentile? yang:gauge32 | +--ro low-jitter-percentile? yang:gauge32
| +--ro intermediate-jitter-percentile? yang:gauge32 | +--ro intermediate-jitter-percentile? yang:gauge32
| +--ro high-jitter-percentile? yang:gauge32 | +--ro high-jitter-percentile? yang:gauge32
+--ro vpn-underlay-transport-type? identityref +--ro one-way-pm-statistics-per-class* [class-id]
+--ro vpn-one-way-pm-statistics* [class-id] | +--ro class-id string
+--ro class-id string | +--ro loss-statistics
+--ro loss-statistics | | +--ro packet-loss-count? yang:counter64
| +--ro packet-loss-count? yang:counter64 | | +--ro loss-ratio? percentage
| +--ro loss-ratio? percentage | +--ro delay-statistics
+--ro delay-statistics | | +--ro unit-value? identityref
| +--ro unit-value? identityref | | +--ro min-delay-value? yang:gauge64
| +--ro min-delay-value? yang:gauge64 | | +--ro max-delay-value? yang:gauge64
| +--ro max-delay-value? yang:gauge64 | | +--ro low-delay-percentile? yang:gauge64
| +--ro low-delay-percentile? yang:gauge64 | | +--ro intermediate-delay-percentile? yang:gauge64
| +--ro intermediate-delay-percentile? yang:gauge64 | | +--ro high-delay-percentile? yang:gauge64
| +--ro high-delay-percentile? yang:gauge64 | +--ro jitter-statistics
+--ro jitter-statistics | +--ro unit-value? identityref
+--ro unit-value? identityref | +--ro min-jitter-value? yang:gauge32
+--ro min-jitter-value? yang:gauge32 | +--ro max-jitter-value? yang:gauge32
+--ro max-jitter-value? yang:gauge32 | +--ro low-jitter-percentile? yang:gauge32
+--ro low-jitter-percentile? yang:gauge32 | +--ro intermediate-jitter-percentile? yang:gauge32
+--ro intermediate-jitter-percentile? yang:gauge32 | +--ro high-jitter-percentile? yang:gauge32
+--ro high-jitter-percentile? yang:gauge32 +--rw (vpn-pm-type)?
+--:(inter-vpn-access-interface)
| +--rw inter-vpn-access-interface? empty
+--:(underlay-tunnel)
+--ro vpn-underlay-transport-type? identityref
augment /nw:networks/nw:network/nw:node/nt:termination-point: augment /nw:networks/nw:network/nw:node/nt:termination-point:
+--ro pm-statistics +--ro pm-statistics
+--ro reference-time? yang:date-and-time +--ro reference-time? yang:date-and-time
+--ro inbound-octets? yang:counter64 +--ro inbound-octets? yang:counter64
+--ro inbound-unicast? yang:counter64 +--ro inbound-unicast? yang:counter64
+--ro inbound-nunicast? yang:counter64 +--ro inbound-nunicast? yang:counter64
+--ro inbound-discards? yang:counter32 +--ro inbound-discards? yang:counter64
+--ro inbound-errors? yang:counter64 +--ro inbound-errors? yang:counter64
+--ro inbound-unknown-protocol? yang:counter64 +--ro inbound-unknown-protocol? yang:counter64
+--ro outbound-octets? yang:counter64 +--ro outbound-octets? yang:counter64
+--ro outbound-unicast? yang:counter64 +--ro outbound-unicast? yang:counter64
+--ro outbound-nunicast? yang:counter64 +--ro outbound-nunicast? yang:counter64
+--ro outbound-discards? yang:counter64 +--ro outbound-discards? yang:counter64
+--ro outbound-errors? yang:counter64 +--ro outbound-errors? yang:counter64
+--ro vpn-network-access* [network-access-id] +--ro vpn-network-access* [network-access-id]
+--ro network-access-id vpn-common:vpn-id +--ro network-access-id vpn-common:vpn-id
+--ro reference-time? yang:date-and-time +--ro reference-time? yang:date-and-time
+--ro inbound-octets? yang:counter64 +--ro inbound-octets? yang:counter64
+--ro inbound-unicast? yang:counter64 +--ro inbound-unicast? yang:counter64
+--ro inbound-nunicast? yang:counter64 +--ro inbound-nunicast? yang:counter64
+--ro inbound-discards? yang:counter32 +--ro inbound-discards? yang:counter64
+--ro inbound-errors? yang:counter64 +--ro inbound-errors? yang:counter64
+--ro inbound-unknown-protocol? yang:counter64 +--ro inbound-unknown-protocol? yang:counter64
+--ro outbound-octets? yang:counter64 +--ro outbound-octets? yang:counter64
+--ro outbound-unicast? yang:counter64 +--ro outbound-unicast? yang:counter64
+--ro outbound-nunicast? yang:counter64 +--ro outbound-nunicast? yang:counter64
+--ro outbound-discards? yang:counter64 +--ro outbound-discards? yang:counter64
+--ro outbound-errors? yang:counter64 +--ro outbound-errors? yang:counter64
Figure 6: Link and Termination point Level YANG Tree of the Figure 7: Link and Termination point Level YANG Tree of the
hierarchies hierarchies
For the data nodes of 'link' depicted in Figure 6, the YANG module For the data nodes of 'link' depicted in Figure 7, the YANG module
defines the following minimal set of link-level performance defines the following minimal set of link-level performance
attributes: attributes:
Percentile parameters: The module supports reporting delay and Percentile parameters: The module supports reporting delay and
jitter metric by percentile values. By default, low percentile jitter metric by percentile values. By default, low percentile
(10th percentile), intermediate percentile (50th percentile), high (10th percentile), intermediate percentile (50th percentile), high
percentile (90th percentile) are used. Setting a percentile to percentile (90th percentile) are used. Setting a percentile to
0.00 indicates the client is not interested in receiving 0.00 indicates the client is not interested in receiving
particular percentile. If all percentile nodes are set to 0.00, particular percentile. If all percentile nodes are set to 0.00,
this represents that no percentile related nodes will be reported this represents that no percentile related nodes will be reported
skipping to change at page 12, line 4 skipping to change at page 12, line 48
receiving only high percentiles. Then for a given link, at a receiving only high percentiles. Then for a given link, at a
given "start-time", "end-time" and "measurement-interval", the given "start-time", "end-time" and "measurement-interval", the
'high-delay-percentile' and 'high-jitter-percentile' will be 'high-delay-percentile' and 'high-jitter-percentile' will be
reported. An example to illustrate the use of percentiles is reported. An example to illustrate the use of percentiles is
provided in Appendix A.3. provided in Appendix A.3.
PM source ("pm-source"): Indicates the performance monitoring PM source ("pm-source"): Indicates the performance monitoring
source. The data for the topology link can be based, e.g., on source. The data for the topology link can be based, e.g., on
BGP-LS [RFC8571]. The statistics of the VPN abstract links can be BGP-LS [RFC8571]. The statistics of the VPN abstract links can be
collected based upon VPN OAM mechanisms, e.g.,OAM mechanisms collected based upon VPN OAM mechanisms, e.g.,OAM mechanisms
referenced in [I-D.ietf-opsawg-l3sm-l3nm], or Ethernet service OAM referenced in [RFC9182], or Ethernet service OAM [ITU-T-Y-1731]
[ITU-T-Y-1731] referenced in [I-D.ietf-opsawg-l2nm]. referenced in [I-D.ietf-opsawg-l2nm]. Alternatively, the data can
Alternatively, the data can be based upon the underlay technology be based upon the underlay technology OAM mechanisms, for example,
OAM mechanisms, for example, Generic Routing Encapsulation (GRE) Generic Routing Encapsulation (GRE) tunnel OAM.
tunnel OAM.
Measurement interval ("measurement-interval"): Specifies the Measurement interval ("measurement-interval"): Specifies the
performance measurement interval, in seconds. performance measurement interval, in seconds.
Start time ("start-time"): Indicates the start time of the Start time ("start-time"): Indicates the start time of the
performance measurement for link statistics. performance measurement for link statistics.
End time ("end-time"): Indicates the end time of the performance End time ("end-time"): Indicates the end time of the performance
measurement for link statistics. measurement for link statistics.
skipping to change at page 12, line 37 skipping to change at page 13, line 32
Delay statistics: A set of one-way delay statistics attributes that Delay statistics: A set of one-way delay statistics attributes that
are used to measure end to end latency between VPN sites or are used to measure end to end latency between VPN sites or
between any two network nodes. The peak/min values or percentile between any two network nodes. The peak/min values or percentile
values can be reported. values can be reported.
Jitter statistics: A set of one-way IP Packet Delay Variation Jitter statistics: A set of one-way IP Packet Delay Variation
[RFC3393] statistics attributes that are used to measure end to [RFC3393] statistics attributes that are used to measure end to
end jitter between VPN sites or between any two network nodes. end jitter between VPN sites or between any two network nodes.
The peak/min values or percentile values can be reported. The peak/min values or percentile values can be reported.
PM statistics per class ("one-way-pm-statistics-per-class"): Lists p
erformance measurement statistics for the topology link or the
abstract underlay link between VPN PEs with given "class-id"
names. The list is defined separately from "one-way-pm-
statistics", which is used to collect generic metrics for
unspecified "class-id" names.
VPN PM type ("vpn-pm-type"): Indicates the VPN performance type,
which can be inter-vpn-access-interface PM or VPN underlay-tunnel
PM. These two methods are common VPN measurement methods. The
inter-VPN-access-interface PM is to monitor the performance of
logical point-to-point connections between a source and a
destination VPN access interfaces. And the underlay-tunnel PM is
to monitor the performance of underlay tunnels of VPNs. The
inter-VPN-access-interface PM includes PE-PE monitoring.
Therefore, only one of the two methods is needed , and the model
defines "choice" to indicate these two methods, which also allows
other methods to be extended.
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 [I-D.ietf-opsawg-vpn-common], which describes the defined in [RFC9181], which describes the transport technology to
transport technology to carry the traffic of the VPN service. carry the traffic of the VPN service.
VPN PM statistics ("vpn-unidirectional-pm-statistics"): Lists
performance measurement statistics for the abstract underlay link
between VPN PEs with given "class-id" names. The list is defined
separately from "one-way-pm-statistics", which is used to collect
generic metrics for unspecified "class-id" names.
For the data nodes of 'termination-point' depicted in Figure 6, 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:
Inbound statistics: A set of inbound statistics attributes that are Inbound statistics: A set of inbound statistics attributes that are
used to measure the inbound statistics of the termination point, used to measure the inbound statistics of the termination point,
such as received packets, received packets with errors, etc. such as received packets, received packets with errors, etc.
Outbound statistics: A set of outbound statistics attributes that Outbound statistics: A set of outbound statistics attributes that
are used to measure the outbound statistics of the termination are used to measure the outbound statistics of the termination
point, such as sent packets, packets that could not be sent due to point, such as sent packets, packets that could not be sent due to
errors, etc. errors, etc.
VPN network access ("vpn-network-access"): Lists counters of the VPN VPN network access ("vpn-network-access"): Lists counters of the VPN
network access defined in [I-D.ietf-opsawg-l3sm-l3nm] or network access defined in [RFC9182] or [I-D.ietf-opsawg-l2nm].
[I-D.ietf-opsawg-l2nm]. When multiple VPN network accesses are When multiple VPN network accesses are created using the same
created using the same physical port, finer-grained metrics can be physical port, finer-grained metrics can be monitored. If a TP is
monitored. 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 [I-D.ietf-opsawg-vpn-common]. [RFC6991], [RFC8532], and [RFC9181].
<CODE BEGINS> file "ietf-network-vpn-pm@2021-01-28.yang" <CODE BEGINS> file "ietf-network-vpn-pm@2021-03-21.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";
} }
import ietf-vpn-common { import ietf-vpn-common {
prefix vpn-common; prefix vpn-common;
reference reference
"RFC CCCC: A Layer 2/3 VPN Common YANG Model."; "RFC 9181: A Common YANG Data Model for Layer 2 and
// RFC Ed.: replace CCCC with actual RFC number and remove Layer 3 VPNs.";
// this note.
} }
import ietf-network { import ietf-network {
prefix nw; prefix nw;
reference reference
"RFC 8345: A YANG Data Model for Network "RFC 8345: A YANG Data Model for Network
Topologies, Section 6.1"; Topologies, Section 6.1";
} }
import ietf-network-topology { import ietf-network-topology {
prefix nt; prefix nt;
reference reference
skipping to change at page 14, line 15 skipping to change at page 15, line 22
} }
import ietf-lime-time-types { import ietf-lime-time-types {
prefix lime; prefix lime;
reference reference
"RFC 8532: Generic YANG Data Model for the Management of "RFC 8532: Generic YANG Data Model for the Management of
Operations, Administration, and Maintenance (OAM) Protocols Operations, Administration, and Maintenance (OAM) Protocols
That Use Connectionless Communications"; That Use Connectionless Communications";
} }
organization organization
"IETF OPSAWG Working Group"; "IETF OPSAWG (Operations and Management Area Working Group)";
contact contact
"Editor: Qin Wu "WG Web: <https://datatracker.ietf.org/wg/opsawg/>
<bill.wu@huawei.com> WG List: <mailto:opsawg@ietf.org>
Editor: Bo Wu Editor: Bo Wu
<lana.wubo@huawei.com> <lana.wubo@huawei.com>
Editor: Mohamed Boucadair Editor: Mohamed Boucadair
<mohamed.boucadair@orange.com>"; <mohamed.boucadair@orange.com>
Editor: Qin Wu
<bill.wu@huawei.com>
Author: Oscar Gonzalez de Dios
<oscar.gonzalezdedios@telefonica.com>
Author: Bin Wen
<bin_wen@comcast.com>";
description description
"This module defines a model for Network and VPN Service "This module defines a model for Network and VPN Service
Performance monitoring. Performance monitoring.
Copyright (c) 2022 IETF Trust and the persons identified as Copyright (c) 2022 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject
the license terms contained in, the Simplified BSD License set to the license terms contained in, the Revised BSD License
forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
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-01-28 { revision 2022-03-21 {
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";
} }
identity pe { identity pe {
base node-type; base node-type;
description description
skipping to change at page 17, line 9 skipping to change at page 18, line 23
description description
"The percentile is a value between 0 and 100, "The percentile is a value between 0 and 100,
e.g. 10.00, 99.90 ,99.99 etc.. e.g. 10.00, 99.90 ,99.99 etc..
For example, for a given one-way delay measurement, For example, for a given one-way delay measurement,
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 vpn-summary-statistics { grouping entry-summary {
description description
"VPN Statistics grouping used for network topology "Entry summary grouping used for network topology
augmentation."; augmentation.";
container vpn-summary-statistics { container entry-summary {
config false; config false;
description description
"Container for VPN summary statistics."; "Container for VPN or network entry summary.";
container ipv4 { container ipv4 {
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
skipping to change at page 21, line 4 skipping to change at page 22, line 19
type yang:date-and-time; type yang:date-and-time;
config false; config false;
description description
"Indicates the time when the statistics are collected."; "Indicates the time when the statistics are collected.";
} }
leaf inbound-octets { leaf inbound-octets {
type yang:counter64; type yang:counter64;
description description
"The total number of octets received on the "The total number of octets received on the
interface, including framing characters."; interface, including framing characters.";
} }
leaf inbound-unicast { leaf inbound-unicast {
type yang:counter64; type yang:counter64;
description description
"The total number of inbound unicast packets."; "The total number of inbound unicast packets.";
} }
leaf inbound-nunicast { leaf inbound-nunicast {
type yang:counter64; type yang:counter64;
description description
"The total number of non-unicast "The total number of inbound non-unicast
(i.e., broadcast or multicast) packets."; (i.e., broadcast or multicast) packets.";
} }
leaf inbound-discards { leaf inbound-discards {
type yang:counter32; type yang:counter64;
description description
"The number of inbound packets that were chosen to be "The number of inbound packets that were chosen to be
discarded even though no errors had been detected. discarded even though no errors had been detected.
One possible reason for discarding such a One possible reason for discarding such a
packet could be to free up buffer space"; packet could be to free up buffer space";
} }
leaf inbound-errors { leaf inbound-errors {
type yang:counter64; type yang:counter64;
description description
"The number of inbound packets that contained errors."; "The number of inbound packets that contained errors.";
skipping to change at page 23, line 33 skipping to change at page 24, line 47
container pm-attributes { container pm-attributes {
leaf node-type { leaf node-type {
type identityref { type identityref {
base node-type; base node-type;
} }
description description
"Node type, e.g., PE, P, ASBR."; "Node type, e.g., PE, P, ASBR.";
} }
description description
"Container for node attributes."; "Container for node attributes.";
uses entry-summary;
} }
} }
augment "/nw:networks/nw:network/nw:node/pm-attributes" { augment "/nw:networks/nw:network/nw:node/pm-attributes" {
when '../../nw:network-types/nvp:service-type' { when '../../nw:network-types/nvp:service-type' {
description description
"Augments only for VPN node attributes."; "Augments only for VPN node attributes.";
} }
description description
"Augments the network node with VPN specific attributes."; "Augments the network node with VPN specific attributes.";
leaf role { leaf role {
type identityref { type identityref {
base vpn-common:role; base vpn-common:role;
} }
default "vpn-common:any-to-any-role"; default "vpn-common:any-to-any-role";
description description
"Role of the node in the VPN."; "Role of the node in the VPN.";
} }
uses vpn-summary-statistics;
} }
augment "/nw:networks/nw:network/nt:link" { augment "/nw:networks/nw:network/nt:link" {
description description
"Augments the network topology link with performance "Augments the network topology link with performance
monitoring attributes."; monitoring attributes.";
container pm-attributes { container pm-attributes {
description description
"Container for PM attributes."; "Container for PM attributes.";
leaf low-percentile { leaf low-percentile {
skipping to change at page 24, line 39 skipping to change at page 26, line 4
} }
leaf high-percentile { leaf high-percentile {
type percentile; type percentile;
default "95.00"; default "95.00";
description description
"High percentile to report. Setting high-percentile "High percentile to report. Setting high-percentile
into 0.00 indicates the client is not interested in into 0.00 indicates the client is not interested in
receiving high percentile."; receiving high percentile.";
} }
leaf measurement-interval { leaf measurement-interval {
type uint32; type uint32 {
range "1..max";
}
units "seconds"; units "seconds";
default "60"; default "60";
description description
"Indicates the time interval to perform PM measurement."; "Indicates the time interval to perform PM measurement.";
} }
leaf start-time { leaf start-time {
type yang:date-and-time; type yang:date-and-time;
config false; config false;
description description
"The time that the current measurement started."; "The time that the current measurement started.";
skipping to change at page 25, line 24 skipping to change at page 26, line 40
"The OAM tool used to collect the PM data."; "The OAM tool used to collect the PM data.";
} }
container one-way-pm-statistics { container one-way-pm-statistics {
config false; config false;
description description
"Container for link telemetry attributes."; "Container for link telemetry attributes.";
uses link-loss-statistics; uses link-loss-statistics;
uses link-delay-statistics; uses link-delay-statistics;
uses link-jitter-statistics; uses link-jitter-statistics;
} }
list one-way-pm-statistics-per-class {
key "class-id";
config false;
description
"The list of PM data based on class of service.";
leaf class-id {
type string;
description
"The class-id is used to identify the class of service.
This identifier is internal to the administration.";
}
uses link-loss-statistics;
uses link-delay-statistics;
uses link-jitter-statistics;
}
} }
} }
augment "/nw:networks/nw:network/nt:link/pm-attributes" { augment "/nw:networks/nw:network/nt:link/pm-attributes" {
when '../../nw:network-types/nvp:service-type' { when '../../nw:network-types/nvp:service-type' {
description description
"Augments only for VPN Network topology."; "Augments only for VPN Network topology.";
} }
description description
"Augments the network topology link with VPN service "Augments the network topology link with VPN service
performance monitoring attributes."; performance monitoring attributes.";
leaf vpn-underlay-transport-type { choice vpn-pm-type {
type identityref {
base vpn-common:protocol-type;
}
config false;
description
"The leaf indicates the underlay transport type of
a VPN service, e.g., GRE, LDP, etc.";
}
list vpn-one-way-pm-statistics {
key "class-id";
config false;
description description
"The list of PM data based on class of service."; "The VPN PM type of this logical point-to-point
leaf class-id { unidirectional VPN link.";
type string; case inter-vpn-access-interface {
description leaf inter-vpn-access-interface {
"The class-id is used to identify the class of service. type empty;
This identifier is internal to the administration."; description
"This is a placeholder for inter-vpn-access-interface PM.
There is no technology to be defined.";
}
}
case underlay-tunnel {
leaf vpn-underlay-transport-type {
type identityref {
base vpn-common:protocol-type;
}
config false;
description
"The leaf indicates the underlay transport type of
a VPN service, e.g., GRE, LDP, etc.";
}
} }
uses link-loss-statistics;
uses link-delay-statistics;
uses link-jitter-statistics;
} }
} }
augment "/nw:networks/nw:network/nw:node/nt:termination-point" { augment "/nw:networks/nw:network/nw:node/nt:termination-point" {
description description
"Augments the network topology termination point with "Augments the network topology termination point with
performance monitoring attributes."; performance monitoring attributes.";
container pm-statistics { container pm-statistics {
config false; config false;
description description
skipping to change at page 27, line 38 skipping to change at page 29, line 21
operation that can be exploited to impact the network monitoring: operation that can be exploited to impact the network monitoring:
* "/nw:networks/nw:network/nw:network-types" * "/nw:networks/nw:network/nw:network-types"
* "/nw:networks/nw:network/nvp:vpn-pm-attributes" * "/nw:networks/nw:network/nvp:vpn-pm-attributes"
* "/nw:networks/nw:network/nw:node/nvp:pm-attributes" * "/nw:networks/nw:network/nw:node/nvp:pm-attributes"
* /nw:networks/nw:network/nt:link/nvp:pm-attributes" * /nw:networks/nw:network/nt:link/nvp:pm-attributes"
* /nw:networks/nw:network/nw:node/nt:termination-point/nvp:pm-
statistics"
Some of the readable data nodes in this YANG module may be considered Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. The nodes sensitive or vulnerable in some network environments. The nodes
reveals the quality of a service that is operated by an operator. It reveals the quality of a service that is operated by an operator. It
is thus important to control read access (e.g., via get, get-config, is thus important to control read access (e.g., via get, get-config,
or notification) to these data nodes. These are the subtrees and or notification) to these data nodes. These are the subtrees and
data nodes and their sensitivity/vulnerability: data nodes and their sensitivity/vulnerability:
* "/nw:networks/nw:network/nw:node/nvp:pm-attributes/nvp:vpn- * "/nw:networks/nw:network/nw:node/nvp:pm-attributes/nvp:vpn-
summary-statistics": Unauthorized access to this subtree can summary-statistics": Unauthorized access to this subtree can
disclose the operational state information of VPN instances. disclose the operational state information of VPN instances.
* "/nw:networks/nw:network/nt:link/nvp:pm-attributes/nvp:one-way-pm- * "/nw:networks/nw:network/nt:link/nvp:pm-attributes/nvp:one-way-pm-
statistics": Unauthorized access to this subtree can disclose the statistics": Unauthorized access to this subtree can disclose the
operational state information of network links or VPN underlay operational state information of network links or VPN abstract
tunnels. links.
* "/nw:networks/nw:network/nw:node/nt:termination-point/nvp:pm- * "/nw:networks/nw:network/nw:node/nt:termination-point/nvp:pm-
statistics": Unauthorized access to this subtree can disclose the statistics": Unauthorized access to this subtree can disclose the
operational state information of network termination points or VPN operational state information of network termination points or VPN
network accesses. network accesses.
7. IANA Considerations 7. IANA Considerations
This document requests IANA to register the following URI in the "ns" This document requests IANA to register the following URI in the "ns"
subregistry within the "IETF XML Registry" [RFC3688]: subregistry within the "IETF XML Registry" [RFC3688]:
skipping to change at page 28, line 32 skipping to change at page 30, line 18
Name: ietf-network-vpn-pm Name: ietf-network-vpn-pm
Namespace: urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm Namespace: urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm
Maintained by IANA: N Maintained by IANA: N
Prefix: nvp Prefix: nvp
Reference: RFC XXXX (RFC Ed.: replace XXXX with actual Reference: RFC XXXX (RFC Ed.: replace XXXX with actual
RFC number and remove this note.) RFC number and remove this note.)
8. Acknowledgements 8. Acknowledgements
Thanks to Joe Clarke, Adrian Farrel, Greg Mirsky, Roque Gagliano, Thanks to Joe Clarke, Adrian Farrel, Tom Petch, Greg Mirsky, Roque
Erez Segev, and Dhruv Dhody for reviewing and providing important Gagliano, Erez Segev, and Dhruv Dhody for reviewing and providing
input to this document. important input to this document.
9. Contributors 9. Contributors
The following authors contributed significantly to this document: The following authors contributed significantly to this document:
Michale Wang Michale Wang
Huawei Huawei
Email:wangzitao@huawei.com Email:wangzitao@huawei.com
Roni Even Roni Even
skipping to change at page 29, line 25 skipping to change at page 30, line 46
Email: liuc131@chinaunicom.cn Email: liuc131@chinaunicom.cn
Honglei Xu Honglei Xu
China Telecom China Telecom
Email: xuhl.bri@chinatelecom.cn Email: xuhl.bri@chinatelecom.cn
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-opsawg-vpn-common]
Barguil, S., Dios, O. G. D., Boucadair, M., and Q. Wu, "A
Layer 2/3 VPN Common YANG Model", Work in Progress,
Internet-Draft, draft-ietf-opsawg-vpn-common-12, 29
September 2021, <https://www.ietf.org/archive/id/draft-
ietf-opsawg-vpn-common-12.txt>.
[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>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
skipping to change at page 30, line 51 skipping to change at page 32, line 16
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>.
[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.,
Ed., and Q. Wu, "A Common YANG Data Model for Layer 2 and
Layer 3 VPNs", RFC 9181, DOI 10.17487/RFC9181, February
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", Work in Progress, "Self-Describing Data Object Tags in YANG Data Models",
Internet-Draft, draft-ietf-netmod-node-tags-04, 11 Work in Progress, Internet-Draft, draft-ietf-netmod-node-
November 2021, <https://www.ietf.org/archive/id/draft- tags-06, 21 February 2022,
ietf-netmod-node-tags-04.txt>. <https://www.ietf.org/archive/id/draft-ietf-netmod-node-
tags-06.txt>.
[I-D.ietf-opsawg-l2nm] [I-D.ietf-opsawg-l2nm]
Barguil, S., Dios, O. G. D., Boucadair, M., and L. A. Barguil, S., Dios, O. G. D., Boucadair, M., and L. A.
Munoz, "A Layer 2 VPN Network YANG Model", Work in Munoz, "A Layer 2 VPN Network YANG Model", Work in
Progress, Internet-Draft, draft-ietf-opsawg-l2nm-12, 22 Progress, Internet-Draft, draft-ietf-opsawg-l2nm-12, 22
November 2021, <https://www.ietf.org/archive/id/draft- November 2021, <https://www.ietf.org/archive/id/draft-
ietf-opsawg-l2nm-12.txt>. ietf-opsawg-l2nm-12.txt>.
[I-D.ietf-opsawg-l3sm-l3nm] [I-D.ietf-opsawg-sap]
Barguil, S., Dios, O. G. D., Boucadair, M., Munoz, L. A., Boucadair, M., Dios, O. G. D., Barguil, S., Wu, Q., and V.
and A. Aguado, "A Layer 3 VPN Network YANG Model", Work in Lopez, "A Network YANG Model for Service Attachment Points
Progress, Internet-Draft, draft-ietf-opsawg-l3sm-l3nm-18, (SAPs)", Work in Progress, Internet-Draft, draft-ietf-
8 October 2021, <https://www.ietf.org/archive/id/draft- opsawg-sap-02, 22 February 2022,
ietf-opsawg-l3sm-l3nm-18.txt>. <https://www.ietf.org/archive/id/draft-ietf-opsawg-sap-
02.txt>.
[ITU-T-Y-1731] [ITU-T-Y-1731]
ITU-T, "Operator Ethernet Service Definition", August ITU-T, "Operator Ethernet Service Definition", August
2015, <https://www.itu.int/rec/T-REC-Y.1731/en>. 2015, <https://www.itu.int/rec/T-REC-Y.1731/en>.
[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>.
skipping to change at page 32, line 25 skipping to change at page 33, line 48
C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of
IGP Traffic Engineering Performance Metric Extensions", IGP Traffic Engineering Performance Metric Extensions",
RFC 8571, DOI 10.17487/RFC8571, March 2019, RFC 8571, DOI 10.17487/RFC8571, March 2019,
<https://www.rfc-editor.org/info/rfc8571>. <https://www.rfc-editor.org/info/rfc8571>.
[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.,
Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model
for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182,
February 2022, <https://www.rfc-editor.org/info/rfc9182>.
Appendix A. Illustrating Examples Appendix A. Illustrating Examples
A.1. VPN Performance Subscription Example A.1. VPN Performance Subscription Example
The example shown in Figure 7 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-topo:networks":{ "ietf-network-topo:networks":{
skipping to change at page 33, line 4 skipping to change at page 34, line 32
"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":{
"tp-id":"1-0-1", "tp-id":"1-0-1"
} }
}, },
{ {
"node-id":"B", "node-id":"B",
"ietf-network-vpn-pm:pm-attributes":{ "ietf-network-vpn-pm:pm-attributes":{
"node-type":"PE" "node-type":"PE"
}, },
"termination-point":{ "termination-point":{
"tp-id":"2-0-1", "tp-id":"2-0-1"
} }
} }
], ],
"link":{ "link":{
"link-id":"A-B", "link-id":"A-B",
"source":{ "source":{
"source-node":"A" "source-node":"A"
}, },
"destination":{ "destination":{
"dest-node":"B" "dest-node":"B"
skipping to change at page 33, line 43 skipping to change at page 35, line 24
} }
} }
} }
}, },
"ietf-yang-push:periodic":{ "ietf-yang-push:periodic":{
"ietf-yang-push:period":"500" "ietf-yang-push:period":"500"
} }
} }
} }
Figure 7: Pub/Sub Retrieval Figure 8: Pub/Sub Retrieval
A.2. Example of VPN Performance Snapshot A.2. Example of VPN Performance Snapshot
This example, depicted in Figure 8, illustrates an VPN PM instance This example, depicted in Figure 9, illustrates an VPN PM instance
example in which a client uses RESTCONF [RFC8040] to fetch the example in which a client uses RESTCONF [RFC8040] to fetch the
performance data of the link and TP belonged to "VPN1". performance data of the link and TP belonged to "VPN1".
{ {
"ietf-network-topo:networks": { "ietf-network-topo:networks": {
"network": { "network": {
"network-id": "vpn1", "network-id": "foo:vpn1",
"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": {
"tp-id": "1-0-1", "tp-id": "1-0-1",
"ietf-network-vpn-pm:pm-statistics": { "ietf-network-vpn-pm:pm-statistics": {
"inbound-octets": "100", "inbound-octets": "100",
skipping to change at page 34, line 46 skipping to change at page 36, line 46
], ],
"link": { "link": {
"link-id": "A-B", "link-id": "A-B",
"source": { "source-node": "A" }, "source": { "source-node": "A" },
"destination": { "dest-node": "B" }, "destination": { "dest-node": "B" },
"ietf-network-pm:pm-attributes": { "ietf-network-pm:pm-attributes": {
"one-way-pm-statistics": { "one-way-pm-statistics": {
"loss-statistics": { "packet-loss-count": "120" } "loss-statistics": { "packet-loss-count": "120" }
}, },
"vpn-underlay-transport-type": "ietf-vpn-common:gre" "vpn-underlay-transport-type": "ietf-vpn-common:gre"
}, }
} }
} }
} }
} }
Figure 8 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": "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",
"middle-percentile":"50.00", "middle-percentile": "50.00",
"high-percentile":"90.00", "high-percentile": "90.00",
"one-way-pm-statistics:delay-statistics":{ "one-way-pm-statistics": {
"unit-values":"lime:milliseconds", "delay-statistics": {
"min-delay-value":"43", "unit-values": "lime:milliseconds",
"max-delay-value":"99", "min-delay-value": "43",
"low-delay-percentile":"64", "max-delay-value": "99",
"middle-delay-percentile":"77", "low-delay-percentile": "64",
"high-delay-percentile":"98" "intermediate-delay-percentile": "77",
}, "high-delay-percentile": "98"
"ietf-network-vpn-pm:vpn-underlay-transport-type": }
"ietf-vpn-common:gre", },
} "ietf-network-vpn-pm:inter-vpn-access-interface": [null]
} }
] }
]
} }
Authors' Addresses Authors' Addresses
Bo Wu (editor) Bo Wu (editor)
Huawei Huawei
101 Software Avenue, Yuhua District 101 Software Avenue, Yuhua District
Nanjing Nanjing
Jiangsu, 210012 Jiangsu, 210012
China China
 End of changes. 82 change blocks. 
243 lines changed or deleted 329 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/