idnits 2.17.1
draft-ietf-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 :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (February 17, 2021) is 1164 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)
== Outdated reference: A later version (-18) exists of
draft-ietf-opsawg-l3sm-l3nm-05
== Outdated reference: A later version (-12) exists of
draft-ietf-opsawg-vpn-common-03
Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--).
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: August 21, 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 February 17, 2021
17 A YANG Model for Network and VPN Service Performance Monitoring
18 draft-ietf-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 August 21, 2021.
53 Copyright Notice
55 Copyright (c) 2021 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 Performance Monitoring Model Usage . 3
73 3.1. Retrieval via Pub/Sub Mechanism . . . . . . . . . . . . . 4
74 3.2. On demand Retrieval via RPC Model . . . . . . . . . . . . 5
75 4. Description of the Data Model . . . . . . . . . . . . . . . . 5
76 4.1. Layering Relationship Between Multiple Layers of Topology 5
77 4.2. Network Level . . . . . . . . . . . . . . . . . . . . . . 6
78 4.3. Node Level . . . . . . . . . . . . . . . . . . . . . . . 7
79 4.4. Link and Termination Point Level . . . . . . . . . . . . 8
80 5. Example of I2RS Pub/Sub Retrieval . . . . . . . . . . . . . . 11
81 6. Example of RPC-based Retrieval . . . . . . . . . . . . . . . 12
82 7. Network and VPN Service Assurance YANG Module . . . . . . . . 14
83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
85 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
86 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27
87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
88 12.1. Normative References . . . . . . . . . . . . . . . . . . 27
89 12.2. Informative References . . . . . . . . . . . . . . . . . 29
90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
92 1. Introduction
94 [RFC4176] provides a framework for L3VPN operations and management
95 and specifies that performance management is required after service
96 configuration. This document defines a YANG Model for both network
97 performance monitoring and VPN service performance monitoring that
98 can be used to monitor and manage network performance on the topology
99 level or the service topology between VPN sites.
101 This document does not introduce new metrics for network performance
102 or mechanisms for measuring network performance, but uses the
103 existing mechanisms and statistics to show the performance monitoring
104 statistics at the network and service layers. The YANG model defined
105 in this document is designed as an augmentation to the network
106 topology YANG model defined in [RFC8345] and draws on relevant YANG
107 types defined in [RFC6991], [RFC8299], [RFC8345], and [RFC8532].
109 2. Terminology
111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
113 "OPTIONAL" in this document are to be interpreted as described in BCP
114 14 [RFC2119][RFC8174] when, and only when, they appear in all
115 capitals, as shown here.
117 Tree diagrams used in this document follow the notation defined in
118 [RFC8340].
120 3. Network and VPN Service Performance Monitoring Model Usage
122 Models are key for automatic management operations. According to
123 [I-D.ietf-opsawg-model-automation-framework] , together with service
124 and network models, performance measurement telemetry model can
125 monitor network performance to meet specific service SLA
126 requirements. The model defined in this document is to derive VPN or
127 network level performance data based on lower-level data collected
128 via monitoring counters in the devices.
130 +---------------+
131 | Customer |
132 +---------------+
133 Customer Service Models |
134 |
135 +-----------------+
136 | Service |
137 | Orchestration |
138 +-----------------+
139 Service Network Models | | Network and VPN Service PM Model
140 | |
141 +-----------------+
142 | Network |
143 | Controller |
144 +-------|----------+
145 |
146 +------------------------------------------------+
147 Network
149 Figure 1: Reference Architecture
151 As shown in Figure 1 , the network and VPN service performance
152 monitoring model can be used to expose some performance information
153 to the above layer. The information can be used by the orchestrator
154 to subscribe to performance data. The controller will then notify
155 the orchestrator of corresponding parameter changes.
157 Before using the Network and VPN Service PM Model, the mapping
158 between the VPN Service topology and the underlying physical network
159 has been setup, and the performance monitoring data per link in the
160 underlying network can be collected using network performance
161 measurement method such as MPLS Loss and Delay Measurement [RFC6374].
163 The performance monitoring information reflecting the quality of the
164 Network or VPN service such as end to end network performance data
165 between source node and destination node in the network or between
166 VPN sites can be aggregated or calculated using, for example, PCEP
167 solution [RFC8233] [RFC7471] [RFC8570] [RFC8571] or LMAP [RFC8194].
169 The measurement interval and report interval associated with these
170 performance data usually depends on configuration parameters.
172 3.1. Retrieval via Pub/Sub Mechanism
174 Some applications such as service-assurance applications, which must
175 maintain a continuous view of operational data and state, can use
176 subscription model [RFC8641] to subscribe to the specific Network
177 performance data or VPN service performance data they are interested
178 in, at the data source.
180 The data source can then use the Network and VPN service assurance
181 model defined in this document and the YANG Push model [RFC8641] to
182 distribute specific telemetry data to target recipients.
184 3.2. On demand Retrieval via RPC Model
186 To obtain a snapshot of a large amount of performance data from a
187 network element (including network controllers), service-assurance
188 applications may use polling-based methods such as RPC model to fetch
189 performance data on demand.
191 4. Description of the Data Model
193 This document defines the YANG module "ietf-network-vpn-pm", which is
194 an augmentation to the "ietf-network" and "ietf-network-topology".
196 The performance monitoring data is augmented to service topology as
197 shown in Figure 2.
199 +----------------------+ +-----------------------+
200 |ietf-network | |Network and VPN Service|
201 |ietf-network-topology |<---------|Performance Monitoring |
202 +----------------------+ augments | Model |
203 +-----------------------+
205 Figure 2: Module Augmentation
207 4.1. Layering Relationship Between Multiple Layers of Topology
209 [RFC8345] defines a YANG [RFC7950] data model for network/service
210 topologies and inventories. The service topology described in
211 [RFC8345] includes the virtual topology for a service layer above
212 Layer 1 (L1), Layer 2 (L2), and Layer 3 (L3). This service topology
213 has the generic topology elements of node, link, and terminating
214 point. One typical example of a service topology is described in
215 Figure 3 of [RFC8345]: two VPN service topologies instantiated over a
216 common L3 topology. Each VPN service topology is mapped onto a
217 subset of nodes from the common L3 topology.
219 Figure 3 illustrates an example of a topology mapping between the VPN
220 service topology and an underlying network:
222 VPN-SVC 1 VPN-SVC 2
223 / \
224 VPN-Service-topology 1 VPN-Service-topology-2
225 / | \ / | \
226 Site-1A Site-1B Site1-C Site-2A Site-2B Site-2C Top-Down
227 | | | | | | Service Topology
228 CE CE CE CE CE CE
229 | | | | | |
230 PE PE PE PE PE PE
231 ====|==========|=======|=======|=========|=====|====================
232 +-------+ | \ / / |
233 Bottom-up | | \ / / |
234 Network | | /\ / |
235 topology | | / \ | |
236 | | | | | |
237 node1 node2 node3 node4 node5 node6
239 Figure 3: Example of topology mapping between VPN Service Topo and
240 Underlying network
242 As shown in Figure 3, two VPN services topologies are both built on
243 top of one common underlying physical network:
245 o VPN-SVC 1: supporting "hub-spoke" communications for Customer 1
246 connecting the customer's access at 3 sites. Site-1A, Site-1B,
247 and Site-1C are connected to PEs that are mapped to nodes 1, 2,
248 and 3 in the underlying physical network.
249 Site-1 A plays the role of hub while Site-2 B and C plays the role
250 of spoke.
252 o VPN-SVC 2: supporting "hub-spoke disjoint" communications for
253 Customer 2 connecting the customer's access at 3 sites. Site-2A,
254 Site-2B, and Site-2C are connected to PEs that are mapped to nodes
255 4, 5, and 6 in the underlying physical network.
257 Site-2 A and B play the role of hub while Site-2 C plays the role
258 of spoke.
260 4.2. Network Level
262 For network performance monitoring, the attributes of "Network Level"
263 that defined in [RFC8345] do not need to be extended.
265 For VPN service performance monitoring, this document defines some
266 new network service type: "L3VPN, L2VPN". When a network topology
267 data instance contains the L3VPN or L2VPN network type, it represents
268 an VPN instance that can perform performance monitoring.
270 This model defines only the following minimal set of Network level
271 network topology attributes:
273 o "vpn-id": Refers to an identifier of VPN service
274 (e.g.,L3NM[I-D.ietf-opsawg-l3sm-l3nm]). This identifier allows to
275 correlate the performance status with the network service
276 configuration.
278 o "vpn-topo": The type of VPN service topology, this model supports
279 "any-to-any", "Hub and Spoke" (where Hubs can exchange traffic),
280 and "Hub and Spoke disjoint" (where Hubs cannot exchange traffic).
281 [RFC8299] defines a YANG model for L3VPN Service Delivery. Three
282 types of VPN service topologies are supported in : "any to any",
283 "hub and spoke", and "hub and spoke disjoint". These VPN topology
284 types can be used to describe how VPN sites communicate with each
285 other.
287 module: ietf-network-vpn-pm
288 augment /nw:networks/nw:network/nw:network-types:
289 +--rw network-service-type!
290 +--rw network-service-type? identityref
291 augment /nw:networks/nw:network:
292 +--rw vpn-topo-attributes
293 +--rw vpn-id? vpn-common:vpn-id
294 +--rw vpn-topology? identityref
296 Figure 4: Network Level View of the hierarchies
298 4.3. Node Level
300 For network performance monitoring, the attributes of "Node Level"
301 that defined in [RFC8345] do not need to be extended.
303 For VPN service performance monitoring, this model defines only the
304 following minimal set of Node level network topology attributes:
306 o "node-type" (Attribute): Indicates the type of the node, such as
307 PE or ASBR. This "node-type" can be used to report performance
308 metric between any two nodes each with specific node-type.
310 o "site-id" (Constraint): Uniquely identifies the site within the
311 overall network infrastructure.
313 o "site-role" (Constraint): Defines the role of the site in a
314 particular VPN topology.
316 o "vpn-summary-statistics": IPv4 statistics, and IPv6 statistics
317 have been specified separately. And MAC statistics could be
318 extended for L2VPN.
320 augment /nw:networks/nw:network/nw:node:
321 +--rw node-attributes
322 | +--rw node-type? identityref
323 | +--rw site-id? string
324 | +--rw site-role? identityref
325 +--rw vpn-summary-statistics
326 +--rw ipv4
327 | +--rw total-routes? uint32
328 | +--rw total-active-routes? uint32
329 +--rw ipv6
330 +--rw total-routes? uint32
331 +--rw total-active-routes? uint32
333 Figure 5: Node Level View of the hierarchies
335 4.4. Link and Termination Point Level
337 The link nodes are classified into two types: one is topology link
338 defined in [RFC8345], and the other is abstract link of a VPN between
339 PEs.
341 The performance data of the link is a collection of counters that
342 report the performance status. The data for the topology link can be
343 based on BGP-LS [RFC8571]. The statistics of the VPN abstract links
344 can be collected based on VPN OAM mechanisms, e.g. TWAMP etc.
345 Alternatively, the data can base on the underlay technology OAM
346 mechanism, for example, GRE tunnel OAM.
348 augment /nw:networks/nw:network/nt:link:
349 +--rw link-type? identityref
350 augment /nw:networks/nw:network/nt:link:
351 +--rw low-percentile? percentile
352 +--rw middle-percentile? percentile
353 +--rw high-percentile? percentile
354 +--rw reference-time? yang:date-and-time
355 +--rw measurement-interval? uint32
356 +--ro link-telemetry-attributes
357 +--ro loss-statistics
358 | +--ro packet-loss-count? yang:counter32
359 | +--ro packet-reorder-count? yang:counter32
360 | +--ro packets-out-of-seq-count? yang:counter32
361 | +--ro packets-dup-count? yang:counter32
362 | +--ro loss-ratio? percentage
363 +--ro delay-statistics
364 | +--ro direction? identityref
365 | +--ro unit-value? identityref
366 | +--ro min-delay-value? yang:gauge64
367 | +--ro max-delay-value? yang:gauge64
368 | +--ro low-delay-percentile? yang:gauge64
369 | +--ro middle-delay-percentile? yang:gauge64
370 | +--ro high-delay-percentile? yang:gauge64
371 +--ro jitter-statistics
372 +--ro unit-value? identityref
373 +--ro min-jitter-value? yang:gauge32
374 +--ro max-jitter-value? yang:gauge32
375 +--ro low-jitter-percentile? yang:gauge32
376 +--ro middle-jitter-percentile? yang:gauge32
377 +--ro high-jitter-percentile? yang:gauge32
378 augment /nw:networks/nw:network/nw:node/nt:termination-point:
379 +--ro tp-telemetry-attributes
380 +--ro inbound-octets? yang:counter64
381 +--ro inbound-unicast? yang:counter64
382 +--ro inbound-nunicast? yang:counter64
383 +--ro inbound-discards? yang:counter32
384 +--ro inbound-errors? yang:counter32
385 +--ro inbound-unknown-protocol? yang:counter32
386 +--ro outbound-octets? yang:counter64
387 +--ro outbound-unicast? yang:counter64
388 +--ro outbound-nunicast? yang:counter64
389 +--ro outbound-discards? yang:counter32
390 +--ro outbound-errors? yang:counter32
391 +--ro outbound-qlen? uint32
393 Figure 6: Link and Termination point Level View of the hierarchies
395 For the nodes of the link in the figure, this module defines the
396 following minimal set of link level performance attributes:
398 o "link-type": Indicates the abstract link of a VPN, such as GRE or
399 IP-in-IP. The leaf refers to an identifier of VPN Common
400 "underlay-transport" [I-D.ietf-opsawg-vpn-common], which describes
401 the transport technology to carry the traffic of the VPN service.
403 o Percentile parameters: The module supports reporting delay and
404 jitter metric by percentile values. By default, low percentile
405 (10th percentile), mid percentile (50th percentile), high
406 percentile (90th percentile) are used. Setting a percentile into
407 0.00 indicates the client is not interested in receiving
408 particular percentile. If all percentile nodes are set to 0.00,
409 this represents that no percentile related nodes will be reported
410 for a given performance metric (e.g. one-way delay, one-way delay
411 variation) and only peak/min values will be reported. For
412 example, a client can inform the server that it is interested in
413 receiving only high percentiles. Then for a given link, at a
414 given "reference-time" "measurement-interval", the high-delay-
415 percentile and high-jitter-percentile will be reported.
417 o Loss Statistics: A set of loss statistics attributes that are used
418 to measure end to end loss between VPN sites or between any two
419 network nodes. The exact loss value or the loss percentage can be
420 reported.
422 o Delay Statistics: A set of delay statistics attributes that are
423 used to measure end to end latency between VPN sites or between
424 any two network nodes. The peak/min values or percentile values
425 can be reported.
427 o Jitter Statistics: A set of IP Packet Delay Variation [RFC3393]
428 statistics attributes that are used to measure end to end jitter
429 between VPN sites or between any two network nodes. The peak/min
430 values or percentile values can be reported.
432 For the nodes of "termination points" in the figure, the module
433 defines the following minimal set of statistics:
435 o Inbound statistics: A set of inbound statistics attributes that
436 are used to measure the inbound statistics of the termination
437 point, such as received packets, received packets with errors,
438 etc.
440 o Outbound statistics: A set of outbound statistics attributes that
441 are used to measure the outbound statistics of the termination
442 point, such as sent packets, packets that could not be sent due to
443 errors, etc.
445 5. Example of I2RS Pub/Sub Retrieval
447 This example shows the way for a client to subscribe for the
448 Performance monitoring information between node A and node B in the
449 L3 network topology built on top of the underlying network . The
450 performance monitoring parameter that the client is interested in is
451 end to end loss attribute.
453
455
457
458
460
461 l3-network
462
464 L3VPN
465
466
467 A
468
470 pe
471
472
474 1-0-1
475
477 150
478 100
479
480
481
482
483 B
484
486 pe
487
488
490 2-0-1
491
493 150
494 100
495
496
497
498
500 A-B
501
504
505 B
506
507 mpls-te
508
510
511 100
512
513
514
515
516
517
518
520 500
521
522
523
525 6. Example of RPC-based Retrieval
527 This example shows the way for the client to use RPC model to fetch
528 performance data on demand, e.g., the client requests "packet-loss-
529 count" between PE1 in site 1 and PE2 in site 2 belonging to the same
530 VPN1.
532
534
536
537
538 vpn1
539
540 A
541
543 pe
544
545
547 1-0-1
548
550 100
551 150
552
553
554
555
556 B
557
559 pe
560
561
563 2-0-1
564
566 150
567 100
568
569
570
571
572 A-B
573
576
577 B
578
579 mpls-te
580
582
583 120
584
585
587
588
589
590
592 7. Network and VPN Service Assurance YANG Module
594 This module uses types defined in [RFC8345], [RFC8299] and [RFC8532].
596 file "ietf-network-vpn-pm@2021-01-15.yang"
597 module ietf-network-vpn-pm {
598 yang-version 1.1;
599 namespace "urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm";
600 prefix nvp;
602 import ietf-yang-types {
603 prefix yang;
604 reference
605 "RFC 6991: Common YANG Types.";
606 }
607 import ietf-vpn-common {
608 prefix vpn-common;
609 }
610 import ietf-network {
611 prefix nw;
612 reference
613 "Section 6.1 of RFC 8345: A YANG Data Model for Network
614 Topologies";
615 }
616 import ietf-network-topology {
617 prefix nt;
618 reference
619 "Section 6.2 of RFC 8345: A YANG Data Model for Network
620 Topologies";
621 }
622 import ietf-lime-time-types {
623 prefix lime;
624 reference
625 "RFC 8532: Generic YANG Data Model for the Management of
626 Operations, Administration, and Maintenance (OAM) Protocols
627 That Use Connectionless Communications";
628 }
630 organization
631 "IETF OPSAWG Working Group";
632 contact
633 "Editor: Qin Wu
634
636 Editor: Bo Wu
637
638 Editor: Mohamed Boucadair
639 ";
640 description
641 "This module defines a model for Network and VPN Service Performance
642 monitoring.
644 Copyright (c) 2021 IETF Trust and the persons identified as
645 authors of the code. All rights reserved.
647 Redistribution and use in source and binary forms, with or
648 without modification, is permitted pursuant to, and subject
649 to the license terms contained in, the Simplified BSD License
650 set forth in Section 4.c of the IETF Trust's Legal Provisions
651 Relating to IETF Documents
652 (http://trustee.ietf.org/license-info).
654 This version of this YANG module is part of RFC XXXX; see
655 the RFC itself for full legal notices.";
657 revision 2021-01-15 {
658 description
659 "Initial revision.";
660 reference
661 "RFC XXXX: A YANG Model for Network and VPN Service Performance
662 Monitoring";
663 }
665 identity pe {
666 base vpn-common:role;
667 description
668 "Identity for PE type";
669 }
671 identity ce {
672 base vpn-common:role;
673 description
674 "Identity for CE type";
675 }
677 identity asbr {
678 base vpn-common:role;
679 description
680 "Identity for ASBR type";
681 }
683 identity p {
684 base vpn-common:role;
685 description
686 "Identity for P type";
687 }
689 identity link-type {
690 base vpn-common:protocol-type;
691 description
692 "Base identity for link type, e.g.,GRE, MPLS TE, VXLAN.";
693 }
695 identity VXLAN {
696 base link-type;
697 description
698 "Base identity for VXLAN Tunnel.";
699 }
701 identity ip-in-ip {
702 base link-type;
703 description
704 "Base identity for IP in IP Tunnel.";
705 }
707 identity direction {
708 description
709 "Base Identity for measurement direction including
710 one way measurement and two way measurement.";
711 }
713 identity one-way {
714 base direction;
715 description
716 "Identity for one way measurement.";
717 }
719 identity two-way {
720 base direction;
721 description
722 "Identity for two way measurement.";
723 }
725 typedef percentage {
726 type decimal64 {
727 fraction-digits 5;
728 range "0..100";
729 }
730 description
731 "Percentage.";
733 }
735 typedef percentile {
736 type decimal64 {
737 fraction-digits 5;
738 }
739 description
740 "The percentile is a statistical value that indicates that a
741 certain percentage of a set of data falls below it.";
742 }
744 grouping vpn-summary-statistics {
745 description
746 "VPN Statistics grouping used for network topology
747 augmentation.";
748 container vpn-summary-statistics {
749 description
750 "Container for VPN summary statistics.";
751 container ipv4 {
752 leaf total-routes {
753 type uint32;
754 description
755 "Total routes for the VPN.";
756 }
757 leaf total-active-routes {
758 type uint32;
759 description
760 "Total active routes for the VPN.";
761 }
762 description
763 "IPv4-specific parameters.";
764 }
765 container ipv6 {
766 leaf total-routes {
767 type uint32;
768 description
769 "Total routes for the VPN.";
770 }
771 leaf total-active-routes {
772 type uint32;
773 description
774 "Total active routes for the VPN.";
775 }
776 description
777 "IPv6-specific parameters.";
778 }
779 }
780 }
781 grouping link-error-statistics {
782 description
783 "Grouping for per link error statistics.";
784 container loss-statistics {
785 description
786 "Per link loss statistics.";
787 leaf packet-loss-count {
788 type yang:counter32;
789 description
790 "Total received packet drops count.";
791 }
792 leaf packet-reorder-count {
793 type yang:counter32;
794 description
795 "Total received packet reordered count.";
796 }
797 leaf packets-out-of-seq-count {
798 type yang:counter32;
799 description
800 "Total received out of sequence count.";
801 }
802 leaf packets-dup-count {
803 type yang:counter32;
804 description
805 "Total received packet duplicates count.";
806 }
807 leaf loss-ratio {
808 type percentage;
809 description
810 "Loss ratio of the packets. Express as percentage
811 of packets lost with respect to packets sent.";
812 }
813 }
814 }
816 grouping link-delay-statistics {
817 description
818 "Grouping for per link delay statistics";
819 container delay-statistics {
820 description
821 "Link delay summarised information. By default,
822 one way measurement protocol (e.g., OWAMP) is used
823 to measure delay.";
824 leaf direction {
825 type identityref {
826 base direction;
827 }
828 default "one-way";
829 description
830 "Define measurement direction including one way
831 measurement and two way measurement.";
832 }
833 leaf unit-value {
834 type identityref {
835 base lime:time-unit-type;
836 }
837 default "lime:milliseconds";
838 description
839 "Time units, where the options are s, ms, ns, etc.";
840 }
841 leaf min-delay-value {
842 type yang:gauge64;
843 description
844 "Minimum delay value observed.";
845 }
846 leaf max-delay-value {
847 type yang:gauge64;
848 description
849 "Maximum delay value observed.";
850 }
851 leaf low-delay-percentile {
852 type yang:gauge64;
853 description
854 "Low percentile of the delay observed with
855 specific measurement method.";
856 }
857 leaf middle-delay-percentile {
858 type yang:gauge64;
859 description
860 "Middle percentile of the delay observed with
861 specific measurement method.";
862 }
863 leaf high-delay-percentile {
864 type yang:gauge64;
865 description
866 "High percentile of the delay observed with
867 specific measurement method.";
868 }
869 }
870 }
872 grouping link-jitter-statistics {
873 description
874 "Grouping for per link jitter statistics";
875 container jitter-statistics {
876 description
877 "Link jitter summarised information. By default,
878 jitter is measured using IP Packet Delay Variation
879 (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:gauge32;
890 description
891 "Minimum jitter value observed.";
892 }
893 leaf max-jitter-value {
894 type yang:gauge32;
895 description
896 "Maximum jitter value observed.";
897 }
898 leaf low-jitter-percentile {
899 type yang:gauge32;
900 description
901 "Low percentile of the jitter observed.";
902 }
903 leaf middle-jitter-percentile {
904 type yang:gauge32;
905 description
906 "Middle percentile of the jitter observed.";
907 }
908 leaf high-jitter-percentile {
909 type yang:gauge32;
910 description
911 "High percentile of the jitter observed.";
912 }
913 }
914 }
916 grouping tp-svc-telemetry {
917 leaf inbound-octets {
918 type yang:counter64;
919 description
920 "The total number of octets received on the
921 interface, including framing characters.";
922 }
923 leaf inbound-unicast {
924 type yang:counter64;
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 yang:counter64;
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 yang:counter32;
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 yang:counter32;
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 inbound-unknown-protocol {
952 type yang:counter32;
953 description
954 "The number of packets received via the interface
955 which were discarded because of an unknown or
956 unsupported protocol.";
957 }
958 leaf outbound-octets {
959 type yang:counter64;
960 description
961 "The total number of octets transmitted out of the
962 interface, including framing characters.";
963 }
964 leaf outbound-unicast {
965 type yang:counter64;
966 description
967 "The total number of packets that higher-level
968 protocols requested be transmitted to a
969 subnetwork-unicast address, including those that
970 were discarded or not sent.";
971 }
972 leaf outbound-nunicast {
973 type yang:counter64;
974 description
975 "The total number of packets that higher-level
976 protocols requested be transmitted to a non-
977 unicast (i.e., a subnetwork-broadcast or
978 subnetwork-multicast) address, including those
979 that were discarded or not sent.";
980 }
981 leaf outbound-discards {
982 type yang:counter32;
983 description
984 "The number of outbound packets which were chosen
985 to be discarded even though no errors had been
986 detected to prevent their being transmitted. One
987 possible reason for discarding such a packet could
988 be to free up buffer space.";
989 }
990 leaf outbound-errors {
991 type yang:counter32;
992 description
993 "The number of outbound packets that contained
994 errors preventing them from being deliverable to a
995 higher-layer protocol.";
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 "Defines the service topologyies types";
1013 container network-service-type {
1014 presence "Indicates Network service topology";
1015 leaf network-service-type {
1016 type identityref {
1017 base vpn-common:service-type;
1018 }
1019 description
1020 "The presence identifies the network service type,
1021 e.g., L3VPN, L2VPN, etc.";
1022 }
1023 description
1024 "Container for vpn service type.";
1025 }
1026 }
1028 augment "/nw:networks/nw:network" {
1029 when 'nw:network-types/nvp:network-service-type' {
1030 description
1031 "Augment only for VPN Network topology.";
1032 }
1033 description
1034 "Augment the network with service topology attributes";
1035 container vpn-topo-attributes {
1036 leaf vpn-id {
1037 type vpn-common:vpn-id;
1038 description
1039 "Pointer to the parent VPN service(e.g., L3NM),
1040 if any.";
1041 }
1042 leaf vpn-topology {
1043 type identityref {
1044 base vpn-common:vpn-topology;
1045 }
1046 description
1047 "VPN service topology, e.g., hub-spoke, any-to-any,
1048 hub-spoke-disjoint";
1049 }
1050 description
1051 "Container for vpn topology attributes.";
1052 }
1053 }
1055 augment "/nw:networks/nw:network/nw:node" {
1056 when '../nw:network-types/nvp:network-service-type' {
1057 description
1058 "Augment only for VPN Network topology.";
1059 }
1060 description
1061 "Augment the network node with service topology attributes";
1062 container node-attributes {
1063 leaf node-type {
1064 type identityref {
1065 base vpn-common:role;
1066 }
1067 description
1068 "Node type, e.g., PE, P, ASBR.";
1070 }
1071 leaf site-id {
1072 type string;
1073 description
1074 "Associated vpn site";
1075 }
1076 leaf site-role {
1077 type identityref {
1078 base vpn-common:role;
1079 }
1080 default "vpn-common:any-to-any-role";
1081 description
1082 "Role of the site in the VPN.";
1083 }
1084 description
1085 "Container for service topology attributes.";
1086 }
1087 uses vpn-summary-statistics;
1088 }
1090 augment "/nw:networks/nw:network/nt:link" {
1091 when '../nw:network-types/nvp:network-service-type' {
1092 description
1093 "Augment only for VPN Network topology.";
1094 }
1095 description
1096 "Augment the network topology link with service topology
1097 attributes";
1098 leaf link-type {
1099 type identityref {
1100 base vpn-common:protocol-type;
1101 }
1102 description
1103 "Underlay-transport type, e.g., GRE, LDP, etc.";
1104 }
1105 }
1107 augment "/nw:networks/nw:network/nt:link" {
1108 description
1109 "Augment the network topology link with service topology
1110 attributes";
1111 leaf low-percentile {
1112 type percentile;
1113 default "10.00";
1114 description
1115 "Low percentile to report. Setting low-percentile
1116 into 0.00 indicates the client is not interested in receiving
1117 low percentile.";
1119 }
1120 leaf middle-percentile {
1121 type percentile;
1122 default "50.00";
1123 description
1124 "Middle percentile to report. Setting middle-percentile
1125 into 0.00 indicates the client is not interested in receiving
1126 middle percentile.";
1127 }
1128 leaf high-percentile {
1129 type percentile;
1130 default "90.00";
1131 description
1132 "High percentile to report. Setting high-percentile
1133 into 0.00 indicates the client is not interested in receiving
1134 high percentile";
1135 }
1136 leaf reference-time {
1137 type yang:date-and-time;
1138 description
1139 "The time that the current Measurement Interval started.";
1140 }
1141 leaf measurement-interval {
1142 type uint32;
1143 units "seconds";
1144 default "60";
1145 description
1146 "Interval to calculate performance metric.";
1147 }
1148 container link-telemetry-attributes {
1149 config false;
1150 uses link-error-statistics;
1151 uses link-delay-statistics;
1152 uses link-jitter-statistics;
1153 description
1154 "Container for service telemetry attributes.";
1155 }
1156 }
1158 augment "/nw:networks/nw:network/nw:node/nt:termination-point" {
1159 description
1160 "Augment the network topology termination point with vpn
1161 service attributes";
1162 container tp-telemetry-attributes {
1163 config false;
1164 uses tp-svc-telemetry;
1165 description
1166 "Container for termination point service telemetry attributes.";
1168 }
1169 }
1170 }
1171
1173 8. Security Considerations
1175 The YANG modules defined in this document MAY be accessed via the
1176 RESTCONF protocol [RFC8040] or NETCONF protocol [RFC6241]. The
1177 lowest RESTCONF or NETCONF layer requires that the transport-layer
1178 protocol provides both data integrity and confidentiality, see
1179 Section 2 in [RFC8040] and [RFC6241]. The lowest NETCONF layer is
1180 the secure transport layer, and the mandatory-to-implement secure
1181 transport is Secure Shell (SSH)[RFC6242] . The lowest RESTCONF layer
1182 is HTTPS, and the mandatory-to-implement secure transport is TLS
1183 [RFC8446].
1185 The NETCONF access control model [RFC8341] provides the means to
1186 restrict access for particular NETCONF or RESTCONF users to a
1187 preconfigured subset of all available NETCONF or RESTCONF protocol
1188 operations and content.
1190 There are a number of data nodes defined in this YANG module that are
1191 writable/creatable/deletable (i.e., config true, which is the
1192 default). These data nodes may be considered sensitive or vulnerable
1193 in some network environments. Write operations (e.g., edit-config)
1194 to these data nodes without proper protection can have a negative
1195 effect on network operations. These are the subtrees and data nodes
1196 and their sensitivity/vulnerability:
1198 o /nw:networks/nw:network/svc-topo:svc-telemetry-attributes
1200 o /nw:networks/nw:network/nw:node/svc-topo:node-attributes
1202 9. IANA Considerations
1204 This document requests IANA to register the following URI in the "ns"
1205 subregistry within the "IETF XML Registry" [RFC3688]:
1207 URI: urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm
1208 Registrant Contact: The IESG.
1209 XML: N/A, the requested URI is an XML namespace.
1211 This document requests IANA to register the following YANG module in
1212 the "YANG Module Names" subregistry [RFC6020] within the "YANG
1213 Parameters" registry.
1215 Name: ietf-network-vpn-pm
1216 Namespace: urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm
1217 Maintained by IANA: N
1218 Prefix: nvp
1219 Reference: RFC XXXX
1221 10. Acknowledgements
1223 Thanks to Joe Clarke, Adrian Farrel, Greg Mirsky,Roque Gagliano,Erez
1224 Segev for reviewing this draft and providing important input to this
1225 document.
1227 11. Contributors
1229 Michale Wang
1230 Huawei
1231 Email:wangzitao@huawei.com
1233 Roni Even
1234 Huawei
1235 Email: ron.even.tlv@gmail.com
1237 12. References
1239 12.1. Normative References
1241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1242 Requirement Levels", BCP 14, RFC 2119,
1243 DOI 10.17487/RFC2119, March 1997,
1244 .
1246 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
1247 Metric for IP Performance Metrics (IPPM)", RFC 3393,
1248 DOI 10.17487/RFC3393, November 2002,
1249 .
1251 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1252 DOI 10.17487/RFC3688, January 2004,
1253 .
1255 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
1256 the Network Configuration Protocol (NETCONF)", RFC 6020,
1257 DOI 10.17487/RFC6020, October 2010,
1258 .
1260 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
1261 and A. Bierman, Ed., "Network Configuration Protocol
1262 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
1263 .
1265 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
1266 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
1267 .
1269 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
1270 Measurement for MPLS Networks", RFC 6374,
1271 DOI 10.17487/RFC6374, September 2011,
1272 .
1274 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
1275 RFC 6991, DOI 10.17487/RFC6991, July 2013,
1276 .
1278 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
1279 RFC 7950, DOI 10.17487/RFC7950, August 2016,
1280 .
1282 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1283 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1284 May 2017, .
1286 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
1287 "YANG Data Model for L3VPN Service Delivery", RFC 8299,
1288 DOI 10.17487/RFC8299, January 2018,
1289 .
1291 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
1292 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
1293 .
1295 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
1296 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
1297 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
1298 2018, .
1300 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
1301 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
1302 .
1304 [RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S.
1305 Raghavan, "Generic YANG Data Model for the Management of
1306 Operations, Administration, and Maintenance (OAM)
1307 Protocols That Use Connectionless Communications",
1308 RFC 8532, DOI 10.17487/RFC8532, April 2019,
1309 .
1311 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
1312 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
1313 September 2019, .
1315 12.2. Informative References
1317 [I-D.ietf-opsawg-l3sm-l3nm]
1318 barguil, s., Dios, O., Boucadair, M., Munoz, L., and A.
1319 Aguado, "A Layer 3 VPN Network YANG Model", draft-ietf-
1320 opsawg-l3sm-l3nm-05 (work in progress), October 2020.
1322 [I-D.ietf-opsawg-model-automation-framework]
1323 WU, Q., Boucadair, M., Lopez, D., Xie, C., and L. Geng, "A
1324 Framework for Automating Service and Network Management
1325 with YANG", draft-ietf-opsawg-model-automation-
1326 framework-10 (work in progress), October 2020.
1328 [I-D.ietf-opsawg-vpn-common]
1329 barguil, s., Dios, O., Boucadair, M., and Q. WU, "A Layer
1330 2/3 VPN Common YANG Model", draft-ietf-opsawg-vpn-
1331 common-03 (work in progress), January 2021.
1333 [RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K.,
1334 and A. Gonguet, "Framework for Layer 3 Virtual Private
1335 Networks (L3VPN) Operations and Management", RFC 4176,
1336 DOI 10.17487/RFC4176, October 2005,
1337 .
1339 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
1340 Previdi, "OSPF Traffic Engineering (TE) Metric
1341 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
1342 .
1344 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
1345 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
1346 .
1348 [RFC8194] Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for
1349 LMAP Measurement Agents", RFC 8194, DOI 10.17487/RFC8194,
1350 August 2017, .
1352 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki,
1353 "Extensions to the Path Computation Element Communication
1354 Protocol (PCEP) to Compute Service-Aware Label Switched
1355 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September
1356 2017, .
1358 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
1359 Access Control Model", STD 91, RFC 8341,
1360 DOI 10.17487/RFC8341, March 2018,
1361 .
1363 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
1364 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
1365 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
1366 2019, .
1368 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and
1369 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of
1370 IGP Traffic Engineering Performance Metric Extensions",
1371 RFC 8571, DOI 10.17487/RFC8571, March 2019,
1372 .
1374 Authors' Addresses
1376 Bo Wu
1377 Huawei
1378 101 Software Avenue, Yuhua District
1379 Nanjing, Jiangsu 210012
1380 China
1382 Email: lana.wubo@huawei.com
1384 Qin Wu
1385 Huawei
1386 101 Software Avenue, Yuhua District
1387 Nanjing, Jiangsu 210012
1388 China
1390 Email: bill.wu@huawei.com
1392 Mohamed Boucadair
1393 Orange
1394 Rennes 35000
1395 France
1397 Email: mohamed.boucadair@orange.com
1398 Oscar Gonzalez de Dios
1399 Telefonica
1400 Madrid
1401 ES
1403 Email: oscar.gonzalezdedios@telefonica.com
1405 Bin Wen
1406 Comcast
1408 Email: bin_wen@comcast.com
1410 Change Liu
1411 China Unicom
1413 Email: liuc131@chinaunicom.cn
1415 Honglei Xu
1416 China Telecom
1418 Email: xuhl.bri@chinatelecom.cn