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