idnits 2.17.1 draft-www-bess-yang-vpn-service-pm-04.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. ** The abstract seems to contain references ([RFC8345]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2019) is 1632 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: 'RFC8299' is mentioned on line 95, but not defined == Missing Reference: 'RFC8194' is mentioned on line 202, but not defined == Missing Reference: 'I-D.ietf-netconf-yang-push' is mentioned on line 211, but not defined == Missing Reference: 'RFC8040' is mentioned on line 943, but not defined == Missing Reference: 'RFC5246' is mentioned on line 947, but not defined ** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446) == Unused Reference: 'RFC6370' is defined on line 1018, but no explicit reference was found in the text == Unused Reference: 'RFC7950' is defined on line 1038, but no explicit reference was found in the text == Unused Reference: 'RFC7952' is defined on line 1042, 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 Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group M. Wang 3 Internet-Draft Q. Wu 4 Intended status: Standards Track R. Even 5 Expires: May 3, 2020 Huawei 6 B. Wen 7 Comcast 8 C. Liu 9 China Unicom 10 H. Xu 11 China Telecom 12 October 31, 2019 14 A YANG Model for Network and VPN Service Performance Monitoring 15 draft-www-bess-yang-vpn-service-pm-04 17 Abstract 19 The data model defined in [RFC8345] introduces vertical layering 20 relationships between networks that can be augmented to cover 21 network/service topologies. This document defines a YANG model for 22 both Network Performance Monitoring and VPN Service Performance 23 Monitoring that can be used to monitor and manage network performance 24 on the topology at higher layer or the service topology between VPN 25 sites. This model is an augmentation to the network topology YANG 26 data model defined in [RFC8345]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 3, 2020. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Conventions used in this document . . . . . . . . . . . . . . 3 64 2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Network and VPN service assurance module . . . . . . . . . . 3 66 4. Layering relationship between multiple layers of topology . . 4 67 5. Model Usage Guideline . . . . . . . . . . . . . . . . . . . . 5 68 5.1. Performance Monitoring Data Source . . . . . . . . . . . 5 69 5.2. Retrieval via I2RS Pub/Sub [RFC7923] . . . . . . . . . . 5 70 5.3. On demand Retrieval via RPC model . . . . . . . . . . . . 5 71 6. Design of the Data Model . . . . . . . . . . . . . . . . . . 5 72 6.1. Network Level . . . . . . . . . . . . . . . . . . . . . . 6 73 6.2. Node Level . . . . . . . . . . . . . . . . . . . . . . . 6 74 6.3. Link and Termination Point Level . . . . . . . . . . . . 7 75 7. Example of I2RS Pub/Sub Retrieval [RFC7923] . . . . . . . . . 8 76 8. Example of RPC model based Retrieval . . . . . . . . . . . . 10 77 9. Network and VPN Service Assurance YANG Module . . . . . . . . 11 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 79 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 80 12. Normative References . . . . . . . . . . . . . . . . . . . . 22 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 83 1. Introduction 85 [RFC8345] defines an abstract YANG data model for network/service 86 topologies and inventories. Service topology described in [RFC8345] 87 includes the a virtual topology for a service layer above the L1, L2, 88 and L3 layers. This service topology has the generic topology 89 elements of node, link, and terminating point. One typical example 90 of a service topology is described in figure 3 of [RFC8345], two VPN 91 service topologies instantiated over a common L3 topology. Each VPN 92 service topology is mapped onto a subset of nodes from the common L3 93 topology. 95 In [RFC8299], 3 types of VPN service topologies are defined for the 96 L3VPN service data model: any to any; hub and spoke; and hub and 97 spoke disjoint. These VPN topology types can be used to describe how 98 VPN sites communicate with each other. 100 This document defines a YANG Model for both Network performance 101 monitoring and VPN Service Performance Monitoring that can be used to 102 monitor and manage network Performance on the topology at higher 103 layer or the service topology between VPN sites and it is an 104 augmentation to the network topology YANG data model defined in 105 [RFC8345]. 107 2. Conventions used in this document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. In this 112 document, these words will appear with that interpretation only when 113 in ALL CAPS. Lower case uses of these words are not to be 114 interpreted as carrying [RFC2119] significance. 116 2.1. Tree Diagrams 118 Tree diagrams used in this document follow the notation defined in 119 [RFC8340]. 121 3. Network and VPN service assurance module 123 This module defined in this document is a Network and VPN Service 124 assurance module that can be used to monitor and manage the network 125 Performance on the topology at higher layer layer or the service 126 topology between VPN sites and it is an augmentation to the "ietf- 127 network" and "ietf-network-topology" YANG data model [RFC8345]. The 128 performance monitoring data is augmented to service topology. 130 +----------------------+ +-----------------------+ 131 |ietf-network | |Network and VPN Service| 132 |ietf-network-topology |<---------|Peformance Monitoring | 133 +----------------------+ augments | Model | 134 +-----------------------+ 136 4. Layering relationship between multiple layers of topology 138 The data model defined in [RFC8345] can describe vertical layering 139 relationships between networks. That model can be augmented to cover 140 network/service topologies. 142 Figure 1 describes an example on topology mapping between the VPN 143 service topology and the underlying network: 145 VPN-SVC 1 VPN-SVC 2 146 / \ 147 VPN-Service-topology 1 VPN-Service-topology-2 148 / | \ / | \ 149 Site-1A Site-1B Site1-C Site-2A Site-2B Site-2C Top-Down 150 | | | | | | Service Topology 151 CE CE CE CE CE CE 152 | | | | | | 153 PE PE PE PE PE PE 154 ====|==========|=======|=======|=========|=====|====================== 155 +-------+ | \ / / | 156 Bottom-up | | \ / / | 157 Network | | /\ / | 158 topology | | / \ | | 159 | | | | | | 160 node1 node2 node3 node4 node5 node6 162 Example of topology mapping between VPN Service Topo and Underlying 163 network 165 As shown in Figure 1, Site-1A, Site-1B, and Site-1C are mapped to 166 nodes 1, 2, and 3, while Site-2A, Site-2B, and Site-2C are mapped to 167 nodes 4, 5, and 6 in the underlying physical network. In this 168 figure, two VPN services topologies are both built on top of one 169 common underlying physical network. 171 VPN-SVC 1: supporting hub-spoke communication for Customer 1 172 connecting the customers access at 3 sites 174 VPN-SVC 2: supporting hub-spoke disjoint communication for 175 Customer 2 connecting the customers access at 3 sites 177 VPN service topology 1 is hub and spoke topology while VPN service 178 topology 2 is hub and spoke disjoint topology. In VPN service 179 topology 1, Site-1 A plays the role of hub while Site-2 B and C plays 180 the role of spoke. In VPN service topoogy 2, Site-2 A and B play the 181 role of hub while Site-2 C plays the role of spoke. 183 5. Model Usage Guideline 185 An SP must be able to manage the capabilities and characteristics of 186 their Network/VPN services when Network connection is established or 187 VPN sites are setup to communicate with each other. VPN service 188 topology such as hub and spoke describes how these VPN sites are 189 communicating with each other. 191 5.1. Performance Monitoring Data Source 193 As described in Section 4, once the mapping between VPN Service 194 topology and underlying physical network has been setup, the 195 performance monitoring data per link in the underlying network can be 196 collected using network performance measurement method such as MPLS 197 Loss and Delay Measurement [RFC6374]. The performance monitoring 198 information reflecting the quality of the Network or VPN service such 199 as end to end network performance data between source node and 200 destination node in the network or between VPN sites can be 201 aggregated or calculated using PCEP solution [RFC5440] or LMAP 202 solution [RFC8194]. The information can be fed into data source such 203 as the management system or network devices. The measurement 204 interval and report interval associated with these performance data 205 usually depends on configuration parameters. 207 5.2. Retrieval via I2RS Pub/Sub [RFC7923] 209 Some applications such as service-assurance applications, which must 210 maintain a continuous view of operational data and state, can use 211 subscription model [I-D.ietf-netconf-yang-push] to subscribe to the 212 Network performance data or VPN service performance data they are 213 interested in, at the data source. 215 The data source can then use the Network and VPN service assurance 216 model defined in this document and push model [I-D.ietf-netconf-yang- 217 push] to distribute specific telemetry data to target recipients. 219 5.3. On demand Retrieval via RPC model 221 To obtain a snapshot of a large amount of performance data from the 222 network element, service-assurance applications can also use polling 223 based solution such as RPC model to fetch performance data on demand. 225 6. Design of the Data Model 227 This document defines the YANG module "ietf-network-vpn-pm", which 228 has the following structure 230 6.1. Network Level 232 module: ietf-network-vpn-pm 233 augment /nw:networks/nw:network/nw:network-types: 234 +--rw network-technology-type* identityref 235 augment /nw:networks/nw:network: 236 +--rw vpn-topo-attributes 237 +--rw vpn-topo? identityref 239 Network Level View of the hierarchies 241 For VPN service performance monitoring, this model defines only the 242 following minimal set of Network level network topology attributes: 244 o Network-technology-type: Indicate the network technology type such 245 as L3VPN, L2VPN,ISIS, OSPF. If the network-technology-type is VPN 246 type,e.g.,L3VPN, L2VPN, the VPN-topo should be set. 248 o vpn-topo: The type of VPN service topology, this model supports 249 any-to-any, Hub and Spoke (where Hubs can exchange traffic), and 250 "Hub and Spoke disjoint" (where Hubs cannot exchange traffic). 252 For network performance monitoring, the attributes of "Network Level" 253 that defined in [RFC8345] do not need to be extended. 255 6.2. Node Level 257 augment /nw:networks/nw:network/nw:node: 258 +--rw node-attributes 259 +--rw node-type? identityref 260 +--rw site-id? string 261 +--rw site-role? Identityref 263 Node Level View of the hierarchies 265 The Network and VPN service performance monitoring model defines only 266 the following minimal set of Node level network topology attributes 267 and constraints: 269 o Node-type (Attribute): Indicate the type of the node, such as PE 270 or ASBR. 272 o Site-id (Constraint): Uniquely identifies the site within the 273 overall network infrastructure. 275 o Site-role (Constraint): Defines the role of the site in a 276 particular VPN topology. 278 6.3. Link and Termination Point Level 280 augment /nw:networks/nw:network/nt:link: 281 +--rw link-type? identityref 282 +--ro link-telemetry-attributes 283 +--ro loss-statistics 284 | +--ro direction identityref 285 | +--ro packet-loss-count? uint32 286 | +--ro loss-ratio? percentage 287 | +--ro packet-reorder-count? uint32 288 | +--ro packets-out-of-seq-count? uint32 289 | +--ro packets-dup-count? uint32 290 +--ro delay-statistics 291 | +--ro direction? identityref 292 | +--ro min-delay-value? uint32 293 | +--ro max-delay-value? uint32 294 | +--ro average-delay-value? uint32 295 +--ro jitter-statistics 296 +--ro direction? identityref 297 +--ro min-jitter-value? uint32 298 +--ro max-jitter-value? uint32 299 +--ro average-jitter-value? uint32 300 augment /nw:networks/nw:network/nw:node/nt:termination-point: 301 +--ro tp-telemetry-attributes 302 +--ro in-octets? uint32 303 +--ro inbound-unicast? uint32 304 +--ro inbound-nunicast? uint32 305 +--ro inbound-discards? uint32 306 +--ro inbound-errors? uint32 307 +--ro inunknow-protos? uint32 308 +--ro out-octets? uint32 309 +--ro outbound-unicast? uint32 310 +--ro outbound-nunicast? uint32 311 +--ro outbound-discards? uint32 312 +--ro outbound-errors? uint32 313 +--ro outbound-qlen? uint32 315 Link and Termination point Level View of the hierarchies 317 The Network and VPN service performance monitoring model defines only 318 the following minimal set of Link level network topology attributes: 320 o Link-type (Attribute): Indicate the type of the link, such as 321 GRE,IP in IP. 323 o Loss Statistics: A set of loss statistics attributes that are used 324 to measure end to end loss between VPN sites. 326 o Delay Statistics: A set of delay statistics attributes that are 327 used to measure end to end latency between VPN sites. 329 o Jitter Statistics: A set of jitter statistics attributes that are 330 used to measure end to end jitter between VPN sites. 332 The Network and VPN service performance monitoring defines the 333 following minimal set of Termination point level network topology 334 attributes: 336 o Inbound statistics: A set of inbound statistics attributes that 337 are used to measure the inbound statistics of the termination 338 point, such as "the total number of octets received on the 339 termination point", "The number of inbound packets which were 340 chosen to be discarded", "The number of inbound packets that 341 contained errors", etc. 343 o Outbound statistics: A set of outbound statistics attributes that 344 are used to measure the outbound statistics of the termination 345 point, such as "the total number of octets transmitted out of the 346 termination point", "The number of outbound packets which were 347 chosen to be discarded", "The number of outbound packets that 348 contained errors", etc. 350 7. Example of I2RS Pub/Sub Retrieval [RFC7923] 352 This example shows the way for a client to subscribe for the 353 Performance monitoring information between node A and node B in the 354 L3 network topology built on top of the underlying network . The 355 performance monitoring parameter that the client is interested in is 356 end to end loss attribute. 358 360 362 363 364 365 l3-network 366 367 L3VPN 368 369 370 A 371 372 pe 373 374 375 1-0-1 376 377 100 378 150 379 380 381 382 383 B 384 385 pe 386 387 388 2-0-1 389 390 150 391 100 392 393 394 395 396 A-B 397 398 A 399 400 401 B 402 403 mpls-te 404 406 407 100 408 409 410 411 412 413 414 500 415 416 418 8. Example of RPC model based Retrieval 420 This example shows the way for the client to use RPC model to fetch 421 performance data on demand,e.g., the client requests packet-loss- 422 count between PE1 in site 1 and PE2 in site 2 belonging to the same 423 VPN1. 425 427 428 429 430 vpn1 431 432 A 433 434 pe 435 436 437 1-0-1 438 439 100 440 150 441 442 443 444 445 B 446 447 pe 448 449 450 2-0-1 451 452 150 453 100 454 455 456 457 A-B 458 459 A 460 461 462 B 463 464 mpls-te 465 466 467 120 468 469 470 471 472 473 475 9. Network and VPN Service Assurance YANG Module 477 file "ietf-network-vpn-pm.yang" 478 module ietf-network-vpn-pm { 479 yang-version 1.1; 480 namespace "urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm"; 481 prefix nvp; 483 import ietf-network { 484 prefix nw; 485 } 486 import ietf-network-topology { 487 prefix nt; 488 } 489 import ietf-l3vpn-svc { 490 prefix l3vpn-svc; 491 } 493 organization 494 "IETF BESS Working Group"; 495 contact 496 "Zitao Wang: wangzitao@huawei.com 497 Qin Wu: bill.wu@huawei.com"; 498 description 499 "This module defines a model for the VPN Service Performance monitoring."; 501 revision 2019-03-01 { 502 description 503 "Initial revision."; 504 reference 505 "foo"; 506 } 508 identity network-type { 509 description 510 "Base type for Overlay network topology"; 511 } 513 identity l3vpn { 514 base network-type; 515 description 516 "Indentity for layer3 vpn network type."; 517 } 519 identity l2vpn { 520 base network-type; 521 description 522 "Identity for layer2 vpn network type."; 523 } 525 identity ospf { 526 base network-type; 527 description 528 "Identity for OSPF network type."; 529 } 531 identity isis { 532 base network-type; 533 description 534 "Identity for ISIS network type."; 535 } 536 identity node-type { 537 description 538 "Base identity for node type"; 539 } 541 identity pe { 542 base node-type; 543 description 544 "Identity for PE type"; 545 } 547 identity ce { 548 base node-type; 549 description 550 "Identity for CE type"; 551 } 553 identity asbr { 554 base node-type; 555 description 556 "Identity for ASBR type"; 557 } 559 identity p { 560 base node-type; 561 description 562 "Identity for P type"; 563 } 565 identity link-type { 566 description 567 "Base identity for link type,e.g.,GRE, MPLS TE, VXLAN."; 568 } 569 identity gre { 570 base link-type; 571 description 572 "Base identity for GRE Tunnel."; 573 } 574 identity VXLAN { 575 base link-type; 576 description 577 "Base identity for VXLAN Tunnel."; 578 } 579 identity ip-in-ip { 580 base link-type; 581 description 582 "Base identity for IP in IP Tunnel."; 583 } 584 identity direction { 585 description 586 "Base Identity for measurement direction including 587 one way measurement and two way measurement."; 588 } 590 identity oneway { 591 base direction; 592 description 593 "Identity for one way measurement."; 594 } 596 identity twoway { 597 base direction; 598 description 599 "Identity for two way measurement."; 600 } 601 typedef percentage { 602 type decimal64 { 603 fraction-digits 5; 604 range "0..100"; 605 } 606 description 607 "Percentage."; 608 } 609 grouping link-error-statistics { 610 description 611 "Grouping for per link error statistics"; 612 container loss-statistics { 613 description 614 "Per link loss statistics."; 615 leaf direction { 616 type identityref { 617 base direction; 618 } 619 default "oneway"; 620 description 621 "Define measurement direction including one way 622 measurement and two way measurement."; 623 } 624 leaf packet-loss-count { 625 type uint32 { 626 range "0..4294967295"; 627 } 628 default "0"; 629 description 630 "Total received packet drops count. 631 The value of count will be set to zero (0) 632 on creation and will thereafter increase 633 monotonically until it reaches a maximum value 634 of 2^32-1 (4294967295 decimal), when it wraps 635 around and starts increasing again from zero."; 636 } 637 leaf loss-ratio { 638 type percentage; 639 description 640 "Loss ratio of the packets. Express as percentage 641 of packets lost with respect to packets sent."; 642 } 643 leaf packet-reorder-count { 644 type uint32 { 645 range "0..4294967295"; 646 } 647 default "0"; 648 description 649 "Total received packet reordered count. 650 The value of count will be set to zero (0) 651 on creation and will thereafter increase 652 monotonically until it reaches a maximum value 653 of 2^32-1 (4294967295 decimal), when it wraps 654 around and starts increasing again from zero."; 655 } 656 leaf packets-out-of-seq-count { 657 type uint32 { 658 range "0..4294967295"; 659 } 660 description 661 "Total received out of sequence count. 662 The value of count will be set to zero (0) 663 on creation and will thereafter increase 664 monotonically until it reaches a maximum value 665 of 2^32-1 (4294967295 decimal), when it wraps 666 around and starts increasing again from zero.."; 667 } 668 leaf packets-dup-count { 669 type uint32 { 670 range "0..4294967295"; 671 } 672 description 673 "Total received packet duplicates count. 674 The value of count will be set to zero (0) 675 on creation and will thereafter increase 676 monotonically until it reaches a maximum value 677 of 2^32-1 (4294967295 decimal), when it wraps 678 around and starts increasing again from zero."; 679 } 680 } 681 } 683 grouping link-delay-statistics { 684 description 685 "Grouping for per link delay statistics"; 686 container delay-statistics { 687 description 688 "Link delay summarised information. By default, 689 one way measurement protocol (e.g., OWAMP) is used 690 to measure delay."; 691 leaf direction { 692 type identityref { 693 base direction; 694 } 695 default "oneway"; 696 description 697 "Define measurement direction including one way 698 measurement and two way measurement."; 699 } 700 leaf min-delay-value { 701 type uint32; 702 description 703 "Minimum delay value observed."; 704 } 705 leaf max-delay-value { 706 type uint32; 707 description 708 "Maximum delay value observed."; 709 } 710 leaf average-delay-value { 711 type uint32; 712 description 713 "Average delay is calculated on all the packets of a sample 714 and is a simple computation to be performed for single marking method."; 715 } 716 } 717 } 719 grouping link-jitter-statistics { 720 description 721 "Grouping for per link jitter statistics"; 722 container jitter-statistics { 723 description 724 "Link jitter summarised information. By default, 725 jitter is measured using IP Packet Delay Variation 726 (IPDV) as defined in RFC3393."; 727 leaf direction { 728 type identityref { 729 base direction; 730 } 731 default "oneway"; 732 description 733 "Define measurement direction including one way 734 measurement and two way measurement."; 735 } 736 leaf min-jitter-value { 737 type uint32; 738 description 739 "Minimum jitter value observed."; 740 } 741 leaf max-jitter-value { 742 type uint32; 743 description 744 "Maximum jitter value observed."; 745 } 746 leaf average-jitter-value { 747 type uint32; 748 description 749 "Average jitter is calculated on all the packets of a sample 750 and is a simple computation to be performed for single marking method."; 751 } 752 } 754 } 756 grouping tp-svc-telemetry { 758 leaf in-octets { 759 type uint32; 760 description 761 "The total number of octets received on the 762 interface, including framing characters."; 763 } 764 leaf inbound-unicast { 765 type uint32; 766 description 767 "Inbound unicast packets were received, and delivered 768 to a higher layer during the last period."; 769 } 770 leaf inbound-nunicast { 771 type uint32; 772 description 773 "The number of non-unicast (i.e., subnetwork- 774 broadcast or subnetwork-multicast) packets 775 delivered to a higher-layer protocol."; 776 } 777 leaf inbound-discards { 778 type uint32; 779 description 780 "The number of inbound packets which were chosen 781 to be discarded even though no errors had been 782 detected to prevent their being deliverable to a 783 higher-layer protocol."; 784 } 785 leaf inbound-errors { 786 type uint32; 787 description 788 "The number of inbound packets that contained 789 errors preventing them from being deliverable to a 790 higher-layer protocol."; 791 } 792 leaf inunknow-protos { 793 type uint32; 794 description 795 "The number of packets received via the interface 796 which were discarded because of an unknown or 797 unsupported protocol"; 798 } 799 leaf out-octets { 800 type uint32; 801 description 802 "The total number of octets transmitted out of the 803 interface, including framing characters"; 804 } 805 leaf outbound-unicast { 806 type uint32; 807 description 808 "The total number of packets that higher-level 809 protocols requested be transmitted to a 810 subnetwork-unicast address, including those that 811 were discarded or not sent."; 812 } 813 leaf outbound-nunicast { 814 type uint32; 815 description 816 "The total number of packets that higher-level 817 protocols requested be transmitted to a non- 818 unicast (i.e., a subnetwork-broadcast or 819 subnetwork-multicast) address, including those 820 that were discarded or not sent."; 821 } 822 leaf outbound-discards { 823 type uint32; 824 description 825 "The number of outbound packets which were chosen 826 to be discarded even though no errors had been 827 detected to prevent their being transmitted. One 828 possible reason for discarding such a packet could 829 be to free up buffer space."; 830 } 831 leaf outbound-errors { 832 type uint32; 833 description 834 "The number of outbound packets that contained 835 errors preventing them from being deliverable to a 836 higher-layer protocol."; 837 } 838 leaf outbound-qlen { 839 type uint32; 840 description 841 " Length of the queue of the interface from where 842 the packet is forwarded out. The queue depth could 843 be the current number of memory buffers used by the 844 queue and a packet can consume one or more memory buffers 845 thus constituting device-level information."; 846 } 847 description 848 "Grouping for interface service telemetry"; 849 } 850 augment "/nw:networks/nw:network/nw:network-types" { 851 description 852 "Augment the network-types with service topologyies types"; 853 leaf-list network-technology-type { 854 type identityref { 855 base network-type; 856 } 857 description 858 "Identify the network technology type,e.g.,L3VPN,L2VPN, ISIS, OSPF."; 859 } 860 } 861 augment "/nw:networks/nw:network" { 862 description 863 "Augment the network with service topology attributes"; 864 container overlay-topo-attributes { 865 leaf vpn-topology { 866 type identityref { 867 base l3vpn-svc:vpn-topology; 868 } 869 description 870 "VPN service topology, e.g. hub-spoke, any-to-any, hub-spoke-disjoint, etc"; 871 } 872 description 873 "Container for vpn services"; 874 } 875 } 876 augment "/nw:networks/nw:network/nw:node" { 877 description 878 "Augment the network node with overlay topology attributes"; 879 container node-attributes { 880 leaf node-type { 881 type identityref { 882 base node-type; 883 } 884 description 885 "Node type, e.g. PE, P, ASBR, etc"; 886 } 887 leaf site-id { 888 type string; 889 description 890 "Asscoiated vpn site"; 891 } 892 leaf site-role { 893 type identityref { 894 base l3vpn-svc:site-role; 895 } 896 default "l3vpn-svc:any-to-any-role"; 897 description 898 "Role of the site in the VPN."; 899 } 900 description 901 "Container for overlay topology attributes"; 902 } 903 } 904 augment "/nw:networks/nw:network/nt:link" { 905 description 906 "Augment the network topology link with overlay topology attributes"; 907 leaf link-type { 908 type identityref { 909 base link-type; 910 } 911 description 912 "Link type, e.g. GRE,VXLAN,IP in IP, etc"; 913 } 914 container link-telemetry-attributes { 915 config false; 916 uses link-error-statistics; 917 uses link-delay-statistics; 918 uses link-jitter-statistics; 919 description 920 "Container for service telemetry attributes"; 921 } 922 } 923 augment "/nw:networks/nw:network/nw:node/nt:termination-point" { 924 description 925 "Augment the network topology termination point with vpn service attributes"; 926 container tp-telemetry-attributes { 927 config false; 928 uses tp-svc-telemetry; 929 description 930 "Container for termination point service telemetry attributes."; 931 } 932 } 933 } 935 937 10. Security Considerations 939 The YANG modules defined in this document MAY be accessed via the 940 RESTCONF protocol [RFC8040] or NETCONF protocol ([RFC6241]). The 941 lowest RESTCONF or NETCONF layer requires that the transport-layer 942 protocol provides both data integrity and confidentiality, see 943 Section 2 in [RFC8040] and [RFC6241]. The lowest NETCONF layer is 944 the secure transport layer, and the mandatory-to-implement secure 945 transport is Secure Shell (SSH)[RFC6242] . The lowest RESTCONF layer 946 is HTTPS, and the mandatory-to-implement secure transport is TLS 947 [RFC5246]. 949 The NETCONF access control model [RFC6536] provides the means to 950 restrict access for particular NETCONF or RESTCONF users to a 951 preconfigured subset of all available NETCONF or RESTCONF protocol 952 operations and content. 954 There are a number of data nodes defined in this YANG module that are 955 writable/creatable/deletable (i.e., config true, which is the 956 default). These data nodes may be considered sensitive or vulnerable 957 in some network environments. Write operations (e.g., edit-config) 958 to these data nodes without proper protection can have a negative 959 effect on network operations. These are the subtrees and data nodes 960 and their sensitivity/vulnerability: 962 o /nw:networks/nw:network/svc-topo:svc-telemetry-attributes 964 o /nw:networks/nw:network/nw:node/svc-topo:node-attributes 966 11. IANA Considerations 968 This document registers a URI in the IETF XML registry [RFC3688]. 969 Following the format in [RFC3688], the following registration is 970 requested to be made: 972 --------------------------------------------------------------------- 973 URI: urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm 975 Registrant Contact: The IESG. 977 XML: N/A, the requested URI is an XML namespace. 978 --------------------------------------------------------------------- 980 This document registers a YANG module in the YANG Module Names 981 registry [RFC6020]. 983 --------------------------------------------------------------------- 984 Name: ietf-network-vpn-pm 985 Namespace: urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm 986 Prefix: nvp 987 Reference: RFC xxxx 988 --------------------------------------------------------------------- 990 12. Normative References 992 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 993 Requirement Levels", March 1997. 995 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 996 DOI 10.17487/RFC3688, January 2004, 997 . 999 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1000 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1001 DOI 10.17487/RFC5440, March 2009, 1002 . 1004 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1005 the Network Configuration Protocol (NETCONF)", RFC 6020, 1006 DOI 10.17487/RFC6020, October 2010, 1007 . 1009 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1010 and A. Bierman, Ed., "Network Configuration Protocol 1011 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1012 . 1014 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1015 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1016 . 1018 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 1019 Profile (MPLS-TP) Identifiers", RFC 6370, 1020 DOI 10.17487/RFC6370, September 2011, 1021 . 1023 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 1024 Measurement for MPLS Networks", RFC 6374, 1025 DOI 10.17487/RFC6374, September 2011, 1026 . 1028 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1029 Protocol (NETCONF) Access Control Model", RFC 6536, 1030 DOI 10.17487/RFC6536, March 2012, 1031 . 1033 [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements 1034 for Subscription to YANG Datastores", RFC 7923, 1035 DOI 10.17487/RFC7923, June 2016, 1036 . 1038 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1039 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1040 . 1042 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", 1043 RFC 7952, DOI 10.17487/RFC7952, August 2016, 1044 . 1046 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1047 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1048 . 1050 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1051 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1052 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1053 2018, . 1055 Authors' Addresses 1057 Michael Wang 1058 Huawei Technologies,Co.,Ltd 1059 101 Software Avenue, Yuhua District 1060 Nanjing 210012 1061 China 1063 Email: wangzitao@huawei.com 1065 Qin Wu 1066 Huawei 1067 101 Software Avenue, Yuhua District 1068 Nanjing, Jiangsu 210012 1069 China 1071 Email: bill.wu@huawei.com 1073 Roni Even 1074 Huawei Technologies,Co.,Ltd 1075 Tel Aviv 1076 Israel 1078 Email: roni.even@huawei.com 1079 Bin Wen 1080 Comcast 1082 Email: bin_wen@comcast.com 1084 Change Liu 1085 China Unicom 1087 Email: liuc131@chinaunicom.cn 1089 Honglei Xu 1090 China Telecom 1092 Email: xuhl.bri@chinatelecom.cn