idnits 2.17.1 draft-ietf-opsawg-yang-vpn-service-pm-01.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 1 character 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 (July 6, 2021) is 1018 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 253, but not defined == Missing Reference: 'CE2' is mentioned on line 257, but not defined == Missing Reference: 'N4' is mentioned on line 257, but not defined == Missing Reference: 'N3' is mentioned on line 257, but not defined == Missing Reference: 'CE4' is mentioned on line 257, but not defined == Unused Reference: 'RFC5357' is defined on line 1207, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-opsawg-vpn-common-07 == Outdated reference: A later version (-19) exists of draft-ietf-opsawg-l2nm-02 == Outdated reference: A later version (-18) exists of draft-ietf-opsawg-l3sm-l3nm-08 Summary: 1 error (**), 0 flaws (~~), 10 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: January 7, 2022 M. Boucadair, Ed. 6 Orange 7 O. Gonzalez de Dios 8 Telefonica 9 B. Wen 10 Comcast 11 C. Liu 12 China Unicom 13 H. Xu 14 China Telecom 15 July 6, 2021 17 A YANG Model for Network and VPN Service Performance Monitoring 18 draft-ietf-opsawg-yang-vpn-service-pm-01 20 Abstract 22 The data model defined in RFC 8345 introduces vertical layering 23 relationships between networks that can be augmented to cover network 24 and service topologies. This document defines a YANG module for both 25 network performance monitoring (PM) and VPN service performance 26 monitoring that can be used to monitor and manage network performance 27 on the topology at higher layer or the service topology between VPN 28 sites. 30 The YANG model defined in this document is designed as an 31 augmentation to the network topology YANG model defined in RFC 8345 32 and draws on relevant YANG types defined in RFC 6991, RFC 8345, and 33 RFC 8532. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 7, 2022. 51 Copyright Notice 53 Copyright (c) 2021 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Network and VPN Service Performance Monitoring Model Usage . 3 71 3.1. Collecting Data via Pub/Sub Mechanism . . . . . . . . . . 5 72 3.2. Collecting Data via Retrieval Methods . . . . . . . . . . 5 73 4. Description of The Data Model . . . . . . . . . . . . . . . . 5 74 4.1. Layering Relationship between Multiple Layers of Topology 5 75 4.2. Network Level . . . . . . . . . . . . . . . . . . . . . . 7 76 4.3. Node Level . . . . . . . . . . . . . . . . . . . . . . . 7 77 4.4. Link and Termination Point Level . . . . . . . . . . . . 8 78 5. Network and VPN Service Performance Monitoring YANG Module . 11 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 82 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 24 85 10.2. Informative References . . . . . . . . . . . . . . . . . 26 86 Appendix A. Illustrating Examples . . . . . . . . . . . . . . . 27 87 A.1. Example of Pub/Sub Retrieval . . . . . . . . . . . . . . 27 88 A.2. Example of RPC-based Retrieval . . . . . . . . . . . . . 29 89 A.3. Example of Percentile Monitoring . . . . . . . . . . . . 30 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 92 1. Introduction 94 [RFC8969] describes a framework for automating service and network 95 management with YANG models, proposing the performance measurement 96 telemetry model to be tied with the service, such as Layer 3 VPN and 97 Layer 2 VPN, or network models to monitor the overall network 98 performance or Service Level Agreements (SLA). 100 This document defines a YANG module [RFC7950] for both network 101 performance monitoring and VPN service performance monitoring. This 102 module can be used to monitor and manage network performance on the 103 topology level or the service topology between VPN sites, in 104 particular. 106 This document does not introduce new metrics for network performance 107 or mechanisms for measuring network performance, but uses the 108 existing mechanisms and statistics to show the performance monitoring 109 statistics at the network and service layers. The YANG module 110 defined in this document is designed as an augmentation to the 111 network topology YANG model defined in [RFC8345]. 113 This document uses the common VPN YANG module defined in 114 [I-D.ietf-opsawg-vpn-common]. 116 Appendix A provides a set of examples to illustrate the use of the 117 module. 119 2. Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in BCP 124 14 [RFC2119][RFC8174] when, and only when, they appear in all 125 capitals, as shown here. 127 Tree diagrams used in this document follow the notation defined in 128 [RFC8340]. 130 3. Network and VPN Service Performance Monitoring Model Usage 132 Models are key for automating network management operations. 133 According to [RFC8969], together with service and network models, 134 performance measurement telemetry models are needed to monitor 135 network performance to meet specific service requirements (typically 136 captured in an SLA). The YANG module defined in this document is 137 designed to derive VPN or network level performance data based on 138 lower-level data collected via monitoring counters of the involved 139 devices. 141 +---------------+ 142 | Customer | 143 +-------+-------+ 144 | 145 Customer Service Models | 146 | 147 +-------+---------+ 148 | Service | 149 | Orchestration | 150 +------+-+--------+ 151 | | 152 Network Service Models | | Network and VPN Service PM Models 153 | | 154 +------+-+--------+ 155 | Network | 156 | Controller | 157 +-------+---------+ 158 | 159 +-----------------------+------------------------+ 160 Network 162 Figure 1: Reference Architecture 164 As shown in Figure 1, in the context of layering model architecture 165 described in [RFC8309], the network and VPN service performance 166 monitoring (PM) model can be used to expose some performance 167 information to the above layer. Such an information can be used by 168 an orchestrator to subscribe to performance data. The network 169 controller will then notify the orchestrator about corresponding 170 parameter changes. 172 Before using the network and VPN service PM model, the mapping 173 between the VPN service topology and the underlying physical network 174 should be setup. Also, the performance monitoring data per link in 175 the underlying network can be collected using network performance 176 measurement method such as MPLS Loss and Delay Measurement [RFC6374]. 178 The performance monitoring information reflecting the quality of the 179 network or VPN service (e.g., end to end network performance data 180 between source node and destination node in the network or between 181 VPN sites) can be computed and aggregated, for example, the 182 information from Traffic Engineering Database (TED), defined in 183 [RFC7471], [RFC8570], or [RFC8571] or LMAP [RFC8194]. 185 The measurement and report intervals that are associated with these 186 performance data usually depend on the configuration parameters. 188 3.1. Collecting Data via Pub/Sub Mechanism 190 Some applications such as service-assurance applications, which must 191 maintain a continuous view of operational data and state, can use the 192 subscription model [RFC8641] to subscribe to the specific network 193 performance data or VPN service performance data they are interested 194 in, at the data source. 196 The data source can, then, use the network and VPN service assurance 197 model defined in this document and the YANG Push model [RFC8641] to 198 distribute specific telemetry data to target recipients. 200 3.2. Collecting Data via Retrieval Methods 202 To obtain a snapshot of a large amount of performance data from a 203 network element (including network controllers), service-assurance 204 applications may use methods such as retrieving performance data or 205 RPC commands defined as part of YANG models. 207 4. Description of The Data Model 209 This document defines the YANG module, "ietf-network-vpn-pm", which 210 is an augmentation to the "ietf-network" and "ietf-network-topology". 212 The performance monitoring data augments the service topology as 213 shown in Figure 2. 215 +----------------------+ +-----------------------+ 216 |ietf-network | |Network and VPN Service| 217 |ietf-network-topology |<---------|Performance Monitoring | 218 +----------------------+ augments | Model | 219 +-----------------------+ 221 Figure 2: Module Augmentation 223 4.1. Layering Relationship between Multiple Layers of Topology 225 [RFC8345] defines a YANG data model for network/service topologies 226 and inventories. The service topology described in [RFC8345] 227 includes the virtual topology for a service layer above Layer 1 (L1), 228 Layer 2 (L2), and Layer 3 (L3). This service topology has the 229 generic topology elements of node, link, and terminating point. One 230 typical example of a service topology is described in Figure 3 of 231 [RFC8345]: two VPN service topologies instantiated over a common L3 232 topology. Each VPN service topology is mapped onto a subset of nodes 233 from the common L3 topology. 235 Figure 3 illustrates an example of a topology that maps between the 236 VPN service topology and an underlying network: 238 VPN 1 VPN 2 239 +-----------------------+ +---------------------+ 240 /S1C-[VN3]... / /S2A S2B / 241 / / \ ::::: / / -[VN1]______[VN3]- / 242 / / \ : / / : : / 243 / / \ S1A :: : : : : : : / 244 /S1B-[VN2]____[VN1]-- / / : : : / 245 +--------:-------:------+ +---:----:----------:-+ 246 : : :: : : : : 247 : : : : : 248 Site-1A : +-------:--: ----- -------- : -------:-----+ Site-1C 249 [CE1]___: /__ ___ [N1]__________________ [N2]__ :___ /__[CE3] 250 :/ / / \ _____/ / : / 251 [CE5]___ : ___ / / \ _____/ / :: / 252 Site-2A /: / \ / / : / 253 / : [N5] / : / 254 / : / __/ \__ / : / 255 / : / ___/ \__ / : / 256 Site-1B / : / ___/ \ / : / Site-2B 257 [CE2]-/------- [N4]_________________ [N3]:::-----/----[CE4] 258 +------------------------------------------+ 260 Legend: N:node VN:VPN-Node 262 Figure 3: Example of Topology Mapping Between VPN Service Topology 263 and Underlying Network 265 As shown in Figure 3, two VPN services topologies are both built on 266 top of one common underlying physical network: 268 VPN 1: This service topology supports hub-spoke communications for 269 'customer 1' connecting the customer's access at three sites: 270 'Site-1A', 'Site-1B', and 'Site-1C'. These sites are connected to 271 nodes that are mapped to node 1 (N1), node 2 (N2), and node 4 (N4) 272 in the underlying physical network. 'Site-1A' plays the role of 273 hub while 'Site-1B' and 'Site-1C' are configured as spoke. 275 VPN 2: This service supports any-to-any communications for 276 'customer 2' connecting the customer's access at two sites: 'Site- 277 2A' and 'Site-2B'. These sites are connected to nodes that are 278 mapped to nodes 1 (N1) and node 3 (N3)5 in the underlying physical 279 network. 'Site-2A' and 'Site-2B' have 'any-to-any' role. 281 4.2. Network Level 283 For network performance monitoring, the container of "networks" in 284 [RFC8345] do not need to be extended. 286 For VPN service performance monitoring, the container "service-type" 287 is defined to indicate the VPN type, e.g., L3VPN or Virtual Private 288 LAN Service (VPLS). The values are taken from 289 [I-D.ietf-opsawg-vpn-common]. When a network topology instance 290 contains the L3VPN or other L2VPN network type, it represents a VPN 291 instance that can perform performance monitoring. 293 This model defines the following set of network level attributes: 295 "vpn-id": Refers to an identifier of VPN service defined in 296 [I-D.ietf-opsawg-vpn-common]). This identifier is used to 297 correlate the performance status with the network service 298 configuration. 300 "vpn-service-topology": Indicates the type of VPN topology. This 301 model supports "any-to-any", "Hub and Spoke" (where Hubs can 302 exchange traffic), and "Hub and Spoke disjoint" (where Hubs cannot 303 exchange traffic) that are taken from 304 [I-D.ietf-opsawg-vpn-common]. These VPN topology types can be 305 used to describe how VPN sites communicate with each other. 307 module: ietf-network-vpn-pm 308 augment /nw:networks/nw:network/nw:network-types: 309 +--rw service-type! 310 +--rw service-type? identityref 311 augment /nw:networks/nw:network: 312 +--rw vpn-pm-attributes 313 +--rw vpn-id? vpn-common:vpn-id 314 +--rw vpn-service-topology? identityref 316 Figure 4: Network Level View of the Hierarchies 318 4.3. Node Level 320 For network performance monitoring, a container of "pm-attributes" is 321 augmented to the list of "node" that are defined in [RFC8345]. And 322 the leaf of "node-type" indicates the device type of Provider Edge 323 (PE), Provider (P) device, or Autonomous System Border Router (ASBR), 324 so that the performance metric between any two nodes each with 325 specific node type can be reported. 327 For VPN service performance monitoring, this model defines only the 328 following minimal set of node level network topology attributes: 330 "role": Defines the role in a particular VPN service topology. The 331 roles are taken from [I-D.ietf-opsawg-vpn-common] (e.g., any-to- 332 any-role, spoke-role, hub-role). 334 "vpn-summary-statistics": Lists a set of IPv4 statistics, IPv6 335 statistics, and MAC statistics. These statistics are specified 336 separately. 338 augment /nw:networks/nw:network/nw:node: 339 +--rw pm-attributes 340 +--rw node-type? identityref 341 +--rw role? identityref 342 +--ro vpn-summary-statistics 343 +--ro ipv4 344 | +--ro maximum-routes? uint32 345 | +--ro total-active-routes? uint32 346 +--ro ipv6 347 | +--ro maximum-routes? uint32 348 | +--ro total-active-routes? uint32 349 +--ro mac-num 350 +--ro mac-num-limit? uint32 351 +--ro total-active-mac-num? uint32 353 Figure 5: Node Level View of the Hierarchies 355 4.4. Link and Termination Point Level 357 The 'links' are classified into two types: topology link defined in 358 [RFC8345] and abstract link of a VPN between PEs. 360 The performance data of a link is a collection of counters that 361 report the performance status. 363 augment /nw:networks/nw:network/nt:link: 364 +--rw pm-attributes 365 +--rw low-percentile? percentile 366 +--rw middle-percentile? percentile 367 +--rw high-percentile? percentile 368 +--ro pm-source? string 369 +--ro reference-time? yang:date-and-time 370 +--ro measurement-interval? uint32 371 +--ro pm-statistics 372 | +--ro loss-statistics 373 | | +--ro packet-loss-count? yang:counter64 374 | | +--ro packet-reorder-count? yang:counter64 375 | | +--ro packets-out-of-seq-count? yang:counter64 376 | | +--ro packets-dup-count? yang:counter64 377 | | +--ro loss-ratio? percentage 378 | +--ro delay-statistics 379 | | +--ro direction? identityref 380 | | +--ro unit-value? identityref 381 | | +--ro min-delay-value? yang:gauge64 382 | | +--ro max-delay-value? yang:gauge64 383 | | +--ro low-delay-percentile? yang:gauge64 384 | | +--ro middle-delay-percentile? yang:gauge64 385 | | +--ro high-delay-percentile? yang:gauge64 386 | +--ro jitter-statistics 387 | +--ro unit-value? identityref 388 | +--ro min-jitter-value? yang:gauge32 389 | +--ro max-jitter-value? yang:gauge32 390 | +--ro low-jitter-percentile? yang:gauge32 391 | +--ro middle-jitter-percentile? yang:gauge32 392 | +--ro high-jitter-percentile? yang:gauge32 393 +--ro protocol-type? identityref 394 augment /nw:networks/nw:network/nw:node/nt:termination-point: 395 +--ro pm-statistics 396 +--ro inbound-octets? yang:counter64 397 +--ro inbound-unicast? yang:counter64 398 +--ro inbound-nunicast? yang:counter64 399 +--ro inbound-discards? yang:counter32 400 +--ro inbound-errors? yang:counter64 401 +--ro inbound-unknown-protocol? yang:counter64 402 +--ro outbound-octets? yang:counter64 403 +--ro outbound-unicast? yang:counter64 404 +--ro outbound-nunicast? yang:counter64 405 +--ro outbound-discards? yang:counter64 406 +--ro outbound-errors? yang:counter64 408 Figure 6: Link and Termination point Level View of the hierarchies 410 For the data nodes of 'link' depicted in Figure 6, the YANG module 411 defines the following minimal set of link-level performance 412 attributes: 414 Percentile parameters: The module supports reporting delay and 415 jitter metric by percentile values. By default, low percentile 416 (10th percentile), mid percentile (50th percentile), high 417 percentile (90th percentile) are used. Setting a percentile into 418 0.00 indicates the client is not interested in receiving 419 particular percentile. If all percentile nodes are set to 0.00, 420 this represents that no percentile related nodes will be reported 421 for a given performance metric (e.g. one-way delay, one-way delay 422 variation) and only peak/min values will be reported. For 423 example, a client can inform the server that it is interested in 424 receiving only high percentiles. Then for a given link, at a 425 given "reference-time" "measurement-interval", the 'high-delay- 426 percentile' and 'high-jitter-percentile' will be reported. An 427 example to illustrate the use of percentiles is provided in 428 Appendix A.3. 430 "pm-source": Indicates the performance monitoring source. The data 431 for the topology link can be based, e.g., on BGP-LS [RFC8571]. 432 The statistics of the VPN abstract links can be collected based 433 upon VPN OAM mechanisms, e.g., OAM mechanisms specified in 434 [I-D.ietf-opsawg-l3sm-l3nm], or Ethernet service OAM specified in 435 [I-D.ietf-opsawg-l2nm]. Alternatively, the data can be based upon 436 the underlay technology OAM mechanisms, for example, GRE tunnel 437 OAM. 439 Loss Statistics: A set of loss statistics attributes that are used 440 to measure end to end loss between VPN sites or between any two 441 network nodes. The exact loss value or the loss percentage can be 442 reported. 444 Delay Statistics: A set of delay statistics attributes that are used 445 to measure end to end latency between VPN sites or between any two 446 network nodes. The peak/min values or percentile values can be 447 reported. 449 Jitter Statistics: A set of IP Packet Delay Variation [RFC3393] 450 statistics attributes that are used to measure end to end jitter 451 between VPN sites or between any two network nodes. The peak/min 452 values or percentile values can be reported. 454 "protocol-type": Indicates the abstract link protocol-type of a VPN, 455 such as GRE or IP-in-IP. The leaf refers to an identifier of the 456 "underlay-transport" defined in [I-D.ietf-opsawg-vpn-common], 457 which describes the transport technology to carry the traffic of 458 the VPN service. 460 For the data nodes of 'termination-point' depicted in Figure 6, the 461 module defines the following minimal set of statistics: 463 Inbound statistics: A set of inbound statistics attributes that are 464 used to measure the inbound statistics of the termination point, 465 such as received packets, received packets with errors, etc. 467 Outbound statistics: A set of outbound statistics attributes that 468 are used to measure the outbound statistics of the termination 469 point, such as sent packets, packets that could not be sent due to 470 errors, etc. 472 5. Network and VPN Service Performance Monitoring YANG Module 474 The "ietf-network-vpn-pm" module uses types defined in [RFC8345], 475 [RFC6991], and [RFC8532]. 477 file "ietf-network-vpn-pm@2021-07-06.yang" 478 module ietf-network-vpn-pm { 479 yang-version 1.1; 480 namespace "urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm"; 481 prefix nvp; 483 import ietf-yang-types { 484 prefix yang; 485 reference 486 "RFC 6991: Common YANG Types"; 487 } 488 import ietf-vpn-common { 489 prefix vpn-common; 490 reference 491 "RFC CCCC: A Layer 2/3 VPN Common YANG Model"; 492 } 493 import ietf-network { 494 prefix nw; 495 reference 496 "RFC 8345: A YANG Data Model for Network 497 Topologies, Section 6.1"; 498 } 499 import ietf-network-topology { 500 prefix nt; 501 reference 502 "RFC 8345: A YANG Data Model for Network 503 Topologies, Section 6.2"; 504 } 505 import ietf-lime-time-types { 506 prefix lime; 507 reference 508 "RFC 8532: Generic YANG Data Model for the Management of 509 Operations, Administration, and Maintenance 510 (OAM) Protocols That Use Connectionless Communications"; 511 } 513 organization 514 "IETF OPSAWG Working Group"; 515 contact 516 "Editor: Qin Wu 517 518 Editor: Bo Wu 519 520 Editor: Mohamed Boucadair 521 "; 522 description 523 "This module defines a model for Network and VPN Service Performance 524 monitoring. 526 Copyright (c) 2021 IETF Trust and the persons identified as 527 authors of the code. All rights reserved. 529 Redistribution and use in source and binary forms, with or 530 without modification, is permitted pursuant to, and subject 531 to the license terms contained in, the Simplified BSD License 532 set forth in Section 4.c of the IETF Trust's Legal Provisions 533 Relating to IETF Documents 534 (http://trustee.ietf.org/license-info). 536 This version of this YANG module is part of RFC XXXX; see 537 the RFC itself for full legal notices."; 539 revision 2021-07-06 { 540 description 541 "Initial revision."; 542 reference 543 "RFC XXXX: A YANG Model for Network and VPN Service Performance 544 Monitoring"; 545 } 547 identity node-type { 548 description 549 "Base identity for node type"; 550 } 552 identity pe { 553 base node-type; 554 description 555 "Identity for Provider Edge (PE) type."; 556 } 558 identity asbr { 559 base node-type; 560 description 561 "Identity for Autonomous System Border Router (ASBR) type."; 562 } 564 identity p { 565 base node-type; 566 description 567 "Identity for P type."; 568 } 570 identity direction { 571 description 572 "Base identity for measurement direction including 573 one-way measurement and two-way measurement."; 574 } 576 identity one-way { 577 base direction; 578 description 579 "Identity for one-way measurement."; 580 } 582 identity two-way { 583 base direction; 584 description 585 "Identity for two-way measurement."; 586 } 588 typedef percentage { 589 type decimal64 { 590 fraction-digits 5; 591 range "0..100"; 592 } 593 description 594 "Percentage."; 595 } 597 typedef percentile { 598 type decimal64 { 599 fraction-digits 5; 600 } 601 description 602 "The percentile is a statistical value that indicates that a 603 certain percentage of a set of data falls below it."; 604 } 606 grouping vpn-summary-statistics { 607 description 608 "VPN Statistics grouping used for network topology 609 augmentation."; 610 container vpn-summary-statistics { 611 config false; 612 description 613 "Container for VPN summary statistics."; 614 container ipv4 { 615 leaf maximum-routes { 616 type uint32; 617 description 618 "Total routes for the VPN."; 619 } 620 leaf total-active-routes { 621 type uint32; 622 description 623 "Total active routes for the VPN."; 624 } 625 description 626 "IPv4-specific parameters."; 627 } 628 container ipv6 { 629 leaf maximum-routes { 630 type uint32; 631 description 632 "Total routes for the VPN."; 633 } 634 leaf total-active-routes { 635 type uint32; 636 description 637 "Total active routes for the VPN."; 638 } 639 description 640 "IPv6-specific parameters."; 641 } 642 container mac-num { 643 leaf mac-num-limit { 644 type uint32; 645 description 646 "Maximum number of MAC addresses."; 647 } 648 leaf total-active-mac-num { 649 type uint32; 650 description 651 "Total active MAC entries for the VPN."; 652 } 653 description 654 "MAC statistics."; 655 } 656 } 657 } 659 grouping link-error-statistics { 660 description 661 "Grouping for per link error statistics."; 662 container loss-statistics { 663 description 664 "Per link loss statistics."; 665 leaf packet-loss-count { 666 type yang:counter64; 667 description 668 "Total received packet drops count."; 669 } 670 leaf packet-reorder-count { 671 type yang:counter64; 672 description 673 "Total received packet reordered count."; 674 } 675 leaf packets-out-of-seq-count { 676 type yang:counter64; 677 description 678 "Total received out of sequence count."; 679 } 680 leaf packets-dup-count { 681 type yang:counter64; 682 description 683 "Total received packet duplicates count."; 684 } 685 leaf loss-ratio { 686 type percentage; 687 description 688 "Loss ratio of the packets. Express as percentage 689 of packets lost with respect to packets sent."; 690 } 691 } 692 } 694 grouping link-delay-statistics { 695 description 696 "Grouping for per link delay statistics"; 698 container delay-statistics { 699 description 700 "Link delay summarised information. By default, 701 one way measurement protocol (e.g., OWAMP) is used 702 to measure delay."; 703 leaf direction { 704 type identityref { 705 base direction; 706 } 707 default "one-way"; 708 description 709 "Define measurement direction including one way 710 measurement and two way measurement."; 711 } 712 leaf unit-value { 713 type identityref { 714 base lime:time-unit-type; 715 } 716 default "lime:milliseconds"; 717 description 718 "Time units, where the options are s, ms, ns, etc."; 719 } 720 leaf min-delay-value { 721 type yang:gauge64; 722 description 723 "Minimum delay value observed."; 724 } 725 leaf max-delay-value { 726 type yang:gauge64; 727 description 728 "Maximum delay value observed."; 729 } 730 leaf low-delay-percentile { 731 type yang:gauge64; 732 description 733 "Low percentile of the delay observed with 734 specific measurement method."; 735 } 736 leaf middle-delay-percentile { 737 type yang:gauge64; 738 description 739 "Middle percentile of the delay observed with 740 specific measurement method."; 741 } 742 leaf high-delay-percentile { 743 type yang:gauge64; 744 description 745 "High percentile of the delay observed with 746 specific measurement method."; 747 } 748 } 749 } 751 grouping link-jitter-statistics { 752 description 753 "Grouping for per link jitter statistics"; 754 container jitter-statistics { 755 description 756 "Link jitter summarised information. By default, 757 jitter is measured using IP Packet Delay Variation 758 (IPDV)."; 759 leaf unit-value { 760 type identityref { 761 base lime:time-unit-type; 762 } 763 default "lime:milliseconds"; 764 description 765 "Time units, where the options are s, ms, ns, etc."; 766 } 767 leaf min-jitter-value { 768 type yang:gauge32; 769 description 770 "Minimum jitter value observed."; 771 } 772 leaf max-jitter-value { 773 type yang:gauge32; 774 description 775 "Maximum jitter value observed."; 776 } 777 leaf low-jitter-percentile { 778 type yang:gauge32; 779 description 780 "Low percentile of the jitter observed."; 781 } 782 leaf middle-jitter-percentile { 783 type yang:gauge32; 784 description 785 "Middle percentile of the jitter observed."; 786 } 787 leaf high-jitter-percentile { 788 type yang:gauge32; 789 description 790 "High percentile of the jitter observed."; 791 } 792 } 793 } 794 grouping tp-svc-telemetry { 795 leaf inbound-octets { 796 type yang:counter64; 797 description 798 "The total number of octets received on the 799 interface, including framing characters."; 800 } 801 leaf inbound-unicast { 802 type yang:counter64; 803 description 804 "Inbound unicast packets were received, and delivered 805 to a higher layer during the last period."; 806 } 807 leaf inbound-nunicast { 808 type yang:counter64; 809 description 810 "The number of non-unicast (i.e., subnetwork- 811 broadcast or subnetwork-multicast) packets 812 delivered to a higher-layer protocol."; 813 } 814 leaf inbound-discards { 815 type yang:counter32; 816 description 817 "The number of inbound packets which were chosen 818 to be discarded even though no errors had been 819 detected to prevent their being deliverable to a 820 higher-layer protocol."; 821 } 822 leaf inbound-errors { 823 type yang:counter64; 824 description 825 "The number of inbound packets that contained 826 errors preventing them from being deliverable to a 827 higher-layer protocol."; 828 } 829 leaf inbound-unknown-protocol { 830 type yang:counter64; 831 description 832 "The number of packets received via the interface 833 which were discarded because of an unknown or 834 unsupported protocol."; 835 } 836 leaf outbound-octets { 837 type yang:counter64; 838 description 839 "The total number of octets transmitted out of the 840 interface, including framing characters."; 841 } 842 leaf outbound-unicast { 843 type yang:counter64; 844 description 845 "The total number of packets that higher-level 846 protocols requested be transmitted to a 847 subnetwork-unicast address, including those that 848 were discarded or not sent."; 849 } 850 leaf outbound-nunicast { 851 type yang:counter64; 852 description 853 "The total number of packets that higher-level 854 protocols requested be transmitted to a non- 855 unicast (i.e., a subnetwork-broadcast or 856 subnetwork-multicast) address, including those 857 that were discarded or not sent."; 858 } 859 leaf outbound-discards { 860 type yang:counter64; 861 description 862 "The number of outbound packets which were chosen 863 to be discarded even though no errors had been 864 detected to prevent their being transmitted. One 865 possible reason for discarding such a packet could 866 be to free up buffer space."; 867 } 868 leaf outbound-errors { 869 type yang:counter64; 870 description 871 "The number of outbound packets that contained 872 errors preventing them from being deliverable to a 873 higher-layer protocol."; 874 } 875 description 876 "Grouping for interface service telemetry."; 877 } 879 augment "/nw:networks/nw:network/nw:network-types" { 880 description 881 "Defines the service topologies types"; 882 container service-type { 883 presence "Indicates Network service topology"; 884 leaf service-type { 885 type identityref { 886 base vpn-common:service-type; 887 } 888 description 889 "The presence identifies the network service type, 890 e.g., L3VPN, VPLS, etc."; 891 } 892 description 893 "Container for VPN service type."; 894 } 895 } 897 augment "/nw:networks/nw:network" { 898 when 'nw:network-types/nvp:service-type' { 899 description 900 "Augment only for VPN Network topology."; 901 } 902 description 903 "Augment the network with service topology attributes"; 904 container vpn-pm-attributes { 905 leaf vpn-id { 906 type vpn-common:vpn-id; 907 description 908 "VPN identifier."; 909 } 910 leaf vpn-service-topology { 911 type identityref { 912 base vpn-common:vpn-topology; 913 } 914 description 915 "VPN service topology, e.g., hub-spoke, any-to-any, 916 hub-spoke-disjoint"; 917 } 918 description 919 "Container for vpn topology attributes."; 920 } 921 } 923 augment "/nw:networks/nw:network/nw:node" { 924 description 925 "Augment the network node with other general attributes"; 926 container pm-attributes { 927 leaf node-type { 928 type identityref { 929 base node-type; 930 } 931 description 932 "Node type, e.g., PE, P, ASBR."; 933 } 934 description 935 "Container for node attributes."; 936 } 937 } 938 augment "/nw:networks/nw:network/nw:node/pm-attributes" { 939 when '../../nw:network-types/nvp:service-type' { 940 description 941 "Augment only for VPN node attributes."; 942 } 943 description 944 "Augment the network node with VPN specific attributes"; 945 leaf role { 946 type identityref { 947 base vpn-common:role; 948 } 949 default "vpn-common:any-to-any-role"; 950 description 951 "Role of the node in the VPN."; 952 } 953 uses vpn-summary-statistics; 954 } 956 augment "/nw:networks/nw:network/nt:link" { 957 description 958 "Augment the network topology link with performance monitoring 959 attributes"; 960 container pm-attributes { 961 description 962 "Container for PM attributes."; 963 leaf low-percentile { 964 type percentile; 965 default "10.00"; 966 description 967 "Low percentile to report. Setting low-percentile 968 into 0.00 indicates the client is not interested in receiving 969 low percentile."; 970 } 971 leaf middle-percentile { 972 type percentile; 973 default "50.00"; 974 description 975 "Middle percentile to report. Setting middle-percentile 976 into 0.00 indicates the client is not interested in receiving 977 middle percentile."; 978 } 979 leaf high-percentile { 980 type percentile; 981 default "90.00"; 982 description 983 "High percentile to report. Setting high-percentile 984 into 0.00 indicates the client is not interested in receiving 985 high percentile"; 987 } 988 leaf pm-source { 989 type string; 990 config false; 991 description 992 "The OAM tool used to collect the PM data."; 993 } 994 leaf reference-time { 995 type yang:date-and-time; 996 config false; 997 description 998 "The time that the current Measurement Interval started."; 999 } 1000 leaf measurement-interval { 1001 type uint32; 1002 units "seconds"; 1003 default "60"; 1004 config false; 1005 description 1006 "Interval to calculate performance metric."; 1007 } 1008 container pm-statistics { 1009 config false; 1010 uses link-error-statistics; 1011 uses link-delay-statistics; 1012 uses link-jitter-statistics; 1013 description 1014 "Container for service telemetry attributes."; 1015 } 1016 } 1017 } 1019 augment "/nw:networks/nw:network/nt:link/pm-attributes" { 1020 when '../../nw:network-types/nvp:service-type' { 1021 description 1022 "Augment only for VPN Network topology."; 1023 } 1024 description 1025 "Augment the network topology link with service performance 1026 monitoring attributes"; 1027 leaf protocol-type { 1028 type identityref { 1029 base vpn-common:protocol-type; 1030 } 1031 config false; 1032 description 1033 "Underlay-transport type, e.g., GRE, LDP, etc."; 1034 } 1036 } 1038 augment "/nw:networks/nw:network/nw:node/nt:termination-point" { 1039 description 1040 "Augment the network topology termination point with 1041 performance monitoring attributes"; 1042 container pm-statistics { 1043 config false; 1044 uses tp-svc-telemetry; 1045 description 1046 "Container for termination point PM attributes."; 1047 } 1048 } 1049 } 1051 1053 6. Security Considerations 1055 The YANG modules defined in this document MAY be accessed via the 1056 RESTCONF protocol [RFC8040] or NETCONF protocol [RFC6241]. The 1057 lowest RESTCONF or NETCONF layer requires that the transport-layer 1058 protocol provides both data integrity and confidentiality, see 1059 Section 2 in [RFC8040] and [RFC6241]. The lowest NETCONF layer is 1060 the secure transport layer, and the mandatory-to-implement secure 1061 transport is Secure Shell (SSH)[RFC6242] . The lowest RESTCONF layer 1062 is HTTPS, and the mandatory-to-implement secure transport is TLS 1063 [RFC8446]. 1065 The NETCONF access control model [RFC8341] provides the means to 1066 restrict access for particular NETCONF or RESTCONF users to a 1067 preconfigured subset of all available NETCONF or RESTCONF protocol 1068 operations and content. 1070 There are a number of data nodes defined in this YANG module that are 1071 writable/creatable/deletable (i.e., config true, which is the 1072 default). These data nodes may be considered sensitive or vulnerable 1073 in some network environments. Write operations (e.g., edit-config) 1074 to these data nodes without proper protection can have a negative 1075 effect on network operations. These are the subtrees and data nodes 1076 and their sensitivity/vulnerability: 1078 o /nw:networks/nw:network/svc-topo:svc-telemetry-attributes 1080 o /nw:networks/nw:network/nw:node/svc-topo:node-attributes 1082 7. IANA Considerations 1084 This document requests IANA to register the following URI in the "ns" 1085 subregistry within the "IETF XML Registry" [RFC3688]: 1087 URI: urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm 1088 Registrant Contact: The IESG. 1089 XML: N/A, the requested URI is an XML namespace. 1091 This document requests IANA to register the following YANG module in 1092 the "YANG Module Names" subregistry [RFC6020] within the "YANG 1093 Parameters" registry. 1095 Name: ietf-network-vpn-pm 1096 Namespace: urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm 1097 Maintained by IANA: N 1098 Prefix: nvp 1099 Reference: RFC XXXX 1101 8. Acknowledgements 1103 Thanks to Joe Clarke, Adrian Farrel, Greg Mirsky, Roque Gagliano, 1104 Erez Segev, and Dhruv Dhody for reviewing and providing important 1105 input to this document. 1107 9. Contributors 1109 Michale Wang 1110 Huawei 1111 Email:wangzitao@huawei.com 1113 Roni Even 1114 Huawei 1115 Email: ron.even.tlv@gmail.com 1117 10. References 1119 10.1. Normative References 1121 [I-D.ietf-opsawg-vpn-common] 1122 Barguil, S., Dios, O. G. D., Boucadair, M., and Q. Wu, "A 1123 Layer 2/3 VPN Common YANG Model", draft-ietf-opsawg-vpn- 1124 common-07 (work in progress), April 2021. 1126 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1127 Requirement Levels", BCP 14, RFC 2119, 1128 DOI 10.17487/RFC2119, March 1997, 1129 . 1131 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1132 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1133 DOI 10.17487/RFC3393, November 2002, 1134 . 1136 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1137 DOI 10.17487/RFC3688, January 2004, 1138 . 1140 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1141 the Network Configuration Protocol (NETCONF)", RFC 6020, 1142 DOI 10.17487/RFC6020, October 2010, 1143 . 1145 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1146 and A. Bierman, Ed., "Network Configuration Protocol 1147 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1148 . 1150 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1151 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1152 . 1154 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 1155 Measurement for MPLS Networks", RFC 6374, 1156 DOI 10.17487/RFC6374, September 2011, 1157 . 1159 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1160 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1161 . 1163 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1164 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1165 . 1167 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1168 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1169 May 2017, . 1171 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1172 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1173 . 1175 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1176 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1177 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1178 2018, . 1180 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1181 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1182 . 1184 [RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S. 1185 Raghavan, "Generic YANG Data Model for the Management of 1186 Operations, Administration, and Maintenance (OAM) 1187 Protocols That Use Connectionless Communications", 1188 RFC 8532, DOI 10.17487/RFC8532, April 2019, 1189 . 1191 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1192 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1193 September 2019, . 1195 10.2. Informative References 1197 [I-D.ietf-opsawg-l2nm] 1198 Barguil, S., Dios, O. G. D., Boucadair, M., and L. A. 1199 Munoz, "A Layer 2 VPN Network YANG Model", draft-ietf- 1200 opsawg-l2nm-02 (work in progress), April 2021. 1202 [I-D.ietf-opsawg-l3sm-l3nm] 1203 Barguil, S., Dios, O. G. D., Boucadair, M., Munoz, L. A., 1204 and A. Aguado, "A Layer 3 VPN Network YANG Model", draft- 1205 ietf-opsawg-l3sm-l3nm-08 (work in progress), April 2021. 1207 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 1208 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 1209 RFC 5357, DOI 10.17487/RFC5357, October 2008, 1210 . 1212 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1213 Previdi, "OSPF Traffic Engineering (TE) Metric 1214 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1215 . 1217 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1218 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1219 . 1221 [RFC8194] Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for 1222 LMAP Measurement Agents", RFC 8194, DOI 10.17487/RFC8194, 1223 August 2017, . 1225 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1226 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1227 . 1229 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1230 Access Control Model", STD 91, RFC 8341, 1231 DOI 10.17487/RFC8341, March 2018, 1232 . 1234 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 1235 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 1236 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 1237 2019, . 1239 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 1240 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 1241 IGP Traffic Engineering Performance Metric Extensions", 1242 RFC 8571, DOI 10.17487/RFC8571, March 2019, 1243 . 1245 [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and 1246 L. Geng, "A Framework for Automating Service and Network 1247 Management with YANG", RFC 8969, DOI 10.17487/RFC8969, 1248 January 2021, . 1250 Appendix A. Illustrating Examples 1252 A.1. Example of Pub/Sub Retrieval 1254 The example shown in Figure 7 illustrates how a client subscribes to 1255 the performance monitoring information between nodes ('node-id') A 1256 and B in the L3 network topology. The performance monitoring 1257 parameter that the client is interested in is end-to-end loss. 1259 1261 1263 1264 1266 1267 l3-network 1268 1270 L3VPN 1271 1272 1273 A 1274 1275 xmlns="urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm"> 1276 pe 1278 1279 1281 1-0-1 1282 1284 150 1285 100 1286 1287 1288 1289 1290 B 1291 1292 xmlns="urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm"> 1293 pe 1294 1295 1297 2-0-1 1298 1300 150 1301 100 1302 1303 1304 1305 1307 A-B 1308 1309 A 1310 1311 1312 B 1313 1314 mpls-te 1315 1317 1318 100 1319 1320 1321 1322 1323 1324 1325 1327 500 1328 1329 1330 1332 Figure 7: Pub/Siub Retrieval 1334 A.2. Example of RPC-based Retrieval 1336 This example, depicted in Figure 8, illustrates how a the client can 1337 use the RPC model to fetch performance data on demand. For example, 1338 the client requests "packet-loss-count" between 'source-node' A and 1339 'dest-node' B that belong to the same VPN ('VPN1'). 1341 1343 1345 1346 1347 vpn1 1348 1349 A 1350 1352 pe 1353 1354 1356 1-0-1 1357 1359 100 1360 150 1361 1362 1363 1364 1365 B 1366 1368 pe 1369 1370 1372 2-0-1 1373 1375 150 1376 100 1377 1378 1379 1380 1381 A-B 1382 1383 A 1384 1385 1386 B 1387 1388 <-type>mpls-te 1389 1391 1392 120 1393 1394 1395 1396 1397 1398 1400 Figure 8 1402 A.3. Example of Percentile Monitoring 1404 The following shows an example of a percentile measurement for a VPN 1405 link. 1407 { 1408 "ietf-network-topology:link":[ 1409 { 1410 "link-id":"vpn1-link1", 1411 "source":{ 1412 "source-node":"vpn-node1" 1413 }, 1414 "destination":{ 1415 "dest-node":"vpn-node3" 1416 }, 1417 "ietf-network-vpn-pm:protocol-type":"gre", 1418 "ietf-network-vpn-pm:pm-attributes":{ 1419 "low-percentile":"20.00", 1420 "middle-percentile":"50.00", 1421 "high-percentile":"90.00", 1422 "pm-statistics:delay-statistics":{ 1423 "direction":"one-way", 1424 "unit-values":"milliseconds", 1425 "min-delay-value":"43", 1426 "max-delay-value":"99", 1427 "low-delay-percentile":"64", 1428 "middle-delay-percentile":"77", 1429 "high-delay-percentile":"98" 1430 } 1431 } 1432 } 1433 ] 1434 } 1436 Authors' Addresses 1438 Bo Wu (editor) 1439 Huawei 1440 101 Software Avenue, Yuhua District 1441 Nanjing, Jiangsu 210012 1442 China 1444 Email: lana.wubo@huawei.com 1446 Qin Wu (editor) 1447 Huawei 1448 101 Software Avenue, Yuhua District 1449 Nanjing, Jiangsu 210012 1450 China 1452 Email: bill.wu@huawei.com 1453 Mohamed Boucadair (editor) 1454 Orange 1455 Rennes 35000 1456 France 1458 Email: mohamed.boucadair@orange.com 1460 Oscar Gonzalez de Dios 1461 Telefonica 1462 Madrid 1463 ES 1465 Email: oscar.gonzalezdedios@telefonica.com 1467 Bin Wen 1468 Comcast 1470 Email: bin_wen@comcast.com 1472 Change Liu 1473 China Unicom 1475 Email: liuc131@chinaunicom.cn 1477 Honglei Xu 1478 China Telecom 1480 Email: xuhl.bri@chinatelecom.cn