idnits 2.17.1 draft-ietf-opsawg-yang-vpn-service-pm-03.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 1238: '...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 (29 January 2022) is 816 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 290, but not defined == Missing Reference: 'CE2' is mentioned on line 294, but not defined == Missing Reference: 'N4' is mentioned on line 294, but not defined == Missing Reference: 'N3' is mentioned on line 294, but not defined == Missing Reference: 'CE4' is mentioned on line 294, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-netmod-node-tags-04 == Outdated reference: A later version (-19) exists of draft-ietf-opsawg-l2nm-12 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). 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: 2 August 2022 M. Boucadair, Ed. 6 Orange 7 O. Gonzalez de Dios 8 Telefonica 9 B. Wen 10 Comcast 11 29 January 2022 13 A YANG Model for Network and VPN Service Performance Monitoring 14 draft-ietf-opsawg-yang-vpn-service-pm-03 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 2 August 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Network and VPN Service Performance Monitoring Model Usage . 4 63 3.1. Collecting Data via Pub/Sub Mechanism . . . . . . . . . . 5 64 3.2. Collecting Data On-demand . . . . . . . . . . . . . . . . 6 65 4. Description of The Data Model . . . . . . . . . . . . . . . . 6 66 4.1. Layering Relationship between Multiple Layers of 67 Topology . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.2. Network Level . . . . . . . . . . . . . . . . . . . . . . 8 69 4.3. Node Level . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.4. Link and Termination Point Level . . . . . . . . . . . . 9 71 5. Network and VPN Service Performance Monitoring YANG Module . 13 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 75 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 29 78 10.2. Informative References . . . . . . . . . . . . . . . . . 30 79 Appendix A. Illustrating Examples . . . . . . . . . . . . . . . 32 80 A.1. VPN Performance Subscription Example . . . . . . . . . . 32 81 A.2. Example of VPN Performance Snapshot . . . . . . . . . . . 33 82 A.3. Example of Percentile Monitoring . . . . . . . . . . . . 35 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 85 1. Introduction 87 [RFC8969] describes a framework for automating service and network 88 management with YANG models. It proposes that the performance 89 measurement telemetry model to be tied with the service, such as 90 Layer 3 VPN and Layer 2 VPN, or network models to monitor the overall 91 network performance or Service Level Agreements (SLA). 93 The performance of VPN services is associated with the performance 94 changes of the underlay network that carries VPN services, such as 95 the delay of the underlay tunnels and the packet loss status of the 96 device interfaces. Additionally, the integration of Layer 2/Layer 3 97 VPN performance and network performance data enables the orchestrator 98 to subscribe to VPN service performance in a unified manner. 99 Therefore, this document defines a YANG module for both network and 100 VPN service performance monitoring (PM). The module can be used to 101 monitor and manage network performance on the topology level or the 102 service topology between VPN sites, in particular. 104 This document does not introduce new metrics for network performance 105 or mechanisms for measuring network performance, but uses the 106 existing mechanisms and statistics to display the performance 107 monitoring statistics at the network and service layers. All these 108 metrics are defined as unidirectional metrics. 110 The YANG module defined in this document is designed as an 111 augmentation to the network topology YANG model defined in [RFC8345] 112 and draws on relevant YANG types defined in [RFC6991], [RFC8345], 113 [RFC8532], and [I-D.ietf-opsawg-vpn-common]. 115 Appendix A provides a set of examples to illustrate the use of the 116 module. 118 2. Terminology 120 The following terms are defined in [RFC7950] and are used in this 121 specification: 123 * augment 125 * data model 127 * data node 129 The terminology for describing YANG data models is found in 130 [RFC7950]. 132 The tree diagrams used in this document follow the notation defined 133 in [RFC8340]. 135 2.1. Acronyms 137 The following acronyms are used in the document: 139 L2VPN Layer 2 Virtual Private Network 140 L3VPN Layer 3 Virtual Private Network 141 L2NM L2VPN Network Model 142 L3NM L3VPN Network Model 143 MPLS Multiprotocol Label Switching 144 OAM Operations, Administration, and Maintenance 145 OWAMP One-Way Active Measurement Protocol 146 PE Provider Edge 147 PM Performance Monitoring 148 SLA Service Level Agreements 149 TE Traffic Engineering 150 TWAMP Two-Way Active Measurement Protocol 151 VPLS Virtual Private LAN Service 152 VPN Virtual Private Network 154 3. Network and VPN Service Performance Monitoring Model Usage 156 Models are key for automating network management operations. 157 According to [RFC8969], together with service and network models, 158 performance measurement telemetry models are needed to monitor 159 network performance to meet specific service requirements (typically 160 captured in an SLA). 162 +---------------+ 163 | Customer | 164 +-------+-------+ 165 | 166 Customer Service Models | 167 | 168 +-------+---------+ 169 | Service | 170 | Orchestration | 171 +------+-+--------+ 172 | | 173 Network Service Models | | Network and VPN Service PM Models 174 | | 175 +------+-+--------+ 176 | Network | 177 | Controller | 178 +-------+---------+ 179 | 180 +-----------------------+------------------------+ 181 Network 183 Figure 1: Reference Architecture 185 As shown in Figure 1, in the context of layering model architecture 186 described in [RFC8309], the network and VPN service performance 187 monitoring (PM) model can be used to expose a set of performance 188 information to the above layer. Such information can be used by an 189 orchestrator to subscribe to performance data. The network 190 controller will then notify the orchestrator about corresponding 191 parameter changes. 193 Before using the network and VPN service PM model, the mapping 194 between the VPN service topology and the underlying physical network 195 should be set up. 197 The YANG module defined in this document is designed to derive VPN or 198 network level performance data based on lower-level data collected 199 via monitoring counters of the involved devices. The performance 200 monitoring data per link in the underlying network can be collected 201 using a network performance measurement method such as One-Way Active 202 Measurement Protocol (OWAMP) [RFC4656], Two-Way Active Measurement 203 Protocol (TWAMP) [RFC5357], and Multiprotocol Label Switching (MPLS) 204 Loss and Delay Measurement [RFC6374]. The performance monitoring 205 information reflecting the quality of the network or VPN service 206 (e.g., end-to-end network performance data between source node and 207 destination node in the network or between VPN sites) can be computed 208 and aggregated, for example, using the information from the Traffic 209 Engineering Database (TED), [RFC7471] [RFC8570] [RFC8571] or LMAP 210 [RFC8194]. 212 The measurement and report intervals that are associated with these 213 performance data usually depend on the configuration of the specific 214 measurement method or collection method or various combinations. 215 This document defines a network-wide measurement interval to align 216 measurement requirements for networks or VPN services. 218 In addition, the amount of performance data collected from the 219 devices can be huge. To avoid receiving a large amount of 220 operational data of VPN instances, VPN interfaces, or tunnels, the 221 network controller can specifically subscribe to metric-specific data 222 using the tagging methods defined in [I-D.ietf-netmod-node-tags]. 224 3.1. Collecting Data via Pub/Sub Mechanism 226 Some applications such as service-assurance applications, which must 227 maintain a continuous view of operational data and state, can use the 228 subscription model specified in[RFC8641] to subscribe to the specific 229 network performance data or VPN service performance data they are 230 interested in, at the data source. 232 The data source can, then, use the network and VPN service assurance 233 model defined in this document and the YANG Push model [RFC8641] to 234 distribute specific telemetry data to target recipients. 236 3.2. Collecting Data On-demand 238 To obtain a snapshot of a large amount of performance data from a 239 network topology or VPN network, service-assurance applications may 240 retrieve information using the network and VPN service PM model 241 through a NETCONF [RFC6241] or a RESTCONF [RFC8040] interface. 243 4. Description of The Data Model 245 This document defines the YANG module, "ietf-network-vpn-pm", which 246 is an augmentation to the "ietf-network" and "ietf-network-topology". 248 The performance monitoring data augments the service topology as 249 shown in Figure 2. 251 +----------------------+ +-----------------------+ 252 |ietf-network | |Network and VPN Service| 253 |ietf-network-topology |<---------|Performance Monitoring | 254 +----------------------+ augments | Model | 255 +-----------------------+ 257 Figure 2: Module Augmentation 259 4.1. Layering Relationship between Multiple Layers of Topology 261 [RFC8345] defines a YANG data model for network/service topologies 262 and inventories. The service topology described in [RFC8345] 263 includes the virtual topology for a service layer above Layer 1 (L1), 264 Layer 2 (L2), and Layer 3 (L3). This service topology has the 265 generic topology elements of node, link, and terminating point. One 266 typical example of a service topology is described in Figure 3 of 267 [RFC8345]: two VPN service topologies instantiated over a common L3 268 topology. Each VPN service topology is mapped onto a subset of nodes 269 from the common L3 topology. 271 Figure 3 illustrates an example of a topology that maps between the 272 VPN service topology and an underlying network: 274 VPN 1 VPN 2 275 +-----------------------+ +---------------------+ 276 / / / / 277 /S1C_[VN3]::: / /S2A S2B / 278 / \ ::::: / / _[VN1]______[VN3]_ / 279 / \ : / / : : / Overlay 280 / \ :: : : : : : : / 281 /S1B_[VN2]____[VN1]_S1A / / : : : / 282 +--------:-------:------+ +---:----:----------:-+ 283 : : :: : : : : 284 : : : : : 285 Site-1A : +-------:--: ----- -------- : -------:-----+ Site-1C 286 [CE1]___: /__ ___ [N1]__________________ [N2]__ :___ /__[CE3] 287 :/ / / \ _____/ / : / 288 [CE5]___ : ___ / / \ _____/ / :: / 289 Site-2A /: / \ / / : / 290 / : [N5] / : / Underlay Network 291 / : / __/ \__ / : / 292 / : / ___/ \__ / : / 293 Site-1B / : / ___/ \ / : / Site-2B 294 [CE2]_ /________[N4]_________________ [N3]:::_____/____[CE4] 295 +------------------------------------------+ 297 Legend: 298 N:node VN:VPN-Node S:Site 299 __ Link 300 : Mapping between networks 302 Figure 3: Example of Topology Mapping Between VPN Service 303 Topology and Underlying Network 305 As shown in Figure 3, two VPN services topologies are both built on 306 top of one common underlying physical network: 308 VPN 1: This service topology supports hub-spoke communications for 309 'customer 1' connecting the customer's access at three sites: 310 'Site-1A', 'Site-1B', and 'Site-1C'. These sites are connected to 311 nodes that are mapped to node 1 (N1), node 2 (N2), and node 4 (N4) 312 in the underlying physical network. 'Site-1A' plays the role of 313 hub while 'Site-1B' and 'Site-1C' are configured as spoke. 315 VPN 2: This service supports any-to-any communications for 'customer 316 2' connecting the customer's access at two sites: 'Site-2A' and 317 'Site-2B'. These sites are connected to nodes that are mapped to 318 nodes 1 (N1) and node 3 (N3)5 in the underlying physical network. 319 'Site-2A' and 'Site-2B' have 'any-to-any' role. 321 4.2. Network Level 323 For network performance monitoring, the container of "networks" in 324 [RFC8345] does not need to be extended. 326 For VPN service performance monitoring, the container "service-type" 327 is defined to indicate the VPN type, e.g., L3VPN or Virtual Private 328 LAN Service (VPLS). The values are taken from 329 [I-D.ietf-opsawg-vpn-common]. When a network topology instance 330 contains the L3VPN or other L2VPN network type, it represents a VPN 331 instance that can perform performance monitoring. 333 The tree in Figure 4 is a part of ietf-network-vpn-pm tree. It 334 defines the following set of network level attributes: 336 "vpn-id": Refers to an identifier of VPN service defined in 337 [I-D.ietf-opsawg-vpn-common]). This identifier is used to 338 correlate the performance status with the network service 339 configuration. 341 "vpn-service-topology": Indicates the type of the VPN topology. 342 This model supports "any-to-any", "Hub and Spoke" (where Hubs can 343 exchange traffic), and "Hub and Spoke disjoint" (where Hubs cannot 344 exchange traffic) that are taken from 345 [I-D.ietf-opsawg-vpn-common]. These VPN topology types can be 346 used to describe how VPN sites communicate with each other. 348 module: ietf-network-vpn-pm 349 augment /nw:networks/nw:network/nw:network-types: 350 +--rw service-type! 351 +--rw service-type? identityref 352 augment /nw:networks/nw:network: 353 +--rw vpn-pm-attributes 354 +--rw vpn-id? vpn-common:vpn-id 355 +--rw vpn-service-topology? identityref 357 Figure 4: Network Level YANG Tree of the Hierarchies 359 4.3. Node Level 361 The tree in Figure 5 is the node part of ietf-network-vpn-pm tree. 363 For network performance monitoring, a container of "pm-attributes" is 364 augmented to the list of "node" that are defined in [RFC8345]. The 365 "node-type" indicates the device type of Provider Edge (PE), Provider 366 (P) device, or Autonomous System Border Router (ASBR), so that the 367 performance metric between any two nodes each with specific node type 368 can be reported. 370 For VPN service performance monitoring, the model defines the 371 following minimal set of node level network topology attributes: 373 "role": Defines the role in a particular VPN service topology. The 374 roles are taken from [I-D.ietf-opsawg-vpn-common] (e.g., any-to- 375 any-role, spoke-role, hub-role). 377 "vpn-summary-statistics": Lists a set of IPv4 statistics, IPv6 378 statistics, and MAC statistics. These statistics are specified 379 separately. 381 augment /nw:networks/nw:network/nw:node: 382 +--rw pm-attributes 383 +--rw node-type? identityref 384 +--rw role? identityref 385 +--ro vpn-summary-statistics 386 +--ro ipv4 387 | +--ro maximum-routes? uint32 388 | +--ro total-active-routes? uint32 389 +--ro ipv6 390 | +--ro maximum-routes? uint32 391 | +--ro total-active-routes? uint32 392 +--ro mac-num 393 +--ro mac-num-limit? uint32 394 +--ro total-active-mac-num? uint32 396 Figure 5: Node Level YANG Tree of the Hierarchies 398 4.4. Link and Termination Point Level 400 The tree in Figure 6 is the link and termination point (TP) part of 401 ietf-network-vpn-pm tree. 403 The 'links' are classified into two types: topology link defined in 404 [RFC8345] and abstract link of a VPN between PEs. 406 The performance data of a link is a collection of counters that 407 report the performance status. 409 augment /nw:networks/nw:network/nt:link: 410 +--rw pm-attributes 411 +--rw low-percentile? percentile 412 +--rw intermediate-percentile? percentile 413 +--rw high-percentile? percentile 414 +--rw measurement-interval? uint32 415 +--ro start-time? yang:date-and-time 416 +--ro end-time? yang:date-and-time 417 +--ro pm-source? identityref 418 +--ro one-way-pm-statistics 419 | +--ro loss-statistics 420 | | +--ro packet-loss-count? yang:counter64 421 | | +--ro loss-ratio? percentage 422 | +--ro delay-statistics 423 | | +--ro unit-value? identityref 424 | | +--ro min-delay-value? yang:gauge64 425 | | +--ro max-delay-value? yang:gauge64 426 | | +--ro low-delay-percentile? yang:gauge64 427 | | +--ro intermediate-delay-percentile? yang:gauge64 428 | | +--ro high-delay-percentile? yang:gauge64 429 | +--ro jitter-statistics 430 | +--ro unit-value? identityref 431 | +--ro min-jitter-value? yang:gauge32 432 | +--ro max-jitter-value? yang:gauge32 433 | +--ro low-jitter-percentile? yang:gauge32 434 | +--ro intermediate-jitter-percentile? yang:gauge32 435 | +--ro high-jitter-percentile? yang:gauge32 436 +--ro vpn-underlay-transport-type? identityref 437 +--ro vpn-one-way-pm-statistics* [class-id] 438 +--ro class-id string 439 +--ro loss-statistics 440 | +--ro packet-loss-count? yang:counter64 441 | +--ro loss-ratio? percentage 442 +--ro delay-statistics 443 | +--ro unit-value? identityref 444 | +--ro min-delay-value? yang:gauge64 445 | +--ro max-delay-value? yang:gauge64 446 | +--ro low-delay-percentile? yang:gauge64 447 | +--ro intermediate-delay-percentile? yang:gauge64 448 | +--ro high-delay-percentile? yang:gauge64 449 +--ro jitter-statistics 450 +--ro unit-value? identityref 451 +--ro min-jitter-value? yang:gauge32 452 +--ro max-jitter-value? yang:gauge32 453 +--ro low-jitter-percentile? yang:gauge32 454 +--ro intermediate-jitter-percentile? yang:gauge32 455 +--ro high-jitter-percentile? yang:gauge32 457 augment /nw:networks/nw:network/nw:node/nt:termination-point: 458 +--ro pm-statistics 459 +--ro reference-time? yang:date-and-time 460 +--ro inbound-octets? yang:counter64 461 +--ro inbound-unicast? yang:counter64 462 +--ro inbound-nunicast? yang:counter64 463 +--ro inbound-discards? yang:counter32 464 +--ro inbound-errors? yang:counter64 465 +--ro inbound-unknown-protocol? yang:counter64 466 +--ro outbound-octets? yang:counter64 467 +--ro outbound-unicast? yang:counter64 468 +--ro outbound-nunicast? yang:counter64 469 +--ro outbound-discards? yang:counter64 470 +--ro outbound-errors? yang:counter64 471 +--ro vpn-network-access* [network-access-id] 472 +--ro network-access-id vpn-common:vpn-id 473 +--ro reference-time? yang:date-and-time 474 +--ro inbound-octets? yang:counter64 475 +--ro inbound-unicast? yang:counter64 476 +--ro inbound-nunicast? yang:counter64 477 +--ro inbound-discards? yang:counter32 478 +--ro inbound-errors? yang:counter64 479 +--ro inbound-unknown-protocol? yang:counter64 480 +--ro outbound-octets? yang:counter64 481 +--ro outbound-unicast? yang:counter64 482 +--ro outbound-nunicast? yang:counter64 483 +--ro outbound-discards? yang:counter64 484 +--ro outbound-errors? yang:counter64 486 Figure 6: Link and Termination point Level YANG Tree of the 487 hierarchies 489 For the data nodes of 'link' depicted in Figure 6, the YANG module 490 defines the following minimal set of link-level performance 491 attributes: 493 Percentile parameters: The module supports reporting delay and 494 jitter metric by percentile values. By default, low percentile 495 (10th percentile), intermediate percentile (50th percentile), high 496 percentile (90th percentile) are used. Setting a percentile to 497 0.00 indicates the client is not interested in receiving 498 particular percentile. If all percentile nodes are set to 0.00, 499 this represents that no percentile related nodes will be reported 500 for a given performance metric (e.g., one-way delay, one-way delay 501 variation) and only peak/min values will be reported. For 502 example, a client can inform the server that it is interested in 503 receiving only high percentiles. Then for a given link, at a 504 given "start-time", "end-time" and "measurement-interval", the 505 'high-delay-percentile' and 'high-jitter-percentile' will be 506 reported. An example to illustrate the use of percentiles is 507 provided in Appendix A.3. 509 PM source ("pm-source"): Indicates the performance monitoring 510 source. The data for the topology link can be based, e.g., on 511 BGP-LS [RFC8571]. The statistics of the VPN abstract links can be 512 collected based upon VPN OAM mechanisms, e.g.,OAM mechanisms 513 referenced in [I-D.ietf-opsawg-l3sm-l3nm], or Ethernet service OAM 514 [ITU-T-Y-1731] referenced in [I-D.ietf-opsawg-l2nm]. 515 Alternatively, the data can be based upon the underlay technology 516 OAM mechanisms, for example, Generic Routing Encapsulation (GRE) 517 tunnel OAM. 519 Measurement interval ("measurement-interval"): Specifies the 520 performance measurement interval, in seconds. 522 Start time ("start-time"): Indicates the start time of the 523 performance measurement for link statistics. 525 End time ("end-time"): Indicates the end time of the performance 526 measurement for link statistics. 528 Reference time ("reference-time"): Indicates the timestamp when the 529 counters are obtained. 531 Loss statistics: A set of one-way loss statistics attributes that 532 are used to measure end to end loss between VPN sites or between 533 any two network nodes. The exact loss value or the loss 534 percentage can be reported. 536 Delay statistics: A set of one-way delay statistics attributes that 537 are used to measure end to end latency between VPN sites or 538 between any two network nodes. The peak/min values or percentile 539 values can be reported. 541 Jitter statistics: A set of one-way IP Packet Delay Variation 542 [RFC3393] statistics attributes that are used to measure end to 543 end jitter between VPN sites or between any two network nodes. 544 The peak/min values or percentile values can be reported. 546 VPN underlay transport type ("vpn-underlay-transport-type"): Indicat 547 es the abstract link protocol-type of a VPN, such as GRE or IP-in- 548 IP. The leaf refers to an identifier of the "underlay-transport" 549 defined in [I-D.ietf-opsawg-vpn-common], which describes the 550 transport technology to carry the traffic of the VPN service. 552 VPN PM statistics ("vpn-unidirectional-pm-statistics"): Lists 553 performance measurement statistics for the abstract underlay link 554 between VPN PEs with given "class-id" names. The list is defined 555 separately from "one-way-pm-statistics", which is used to collect 556 generic metrics for unspecified "class-id" names. 558 For the data nodes of 'termination-point' depicted in Figure 6, the 559 module defines the following minimal set of statistics: 561 Inbound statistics: A set of inbound statistics attributes that are 562 used to measure the inbound statistics of the termination point, 563 such as received packets, received packets with errors, etc. 565 Outbound statistics: A set of outbound statistics attributes that 566 are used to measure the outbound statistics of the termination 567 point, such as sent packets, packets that could not be sent due to 568 errors, etc. 570 VPN network access ("vpn-network-access"): Lists counters of the VPN 571 network access defined in [I-D.ietf-opsawg-l3sm-l3nm] or 572 [I-D.ietf-opsawg-l2nm]. When multiple VPN network accesses are 573 created using the same physical port, finer-grained metrics can be 574 monitored. 576 5. Network and VPN Service Performance Monitoring YANG Module 578 The "ietf-network-vpn-pm" module uses types defined in [RFC8345], 579 [RFC6991], [RFC8532], and [I-D.ietf-opsawg-vpn-common]. 581 file "ietf-network-vpn-pm@2021-01-28.yang" 582 module ietf-network-vpn-pm { 583 yang-version 1.1; 584 namespace "urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm"; 585 prefix nvp; 587 import ietf-yang-types { 588 prefix yang; 589 reference 590 "RFC 6991: Common YANG Types"; 591 } 592 import ietf-vpn-common { 593 prefix vpn-common; 594 reference 595 "RFC CCCC: A Layer 2/3 VPN Common YANG Model."; 596 // RFC Ed.: replace CCCC with actual RFC number and remove 597 // this note. 598 } 599 import ietf-network { 600 prefix nw; 601 reference 602 "RFC 8345: A YANG Data Model for Network 603 Topologies, Section 6.1"; 604 } 605 import ietf-network-topology { 606 prefix nt; 607 reference 608 "RFC 8345: A YANG Data Model for Network 609 Topologies, Section 6.2"; 610 } 611 import ietf-lime-time-types { 612 prefix lime; 613 reference 614 "RFC 8532: Generic YANG Data Model for the Management of 615 Operations, Administration, and Maintenance (OAM) Protocols 616 That Use Connectionless Communications"; 617 } 619 organization 620 "IETF OPSAWG Working Group"; 621 contact 622 "Editor: Qin Wu 623 624 Editor: Bo Wu 625 626 Editor: Mohamed Boucadair 627 "; 628 description 629 "This module defines a model for Network and VPN Service 630 Performance monitoring. 632 Copyright (c) 2022 IETF Trust and the persons identified as 633 authors of the code. All rights reserved. 635 Redistribution and use in source and binary forms, with or 636 without modification, is permitted pursuant to, and subject to 637 the license terms contained in, the Simplified BSD License set 638 forth in Section 4.c of the IETF Trust's Legal Provisions 639 Relating to IETF Documents 640 (https://trustee.ietf.org/license-info). 642 This version of this YANG module is part of RFC XXXX 643 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 644 for full legal notices."; 646 // RFC Ed.: update the date below with the date of RFC 647 // publication and remove this note. 648 // RFC Ed.: replace XXXX with actual RFC number and remove 649 // this note. 651 revision 2022-01-28 { 652 description 653 "Initial revision."; 654 reference 655 "RFC XXXX: A YANG Model for Network and VPN Service 656 Performance Monitoring"; 658 } 660 identity node-type { 661 description 662 "Base identity for node type"; 663 } 665 identity pe { 666 base node-type; 667 description 668 "Provider Edge (PE) node type."; 669 reference 670 "RFC 4026: Provider Provisioned 671 Virtual Private Network (VPN) Terminology"; 672 } 674 identity p { 675 base node-type; 676 description 677 "Provider router node type."; 678 reference 679 "RFC 4026: Provider Provisioned 680 Virtual Private Network (VPN) Terminology"; 681 } 683 identity asbr { 684 base node-type; 685 description 686 "Autonomous System Border Router (ASBR) node type."; 687 reference 688 "RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs)"; 689 } 691 identity pm-source-type { 692 description 693 "Base identity from which specific performance monitoring 694 mechanism types are derived."; 695 } 697 identity pm-source-bgpls { 698 base pm-source-type; 699 description 700 "Indicates BGP-LS as the performance monitoring metric source"; 701 reference 702 "RFC 8571: BGP - Link State (BGP-LS) Advertisement of 703 IGP Traffic Engineering Performance Metric Extensions"; 704 } 705 identity pm-source-owamp { 706 base pm-source-type; 707 description 708 "Indicates One-Way Active Measurement Protocol(OWAMP) 709 as the performance monitoring metric source."; 710 reference 711 "RFC 4656: A One-Way Active Measurement Protocol (OWAMP)"; 712 } 714 identity pm-source-twamp { 715 base pm-source-type; 716 description 717 "Indicates Two-Way Active Measurement Protocol(TWAMP) 718 as the performance monitoring metric source."; 719 reference 720 "RFC 5357: A Two-Way Active Measurement Protocol (TWAMP)"; 721 } 723 identity pm-source-y-1731 { 724 base pm-source-type; 725 description 726 "Indicates Ethernet OAM Y.1731 as the performance monitoring 727 metric source."; 728 reference 729 "ITU-T Y.1731: Operations, administration and 730 maintenance (OAM) functions and mechanisms 731 for Ethernet-based networks"; 732 } 734 typedef percentage { 735 type decimal64 { 736 fraction-digits 5; 737 range "0..100"; 738 } 739 description 740 "Percentage."; 741 } 743 typedef percentile { 744 type decimal64 { 745 fraction-digits 2; 746 range "0..100"; 747 } 748 description 749 "The percentile is a value between 0 and 100, 750 e.g. 10.00, 99.90 ,99.99 etc.. 751 For example, for a given one-way delay measurement, 752 if the percentile is set to 95.00 and 753 the 95th percentile one-way delay is 2 milliseconds, 754 then the 95 percent of the sample value 755 is less than or equal to 2 milliseconds."; 756 } 758 grouping vpn-summary-statistics { 759 description 760 "VPN Statistics grouping used for network topology 761 augmentation."; 762 container vpn-summary-statistics { 763 config false; 764 description 765 "Container for VPN summary statistics."; 766 container ipv4 { 767 leaf maximum-routes { 768 type uint32; 769 description 770 "Indicates the maximum number of IPv4 routes 771 for the VPN."; 772 } 773 leaf total-active-routes { 774 type uint32; 775 description 776 "Indicates total active IPv4 routes for the VPN."; 777 } 778 description 779 "IPv4-specific parameters."; 780 } 781 container ipv6 { 782 leaf maximum-routes { 783 type uint32; 784 description 785 "Indicates the maximum number of IPv6 routes 786 for the VPN."; 787 } 788 leaf total-active-routes { 789 type uint32; 790 description 791 "Indicates total active IPv6 routes for the VPN."; 792 } 793 description 794 "IPv6-specific parameters."; 795 } 796 container mac-num { 797 leaf mac-num-limit { 798 type uint32; 799 description 800 "Maximum number of MAC addresses."; 802 } 803 leaf total-active-mac-num { 804 type uint32; 805 description 806 "Total active MAC entries for the VPN."; 807 } 808 description 809 "MAC statistics."; 810 } 811 } 812 } 814 grouping link-loss-statistics { 815 description 816 "Grouping for per link error statistics."; 817 container loss-statistics { 818 description 819 "Link loss summarized information. By default, 820 one way measurement protocol (e.g., OWAMP) is used 821 to measure one-way packet loss."; 822 reference 823 "RFC 4656: A One-way Active Measurement Protocol (OWAMP)"; 824 leaf packet-loss-count { 825 type yang:counter64; 826 description 827 "Total received packet drops count."; 828 } 829 leaf loss-ratio { 830 type percentage; 831 description 832 "Loss ratio of the packets. Express as percentage 833 of packets lost with respect to packets sent."; 834 } 835 } 836 } 838 grouping link-delay-statistics { 839 description 840 "Grouping for per link delay statistics."; 841 container delay-statistics { 842 description 843 "Link delay summarized information. By default, 844 one way measurement protocol (e.g., OWAMP) is used 845 to measure delay."; 846 reference 847 "RFC 4656: A One-way Active Measurement Protocol (OWAMP)"; 848 leaf unit-value { 849 type identityref { 850 base lime:time-unit-type; 851 } 852 default "lime:milliseconds"; 853 description 854 "Time units, where the options are s, ms, ns, etc."; 855 } 856 leaf min-delay-value { 857 type yang:gauge64; 858 description 859 "Minimum observed one-way delay."; 860 } 861 leaf max-delay-value { 862 type yang:gauge64; 863 description 864 "Maximum observed one-way delay."; 865 } 866 leaf low-delay-percentile { 867 type yang:gauge64; 868 description 869 "Low percentile of observed one-way delay with 870 specific measurement method."; 871 } 872 leaf intermediate-delay-percentile { 873 type yang:gauge64; 874 description 875 "Intermediate percentile of observed one-way delay with 876 specific measurement method."; 877 } 878 leaf high-delay-percentile { 879 type yang:gauge64; 880 description 881 "High percentile of observed one-way delay with 882 specific measurement method."; 883 } 884 } 885 } 887 grouping link-jitter-statistics { 888 description 889 "Grouping for per link jitter statistics."; 890 container jitter-statistics { 891 description 892 "Link jitter summarized information. By default, 893 jitter is measured using one-way IP Packet 894 Delay Variation (IPDV)."; 895 reference 896 "RFC 3393: IP Packet Delay Variation Metric 897 for IP Performance Metrics (IPPM)"; 899 leaf unit-value { 900 type identityref { 901 base lime:time-unit-type; 902 } 903 default "lime:milliseconds"; 904 description 905 "Time units, where the options are s, ms, ns, etc."; 906 } 907 leaf min-jitter-value { 908 type yang:gauge32; 909 description 910 "Minimum observed one-way jitter."; 911 } 912 leaf max-jitter-value { 913 type yang:gauge32; 914 description 915 "Maximum observed one-way jitter."; 916 } 917 leaf low-jitter-percentile { 918 type yang:gauge32; 919 description 920 "Low percentile of observed one-way jitter."; 921 } 922 leaf intermediate-jitter-percentile { 923 type yang:gauge32; 924 description 925 "Intermediate percentile of observed one-way jitter."; 926 } 927 leaf high-jitter-percentile { 928 type yang:gauge32; 929 description 930 "High percentile of observed one-way jitter."; 931 } 932 } 933 } 935 grouping tp-svc-telemetry { 936 leaf reference-time { 937 type yang:date-and-time; 938 config false; 939 description 940 "Indicates the time when the statistics are collected."; 941 } 942 leaf inbound-octets { 943 type yang:counter64; 944 description 945 "The total number of octets received on the 946 interface, including framing characters."; 948 } 949 leaf inbound-unicast { 950 type yang:counter64; 951 description 952 "The total number of inbound unicast packets."; 953 } 954 leaf inbound-nunicast { 955 type yang:counter64; 956 description 957 "The total number of non-unicast 958 (i.e., broadcast or multicast) packets."; 959 } 960 leaf inbound-discards { 961 type yang:counter32; 962 description 963 "The number of inbound packets that were chosen to be 964 discarded even though no errors had been detected. 965 One possible reason for discarding such a 966 packet could be to free up buffer space"; 967 } 968 leaf inbound-errors { 969 type yang:counter64; 970 description 971 "The number of inbound packets that contained errors."; 972 } 973 leaf inbound-unknown-protocol { 974 type yang:counter64; 975 description 976 "The number of packets received via the interface 977 which were discarded because of an unknown or 978 unsupported protocol."; 979 } 980 leaf outbound-octets { 981 type yang:counter64; 982 description 983 "The total number of octets transmitted out of the 984 interface, including framing characters."; 985 } 986 leaf outbound-unicast { 987 type yang:counter64; 988 description 989 "The total number of outbound unicast packets."; 990 } 991 leaf outbound-nunicast { 992 type yang:counter64; 993 description 994 "The total number of outbound non unicast 995 (i.e., broadcast or multicast) packets."; 997 } 998 leaf outbound-discards { 999 type yang:counter64; 1000 description 1001 "The number of outbound packets which were chosen 1002 to be discarded even though no errors had been 1003 detected to prevent their being transmitted. 1004 One possible reason for discarding such a packet could 1005 be to free up buffer space."; 1006 } 1007 leaf outbound-errors { 1008 type yang:counter64; 1009 description 1010 "The number of outbound packets that contained 1011 errors."; 1012 } 1013 description 1014 "Grouping for interface service telemetry."; 1015 } 1017 augment "/nw:networks/nw:network/nw:network-types" { 1018 description 1019 "Defines the service topologies types."; 1020 container service-type { 1021 presence "Indicates network service topology."; 1022 leaf service-type { 1023 type identityref { 1024 base vpn-common:service-type; 1025 } 1026 description 1027 "The presence identifies the network service type, 1028 e.g., L3VPN, VPLS, etc."; 1029 } 1030 description 1031 "Container for VPN service type."; 1032 } 1033 } 1035 augment "/nw:networks/nw:network" { 1036 when 'nw:network-types/nvp:service-type' { 1037 description 1038 "Augments only for VPN Network topology."; 1039 } 1040 description 1041 "Augments the network with service topology attributes"; 1042 container vpn-pm-attributes { 1043 leaf vpn-id { 1044 type vpn-common:vpn-id; 1045 description 1046 "VPN identifier."; 1047 } 1048 leaf vpn-service-topology { 1049 type identityref { 1050 base vpn-common:vpn-topology; 1051 } 1052 description 1053 "VPN service topology, e.g., hub-spoke, any-to-any, 1054 hub-spoke-disjoint."; 1055 } 1056 description 1057 "Container for VPN topology attributes."; 1058 } 1059 } 1061 augment "/nw:networks/nw:network/nw:node" { 1062 description 1063 "Augments the network node with other general attributes."; 1064 container pm-attributes { 1065 leaf node-type { 1066 type identityref { 1067 base node-type; 1068 } 1069 description 1070 "Node type, e.g., PE, P, ASBR."; 1071 } 1072 description 1073 "Container for node attributes."; 1074 } 1075 } 1077 augment "/nw:networks/nw:network/nw:node/pm-attributes" { 1078 when '../../nw:network-types/nvp:service-type' { 1079 description 1080 "Augments only for VPN node attributes."; 1081 } 1082 description 1083 "Augments the network node with VPN specific attributes."; 1084 leaf role { 1085 type identityref { 1086 base vpn-common:role; 1087 } 1088 default "vpn-common:any-to-any-role"; 1089 description 1090 "Role of the node in the VPN."; 1091 } 1092 uses vpn-summary-statistics; 1094 } 1096 augment "/nw:networks/nw:network/nt:link" { 1097 description 1098 "Augments the network topology link with performance 1099 monitoring attributes."; 1100 container pm-attributes { 1101 description 1102 "Container for PM attributes."; 1103 leaf low-percentile { 1104 type percentile; 1105 default "10.00"; 1106 description 1107 "Low percentile to report. Setting low-percentile 1108 into 0.00 indicates the client is not interested 1109 in receiving low percentile."; 1110 } 1111 leaf intermediate-percentile { 1112 type percentile; 1113 default "50.00"; 1114 description 1115 "Intermediate percentile to report. Setting 1116 intermediate-percentile into 0.00 indicates the client 1117 is not interested in receiving intermediate percentile."; 1118 } 1119 leaf high-percentile { 1120 type percentile; 1121 default "95.00"; 1122 description 1123 "High percentile to report. Setting high-percentile 1124 into 0.00 indicates the client is not interested in 1125 receiving high percentile."; 1126 } 1127 leaf measurement-interval { 1128 type uint32; 1129 units "seconds"; 1130 default "60"; 1131 description 1132 "Indicates the time interval to perform PM measurement."; 1133 } 1134 leaf start-time { 1135 type yang:date-and-time; 1136 config false; 1137 description 1138 "The time that the current measurement started."; 1139 } 1140 leaf end-time { 1141 type yang:date-and-time; 1142 config false; 1143 description 1144 "The time that the current measurement ended."; 1145 } 1146 leaf pm-source { 1147 type identityref { 1148 base pm-source-type; 1149 } 1150 config false; 1151 description 1152 "The OAM tool used to collect the PM data."; 1153 } 1154 container one-way-pm-statistics { 1155 config false; 1156 description 1157 "Container for link telemetry attributes."; 1158 uses link-loss-statistics; 1159 uses link-delay-statistics; 1160 uses link-jitter-statistics; 1161 } 1162 } 1163 } 1165 augment "/nw:networks/nw:network/nt:link/pm-attributes" { 1166 when '../../nw:network-types/nvp:service-type' { 1167 description 1168 "Augments only for VPN Network topology."; 1169 } 1170 description 1171 "Augments the network topology link with VPN service 1172 performance monitoring attributes."; 1173 leaf vpn-underlay-transport-type { 1174 type identityref { 1175 base vpn-common:protocol-type; 1176 } 1177 config false; 1178 description 1179 "The leaf indicates the underlay transport type of 1180 a VPN service, e.g., GRE, LDP, etc."; 1181 } 1182 list vpn-one-way-pm-statistics { 1183 key "class-id"; 1184 config false; 1185 description 1186 "The list of PM data based on class of service."; 1187 leaf class-id { 1188 type string; 1189 description 1190 "The class-id is used to identify the class of service. 1191 This identifier is internal to the administration."; 1192 } 1193 uses link-loss-statistics; 1194 uses link-delay-statistics; 1195 uses link-jitter-statistics; 1196 } 1197 } 1199 augment "/nw:networks/nw:network/nw:node/nt:termination-point" { 1200 description 1201 "Augments the network topology termination point with 1202 performance monitoring attributes."; 1203 container pm-statistics { 1204 config false; 1205 description 1206 "Container for termination point PM attributes."; 1207 uses tp-svc-telemetry; 1208 } 1209 } 1211 augment "/nw:networks/nw:network/nw:node" 1212 + "/nt:termination-point/pm-statistics" { 1213 when '../../../nw:network-types/nvp:service-type' { 1214 description 1215 "Augments only for VPN Network topology."; 1216 } 1217 description 1218 "Augments the network topology termination-point with 1219 VPN service performance monitoring attributes"; 1220 list vpn-network-access { 1221 key "network-access-id"; 1222 description 1223 "The list of PM based on VPN network accesses."; 1224 leaf network-access-id { 1225 type vpn-common:vpn-id; 1226 description 1227 "References to an identifier for the VPN network 1228 access, e.g. L3VPN or VPLS."; 1229 } 1230 uses tp-svc-telemetry; 1231 } 1232 } 1233 } 1234 1236 6. Security Considerations 1238 The YANG modules defined in this document MAY be accessed via the 1239 RESTCONF protocol [RFC8040] or NETCONF protocol [RFC6241]. The 1240 lowest RESTCONF or NETCONF layer requires that the transport-layer 1241 protocol provides both data integrity and confidentiality, see 1242 Section 2 in [RFC8040] and [RFC6241]. The lowest NETCONF layer is 1243 the secure transport layer, and the mandatory-to-implement secure 1244 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1245 is HTTPS, and the mandatory-to-implement secure transport is TLS 1246 [RFC8446]. 1248 The NETCONF access control model [RFC8341] provides the means to 1249 restrict access for particular NETCONF or RESTCONF users to a 1250 preconfigured subset of all available NETCONF or RESTCONF protocol 1251 operations and content. 1253 There are a number of data nodes defined in this YANG module that are 1254 writable/creatable/deletable (i.e., config true, which is the 1255 default). These data nodes may be considered sensitive or vulnerable 1256 in some network environments. Write operations (e.g., edit-config) 1257 to these data nodes without proper protection can have a negative 1258 effect on network operations. These are the subtrees with the write 1259 operation that can be exploited to impact the network monitoring: 1261 * "/nw:networks/nw:network/nw:network-types" 1263 * "/nw:networks/nw:network/nvp:vpn-pm-attributes" 1265 * "/nw:networks/nw:network/nw:node/nvp:pm-attributes" 1267 * /nw:networks/nw:network/nt:link/nvp:pm-attributes" 1269 Some of the readable data nodes in this YANG module may be considered 1270 sensitive or vulnerable in some network environments. The nodes 1271 reveals the quality of a service that is operated by an operator. It 1272 is thus important to control read access (e.g., via get, get-config, 1273 or notification) to these data nodes. These are the subtrees and 1274 data nodes and their sensitivity/vulnerability: 1276 * "/nw:networks/nw:network/nw:node/nvp:pm-attributes/nvp:vpn- 1277 summary-statistics": Unauthorized access to this subtree can 1278 disclose the operational state information of VPN instances. 1280 * "/nw:networks/nw:network/nt:link/nvp:pm-attributes/nvp:one-way-pm- 1281 statistics": Unauthorized access to this subtree can disclose the 1282 operational state information of network links or VPN underlay 1283 tunnels. 1285 * "/nw:networks/nw:network/nw:node/nt:termination-point/nvp:pm- 1286 statistics": Unauthorized access to this subtree can disclose the 1287 operational state information of network termination points or VPN 1288 network accesses. 1290 7. IANA Considerations 1292 This document requests IANA to register the following URI in the "ns" 1293 subregistry within the "IETF XML Registry" [RFC3688]: 1295 URI: urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm 1296 Registrant Contact: The IESG. 1297 XML: N/A, the requested URI is an XML namespace. 1299 This document requests IANA to register the following YANG module in 1300 the "YANG Module Names" subregistry [RFC6020] within the "YANG 1301 Parameters" registry. 1303 Name: ietf-network-vpn-pm 1304 Namespace: urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm 1305 Maintained by IANA: N 1306 Prefix: nvp 1307 Reference: RFC XXXX (RFC Ed.: replace XXXX with actual 1308 RFC number and remove this note.) 1310 8. Acknowledgements 1312 Thanks to Joe Clarke, Adrian Farrel, Greg Mirsky, Roque Gagliano, 1313 Erez Segev, and Dhruv Dhody for reviewing and providing important 1314 input to this document. 1316 9. Contributors 1318 The following authors contributed significantly to this document: 1320 Michale Wang 1321 Huawei 1322 Email:wangzitao@huawei.com 1324 Roni Even 1325 Huawei 1326 Email: ron.even.tlv@gmail.com 1328 Change Liu 1329 China Unicom 1330 Email: liuc131@chinaunicom.cn 1332 Honglei Xu 1333 China Telecom 1334 Email: xuhl.bri@chinatelecom.cn 1336 10. References 1338 10.1. Normative References 1340 [I-D.ietf-opsawg-vpn-common] 1341 Barguil, S., Dios, O. G. D., Boucadair, M., and Q. Wu, "A 1342 Layer 2/3 VPN Common YANG Model", Work in Progress, 1343 Internet-Draft, draft-ietf-opsawg-vpn-common-12, 29 1344 September 2021, . 1347 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1348 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1349 DOI 10.17487/RFC3393, November 2002, 1350 . 1352 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1353 DOI 10.17487/RFC3688, January 2004, 1354 . 1356 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1357 the Network Configuration Protocol (NETCONF)", RFC 6020, 1358 DOI 10.17487/RFC6020, October 2010, 1359 . 1361 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1362 and A. Bierman, Ed., "Network Configuration Protocol 1363 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1364 . 1366 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1367 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1368 . 1370 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 1371 Measurement for MPLS Networks", RFC 6374, 1372 DOI 10.17487/RFC6374, September 2011, 1373 . 1375 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1376 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1377 . 1379 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1380 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1381 . 1383 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1384 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1385 . 1387 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1388 Access Control Model", STD 91, RFC 8341, 1389 DOI 10.17487/RFC8341, March 2018, 1390 . 1392 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1393 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1394 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1395 2018, . 1397 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1398 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1399 . 1401 [RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S. 1402 Raghavan, "Generic YANG Data Model for the Management of 1403 Operations, Administration, and Maintenance (OAM) 1404 Protocols That Use Connectionless Communications", 1405 RFC 8532, DOI 10.17487/RFC8532, April 2019, 1406 . 1408 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1409 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1410 September 2019, . 1412 10.2. Informative References 1414 [I-D.ietf-netmod-node-tags] 1415 Wu, Q., Claise, B., Liu, P., Du, Z., and M. Boucadair, 1416 "Self Describing Data Object Tags", Work in Progress, 1417 Internet-Draft, draft-ietf-netmod-node-tags-04, 11 1418 November 2021, . 1421 [I-D.ietf-opsawg-l2nm] 1422 Barguil, S., Dios, O. G. D., Boucadair, M., and L. A. 1423 Munoz, "A Layer 2 VPN Network YANG Model", Work in 1424 Progress, Internet-Draft, draft-ietf-opsawg-l2nm-12, 22 1425 November 2021, . 1428 [I-D.ietf-opsawg-l3sm-l3nm] 1429 Barguil, S., Dios, O. G. D., Boucadair, M., Munoz, L. A., 1430 and A. Aguado, "A Layer 3 VPN Network YANG Model", Work in 1431 Progress, Internet-Draft, draft-ietf-opsawg-l3sm-l3nm-18, 1432 8 October 2021, . 1435 [ITU-T-Y-1731] 1436 ITU-T, "Operator Ethernet Service Definition", August 1437 2015, . 1439 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 1440 Zekauskas, "A One-way Active Measurement Protocol 1441 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 1442 . 1444 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 1445 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 1446 RFC 5357, DOI 10.17487/RFC5357, October 2008, 1447 . 1449 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1450 Previdi, "OSPF Traffic Engineering (TE) Metric 1451 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1452 . 1454 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1455 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1456 . 1458 [RFC8194] Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for 1459 LMAP Measurement Agents", RFC 8194, DOI 10.17487/RFC8194, 1460 August 2017, . 1462 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1463 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1464 . 1466 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 1467 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 1468 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 1469 2019, . 1471 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 1472 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 1473 IGP Traffic Engineering Performance Metric Extensions", 1474 RFC 8571, DOI 10.17487/RFC8571, March 2019, 1475 . 1477 [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and 1478 L. Geng, "A Framework for Automating Service and Network 1479 Management with YANG", RFC 8969, DOI 10.17487/RFC8969, 1480 January 2021, . 1482 Appendix A. Illustrating Examples 1484 A.1. VPN Performance Subscription Example 1486 The example shown in Figure 7 illustrates how a client subscribes to 1487 the performance monitoring information between nodes ('node-id') A 1488 and B in the L3 network topology. The performance monitoring 1489 parameter that the client is interested in is end-to-end loss. 1491 POST /restconf/operations 1492 /ietf-subscribed-notifications:establish-subscription 1493 { 1494 "ietf-subscribed-notifications:input":{ 1495 "stream-subtree-filter":{ 1496 "ietf-network-topo:networks":{ 1497 "network":{ 1498 "network-id":"l3-network", 1499 "ietf-network-vpn-pm:service-type":{ 1500 "ietf-vpn-common:l3vpn":{} 1501 }, 1502 "node":[ 1503 { 1504 "node-id":"A", 1505 "ietf-network-vpn-pm:pm-attributes":{ 1506 "node-type":"PE" 1507 }, 1508 "termination-point":{ 1509 "tp-id":"1-0-1", 1510 } 1511 }, 1512 { 1513 "node-id":"B", 1514 "ietf-network-vpn-pm:pm-attributes":{ 1515 "node-type":"PE" 1516 }, 1517 "termination-point":{ 1518 "tp-id":"2-0-1", 1519 } 1520 } 1521 ], 1522 "link":{ 1523 "link-id":"A-B", 1524 "source":{ 1525 "source-node":"A" 1526 }, 1527 "destination":{ 1528 "dest-node":"B" 1529 }, 1530 "ietf-network-vpn-pm:pm-attributes":{ 1531 "one-way-pm-statistics":{ 1532 "loss-statistics":{ 1533 "packet-loss-count":{} 1534 } 1535 }, 1536 "vpn-underlay-transport-type":"ietf-vpn-common:gre" 1537 } 1538 } 1539 } 1540 } 1541 }, 1542 "ietf-yang-push:periodic":{ 1543 "ietf-yang-push:period":"500" 1544 } 1545 } 1546 } 1548 Figure 7: Pub/Sub Retrieval 1550 A.2. Example of VPN Performance Snapshot 1552 This example, depicted in Figure 8, illustrates an VPN PM instance 1553 example in which a client uses RESTCONF [RFC8040] to fetch the 1554 performance data of the link and TP belonged to "VPN1". 1556 { 1557 "ietf-network-topo:networks": { 1558 "network": { 1559 "network-id": "vpn1", 1560 "node": [ 1561 { 1562 "node-id": "A", 1563 "ietf-network-vpn-pm:pm-attributes": { 1564 "node-type": "PE" 1565 }, 1566 "termination-point": { 1567 "tp-id": "1-0-1", 1568 "ietf-network-vpn-pm:pm-statistics": { 1569 "inbound-octets": "100", 1570 "outbound-octets": "150" 1571 } 1572 } 1573 }, 1574 { 1575 "node-id": "B", 1576 "ietf-network-vpn-pm:pm-attributes": { 1577 "node-type": "PE" 1578 }, 1579 "termination-point": { 1580 "tp-id": "2-0-1", 1581 "ietf-network-vpn-pm:pm-statistics": { 1582 "inbound-octets": "150", 1583 "outbound-octets": "100" 1584 } 1585 } 1586 } 1587 ], 1588 "link": { 1589 "link-id": "A-B", 1590 "source": { "source-node": "A" }, 1591 "destination": { "dest-node": "B" }, 1592 "ietf-network-pm:pm-attributes": { 1593 "one-way-pm-statistics": { 1594 "loss-statistics": { "packet-loss-count": "120" } 1595 }, 1596 "vpn-underlay-transport-type": "ietf-vpn-common:gre" 1597 }, 1598 } 1599 } 1600 } 1601 } 1603 Figure 8 1605 A.3. Example of Percentile Monitoring 1607 The following shows an example of a percentile measurement for a VPN 1608 link. 1610 { 1611 "ietf-network-topology:link":[ 1612 { 1613 "link-id":"vpn1-link1", 1614 "source":{ 1615 "source-node":"vpn-node1" 1616 }, 1617 "destination":{ 1618 "dest-node":"vpn-node3" 1619 }, 1620 "ietf-network-vpn-pm:pm-attributes":{ 1621 "low-percentile":"20.00", 1622 "middle-percentile":"50.00", 1623 "high-percentile":"90.00", 1624 "one-way-pm-statistics:delay-statistics":{ 1625 "unit-values":"lime:milliseconds", 1626 "min-delay-value":"43", 1627 "max-delay-value":"99", 1628 "low-delay-percentile":"64", 1629 "middle-delay-percentile":"77", 1630 "high-delay-percentile":"98" 1631 }, 1632 "ietf-network-vpn-pm:vpn-underlay-transport-type": 1633 "ietf-vpn-common:gre", 1634 } 1635 } 1636 ] 1637 } 1639 Authors' Addresses 1641 Bo Wu (editor) 1642 Huawei 1643 101 Software Avenue, Yuhua District 1644 Nanjing 1645 Jiangsu, 210012 1646 China 1648 Email: lana.wubo@huawei.com 1649 Qin Wu (editor) 1650 Huawei 1651 101 Software Avenue, Yuhua District 1652 Nanjing 1653 Jiangsu, 210012 1654 China 1656 Email: bill.wu@huawei.com 1658 Mohamed Boucadair (editor) 1659 Orange 1660 Rennes 35000 1661 France 1663 Email: mohamed.boucadair@orange.com 1665 Oscar Gonzalez de Dios 1666 Telefonica 1667 Madrid 1668 Spain 1670 Email: oscar.gonzalezdedios@telefonica.com 1672 Bin Wen 1673 Comcast 1675 Email: bin_wen@comcast.com