idnits 2.17.1 draft-www-bess-yang-vpn-service-pm-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 16 instances of too long lines in the document, the longest one being 24 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 (March 8, 2019) is 1848 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 893, but not defined == Missing Reference: 'RFC5246' is mentioned on line 897, but not defined ** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446) == Unused Reference: 'RFC6370' is defined on line 968, but no explicit reference was found in the text == Unused Reference: 'RFC7950' is defined on line 988, but no explicit reference was found in the text == Unused Reference: 'RFC7952' is defined on line 992, 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: September 9, 2019 Huawei 6 B. Wen 7 Comcast 8 C. Liu 9 China Unicom 10 March 8, 2019 12 A YANG Model for Network and VPN Service Performance Monitoring 13 draft-www-bess-yang-vpn-service-pm-02 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 September 9, 2019. 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 . . . . . . . . . . . . 11 76 9. Network and VPN Service Assurance YANG Module . . . . . . . . 11 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 78 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 79 12. Normative References . . . . . . . . . . . . . . . . . . . . 21 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 The Network and VPN service performance monitoring model defines only 267 the following minimal set of Network level service topology 268 attributes: 270 o svc-topo-type: Indicate the network type is service topology type 271 such as L3VPN service topology, L2VPN service topology. 273 o vpn-topo: The type of VPN service topology, this model supports 274 any-to-any, Hub and Spoke (where Hubs can exchange traffic), and 275 "Hub and Spoke disjoint" (where Hubs cannot exchange traffic). 277 6.2. Node Level 278 augment /nw:networks/nw:network/nw:node: 279 +--rw node-attributes 280 +--rw node-type? identityref 281 +--rw site-id? string 282 +--rw site-role? Identityref 284 Node Level View of the hierarchies 286 The Network and VPN service performance monitoring model defines only 287 the following minimal set of Node level service topology attributes 288 and constraints: 290 o Node-type (Attribute): Indicate the type of the node, such as PE 291 or ASBR. 293 o Site-id (Constraint): Uniquely identifies the site within the 294 overall network infrastructure. 296 o Site-role (Constraint): Defines the role of the site in a 297 particular VPN topology. 299 6.3. Link and Termination Point Level 300 augment /nw:networks/nw:network/nt:link: 301 +--ro svc-telemetry-attributes 302 +--ro loss-statistics 303 | +--ro direction identityref 304 | +--ro packet-loss-count? uint32 305 | +--ro loss-ratio? percentage 306 | +--ro packet-reorder-count? uint32 307 | +--ro packets-out-of-seq-count? uint32 308 | +--ro packets-dup-count? uint32 309 +--ro delay-statistics 310 | +--ro direction? identityref 311 | +--ro min-delay-value? uint32 312 | +--ro max-delay-value? uint32 313 | +--ro average-delay-value? uint32 314 +--ro jitter-statistics 315 +--ro direction? identityref 316 +--ro min-jitter-value? uint32 317 +--ro max-jitter-value? uint32 318 +--ro average-jitter-value? uint32 319 augment /nw:networks/nw:network/nw:node/nt:termination-point: 320 +--ro tp-telemetry-attributes 321 +--ro in-octets? uint32 322 +--ro inbound-unicast? uint32 323 +--ro inbound-nunicast? uint32 324 +--ro inbound-discards? uint32 325 +--ro inbound-errors? uint32 326 +--ro inunknow-protos? uint32 327 +--ro out-octets? uint32 328 +--ro outbound-unicast? uint32 329 +--ro outbound-nunicast? uint32 330 +--ro outbound-discards? uint32 331 +--ro outbound-errors? uint32 332 +--ro outbound-qlen? uint32 334 Link and Termination point Level View of the hierarchies 336 The Network and VPN service performance monitoring model defines only 337 the following minimal set of Link level service topology attributes: 339 Loss Statistics: A set of loss statistics attributes that are used 340 to measure end to end loss between VPN sites. 342 Delay Statistics: A set of delay statistics attributes that are 343 used to measure end to end latency between VPN sites. 345 Jitter Statistics: A set of jitter statistics attributes that are 346 used to measure end to end jitter between VPN sites. 348 The Network and VPN service performance monitoring defines the 349 following minimal set of Termination point level service topology 350 attributes: 352 Inbound statistics: A set of inbound statistics attributes that 353 are used to measure the inbound statistics of the termination 354 point, such as "the total number of octets received on the 355 termination point", "The number of inbound packets which were 356 chosen to be discarded", "The number of inbound packets that 357 contained errors", etc. 359 Outbound statistics: A set of outbound statistics attributes that 360 are used to measure the outbound statistics of the termination 361 point, such as "the total number of octets transmitted out of the 362 termination point", "The number of outbound packets which were 363 chosen to be discarded", "The number of outbound packets that 364 contained errors", etc. 366 7. Example of I2RS Pub/Sub Retrieval [RFC7923] 368 This example shows the way for a client to subscribe for the 369 Performance monitoring information between node A and node B in the 370 L3 network topology built on top of the underlying optical network . 371 The performance monitoring parameter that the client is interested in 372 is end to end loss attribute. 374 376 378 379 380 381 l3-network 382 383 A 384 385 pe 386 387 388 389 B 390 391 pe 392 393 394 395 A-B 396 397 A 398 399 400 B 401 402 404 405 100 406 407 408 409 410 411 412 500 413 414 416 8. Example of RPC model based Retrieval 418 This example shows the way for the client to use RPC model to fetch 419 performance data on demand,e.g., the client requests packet-loss- 420 count between PE1 in site 1 and PE2 in site 2 belonging to VPN1. 422 424 425 426 427 vpn1 428 429 A 430 431 pe 432 433 434 435 B 436 437 pe 438 439 440 A-B 441 442 A 443 444 445 B 446 447 448 449 120 450 451 452 453 454 455 457 9. Network and VPN Service Assurance YANG Module 459 file "ietf-network-vpn-svc-pm.yang" 460 module ietf-network-vpn-svc-pm { 461 yang-version 1.1; 462 namespace "urn:ietf:params:xml:ns:yang:ietf-network-vpn-svc-pm"; 463 prefix svc-topo; 464 import ietf-network { 465 prefix nw; 466 } 467 import ietf-network-topology { 468 prefix nt; 469 } 470 import ietf-l3vpn-svc { 471 prefix l3vpn-svc; 472 } 474 organization 475 "IETF xxx Working Group"; 476 contact 477 "Zitao Wang: wangzitao@huawei.com 478 Qin Wu: bill.wu@huawei.com"; 479 description 480 "This module defines a model for the VPN Service Performance monitoring."; 482 revision 2019-03-01 { 483 description 484 "Initial revision."; 485 reference 486 "foo"; 487 } 489 identity service-type { 490 description 491 "Base type for service topology"; 492 } 494 identity l3vpn-svc { 495 base service-type; 496 description 497 "Indentity for layer3 vpn service"; 498 } 500 identity l2vpn-svc { 501 base service-type; 502 description 503 "Identity for layer2 vpn service"; 504 } 506 identity node-type { 507 description 508 "Base identity for node type"; 509 } 511 identity pe { 512 base node-type; 513 description 514 "Identity for PE type"; 515 } 517 identity ce { 518 base node-type; 519 description 520 "Identity for CE type"; 521 } 523 identity asbr { 524 base node-type; 525 description 526 "Identity for ASBR type"; 527 } 529 identity p { 530 base node-type; 531 description 532 "Identity for P type"; 533 } 535 identity direction { 536 description 537 "Base Identity for measurement direction including 538 one way measurement and two way measurement."; 539 } 541 identity oneway { 542 base direction; 543 description 544 "Identity for one way measurement."; 545 } 547 identity twoway { 548 base direction; 549 description 550 "Identity for two way measurement."; 551 } 553 typedef percentage { 554 type decimal64 { 555 fraction-digits 5; 556 range "0..100"; 557 } 558 description 559 "Percentage."; 561 } 563 grouping link-error-statistics { 564 description 565 "Grouping for per link error statistics"; 566 container loss-statistics { 567 description 568 "Per link loss statistics."; 569 leaf direction { 570 type identityref { 571 base direction; 572 } 573 default "oneway"; 574 description 575 "Define measurement direction including one way 576 measurement and two way measurement."; 577 } 578 leaf packet-loss-count { 579 type uint32 { 580 range "0..4294967295"; 581 } 582 default "0"; 583 description 584 "Total received packet drops count. 585 The value of count will be set to zero (0) 586 on creation and will thereafter increase 587 monotonically until it reaches a maximum value 588 of 2^32-1 (4294967295 decimal), when it wraps 589 around and starts increasing again from zero."; 590 } 591 leaf loss-ratio { 592 type percentage; 593 description 594 "Loss ratio of the packets. Express as percentage 595 of packets lost with respect to packets sent."; 596 } 597 leaf packet-reorder-count { 598 type uint32 { 599 range "0..4294967295"; 600 } 601 default "0"; 602 description 603 "Total received packet reordered count. 604 The value of count will be set to zero (0) 605 on creation and will thereafter increase 606 monotonically until it reaches a maximum value 607 of 2^32-1 (4294967295 decimal), when it wraps 608 around and starts increasing again from zero."; 610 } 611 leaf packets-out-of-seq-count { 612 type uint32 { 613 range "0..4294967295"; 614 } 615 description 616 "Total received out of sequence count. 617 The value of count will be set to zero (0) 618 on creation and will thereafter increase 619 monotonically until it reaches a maximum value 620 of 2^32-1 (4294967295 decimal), when it wraps 621 around and starts increasing again from zero.."; 622 } 623 leaf packets-dup-count { 624 type uint32 { 625 range "0..4294967295"; 626 } 627 description 628 "Total received packet duplicates count. 629 The value of count will be set to zero (0) 630 on creation and will thereafter increase 631 monotonically until it reaches a maximum value 632 of 2^32-1 (4294967295 decimal), when it wraps 633 around and starts increasing again from zero."; 634 } 635 } 636 } 638 grouping link-delay-statistics { 639 description 640 "Grouping for per link delay statistics"; 641 container delay-statistics { 642 description 643 "Link delay summarised information. By default, 644 one way measurement protocol (e.g., OWAMP) is used 645 to measure delay."; 646 leaf direction { 647 type identityref { 648 base direction; 649 } 650 default "oneway"; 651 description 652 "Define measurement direction including one way 653 measurement and two way measurement."; 654 } 655 leaf min-delay-value { 656 type uint32; 657 description 658 "Minimum delay value observed."; 659 } 660 leaf max-delay-value { 661 type uint32; 662 description 663 "Maximum delay value observed."; 664 } 665 leaf average-delay-value { 666 type uint32; 667 description 668 "Average delay is calculated on all the packets of a sample 669 and is a simple computation to be performed for single marking method."; 670 } 671 } 672 } 674 grouping link-jitter-statistics { 675 description 676 "Grouping for per link jitter statistics"; 677 container jitter-statistics { 678 description 679 "Link jitter summarised information. By default, 680 jitter is measured using IP Packet Delay Variation 681 (IPDV) as defined in RFC3393."; 682 leaf direction { 683 type identityref { 684 base direction; 685 } 686 default "oneway"; 687 description 688 "Define measurement direction including one way 689 measurement and two way measurement."; 690 } 691 leaf min-jitter-value { 692 type uint32; 693 description 694 "Minimum jitter value observed."; 695 } 696 leaf max-jitter-value { 697 type uint32; 698 description 699 "Maximum jitter value observed."; 700 } 701 leaf average-jitter-value { 702 type uint32; 703 description 704 "Average jitter is calculated on all the packets of a sample 705 and is a simple computation to be performed for single marking method."; 707 } 708 } 709 } 711 grouping tp-svc-telemetry { 713 leaf in-octets { 714 type uint32; 715 description 716 "The total number of octets received on the 717 interface, including framing characters."; 718 } 719 leaf inbound-unicast { 720 type uint32; 721 description 722 "Inbound unicast packets were received, and delivered 723 to a higher layer during the last period."; 724 } 725 leaf inbound-nunicast { 726 type uint32; 727 description 728 "The number of non-unicast (i.e., subnetwork- 729 broadcast or subnetwork-multicast) packets 730 delivered to a higher-layer protocol."; 731 } 732 leaf inbound-discards { 733 type uint32; 734 description 735 "The number of inbound packets which were chosen 736 to be discarded even though no errors had been 737 detected to prevent their being deliverable to a 738 higher-layer protocol."; 739 } 740 leaf inbound-errors { 741 type uint32; 742 description 743 "The number of inbound packets that contained 744 errors preventing them from being deliverable to a 745 higher-layer protocol."; 746 } 747 leaf inunknow-protos { 748 type uint32; 749 description 750 "The number of packets received via the interface 751 which were discarded because of an unknown or 752 unsupported protocol"; 753 } 754 leaf out-octets { 755 type uint32; 756 description 757 "The total number of octets transmitted out of the 758 interface, including framing characters"; 759 } 760 leaf outbound-unicast { 761 type uint32; 762 description 763 "The total number of packets that higher-level 764 protocols requested be transmitted to a 765 subnetwork-unicast address, including those that 766 were discarded or not sent."; 767 } 768 leaf outbound-nunicast { 769 type uint32; 770 description 771 "The total number of packets that higher-level 772 protocols requested be transmitted to a non- 773 unicast (i.e., a subnetwork-broadcast or 774 subnetwork-multicast) address, including those 775 that were discarded or not sent."; 776 } 777 leaf outbound-discards { 778 type uint32; 779 description 780 "The number of outbound packets which were chosen 781 to be discarded even though no errors had been 782 detected to prevent their being transmitted. One 783 possible reason for discarding such a packet could 784 be to free up buffer space."; 785 } 786 leaf outbound-errors { 787 type uint32; 788 description 789 "The number of outbound packets that contained 790 errors preventing them from being deliverable to a 791 higher-layer protocol."; 792 } 793 leaf outbound-qlen { 794 type uint32; 795 description 796 " Length of the queue of the interface from where 797 the packet is forwarded out. The queue depth could 798 be the current number of memory buffers used by the 799 queue and a packet can consume one or more memory buffers 800 thus constituting device-level information."; 801 } 802 description 803 "Grouping for interface service telemetry"; 804 } 806 augment "/nw:networks/nw:network/nw:network-types" { 807 description 808 "Augment the network-types with service topologyies types"; 809 leaf svc-topo-type { 810 type identityref { 811 base service-type; 812 } 813 description 814 "Identify the topology type to be composited service topology"; 815 } 816 } 817 augment "/nw:networks/nw:network" { 818 description 819 "Augment the network with service topology attributes"; 820 container svc-topo-attributes { 821 leaf vpn-topology { 822 type identityref { 823 base l3vpn-svc:vpn-topology; 824 } 825 description 826 "VPN service topology, e.g. hub-spoke, any-to-any, hub-spoke-disjoint, etc"; 827 } 828 description 829 "Container for vpn services"; 830 } 831 } 832 augment "/nw:networks/nw:network/nw:node" { 833 description 834 "Augment the network node with serice attributes"; 835 container node-attributes { 836 leaf node-type { 837 type identityref { 838 base node-type; 839 } 840 description 841 "Node type, e.g. PE, P, ASBR, etc"; 842 } 843 leaf site-id { 844 type string; 845 description 846 "Asscoiated vpn site"; 847 } 848 leaf site-role { 849 type identityref { 850 base l3vpn-svc:site-role; 852 } 853 default "l3vpn-svc:any-to-any-role"; 854 description 855 "Role of the site in the IP VPN."; 856 } 857 description 858 "Container for service topology attributes"; 859 } 860 } 861 augment "/nw:networks/nw:network/nt:link" { 862 description 863 "Augment the network topology link with vpn service attributes"; 864 container svc-telemetry-attributes { 865 config false; 866 uses link-error-statistics; 867 uses link-delay-statistics; 868 uses link-jitter-statistics; 869 description 870 "Container for service telemetry attributes"; 871 } 872 } 873 augment "/nw:networks/nw:network/nw:node/nt:termination-point" { 874 description 875 "Augment the network topology termination point with vpn service attributes"; 876 container tp-telemetry-attributes { 877 config false; 878 uses tp-svc-telemetry; 879 description 880 "Container for termination point service telemetry attributes."; 881 } 882 } 883 } 885 887 10. Security Considerations 889 The YANG modules defined in this document MAY be accessed via the 890 RESTCONF protocol [RFC8040] or NETCONF protocol ([RFC6241]). The 891 lowest RESTCONF or NETCONF layer requires that the transport-layer 892 protocol provides both data integrity and confidentiality, see 893 Section 2 in [RFC8040] and [RFC6241]. The lowest NETCONF layer is 894 the secure transport layer, and the mandatory-to-implement secure 895 transport is Secure Shell (SSH)[RFC6242] . The lowest RESTCONF layer 896 is HTTPS, and the mandatory-to-implement secure transport is TLS 897 [RFC5246]. 899 The NETCONF access control model [RFC6536] provides the means to 900 restrict access for particular NETCONF or RESTCONF users to a 901 preconfigured subset of all available NETCONF or RESTCONF protocol 902 operations and content. 904 There are a number of data nodes defined in this YANG module that are 905 writable/creatable/deletable (i.e., config true, which is the 906 default). These data nodes may be considered sensitive or vulnerable 907 in some network environments. Write operations (e.g., edit-config) 908 to these data nodes without proper protection can have a negative 909 effect on network operations. These are the subtrees and data nodes 910 and their sensitivity/vulnerability: 912 o /nw:networks/nw:network/svc-topo:svc-telemetry-attributes 914 o /nw:networks/nw:network/nw:node/svc-topo:node-attributes 916 11. IANA Considerations 918 This document registers a URI in the IETF XML registry [RFC3688]. 919 Following the format in [RFC3688], the following registration is 920 requested to be made: 922 --------------------------------------------------------------------- 923 URI: urn:ietf:params:xml:ns:yang:ietf-network-vpn-svc-pm 925 Registrant Contact: The IESG. 927 XML: N/A, the requested URI is an XML namespace. 928 --------------------------------------------------------------------- 930 This document registers a YANG module in the YANG Module Names 931 registry [RFC6020]. 933 --------------------------------------------------------------------- 934 Name: ietf-vpn-svc-pm 935 Namespace: urn:ietf:params:xml:ns:yang:ietf-network-vpn-svc-pm 936 Prefix: vnrsc 937 Reference: RFC xxxx 938 --------------------------------------------------------------------- 940 12. Normative References 942 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 943 Requirement Levels", March 1997. 945 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 946 DOI 10.17487/RFC3688, January 2004, 947 . 949 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 950 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 951 DOI 10.17487/RFC5440, March 2009, 952 . 954 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 955 the Network Configuration Protocol (NETCONF)", RFC 6020, 956 DOI 10.17487/RFC6020, October 2010, 957 . 959 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 960 and A. Bierman, Ed., "Network Configuration Protocol 961 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 962 . 964 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 965 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 966 . 968 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 969 Profile (MPLS-TP) Identifiers", RFC 6370, 970 DOI 10.17487/RFC6370, September 2011, 971 . 973 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 974 Measurement for MPLS Networks", RFC 6374, 975 DOI 10.17487/RFC6374, September 2011, 976 . 978 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 979 Protocol (NETCONF) Access Control Model", RFC 6536, 980 DOI 10.17487/RFC6536, March 2012, 981 . 983 [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements 984 for Subscription to YANG Datastores", RFC 7923, 985 DOI 10.17487/RFC7923, June 2016, 986 . 988 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 989 RFC 7950, DOI 10.17487/RFC7950, August 2016, 990 . 992 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", 993 RFC 7952, DOI 10.17487/RFC7952, August 2016, 994 . 996 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 997 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 998 . 1000 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1001 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1002 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1003 2018, . 1005 Authors' Addresses 1007 Michael Wang 1008 Huawei Technologies,Co.,Ltd 1009 101 Software Avenue, Yuhua District 1010 Nanjing 210012 1011 China 1013 Email: wangzitao@huawei.com 1015 Qin Wu 1016 Huawei 1017 101 Software Avenue, Yuhua District 1018 Nanjing, Jiangsu 210012 1019 China 1021 Email: bill.wu@huawei.com 1023 Roni Even 1024 Huawei Technologies,Co.,Ltd 1025 Tel Aviv 1026 Israel 1028 Email: roni.even@huawei.com 1030 Bin Wen 1031 Comcast 1033 Email: bin_wen@comcast.com 1034 Change Liu 1035 China Unicom 1037 Email: liuc131@chinaunicom.cn