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