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