idnits 2.17.1 draft-www-opsawg-yang-vpn-service-pm-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 29 instances of too long lines in the document, the longest one being 28 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1042 has weird spacing: '...Network topol...' -- The document date (November 2, 2020) is 1271 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: 'RFC8194' is mentioned on line 167, but not defined == Missing Reference: 'RFC8040' is mentioned on line 1181, but not defined == Missing Reference: 'RFC5246' is mentioned on line 1185, but not defined ** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446) == Unused Reference: 'RFC6370' is defined on line 1270, but no explicit reference was found in the text == Unused Reference: 'RFC7923' is defined on line 1289, but no explicit reference was found in the text == Unused Reference: 'RFC7950' is defined on line 1294, but no explicit reference was found in the text == Unused Reference: 'RFC7952' is defined on line 1298, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) ** Downref: Normative reference to an Informational RFC: RFC 7923 -- Obsolete informational reference (is this intentional?): RFC 7810 (Obsoleted by RFC 8570) Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). 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: May 6, 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 November 2, 2020 17 A YANG Model for Network and VPN Service Performance Monitoring 18 draft-www-opsawg-yang-vpn-service-pm-02 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 May 6, 2021. 53 Copyright Notice 55 Copyright (c) 2020 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 . . . . . . . . 13 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 151 As shown in figure 1, the Network and VPN Service PM Model can be 152 used to expose some performance information to the above layer. The 153 information can be used by the Orchestrator to subscribe to 154 performance data. The Controller will then notify the Orchestrator 155 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] [RFC7810] [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 [I-D.ietf-netconf-yang-push] to subscribe to the 177 specific Network performance data or VPN service performance data 178 they are interested 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 182 [I-D.ietf-netconf-yang-push] to distribute specific telemetry data to 183 target recipients. 185 3.2. On demand Retrieval via RPC Model 187 To obtain a snapshot of a large amount of performance data from a 188 network element (including network controllers), service-assurance 189 applications may use polling-based methods such as RPC model to fetch 190 performance data on demand. 192 4. Description of the Data Model 194 This document defines the YANG module "ietf-network-vpn-pm", which is 195 an augmentation to the "ietf-network" and "ietf-network-topology". 197 The performance monitoring data is augmented to service topology as 198 shown in Figure 1. 200 +----------------------+ +-----------------------+ 201 |ietf-network | |Network and VPN Service| 202 |ietf-network-topology |<---------|Performance Monitoring | 203 +----------------------+ augments | Model | 204 +-----------------------+ 206 Figure 1: Module Augmentation 208 [RFC8345]defines a YANG data model for network/service topologies and 209 inventories. The service topology described in [RFC8345] includes 210 the virtual topology for a service layer above Layer 1 (L1), Layer 2 211 (L2), and Layer 3 (L3). This service topology has the generic 212 topology elements of node, link, and terminating point. One typical 213 example of a service topology is described in Figure 3 of [RFC8345]: 214 two VPN service topologies instantiated over a common L3 topology. 215 Each VPN service topology is mapped onto a subset of nodes from the 216 common L3 topology. 218 4.1. Layering Relationship Between Multiple Layers of Topology 220 The data model defined in [RFC8345] can describe vertical layering 221 relationships between networks. That model can be augmented to cover 222 network/service topologies. 224 Figure 2 illustrates an example of a topology mapping between the VPN 225 service topology and an underlying network: 227 VPN-SVC 1 VPN-SVC 2 228 / \ 229 VPN-Service-topology 1 VPN-Service-topology-2 230 / | \ / | \ 231 Site-1A Site-1B Site1-C Site-2A Site-2B Site-2C Top-Down 232 | | | | | | Service Topology 233 CE CE CE CE CE CE 234 | | | | | | 235 PE PE PE PE PE PE 236 ====|==========|=======|=======|=========|=====|====================== 237 +-------+ | \ / / | 238 Bottom-up | | \ / / | 239 Network | | /\ / | 240 topology | | / \ | | 241 | | | | | | 242 node1 node2 node3 node4 node5 node6 244 Figure 2: Example of topology mapping between VPN Service Topo and 245 Underlying network 247 As shown in Figure 2, two VPN services topologies are both built on 248 top of one common underlying physical network: 250 o VPN-SVC 1: supporting "hub-spoke" communications for Customer 1 251 connecting the customer's access at 3 sites. Site-1A, Site-1B, 252 and Site-1C are connected to PEs that are mapped to nodes 1, 2, 253 and 3 in the underlying physical network. 255 Site-1 A plays the role of hub while Site-2 B and C plays the role 256 of spoke. 258 o VPN-SVC 2: supporting "hub-spoke disjoint" communications for 259 Customer 2 connecting the customer's access at 3 sites. Site-2A, 260 Site-2B, and Site-2C are connected to PEs that are mapped to nodes 261 4, 5, and 6 in the underlying physical network. 263 Site-2 A and B play the role of hub while Site-2 C plays the role 264 of spoke. 266 4.2. Network Level 268 For network performance monitoring, the attributes of "Network Level" 269 that defined in [RFC8345] do not need to be extended. 271 For VPN service performance monitoring, this document defines some 272 new network type: "L3VPN, L2VPN". When a network topology data 273 instance contains the L3VPN or L2VPN network type, it represents an 274 VPN instance that can perform performance monitoring. 276 This model defines only the following minimal set of Network level 277 network topology attributes: 279 o "l3nm-vpn-id": Refers to an identifier of L3NM service. This 280 identifier allows to correlate the performance status with the 281 network service configuration. 283 o "vpn-topo": The type of VPN service topology, this model supports 284 "any-to-any", "Hub and Spoke" (where Hubs can exchange traffic), 285 and "Hub and Spoke disjoint" (where Hubs cannot exchange traffic). 286 [RFC8299] defines a YANG model for L3VPN Service Delivery. Three 287 types of VPN service topologies are supported in : "any to any", 288 "hub and spoke", and "hub and spoke disjoint". These VPN topology 289 types can be used to describe how VPN sites communicate with each 290 other. 292 module: ietf-network-vpn-pm 293 augment /nw:networks/nw:network/nw:network-types: 294 +--rw network-service-type! 295 +--rw network-service-type? identityref 296 augment /nw:networks/nw:network: 297 +--rw vpn-topo-attributes 298 +--rw l3nm-vpn-id? vpn-common:vpn-id 299 +--rw vpn-topology? identityref 301 Figure 3: Network Level View of the hierarchies 303 4.3. Node Level 305 For network performance monitoring, the attributes of "Node Level" 306 that defined in [RFC8345] do not need to be extended. 308 For VPN service performance monitoring, this model defines only the 309 following minimal set of Node level network topology attributes: 311 o "node-type" (Attribute): Indicates the type of the node, such as 312 PE or ASBR. This "node-type" can be used to report performance 313 metric between any two nodes each with specific node-type. 315 o "site-id" (Constraint): Uniquely identifies the site within the 316 overall network infrastructure. 318 o "site-role" (Constraint): Defines the role of the site in a 319 particular VPN topology. 321 o "vpn-summary-statistics": IPv4 statistics, and IPv6 statisticshave 322 been specified separately. And MAC statistics could be extended 323 for L2VPN. 325 augment /nw:networks/nw:network/nw:node: 326 +--rw node-attributes 327 | +--rw node-type? identityref 328 | +--rw site-id? string 329 | +--rw site-role? identityref 330 +--rw vpn-summary-statistics 331 +--rw ipv4 332 | +--rw total-routes? uint32 333 | +--rw total-active-routes? uint32 334 +--rw ipv6 335 +--rw total-routes? uint32 336 +--rw total-active-routes? uint32 338 Figure 4: Node Level View of the hierarchies 340 4.4. Link and Termination Point Level 342 The link nodes are classified into two types: one is topology link 343 defined in [RFC8345] , and the other is abstract link of a VPN 344 between PEs. 346 The performance statistics of the topology links can be based on BGP- 347 LS [RFC8571]. The statistics of the VPN abstract links can be 348 collected based on VPN OAM mechanisms, e.g. TWAMP etc. 349 Alternatively, the data cen based on the underlay technology OAM 350 mechanism, for example, GRE tunnel OAM. 352 "link-type": Refers to an identifier of L3NM "underlay-transport". 353 This identifier describes the transport technology to carry the 354 traffic of the VPN service. 356 augment /nw:networks/nw:network/nt:link: 357 +--rw link-type? identityref 358 augment /nw:networks/nw:network/nt:link: 359 +--rw low-percentile percentile 360 +--rw high-percentile percentile 361 +--rw middle-percentile percentile 362 +--ro reference-time yang:date-and-time 363 +--ro measurement-interval uint32 364 +--ro link-telemetry-attributes 365 +--ro loss-statistics 366 | +--ro packet-loss-count? uint32 367 | +--ro loss-ratio? percentage 368 | +--ro packet-reorder-count? uint32 369 | +--ro packets-out-of-seq-count? uint32 370 | +--ro packets-dup-count? uint32 371 +--ro delay-statistics 372 | +--ro direction? identityref 373 | +--ro unit-value identityref 374 | +--ro min-delay-value? yang:gauge64 375 | +--ro max-delay-value? yang:gauge64 376 | +--ro high-delay-percentile? yang:gauge64 377 | +--ro middle-delay-percentile? yang:gauge64 378 | +--ro low-delay-percentile? yang:gauge64 379 +--ro jitter-statistics 380 +--ro unit-value identityref 381 +--ro min-jitter-value? yang:gauge64 382 +--ro max-jitter-value? yang:gauge64 383 +--ro low-jitter-percentile? yang:gauge64 384 +--ro high-jitter-percentile? yang:gauge64 385 +--ro middle-jitter-percentile? yang:gauge64 386 augment /nw:networks/nw:network/nw:node/nt:termination-point: 387 +--ro tp-telemetry-attributes 388 +--ro in-octets? uint32 389 +--ro out-octets? uint32 390 +--ro inbound-unicast? uint32 391 +--ro inbound-nunicast? uint32 392 +--ro inbound-discards? uint32 393 +--ro inbound-errors? uint32 394 +--ro in-unknown-protocol? uint32 395 +--ro outbound-unicast? uint32 396 +--ro outbound-nunicast? uint32 397 +--ro outbound-discards? uint32 398 +--ro outbound-errors? uint32 399 +--ro outbound-qlen? uint32 401 Figure 5: Link and Termination point Level View of the hierarchies 403 The Network and VPN service performance monitoring model defines only 404 the following minimal set of Link level network topology attributes: 406 o "link-type" (Attribute): Indicates the type of the link, such as 407 GRE or IP-in-IP. 409 o "low-percentile": Indicates low percentile to report. Setting 410 low-percentile into 0.00 indicates the client is not interested in 411 receiving low percentile. 413 o "middle-percentile": Indicates middle percentile to report. 414 Setting middle-percentile into 0.00 indicates the client is not 415 interested in receiving middle percentile. 417 o "high-percentile": Indicates high percentile to report. Setting 418 low-percentile into 0.00 indicates the client is not interested in 419 receiving high percentile. 421 o Loss Statistics: A set of loss statistics attributes that are used 422 to measure end to end loss between VPN sites or between any two 423 network nodes. 425 o Delay Statistics: A set of delay statistics attributes that are 426 used to measure end to end latency between VPN sites or between 427 any two network nodes.. 429 o Jitter Statistics: A set of IP Packet Delay Variation [RFC3393] 430 statistics attributes that are used to measure end to end jitter 431 between VPN sites or between any two network nodes.. 433 The Network and VPN service performance monitoring defines the 434 following minimal set of Termination point level network topology 435 attributes: 437 o Inbound statistics: A set of inbound statistics attributes that 438 are used to measure the inbound statistics of the termination 439 point, such as "the total number of octets received on the 440 termination point", "The number of inbound packets which were 441 chosen to be discarded", "The number of inbound packets that 442 contained errors", etc. 444 o Outbound statistics: A set of outbound statistics attributes that 445 are used to measure the outbound statistics of the termination 446 point, such as "the total number of octets transmitted out of the 447 termination point", "The number of outbound packets which were 448 chosen to be discarded", "The number of outbound packets that 449 contained errors", etc. 451 5. Example of I2RS Pub/Sub Retrieval 453 This example shows the way for a client to subscribe for the 454 Performance monitoring information between node A and node B in the 455 L3 network topology built on top of the underlying network . The 456 performance monitoring parameter that the client is interested in is 457 end to end loss attribute. 459 461 463 464 465 466 l3-network 467 468 L3VPN 469 470 471 A 472 473 pe 474 475 476 1-0-1 477 478 100 479 150 480 481 482 483 484 B 485 486 pe 487 488 489 2-0-1 490 491 150 492 100 493 494 495 496 497 A-B 498 499 A 500 501 502 B 503 504 mpls-te 505 507 508 100 509 510 511 512 513 514 515 500 516 517 519 6. Example of RPC-based Retrieval 521 This example shows the way for the client to use RPC model to fetch 522 performance data on demand, e.g., the client requests "packet-loss- 523 count" between PE1 in site 1 and PE2 in site 2 belonging to the same 524 VPN1. 526 528 529 530 531 vpn1 532 533 A 534 535 pe 536 537 538 1-0-1 539 540 100 541 150 542 543 544 545 546 B 547 548 pe 549 550 551 2-0-1 552 553 150 554 100 555 556 557 558 A-B 559 560 A 561 562 563 B 564 565 mpls-te 566 567 568 120 569 570 571 572 573 574 576 7. Network and VPN Service Assurance YANG Module 578 This module uses types defined in [RFC8345], [RFC8299] and [RFC8532]. 580 file "ietf-network-vpn-pm@2020-10-30.yang" 581 module ietf-network-vpn-pm { 582 yang-version 1.1; 583 namespace "urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm"; 584 prefix nvp; 586 import ietf-yang-types { 587 prefix yang; 588 reference 589 "RFC 6991: Common YANG Types."; 590 } 591 import ietf-vpn-common { 592 prefix vpn-common; 593 } 594 import ietf-network { 595 prefix nw; 596 reference 597 "Section 6.1 of RFC 8345: A YANG Data Model for Network 598 Topologies"; 599 } 600 import ietf-network-topology { 601 prefix nt; 602 reference 603 "Section 6.2 of RFC 8345: A YANG Data Model for Network 604 Topologies"; 605 } 606 import ietf-lime-time-types { 607 prefix lime; 608 reference 609 "RFC 8532: Generic YANG Data Model for the Management of 610 Operations, Administration, and Maintenance (OAM) Protocols 611 That Use Connectionless Communications"; 612 } 614 organization 615 "IETF OPSAWG Working Group"; 616 contact 617 "Editor: Qin Wu 618 619 Editor: Mohamed Boucadair 620 "; 621 description 622 "This module defines a model for Network and VPN Service Performance 623 monitoring. 625 Copyright (c) 2020 IETF Trust and the persons identified as 626 authors of the code. All rights reserved. 628 Redistribution and use in source and binary forms, with or 629 without modification, is permitted pursuant to, and subject 630 to the license terms contained in, the Simplified BSD License 631 set forth in Section 4.c of the IETF Trust's Legal Provisions 632 Relating to IETF Documents 633 (http://trustee.ietf.org/license-info). 635 This version of this YANG module is part of RFC XXXX; see 636 the RFC itself for full legal notices."; 638 revision 2020-10-28 { 639 description 640 "Initial revision."; 641 reference 642 "RFC XXXX: A YANG Model for Network and VPN Service Performance 643 Monitoring"; 644 } 646 identity pe { 647 base vpn-common:role; 648 description 649 "Identity for PE type"; 650 } 652 identity ce { 653 base vpn-common:role; 654 description 655 "Identity for CE type"; 656 } 658 identity asbr { 659 base vpn-common:role; 660 description 661 "Identity for ASBR type"; 662 } 664 identity p { 665 base vpn-common:role; 666 description 667 "Identity for P type"; 668 } 670 identity link-type { 671 base vpn-common:protocol-type; 672 description 673 "Base identity for link type, e.g.,GRE, MPLS TE, VXLAN."; 674 } 676 identity VXLAN { 677 base link-type; 678 description 679 "Base identity for VXLAN Tunnel."; 680 } 682 identity ip-in-ip { 683 base link-type; 684 description 685 "Base identity for IP in IP Tunnel."; 686 } 688 identity direction { 689 description 690 "Base Identity for measurement direction including 691 one way measurement and two way measurement."; 692 } 694 identity one-way { 695 base direction; 696 description 697 "Identity for one way measurement."; 698 } 700 identity two-way { 701 base direction; 702 description 703 "Identity for two way measurement."; 704 } 706 typedef percentage { 707 type decimal64 { 708 fraction-digits 5; 709 range "0..100"; 710 } 711 description 712 "Percentage."; 713 } 715 typedef percentile { 716 type decimal64 { 717 fraction-digits 2; 718 } 719 description 720 "The nth percentile of a set of data is the 721 value at which n percent of the data is below it."; 722 } 724 grouping vpn-summary-statistics { 725 description 726 "VPN Statistics grouping used for network topology 727 augmentation."; 728 container vpn-summary-statistics { 729 description 730 "Container for VPN summary statistics."; 731 container ipv4 { 732 leaf total-routes { 733 type uint32; 734 description 735 "Total routes in the RIB from all protocols."; 736 } 737 leaf total-active-routes { 738 type uint32; 739 description 740 "Total active routes in the RIB."; 741 } 742 description 743 "IPv4-specific parameters."; 744 } 745 container ipv6 { 746 leaf total-routes { 747 type uint32; 748 description 749 "Total routes in the RIB from all protocols."; 750 } 751 leaf total-active-routes { 752 type uint32; 753 description 754 "Total active routes in the RIB."; 755 } 756 description 757 "IPv6-specific parameters."; 758 } 759 } 760 } 762 grouping link-error-statistics { 763 description 764 "Grouping for per link error statistics."; 765 container loss-statistics { 766 description 767 "Per link loss statistics."; 768 leaf packet-loss-count { 769 type uint32 { 770 range "0..4294967295"; 771 } 772 default "0"; 773 description 774 "Total received packet drops count. 775 The value of count will be set to zero (0) 776 on creation and will thereafter increase 777 monotonically until it reaches a maximum value 778 of 2^32-1 (4294967295 decimal), when it wraps 779 around and starts increasing again from zero."; 780 } 781 leaf loss-ratio { 782 type percentage; 783 description 784 "Loss ratio of the packets. Express as percentage 785 of packets lost with respect to packets sent."; 786 } 787 leaf packet-reorder-count { 788 type uint32 { 789 range "0..4294967295"; 790 } 791 default "0"; 792 description 793 "Total received packet reordered count. 794 The value of count will be set to zero (0) 795 on creation and will thereafter increase 796 monotonically until it reaches a maximum value 797 of 2^32-1 (4294967295 decimal), when it wraps 798 around and starts increasing again from zero."; 799 } 800 leaf packets-out-of-seq-count { 801 type uint32 { 802 range "0..4294967295"; 803 } 804 description 805 "Total received out of sequence count. 806 The value of count will be set to zero (0) 807 on creation and will thereafter increase 808 monotonically until it reaches a maximum value 809 of 2^32-1 (4294967295 decimal), when it wraps 810 around and starts increasing again from zero.."; 811 } 812 leaf packets-dup-count { 813 type uint32 { 814 range "0..4294967295"; 815 } 816 description 817 "Total received packet duplicates count. 818 The value of count will be set to zero (0) 819 on creation and will thereafter increase 820 monotonically until it reaches a maximum value 821 of 2^32-1 (4294967295 decimal), when it wraps 822 around and starts increasing again from zero."; 823 } 824 } 825 } 827 grouping link-delay-statistics { 828 description 829 "Grouping for per link delay statistics"; 830 container delay-statistics { 831 description 832 "Link delay summarised information. By default, 833 one way measurement protocol (e.g., OWAMP) is used 834 to measure delay."; 836 leaf direction { 837 type identityref { 838 base direction; 839 } 840 default "one-way"; 841 description 842 "Define measurement direction including one way 843 measurement and two way measurement."; 844 } 845 leaf unit-value { 846 type identityref { 847 base lime:time-unit-type; 848 } 849 default "lime:milliseconds"; 850 description 851 "Time units, where the options are s, ms, ns, etc."; 852 } 853 leaf min-delay-value { 854 type yang:gauge64; 855 description 856 "Minimum delay value observed."; 857 } 858 leaf max-delay-value { 859 type yang:gauge64; 860 description 861 "Maximum delay value observed."; 862 } 863 leaf low-delay-percentile { 864 type yang:gauge64; 865 description 866 "Low percentile of the delay observed with 867 specific measurement method."; 868 } 869 leaf middle-delay-percentile { 870 type yang:gauge64; 871 description 872 "Middle percentile of the delay observed with 873 specific measurement method."; 874 } 875 leaf high-delay-percentile { 876 type yang:gauge64; 877 description 878 "High percentile of the delay observed with 879 specific measurement method."; 880 } 881 } 882 } 883 grouping link-jitter-statistics { 884 description 885 "Grouping for per link jitter statistics"; 886 container jitter-statistics { 887 description 888 "Link jitter summarised information. By default, 889 jitter is measured using IP Packet Delay Variation 890 (IPDV)."; 891 leaf unit-value { 892 type identityref { 893 base lime:time-unit-type; 894 } 895 default "lime:milliseconds"; 896 description 897 "Time units, where the options are s, ms, ns, etc."; 898 } 899 leaf min-jitter-value { 900 type yang:gauge64; 901 description 902 "Minimum jitter value observed."; 903 } 904 leaf max-jitter-value { 905 type yang:gauge64; 906 description 907 "Maximum jitter value observed."; 908 } 909 leaf low-jitter-percentile { 910 type yang:gauge64; 911 description 912 "Low percentile of the jitter observed."; 913 } 914 leaf middle-jitter-percentile { 915 type yang:gauge64; 916 description 917 "Middle percentile of the jitter observed."; 918 } 919 leaf high-jitter-percentile { 920 type yang:gauge64; 921 description 922 "High percentile of the jitter observed."; 923 } 924 } 925 } 927 grouping tp-svc-telemetry { 928 leaf in-octets { 929 type uint32; 930 description 931 "The total number of octets received on the 932 interface, including framing characters."; 933 } 934 leaf inbound-unicast { 935 type uint32; 936 description 937 "Inbound unicast packets were received, and delivered 938 to a higher layer during the last period."; 939 } 940 leaf inbound-nunicast { 941 type uint32; 942 description 943 "The number of non-unicast (i.e., subnetwork- 944 broadcast or subnetwork-multicast) packets 945 delivered to a higher-layer protocol."; 946 } 947 leaf inbound-discards { 948 type uint32; 949 description 950 "The number of inbound packets which were chosen 951 to be discarded even though no errors had been 952 detected to prevent their being deliverable to a 953 higher-layer protocol."; 954 } 955 leaf inbound-errors { 956 type uint32; 957 description 958 "The number of inbound packets that contained 959 errors preventing them from being deliverable to a 960 higher-layer protocol."; 961 } 962 leaf outbound-errors { 963 type uint32; 964 description 965 "The number of outbound packets that contained 966 errors preventing them from being deliverable to a 967 higher-layer protocol."; 968 } 969 leaf in-unknown-protocol { 970 type uint32; 971 description 972 "The number of packets received via the interface 973 which were discarded because of an unknown or 974 unsupported protocol."; 975 } 976 leaf out-octets { 977 type uint32; 978 description 979 "The total number of octets transmitted out of the 980 interface, including framing characters."; 981 } 982 leaf outbound-unicast { 983 type uint32; 984 description 985 "The total number of packets that higher-level 986 protocols requested be transmitted to a 987 subnetwork-unicast address, including those that 988 were discarded or not sent."; 989 } 990 leaf outbound-nunicast { 991 type uint32; 992 description 993 "The total number of packets that higher-level 994 protocols requested be transmitted to a non- 995 unicast (i.e., a subnetwork-broadcast or 996 subnetwork-multicast) address, including those 997 that were discarded or not sent."; 998 } 999 leaf outbound-discards { 1000 type uint32; 1001 description 1002 "The number of outbound packets which were chosen 1003 to be discarded even though no errors had been 1004 detected to prevent their being transmitted. One 1005 possible reason for discarding such a packet could 1006 be to free up buffer space."; 1007 } 1008 leaf outbound-qlen { 1009 type uint32; 1010 description 1011 " Length of the queue of the interface from where 1012 the packet is forwarded out. The queue depth could 1013 be the current number of memory buffers used by the 1014 queue and a packet can consume one or more memory buffers 1015 thus constituting device-level information."; 1016 } 1017 description 1018 "Grouping for interface service telemetry."; 1019 } 1021 augment "/nw:networks/nw:network/nw:network-types" { 1022 description 1023 "Defines the service topologyies types"; 1024 container network-service-type { 1025 presence "Indicates Network service topology"; 1026 leaf network-service-type { 1027 type identityref { 1028 base vpn-common:service-type; 1029 } 1030 description 1031 "The presence identifies the network service type, e.g., L3VPN, 1032 L2VPN, etc."; 1033 } 1034 } 1035 } 1037 augment "/nw:networks/nw:network" { 1038 description 1039 "Augment the network with service topology attributes"; 1040 when 'nw:network-types/nvp:network-service-type' { 1041 description 1042 "Augment only for VPN Network topology."; 1043 } 1044 container vpn-topo-attributes { 1045 leaf l3nm-vpn-id { 1046 type vpn-common:vpn-id; 1047 description 1048 "Pointer to the parent L3NM service, 1049 if any."; 1050 } 1051 leaf vpn-topology { 1052 type identityref { 1053 base vpn-common:vpn-topology; 1054 } 1055 description 1056 "VPN service topology, e.g., hub-spoke, any-to-any, 1057 hub-spoke-disjoint"; 1058 } 1059 description 1060 "Container for vpn topology attributes."; 1061 } 1062 } 1064 augment "/nw:networks/nw:network/nw:node" { 1065 description 1066 "Augment the network node with overlay topology attributes"; 1067 when '../nw:network-types/nvp:network-service-type' { 1068 description 1069 "Augment only for VPN Network topology."; 1070 } 1071 container node-attributes { 1072 leaf node-type { 1073 type identityref { 1074 base vpn-common:role; 1076 } 1077 description 1078 "Node type, e.g., PE, P, ASBR."; 1079 } 1080 leaf site-id { 1081 type string; 1082 description 1083 "Associated vpn site"; 1084 } 1085 leaf site-role { 1086 type identityref { 1087 base vpn-common:role; 1088 } 1089 default "vpn-common:any-to-any-role"; 1090 description 1091 "Role of the site in the VPN."; 1092 } 1093 description 1094 "Container for overlay topology attributes."; 1095 } 1096 uses vpn-summary-statistics; 1097 } 1099 augment "/nw:networks/nw:network/nt:link" { 1100 description 1101 "Augment the network topology link with overlay topology attributes"; 1102 when '../nw:network-types/nvp:network-service-type' { 1103 description 1104 "Augment only for VPN Network topology."; 1105 } 1106 leaf link-type { 1107 type identityref { 1108 base vpn-common:routing-protocol-type; 1109 } 1110 description 1111 "Underlay-transport type, e.g., GRE, LDP, etc."; 1112 } 1113 } 1115 augment "/nw:networks/nw:network/nt:link" { 1116 description 1117 "Augment the network topology link with overlay topology attributes"; 1118 leaf low-percentile { 1119 type percentile; 1120 default "10.00"; 1121 description 1122 "Low percentile to report.Setting low-percentile into 0.00 indicates 1123 the client is not interested in receiving low percentile."; 1125 } 1126 leaf middle-percentile { 1127 type percentile; 1128 default "50.00"; 1129 description 1130 "Middle percentile to report.Setting middle-percentile into 0.00 indicates 1131 the client is not interested in receiving middle percentile."; 1132 } 1133 leaf high-percentile { 1134 type percentile; 1135 default "90.00"; 1136 description 1137 "High percentile to report."; 1138 } 1139 leaf reference-time { 1140 type yang:date-and-time; 1141 description 1142 "The time that the current Measurement Interval started.Setting high-percentile 1143 into 0.00 indicates the client is not interested in receiving high percentile."; 1144 } 1145 leaf measurement-interval { 1146 type uint32; 1147 units "seconds"; 1148 default "60"; 1149 description 1150 "Interval to calculate performance metric."; 1151 } 1152 container link-telemetry-attributes { 1153 config false; 1154 uses link-error-statistics; 1155 uses link-delay-statistics; 1156 uses link-jitter-statistics; 1157 description 1158 "Container for service telemetry attributes."; 1159 } 1160 } 1162 augment "/nw:networks/nw:network/nw:node/nt:termination-point" { 1163 description 1164 "Augment the network topology termination point with vpn service attributes"; 1165 container tp-telemetry-attributes { 1166 config false; 1167 uses tp-svc-telemetry; 1168 description 1169 "Container for termination point service telemetry attributes."; 1170 } 1171 } 1172 } 1173 1175 8. Security Considerations 1177 The YANG modules defined in this document MAY be accessed via the 1178 RESTCONF protocol [RFC8040] or NETCONF protocol ([RFC6241]). The 1179 lowest RESTCONF or NETCONF layer requires that the transport-layer 1180 protocol provides both data integrity and confidentiality, see 1181 Section 2 in [RFC8040] and [RFC6241]. The lowest NETCONF layer is 1182 the secure transport layer, and the mandatory-to-implement secure 1183 transport is Secure Shell (SSH)[RFC6242] . The lowest RESTCONF layer 1184 is HTTPS, and the mandatory-to-implement secure transport is TLS 1185 [RFC5246]. 1187 The NETCONF access control model [RFC6536] provides the means to 1188 restrict access for particular NETCONF or RESTCONF users to a 1189 preconfigured subset of all available NETCONF or RESTCONF protocol 1190 operations and content. 1192 There are a number of data nodes defined in this YANG module that are 1193 writable/creatable/deletable (i.e., config true, which is the 1194 default). These data nodes may be considered sensitive or vulnerable 1195 in some network environments. Write operations (e.g., edit-config) 1196 to these data nodes without proper protection can have a negative 1197 effect on network operations. These are the subtrees and data nodes 1198 and their sensitivity/vulnerability: 1200 o /nw:networks/nw:network/svc-topo:svc-telemetry-attributes 1202 o /nw:networks/nw:network/nw:node/svc-topo:node-attributes 1204 9. IANA Considerations 1206 This document requests IANA to register the following URI in the "ns" 1207 subregistry within the "IETF XML Registry" [RFC3688]: 1209 URI: urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm 1210 Registrant Contact: The IESG. 1211 XML: N/A, the requested URI is an XML namespace. 1213 This document requests IANA to register the following YANG module in 1214 the "YANG Module Names" subregistry [RFC6020] within the "YANG 1215 Parameters" registry. 1217 Name: ietf-network-vpn-pm 1218 Namespace: urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm 1219 Maintained by IANA: N 1220 Prefix: nvp 1221 Reference: RFC XXXX 1223 10. Acknowledgements 1225 Thanks to Adrian Farrel for reviewing this draft and providing 1226 important input to this document. 1228 11. Contributors 1230 Michale Wang 1231 Huawei 1232 Email:wangzitao@huawei.com 1234 Roni Even 1235 Huawei 1236 Email: ron.even.tlv@gmail.com 1238 12. References 1240 12.1. Normative References 1242 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1243 Requirement Levels", BCP 14, RFC 2119, 1244 DOI 10.17487/RFC2119, March 1997, 1245 . 1247 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1248 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1249 DOI 10.17487/RFC3393, November 2002, 1250 . 1252 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1253 DOI 10.17487/RFC3688, January 2004, 1254 . 1256 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1257 the Network Configuration Protocol (NETCONF)", RFC 6020, 1258 DOI 10.17487/RFC6020, October 2010, 1259 . 1261 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1262 and A. Bierman, Ed., "Network Configuration Protocol 1263 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1264 . 1266 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1267 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1268 . 1270 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 1271 Profile (MPLS-TP) Identifiers", RFC 6370, 1272 DOI 10.17487/RFC6370, September 2011, 1273 . 1275 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 1276 Measurement for MPLS Networks", RFC 6374, 1277 DOI 10.17487/RFC6374, September 2011, 1278 . 1280 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1281 Protocol (NETCONF) Access Control Model", RFC 6536, 1282 DOI 10.17487/RFC6536, March 2012, 1283 . 1285 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1286 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1287 . 1289 [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements 1290 for Subscription to YANG Datastores", RFC 7923, 1291 DOI 10.17487/RFC7923, June 2016, 1292 . 1294 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1295 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1296 . 1298 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", 1299 RFC 7952, DOI 10.17487/RFC7952, August 2016, 1300 . 1302 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1303 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1304 May 2017, . 1306 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1307 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1308 . 1310 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1311 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1312 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1313 2018, . 1315 [RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S. 1316 Raghavan, "Generic YANG Data Model for the Management of 1317 Operations, Administration, and Maintenance (OAM) 1318 Protocols That Use Connectionless Communications", 1319 RFC 8532, DOI 10.17487/RFC8532, April 2019, 1320 . 1322 12.2. Informative References 1324 [I-D.ietf-netconf-yang-push] 1325 Clemm, A. and E. Voit, "Subscription to YANG Datastores", 1326 draft-ietf-netconf-yang-push-25 (work in progress), May 1327 2019. 1329 [I-D.ietf-opsawg-model-automation-framework] 1330 WU, Q., Boucadair, M., Lopez, D., Xie, C., and L. Geng, "A 1331 Framework for Automating Service and Network Management 1332 with YANG", draft-ietf-opsawg-model-automation- 1333 framework-10 (work in progress), October 2020. 1335 [RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., 1336 and A. Gonguet, "Framework for Layer 3 Virtual Private 1337 Networks (L3VPN) Operations and Management", RFC 4176, 1338 DOI 10.17487/RFC4176, October 2005, 1339 . 1341 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1342 Previdi, "OSPF Traffic Engineering (TE) Metric 1343 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1344 . 1346 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 1347 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 1348 RFC 7810, DOI 10.17487/RFC7810, May 2016, 1349 . 1351 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, 1352 "Extensions to the Path Computation Element Communication 1353 Protocol (PCEP) to Compute Service-Aware Label Switched 1354 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 1355 2017, . 1357 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 1358 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 1359 DOI 10.17487/RFC8299, January 2018, 1360 . 1362 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 1363 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 1364 IGP Traffic Engineering Performance Metric Extensions", 1365 RFC 8571, DOI 10.17487/RFC8571, March 2019, 1366 . 1368 Authors' Addresses 1370 Bo Wu 1371 Huawei 1372 101 Software Avenue, Yuhua District 1373 Nanjing, Jiangsu 210012 1374 China 1376 Email: lana.wubo@huawei.com 1378 Qin Wu 1379 Huawei 1380 101 Software Avenue, Yuhua District 1381 Nanjing, Jiangsu 210012 1382 China 1384 Email: bill.wu@huawei.com 1386 Mohamed Boucadair 1387 Orange 1388 Rennes 35000 1389 France 1391 Email: mohamed.boucadair@orange.com 1393 Oscar Gonzalez de Dios 1394 Telefonica 1395 Madrid 1396 ES 1398 Email: oscar.gonzalezdedios@telefonica.com 1400 Bin Wen 1401 Comcast 1403 Email: bin_wen@comcast.com 1404 Change Liu 1405 China Unicom 1407 Email: liuc131@chinaunicom.cn 1409 Honglei Xu 1410 China Telecom 1412 Email: xuhl.bri@chinatelecom.cn