A YANG Data Model for Network and VPN Service Performance Monitoring
Extracted elements (19)
The 'inter-vpn-access-interface' PM leaf is defined as type 'empty' and is not bound to a specific VPN access interface, allowing source or destination VPN access interface details to be augmented as needed by technology-specific extensions.
The module does not introduce new performance metrics or measurement mechanisms; it reuses existing OAM mechanisms (OWAMP, TWAMP, STAMP, MPLS Loss and Delay, IOAM, BGP-LS, ITU-T Y.1731) as data sources. This avoids duplicating measurement standards and focuses the module on unified monitoring and management.
The 'service' container in 'network-types' uses YANG presence semantics so that a single YANG module can monitor both underlay networks and overlay VPN services as separate entries in the network list. Absence of the container indicates network PM; presence indicates VPN service PM.
Performance data can be retrieved on-demand via NETCONF (RFC 6241) or RESTCONF (RFC 8040) using filters such as 'link-id'. It can also be obtained via subscription using YANG-Push (RFC 8641) for periodic, on-change, or replay notifications, and via alarm notifications (RFC 8632) for threshold crossings.
The module is designed as an augmentation to RFC 8345 ('ietf-network' and 'ietf-network-topology') and imports types from RFC 6991, RFC 8345, RFC 8532, and RFC 9181. Controllers must first establish topology visibility using RFC 8345 and related VPN models (L3NM RFC 9182, L2NM RFC 9291) before using the PM module.
All link-level performance metrics (loss, delay, jitter) are defined as unidirectional (one-way) metrics. Loss is reported as packet-loss-count (yang:counter64) or loss-ratio (percentage to 5 decimal places). Delay and jitter report min, max, and three configurable percentile values with configurable time units (default: milliseconds).
Percentile reporting is controlled by three configurable leaves: 'low-percentile' (default 10.000), 'intermediate-percentile' (default 50.000), and 'high-percentile' (default 95.000), each typed as decimal64 with 3 fraction digits in range 0..100. Setting a percentile to 0.000 disables reporting of that percentile; setting all three to 0.000 suppresses all percentile reporting and reports only peak/min values.
The 'ietf-network-vpn-pm' YANG module augments the RFC 8345 'ietf-network' and 'ietf-network-topology' modules to provide performance monitoring (PM) for both underlay networks and overlay VPN services. The presence or absence of the 'service' container in 'network-types' distinguishes VPN service PM from network PM.
The link-level augmentation defines a 'perf-mon' container with configurable percentile parameters (low, intermediate, high), a 'measurement-interval' in seconds, and a 'pm' list keyed by 'pm-type'. Each PM entry carries start/end times, pm-source, one-way loss/delay/jitter statistics, and per-class statistics.
The network-level augmentation adds a 'service' presence container to '/nw:networks/nw:network/nw:network-types'. When present, it carries 'service-type' (mandatory, e.g., L3VPN or VPLS), 'vpn-id', and 'vpn-service-topology' (any-to-any, hub-spoke, hub-spoke-disjoint).
The node-level augmentation adds 'node-type' (PE, P, or ASBR), an 'entry-summary' container with IPv4, IPv6, and MAC route/entry counts, and a 'role' leaf (any-to-any-role, spoke-role, hub-role) for VPN service topology nodes.
The 'one-way-pm-statistics-per-class' list, keyed by 'class-id' (string), provides per-class-of-service loss, delay, and jitter statistics on each link. This is separate from the generic 'one-way-pm-statistics' container which covers traffic with unspecified class-id.
The 'pm-source' leaf (identityref) identifies the OAM tool used to collect PM data. Defined identities include pm-source-bgpls (RFC 8571), pm-source-owamp (RFC 4656), pm-source-twamp (RFC 5357), pm-source-stamp (RFC 8762), pm-source-y-1731 (ITU-T Y.1731), and pm-source-ioam (RFC 9197).
The termination-point augmentation adds a 'pm-statistics' container (config false) with inbound/outbound counters (octets, unicast, broadcast, multicast, discards, errors, unknown-protocol) and a 'vpn-network-access' list for per-VPN-access finer-grained metrics.
The 'vpn-pm-type' container on links (augmented when 'service' container is present) supports two VPN measurement methods: 'inter-vpn-access-interface' PM (logical PE-PE connections between VPN access interfaces) and 'vpn-tunnel' PM (e.g., GRE or Geneve tunnels). Only one method is typically used since inter-VPN-access includes PE-PE monitoring.
IANA registered the URI 'urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm' in the 'ns' subregistry of the IETF XML Registry (RFC 3688), and registered the YANG module 'ietf-network-vpn-pm' with prefix 'nvp' in the 'YANG Module Names' subregistry of the YANG Parameters registry (RFC 6020).
The YANG module must be accessed via NETCONF over SSH (mandatory-to-implement, RFC 6242) or RESTCONF over HTTPS/TLS 1.3 (mandatory-to-implement, RFC 8446). Access control must be enforced using NACM (RFC 8341) to restrict read and write access to sensitive PM data nodes.
Unauthorized read access to the node subtree, link PM statistics subtree, and termination-point PM statistics subtree can disclose operational state of underlay network instances, VPN instances, links, and VPN access interfaces. A trade-off between confidentiality and monitoring visibility must be considered.
Unauthorized write access to configurable PM data nodes (service-type, VPN identifier, VPN topology, node-type, VPN topology role, percentile settings, measurement interval, vpn-pm-type) can disable VPN PM, render data unusable, or degrade monitoring fidelity. These nodes require proper access control protection.