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