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