draft-ietf-opsawg-yang-vpn-service-pm-04.txt   draft-ietf-opsawg-yang-vpn-service-pm-05.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: 22 September 2022 M. Boucadair, Ed. Expires: 10 October 2022 M. Boucadair, Ed.
Orange Orange
O. Gonzalez de Dios O. Gonzalez de Dios
Telefonica Telefonica
B. Wen B. Wen
Comcast Comcast
21 March 2022 8 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-04 draft-ietf-opsawg-yang-vpn-service-pm-05
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 22 September 2022. This Internet-Draft will expire on 10 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 29 skipping to change at page 2, line 29
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 . . . . . . . . . . . . . . . . . . . . . . . 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 . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.1. Normative References . . . . . . . . . . . . . . . . . . 30 10.1. Normative References . . . . . . . . . . . . . . . . . . 31
10.2. Informative References . . . . . . . . . . . . . . . . . 32 10.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Illustrating Examples . . . . . . . . . . . . . . . 34 Appendix A. Illustrating Examples . . . . . . . . . . . . . . . 35
A.1. VPN Performance Subscription Example . . . . . . . . . . 34 A.1. VPN Performance Subscription Example . . . . . . . . . . 35
A.2. Example of VPN Performance Snapshot . . . . . . . . . . . 35 A.2. Example of VPN Performance Snapshot . . . . . . . . . . . 36
A.3. Example of Percentile Monitoring . . . . . . . . . . . . 37 A.3. Example of Percentile Monitoring . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 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 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 Agreement (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
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
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 8 skipping to change at page 5, line 8
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 information from [RFC8345], [I-D.ietf-opsawg-sap]
or VPN instances. Then the controller derive network or VPN level or VPN instances. Then the controller derives network or VPN level
performance data by aggregating (and filtering) lower-level data performance data by aggregating (and filtering) lower-level data
collected via monitoring counters of the involved devices. 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
skipping to change at page 5, line 43 skipping to change at page 5, line 43
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 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. they are interested in, at the data source. For example, network or
VPN topology updates may be obtained through on-change notifications
[RFC8641]. For dynamic-changing PM data, various notifications can
be specified to obtain more complete data. A periodic notification
[RFC8641] can be specified to obtain real-time performance data, a
replay notification defined in [RFC5277] or [RFC8639] can be
specified to obtain historical data, or alarm notifications [RFC8632]
can be specified to get alarms for the metrics which exceed or fall
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.
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
skipping to change at page 9, line 42 skipping to change at page 9, line 42
4.3. Node Level 4.3. Node Level
The tree in Figure 6 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
container includes the following attributes: container includes the following attributes:
"node-type": Indicates the device type of Provider Edge (PE), "node-type": Indicates the device type of Provider Edge (PE),
Provider (P) device, or Autonomous System Border Router (ASBR), so Provider (P) device, or Autonomous System Border Router (ASBR) as
that the performance metric between any two nodes each with defined in [RFC4026] and [RFC4364], so that the performance metric
specific node type can be reported. between any two nodes each with specific node type can be
reported.
"entry-summary": Lists a set of IPv4 statistics, IPv6 statistics, "entry-summary": Lists a set of IPv4 statistics, IPv6 statistics,
and MAC statistics. The detailed statistics are specified and MAC statistics. The detailed statistics are specified
separately. separately.
For VPN service performance monitoring, the model defines one For VPN service performance monitoring, the model defines one
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,
skipping to change at page 11, line 11 skipping to change at page 11, line 14
| | +--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:gauge64
| +--ro max-jitter-value? yang:gauge32 | +--ro max-jitter-value? yang:gauge64
| +--ro low-jitter-percentile? yang:gauge32 | +--ro low-jitter-percentile? yang:gauge64
| +--ro intermediate-jitter-percentile? yang:gauge32 | +--ro intermediate-jitter-percentile? yang:gauge64
| +--ro high-jitter-percentile? yang:gauge32 | +--ro high-jitter-percentile? yang:gauge64
+--ro one-way-pm-statistics-per-class* [class-id] +--ro one-way-pm-statistics-per-class* [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:gauge64
| +--ro max-jitter-value? yang:gauge32 | +--ro max-jitter-value? yang:gauge64
| +--ro low-jitter-percentile? yang:gauge32 | +--ro low-jitter-percentile? yang:gauge64
| +--ro intermediate-jitter-percentile? yang:gauge32 | +--ro intermediate-jitter-percentile? yang:gauge64
| +--ro high-jitter-percentile? yang:gauge32 | +--ro high-jitter-percentile? yang:gauge64
+--rw (vpn-pm-type)? +--rw (vpn-pm-type)?
+--:(inter-vpn-access-interface) +--:(inter-vpn-access-interface)
| +--rw inter-vpn-access-interface? empty | +--rw inter-vpn-access-interface? empty
+--:(underlay-tunnel) +--:(underlay-tunnel)
+--ro vpn-underlay-transport-type? identityref +--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
skipping to change at page 14, line 32 skipping to change at page 14, line 44
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@2021-03-21.yang" <CODE BEGINS> file "ietf-network-vpn-pm@2021-04-08.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 12 skipping to change at page 16, line 24
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-03-21 { revision 2022-04-08 {
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 19, line 36 skipping to change at page 19, line 46
"MAC statistics."; "MAC statistics.";
} }
} }
} }
grouping link-loss-statistics { grouping link-loss-statistics {
description description
"Grouping for per link error statistics."; "Grouping for per link error statistics.";
container loss-statistics { container loss-statistics {
description description
"Link loss summarized information. By default, "One-way link loss summarized information.";
one way measurement protocol (e.g., OWAMP) is used
to measure one-way packet loss.";
reference reference
"RFC 4656: A One-way Active Measurement Protocol (OWAMP)"; "RFC 4656: A One-way Active Measurement Protocol (OWAMP)
ITU-T Y.1731: Operations, administration and
maintenance (OAM) functions and mechanisms
for Ethernet-based networks";
leaf packet-loss-count { leaf packet-loss-count {
type yang:counter64; type yang:counter64;
description description
"Total received packet drops count."; "Total received packet drops count.";
} }
leaf loss-ratio { leaf loss-ratio {
type percentage; type percentage;
description description
"Loss ratio of the packets. Express as percentage "Loss ratio of the packets. Express as percentage
of packets lost with respect to packets sent."; of packets lost with respect to packets sent.";
skipping to change at page 20, line 4 skipping to change at page 20, line 17
description description
"Total received packet drops count."; "Total received packet drops count.";
} }
leaf loss-ratio { leaf loss-ratio {
type percentage; type percentage;
description description
"Loss ratio of the packets. Express as percentage "Loss ratio of the packets. Express as percentage
of packets lost with respect to packets sent."; of packets lost with respect to packets sent.";
} }
} }
} }
grouping link-delay-statistics { grouping link-delay-statistics {
description description
"Grouping for per link delay statistics."; "Grouping for per link delay statistics.";
container delay-statistics { container delay-statistics {
description description
"Link delay summarized information. By default, "One-way link delay summarized information.";
one way measurement protocol (e.g., OWAMP) is used
to measure delay.";
reference reference
"RFC 4656: A One-way Active Measurement Protocol (OWAMP)"; "RFC 4656: A One-way Active Measurement Protocol (OWAMP)
ITU-T Y.1731: Operations, administration and
maintenance (OAM) functions and mechanisms
for Ethernet-based networks";
leaf unit-value { leaf unit-value {
type identityref { type identityref {
base lime:time-unit-type; base lime:time-unit-type;
} }
default "lime:milliseconds"; default "lime:milliseconds";
description description
"Time units, where the options are s, ms, ns, etc."; "Time units, where the options are s, ms, ns, etc.";
} }
leaf min-delay-value { leaf min-delay-value {
type yang:gauge64; type yang:gauge64;
skipping to change at page 21, line 4 skipping to change at page 21, line 18
description description
"Intermediate percentile of observed one-way delay with "Intermediate percentile of observed one-way delay with
specific measurement method."; specific measurement method.";
} }
leaf high-delay-percentile { leaf high-delay-percentile {
type yang:gauge64; type yang:gauge64;
description description
"High percentile of observed one-way delay with "High percentile of observed one-way delay with
specific measurement method."; specific measurement method.";
} }
} }
} }
grouping link-jitter-statistics { grouping link-jitter-statistics {
description description
"Grouping for per link jitter statistics."; "Grouping for per link jitter statistics.";
container jitter-statistics { container jitter-statistics {
description description
"Link jitter summarized information. By default, "One-way link jitter summarized information.";
jitter is measured using one-way IP Packet
Delay Variation (IPDV).";
reference reference
"RFC 3393: IP Packet Delay Variation Metric "RFC 3393: IP Packet Delay Variation Metric
for IP Performance Metrics (IPPM)"; for IP Performance Metrics (IPPM)
RFC 4656: A One-way Active Measurement Protocol (OWAMP)
ITU-T Y.1731: Operations, administration and
maintenance (OAM) functions and mechanisms
for Ethernet-based networks";
leaf unit-value { leaf unit-value {
type identityref { type identityref {
base lime:time-unit-type; base lime:time-unit-type;
} }
default "lime:milliseconds"; default "lime:milliseconds";
description description
"Time units, where the options are s, ms, ns, etc."; "Time units, where the options are s, ms, ns, etc.";
} }
leaf min-jitter-value { leaf min-jitter-value {
type yang:gauge32; type yang:gauge64;
description description
"Minimum observed one-way jitter."; "Minimum observed one-way jitter.";
} }
leaf max-jitter-value { leaf max-jitter-value {
type yang:gauge32; type yang:gauge64;
description description
"Maximum observed one-way jitter."; "Maximum observed one-way jitter.";
} }
leaf low-jitter-percentile { leaf low-jitter-percentile {
type yang:gauge32; type yang:gauge64;
description description
"Low percentile of observed one-way jitter."; "Low percentile of observed one-way jitter.";
} }
leaf intermediate-jitter-percentile { leaf intermediate-jitter-percentile {
type yang:gauge32; type yang:gauge64;
description description
"Intermediate percentile of observed one-way jitter."; "Intermediate percentile of observed one-way jitter.";
} }
leaf high-jitter-percentile { leaf high-jitter-percentile {
type yang:gauge32; type yang:gauge64;
description description
"High percentile of observed one-way jitter."; "High percentile of observed one-way jitter.";
} }
} }
} }
grouping tp-svc-telemetry { grouping tp-svc-telemetry {
leaf reference-time { leaf reference-time {
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 {
skipping to change at page 22, line 36 skipping to change at page 22, line 50
type yang:counter64; type yang:counter64;
description description
"The total number of inbound 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:counter64; 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 Possible reasons for discarding such a packet could
packet could be to free up buffer space"; be to free up buffer space, not enough buffer for
too much data, etc.";
} }
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.";
} }
leaf inbound-unknown-protocol { leaf inbound-unknown-protocol {
type yang:counter64; type yang:counter64;
description description
"The number of packets received via the interface "The number of packets received via the interface
skipping to change at page 23, line 25 skipping to change at page 23, line 41
description description
"The total number of outbound non unicast "The total number of outbound non unicast
(i.e., broadcast or multicast) packets."; (i.e., broadcast or multicast) packets.";
} }
leaf outbound-discards { leaf outbound-discards {
type yang:counter64; type yang:counter64;
description description
"The number of outbound packets which were chosen "The number of outbound packets which were chosen
to be discarded even though no errors had been to be discarded even though no errors had been
detected to prevent their being transmitted. detected to prevent their being transmitted.
One possible reason for discarding such a packet could Possible reasons for discarding such a packet could
be to free up buffer space."; be to free up buffer space, not enough buffer for
too much data, etc.";
} }
leaf outbound-errors { leaf outbound-errors {
type yang:counter64; type yang:counter64;
description description
"The number of outbound packets that contained "The number of outbound packets that contained
errors."; errors.";
} }
description description
"Grouping for interface service telemetry."; "Grouping for interface service telemetry.";
} }
skipping to change at page 30, line 46 skipping to change at page 31, line 25
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
[ITU-T-Y-1731]
ITU-T, "Operator Ethernet Service Definition", August
2015, <https://www.itu.int/rec/T-REC-Y.1731/en>.
[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>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
<https://www.rfc-editor.org/info/rfc4656>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, DOI 10.17487/RFC5357, October 2008,
<https://www.rfc-editor.org/info/rfc5357>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
skipping to change at page 32, line 42 skipping to change at page 33, line 35
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-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-02, 22 February 2022, opsawg-sap-03, 21 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-opsawg-sap- <https://www.ietf.org/archive/id/draft-ietf-opsawg-sap-
02.txt>. 03.txt>.
[ITU-T-Y-1731] [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
ITU-T, "Operator Ethernet Service Definition", August Private Network (VPN) Terminology", RFC 4026,
2015, <https://www.itu.int/rec/T-REC-Y.1731/en>. DOI 10.17487/RFC4026, March 2005,
<https://www.rfc-editor.org/info/rfc4026>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Zekauskas, "A One-way Active Measurement Protocol Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 2006, <https://www.rfc-editor.org/info/rfc4364>.
<https://www.rfc-editor.org/info/rfc4656>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008,
RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5277>.
<https://www.rfc-editor.org/info/rfc5357>.
[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
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
skipping to change at page 33, line 43 skipping to change at page 34, line 33
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 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and
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>.
[RFC8632] Vallin, S. and M. Bjorklund, "A YANG Data Model for Alarm
Management", RFC 8632, DOI 10.17487/RFC8632, September
2019, <https://www.rfc-editor.org/info/rfc8632>.
[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
E., and A. Tripathy, "Subscription to YANG Notifications",
RFC 8639, DOI 10.17487/RFC8639, September 2019,
<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>.
 End of changes. 38 change blocks. 
68 lines changed or deleted 104 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/