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