idnits 2.17.1 draft-ietf-opsawg-yang-vpn-service-pm-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1333: '...in this document MAY be accessed via t...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (8 April 2022) is 720 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'N5' is mentioned on line 300, but not defined == Missing Reference: 'CE2' is mentioned on line 304, but not defined == Missing Reference: 'N4' is mentioned on line 304, but not defined == Missing Reference: 'N3' is mentioned on line 304, but not defined == Missing Reference: 'CE4' is mentioned on line 304, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-T-Y-1731' == Outdated reference: A later version (-11) exists of draft-ietf-netmod-node-tags-06 == Outdated reference: A later version (-19) exists of draft-ietf-opsawg-l2nm-12 == Outdated reference: A later version (-15) exists of draft-ietf-opsawg-sap-03 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG Working Group B. Wu, Ed. 3 Internet-Draft Q. Wu, Ed. 4 Intended status: Standards Track Huawei 5 Expires: 10 October 2022 M. Boucadair, Ed. 6 Orange 7 O. Gonzalez de Dios 8 Telefonica 9 B. Wen 10 Comcast 11 8 April 2022 13 A YANG Model for Network and VPN Service Performance Monitoring 14 draft-ietf-opsawg-yang-vpn-service-pm-05 16 Abstract 18 The data model for network topologies defined in RFC 8345 introduces 19 vertical layering relationships between networks that can be 20 augmented to cover network and service topologies. This document 21 defines a YANG module for performance monitoring (PM) of both 22 networks and VPN services that can be used to monitor and manage 23 network performance on the topology at higher layer or the service 24 topology between VPN sites. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 10 October 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Network and VPN Service Performance Monitoring Model Usage . 4 63 3.1. Collecting Data via Pub/Sub Mechanism . . . . . . . . . . 5 64 3.2. Collecting Data On-demand . . . . . . . . . . . . . . . . 6 65 4. Description of The Data Model . . . . . . . . . . . . . . . . 6 66 4.1. Layering Relationship between Multiple Layers of 67 Topology . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.2. Network Level . . . . . . . . . . . . . . . . . . . . . . 8 69 4.3. Node Level . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.4. Link and Termination Point Level . . . . . . . . . . . . 10 71 5. Network and VPN Service Performance Monitoring YANG Module . 14 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 75 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 31 78 10.2. Informative References . . . . . . . . . . . . . . . . . 33 79 Appendix A. Illustrating Examples . . . . . . . . . . . . . . . 35 80 A.1. VPN Performance Subscription Example . . . . . . . . . . 35 81 A.2. Example of VPN Performance Snapshot . . . . . . . . . . . 36 82 A.3. Example of Percentile Monitoring . . . . . . . . . . . . 38 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 85 1. Introduction 87 [RFC8969] describes a framework for automating service and network 88 management with YANG models. It defines that the performance 89 measurement telemetry model to be tied with the service, such as 90 Layer 3 VPN and Layer 2 VPN, or network models to monitor the overall 91 network performance or Service Level Agreement (SLA). 93 The performance of VPN services is associated with the performance 94 changes of the underlay network that carries VPN services, such as 95 the delay of the underlay tunnels and the packet loss status of the 96 device interfaces. Additionally, the integration of Layer 2/Layer 3 97 VPN performance and network performance data enables the orchestrator 98 to subscribe to VPN service performance in a unified manner. 99 Therefore, this document defines a YANG module for both network and 100 VPN service performance monitoring (PM). The module can be used to 101 monitor and manage network performance on the topology level or the 102 service topology between VPN sites, in particular. 104 This document does not introduce new metrics for network performance 105 or mechanisms for measuring network performance, but uses the 106 existing mechanisms and statistics to display the performance 107 monitoring statistics at the network and service layers. All these 108 metrics are defined as unidirectional metrics. 110 The YANG module defined in this document is designed as an 111 augmentation to the network topology YANG model defined in [RFC8345] 112 and draws on relevant YANG types defined in [RFC6991], [RFC8345], 113 [RFC8532], and [RFC9181]. 115 Appendix A provides a set of examples to illustrate the use of the 116 module. 118 2. Terminology 120 The following terms are defined in [RFC7950] and are used in this 121 specification: 123 * augment 125 * data model 127 * data node 129 The terminology for describing YANG data models is found in 130 [RFC7950]. 132 The tree diagrams used in this document follow the notation defined 133 in [RFC8340]. 135 2.1. Acronyms 137 The following acronyms are used in the document: 139 L2VPN Layer 2 Virtual Private Network 140 L3VPN Layer 3 Virtual Private Network 141 L2NM L2VPN Network Model 142 L3NM L3VPN Network Model 143 MPLS Multiprotocol Label Switching 144 OAM Operations, Administration, and Maintenance 145 OWAMP One-Way Active Measurement Protocol 146 PE Provider Edge 147 PM Performance Monitoring 148 SLA Service Level Agreements 149 TWAMP Two-Way Active Measurement Protocol 150 VPLS Virtual Private LAN Service 151 VPN Virtual Private Network 153 3. Network and VPN Service Performance Monitoring Model Usage 155 Models are key for automating network management operations. 156 According to [RFC8969], together with service and network models, 157 performance measurement telemetry models are needed to monitor 158 network performance to meet specific service requirements (typically 159 captured in an SLA). 161 +---------------+ 162 | Customer | 163 +-------+-------+ 164 | 165 Customer Service Models | 166 | 167 +-------+---------+ 168 | Service | 169 | Orchestration | 170 +------+-+--------+ 171 | | 172 Network Service Models | | Network and VPN Service PM Models 173 | | 174 +------+-+--------+ 175 | Network | 176 | Controller | 177 +-------+---------+ 178 | 179 +-----------------------+------------------------+ 180 Network 182 Figure 1: Reference Architecture 184 As shown in Figure 1, in the context of the layering model 185 architecture described in [RFC8309], the network and VPN service 186 performance monitoring (PM) model can be used to expose a set of 187 performance information to the above layer. Such information can be 188 used by an orchestrator to subscribe to performance data. The 189 network controller will then notify the orchestrator about 190 corresponding parameter changes. 192 Before using the model, the controller needs to establish complete 193 topology visibility of the network and VPN. For example, the 194 controller can use information from [RFC8345], [I-D.ietf-opsawg-sap] 195 or VPN instances. Then the controller derives network or VPN level 196 performance data by aggregating (and filtering) lower-level data 197 collected via monitoring counters of the involved devices. 199 The network or VPN performance data can be based on different 200 sources. For example, the performance monitoring data per link in 201 the underlying network can be collected using a network performance 202 measurement method such as One-Way Active Measurement Protocol 203 (OWAMP) [RFC4656], Two-Way Active Measurement Protocol (TWAMP) 204 [RFC5357], and Multiprotocol Label Switching (MPLS) Loss and Delay 205 Measurement [RFC6374]. The performance monitoring information 206 reflecting the quality of the network or VPN service (e.g., end-to- 207 end network performance data between source node and destination node 208 in the network or between VPN sites) can be computed and aggregated, 209 for example, using the information from the Traffic Engineering 210 Database (TED), [RFC7471] [RFC8570] [RFC8571] or LMAP [RFC8194]. 212 The measurement and report intervals that are associated with these 213 performance data usually depend on the configuration of the specific 214 measurement method or collection method or various combinations. 215 This document defines a network-wide measurement interval to align 216 measurement requirements for networks or VPN services. 218 In addition, the amount of performance data collected from the 219 devices can be huge. To avoid receiving a large amount of 220 operational data of VPN instances, VPN interfaces, or tunnels, the 221 network controller can specifically subscribe to metric-specific data 222 using the tagging methods defined in [I-D.ietf-netmod-node-tags]. 224 3.1. Collecting Data via Pub/Sub Mechanism 226 Some applications such as service-assurance applications, which must 227 maintain a continuous view of operational data and state, can use the 228 subscription model specified in [RFC8641] to subscribe to the 229 specific network performance data or VPN service performance data 230 they are interested in, at the data source. For example, network or 231 VPN topology updates may be obtained through on-change notifications 232 [RFC8641]. For dynamic-changing PM data, various notifications can 233 be specified to obtain more complete data. A periodic notification 234 [RFC8641] can be specified to obtain real-time performance data, a 235 replay notification defined in [RFC5277] or [RFC8639] can be 236 specified to obtain historical data, or alarm notifications [RFC8632] 237 can be specified to get alarms for the metrics which exceed or fall 238 below the performance threshold. 240 The data source can, then, use the network and VPN service assurance 241 model defined in this document and the YANG Push model [RFC8641] to 242 distribute specific telemetry data to target recipients. 244 3.2. Collecting Data On-demand 246 To obtain a snapshot of a large amount of performance data from a 247 network topology or VPN network, service-assurance applications may 248 retrieve information using the network and VPN service PM model 249 through a NETCONF [RFC6241] or a RESTCONF [RFC8040] interface. For 250 example, a specified "link-id" of a VPN can be used as a filter in a 251 RESTCONF GET request to retrieve per-link VPN PM data. 253 4. Description of The Data Model 255 This document defines the YANG module, "ietf-network-vpn-pm", which 256 is an augmentation to the "ietf-network" and "ietf-network-topology". 258 The performance monitoring data augments the service topology as 259 shown in Figure 2. 261 +----------------------+ +-----------------------+ 262 |ietf-network | |Network and VPN Service| 263 |ietf-network-topology |<---------|Performance Monitoring | 264 +----------------------+ augments | Model | 265 +-----------------------+ 267 Figure 2: Module Augmentation 269 4.1. Layering Relationship between Multiple Layers of Topology 271 [RFC8345] defines a YANG data model for network/service topologies 272 and inventories. The service topology described in [RFC8345] 273 includes the virtual topology for a service layer above Layer 1 (L1), 274 Layer 2 (L2), and Layer 3 (L3). This service topology has the 275 generic topology elements of node, link, and terminating point. One 276 typical example of a service topology is described in Figure 3 of 277 [RFC8345]: two VPN service topologies instantiated over a common L3 278 topology. Each VPN service topology is mapped onto a subset of nodes 279 from the common L3 topology. 281 Figure 3 illustrates an example of a topology that maps between the 282 VPN service topology and an underlying network: 284 VPN 1 VPN 2 285 +-----------------------+ +---------------------+ 286 / / / / 287 /S1C_[VN3]::: / /S2A S2B / 288 / \ ::::: / / _[VN1]______[VN3]_ / 289 / \ : / / : : / Overlay 290 / \ :: : : : : : : / 291 /S1B_[VN2]____[VN1]_S1A / / : : : / 292 +--------:-------:------+ +---:----:----------:-+ 293 : : :: : : : : 294 : : : : : 295 Site-1A : +-------:--: ----- -------- : -------:-----+ Site-1C 296 [CE1]___: /__ ___ [N1]__________________ [N2]__ :___ /__[CE3] 297 :/ / / \ _____/ / : / 298 [CE5]___ : ___ / / \ _____/ / :: / 299 Site-2A /: / \ / / : / 300 / : [N5] / : / Underlay Network 301 / : / __/ \__ / : / 302 / : / ___/ \__ / : / 303 Site-1B / : / ___/ \ / : / Site-2B 304 [CE2]_ /________[N4]_________________ [N3]:::_____/____[CE4] 305 +------------------------------------------+ 307 Legend: 308 N:node VN:VPN-Node S:Site 309 __ Link 310 : Mapping between networks 312 Figure 3: Example of Topology Mapping Between VPN Service 313 Topology and Underlying Network 315 As shown in Figure 3, two VPN services topologies are both built on 316 top of one common underlying physical network: 318 VPN 1: This service topology supports hub-spoke communications for 319 'customer 1' connecting the customer's access at three sites: 320 'Site-1A', 'Site-1B', and 'Site-1C'. These sites are connected to 321 nodes that are mapped to node 1 (N1), node 2 (N2), and node 4 (N4) 322 in the underlying physical network. 'Site-1A' plays the role of 323 hub while 'Site-1B' and 'Site-1C' are configured as spoke. 325 VPN 2: This service supports any-to-any communications for 'customer 326 2' connecting the customer's access at two sites: 'Site-2A' and 327 'Site-2B'. These sites are connected to nodes that are mapped to 328 nodes 1 (N1) and node 3 (N3)5 in the underlying physical network. 329 'Site-2A' and 'Site-2B' have 'any-to-any' role. 331 Apart from the association between the VPN topology and the underlay 332 topology, VPN Network PM can also provide the performance status of 333 the underlay network and VPN services. For example, network PM can 334 provide link PM statistics and port statistics. VPN PM can provides 335 statistics on VPN access interfaces, the number of current VRF routes 336 or L2VPN MAC entry of VPN nodes, and performance statistics on the 337 logical point-to-point link between source and destination VPN nodes 338 or between source and destination VPN access interfaces. Figure 4 339 illustrates an example of VPN PM and the difference between two VPN 340 PM measurement methods. One is the VPN tunnel PM and the other is 341 inter-VPN-access interface PM. 343 +-----------------------------------------------------+ 344 | | 345 | VPN2 Link | 346 | |<-------------------->| | 347 | | | | 348 | VPN2+---+---+ +---+---+VPN2 | 349 | TP1| VN1 | Tunnel PM | VN3 |TP2 | 350 | ---+ PE A |==============| PE B +---- | 351 |vpn-access+-------+ +-------+ vpn-access| 352 |-interface| | -interface| 353 | |##############################| | 354 | |inter-vpn-access-interface PM | | 355 | | 356 +-----------------------------------------------------+ 357 | | 358 | | 359 +----+ | TP+-----+ Link +---+ Link +-----+TP | +----+ 360 | CE4+-+----------+ N1 +-------+-N2+-------+ N3 +----------+-+CE5 | 361 +----+ | 1-1+-----+1-2 2-1+---+2-2 3-1+-----+3-2 | +----+ 362 | | 363 | | 364 +-----------------------------------------------------+ 365 Legend: 366 N:node VN:VPN-Node 367 -:Link 369 Figure 4: An Example of VPN PM 371 4.2. Network Level 373 For network performance monitoring, the container of "networks" in 374 [RFC8345] does not need to be extended. 376 For VPN service performance monitoring, the container "service-type" 377 is defined to indicate the VPN type, e.g., L3VPN or Virtual Private 378 LAN Service (VPLS). The values are taken from [RFC9181]. When a 379 network topology instance contains the L3VPN or other L2VPN network 380 type, it represents a VPN instance that can perform performance 381 monitoring. 383 The tree in Figure 5 is a part of ietf-network-vpn-pm tree. It 384 defines the following set of network level attributes: 386 "vpn-id": Refers to an identifier of VPN service defined in 387 [RFC9181]). This identifier is used to correlate the performance 388 status with the network service configuration. 390 "vpn-service-topology": Indicates the type of the VPN topology. 391 This model supports "any-to-any", "Hub and Spoke" (where Hubs can 392 exchange traffic), and "Hub and Spoke disjoint" (where Hubs cannot 393 exchange traffic) that are taken from [RFC9181]. These VPN 394 topology types can be used to describe how VPN sites communicate 395 with each other. 397 module: ietf-network-vpn-pm 398 augment /nw:networks/nw:network/nw:network-types: 399 +--rw service-type! 400 +--rw service-type? identityref 401 augment /nw:networks/nw:network: 402 +--rw vpn-pm-attributes 403 +--rw vpn-id? vpn-common:vpn-id 404 +--rw vpn-service-topology? identityref 406 Figure 5: Network Level YANG Tree of the Hierarchies 408 4.3. Node Level 410 The tree in Figure 6 is the node part of ietf-network-vpn-pm tree. 412 For network performance monitoring, a container of "pm-attributes" is 413 augmented to the list of "node" that are defined in [RFC8345]. The 414 container includes the following attributes: 416 "node-type": Indicates the device type of Provider Edge (PE), 417 Provider (P) device, or Autonomous System Border Router (ASBR) as 418 defined in [RFC4026] and [RFC4364], so that the performance metric 419 between any two nodes each with specific node type can be 420 reported. 422 "entry-summary": Lists a set of IPv4 statistics, IPv6 statistics, 423 and MAC statistics. The detailed statistics are specified 424 separately. 426 For VPN service performance monitoring, the model defines one 427 attribute: 429 "role": Defines the role in a particular VPN service topology. The 430 roles are taken from [RFC9181] (e.g., any-to-any-role, spoke-role, 431 hub-role). 433 augment /nw:networks/nw:network/nw:node: 434 +--rw pm-attributes 435 +--rw node-type? identityref 436 +--ro entry-summary 437 | +--ro ipv4 438 | | +--ro maximum-routes? uint32 439 | | +--ro total-active-routes? uint32 440 | +--ro ipv6 441 | | +--ro maximum-routes? uint32 442 | | +--ro total-active-routes? uint32 443 | +--ro mac-num 444 | +--ro mac-num-limit? uint32 445 | +--ro total-active-mac-num? uint32 446 +--rw role? identityref 448 Figure 6: Node Level YANG Tree of the Hierarchies 450 4.4. Link and Termination Point Level 452 The tree in Figure 7 is the link and termination point (TP) part of 453 ietf-network-vpn-pm tree. 455 The 'links' are classified into two types: topology link defined in 456 [RFC8345] and abstract link of a VPN between PEs. 458 The performance data of a link is a collection of counters that 459 report the performance status. 461 augment /nw:networks/nw:network/nt:link: 462 +--rw pm-attributes 463 +--rw low-percentile? percentile 464 +--rw intermediate-percentile? percentile 465 +--rw high-percentile? percentile 466 +--rw measurement-interval? uint32 467 +--ro start-time? yang:date-and-time 468 +--ro end-time? yang:date-and-time 469 +--ro pm-source? identityref 470 +--ro one-way-pm-statistics 471 | +--ro loss-statistics 472 | | +--ro packet-loss-count? yang:counter64 473 | | +--ro loss-ratio? percentage 474 | +--ro delay-statistics 475 | | +--ro unit-value? identityref 476 | | +--ro min-delay-value? yang:gauge64 477 | | +--ro max-delay-value? yang:gauge64 478 | | +--ro low-delay-percentile? yang:gauge64 479 | | +--ro intermediate-delay-percentile? yang:gauge64 480 | | +--ro high-delay-percentile? yang:gauge64 481 | +--ro jitter-statistics 482 | +--ro unit-value? identityref 483 | +--ro min-jitter-value? yang:gauge64 484 | +--ro max-jitter-value? yang:gauge64 485 | +--ro low-jitter-percentile? yang:gauge64 486 | +--ro intermediate-jitter-percentile? yang:gauge64 487 | +--ro high-jitter-percentile? yang:gauge64 488 +--ro one-way-pm-statistics-per-class* [class-id] 489 | +--ro class-id string 490 | +--ro loss-statistics 491 | | +--ro packet-loss-count? yang:counter64 492 | | +--ro loss-ratio? percentage 493 | +--ro delay-statistics 494 | | +--ro unit-value? identityref 495 | | +--ro min-delay-value? yang:gauge64 496 | | +--ro max-delay-value? yang:gauge64 497 | | +--ro low-delay-percentile? yang:gauge64 498 | | +--ro intermediate-delay-percentile? yang:gauge64 499 | | +--ro high-delay-percentile? yang:gauge64 500 | +--ro jitter-statistics 501 | +--ro unit-value? identityref 502 | +--ro min-jitter-value? yang:gauge64 503 | +--ro max-jitter-value? yang:gauge64 504 | +--ro low-jitter-percentile? yang:gauge64 505 | +--ro intermediate-jitter-percentile? yang:gauge64 506 | +--ro high-jitter-percentile? yang:gauge64 507 +--rw (vpn-pm-type)? 508 +--:(inter-vpn-access-interface) 509 | +--rw inter-vpn-access-interface? empty 510 +--:(underlay-tunnel) 511 +--ro vpn-underlay-transport-type? identityref 512 augment /nw:networks/nw:network/nw:node/nt:termination-point: 513 +--ro pm-statistics 514 +--ro reference-time? yang:date-and-time 515 +--ro inbound-octets? yang:counter64 516 +--ro inbound-unicast? yang:counter64 517 +--ro inbound-nunicast? yang:counter64 518 +--ro inbound-discards? yang:counter64 519 +--ro inbound-errors? yang:counter64 520 +--ro inbound-unknown-protocol? yang:counter64 521 +--ro outbound-octets? yang:counter64 522 +--ro outbound-unicast? yang:counter64 523 +--ro outbound-nunicast? yang:counter64 524 +--ro outbound-discards? yang:counter64 525 +--ro outbound-errors? yang:counter64 526 +--ro vpn-network-access* [network-access-id] 527 +--ro network-access-id vpn-common:vpn-id 528 +--ro reference-time? yang:date-and-time 529 +--ro inbound-octets? yang:counter64 530 +--ro inbound-unicast? yang:counter64 531 +--ro inbound-nunicast? yang:counter64 532 +--ro inbound-discards? yang:counter64 533 +--ro inbound-errors? yang:counter64 534 +--ro inbound-unknown-protocol? yang:counter64 535 +--ro outbound-octets? yang:counter64 536 +--ro outbound-unicast? yang:counter64 537 +--ro outbound-nunicast? yang:counter64 538 +--ro outbound-discards? yang:counter64 539 +--ro outbound-errors? yang:counter64 541 Figure 7: Link and Termination point Level YANG Tree of the 542 hierarchies 544 For the data nodes of 'link' depicted in Figure 7, the YANG module 545 defines the following minimal set of link-level performance 546 attributes: 548 Percentile parameters: The module supports reporting delay and 549 jitter metric by percentile values. By default, low percentile 550 (10th percentile), intermediate percentile (50th percentile), high 551 percentile (90th percentile) are used. Setting a percentile to 552 0.00 indicates the client is not interested in receiving 553 particular percentile. If all percentile nodes are set to 0.00, 554 this represents that no percentile related nodes will be reported 555 for a given performance metric (e.g., one-way delay, one-way delay 556 variation) and only peak/min values will be reported. For 557 example, a client can inform the server that it is interested in 558 receiving only high percentiles. Then for a given link, at a 559 given "start-time", "end-time" and "measurement-interval", the 560 'high-delay-percentile' and 'high-jitter-percentile' will be 561 reported. An example to illustrate the use of percentiles is 562 provided in Appendix A.3. 564 PM source ("pm-source"): Indicates the performance monitoring 565 source. The data for the topology link can be based, e.g., on 566 BGP-LS [RFC8571]. The statistics of the VPN abstract links can be 567 collected based upon VPN OAM mechanisms, e.g.,OAM mechanisms 568 referenced in [RFC9182], or Ethernet service OAM [ITU-T-Y-1731] 569 referenced in [I-D.ietf-opsawg-l2nm]. Alternatively, the data can 570 be based upon the underlay technology OAM mechanisms, for example, 571 Generic Routing Encapsulation (GRE) tunnel OAM. 573 Measurement interval ("measurement-interval"): Specifies the 574 performance measurement interval, in seconds. 576 Start time ("start-time"): Indicates the start time of the 577 performance measurement for link statistics. 579 End time ("end-time"): Indicates the end time of the performance 580 measurement for link statistics. 582 Reference time ("reference-time"): Indicates the timestamp when the 583 counters are obtained. 585 Loss statistics: A set of one-way loss statistics attributes that 586 are used to measure end to end loss between VPN sites or between 587 any two network nodes. The exact loss value or the loss 588 percentage can be reported. 590 Delay statistics: A set of one-way delay statistics attributes that 591 are used to measure end to end latency between VPN sites or 592 between any two network nodes. The peak/min values or percentile 593 values can be reported. 595 Jitter statistics: A set of one-way IP Packet Delay Variation 596 [RFC3393] statistics attributes that are used to measure end to 597 end jitter between VPN sites or between any two network nodes. 598 The peak/min values or percentile values can be reported. 600 PM statistics per class ("one-way-pm-statistics-per-class"): Lists p 601 erformance measurement statistics for the topology link or the 602 abstract underlay link between VPN PEs with given "class-id" 603 names. The list is defined separately from "one-way-pm- 604 statistics", which is used to collect generic metrics for 605 unspecified "class-id" names. 607 VPN PM type ("vpn-pm-type"): Indicates the VPN performance type, 608 which can be inter-vpn-access-interface PM or VPN underlay-tunnel 609 PM. These two methods are common VPN measurement methods. The 610 inter-VPN-access-interface PM is to monitor the performance of 611 logical point-to-point connections between a source and a 612 destination VPN access interfaces. And the underlay-tunnel PM is 613 to monitor the performance of underlay tunnels of VPNs. The 614 inter-VPN-access-interface PM includes PE-PE monitoring. 615 Therefore, only one of the two methods is needed , and the model 616 defines "choice" to indicate these two methods, which also allows 617 other methods to be extended. 619 VPN underlay transport type ("vpn-underlay-transport-type"): Indicat 620 es the abstract link protocol-type of a VPN, such as GRE or IP-in- 621 IP. The leaf refers to an identifier of the "underlay-transport" 622 defined in [RFC9181], which describes the transport technology to 623 carry the traffic of the VPN service. 625 For the data nodes of 'termination-point' depicted in Figure 7, the 626 module defines the following minimal set of statistics: 628 Inbound statistics: A set of inbound statistics attributes that are 629 used to measure the inbound statistics of the termination point, 630 such as received packets, received packets with errors, etc. 632 Outbound statistics: A set of outbound statistics attributes that 633 are used to measure the outbound statistics of the termination 634 point, such as sent packets, packets that could not be sent due to 635 errors, etc. 637 VPN network access ("vpn-network-access"): Lists counters of the VPN 638 network access defined in [RFC9182] or [I-D.ietf-opsawg-l2nm]. 639 When multiple VPN network accesses are created using the same 640 physical port, finer-grained metrics can be monitored. If a TP is 641 associated with only a single VPN, this list is not required. 643 5. Network and VPN Service Performance Monitoring YANG Module 645 The "ietf-network-vpn-pm" module uses types defined in [RFC8345], 646 [RFC6991], [RFC8532], and [RFC9181]. 648 file "ietf-network-vpn-pm@2021-04-08.yang" 649 module ietf-network-vpn-pm { 650 yang-version 1.1; 651 namespace "urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm"; 652 prefix nvp; 654 import ietf-yang-types { 655 prefix yang; 656 reference 657 "RFC 6991: Common YANG Types"; 658 } 659 import ietf-vpn-common { 660 prefix vpn-common; 661 reference 662 "RFC 9181: A Common YANG Data Model for Layer 2 and 663 Layer 3 VPNs."; 664 } 665 import ietf-network { 666 prefix nw; 667 reference 668 "RFC 8345: A YANG Data Model for Network 669 Topologies, Section 6.1"; 670 } 671 import ietf-network-topology { 672 prefix nt; 673 reference 674 "RFC 8345: A YANG Data Model for Network 675 Topologies, Section 6.2"; 676 } 677 import ietf-lime-time-types { 678 prefix lime; 679 reference 680 "RFC 8532: Generic YANG Data Model for the Management of 681 Operations, Administration, and Maintenance (OAM) Protocols 682 That Use Connectionless Communications"; 683 } 685 organization 686 "IETF OPSAWG (Operations and Management Area Working Group)"; 687 contact 688 "WG Web: 689 WG List: 691 Editor: Bo Wu 692 693 Editor: Mohamed Boucadair 694 695 Editor: Qin Wu 696 697 Author: Oscar Gonzalez de Dios 698 699 Author: Bin Wen 700 "; 701 description 702 "This module defines a model for Network and VPN Service 703 Performance monitoring. 705 Copyright (c) 2022 IETF Trust and the persons identified as 706 authors of the code. All rights reserved. 708 Redistribution and use in source and binary forms, with or 709 without modification, is permitted pursuant to, and subject 710 to the license terms contained in, the Revised BSD License 711 set forth in Section 4.c of the IETF Trust's Legal Provisions 712 Relating to IETF Documents 713 (https://trustee.ietf.org/license-info). 715 This version of this YANG module is part of RFC XXXX 716 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 717 for full legal notices."; 719 // RFC Ed.: update the date below with the date of RFC 720 // publication and remove this note. 721 // RFC Ed.: replace XXXX with actual RFC number and remove 722 // this note. 724 revision 2022-04-08 { 725 description 726 "Initial revision."; 727 reference 728 "RFC XXXX: A YANG Model for Network and VPN Service 729 Performance Monitoring"; 730 } 732 identity node-type { 733 description 734 "Base identity for node type"; 735 } 737 identity pe { 738 base node-type; 739 description 740 "Provider Edge (PE) node type."; 741 reference 742 "RFC 4026: Provider Provisioned 743 Virtual Private Network (VPN) Terminology"; 744 } 746 identity p { 747 base node-type; 748 description 749 "Provider router node type."; 750 reference 751 "RFC 4026: Provider Provisioned 752 Virtual Private Network (VPN) Terminology"; 754 } 756 identity asbr { 757 base node-type; 758 description 759 "Autonomous System Border Router (ASBR) node type."; 760 reference 761 "RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs)"; 762 } 764 identity pm-source-type { 765 description 766 "Base identity from which specific performance monitoring 767 mechanism types are derived."; 768 } 770 identity pm-source-bgpls { 771 base pm-source-type; 772 description 773 "Indicates BGP-LS as the performance monitoring metric source"; 774 reference 775 "RFC 8571: BGP - Link State (BGP-LS) Advertisement of 776 IGP Traffic Engineering Performance Metric Extensions"; 777 } 779 identity pm-source-owamp { 780 base pm-source-type; 781 description 782 "Indicates One-Way Active Measurement Protocol(OWAMP) 783 as the performance monitoring metric source."; 784 reference 785 "RFC 4656: A One-Way Active Measurement Protocol (OWAMP)"; 786 } 788 identity pm-source-twamp { 789 base pm-source-type; 790 description 791 "Indicates Two-Way Active Measurement Protocol(TWAMP) 792 as the performance monitoring metric source."; 793 reference 794 "RFC 5357: A Two-Way Active Measurement Protocol (TWAMP)"; 795 } 797 identity pm-source-y-1731 { 798 base pm-source-type; 799 description 800 "Indicates Ethernet OAM Y.1731 as the performance monitoring 801 metric source."; 803 reference 804 "ITU-T Y.1731: Operations, administration and 805 maintenance (OAM) functions and mechanisms 806 for Ethernet-based networks"; 807 } 809 typedef percentage { 810 type decimal64 { 811 fraction-digits 5; 812 range "0..100"; 813 } 814 description 815 "Percentage."; 816 } 818 typedef percentile { 819 type decimal64 { 820 fraction-digits 2; 821 range "0..100"; 822 } 823 description 824 "The percentile is a value between 0 and 100, 825 e.g. 10.00, 99.90 ,99.99 etc.. 826 For example, for a given one-way delay measurement, 827 if the percentile is set to 95.00 and 828 the 95th percentile one-way delay is 2 milliseconds, 829 then the 95 percent of the sample value 830 is less than or equal to 2 milliseconds."; 831 } 833 grouping entry-summary { 834 description 835 "Entry summary grouping used for network topology 836 augmentation."; 837 container entry-summary { 838 config false; 839 description 840 "Container for VPN or network entry summary."; 841 container ipv4 { 842 leaf maximum-routes { 843 type uint32; 844 description 845 "Indicates the maximum number of IPv4 routes 846 for the VPN."; 847 } 848 leaf total-active-routes { 849 type uint32; 850 description 851 "Indicates total active IPv4 routes for the VPN."; 852 } 853 description 854 "IPv4-specific parameters."; 855 } 856 container ipv6 { 857 leaf maximum-routes { 858 type uint32; 859 description 860 "Indicates the maximum number of IPv6 routes 861 for the VPN."; 862 } 863 leaf total-active-routes { 864 type uint32; 865 description 866 "Indicates total active IPv6 routes for the VPN."; 867 } 868 description 869 "IPv6-specific parameters."; 870 } 871 container mac-num { 872 leaf mac-num-limit { 873 type uint32; 874 description 875 "Maximum number of MAC addresses."; 876 } 877 leaf total-active-mac-num { 878 type uint32; 879 description 880 "Total active MAC entries for the VPN."; 881 } 882 description 883 "MAC statistics."; 884 } 885 } 886 } 888 grouping link-loss-statistics { 889 description 890 "Grouping for per link error statistics."; 891 container loss-statistics { 892 description 893 "One-way link loss summarized information."; 894 reference 895 "RFC 4656: A One-way Active Measurement Protocol (OWAMP) 896 ITU-T Y.1731: Operations, administration and 897 maintenance (OAM) functions and mechanisms 898 for Ethernet-based networks"; 900 leaf packet-loss-count { 901 type yang:counter64; 902 description 903 "Total received packet drops count."; 904 } 905 leaf loss-ratio { 906 type percentage; 907 description 908 "Loss ratio of the packets. Express as percentage 909 of packets lost with respect to packets sent."; 910 } 911 } 912 } 914 grouping link-delay-statistics { 915 description 916 "Grouping for per link delay statistics."; 917 container delay-statistics { 918 description 919 "One-way link delay summarized information."; 920 reference 921 "RFC 4656: A One-way Active Measurement Protocol (OWAMP) 922 ITU-T Y.1731: Operations, administration and 923 maintenance (OAM) functions and mechanisms 924 for Ethernet-based networks"; 925 leaf unit-value { 926 type identityref { 927 base lime:time-unit-type; 928 } 929 default "lime:milliseconds"; 930 description 931 "Time units, where the options are s, ms, ns, etc."; 932 } 933 leaf min-delay-value { 934 type yang:gauge64; 935 description 936 "Minimum observed one-way delay."; 937 } 938 leaf max-delay-value { 939 type yang:gauge64; 940 description 941 "Maximum observed one-way delay."; 942 } 943 leaf low-delay-percentile { 944 type yang:gauge64; 945 description 946 "Low percentile of observed one-way delay with 947 specific measurement method."; 949 } 950 leaf intermediate-delay-percentile { 951 type yang:gauge64; 952 description 953 "Intermediate percentile of observed one-way delay with 954 specific measurement method."; 955 } 956 leaf high-delay-percentile { 957 type yang:gauge64; 958 description 959 "High percentile of observed one-way delay with 960 specific measurement method."; 961 } 962 } 963 } 965 grouping link-jitter-statistics { 966 description 967 "Grouping for per link jitter statistics."; 968 container jitter-statistics { 969 description 970 "One-way link jitter summarized information."; 971 reference 972 "RFC 3393: IP Packet Delay Variation Metric 973 for IP Performance Metrics (IPPM) 974 RFC 4656: A One-way Active Measurement Protocol (OWAMP) 975 ITU-T Y.1731: Operations, administration and 976 maintenance (OAM) functions and mechanisms 977 for Ethernet-based networks"; 978 leaf unit-value { 979 type identityref { 980 base lime:time-unit-type; 981 } 982 default "lime:milliseconds"; 983 description 984 "Time units, where the options are s, ms, ns, etc."; 985 } 986 leaf min-jitter-value { 987 type yang:gauge64; 988 description 989 "Minimum observed one-way jitter."; 990 } 991 leaf max-jitter-value { 992 type yang:gauge64; 993 description 994 "Maximum observed one-way jitter."; 995 } 996 leaf low-jitter-percentile { 997 type yang:gauge64; 998 description 999 "Low percentile of observed one-way jitter."; 1000 } 1001 leaf intermediate-jitter-percentile { 1002 type yang:gauge64; 1003 description 1004 "Intermediate percentile of observed one-way jitter."; 1005 } 1006 leaf high-jitter-percentile { 1007 type yang:gauge64; 1008 description 1009 "High percentile of observed one-way jitter."; 1010 } 1011 } 1012 } 1014 grouping tp-svc-telemetry { 1015 leaf reference-time { 1016 type yang:date-and-time; 1017 config false; 1018 description 1019 "Indicates the time when the statistics are collected."; 1020 } 1021 leaf inbound-octets { 1022 type yang:counter64; 1023 description 1024 "The total number of octets received on the 1025 interface, including framing characters."; 1026 } 1027 leaf inbound-unicast { 1028 type yang:counter64; 1029 description 1030 "The total number of inbound unicast packets."; 1031 } 1032 leaf inbound-nunicast { 1033 type yang:counter64; 1034 description 1035 "The total number of inbound non-unicast 1036 (i.e., broadcast or multicast) packets."; 1037 } 1038 leaf inbound-discards { 1039 type yang:counter64; 1040 description 1041 "The number of inbound packets that were chosen to be 1042 discarded even though no errors had been detected. 1043 Possible reasons for discarding such a packet could 1044 be to free up buffer space, not enough buffer for 1045 too much data, etc."; 1046 } 1047 leaf inbound-errors { 1048 type yang:counter64; 1049 description 1050 "The number of inbound packets that contained errors."; 1051 } 1052 leaf inbound-unknown-protocol { 1053 type yang:counter64; 1054 description 1055 "The number of packets received via the interface 1056 which were discarded because of an unknown or 1057 unsupported protocol."; 1058 } 1059 leaf outbound-octets { 1060 type yang:counter64; 1061 description 1062 "The total number of octets transmitted out of the 1063 interface, including framing characters."; 1064 } 1065 leaf outbound-unicast { 1066 type yang:counter64; 1067 description 1068 "The total number of outbound unicast packets."; 1069 } 1070 leaf outbound-nunicast { 1071 type yang:counter64; 1072 description 1073 "The total number of outbound non unicast 1074 (i.e., broadcast or multicast) packets."; 1075 } 1076 leaf outbound-discards { 1077 type yang:counter64; 1078 description 1079 "The number of outbound packets which were chosen 1080 to be discarded even though no errors had been 1081 detected to prevent their being transmitted. 1082 Possible reasons for discarding such a packet could 1083 be to free up buffer space, not enough buffer for 1084 too much data, etc."; 1085 } 1086 leaf outbound-errors { 1087 type yang:counter64; 1088 description 1089 "The number of outbound packets that contained 1090 errors."; 1091 } 1092 description 1093 "Grouping for interface service telemetry."; 1094 } 1096 augment "/nw:networks/nw:network/nw:network-types" { 1097 description 1098 "Defines the service topologies types."; 1099 container service-type { 1100 presence "Indicates network service topology."; 1101 leaf service-type { 1102 type identityref { 1103 base vpn-common:service-type; 1104 } 1105 description 1106 "The presence identifies the network service type, 1107 e.g., L3VPN, VPLS, etc."; 1108 } 1109 description 1110 "Container for VPN service type."; 1111 } 1112 } 1114 augment "/nw:networks/nw:network" { 1115 when 'nw:network-types/nvp:service-type' { 1116 description 1117 "Augments only for VPN Network topology."; 1118 } 1119 description 1120 "Augments the network with service topology attributes"; 1121 container vpn-pm-attributes { 1122 leaf vpn-id { 1123 type vpn-common:vpn-id; 1124 description 1125 "VPN identifier."; 1126 } 1127 leaf vpn-service-topology { 1128 type identityref { 1129 base vpn-common:vpn-topology; 1130 } 1131 description 1132 "VPN service topology, e.g., hub-spoke, any-to-any, 1133 hub-spoke-disjoint."; 1134 } 1135 description 1136 "Container for VPN topology attributes."; 1137 } 1138 } 1140 augment "/nw:networks/nw:network/nw:node" { 1141 description 1142 "Augments the network node with other general attributes."; 1143 container pm-attributes { 1144 leaf node-type { 1145 type identityref { 1146 base node-type; 1147 } 1148 description 1149 "Node type, e.g., PE, P, ASBR."; 1150 } 1151 description 1152 "Container for node attributes."; 1153 uses entry-summary; 1154 } 1155 } 1157 augment "/nw:networks/nw:network/nw:node/pm-attributes" { 1158 when '../../nw:network-types/nvp:service-type' { 1159 description 1160 "Augments only for VPN node attributes."; 1161 } 1162 description 1163 "Augments the network node with VPN specific attributes."; 1164 leaf role { 1165 type identityref { 1166 base vpn-common:role; 1167 } 1168 default "vpn-common:any-to-any-role"; 1169 description 1170 "Role of the node in the VPN."; 1171 } 1172 } 1174 augment "/nw:networks/nw:network/nt:link" { 1175 description 1176 "Augments the network topology link with performance 1177 monitoring attributes."; 1178 container pm-attributes { 1179 description 1180 "Container for PM attributes."; 1181 leaf low-percentile { 1182 type percentile; 1183 default "10.00"; 1184 description 1185 "Low percentile to report. Setting low-percentile 1186 into 0.00 indicates the client is not interested 1187 in receiving low percentile."; 1188 } 1189 leaf intermediate-percentile { 1190 type percentile; 1191 default "50.00"; 1192 description 1193 "Intermediate percentile to report. Setting 1194 intermediate-percentile into 0.00 indicates the client 1195 is not interested in receiving intermediate percentile."; 1196 } 1197 leaf high-percentile { 1198 type percentile; 1199 default "95.00"; 1200 description 1201 "High percentile to report. Setting high-percentile 1202 into 0.00 indicates the client is not interested in 1203 receiving high percentile."; 1204 } 1205 leaf measurement-interval { 1206 type uint32 { 1207 range "1..max"; 1208 } 1209 units "seconds"; 1210 default "60"; 1211 description 1212 "Indicates the time interval to perform PM measurement."; 1213 } 1214 leaf start-time { 1215 type yang:date-and-time; 1216 config false; 1217 description 1218 "The time that the current measurement started."; 1219 } 1220 leaf end-time { 1221 type yang:date-and-time; 1222 config false; 1223 description 1224 "The time that the current measurement ended."; 1225 } 1226 leaf pm-source { 1227 type identityref { 1228 base pm-source-type; 1229 } 1230 config false; 1231 description 1232 "The OAM tool used to collect the PM data."; 1233 } 1234 container one-way-pm-statistics { 1235 config false; 1236 description 1237 "Container for link telemetry attributes."; 1238 uses link-loss-statistics; 1239 uses link-delay-statistics; 1240 uses link-jitter-statistics; 1241 } 1242 list one-way-pm-statistics-per-class { 1243 key "class-id"; 1244 config false; 1245 description 1246 "The list of PM data based on class of service."; 1247 leaf class-id { 1248 type string; 1249 description 1250 "The class-id is used to identify the class of service. 1251 This identifier is internal to the administration."; 1252 } 1253 uses link-loss-statistics; 1254 uses link-delay-statistics; 1255 uses link-jitter-statistics; 1256 } 1257 } 1258 } 1260 augment "/nw:networks/nw:network/nt:link/pm-attributes" { 1261 when '../../nw:network-types/nvp:service-type' { 1262 description 1263 "Augments only for VPN Network topology."; 1264 } 1265 description 1266 "Augments the network topology link with VPN service 1267 performance monitoring attributes."; 1268 choice vpn-pm-type { 1269 description 1270 "The VPN PM type of this logical point-to-point 1271 unidirectional VPN link."; 1272 case inter-vpn-access-interface { 1273 leaf inter-vpn-access-interface { 1274 type empty; 1275 description 1276 "This is a placeholder for inter-vpn-access-interface PM. 1277 There is no technology to be defined."; 1278 } 1279 } 1280 case underlay-tunnel { 1281 leaf vpn-underlay-transport-type { 1282 type identityref { 1283 base vpn-common:protocol-type; 1284 } 1285 config false; 1286 description 1287 "The leaf indicates the underlay transport type of 1288 a VPN service, e.g., GRE, LDP, etc."; 1289 } 1290 } 1291 } 1292 } 1294 augment "/nw:networks/nw:network/nw:node/nt:termination-point" { 1295 description 1296 "Augments the network topology termination point with 1297 performance monitoring attributes."; 1298 container pm-statistics { 1299 config false; 1300 description 1301 "Container for termination point PM attributes."; 1302 uses tp-svc-telemetry; 1303 } 1304 } 1306 augment "/nw:networks/nw:network/nw:node" 1307 + "/nt:termination-point/pm-statistics" { 1308 when '../../../nw:network-types/nvp:service-type' { 1309 description 1310 "Augments only for VPN Network topology."; 1311 } 1312 description 1313 "Augments the network topology termination-point with 1314 VPN service performance monitoring attributes"; 1315 list vpn-network-access { 1316 key "network-access-id"; 1317 description 1318 "The list of PM based on VPN network accesses."; 1319 leaf network-access-id { 1320 type vpn-common:vpn-id; 1321 description 1322 "References to an identifier for the VPN network 1323 access, e.g. L3VPN or VPLS."; 1324 } 1325 uses tp-svc-telemetry; 1326 } 1327 } 1328 } 1329 1331 6. Security Considerations 1333 The YANG modules defined in this document MAY be accessed via the 1334 RESTCONF protocol [RFC8040] or NETCONF protocol [RFC6241]. The 1335 lowest RESTCONF or NETCONF layer requires that the transport-layer 1336 protocol provides both data integrity and confidentiality, see 1337 Section 2 in [RFC8040] and [RFC6241]. The lowest NETCONF layer is 1338 the secure transport layer, and the mandatory-to-implement secure 1339 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1340 is HTTPS, and the mandatory-to-implement secure transport is TLS 1341 [RFC8446]. 1343 The NETCONF access control model [RFC8341] provides the means to 1344 restrict access for particular NETCONF or RESTCONF users to a 1345 preconfigured subset of all available NETCONF or RESTCONF protocol 1346 operations and content. 1348 There are a number of data nodes defined in this YANG module that are 1349 writable/creatable/deletable (i.e., config true, which is the 1350 default). These data nodes may be considered sensitive or vulnerable 1351 in some network environments. Write operations (e.g., edit-config) 1352 to these data nodes without proper protection can have a negative 1353 effect on network operations. These are the subtrees with the write 1354 operation that can be exploited to impact the network monitoring: 1356 * "/nw:networks/nw:network/nw:network-types" 1358 * "/nw:networks/nw:network/nvp:vpn-pm-attributes" 1360 * "/nw:networks/nw:network/nw:node/nvp:pm-attributes" 1362 * /nw:networks/nw:network/nt:link/nvp:pm-attributes" 1364 * /nw:networks/nw:network/nw:node/nt:termination-point/nvp:pm- 1365 statistics" 1367 Some of the readable data nodes in this YANG module may be considered 1368 sensitive or vulnerable in some network environments. The nodes 1369 reveals the quality of a service that is operated by an operator. It 1370 is thus important to control read access (e.g., via get, get-config, 1371 or notification) to these data nodes. These are the subtrees and 1372 data nodes and their sensitivity/vulnerability: 1374 * "/nw:networks/nw:network/nw:node/nvp:pm-attributes/nvp:vpn- 1375 summary-statistics": Unauthorized access to this subtree can 1376 disclose the operational state information of VPN instances. 1378 * "/nw:networks/nw:network/nt:link/nvp:pm-attributes/nvp:one-way-pm- 1379 statistics": Unauthorized access to this subtree can disclose the 1380 operational state information of network links or VPN abstract 1381 links. 1383 * "/nw:networks/nw:network/nw:node/nt:termination-point/nvp:pm- 1384 statistics": Unauthorized access to this subtree can disclose the 1385 operational state information of network termination points or VPN 1386 network accesses. 1388 7. IANA Considerations 1390 This document requests IANA to register the following URI in the "ns" 1391 subregistry within the "IETF XML Registry" [RFC3688]: 1393 URI: urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm 1394 Registrant Contact: The IESG. 1395 XML: N/A, the requested URI is an XML namespace. 1397 This document requests IANA to register the following YANG module in 1398 the "YANG Module Names" subregistry [RFC6020] within the "YANG 1399 Parameters" registry. 1401 Name: ietf-network-vpn-pm 1402 Namespace: urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm 1403 Maintained by IANA: N 1404 Prefix: nvp 1405 Reference: RFC XXXX (RFC Ed.: replace XXXX with actual 1406 RFC number and remove this note.) 1408 8. Acknowledgements 1410 Thanks to Joe Clarke, Adrian Farrel, Tom Petch, Greg Mirsky, Roque 1411 Gagliano, Erez Segev, and Dhruv Dhody for reviewing and providing 1412 important input to this document. 1414 9. Contributors 1416 The following authors contributed significantly to this document: 1418 Michale Wang 1419 Huawei 1420 Email:wangzitao@huawei.com 1422 Roni Even 1423 Huawei 1424 Email: ron.even.tlv@gmail.com 1426 Change Liu 1427 China Unicom 1428 Email: liuc131@chinaunicom.cn 1430 Honglei Xu 1431 China Telecom 1432 Email: xuhl.bri@chinatelecom.cn 1434 10. References 1436 10.1. Normative References 1438 [ITU-T-Y-1731] 1439 ITU-T, "Operator Ethernet Service Definition", August 1440 2015, . 1442 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1443 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1444 DOI 10.17487/RFC3393, November 2002, 1445 . 1447 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1448 DOI 10.17487/RFC3688, January 2004, 1449 . 1451 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 1452 Zekauskas, "A One-way Active Measurement Protocol 1453 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 1454 . 1456 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 1457 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 1458 RFC 5357, DOI 10.17487/RFC5357, October 2008, 1459 . 1461 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1462 the Network Configuration Protocol (NETCONF)", RFC 6020, 1463 DOI 10.17487/RFC6020, October 2010, 1464 . 1466 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1467 and A. Bierman, Ed., "Network Configuration Protocol 1468 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1469 . 1471 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1472 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1473 . 1475 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 1476 Measurement for MPLS Networks", RFC 6374, 1477 DOI 10.17487/RFC6374, September 2011, 1478 . 1480 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1481 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1482 . 1484 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1485 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1486 . 1488 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1489 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1490 . 1492 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1493 Access Control Model", STD 91, RFC 8341, 1494 DOI 10.17487/RFC8341, March 2018, 1495 . 1497 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1498 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1499 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1500 2018, . 1502 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1503 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1504 . 1506 [RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S. 1507 Raghavan, "Generic YANG Data Model for the Management of 1508 Operations, Administration, and Maintenance (OAM) 1509 Protocols That Use Connectionless Communications", 1510 RFC 8532, DOI 10.17487/RFC8532, April 2019, 1511 . 1513 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1514 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1515 September 2019, . 1517 [RFC9181] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., 1518 Ed., and Q. Wu, "A Common YANG Data Model for Layer 2 and 1519 Layer 3 VPNs", RFC 9181, DOI 10.17487/RFC9181, February 1520 2022, . 1522 10.2. Informative References 1524 [I-D.ietf-netmod-node-tags] 1525 Wu, Q., Claise, B., Liu, P., Du, Z., and M. Boucadair, 1526 "Self-Describing Data Object Tags in YANG Data Models", 1527 Work in Progress, Internet-Draft, draft-ietf-netmod-node- 1528 tags-06, 21 February 2022, 1529 . 1532 [I-D.ietf-opsawg-l2nm] 1533 Barguil, S., Dios, O. G. D., Boucadair, M., and L. A. 1534 Munoz, "A Layer 2 VPN Network YANG Model", Work in 1535 Progress, Internet-Draft, draft-ietf-opsawg-l2nm-12, 22 1536 November 2021, . 1539 [I-D.ietf-opsawg-sap] 1540 Boucadair, M., Dios, O. G. D., Barguil, S., Wu, Q., and V. 1541 Lopez, "A Network YANG Model for Service Attachment Points 1542 (SAPs)", Work in Progress, Internet-Draft, draft-ietf- 1543 opsawg-sap-03, 21 March 2022, 1544 . 1547 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 1548 Private Network (VPN) Terminology", RFC 4026, 1549 DOI 10.17487/RFC4026, March 2005, 1550 . 1552 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1553 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1554 2006, . 1556 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 1557 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 1558 . 1560 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1561 Previdi, "OSPF Traffic Engineering (TE) Metric 1562 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1563 . 1565 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1566 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1567 . 1569 [RFC8194] Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for 1570 LMAP Measurement Agents", RFC 8194, DOI 10.17487/RFC8194, 1571 August 2017, . 1573 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1574 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1575 . 1577 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 1578 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 1579 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 1580 2019, . 1582 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 1583 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 1584 IGP Traffic Engineering Performance Metric Extensions", 1585 RFC 8571, DOI 10.17487/RFC8571, March 2019, 1586 . 1588 [RFC8632] Vallin, S. and M. Bjorklund, "A YANG Data Model for Alarm 1589 Management", RFC 8632, DOI 10.17487/RFC8632, September 1590 2019, . 1592 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1593 E., and A. Tripathy, "Subscription to YANG Notifications", 1594 RFC 8639, DOI 10.17487/RFC8639, September 2019, 1595 . 1597 [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and 1598 L. Geng, "A Framework for Automating Service and Network 1599 Management with YANG", RFC 8969, DOI 10.17487/RFC8969, 1600 January 2021, . 1602 [RFC9182] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., 1603 Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model 1604 for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182, 1605 February 2022, . 1607 Appendix A. Illustrating Examples 1609 A.1. VPN Performance Subscription Example 1611 The example shown in Figure 8 illustrates how a client subscribes to 1612 the performance monitoring information between nodes ('node-id') A 1613 and B in the L3 network topology. The performance monitoring 1614 parameter that the client is interested in is end-to-end loss. 1616 POST /restconf/operations 1617 /ietf-subscribed-notifications:establish-subscription 1618 { 1619 "ietf-subscribed-notifications:input":{ 1620 "stream-subtree-filter":{ 1621 "ietf-network-topo:networks":{ 1622 "network":{ 1623 "network-id":"l3-network", 1624 "ietf-network-vpn-pm:service-type":{ 1625 "ietf-vpn-common:l3vpn":{} 1626 }, 1627 "node":[ 1628 { 1629 "node-id":"A", 1630 "ietf-network-vpn-pm:pm-attributes":{ 1631 "node-type":"PE" 1632 }, 1633 "termination-point":{ 1634 "tp-id":"1-0-1" 1635 } 1636 }, 1637 { 1638 "node-id":"B", 1639 "ietf-network-vpn-pm:pm-attributes":{ 1640 "node-type":"PE" 1641 }, 1642 "termination-point":{ 1643 "tp-id":"2-0-1" 1644 } 1645 } 1646 ], 1647 "link":{ 1648 "link-id":"A-B", 1649 "source":{ 1650 "source-node":"A" 1651 }, 1652 "destination":{ 1653 "dest-node":"B" 1655 }, 1656 "ietf-network-vpn-pm:pm-attributes":{ 1657 "one-way-pm-statistics":{ 1658 "loss-statistics":{ 1659 "packet-loss-count":{} 1660 } 1661 }, 1662 "vpn-underlay-transport-type":"ietf-vpn-common:gre" 1663 } 1664 } 1665 } 1666 } 1667 }, 1668 "ietf-yang-push:periodic":{ 1669 "ietf-yang-push:period":"500" 1670 } 1671 } 1672 } 1674 Figure 8: Pub/Sub Retrieval 1676 A.2. Example of VPN Performance Snapshot 1678 This example, depicted in Figure 9, illustrates an VPN PM instance 1679 example in which a client uses RESTCONF [RFC8040] to fetch the 1680 performance data of the link and TP belonged to "VPN1". 1682 { 1683 "ietf-network-topo:networks": { 1684 "network": { 1685 "network-id": "foo:vpn1", 1686 "node": [ 1687 { 1688 "node-id": "A", 1689 "ietf-network-vpn-pm:pm-attributes": { 1690 "node-type": "PE" 1691 }, 1692 "termination-point": { 1693 "tp-id": "1-0-1", 1694 "ietf-network-vpn-pm:pm-statistics": { 1695 "inbound-octets": "100", 1696 "outbound-octets": "150" 1697 } 1698 } 1699 }, 1700 { 1701 "node-id": "B", 1702 "ietf-network-vpn-pm:pm-attributes": { 1703 "node-type": "PE" 1704 }, 1705 "termination-point": { 1706 "tp-id": "2-0-1", 1707 "ietf-network-vpn-pm:pm-statistics": { 1708 "inbound-octets": "150", 1709 "outbound-octets": "100" 1710 } 1711 } 1712 } 1713 ], 1714 "link": { 1715 "link-id": "A-B", 1716 "source": { "source-node": "A" }, 1717 "destination": { "dest-node": "B" }, 1718 "ietf-network-pm:pm-attributes": { 1719 "one-way-pm-statistics": { 1720 "loss-statistics": { "packet-loss-count": "120" } 1721 }, 1722 "vpn-underlay-transport-type": "ietf-vpn-common:gre" 1723 } 1724 } 1725 } 1726 } 1727 } 1729 Figure 9 1731 A.3. Example of Percentile Monitoring 1733 The following shows an example of a percentile measurement for a VPN 1734 link. 1736 { 1737 "ietf-network-topology:link": [ 1738 { 1739 "link-id": "vpn1-link1", 1740 "source": { 1741 "source-node": "vpn-node1" 1742 }, 1743 "destination": { 1744 "dest-node": "vpn-node3" 1745 }, 1746 "ietf-network-vpn-pm:pm-attributes": { 1747 "low-percentile": "20.00", 1748 "middle-percentile": "50.00", 1749 "high-percentile": "90.00", 1750 "one-way-pm-statistics": { 1751 "delay-statistics": { 1752 "unit-values": "lime:milliseconds", 1753 "min-delay-value": "43", 1754 "max-delay-value": "99", 1755 "low-delay-percentile": "64", 1756 "intermediate-delay-percentile": "77", 1757 "high-delay-percentile": "98" 1758 } 1759 }, 1760 "ietf-network-vpn-pm:inter-vpn-access-interface": [null] 1761 } 1762 } 1763 ] 1764 } 1766 Authors' Addresses 1768 Bo Wu (editor) 1769 Huawei 1770 101 Software Avenue, Yuhua District 1771 Nanjing 1772 Jiangsu, 210012 1773 China 1774 Email: lana.wubo@huawei.com 1775 Qin Wu (editor) 1776 Huawei 1777 101 Software Avenue, Yuhua District 1778 Nanjing 1779 Jiangsu, 210012 1780 China 1781 Email: bill.wu@huawei.com 1783 Mohamed Boucadair (editor) 1784 Orange 1785 Rennes 35000 1786 France 1787 Email: mohamed.boucadair@orange.com 1789 Oscar Gonzalez de Dios 1790 Telefonica 1791 Madrid 1792 Spain 1793 Email: oscar.gonzalezdedios@telefonica.com 1795 Bin Wen 1796 Comcast 1797 Email: bin_wen@comcast.com