idnits 2.17.1 draft-ietf-opsawg-yang-vpn-service-pm-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 17, 2021) is 1164 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) == Outdated reference: A later version (-18) exists of draft-ietf-opsawg-l3sm-l3nm-05 == Outdated reference: A later version (-12) exists of draft-ietf-opsawg-vpn-common-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG Working Group B. Wu 3 Internet-Draft Q. Wu 4 Intended status: Standards Track Huawei 5 Expires: August 21, 2021 M. Boucadair 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 February 17, 2021 17 A YANG Model for Network and VPN Service Performance Monitoring 18 draft-ietf-opsawg-yang-vpn-service-pm-00 20 Abstract 22 The data model defined in RFC8345 introduces vertical layering 23 relationships between networks that can be augmented to cover 24 network/service topologies. This document defines a YANG model for 25 both Network Performance Monitoring 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 This document does not define metrics for network performance or 31 mechanisms for measuring network performance. The YANG model defined 32 in this document is designed as an augmentation to the network 33 topology YANG model defined in RFC 8345 and draws on relevant YANG 34 types defined in RFC 6991, RFC 8299, RFC 8345, and RFC 8532. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on August 21, 2021. 53 Copyright Notice 55 Copyright (c) 2021 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3. Network and VPN Service Performance Monitoring Model Usage . 3 73 3.1. Retrieval via Pub/Sub Mechanism . . . . . . . . . . . . . 4 74 3.2. On demand Retrieval via RPC Model . . . . . . . . . . . . 5 75 4. Description of the Data Model . . . . . . . . . . . . . . . . 5 76 4.1. Layering Relationship Between Multiple Layers of Topology 5 77 4.2. Network Level . . . . . . . . . . . . . . . . . . . . . . 6 78 4.3. Node Level . . . . . . . . . . . . . . . . . . . . . . . 7 79 4.4. Link and Termination Point Level . . . . . . . . . . . . 8 80 5. Example of I2RS Pub/Sub Retrieval . . . . . . . . . . . . . . 11 81 6. Example of RPC-based Retrieval . . . . . . . . . . . . . . . 12 82 7. Network and VPN Service Assurance YANG Module . . . . . . . . 14 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 85 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 86 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 88 12.1. Normative References . . . . . . . . . . . . . . . . . . 27 89 12.2. Informative References . . . . . . . . . . . . . . . . . 29 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 92 1. Introduction 94 [RFC4176] provides a framework for L3VPN operations and management 95 and specifies that performance management is required after service 96 configuration. This document defines a YANG Model for both network 97 performance monitoring and VPN service performance monitoring that 98 can be used to monitor and manage network performance on the topology 99 level or the service topology between VPN sites. 101 This document does not introduce new metrics for network performance 102 or mechanisms for measuring network performance, but uses the 103 existing mechanisms and statistics to show the performance monitoring 104 statistics at the network and service layers. The YANG model defined 105 in this document is designed as an augmentation to the network 106 topology YANG model defined in [RFC8345] and draws on relevant YANG 107 types defined in [RFC6991], [RFC8299], [RFC8345], and [RFC8532]. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in BCP 114 14 [RFC2119][RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 Tree diagrams used in this document follow the notation defined in 118 [RFC8340]. 120 3. Network and VPN Service Performance Monitoring Model Usage 122 Models are key for automatic management operations. According to 123 [I-D.ietf-opsawg-model-automation-framework] , together with service 124 and network models, performance measurement telemetry model can 125 monitor network performance to meet specific service SLA 126 requirements. The model defined in this document is to derive VPN or 127 network level performance data based on lower-level data collected 128 via monitoring counters in the devices. 130 +---------------+ 131 | Customer | 132 +---------------+ 133 Customer Service Models | 134 | 135 +-----------------+ 136 | Service | 137 | Orchestration | 138 +-----------------+ 139 Service Network Models | | Network and VPN Service PM Model 140 | | 141 +-----------------+ 142 | Network | 143 | Controller | 144 +-------|----------+ 145 | 146 +------------------------------------------------+ 147 Network 149 Figure 1: Reference Architecture 151 As shown in Figure 1 , the network and VPN service performance 152 monitoring model can be used to expose some performance information 153 to the above layer. The information can be used by the orchestrator 154 to subscribe to performance data. The controller will then notify 155 the orchestrator of corresponding parameter changes. 157 Before using the Network and VPN Service PM Model, the mapping 158 between the VPN Service topology and the underlying physical network 159 has been setup, and the performance monitoring data per link in the 160 underlying network can be collected using network performance 161 measurement method such as MPLS Loss and Delay Measurement [RFC6374]. 163 The performance monitoring information reflecting the quality of the 164 Network or VPN service such as end to end network performance data 165 between source node and destination node in the network or between 166 VPN sites can be aggregated or calculated using, for example, PCEP 167 solution [RFC8233] [RFC7471] [RFC8570] [RFC8571] or LMAP [RFC8194]. 169 The measurement interval and report interval associated with these 170 performance data usually depends on configuration parameters. 172 3.1. Retrieval via Pub/Sub Mechanism 174 Some applications such as service-assurance applications, which must 175 maintain a continuous view of operational data and state, can use 176 subscription model [RFC8641] to subscribe to the specific Network 177 performance data or VPN service performance data they are interested 178 in, at the data source. 180 The data source can then use the Network and VPN service assurance 181 model defined in this document and the YANG Push model [RFC8641] to 182 distribute specific telemetry data to target recipients. 184 3.2. On demand Retrieval via RPC Model 186 To obtain a snapshot of a large amount of performance data from a 187 network element (including network controllers), service-assurance 188 applications may use polling-based methods such as RPC model to fetch 189 performance data on demand. 191 4. Description of the Data Model 193 This document defines the YANG module "ietf-network-vpn-pm", which is 194 an augmentation to the "ietf-network" and "ietf-network-topology". 196 The performance monitoring data is augmented to service topology as 197 shown in Figure 2. 199 +----------------------+ +-----------------------+ 200 |ietf-network | |Network and VPN Service| 201 |ietf-network-topology |<---------|Performance Monitoring | 202 +----------------------+ augments | Model | 203 +-----------------------+ 205 Figure 2: Module Augmentation 207 4.1. Layering Relationship Between Multiple Layers of Topology 209 [RFC8345] defines a YANG [RFC7950] data model for network/service 210 topologies and inventories. The service topology described in 211 [RFC8345] includes the virtual topology for a service layer above 212 Layer 1 (L1), Layer 2 (L2), and Layer 3 (L3). This service topology 213 has the generic topology elements of node, link, and terminating 214 point. One typical example of a service topology is described in 215 Figure 3 of [RFC8345]: two VPN service topologies instantiated over a 216 common L3 topology. Each VPN service topology is mapped onto a 217 subset of nodes from the common L3 topology. 219 Figure 3 illustrates an example of a topology mapping between the VPN 220 service topology and an underlying network: 222 VPN-SVC 1 VPN-SVC 2 223 / \ 224 VPN-Service-topology 1 VPN-Service-topology-2 225 / | \ / | \ 226 Site-1A Site-1B Site1-C Site-2A Site-2B Site-2C Top-Down 227 | | | | | | Service Topology 228 CE CE CE CE CE CE 229 | | | | | | 230 PE PE PE PE PE PE 231 ====|==========|=======|=======|=========|=====|==================== 232 +-------+ | \ / / | 233 Bottom-up | | \ / / | 234 Network | | /\ / | 235 topology | | / \ | | 236 | | | | | | 237 node1 node2 node3 node4 node5 node6 239 Figure 3: Example of topology mapping between VPN Service Topo and 240 Underlying network 242 As shown in Figure 3, two VPN services topologies are both built on 243 top of one common underlying physical network: 245 o VPN-SVC 1: supporting "hub-spoke" communications for Customer 1 246 connecting the customer's access at 3 sites. Site-1A, Site-1B, 247 and Site-1C are connected to PEs that are mapped to nodes 1, 2, 248 and 3 in the underlying physical network. 249 Site-1 A plays the role of hub while Site-2 B and C plays the role 250 of spoke. 252 o VPN-SVC 2: supporting "hub-spoke disjoint" communications for 253 Customer 2 connecting the customer's access at 3 sites. Site-2A, 254 Site-2B, and Site-2C are connected to PEs that are mapped to nodes 255 4, 5, and 6 in the underlying physical network. 257 Site-2 A and B play the role of hub while Site-2 C plays the role 258 of spoke. 260 4.2. Network Level 262 For network performance monitoring, the attributes of "Network Level" 263 that defined in [RFC8345] do not need to be extended. 265 For VPN service performance monitoring, this document defines some 266 new network service type: "L3VPN, L2VPN". When a network topology 267 data instance contains the L3VPN or L2VPN network type, it represents 268 an VPN instance that can perform performance monitoring. 270 This model defines only the following minimal set of Network level 271 network topology attributes: 273 o "vpn-id": Refers to an identifier of VPN service 274 (e.g.,L3NM[I-D.ietf-opsawg-l3sm-l3nm]). This identifier allows to 275 correlate the performance status with the network service 276 configuration. 278 o "vpn-topo": The type of VPN service topology, this model supports 279 "any-to-any", "Hub and Spoke" (where Hubs can exchange traffic), 280 and "Hub and Spoke disjoint" (where Hubs cannot exchange traffic). 281 [RFC8299] defines a YANG model for L3VPN Service Delivery. Three 282 types of VPN service topologies are supported in : "any to any", 283 "hub and spoke", and "hub and spoke disjoint". These VPN topology 284 types can be used to describe how VPN sites communicate with each 285 other. 287 module: ietf-network-vpn-pm 288 augment /nw:networks/nw:network/nw:network-types: 289 +--rw network-service-type! 290 +--rw network-service-type? identityref 291 augment /nw:networks/nw:network: 292 +--rw vpn-topo-attributes 293 +--rw vpn-id? vpn-common:vpn-id 294 +--rw vpn-topology? identityref 296 Figure 4: Network Level View of the hierarchies 298 4.3. Node Level 300 For network performance monitoring, the attributes of "Node Level" 301 that defined in [RFC8345] do not need to be extended. 303 For VPN service performance monitoring, this model defines only the 304 following minimal set of Node level network topology attributes: 306 o "node-type" (Attribute): Indicates the type of the node, such as 307 PE or ASBR. This "node-type" can be used to report performance 308 metric between any two nodes each with specific node-type. 310 o "site-id" (Constraint): Uniquely identifies the site within the 311 overall network infrastructure. 313 o "site-role" (Constraint): Defines the role of the site in a 314 particular VPN topology. 316 o "vpn-summary-statistics": IPv4 statistics, and IPv6 statistics 317 have been specified separately. And MAC statistics could be 318 extended for L2VPN. 320 augment /nw:networks/nw:network/nw:node: 321 +--rw node-attributes 322 | +--rw node-type? identityref 323 | +--rw site-id? string 324 | +--rw site-role? identityref 325 +--rw vpn-summary-statistics 326 +--rw ipv4 327 | +--rw total-routes? uint32 328 | +--rw total-active-routes? uint32 329 +--rw ipv6 330 +--rw total-routes? uint32 331 +--rw total-active-routes? uint32 333 Figure 5: Node Level View of the hierarchies 335 4.4. Link and Termination Point Level 337 The link nodes are classified into two types: one is topology link 338 defined in [RFC8345], and the other is abstract link of a VPN between 339 PEs. 341 The performance data of the link is a collection of counters that 342 report the performance status. The data for the topology link can be 343 based on BGP-LS [RFC8571]. The statistics of the VPN abstract links 344 can be collected based on VPN OAM mechanisms, e.g. TWAMP etc. 345 Alternatively, the data can base on the underlay technology OAM 346 mechanism, for example, GRE tunnel OAM. 348 augment /nw:networks/nw:network/nt:link: 349 +--rw link-type? identityref 350 augment /nw:networks/nw:network/nt:link: 351 +--rw low-percentile? percentile 352 +--rw middle-percentile? percentile 353 +--rw high-percentile? percentile 354 +--rw reference-time? yang:date-and-time 355 +--rw measurement-interval? uint32 356 +--ro link-telemetry-attributes 357 +--ro loss-statistics 358 | +--ro packet-loss-count? yang:counter32 359 | +--ro packet-reorder-count? yang:counter32 360 | +--ro packets-out-of-seq-count? yang:counter32 361 | +--ro packets-dup-count? yang:counter32 362 | +--ro loss-ratio? percentage 363 +--ro delay-statistics 364 | +--ro direction? identityref 365 | +--ro unit-value? identityref 366 | +--ro min-delay-value? yang:gauge64 367 | +--ro max-delay-value? yang:gauge64 368 | +--ro low-delay-percentile? yang:gauge64 369 | +--ro middle-delay-percentile? yang:gauge64 370 | +--ro high-delay-percentile? yang:gauge64 371 +--ro jitter-statistics 372 +--ro unit-value? identityref 373 +--ro min-jitter-value? yang:gauge32 374 +--ro max-jitter-value? yang:gauge32 375 +--ro low-jitter-percentile? yang:gauge32 376 +--ro middle-jitter-percentile? yang:gauge32 377 +--ro high-jitter-percentile? yang:gauge32 378 augment /nw:networks/nw:network/nw:node/nt:termination-point: 379 +--ro tp-telemetry-attributes 380 +--ro inbound-octets? yang:counter64 381 +--ro inbound-unicast? yang:counter64 382 +--ro inbound-nunicast? yang:counter64 383 +--ro inbound-discards? yang:counter32 384 +--ro inbound-errors? yang:counter32 385 +--ro inbound-unknown-protocol? yang:counter32 386 +--ro outbound-octets? yang:counter64 387 +--ro outbound-unicast? yang:counter64 388 +--ro outbound-nunicast? yang:counter64 389 +--ro outbound-discards? yang:counter32 390 +--ro outbound-errors? yang:counter32 391 +--ro outbound-qlen? uint32 393 Figure 6: Link and Termination point Level View of the hierarchies 395 For the nodes of the link in the figure, this module defines the 396 following minimal set of link level performance attributes: 398 o "link-type": Indicates the abstract link of a VPN, such as GRE or 399 IP-in-IP. The leaf refers to an identifier of VPN Common 400 "underlay-transport" [I-D.ietf-opsawg-vpn-common], which describes 401 the transport technology to carry the traffic of the VPN service. 403 o Percentile parameters: The module supports reporting delay and 404 jitter metric by percentile values. By default, low percentile 405 (10th percentile), mid percentile (50th percentile), high 406 percentile (90th percentile) are used. Setting a percentile into 407 0.00 indicates the client is not interested in receiving 408 particular percentile. If all percentile nodes are set to 0.00, 409 this represents that no percentile related nodes will be reported 410 for a given performance metric (e.g. one-way delay, one-way delay 411 variation) and only peak/min values will be reported. For 412 example, a client can inform the server that it is interested in 413 receiving only high percentiles. Then for a given link, at a 414 given "reference-time" "measurement-interval", the high-delay- 415 percentile and high-jitter-percentile will be reported. 417 o Loss Statistics: A set of loss statistics attributes that are used 418 to measure end to end loss between VPN sites or between any two 419 network nodes. The exact loss value or the loss percentage can be 420 reported. 422 o Delay Statistics: A set of delay statistics attributes that are 423 used to measure end to end latency between VPN sites or between 424 any two network nodes. The peak/min values or percentile values 425 can be reported. 427 o Jitter Statistics: A set of IP Packet Delay Variation [RFC3393] 428 statistics attributes that are used to measure end to end jitter 429 between VPN sites or between any two network nodes. The peak/min 430 values or percentile values can be reported. 432 For the nodes of "termination points" in the figure, the module 433 defines the following minimal set of statistics: 435 o Inbound statistics: A set of inbound statistics attributes that 436 are used to measure the inbound statistics of the termination 437 point, such as received packets, received packets with errors, 438 etc. 440 o Outbound statistics: A set of outbound statistics attributes that 441 are used to measure the outbound statistics of the termination 442 point, such as sent packets, packets that could not be sent due to 443 errors, etc. 445 5. Example of I2RS Pub/Sub Retrieval 447 This example shows the way for a client to subscribe for the 448 Performance monitoring information between node A and node B in the 449 L3 network topology built on top of the underlying network . The 450 performance monitoring parameter that the client is interested in is 451 end to end loss attribute. 453 455 457 458 460 461 l3-network 462 464 L3VPN 465 466 467 A 468 470 pe 471 472 474 1-0-1 475 477 150 478 100 479 480 481 482 483 B 484 486 pe 487 488 490 2-0-1 491 493 150 494 100 495 496 497 498 500 A-B 501 502 A 503 504 505 B 506 507 mpls-te 508 510 511 100 512 513 514 515 516 517 518 520 500 521 522 523 525 6. Example of RPC-based Retrieval 527 This example shows the way for the client to use RPC model to fetch 528 performance data on demand, e.g., the client requests "packet-loss- 529 count" between PE1 in site 1 and PE2 in site 2 belonging to the same 530 VPN1. 532 534 536 537 538 vpn1 539 540 A 541 543 pe 544 545 547 1-0-1 548 550 100 551 150 552 553 554 555 556 B 557 559 pe 560 561 563 2-0-1 564 566 150 567 100 568 569 570 571 572 A-B 573 574 A 575 576 577 B 578 579 mpls-te 580 582 583 120 584 585 587 588 589 590 592 7. Network and VPN Service Assurance YANG Module 594 This module uses types defined in [RFC8345], [RFC8299] and [RFC8532]. 596 file "ietf-network-vpn-pm@2021-01-15.yang" 597 module ietf-network-vpn-pm { 598 yang-version 1.1; 599 namespace "urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm"; 600 prefix nvp; 602 import ietf-yang-types { 603 prefix yang; 604 reference 605 "RFC 6991: Common YANG Types."; 606 } 607 import ietf-vpn-common { 608 prefix vpn-common; 609 } 610 import ietf-network { 611 prefix nw; 612 reference 613 "Section 6.1 of RFC 8345: A YANG Data Model for Network 614 Topologies"; 615 } 616 import ietf-network-topology { 617 prefix nt; 618 reference 619 "Section 6.2 of RFC 8345: A YANG Data Model for Network 620 Topologies"; 621 } 622 import ietf-lime-time-types { 623 prefix lime; 624 reference 625 "RFC 8532: Generic YANG Data Model for the Management of 626 Operations, Administration, and Maintenance (OAM) Protocols 627 That Use Connectionless Communications"; 628 } 630 organization 631 "IETF OPSAWG Working Group"; 632 contact 633 "Editor: Qin Wu 634 636 Editor: Bo Wu 637 638 Editor: Mohamed Boucadair 639 "; 640 description 641 "This module defines a model for Network and VPN Service Performance 642 monitoring. 644 Copyright (c) 2021 IETF Trust and the persons identified as 645 authors of the code. All rights reserved. 647 Redistribution and use in source and binary forms, with or 648 without modification, is permitted pursuant to, and subject 649 to the license terms contained in, the Simplified BSD License 650 set forth in Section 4.c of the IETF Trust's Legal Provisions 651 Relating to IETF Documents 652 (http://trustee.ietf.org/license-info). 654 This version of this YANG module is part of RFC XXXX; see 655 the RFC itself for full legal notices."; 657 revision 2021-01-15 { 658 description 659 "Initial revision."; 660 reference 661 "RFC XXXX: A YANG Model for Network and VPN Service Performance 662 Monitoring"; 663 } 665 identity pe { 666 base vpn-common:role; 667 description 668 "Identity for PE type"; 669 } 671 identity ce { 672 base vpn-common:role; 673 description 674 "Identity for CE type"; 675 } 677 identity asbr { 678 base vpn-common:role; 679 description 680 "Identity for ASBR type"; 681 } 683 identity p { 684 base vpn-common:role; 685 description 686 "Identity for P type"; 687 } 689 identity link-type { 690 base vpn-common:protocol-type; 691 description 692 "Base identity for link type, e.g.,GRE, MPLS TE, VXLAN."; 693 } 695 identity VXLAN { 696 base link-type; 697 description 698 "Base identity for VXLAN Tunnel."; 699 } 701 identity ip-in-ip { 702 base link-type; 703 description 704 "Base identity for IP in IP Tunnel."; 705 } 707 identity direction { 708 description 709 "Base Identity for measurement direction including 710 one way measurement and two way measurement."; 711 } 713 identity one-way { 714 base direction; 715 description 716 "Identity for one way measurement."; 717 } 719 identity two-way { 720 base direction; 721 description 722 "Identity for two way measurement."; 723 } 725 typedef percentage { 726 type decimal64 { 727 fraction-digits 5; 728 range "0..100"; 729 } 730 description 731 "Percentage."; 733 } 735 typedef percentile { 736 type decimal64 { 737 fraction-digits 5; 738 } 739 description 740 "The percentile is a statistical value that indicates that a 741 certain percentage of a set of data falls below it."; 742 } 744 grouping vpn-summary-statistics { 745 description 746 "VPN Statistics grouping used for network topology 747 augmentation."; 748 container vpn-summary-statistics { 749 description 750 "Container for VPN summary statistics."; 751 container ipv4 { 752 leaf total-routes { 753 type uint32; 754 description 755 "Total routes for the VPN."; 756 } 757 leaf total-active-routes { 758 type uint32; 759 description 760 "Total active routes for the VPN."; 761 } 762 description 763 "IPv4-specific parameters."; 764 } 765 container ipv6 { 766 leaf total-routes { 767 type uint32; 768 description 769 "Total routes for the VPN."; 770 } 771 leaf total-active-routes { 772 type uint32; 773 description 774 "Total active routes for the VPN."; 775 } 776 description 777 "IPv6-specific parameters."; 778 } 779 } 780 } 781 grouping link-error-statistics { 782 description 783 "Grouping for per link error statistics."; 784 container loss-statistics { 785 description 786 "Per link loss statistics."; 787 leaf packet-loss-count { 788 type yang:counter32; 789 description 790 "Total received packet drops count."; 791 } 792 leaf packet-reorder-count { 793 type yang:counter32; 794 description 795 "Total received packet reordered count."; 796 } 797 leaf packets-out-of-seq-count { 798 type yang:counter32; 799 description 800 "Total received out of sequence count."; 801 } 802 leaf packets-dup-count { 803 type yang:counter32; 804 description 805 "Total received packet duplicates count."; 806 } 807 leaf loss-ratio { 808 type percentage; 809 description 810 "Loss ratio of the packets. Express as percentage 811 of packets lost with respect to packets sent."; 812 } 813 } 814 } 816 grouping link-delay-statistics { 817 description 818 "Grouping for per link delay statistics"; 819 container delay-statistics { 820 description 821 "Link delay summarised information. By default, 822 one way measurement protocol (e.g., OWAMP) is used 823 to measure delay."; 824 leaf direction { 825 type identityref { 826 base direction; 827 } 828 default "one-way"; 829 description 830 "Define measurement direction including one way 831 measurement and two way measurement."; 832 } 833 leaf unit-value { 834 type identityref { 835 base lime:time-unit-type; 836 } 837 default "lime:milliseconds"; 838 description 839 "Time units, where the options are s, ms, ns, etc."; 840 } 841 leaf min-delay-value { 842 type yang:gauge64; 843 description 844 "Minimum delay value observed."; 845 } 846 leaf max-delay-value { 847 type yang:gauge64; 848 description 849 "Maximum delay value observed."; 850 } 851 leaf low-delay-percentile { 852 type yang:gauge64; 853 description 854 "Low percentile of the delay observed with 855 specific measurement method."; 856 } 857 leaf middle-delay-percentile { 858 type yang:gauge64; 859 description 860 "Middle percentile of the delay observed with 861 specific measurement method."; 862 } 863 leaf high-delay-percentile { 864 type yang:gauge64; 865 description 866 "High percentile of the delay observed with 867 specific measurement method."; 868 } 869 } 870 } 872 grouping link-jitter-statistics { 873 description 874 "Grouping for per link jitter statistics"; 875 container jitter-statistics { 876 description 877 "Link jitter summarised information. By default, 878 jitter is measured using IP Packet Delay Variation 879 (IPDV)."; 880 leaf unit-value { 881 type identityref { 882 base lime:time-unit-type; 883 } 884 default "lime:milliseconds"; 885 description 886 "Time units, where the options are s, ms, ns, etc."; 887 } 888 leaf min-jitter-value { 889 type yang:gauge32; 890 description 891 "Minimum jitter value observed."; 892 } 893 leaf max-jitter-value { 894 type yang:gauge32; 895 description 896 "Maximum jitter value observed."; 897 } 898 leaf low-jitter-percentile { 899 type yang:gauge32; 900 description 901 "Low percentile of the jitter observed."; 902 } 903 leaf middle-jitter-percentile { 904 type yang:gauge32; 905 description 906 "Middle percentile of the jitter observed."; 907 } 908 leaf high-jitter-percentile { 909 type yang:gauge32; 910 description 911 "High percentile of the jitter observed."; 912 } 913 } 914 } 916 grouping tp-svc-telemetry { 917 leaf inbound-octets { 918 type yang:counter64; 919 description 920 "The total number of octets received on the 921 interface, including framing characters."; 922 } 923 leaf inbound-unicast { 924 type yang:counter64; 925 description 926 "Inbound unicast packets were received, and delivered 927 to a higher layer during the last period."; 928 } 929 leaf inbound-nunicast { 930 type yang:counter64; 931 description 932 "The number of non-unicast (i.e., subnetwork- 933 broadcast or subnetwork-multicast) packets 934 delivered to a higher-layer protocol."; 935 } 936 leaf inbound-discards { 937 type yang:counter32; 938 description 939 "The number of inbound packets which were chosen 940 to be discarded even though no errors had been 941 detected to prevent their being deliverable to a 942 higher-layer protocol."; 943 } 944 leaf inbound-errors { 945 type yang:counter32; 946 description 947 "The number of inbound packets that contained 948 errors preventing them from being deliverable to a 949 higher-layer protocol."; 950 } 951 leaf inbound-unknown-protocol { 952 type yang:counter32; 953 description 954 "The number of packets received via the interface 955 which were discarded because of an unknown or 956 unsupported protocol."; 957 } 958 leaf outbound-octets { 959 type yang:counter64; 960 description 961 "The total number of octets transmitted out of the 962 interface, including framing characters."; 963 } 964 leaf outbound-unicast { 965 type yang:counter64; 966 description 967 "The total number of packets that higher-level 968 protocols requested be transmitted to a 969 subnetwork-unicast address, including those that 970 were discarded or not sent."; 971 } 972 leaf outbound-nunicast { 973 type yang:counter64; 974 description 975 "The total number of packets that higher-level 976 protocols requested be transmitted to a non- 977 unicast (i.e., a subnetwork-broadcast or 978 subnetwork-multicast) address, including those 979 that were discarded or not sent."; 980 } 981 leaf outbound-discards { 982 type yang:counter32; 983 description 984 "The number of outbound packets which were chosen 985 to be discarded even though no errors had been 986 detected to prevent their being transmitted. One 987 possible reason for discarding such a packet could 988 be to free up buffer space."; 989 } 990 leaf outbound-errors { 991 type yang:counter32; 992 description 993 "The number of outbound packets that contained 994 errors preventing them from being deliverable to a 995 higher-layer protocol."; 996 } 997 leaf outbound-qlen { 998 type uint32; 999 description 1000 " Length of the queue of the interface from where 1001 the packet is forwarded out. The queue depth could 1002 be the current number of memory buffers used by the 1003 queue and a packet can consume one or more memory buffers 1004 thus constituting device-level information."; 1005 } 1006 description 1007 "Grouping for interface service telemetry."; 1008 } 1010 augment "/nw:networks/nw:network/nw:network-types" { 1011 description 1012 "Defines the service topologyies types"; 1013 container network-service-type { 1014 presence "Indicates Network service topology"; 1015 leaf network-service-type { 1016 type identityref { 1017 base vpn-common:service-type; 1018 } 1019 description 1020 "The presence identifies the network service type, 1021 e.g., L3VPN, L2VPN, etc."; 1022 } 1023 description 1024 "Container for vpn service type."; 1025 } 1026 } 1028 augment "/nw:networks/nw:network" { 1029 when 'nw:network-types/nvp:network-service-type' { 1030 description 1031 "Augment only for VPN Network topology."; 1032 } 1033 description 1034 "Augment the network with service topology attributes"; 1035 container vpn-topo-attributes { 1036 leaf vpn-id { 1037 type vpn-common:vpn-id; 1038 description 1039 "Pointer to the parent VPN service(e.g., L3NM), 1040 if any."; 1041 } 1042 leaf vpn-topology { 1043 type identityref { 1044 base vpn-common:vpn-topology; 1045 } 1046 description 1047 "VPN service topology, e.g., hub-spoke, any-to-any, 1048 hub-spoke-disjoint"; 1049 } 1050 description 1051 "Container for vpn topology attributes."; 1052 } 1053 } 1055 augment "/nw:networks/nw:network/nw:node" { 1056 when '../nw:network-types/nvp:network-service-type' { 1057 description 1058 "Augment only for VPN Network topology."; 1059 } 1060 description 1061 "Augment the network node with service topology attributes"; 1062 container node-attributes { 1063 leaf node-type { 1064 type identityref { 1065 base vpn-common:role; 1066 } 1067 description 1068 "Node type, e.g., PE, P, ASBR."; 1070 } 1071 leaf site-id { 1072 type string; 1073 description 1074 "Associated vpn site"; 1075 } 1076 leaf site-role { 1077 type identityref { 1078 base vpn-common:role; 1079 } 1080 default "vpn-common:any-to-any-role"; 1081 description 1082 "Role of the site in the VPN."; 1083 } 1084 description 1085 "Container for service topology attributes."; 1086 } 1087 uses vpn-summary-statistics; 1088 } 1090 augment "/nw:networks/nw:network/nt:link" { 1091 when '../nw:network-types/nvp:network-service-type' { 1092 description 1093 "Augment only for VPN Network topology."; 1094 } 1095 description 1096 "Augment the network topology link with service topology 1097 attributes"; 1098 leaf link-type { 1099 type identityref { 1100 base vpn-common:protocol-type; 1101 } 1102 description 1103 "Underlay-transport type, e.g., GRE, LDP, etc."; 1104 } 1105 } 1107 augment "/nw:networks/nw:network/nt:link" { 1108 description 1109 "Augment the network topology link with service topology 1110 attributes"; 1111 leaf low-percentile { 1112 type percentile; 1113 default "10.00"; 1114 description 1115 "Low percentile to report. Setting low-percentile 1116 into 0.00 indicates the client is not interested in receiving 1117 low percentile."; 1119 } 1120 leaf middle-percentile { 1121 type percentile; 1122 default "50.00"; 1123 description 1124 "Middle percentile to report. Setting middle-percentile 1125 into 0.00 indicates the client is not interested in receiving 1126 middle percentile."; 1127 } 1128 leaf high-percentile { 1129 type percentile; 1130 default "90.00"; 1131 description 1132 "High percentile to report. Setting high-percentile 1133 into 0.00 indicates the client is not interested in receiving 1134 high percentile"; 1135 } 1136 leaf reference-time { 1137 type yang:date-and-time; 1138 description 1139 "The time that the current Measurement Interval started."; 1140 } 1141 leaf measurement-interval { 1142 type uint32; 1143 units "seconds"; 1144 default "60"; 1145 description 1146 "Interval to calculate performance metric."; 1147 } 1148 container link-telemetry-attributes { 1149 config false; 1150 uses link-error-statistics; 1151 uses link-delay-statistics; 1152 uses link-jitter-statistics; 1153 description 1154 "Container for service telemetry attributes."; 1155 } 1156 } 1158 augment "/nw:networks/nw:network/nw:node/nt:termination-point" { 1159 description 1160 "Augment the network topology termination point with vpn 1161 service attributes"; 1162 container tp-telemetry-attributes { 1163 config false; 1164 uses tp-svc-telemetry; 1165 description 1166 "Container for termination point service telemetry attributes."; 1168 } 1169 } 1170 } 1171 1173 8. Security Considerations 1175 The YANG modules defined in this document MAY be accessed via the 1176 RESTCONF protocol [RFC8040] or NETCONF protocol [RFC6241]. The 1177 lowest RESTCONF or NETCONF layer requires that the transport-layer 1178 protocol provides both data integrity and confidentiality, see 1179 Section 2 in [RFC8040] and [RFC6241]. The lowest NETCONF layer is 1180 the secure transport layer, and the mandatory-to-implement secure 1181 transport is Secure Shell (SSH)[RFC6242] . The lowest RESTCONF layer 1182 is HTTPS, and the mandatory-to-implement secure transport is TLS 1183 [RFC8446]. 1185 The NETCONF access control model [RFC8341] provides the means to 1186 restrict access for particular NETCONF or RESTCONF users to a 1187 preconfigured subset of all available NETCONF or RESTCONF protocol 1188 operations and content. 1190 There are a number of data nodes defined in this YANG module that are 1191 writable/creatable/deletable (i.e., config true, which is the 1192 default). These data nodes may be considered sensitive or vulnerable 1193 in some network environments. Write operations (e.g., edit-config) 1194 to these data nodes without proper protection can have a negative 1195 effect on network operations. These are the subtrees and data nodes 1196 and their sensitivity/vulnerability: 1198 o /nw:networks/nw:network/svc-topo:svc-telemetry-attributes 1200 o /nw:networks/nw:network/nw:node/svc-topo:node-attributes 1202 9. IANA Considerations 1204 This document requests IANA to register the following URI in the "ns" 1205 subregistry within the "IETF XML Registry" [RFC3688]: 1207 URI: urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm 1208 Registrant Contact: The IESG. 1209 XML: N/A, the requested URI is an XML namespace. 1211 This document requests IANA to register the following YANG module in 1212 the "YANG Module Names" subregistry [RFC6020] within the "YANG 1213 Parameters" registry. 1215 Name: ietf-network-vpn-pm 1216 Namespace: urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm 1217 Maintained by IANA: N 1218 Prefix: nvp 1219 Reference: RFC XXXX 1221 10. Acknowledgements 1223 Thanks to Joe Clarke, Adrian Farrel, Greg Mirsky,Roque Gagliano,Erez 1224 Segev for reviewing this draft and providing important input to this 1225 document. 1227 11. Contributors 1229 Michale Wang 1230 Huawei 1231 Email:wangzitao@huawei.com 1233 Roni Even 1234 Huawei 1235 Email: ron.even.tlv@gmail.com 1237 12. References 1239 12.1. Normative References 1241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1242 Requirement Levels", BCP 14, RFC 2119, 1243 DOI 10.17487/RFC2119, March 1997, 1244 . 1246 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1247 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1248 DOI 10.17487/RFC3393, November 2002, 1249 . 1251 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1252 DOI 10.17487/RFC3688, January 2004, 1253 . 1255 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1256 the Network Configuration Protocol (NETCONF)", RFC 6020, 1257 DOI 10.17487/RFC6020, October 2010, 1258 . 1260 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1261 and A. Bierman, Ed., "Network Configuration Protocol 1262 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1263 . 1265 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1266 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1267 . 1269 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 1270 Measurement for MPLS Networks", RFC 6374, 1271 DOI 10.17487/RFC6374, September 2011, 1272 . 1274 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1275 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1276 . 1278 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1279 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1280 . 1282 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1283 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1284 May 2017, . 1286 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 1287 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 1288 DOI 10.17487/RFC8299, January 2018, 1289 . 1291 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1292 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1293 . 1295 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1296 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1297 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1298 2018, . 1300 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1301 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1302 . 1304 [RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S. 1305 Raghavan, "Generic YANG Data Model for the Management of 1306 Operations, Administration, and Maintenance (OAM) 1307 Protocols That Use Connectionless Communications", 1308 RFC 8532, DOI 10.17487/RFC8532, April 2019, 1309 . 1311 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1312 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1313 September 2019, . 1315 12.2. Informative References 1317 [I-D.ietf-opsawg-l3sm-l3nm] 1318 barguil, s., Dios, O., Boucadair, M., Munoz, L., and A. 1319 Aguado, "A Layer 3 VPN Network YANG Model", draft-ietf- 1320 opsawg-l3sm-l3nm-05 (work in progress), October 2020. 1322 [I-D.ietf-opsawg-model-automation-framework] 1323 WU, Q., Boucadair, M., Lopez, D., Xie, C., and L. Geng, "A 1324 Framework for Automating Service and Network Management 1325 with YANG", draft-ietf-opsawg-model-automation- 1326 framework-10 (work in progress), October 2020. 1328 [I-D.ietf-opsawg-vpn-common] 1329 barguil, s., Dios, O., Boucadair, M., and Q. WU, "A Layer 1330 2/3 VPN Common YANG Model", draft-ietf-opsawg-vpn- 1331 common-03 (work in progress), January 2021. 1333 [RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., 1334 and A. Gonguet, "Framework for Layer 3 Virtual Private 1335 Networks (L3VPN) Operations and Management", RFC 4176, 1336 DOI 10.17487/RFC4176, October 2005, 1337 . 1339 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1340 Previdi, "OSPF Traffic Engineering (TE) Metric 1341 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1342 . 1344 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1345 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1346 . 1348 [RFC8194] Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for 1349 LMAP Measurement Agents", RFC 8194, DOI 10.17487/RFC8194, 1350 August 2017, . 1352 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, 1353 "Extensions to the Path Computation Element Communication 1354 Protocol (PCEP) to Compute Service-Aware Label Switched 1355 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 1356 2017, . 1358 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1359 Access Control Model", STD 91, RFC 8341, 1360 DOI 10.17487/RFC8341, March 2018, 1361 . 1363 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 1364 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 1365 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 1366 2019, . 1368 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 1369 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 1370 IGP Traffic Engineering Performance Metric Extensions", 1371 RFC 8571, DOI 10.17487/RFC8571, March 2019, 1372 . 1374 Authors' Addresses 1376 Bo Wu 1377 Huawei 1378 101 Software Avenue, Yuhua District 1379 Nanjing, Jiangsu 210012 1380 China 1382 Email: lana.wubo@huawei.com 1384 Qin Wu 1385 Huawei 1386 101 Software Avenue, Yuhua District 1387 Nanjing, Jiangsu 210012 1388 China 1390 Email: bill.wu@huawei.com 1392 Mohamed Boucadair 1393 Orange 1394 Rennes 35000 1395 France 1397 Email: mohamed.boucadair@orange.com 1398 Oscar Gonzalez de Dios 1399 Telefonica 1400 Madrid 1401 ES 1403 Email: oscar.gonzalezdedios@telefonica.com 1405 Bin Wen 1406 Comcast 1408 Email: bin_wen@comcast.com 1410 Change Liu 1411 China Unicom 1413 Email: liuc131@chinaunicom.cn 1415 Honglei Xu 1416 China Telecom 1418 Email: xuhl.bri@chinatelecom.cn