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
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
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