idnits 2.17.1 draft-ietf-opsawg-yang-vpn-service-pm-07.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 1342: '...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 (25 April 2022) is 725 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' ** Downref: Normative reference to an Informational RFC: RFC 4026 == 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-13 == Outdated reference: A later version (-15) exists of draft-ietf-opsawg-sap-04 Summary: 2 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: 27 October 2022 M. Boucadair, Ed. 6 Orange 7 O. Gonzalez de Dios 8 Telefonica 9 B. Wen 10 Comcast 11 25 April 2022 13 A YANG Model for Network and VPN Service Performance Monitoring 14 draft-ietf-opsawg-yang-vpn-service-pm-07 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 27 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 . . . . . . . . . . . . . . . . . . . . . . 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 . 15 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 . . . . . . . . . . . . . . . . . 33 79 Appendix A. Illustrative 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 [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], and Multiprotocol Label Switching (MPLS) Loss and Delay 208 Measurement [RFC6374]. The performance monitoring information 209 reflecting the quality of the network or VPN service (e.g., end-to- 210 end network performance data between source node and destination node 211 in the network or between VPN sites) can be computed and aggregated, 212 for example, using the information from the Traffic Engineering 213 Database (TED), [RFC7471] [RFC8570] [RFC8571] or LMAP [RFC8194]. 215 The measurement and report intervals that are associated with these 216 performance data usually depend on the configuration of the specific 217 measurement method or collection method or various combinations. 218 This document defines a network-wide measurement interval to align 219 measurement requirements for networks or VPN services. 221 In addition, the amount of performance data collected from the 222 devices can be huge. To avoid receiving a large amount of 223 operational data of VPN instances, VPN interfaces, or tunnels, the 224 network controller can specifically subscribe to metric-specific data 225 using the tagging methods defined in [I-D.ietf-netmod-node-tags]. 227 3.1. Collecting Data via Pub/Sub Mechanism 229 Some applications such as service-assurance applications, which must 230 maintain a continuous view of operational data and state, can use the 231 subscription model specified in [RFC8641] to subscribe to the 232 specific network performance data or VPN service performance data 233 they are interested in, at the data source. For example, network or 234 VPN topology updates may be obtained through on-change notifications 235 [RFC8641]. For dynamic PM data, various notifications can be 236 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 +--:(inter-vpn-access-interface) 516 | +--rw inter-vpn-access-interface? empty 517 +--:(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 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, only one of the two methods is needed , and the model 623 defines "choice" to indicate these two methods, which also allows 624 other methods to be extended. The inter-VPN-access-interface PM 625 is defined as an empty leaf, which is not bound to a specific VPN 626 access interface. The source or destination VPN access interface 627 of the measurement can be augmented as needed. 629 VPN underlay transport type ("vpn-underlay-transport-type"): Indicat 630 es the abstract link protocol-type of a VPN, such as GRE or IP-in- 631 IP. The leaf refers to an identifier of the "underlay-transport" 632 defined in [RFC9181], which describes the transport technology to 633 carry the traffic of the VPN service. 635 For the data nodes of 'termination-point' depicted in Figure 7, the 636 module defines the following minimal set of statistics: 638 Inbound statistics: A set of inbound statistics attributes that are 639 used to measure the inbound statistics of the termination point, 640 such as received packets, received packets with errors, etc. 642 Outbound statistics: A set of outbound statistics attributes that 643 are used to measure the outbound statistics of the termination 644 point, such as sent packets, packets that could not be sent due to 645 errors, etc. 647 VPN network access ("vpn-network-access"): Lists counters of the VPN 648 network access defined in [RFC9182] or [I-D.ietf-opsawg-l2nm]. 649 When multiple VPN network accesses are created using the same 650 physical port, finer-grained metrics can be monitored. If a TP is 651 associated with only a single VPN, this list is not required. 653 5. Network and VPN Service Performance Monitoring YANG Module 655 The "ietf-network-vpn-pm" module uses types defined in [RFC8345], 656 [RFC6991], [RFC8532], and [RFC9181]. 658 file "ietf-network-vpn-pm@2022-04-25.yang" 659 module ietf-network-vpn-pm { 660 yang-version 1.1; 661 namespace "urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm"; 662 prefix nvp; 664 import ietf-yang-types { 665 prefix yang; 666 reference 667 "RFC 6991: Common YANG Types"; 668 } 669 import ietf-vpn-common { 670 prefix vpn-common; 671 reference 672 "RFC 9181: A Common YANG Data Model for Layer 2 and 673 Layer 3 VPNs."; 674 } 675 import ietf-network { 676 prefix nw; 677 reference 678 "RFC 8345: A YANG Data Model for Network 679 Topologies, Section 6.1"; 680 } 681 import ietf-network-topology { 682 prefix nt; 683 reference 684 "RFC 8345: A YANG Data Model for Network 685 Topologies, Section 6.2"; 686 } 687 import ietf-lime-time-types { 688 prefix lime; 689 reference 690 "RFC 8532: Generic YANG Data Model for the Management of 691 Operations, Administration, and Maintenance (OAM) Protocols 692 That Use Connectionless Communications"; 693 } 695 organization 696 "IETF OPSAWG (Operations and Management Area Working Group)"; 697 contact 698 "WG Web: 699 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-04-25 { 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."; 750 reference 751 "RFC 4026: Provider Provisioned 752 Virtual Private Network (VPN) Terminology"; 753 } 755 identity p { 756 base node-type; 757 description 758 "Provider router node type."; 759 reference 760 "RFC 4026: Provider Provisioned 761 Virtual Private Network (VPN) Terminology"; 762 } 764 identity asbr { 765 base node-type; 766 description 767 "Autonomous System Border Router (ASBR) node type."; 768 reference 769 "RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs)"; 770 } 772 identity pm-source-type { 773 description 774 "Base identity from which specific performance monitoring 775 mechanism types are derived."; 776 } 778 identity pm-source-bgpls { 779 base pm-source-type; 780 description 781 "Indicates BGP-LS as the performance monitoring metric source"; 782 reference 783 "RFC 8571: BGP - Link State (BGP-LS) Advertisement of 784 IGP Traffic Engineering Performance Metric Extensions"; 785 } 787 identity pm-source-owamp { 788 base pm-source-type; 789 description 790 "Indicates One-Way Active Measurement Protocol(OWAMP) 791 as the performance monitoring metric source."; 792 reference 793 "RFC 4656: A One-Way Active Measurement Protocol (OWAMP)"; 794 } 795 identity pm-source-twamp { 796 base pm-source-type; 797 description 798 "Indicates Two-Way Active Measurement Protocol(TWAMP) 799 as the performance monitoring metric source."; 800 reference 801 "RFC 5357: A Two-Way Active Measurement Protocol (TWAMP)"; 802 } 804 identity pm-source-y-1731 { 805 base pm-source-type; 806 description 807 "Indicates Ethernet OAM Y.1731 as the performance monitoring 808 metric source."; 809 reference 810 "ITU-T Y.1731: Operations, administration and 811 maintenance (OAM) functions and mechanisms 812 for Ethernet-based networks"; 813 } 815 typedef percentage { 816 type decimal64 { 817 fraction-digits 5; 818 range "0..100"; 819 } 820 description 821 "Percentage."; 822 } 824 typedef percentile { 825 type decimal64 { 826 fraction-digits 2; 827 range "0..100"; 828 } 829 description 830 "The percentile is a value between 0 and 100, 831 e.g. 10.00, 99.90 ,99.99 etc.. 832 For example, for a given one-way delay measurement, 833 if the percentile is set to 95.00 and 834 the 95th percentile one-way delay is 2 milliseconds, 835 then the 95 percent of the sample value 836 is less than or equal to 2 milliseconds."; 837 } 839 grouping entry-summary { 840 description 841 "Entry summary grouping used for network topology 842 augmentation."; 844 container entry-summary { 845 config false; 846 description 847 "Container for VPN or network entry summary."; 848 container ipv4-num { 849 leaf maximum-routes { 850 type uint32; 851 description 852 "Indicates the maximum number of IPv4 routes 853 for the VPN."; 854 } 855 leaf total-active-routes { 856 type uint32; 857 description 858 "Indicates total active IPv4 routes for the VPN."; 859 } 860 description 861 "IPv4-specific parameters."; 862 } 863 container ipv6-num { 864 leaf maximum-routes { 865 type uint32; 866 description 867 "Indicates the maximum number of IPv6 routes 868 for the VPN."; 869 } 870 leaf total-active-routes { 871 type uint32; 872 description 873 "Indicates total active IPv6 routes for the VPN."; 874 } 875 description 876 "IPv6-specific parameters."; 877 } 878 container mac-num { 879 leaf mac-num-limit { 880 type uint32; 881 description 882 "Maximum number of MAC addresses."; 883 } 884 leaf total-active-mac-num { 885 type uint32; 886 description 887 "Total active MAC entries for the VPN."; 888 } 889 description 890 "MAC statistics."; 891 } 893 } 894 } 896 grouping link-loss-statistics { 897 description 898 "Grouping for per link error statistics."; 899 container loss-statistics { 900 description 901 "One-way link loss summarized information."; 902 reference 903 "RFC 4656: A One-way Active Measurement Protocol (OWAMP) 904 ITU-T Y.1731: Operations, administration and 905 maintenance (OAM) functions and mechanisms 906 for Ethernet-based networks"; 907 leaf packet-loss-count { 908 type yang:counter64; 909 description 910 "Total received packet drops count."; 911 } 912 leaf loss-ratio { 913 type percentage; 914 description 915 "Loss ratio of the packets. Express as percentage 916 of packets lost with respect to packets sent."; 917 } 918 } 919 } 921 grouping link-delay-statistics { 922 description 923 "Grouping for per link delay statistics."; 924 container delay-statistics { 925 description 926 "One-way link delay summarized information."; 927 reference 928 "RFC 4656: A One-way Active Measurement Protocol (OWAMP) 929 ITU-T Y.1731: Operations, administration and 930 maintenance (OAM) functions and mechanisms 931 for Ethernet-based networks"; 932 leaf unit-value { 933 type identityref { 934 base lime:time-unit-type; 935 } 936 default "lime:milliseconds"; 937 description 938 "Time units, where the options are s, ms, ns, etc."; 939 } 940 leaf min-delay-value { 941 type yang:gauge64; 942 description 943 "Minimum observed one-way delay."; 944 } 945 leaf max-delay-value { 946 type yang:gauge64; 947 description 948 "Maximum observed one-way delay."; 949 } 950 leaf low-delay-percentile { 951 type yang:gauge64; 952 description 953 "Low percentile of observed one-way delay with 954 specific measurement method."; 955 } 956 leaf intermediate-delay-percentile { 957 type yang:gauge64; 958 description 959 "Intermediate percentile of observed one-way delay with 960 specific measurement method."; 961 } 962 leaf high-delay-percentile { 963 type yang:gauge64; 964 description 965 "High percentile of observed one-way delay with 966 specific measurement method."; 967 } 968 } 969 } 971 grouping link-jitter-statistics { 972 description 973 "Grouping for per link jitter statistics."; 974 container jitter-statistics { 975 description 976 "One-way link jitter summarized information."; 977 reference 978 "RFC 3393: IP Packet Delay Variation Metric 979 for IP Performance Metrics (IPPM) 980 RFC 4656: A One-way Active Measurement Protocol (OWAMP) 981 ITU-T Y.1731: Operations, administration and 982 maintenance (OAM) functions and mechanisms 983 for Ethernet-based networks"; 984 leaf unit-value { 985 type identityref { 986 base lime:time-unit-type; 987 } 988 default "lime:milliseconds"; 989 description 990 "Time units, where the options are s, ms, ns, etc."; 991 } 992 leaf min-jitter-value { 993 type yang:gauge64; 994 description 995 "Minimum observed one-way jitter."; 996 } 997 leaf max-jitter-value { 998 type yang:gauge64; 999 description 1000 "Maximum observed one-way jitter."; 1001 } 1002 leaf low-jitter-percentile { 1003 type yang:gauge64; 1004 description 1005 "Low percentile of observed one-way jitter."; 1006 } 1007 leaf intermediate-jitter-percentile { 1008 type yang:gauge64; 1009 description 1010 "Intermediate percentile of observed one-way jitter."; 1011 } 1012 leaf high-jitter-percentile { 1013 type yang:gauge64; 1014 description 1015 "High percentile of observed one-way jitter."; 1016 } 1017 } 1018 } 1020 grouping tp-svc-telemetry { 1021 leaf reference-time { 1022 type yang:date-and-time; 1023 config false; 1024 description 1025 "Indicates the time when the statistics are collected."; 1026 } 1027 leaf inbound-octets { 1028 type yang:counter64; 1029 description 1030 "The total number of octets received on the 1031 interface, including framing characters."; 1032 } 1033 leaf inbound-unicast { 1034 type yang:counter64; 1035 description 1036 "The total number of inbound unicast packets."; 1038 } 1039 leaf inbound-nunicast { 1040 type yang:counter64; 1041 description 1042 "The total number of inbound non-unicast 1043 (i.e., broadcast or multicast) packets."; 1044 } 1045 leaf inbound-discards { 1046 type yang:counter64; 1047 description 1048 "The number of inbound packets that were chosen to be 1049 discarded even though no errors had been detected. 1050 Possible reasons for discarding such a packet could 1051 be to free up buffer space, not enough buffer for 1052 too much data, etc."; 1053 } 1054 leaf inbound-errors { 1055 type yang:counter64; 1056 description 1057 "The number of inbound packets that contained errors."; 1058 } 1059 leaf inbound-unknown-protocol { 1060 type yang:counter64; 1061 description 1062 "The number of packets received via the interface 1063 which were discarded because of an unknown or 1064 unsupported protocol."; 1065 } 1066 leaf outbound-octets { 1067 type yang:counter64; 1068 description 1069 "The total number of octets transmitted out of the 1070 interface, including framing characters."; 1071 } 1072 leaf outbound-unicast { 1073 type yang:counter64; 1074 description 1075 "The total number of outbound unicast packets."; 1076 } 1077 leaf outbound-nunicast { 1078 type yang:counter64; 1079 description 1080 "The total number of outbound non unicast 1081 (i.e., broadcast or multicast) packets."; 1082 } 1083 leaf outbound-discards { 1084 type yang:counter64; 1085 description 1086 "The number of outbound packets which were chosen 1087 to be discarded even though no errors had been 1088 detected to prevent their being transmitted. 1089 Possible reasons for discarding such a packet could 1090 be to free up buffer space, not enough buffer for 1091 too much data, etc."; 1092 } 1093 leaf outbound-errors { 1094 type yang:counter64; 1095 description 1096 "The number of outbound packets that contained 1097 errors."; 1098 } 1099 description 1100 "Grouping for interface service telemetry."; 1101 } 1103 augment "/nw:networks/nw:network/nw:network-types" { 1104 description 1105 "Defines the service topologies types."; 1106 container service-type { 1107 presence "Indicates network service topology."; 1108 leaf service-type { 1109 type identityref { 1110 base vpn-common:service-type; 1111 } 1112 description 1113 "The presence identifies the network service type, 1114 e.g., L3VPN, VPLS, etc."; 1115 } 1116 description 1117 "Container for VPN service type."; 1118 } 1119 } 1121 augment "/nw:networks/nw:network" { 1122 when 'nw:network-types/nvp:service-type' { 1123 description 1124 "Augments only for VPN Network topology."; 1125 } 1126 description 1127 "Augments the network with service topology attributes"; 1128 container vpn-pm-attributes { 1129 leaf vpn-id { 1130 type vpn-common:vpn-id; 1131 description 1132 "VPN identifier."; 1133 } 1134 leaf vpn-service-topology { 1135 type identityref { 1136 base vpn-common:vpn-topology; 1137 } 1138 description 1139 "VPN service topology, e.g., hub-spoke, any-to-any, 1140 hub-spoke-disjoint."; 1141 } 1142 description 1143 "Container for VPN topology attributes."; 1144 } 1145 } 1147 augment "/nw:networks/nw:network/nw:node" { 1148 description 1149 "Augments the network node with other general attributes."; 1150 container pm-attributes { 1151 leaf node-type { 1152 type identityref { 1153 base node-type; 1154 } 1155 description 1156 "Node type, e.g., PE, P, ASBR."; 1157 } 1158 description 1159 "Container for node attributes."; 1160 uses entry-summary; 1161 } 1162 } 1164 augment "/nw:networks/nw:network/nw:node/pm-attributes" { 1165 when '../../nw:network-types/nvp:service-type' { 1166 description 1167 "Augments only for VPN node attributes."; 1168 } 1169 description 1170 "Augments the network node with VPN specific attributes."; 1171 leaf role { 1172 type identityref { 1173 base vpn-common:role; 1174 } 1175 default "vpn-common:any-to-any-role"; 1176 description 1177 "Role of the node in the VPN."; 1178 } 1179 } 1181 augment "/nw:networks/nw:network/nt:link" { 1182 description 1183 "Augments the network topology link with performance 1184 monitoring attributes."; 1185 container pm-attributes { 1186 description 1187 "Container for PM attributes."; 1188 leaf low-percentile { 1189 type percentile; 1190 default "10.00"; 1191 description 1192 "Low percentile to report. Setting low-percentile 1193 into 0.00 indicates the client is not interested 1194 in receiving low percentile."; 1195 } 1196 leaf intermediate-percentile { 1197 type percentile; 1198 default "50.00"; 1199 description 1200 "Intermediate percentile to report. Setting 1201 intermediate-percentile into 0.00 indicates the client 1202 is not interested in receiving intermediate percentile."; 1203 } 1204 leaf high-percentile { 1205 type percentile; 1206 default "95.00"; 1207 description 1208 "High percentile to report. Setting high-percentile 1209 into 0.00 indicates the client is not interested in 1210 receiving high percentile."; 1211 } 1212 leaf measurement-interval { 1213 type uint32 { 1214 range "1..max"; 1215 } 1216 units "seconds"; 1217 default "60"; 1218 description 1219 "Indicates the time interval to perform PM measurement."; 1220 } 1221 leaf start-time { 1222 type yang:date-and-time; 1223 config false; 1224 description 1225 "The time that the current measurement started."; 1226 } 1227 leaf end-time { 1228 type yang:date-and-time; 1229 config false; 1230 description 1231 "The time that the current measurement ended."; 1232 } 1233 leaf pm-source { 1234 type identityref { 1235 base pm-source-type; 1236 } 1237 config false; 1238 description 1239 "The OAM tool used to collect the PM data."; 1240 } 1241 container one-way-pm-statistics { 1242 config false; 1243 description 1244 "Container for link telemetry attributes."; 1245 uses link-loss-statistics; 1246 uses link-delay-statistics; 1247 uses link-jitter-statistics; 1248 } 1249 list one-way-pm-statistics-per-class { 1250 key "class-id"; 1251 config false; 1252 description 1253 "The list of PM data based on class of service."; 1254 leaf class-id { 1255 type string; 1256 description 1257 "The class-id is used to identify the class of service. 1258 This identifier is internal to the administration."; 1259 } 1260 uses link-loss-statistics; 1261 uses link-delay-statistics; 1262 uses link-jitter-statistics; 1263 } 1264 } 1265 } 1267 augment "/nw:networks/nw:network/nt:link/pm-attributes" { 1268 when '../../nw:network-types/nvp:service-type' { 1269 description 1270 "Augments only for VPN Network topology."; 1271 } 1272 description 1273 "Augments the network topology link with VPN service 1274 performance monitoring attributes."; 1275 choice vpn-pm-type { 1276 description 1277 "The VPN PM type of this logical point-to-point 1278 unidirectional VPN link."; 1279 case inter-vpn-access-interface { 1280 leaf inter-vpn-access-interface { 1281 type empty; 1282 description 1283 "This is a placeholder for inter-vpn-access-interface PM, 1284 which is not bound to a specific VPN access interface. 1285 The source or destination VPN access interface 1286 of the measurement can be augmented as needed."; 1287 } 1288 } 1289 case underlay-tunnel { 1290 leaf vpn-underlay-transport-type { 1291 type identityref { 1292 base vpn-common:protocol-type; 1293 } 1294 config false; 1295 description 1296 "The leaf indicates the underlay transport type of 1297 a VPN service, e.g., GRE, LDP, etc."; 1298 } 1299 } 1300 } 1301 } 1303 augment "/nw:networks/nw:network/nw:node/nt:termination-point" { 1304 description 1305 "Augments the network topology termination point with 1306 performance monitoring attributes."; 1307 container pm-statistics { 1308 config false; 1309 description 1310 "Container for termination point PM attributes."; 1311 uses tp-svc-telemetry; 1312 } 1313 } 1315 augment "/nw:networks/nw:network/nw:node" 1316 + "/nt:termination-point/pm-statistics" { 1317 when '../../../nw:network-types/nvp:service-type' { 1318 description 1319 "Augments only for VPN Network topology."; 1320 } 1321 description 1322 "Augments the network topology termination-point with 1323 VPN service performance monitoring attributes"; 1324 list vpn-network-access { 1325 key "network-access-id"; 1326 description 1327 "The list of PM based on VPN network accesses."; 1328 leaf network-access-id { 1329 type vpn-common:vpn-id; 1330 description 1331 "References to an identifier for the VPN network 1332 access, e.g. L3VPN or VPLS."; 1333 } 1334 uses tp-svc-telemetry; 1335 } 1336 } 1337 } 1338 1340 6. Security Considerations 1342 The YANG modules defined in this document MAY be accessed via the 1343 RESTCONF protocol [RFC8040] or NETCONF protocol [RFC6241]. The 1344 lowest RESTCONF or NETCONF layer requires that the transport-layer 1345 protocol provides both data integrity and confidentiality, see 1346 Section 2 in [RFC8040] and [RFC6241]. The lowest NETCONF layer is 1347 the secure transport layer, and the mandatory-to-implement secure 1348 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1349 is HTTPS, and the mandatory-to-implement secure transport is TLS 1350 [RFC8446]. 1352 The NETCONF access control model [RFC8341] provides the means to 1353 restrict access for particular NETCONF or RESTCONF users to a 1354 preconfigured subset of all available NETCONF or RESTCONF protocol 1355 operations and content. 1357 There are a number of data nodes defined in this YANG module that are 1358 writable/creatable/deletable (i.e., config true, which is the 1359 default). These data nodes may be considered sensitive or vulnerable 1360 in some network environments. Write operations (e.g., edit-config) 1361 to these data nodes without proper protection can have a negative 1362 effect on network operations. These are the subtrees with the write 1363 operation that can be exploited to impact the network monitoring: 1365 * "/nw:networks/nw:network/nw:network-types" 1367 * "/nw:networks/nw:network/nvp:vpn-pm-attributes" 1369 * "/nw:networks/nw:network/nw:node/nvp:pm-attributes" 1371 * /nw:networks/nw:network/nt:link/nvp:pm-attributes" 1372 * /nw:networks/nw:network/nw:node/nt:termination-point/nvp:pm- 1373 statistics" 1375 Some of the readable data nodes in this YANG module may be considered 1376 sensitive or vulnerable in some network environments. The nodes 1377 reveals the quality of a service that is operated by an operator. It 1378 is thus important to control read access (e.g., via get, get-config, 1379 or notification) to these data nodes. These are the subtrees and 1380 data nodes and their sensitivity/vulnerability: 1382 * "/nw:networks/nw:network/nw:node/nvp:pm-attributes/nvp:vpn- 1383 summary-statistics": Unauthorized access to this subtree can 1384 disclose the operational state information of VPN instances. 1386 * "/nw:networks/nw:network/nt:link/nvp:pm-attributes/nvp:one-way-pm- 1387 statistics": Unauthorized access to this subtree can disclose the 1388 operational state information of network links or VPN abstract 1389 links. 1391 * "/nw:networks/nw:network/nw:node/nt:termination-point/nvp:pm- 1392 statistics": Unauthorized access to this subtree can disclose the 1393 operational state information of network termination points or VPN 1394 network accesses. 1396 7. IANA Considerations 1398 This document requests IANA to register the following URI in the "ns" 1399 subregistry within the "IETF XML Registry" [RFC3688]: 1401 URI: urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm 1402 Registrant Contact: The IESG. 1403 XML: N/A, the requested URI is an XML namespace. 1405 This document requests IANA to register the following YANG module in 1406 the "YANG Module Names" subregistry [RFC6020] within the "YANG 1407 Parameters" registry. 1409 Name: ietf-network-vpn-pm 1410 Namespace: urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm 1411 Maintained by IANA: N 1412 Prefix: nvp 1413 Reference: RFC XXXX (RFC Ed.: replace XXXX with actual 1414 RFC number and remove this note.) 1416 8. Acknowledgements 1418 Thanks to Joe Clarke, Adrian Farrel, Tom Petch, Greg Mirsky, Roque 1419 Gagliano, Erez Segev, and Dhruv Dhody for reviewing and providing 1420 important input to this document. 1422 9. Contributors 1424 The following authors contributed significantly to this document: 1426 Michale Wang 1427 Huawei 1428 Email:wangzitao@huawei.com 1430 Roni Even 1431 Huawei 1432 Email: ron.even.tlv@gmail.com 1434 Change Liu 1435 China Unicom 1436 Email: liuc131@chinaunicom.cn 1438 Honglei Xu 1439 China Telecom 1440 Email: xuhl.bri@chinatelecom.cn 1442 10. References 1444 10.1. Normative References 1446 [ITU-T-Y-1731] 1447 ITU-T, "Operator Ethernet Service Definition", August 1448 2015, . 1450 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1451 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1452 DOI 10.17487/RFC3393, November 2002, 1453 . 1455 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1456 DOI 10.17487/RFC3688, January 2004, 1457 . 1459 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 1460 Private Network (VPN) Terminology", RFC 4026, 1461 DOI 10.17487/RFC4026, March 2005, 1462 . 1464 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1465 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1466 2006, . 1468 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 1469 Zekauskas, "A One-way Active Measurement Protocol 1470 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 1471 . 1473 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 1474 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 1475 RFC 5357, DOI 10.17487/RFC5357, October 2008, 1476 . 1478 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1479 the Network Configuration Protocol (NETCONF)", RFC 6020, 1480 DOI 10.17487/RFC6020, October 2010, 1481 . 1483 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1484 and A. Bierman, Ed., "Network Configuration Protocol 1485 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1486 . 1488 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1489 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1490 . 1492 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 1493 Measurement for MPLS Networks", RFC 6374, 1494 DOI 10.17487/RFC6374, September 2011, 1495 . 1497 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1498 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1499 . 1501 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1502 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1503 . 1505 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1506 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1507 . 1509 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1510 Access Control Model", STD 91, RFC 8341, 1511 DOI 10.17487/RFC8341, March 2018, 1512 . 1514 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1515 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1516 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1517 2018, . 1519 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1520 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1521 . 1523 [RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S. 1524 Raghavan, "Generic YANG Data Model for the Management of 1525 Operations, Administration, and Maintenance (OAM) 1526 Protocols That Use Connectionless Communications", 1527 RFC 8532, DOI 10.17487/RFC8532, April 2019, 1528 . 1530 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 1531 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 1532 IGP Traffic Engineering Performance Metric Extensions", 1533 RFC 8571, DOI 10.17487/RFC8571, March 2019, 1534 . 1536 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1537 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1538 September 2019, . 1540 [RFC9181] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., 1541 Ed., and Q. Wu, "A Common YANG Data Model for Layer 2 and 1542 Layer 3 VPNs", RFC 9181, DOI 10.17487/RFC9181, February 1543 2022, . 1545 10.2. Informative References 1547 [I-D.ietf-netmod-node-tags] 1548 Wu, Q., Claise, B., Liu, P., Du, Z., and M. Boucadair, 1549 "Self-Describing Data Object Tags in YANG Data Models", 1550 Work in Progress, Internet-Draft, draft-ietf-netmod-node- 1551 tags-06, 21 February 2022, 1552 . 1555 [I-D.ietf-opsawg-l2nm] 1556 Boucadair, M., Dios, O. G. D., Barguil, S., and L. A. 1557 Munoz, "A YANG Network Data Model for Layer 2 VPNs", Work 1558 in Progress, Internet-Draft, draft-ietf-opsawg-l2nm-13, 14 1559 April 2022, . 1562 [I-D.ietf-opsawg-sap] 1563 Boucadair, M., Dios, O. G. D., Barguil, S., Wu, Q., and V. 1564 Lopez, "A Network YANG Model for Service Attachment Points 1565 (SAPs)", Work in Progress, Internet-Draft, draft-ietf- 1566 opsawg-sap-04, 11 April 2022, 1567 . 1570 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 1571 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 1572 . 1574 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1575 Previdi, "OSPF Traffic Engineering (TE) Metric 1576 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1577 . 1579 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1580 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1581 . 1583 [RFC8194] Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for 1584 LMAP Measurement Agents", RFC 8194, DOI 10.17487/RFC8194, 1585 August 2017, . 1587 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1588 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1589 . 1591 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 1592 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 1593 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 1594 2019, . 1596 [RFC8632] Vallin, S. and M. Bjorklund, "A YANG Data Model for Alarm 1597 Management", RFC 8632, DOI 10.17487/RFC8632, September 1598 2019, . 1600 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1601 E., and A. Tripathy, "Subscription to YANG Notifications", 1602 RFC 8639, DOI 10.17487/RFC8639, September 2019, 1603 . 1605 [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and 1606 L. Geng, "A Framework for Automating Service and Network 1607 Management with YANG", RFC 8969, DOI 10.17487/RFC8969, 1608 January 2021, . 1610 [RFC9182] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., 1611 Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model 1612 for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182, 1613 February 2022, . 1615 Appendix A. Illustrative Examples 1617 A.1. VPN Performance Subscription Example 1619 The example shown in Figure 8 illustrates how a client subscribes to 1620 the performance monitoring information between nodes ('node-id') A 1621 and B in the L3 network topology. The performance monitoring 1622 parameter that the client is interested in is end-to-end loss. 1624 POST /restconf/operations 1625 /ietf-subscribed-notifications:establish-subscription 1626 { 1627 "ietf-subscribed-notifications:input":{ 1628 "stream-subtree-filter":{ 1629 "ietf-network:networks":{ 1630 "network":{ 1631 "network-id":"foo:l3-network", 1632 "ietf-network-vpn-pm:service-type":{ 1633 "ietf-vpn-common:l3vpn":{} 1634 }, 1635 "node":[ 1636 { 1637 "node-id":"A", 1638 "ietf-network-vpn-pm:pm-attributes":{ 1639 "node-type":"PE" 1640 }, 1641 "termination-point":{ 1642 "tp-id":"1-0-1" 1643 } 1644 }, 1645 { 1646 "node-id":"B", 1647 "ietf-network-vpn-pm:pm-attributes":{ 1648 "node-type":"PE" 1649 }, 1650 "termination-point":{ 1651 "tp-id":"2-0-1" 1652 } 1653 } 1654 ], 1655 "ietf-network-topology:link":{ 1656 "link-id":"A-B", 1657 "source":{ 1658 "source-node":"A" 1659 }, 1660 "destination":{ 1661 "dest-node":"B" 1662 }, 1663 "ietf-network-vpn-pm:pm-attributes":{ 1664 "one-way-pm-statistics":{ 1665 "loss-statistics":{ 1666 "packet-loss-count":{} 1667 } 1668 }, 1669 "vpn-underlay-transport-type":"ietf-vpn-common:gre" 1670 } 1671 } 1672 } 1673 } 1674 }, 1675 "ietf-yang-push:periodic":{ 1676 "ietf-yang-push:period":"500" 1677 } 1678 } 1679 } 1681 Figure 8: Pub/Sub Retrieval 1683 A.2. Example of VPN Performance Snapshot 1685 This example, depicted in Figure 9, illustrates an VPN PM instance 1686 example in which a client uses RESTCONF [RFC8040] to fetch the 1687 performance data of the link and TP belonged to "VPN1". 1689 { 1690 "ietf-network:networks": { 1691 "network": { 1692 "network-id": "foo:vpn1", 1693 "node": [ 1694 { 1695 "node-id": "A", 1696 "ietf-network-vpn-pm:pm-attributes": { 1697 "node-type": "PE" 1698 }, 1699 "termination-point": { 1700 "tp-id": "1-0-1", 1701 "ietf-network-vpn-pm:pm-statistics": { 1702 "inbound-octets": "100", 1703 "outbound-octets": "150" 1704 } 1705 } 1706 }, 1707 { 1708 "node-id": "B", 1709 "ietf-network-vpn-pm:pm-attributes": { 1710 "node-type": "PE" 1711 }, 1712 "termination-point": { 1713 "tp-id": "2-0-1", 1714 "ietf-network-vpn-pm:pm-statistics": { 1715 "inbound-octets": "150", 1716 "outbound-octets": "100" 1717 } 1718 } 1719 } 1720 ], 1721 "ietf-network-topology:link": { 1722 "link-id": "A-B", 1723 "source": { "source-node": "A" }, 1724 "destination": { "dest-node": "B" }, 1725 "ietf-network-pm:pm-attributes": { 1726 "one-way-pm-statistics": { 1727 "loss-statistics": { "packet-loss-count": "120" } 1728 }, 1729 "vpn-underlay-transport-type": "ietf-vpn-common:gre" 1730 } 1731 } 1732 } 1733 } 1734 } 1736 Figure 9 1738 A.3. Example of Percentile Monitoring 1740 The following shows an example of a percentile measurement for a VPN 1741 link. 1743 { 1744 "ietf-network-topology:link": [ 1745 { 1746 "link-id": "foo:vpn1-link1", 1747 "source": { 1748 "source-node": "vpn-node1" 1749 }, 1750 "destination": { 1751 "dest-node": "vpn-node3" 1752 }, 1753 "ietf-network-vpn-pm:pm-attributes": { 1754 "low-percentile": "20.00", 1755 "intermediate-percentile": "50.00", 1756 "high-percentile": "90.00", 1757 "one-way-pm-statistics": { 1758 "delay-statistics": { 1759 "unit-value": "lime:milliseconds", 1760 "min-delay-value": "43", 1761 "max-delay-value": "99", 1762 "low-delay-percentile": "64", 1763 "intermediate-delay-percentile": "77", 1764 "high-delay-percentile": "98" 1765 } 1766 }, 1767 "inter-vpn-access-interface": [null] 1768 } 1769 } 1770 ] 1771 } 1773 Authors' Addresses 1775 Bo Wu (editor) 1776 Huawei 1777 101 Software Avenue, Yuhua District 1778 Nanjing 1779 Jiangsu, 210012 1780 China 1781 Email: lana.wubo@huawei.com 1782 Qin Wu (editor) 1783 Huawei 1784 101 Software Avenue, Yuhua District 1785 Nanjing 1786 Jiangsu, 210012 1787 China 1788 Email: bill.wu@huawei.com 1790 Mohamed Boucadair (editor) 1791 Orange 1792 Rennes 35000 1793 France 1794 Email: mohamed.boucadair@orange.com 1796 Oscar Gonzalez de Dios 1797 Telefonica 1798 Madrid 1799 Spain 1800 Email: oscar.gonzalezdedios@telefonica.com 1802 Bin Wen 1803 Comcast 1804 Email: bin_wen@comcast.com