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