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