--- 1/draft-ietf-opsawg-yang-vpn-service-pm-07.txt 2022-05-05 05:13:13.239494435 -0700 +++ 2/draft-ietf-opsawg-yang-vpn-service-pm-08.txt 2022-05-05 05:13:13.311496231 -0700 @@ -1,24 +1,24 @@ OPSAWG Working Group B. Wu, Ed. Internet-Draft Q. Wu, Ed. Intended status: Standards Track Huawei -Expires: 27 October 2022 M. Boucadair, Ed. +Expires: 6 November 2022 M. Boucadair, Ed. Orange O. Gonzalez de Dios Telefonica B. Wen Comcast - 25 April 2022 + 5 May 2022 A YANG Model for Network and VPN Service Performance Monitoring - draft-ietf-opsawg-yang-vpn-service-pm-07 + draft-ietf-opsawg-yang-vpn-service-pm-08 Abstract The data model for network topologies defined in RFC 8345 introduces vertical layering relationships between networks that can be augmented to cover network and service topologies. This document defines a YANG module for performance monitoring (PM) of both networks and VPN services that can be used to monitor and manage network performance on the topology at higher layer or the service topology between VPN sites. @@ -31,21 +31,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 27 October 2022. + This Internet-Draft will expire on 6 November 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -61,33 +61,33 @@ 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Network and VPN Service Performance Monitoring Model Usage . 4 3.1. Collecting Data via Pub/Sub Mechanism . . . . . . . . . . 5 3.2. Collecting Data On-demand . . . . . . . . . . . . . . . . 6 4. Description of The Data Model . . . . . . . . . . . . . . . . 6 4.1. Layering Relationship between Multiple Layers of Topology . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Network Level . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Node Level . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Link and Termination Point Level . . . . . . . . . . . . 10 - 5. Network and VPN Service Performance Monitoring YANG Module . 15 + 5. Network and VPN Service Performance Monitoring YANG Module . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 10.1. Normative References . . . . . . . . . . . . . . . . . . 31 - 10.2. Informative References . . . . . . . . . . . . . . . . . 33 + 10.2. Informative References . . . . . . . . . . . . . . . . . 34 Appendix A. Illustrative Examples . . . . . . . . . . . . . . . 35 A.1. VPN Performance Subscription Example . . . . . . . . . . 35 - A.2. Example of VPN Performance Snapshot . . . . . . . . . . . 36 - A.3. Example of Percentile Monitoring . . . . . . . . . . . . 38 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 + A.2. Example of VPN Performance Snapshot . . . . . . . . . . . 37 + A.3. Example of Percentile Monitoring . . . . . . . . . . . . 39 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 1. Introduction [RFC8969] describes a framework for automating service and network management with YANG [RFC6020] models. It defines that the performance measurement telemetry model should be tied to the services (such as a Layer 3 VPN or Layer 2 VPN) or to the network models to monitor the overall network performance and the Service Level Agreements (SLAs). @@ -197,21 +197,22 @@ [I-D.ietf-opsawg-sap] or VPN information from [RFC9182], [I-D.ietf-opsawg-l2nm]. Then the controller derives network or VPN level performance data by aggregating (and filtering) lower-level data collected via monitoring counters of the involved devices. The network or VPN performance data can be based on different sources. For example, the performance monitoring data per link in the underlying network can be collected using a network performance measurement method such as One-Way Active Measurement Protocol (OWAMP) [RFC4656], Two-Way Active Measurement Protocol (TWAMP) - [RFC5357], and Multiprotocol Label Switching (MPLS) Loss and Delay + [RFC5357], Simple Two-way Active Measurement Protocol(STAMP) + [RFC8762], and Multiprotocol Label Switching (MPLS) Loss and Delay Measurement [RFC6374]. The performance monitoring information reflecting the quality of the network or VPN service (e.g., end-to- end network performance data between source node and destination node in the network or between VPN sites) can be computed and aggregated, for example, using the information from the Traffic Engineering Database (TED), [RFC7471] [RFC8570] [RFC8571] or LMAP [RFC8194]. The measurement and report intervals that are associated with these performance data usually depend on the configuration of the specific measurement method or collection method or various combinations. @@ -504,24 +504,24 @@ | | +--ro low-delay-percentile? yang:gauge64 | | +--ro intermediate-delay-percentile? yang:gauge64 | | +--ro high-delay-percentile? yang:gauge64 | +--ro jitter-statistics | +--ro unit-value? identityref | +--ro min-jitter-value? yang:gauge64 | +--ro max-jitter-value? yang:gauge64 | +--ro low-jitter-percentile? yang:gauge64 | +--ro intermediate-jitter-percentile? yang:gauge64 | +--ro high-jitter-percentile? yang:gauge64 - +--rw (vpn-pm-type)? - +--:(inter-vpn-access-interface) + +--rw vpn-pm-type + +--rw inter-vpn-access-interface | +--rw inter-vpn-access-interface? empty - +--:(underlay-tunnel) + +--rw underlay-tunnel! +--ro vpn-underlay-transport-type? identityref augment /nw:networks/nw:network/nw:node/nt:termination-point: +--ro pm-statistics +--ro reference-time? yang:date-and-time +--ro inbound-octets? yang:counter64 +--ro inbound-unicast? yang:counter64 +--ro inbound-nunicast? yang:counter64 +--ro inbound-discards? yang:counter64 +--ro inbound-errors? yang:counter64 +--ro inbound-unknown-protocol? yang:counter64 @@ -608,30 +608,29 @@ 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 + logical point-to-point VPN 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. The inter-VPN-access-interface PM - is defined as an empty leaf, which is not bound to a specific VPN - access interface. The source or destination VPN access interface - of the measurement can be augmented as needed. + Therefore, usually only one of the two methods is used. The + inter-VPN-access-interface PM is defined as an empty leaf, which + is not bound to a specific VPN access interface. The source or + destination VPN access interface of the measurement can be + augmented as needed. VPN underlay transport type ("vpn-underlay-transport-type"): Indicat 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" defined in [RFC9181], which describes the transport technology to carry the traffic of the VPN service. For the data nodes of 'termination-point' depicted in Figure 7, the module defines the following minimal set of statistics: @@ -648,21 +647,21 @@ network access defined in [RFC9182] or [I-D.ietf-opsawg-l2nm]. When multiple VPN network accesses are created using the same physical port, finer-grained metrics can be monitored. If a TP is associated with only a single VPN, this list is not required. 5. Network and VPN Service Performance Monitoring YANG Module The "ietf-network-vpn-pm" module uses types defined in [RFC8345], [RFC6991], [RFC8532], and [RFC9181]. - file "ietf-network-vpn-pm@2022-04-25.yang" + file "ietf-network-vpn-pm@2022-05-05.yang" module ietf-network-vpn-pm { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm"; prefix nvp; import ietf-yang-types { prefix yang; reference "RFC 6991: Common YANG Types"; } @@ -723,49 +723,46 @@ This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices."; // RFC Ed.: update the date below with the date of RFC // publication and remove this note. // RFC Ed.: replace XXXX with actual RFC number and remove // this note. - revision 2022-04-25 { + revision 2022-05-05 { description "Initial revision."; reference "RFC XXXX: A YANG Model for Network and VPN Service Performance Monitoring"; } identity node-type { description "Base identity for node type"; } identity pe { base node-type; description - "Provider Edge (PE) node type."; - reference - "RFC 4026: Provider Provisioned - Virtual Private Network (VPN) Terminology"; + "Provider Edge (PE) node type. A PE is the name of the device + or set of devices at the edge of the provider network with the + functionality that is needed to interface with the customer."; } - identity p { base node-type; description - "Provider router node type."; - reference - "RFC 4026: Provider Provisioned - Virtual Private Network (VPN) Terminology"; + "Provider router node type. That is, a router + in the core network that does not have interfaces + directly toward a customer."; } identity asbr { base node-type; description "Autonomous System Border Router (ASBR) node type."; reference "RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs)"; } @@ -785,28 +782,37 @@ } identity pm-source-owamp { base pm-source-type; description "Indicates One-Way Active Measurement Protocol(OWAMP) as the performance monitoring metric source."; reference "RFC 4656: A One-Way Active Measurement Protocol (OWAMP)"; } + identity pm-source-twamp { base pm-source-type; description "Indicates Two-Way Active Measurement Protocol(TWAMP) as the performance monitoring metric source."; reference "RFC 5357: A Two-Way Active Measurement Protocol (TWAMP)"; } + identity pm-source-stamp { + base pm-source-type; + description + "Indicates Simple Two-way Active Measurement Protocol(STAMP) + as the performance monitoring metric source."; + reference + "RFC 8762: Simple Two-Way Active Measurement Protocol"; + } identity pm-source-y-1731 { base pm-source-type; description "Indicates Ethernet OAM Y.1731 as the performance monitoring metric source."; reference "ITU-T Y.1731: Operations, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks"; @@ -1265,35 +1271,44 @@ } augment "/nw:networks/nw:network/nt:link/pm-attributes" { when '../../nw:network-types/nvp:service-type' { description "Augments only for VPN Network topology."; } description "Augments the network topology link with VPN service performance monitoring attributes."; - choice vpn-pm-type { + container vpn-pm-type { description "The VPN PM type of this logical point-to-point unidirectional VPN link."; - case inter-vpn-access-interface { + container inter-vpn-access-interface { + description + "Indicates inter-vpn-access-interface PM, which is to + monitor the performance of logical point-to-point VPN + connections between a source and a destination + VPN access interfaces."; leaf inter-vpn-access-interface { type empty; description "This is a placeholder for inter-vpn-access-interface PM, which is not bound to a specific VPN access interface. The source or destination VPN access interface of the measurement can be augmented as needed."; } } - case underlay-tunnel { + container underlay-tunnel { + presence "Enables VPN underlay tunnel PM"; + description + "Indicates underlay-tunnel PM, which is to monitor + the performance of underlay tunnels of VPNs."; 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."; } } @@ -1332,59 +1348,64 @@ access, e.g. L3VPN or VPLS."; } uses tp-svc-telemetry; } } } 6. Security Considerations - The YANG modules defined in this document MAY be accessed via the - RESTCONF protocol [RFC8040] or NETCONF protocol [RFC6241]. The - lowest RESTCONF or NETCONF layer requires that the transport-layer - protocol provides both data integrity and confidentiality, see - Section 2 in [RFC8040] and [RFC6241]. The lowest NETCONF layer is - the secure transport layer, and the mandatory-to-implement secure + The YANG module specified in this document defines a schema for data + that is designed to be accessed via network management protocols such + as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer + is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. - The NETCONF access control model [RFC8341] provides the means to - restrict access for particular NETCONF or RESTCONF users to a - preconfigured subset of all available NETCONF or RESTCONF protocol - operations and content. + The Network Configuration Access Control Model (NACM) [RFC8341] + provides the means to restrict access for particular NETCONF or + RESTCONF users to a preconfigured subset of all available NETCONF or + RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative - effect on network operations. These are the subtrees with the write - operation that can be exploited to impact the network monitoring: + effect on network operations. These are the subtrees and data nodes + and their sensitivity/vulnerability: - * "/nw:networks/nw:network/nw:network-types" + * "/nw:networks/nw:network/nw:network-types": This subtree specifies + the VPN service type. Unauthorized access to this subtree may + render the VPN service type invalid. - * "/nw:networks/nw:network/nvp:vpn-pm-attributes" + * "/nw:networks/nw:network/nvp:vpn-pm-attributes": This subtree + specifies the VPN service identifier and VPN service topology. + Unauthorized access to this subtree may disable the the VPN PM or + render the VPN service topology invalid. - * "/nw:networks/nw:network/nw:node/nvp:pm-attributes" + * "/nw:networks/nw:network/nw:node/nvp:pm-attributes": This subtree + specifies the network node type and VPN service topology role. + Unauthorized access to this subtree may render the node type or + VPN service topology invalid. - * /nw:networks/nw:network/nt:link/nvp:pm-attributes" - * /nw:networks/nw:network/nw:node/nt:termination-point/nvp:pm- - statistics" + * /nw:networks/nw:network/nt:link/nvp:pm-attributes": This subtree + specifies the PM of the network link and VPN link. Unauthorized + access to this subtree can impact the network and VPN monitoring. Some of the readable data nodes in this YANG module may be considered - sensitive or vulnerable in some network environments. The nodes - 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, - or notification) to these data nodes. These are the subtrees and - data nodes and their sensitivity/vulnerability: + sensitive or vulnerable in some network environments. It is thus + important to control read access (e.g., via get, get-config, or + notification) to these data nodes. These are the subtrees and data + nodes and their sensitivity/vulnerability: * "/nw:networks/nw:network/nw:node/nvp:pm-attributes/nvp:vpn- summary-statistics": Unauthorized access to this subtree can disclose the operational state information of VPN instances. * "/nw:networks/nw:network/nt:link/nvp:pm-attributes/nvp:one-way-pm- statistics": Unauthorized access to this subtree can disclose the operational state information of network links or VPN abstract links. @@ -1430,44 +1451,39 @@ Roni Even Huawei Email: ron.even.tlv@gmail.com Change Liu China Unicom Email: liuc131@chinaunicom.cn Honglei Xu China Telecom - Email: xuhl.bri@chinatelecom.cn + Email: xuhl6@chinatelecom.cn 10. References 10.1. Normative References [ITU-T-Y-1731] ITU-T, "Operator Ethernet Service Definition", August 2015, . [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI 10.17487/RFC3393, November 2002, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . - [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual - Private Network (VPN) Terminology", RFC 4026, - DOI 10.17487/RFC4026, March 2005, - . - [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [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, . [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. @@ -1495,20 +1511,24 @@ . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . + [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF + Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, + . + [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., @@ -1530,63 +1550,68 @@ [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions", RFC 8571, DOI 10.17487/RFC8571, March 2019, . [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, September 2019, . + [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple + Two-Way Active Measurement Protocol", RFC 8762, + DOI 10.17487/RFC8762, March 2020, + . + [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, . 10.2. Informative References [I-D.ietf-netmod-node-tags] Wu, Q., Claise, B., Liu, P., Du, Z., and M. Boucadair, - "Self-Describing Data Object Tags in YANG Data Models", - Work in Progress, Internet-Draft, draft-ietf-netmod-node- - tags-06, 21 February 2022, - . + "Data Node Tags in YANG Modules", Work in Progress, + Internet-Draft, draft-ietf-netmod-node-tags-07, 29 April + 2022, . [I-D.ietf-opsawg-l2nm] Boucadair, M., Dios, O. G. D., Barguil, S., and L. A. Munoz, "A YANG Network Data Model for Layer 2 VPNs", Work - in Progress, Internet-Draft, draft-ietf-opsawg-l2nm-13, 14 + in Progress, Internet-Draft, draft-ietf-opsawg-l2nm-15, 29 April 2022, . + opsawg-l2nm-15.txt>. [I-D.ietf-opsawg-sap] Boucadair, M., Dios, O. G. D., Barguil, S., Wu, Q., and V. Lopez, "A Network YANG Model for Service Attachment Points (SAPs)", Work in Progress, Internet-Draft, draft-ietf- opsawg-sap-04, 11 April 2022, . + [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual + Private Network (VPN) Terminology", RFC 4026, + DOI 10.17487/RFC4026, March 2005, + . + [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, . [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, . - [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF - Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, - . - [RFC8194] Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for LMAP Measurement Agents", RFC 8194, DOI 10.17487/RFC8194, August 2017, . [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, . [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) @@ -1757,23 +1783,25 @@ "one-way-pm-statistics": { "delay-statistics": { "unit-value": "lime:milliseconds", "min-delay-value": "43", "max-delay-value": "99", "low-delay-percentile": "64", "intermediate-delay-percentile": "77", "high-delay-percentile": "98" } }, + "vpn-pm-type": { "inter-vpn-access-interface": [null] } } + } ] } Authors' Addresses Bo Wu (editor) Huawei 101 Software Avenue, Yuhua District Nanjing Jiangsu, 210012