idnits 2.17.1 draft-www-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 : ---------------------------------------------------------------------------- ** There are 28 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 -- The document date (July 13, 2020) is 1384 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 221, but not defined == Missing Reference: 'RFC8040' is mentioned on line 1139, but not defined == Missing Reference: 'RFC5246' is mentioned on line 1143, but not defined ** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446) == Unused Reference: 'RFC6370' is defined on line 1228, but no explicit reference was found in the text == Unused Reference: 'RFC7923' is defined on line 1247, but no explicit reference was found in the text == Unused Reference: 'RFC7950' is defined on line 1252, but no explicit reference was found in the text == Unused Reference: 'RFC7952' is defined on line 1256, 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 (~~), 8 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: January 14, 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 July 13, 2020 17 A YANG Model for Network and VPN Service Performance Monitoring 18 draft-www-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 January 14, 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 Assurance Module . . . . . . . . . . 3 73 4. Layering Relationship Between Multiple Layers of Topology . . 4 74 5. Some Model Usage Guidelines . . . . . . . . . . . . . . . . . 5 75 5.1. Performance Monitoring Data Source . . . . . . . . . . . 5 76 5.2. Retrieval via Pub/Sub Mechanism . . . . . . . . . . . . . 5 77 5.3. On demand Retrieval via RPC Model . . . . . . . . . . . . 6 78 6. Data Model Sructure . . . . . . . . . . . . . . . . . . . . . 6 79 6.1. Network Level . . . . . . . . . . . . . . . . . . . . . . 6 80 6.2. Node Level . . . . . . . . . . . . . . . . . . . . . . . 7 81 6.3. Link and Termination Point Level . . . . . . . . . . . . 7 82 7. Example of I2RS Pub/Sub Retrieval . . . . . . . . . . . . . . 10 83 8. Example of RPC-based Retrieval . . . . . . . . . . . . . . . 11 84 9. Network and VPN Service Assurance YANG Module . . . . . . . . 12 85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 86 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 87 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 88 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 89 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 90 14.1. Normative References . . . . . . . . . . . . . . . . . . 26 91 14.2. Informative References . . . . . . . . . . . . . . . . . 28 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 94 1. Introduction 96 [RFC8345] defines a YANG data model for network/service topologies 97 and inventories. The service topology described in [RFC8345] 98 includes the virtual topology for a service layer above Layer 1 (L1), 99 Layer 2 (L2), and Layer 3 (L3). This service topology has the 100 generic topology elements of node, link, and terminating point. One 101 typical example of a service topology is described in Figure 3 of 102 [RFC8345]: two VPN service topologies instantiated over a common L3 103 topology. Each VPN service topology is mapped onto a subset of nodes 104 from the common L3 topology. 106 [RFC8299] defines a YANG model for L3VPN Service Delivery. Three 107 types of VPN service topologies are supported in [RFC8299]: "any to 108 any", "hub and spoke", and "hub and spoke disjoint". These VPN 109 topology types can be used to describe how VPN sites communicate with 110 each other. 112 [RFC4176] provides a framework for L3VPN operations and management. 113 Section 2.2.4 of that document describes performance management. 114 This document defines a YANG Model for both network performance 115 monitoring and VPN service performance monitoring that can be used to 116 monitor and manage network performance on the topology at higher 117 layer or the service topology between VPN sites. 119 This document does not define metrics for network performance or 120 mechanisms for measuring network performance. The YANG model defined 121 in this document is designed as an augmentation to the network 122 topology YANG model defined in [RFC8345] and draws on relevant YANG 123 types defined in [RFC6991], [RFC8299], [RFC8345], and [RFC8532]. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119][RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 Tree diagrams used in this document follow the notation defined in 134 [RFC8340]. 136 3. Network and VPN Service Assurance Module 138 The module defined in this document is a Network and VPN Service 139 assurance module that can be used to monitor and manage the network 140 performance on the topology at higher layer or the service topology 141 between VPN sites and it is an augmentation to the "ietf-network" and 142 "ietf-network-topology" YANG data model [RFC8345]. 144 The performance monitoring data is augmented to service topology as 145 shown in Figure 1. 147 +----------------------+ +-----------------------+ 148 |ietf-network | |Network and VPN Service| 149 |ietf-network-topology |<---------|Performance Monitoring | 150 +----------------------+ augments | Model | 151 +-----------------------+ 153 Figure 1: Module Augmentation 155 4. Layering Relationship Between Multiple Layers of Topology 157 The data model defined in [RFC8345] can describe vertical layering 158 relationships between networks. That model can be augmented to cover 159 network/service topologies. 161 Figure 2 illustrates an example of a topology mapping between the VPN 162 service topology and an underlying network: 164 VPN-SVC 1 VPN-SVC 2 165 / \ 166 VPN-Service-topology 1 VPN-Service-topology-2 167 / | \ / | \ 168 Site-1A Site-1B Site1-C Site-2A Site-2B Site-2C Top-Down 169 | | | | | | Service Topology 170 CE CE CE CE CE CE 171 | | | | | | 172 PE PE PE PE PE PE 173 ====|==========|=======|=======|=========|=====|====================== 174 +-------+ | \ / / | 175 Bottom-up | | \ / / | 176 Network | | /\ / | 177 topology | | / \ | | 178 | | | | | | 179 node1 node2 node3 node4 node5 node6 181 Figure 2: Example of topology mapping between VPN Service Topo and 182 Underlying network 184 As shown in Figure 2, two VPN services topologies are both built on 185 top of one common underlying physical network: 187 o VPN-SVC 1: supporting "hub-spoke" communications for Customer 1 188 connecting the customer's access at 3 sites. Site-1A, Site-1B, 189 and Site-1C are connected to PEs that are mapped to nodes 1, 2, 190 and 3 in the underlying physical network. 192 Site-1 A plays the role of hub while Site-2 B and C plays the role 193 of spoke. 195 o VPN-SVC 2: supporting "hub-spoke disjoint" communications for 196 Customer 2 connecting the customer's access at 3 sites. Site-2A, 197 Site-2B, and Site-2C are connected to PEs that are mapped to nodes 198 4, 5, and 6 in the underlying physical network. 200 Site-2 A and B play the role of hub while Site-2 C plays the role 201 of spoke. 203 5. Some Model Usage Guidelines 205 An SP must be able to manage the capabilities and characteristics of 206 the network/VPN services when Network connection is established or 207 VPN sites are setup to communicate with each other. 209 5.1. Performance Monitoring Data Source 211 As described in Section 4, once the mapping between the VPN Service 212 topology and the underlying physical network has been setup, the 213 performance monitoring data per link in the underlying network can be 214 collected using network performance measurement method such as MPLS 215 Loss and Delay Measurement [RFC6374]. 217 The performance monitoring information reflecting the quality of the 218 Network or VPN service such as end to end network performance data 219 between source node and destination node in the network or between 220 VPN sites can be aggregated or calculated using, for example, PCEP 221 solution [RFC8233] [RFC7471] [RFC7810] [RFC8571] or LMAP [RFC8194]. 223 The information can be fed into data source such as the management 224 system or network devices. The measurement interval and report 225 interval associated with these performance data usually depends on 226 configuration parameters. 228 5.2. Retrieval via Pub/Sub Mechanism 230 Some applications such as service-assurance applications, which must 231 maintain a continuous view of operational data and state, can use 232 subscription model [I-D.ietf-netconf-yang-push] to subscribe to the 233 specific Network performance data or VPN service performance data 234 they are interested in, at the data source. 236 The data source can then use the Network and VPN service assurance 237 model defined in this document and the YANG Push model 238 [I-D.ietf-netconf-yang-push] to distribute specific telemetry data to 239 target recipients. 241 5.3. On demand Retrieval via RPC Model 243 To obtain a snapshot of a large amount of performance data from a 244 network element (including network controllers), service-assurance 245 applications may use polling-based methods such as RPC model to fetch 246 performance data on demand. 248 6. Data Model Sructure 250 This document defines the YANG module "ietf-network-vpn-pm", which 251 has the tree structure described in the following sub-sections. 253 6.1. Network Level 255 module: ietf-network-vpn-pm 256 augment /nw:networks/nw:network/nw:network-types: 257 +--rw network-technology-type* identityref 258 augment /nw:networks/nw:network: 259 +--rw vpn-attributes 260 | +--rw vpn-topo? identityref 261 +--rw vpn-summary-statistics 262 | +--rw ipv4 263 | | +--rw total-routes? uint32 264 | | +--rw total-active-routes? uint32 265 | +--rw ipv6 266 | +--rw total-routes? uint32 267 | +--rw total-active-routes? uint32 269 Figure 3: Network Level View of the hierarchies 271 For VPN service performance monitoring, this model defines only the 272 following minimal set of Network level network topology attributes: 274 o "network-technology-type": Indicates the network technology type 275 such as L3VPN, L2VPN, ISIS, or OSPF. If the "network-technology- 276 type" is "VPN type" (e.g.,L3VPN, L2VPN), the "vpn-topo" MUST be 277 set. 279 o "vpn-topo": The type of VPN service topology, this model supports 280 "any-to-any", "Hub and Spoke" (where Hubs can exchange traffic), 281 and "Hub and Spoke disjoint" (where Hubs cannot exchange traffic). 283 o "vpn-summary-statistics": VPN summary statistics, IPv4 statistics, 284 and IPv6 statistics have been specified separately. 286 For network performance monitoring, the attributes of "Network Level" 287 that defined in [RFC8345] do not need to be extended. 289 6.2. Node Level 291 augment /nw:networks/nw:network/nw:node: 292 +--rw node-attributes 293 | +--rw node-type? identityref 294 | +--rw site-id? string 295 | +--rw site-role? Identityref 297 Figure 4: Node Level View of the hierarchies 299 The Network and VPN service performance monitoring model defines only 300 the following minimal set of Node level network topology attributes 301 and constraints: 303 o "node-type" (Attribute): Indicates the type of the node, such as 304 PE or ASBR. This "node-type" can be used to report performance 305 metric between any two nodes each with specific node-type. 307 o "site-id" (Constraint): Uniquely identifies the site within the 308 overall network infrastructure. 310 o "site-role" (Constraint): Defines the role of the site in a 311 particular VPN topology. 313 6.3. Link and Termination Point Level 314 augment /nw:networks/nw:network/nt:link: 315 +--rw link-type? identityref 316 +--rw low-percentile percentile 317 +--rw high-percentile percentile 318 +--rw middle-percentile percentile 319 +--ro reference-time yang:date-and-time 320 +--ro measurement-interval uint32 321 +--ro link-telemetry-attributes 322 +--ro loss-statistics 323 | +--ro packet-loss-count? uint32 324 | +--ro loss-ratio? percentage 325 | +--ro packet-reorder-count? uint32 326 | +--ro packets-out-of-seq-count? uint32 327 | +--ro packets-dup-count? uint32 328 +--ro delay-statistics 329 | +--ro direction? identityref 330 | +--ro unit-value identityref 331 | +--ro min-delay-value? yang:gauge64 332 | +--ro max-delay-value? yang:gauge64 333 | +--ro high-delay-percentile? yang:gauge64 334 | +--ro middle-delay-percentile? yang:gauge64 335 | +--ro low-delay-percentile? yang:gauge64 336 +--ro jitter-statistics 337 +--ro unit-value identityref 338 +--ro min-jitter-value? yang:gauge64 339 +--ro max-jitter-value? yang:gauge64 340 +--ro low-jitter-percentile? yang:gauge64 341 +--ro high-jitter-percentile? yang:gauge64 342 +--ro middle-jitter-percentile? yang:gauge64 343 augment /nw:networks/nw:network/nw:node/nt:termination-point: 344 +--ro tp-telemetry-attributes 345 +--ro in-octets? uint32 346 +--ro out-octets? uint32 347 +--ro inbound-unicast? uint32 348 +--ro inbound-nunicast? uint32 349 +--ro inbound-discards? uint32 350 +--ro inbound-errors? uint32 351 +--ro in-unknown-protocol? uint32 352 +--ro outbound-unicast? uint32 353 +--ro outbound-nunicast? uint32 354 +--ro outbound-discards? uint32 355 +--ro outbound-errors? uint32 356 +--ro outbound-qlen? uint32 358 Figure 5: Link and Termination point Level View of the hierarchies 360 The Network and VPN service performance monitoring model defines only 361 the following minimal set of Link level network topology attributes: 363 o "link-type" (Attribute): Indicates the type of the link, such as 364 GRE or IP-in-IP. 366 o "low-percentile": Indicates low percentile to report. Setting 367 low-percentile into 0.00 indicates the client is not intererested 368 in receiving low percentile. 370 o "middle-percentile": Indicates middle percentile to report. 371 Setting middle-percentile into 0.00 indicates the client is not 372 intererested in receiving middle percentile. 374 o "high-percentile": Indicates high percentile to report. Setting 375 low-percentile into 0.00 indicates the client is not intererested 376 in receiving high percentile. 378 o Loss Statistics: A set of loss statistics attributes that are used 379 to measure end to end loss between VPN sites or between any two 380 network nodes. 382 o Delay Statistics: A set of delay statistics attributes that are 383 used to measure end to end latency between VPN sites or between 384 any two network nodes.. 386 o Jitter Statistics: A set of IP Packet Delay Variation [RFC3393] 387 statistics attributes that are used to measure end to end jitter 388 between VPN sites or between any two network nodes.. 390 The Network and VPN service performance monitoring defines the 391 following minimal set of Termination point level network topology 392 attributes: 394 o Inbound statistics: A set of inbound statistics attributes that 395 are used to measure the inbound statistics of the termination 396 point, such as "the total number of octets received on the 397 termination point", "The number of inbound packets which were 398 chosen to be discarded", "The number of inbound packets that 399 contained errors", etc. 401 o Outbound statistics: A set of outbound statistics attributes that 402 are used to measure the outbound statistics of the termination 403 point, such as "the total number of octets transmitted out of the 404 termination point", "The number of outbound packets which were 405 chosen to be discarded", "The number of outbound packets that 406 contained errors", etc. 408 7. Example of I2RS Pub/Sub Retrieval 410 This example shows the way for a client to subscribe for the 411 Performance monitoring information between node A and node B in the 412 L3 network topology built on top of the underlying network . The 413 performance monitoring parameter that the client is interested in is 414 end to end loss attribute. 416 418 420 421 422 423 l3-network 424 425 L3VPN 426 427 428 A 429 430 pe 431 432 433 1-0-1 434 435 100 436 150 437 438 439 440 441 B 442 443 pe 444 445 446 2-0-1 447 448 150 449 100 450 451 452 453 454 A-B 455 456 A 457 458 459 B 460 461 mpls-te 462 464 465 100 466 467 468 469 470 471 472 500 473 474 476 8. Example of RPC-based Retrieval 478 This example shows the way for the client to use RPC model to fetch 479 performance data on demand, e.g., the client requests "packet-loss- 480 count" between PE1 in site 1 and PE2 in site 2 belonging to the same 481 VPN1. 483 485 486 487 488 vpn1 489 490 A 491 492 pe 493 494 495 1-0-1 496 497 100 498 150 499 500 501 502 503 B 504 505 pe 506 507 508 2-0-1 509 510 150 511 100 512 513 514 515 A-B 516 517 A 518 519 520 B 521 522 mpls-te 523 524 525 120 526 527 528 529 530 531 533 9. Network and VPN Service Assurance YANG Module 535 This module uses types defined in [RFC8345], [RFC8299] and [RFC8532]. 537 file "ietf-network-vpn-pm@2020-04-17.yang" 538 module ietf-network-vpn-pm { 539 yang-version 1.1; 540 namespace "urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm"; 541 prefix nvp; 543 import ietf-yang-types { 544 prefix yang; 545 reference "RFC 6991: Common YANG Types."; 546 } 547 import ietf-network { 548 prefix nw; 549 reference 550 "Section 6.1 of RFC 8345: A YANG Data Model for Network 551 Topologies"; 553 } 554 import ietf-network-topology { 555 prefix nt; 556 reference 557 "Section 6.2 of RFC 8345: A YANG Data Model for Network 558 Topologies"; 559 } 560 import ietf-l3vpn-svc { 561 prefix l3vpn-svc; 562 reference 563 "RFC 8299: YANG Data Model for L3VPN Service Delivery"; 564 } 565 import ietf-lime-time-types { 566 prefix lime; 567 reference 568 "RFC 8532: Generic YANG Data Model for the Management of 569 Operations, Administration, and Maintenance (OAM) Protocols 570 That Use Connectionless Communications"; 571 } 572 organization 573 "IETF OPSAWG Working Group"; 574 contact 575 "Editor: Qin Wu 576 577 Editor: Mohamed Boucadair 578 "; 579 description 580 "This module defines a model for the VPN Service Performance 581 monitoring. 583 Copyright (c) 2020 IETF Trust and the persons identified as 584 authors of the code. All rights reserved. 586 Redistribution and use in source and binary forms, with or 587 without modification, is permitted pursuant to, and subject 588 to the license terms contained in, the Simplified BSD License 589 set forth in Section 4.c of the IETF Trust's Legal Provisions 590 Relating to IETF Documents 591 (http://trustee.ietf.org/license-info). 593 This version of this YANG module is part of RFC XXXX; see 594 the RFC itself for full legal notices."; 596 revision 2019-04-17 { 597 description 598 "Initial revision."; 599 reference 600 "RFC XXXX: A YANG Model for Network and VPN Service Performance 601 Monitoring"; 602 } 604 identity network-type { 605 description 606 "Base type for Overlay network topology."; 607 } 609 identity l3vpn { 610 base network-type; 611 description 612 "Identity for layer3 VPN network type."; 613 } 615 identity l2vpn { 616 base network-type; 617 description 618 "Identity for layer2 VPN network type."; 619 } 621 identity ospf { 622 base network-type; 623 description 624 "Identity for OSPF network type."; 625 } 627 identity isis { 628 base network-type; 629 description 630 "Identity for ISIS network type."; 631 } 632 identity node-type { 633 description 634 "Base identity for node type"; 635 } 637 identity pe { 638 base node-type; 639 description 640 "Identity for PE type"; 641 } 643 identity ce { 644 base node-type; 645 description 646 "Identity for CE type"; 647 } 648 identity asbr { 649 base node-type; 650 description 651 "Identity for ASBR type"; 652 } 654 identity p { 655 base node-type; 656 description 657 "Identity for P type"; 658 } 660 identity link-type { 661 description 662 "Base identity for link type, e.g.,GRE, MPLS TE, VXLAN."; 663 } 664 identity gre { 665 base link-type; 666 description 667 "Base identity for GRE Tunnel."; 668 } 669 identity VXLAN { 670 base link-type; 671 description 672 "Base identity for VXLAN Tunnel."; 673 } 674 identity ip-in-ip { 675 base link-type; 676 description 677 "Base identity for IP in IP Tunnel."; 678 } 679 identity direction { 680 description 681 "Base Identity for measurement direction including 682 one way measurement and two way measurement."; 683 } 685 identity one-way { 686 base direction; 687 description 688 "Identity for one way measurement."; 689 } 691 identity two-way { 692 base direction; 693 description 694 "Identity for two way measurement."; 695 } 696 typedef percentage { 697 type decimal64 { 698 fraction-digits 5; 699 range "0..100"; 700 } 701 description 702 "Percentage."; 703 } 704 typedef percentile { 705 type decimal64 { 706 fraction-digits 2; 707 } 708 description 709 "The nth percentile of a set of data is the 710 value at which n percent of the data is below it."; 711 } 712 grouping vpn-summary-statistics { 713 description 714 "VPN Statistics grouping used for network topology 715 augmentation."; 716 container vpn-summary-statistics { 717 description "Container for VPN summary statistics."; 718 container ipv4 { 719 leaf total-routes { 720 type uint32; 721 description 722 "Total routes in the RIB from all protocols."; 723 } 724 leaf total-active-routes { 725 type uint32; 726 description 727 "Total active routes in the RIB."; 728 } 729 description 730 "IPv4-specific parameters."; 731 } 732 container ipv6 { 733 leaf total-routes { 734 type uint32; 735 description 736 "Total routes in the RIB from all protocols."; 737 } 738 leaf total-active-routes { 739 type uint32; 740 description 741 "Total active routes in the RIB."; 742 } 743 description 744 "IPv6-specific parameters."; 745 } 746 } 747 } 749 grouping link-error-statistics { 750 description 751 "Grouping for per link error statistics."; 752 container loss-statistics { 753 description 754 "Per link loss statistics."; 756 leaf packet-loss-count { 757 type uint32 { 758 range "0..4294967295"; 759 } 760 default "0"; 761 description 762 "Total received packet drops count. 763 The value of count will be set to zero (0) 764 on creation and will thereafter increase 765 monotonically until it reaches a maximum value 766 of 2^32-1 (4294967295 decimal), when it wraps 767 around and starts increasing again from zero."; 768 } 769 leaf loss-ratio { 770 type percentage; 771 description 772 "Loss ratio of the packets. Express as percentage 773 of packets lost with respect to packets sent."; 774 } 775 leaf packet-reorder-count { 776 type uint32 { 777 range "0..4294967295"; 778 } 779 default "0"; 780 description 781 "Total received packet reordered count. 782 The value of count will be set to zero (0) 783 on creation and will thereafter increase 784 monotonically until it reaches a maximum value 785 of 2^32-1 (4294967295 decimal), when it wraps 786 around and starts increasing again from zero."; 787 } 788 leaf packets-out-of-seq-count { 789 type uint32 { 790 range "0..4294967295"; 791 } 792 description 793 "Total received out of sequence 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-dup-count { 801 type uint32 { 802 range "0..4294967295"; 803 } 804 description 805 "Total received packet duplicates 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 } 813 } 815 grouping link-delay-statistics { 816 description 817 "Grouping for per link delay statistics"; 818 container delay-statistics { 819 description 820 "Link delay summarised information. By default, 821 one way measurement protocol (e.g., OWAMP) is used 822 to measure delay."; 823 leaf direction { 824 type identityref { 825 base direction; 826 } 827 default "one-way"; 828 description 829 "Define measurement direction including one way 830 measurement and two way measurement."; 831 } 832 leaf unit-value { 833 type identityref { 834 base lime:time-unit-type; 835 } 836 default "lime:milliseconds"; 837 description 838 "Time units, where the options are s, ms, ns, etc."; 839 } 840 leaf min-delay-value { 841 type yang:gauge64; 842 description 843 "Minimum delay value observed."; 844 } 845 leaf max-delay-value { 846 type yang:gauge64; 847 description 848 "Maximum delay value observed."; 849 } 850 leaf low-delay-percentile { 851 type yang:gauge64; 852 description 853 "Low percentile of the delay observed with 854 specific measurement method."; 855 } 856 leaf middle-delay-percentile { 857 type yang:gauge64; 858 description 859 "Middle percentile of the delay observed with 860 specific measurement method."; 861 } 862 leaf high-delay-percentile { 863 type yang:gauge64; 864 description 865 "High percentile of the delay observed with 866 specific measurement method."; 867 } 868 } 869 } 871 grouping link-jitter-statistics { 872 description 873 "Grouping for per link jitter statistics"; 874 container jitter-statistics { 875 description 876 "Link jitter summarised information. By default, 877 jitter is measured using IP Packet Delay Variation 878 (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:gauge64; 890 description 891 "Minimum jitter value observed."; 892 } 893 leaf max-jitter-value { 894 type yang:gauge64; 895 description 896 "Maximum jitter value observed."; 897 } 898 leaf low-jitter-percentile { 899 type yang:gauge64; 900 description 901 "Low percentile of the jitter observed."; 902 } 903 leaf middle-jitter-percentile { 904 type yang:gauge64; 905 description 906 "Middle percentile of the jitter observed."; 907 } 908 leaf high-jitter-percentile { 909 type yang:gauge64; 910 description 911 "High percentile of the jitter observed."; 912 } 913 } 914 } 916 grouping tp-svc-telemetry { 917 leaf in-octets { 918 type uint32; 919 description 920 "The total number of octets received on the 921 interface, including framing characters."; 922 } 923 leaf inbound-unicast { 924 type uint32; 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 uint32; 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 uint32; 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 uint32; 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 outbound-errors { 952 type uint32; 953 description 954 "The number of outbound packets that contained 955 errors preventing them from being deliverable to a 956 higher-layer protocol."; 957 } 958 leaf in-unknown-protocol { 959 type uint32; 960 description 961 "The number of packets received via the interface 962 which were discarded because of an unknown or 963 unsupported protocol."; 964 } 965 leaf out-octets { 966 type uint32; 967 description 968 "The total number of octets transmitted out of the 969 interface, including framing characters."; 970 } 971 leaf outbound-unicast { 972 type uint32; 973 description 974 "The total number of packets that higher-level 975 protocols requested be transmitted to a 976 subnetwork-unicast address, including those that 977 were discarded or not sent."; 978 } 979 leaf outbound-nunicast { 980 type uint32; 981 description 982 "The total number of packets that higher-level 983 protocols requested be transmitted to a non- 984 unicast (i.e., a subnetwork-broadcast or 985 subnetwork-multicast) address, including those 986 that were discarded or not sent."; 987 } 988 leaf outbound-discards { 989 type uint32; 990 description 991 "The number of outbound packets which were chosen 992 to be discarded even though no errors had been 993 detected to prevent their being transmitted. One 994 possible reason for discarding such a packet could 995 be to free up buffer space."; 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 "Augment the network-types with service topologyies types"; 1013 leaf-list network-technology-type { 1014 type identityref { 1015 base network-type; 1016 } 1017 description 1018 "Identify the network technology type, e.g., L3VPN, 1019 L2VPN, ISIS, OSPF."; 1020 } 1021 } 1022 augment "/nw:networks/nw:network" { 1023 description 1024 "Augment the network with service topology attributes"; 1025 container vpn-topo-attributes { 1026 leaf vpn-topology { 1027 type identityref { 1028 base l3vpn-svc:vpn-topology; 1029 } 1030 description 1031 "VPN service topology, e.g., hub-spoke, any-to-any, 1032 hub-spoke-disjoint"; 1033 } 1034 description 1035 "Container for vpn topology attributes."; 1036 } 1037 uses vpn-summary-statistics; 1038 } 1039 augment "/nw:networks/nw:network/nw:node" { 1040 description 1041 "Augment the network node with overlay topology attributes"; 1042 container node-attributes { 1043 leaf node-type { 1044 type identityref { 1045 base node-type; 1046 } 1047 description 1048 "Node type, e.g., PE, P, ASBR."; 1049 } 1050 leaf site-id { 1051 type string; 1052 description 1053 "Associated vpn site"; 1054 } 1055 leaf site-role { 1056 type identityref { 1057 base l3vpn-svc:site-role; 1058 } 1059 default "l3vpn-svc:any-to-any-role"; 1060 description 1061 "Role of the site in the VPN."; 1062 } 1063 description 1064 "Container for overlay topology attributes."; 1065 } 1066 } 1067 augment "/nw:networks/nw:network/nt:link" { 1068 description 1069 "Augment the network topology link with overlay topology attributes"; 1070 leaf link-type { 1071 type identityref { 1072 base link-type; 1073 } 1074 description 1075 "Link type, e.g., GRE,VXLAN, IP in IP."; 1076 } 1077 leaf low-percentile { 1078 type percentile; 1079 default 10.00; 1080 description 1081 "Low percentile to report.Setting low-percentile into 0.00 indicates 1082 the client is not intererested in receiving low percentile."; 1083 } 1084 leaf middle-percentile { 1085 type percentile; 1086 default 50.00; 1087 description 1088 "Middle percentile to report.Setting middle-percentile into 0.00 indicates 1089 the client is not intererested in receiving middle percentile."; 1090 } 1091 leaf high-percentile { 1092 type percentile; 1093 default 90.00; 1094 description 1095 "High percentile to report."; 1096 } 1097 leaf reference-time { 1098 type yang:date-and-time; 1099 description 1100 "The time that the current Measurement Interval started.Setting high-percentile 1101 into 0.00 indicates the client is not intererested in receiving high percentile."; 1102 } 1103 leaf measurement-interval { 1104 type uint32; 1105 units "seconds"; 1106 default 60; 1107 description 1108 "Interval to calculate performance metric."; 1109 } 1110 container link-telemetry-attributes { 1111 config false; 1112 uses link-error-statistics; 1113 uses link-delay-statistics; 1114 uses link-jitter-statistics; 1115 description 1116 "Container for service telemetry attributes."; 1117 } 1118 } 1119 augment "/nw:networks/nw:network/nw:node/nt:termination-point" { 1120 description 1121 "Augment the network topology termination point with vpn service attributes"; 1122 container tp-telemetry-attributes { 1123 config false; 1124 uses tp-svc-telemetry; 1125 description 1126 "Container for termination point service telemetry attributes."; 1127 } 1129 } 1130 } 1131 1133 10. Security Considerations 1135 The YANG modules defined in this document MAY be accessed via the 1136 RESTCONF protocol [RFC8040] or NETCONF protocol ([RFC6241]). The 1137 lowest RESTCONF or NETCONF layer requires that the transport-layer 1138 protocol provides both data integrity and confidentiality, see 1139 Section 2 in [RFC8040] and [RFC6241]. The lowest NETCONF layer is 1140 the secure transport layer, and the mandatory-to-implement secure 1141 transport is Secure Shell (SSH)[RFC6242] . The lowest RESTCONF layer 1142 is HTTPS, and the mandatory-to-implement secure transport is TLS 1143 [RFC5246]. 1145 The NETCONF access control model [RFC6536] provides the means to 1146 restrict access for particular NETCONF or RESTCONF users to a 1147 preconfigured subset of all available NETCONF or RESTCONF protocol 1148 operations and content. 1150 There are a number of data nodes defined in this YANG module that are 1151 writable/creatable/deletable (i.e., config true, which is the 1152 default). These data nodes may be considered sensitive or vulnerable 1153 in some network environments. Write operations (e.g., edit-config) 1154 to these data nodes without proper protection can have a negative 1155 effect on network operations. These are the subtrees and data nodes 1156 and their sensitivity/vulnerability: 1158 o /nw:networks/nw:network/svc-topo:svc-telemetry-attributes 1160 o /nw:networks/nw:network/nw:node/svc-topo:node-attributes 1162 11. IANA Considerations 1164 This document requests IANA to register the following URI in the "ns" 1165 subregistry within the "IETF XML Registry" [RFC3688]: 1167 URI: urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm 1168 Registrant Contact: The IESG. 1169 XML: N/A, the requested URI is an XML namespace. 1171 This document requests IANA to register the following YANG module in 1172 the "YANG Module Names" subregistry [RFC6020] within the "YANG 1173 Parameters" registry. 1175 Name: ietf-network-vpn-pm 1176 Namespace: urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm 1177 Maintained by IANA: N 1178 Prefix: nvp 1179 Reference: RFC XXXX 1181 12. Acknowledgements 1183 Thanks to Adrian Farrel for reviewing this draft and providing 1184 important input to this document. 1186 13. Contributors 1188 Michale Wang 1189 Huawei 1190 Email:wangzitao@huawei.com 1192 Roni Even 1193 Huawei 1194 Email: ron.even.tlv@gmail.com 1196 14. References 1198 14.1. Normative References 1200 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1201 Requirement Levels", BCP 14, RFC 2119, 1202 DOI 10.17487/RFC2119, March 1997, 1203 . 1205 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1206 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1207 DOI 10.17487/RFC3393, November 2002, 1208 . 1210 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1211 DOI 10.17487/RFC3688, January 2004, 1212 . 1214 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1215 the Network Configuration Protocol (NETCONF)", RFC 6020, 1216 DOI 10.17487/RFC6020, October 2010, 1217 . 1219 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1220 and A. Bierman, Ed., "Network Configuration Protocol 1221 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1222 . 1224 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1225 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1226 . 1228 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 1229 Profile (MPLS-TP) Identifiers", RFC 6370, 1230 DOI 10.17487/RFC6370, September 2011, 1231 . 1233 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 1234 Measurement for MPLS Networks", RFC 6374, 1235 DOI 10.17487/RFC6374, September 2011, 1236 . 1238 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1239 Protocol (NETCONF) Access Control Model", RFC 6536, 1240 DOI 10.17487/RFC6536, March 2012, 1241 . 1243 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1244 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1245 . 1247 [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements 1248 for Subscription to YANG Datastores", RFC 7923, 1249 DOI 10.17487/RFC7923, June 2016, 1250 . 1252 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1253 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1254 . 1256 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", 1257 RFC 7952, DOI 10.17487/RFC7952, August 2016, 1258 . 1260 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1261 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1262 May 2017, . 1264 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1265 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1266 . 1268 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1269 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1270 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1271 2018, . 1273 [RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S. 1274 Raghavan, "Generic YANG Data Model for the Management of 1275 Operations, Administration, and Maintenance (OAM) 1276 Protocols That Use Connectionless Communications", 1277 RFC 8532, DOI 10.17487/RFC8532, April 2019, 1278 . 1280 14.2. Informative References 1282 [I-D.ietf-netconf-yang-push] 1283 Clemm, A. and E. Voit, "Subscription to YANG Datastores", 1284 draft-ietf-netconf-yang-push-25 (work in progress), May 1285 2019. 1287 [RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., 1288 and A. Gonguet, "Framework for Layer 3 Virtual Private 1289 Networks (L3VPN) Operations and Management", RFC 4176, 1290 DOI 10.17487/RFC4176, October 2005, 1291 . 1293 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1294 Previdi, "OSPF Traffic Engineering (TE) Metric 1295 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1296 . 1298 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 1299 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 1300 RFC 7810, DOI 10.17487/RFC7810, May 2016, 1301 . 1303 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, 1304 "Extensions to the Path Computation Element Communication 1305 Protocol (PCEP) to Compute Service-Aware Label Switched 1306 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 1307 2017, . 1309 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 1310 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 1311 DOI 10.17487/RFC8299, January 2018, 1312 . 1314 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 1315 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 1316 IGP Traffic Engineering Performance Metric Extensions", 1317 RFC 8571, DOI 10.17487/RFC8571, March 2019, 1318 . 1320 Authors' Addresses 1322 Bo Wu 1323 Huawei 1324 101 Software Avenue, Yuhua District 1325 Nanjing, Jiangsu 210012 1326 China 1328 Email: lana.wubo@huawei.com 1330 Qin Wu 1331 Huawei 1332 101 Software Avenue, Yuhua District 1333 Nanjing, Jiangsu 210012 1334 China 1336 Email: bill.wu@huawei.com 1338 Mohamed Boucadair 1339 Orange 1340 Rennes 35000 1341 France 1343 Email: mohamed.boucadair@orange.com 1345 Oscar Gonzalez de Dios 1346 Telefonica 1347 Madrid 1348 ES 1350 Email: oscar.gonzalezdedios@telefonica.com 1352 Bin Wen 1353 Comcast 1355 Email: bin_wen@comcast.com 1357 Change Liu 1358 China Unicom 1360 Email: liuc131@chinaunicom.cn 1361 Honglei Xu 1362 China Telecom 1364 Email: xuhl.bri@chinatelecom.cn