idnits 2.17.1
draft-www-opsawg-yang-vpn-service-pm-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 29 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
== Line 1042 has weird spacing: '...Network topol...'
-- The document date (November 2, 2020) is 1271 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 167, but not defined
== Missing Reference: 'RFC8040' is mentioned on line 1181, but not defined
== Missing Reference: 'RFC5246' is mentioned on line 1185, but not defined
** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446)
== Unused Reference: 'RFC6370' is defined on line 1270, but no explicit
reference was found in the text
== Unused Reference: 'RFC7923' is defined on line 1289, but no explicit
reference was found in the text
== Unused Reference: 'RFC7950' is defined on line 1294, but no explicit
reference was found in the text
== Unused Reference: 'RFC7952' is defined on line 1298, 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 (~~), 9 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: May 6, 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 November 2, 2020
17 A YANG Model for Network and VPN Service Performance Monitoring
18 draft-www-opsawg-yang-vpn-service-pm-02
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 May 6, 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 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 . . . . . . . . 13
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
151 As shown in figure 1, the Network and VPN Service PM Model can be
152 used to expose some performance information to the above layer. The
153 information can be used by the Orchestrator to subscribe to
154 performance data. The Controller will then notify the Orchestrator
155 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] [RFC7810] [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 [I-D.ietf-netconf-yang-push] to subscribe to the
177 specific Network performance data or VPN service performance data
178 they are interested 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
182 [I-D.ietf-netconf-yang-push] to distribute specific telemetry data to
183 target recipients.
185 3.2. On demand Retrieval via RPC Model
187 To obtain a snapshot of a large amount of performance data from a
188 network element (including network controllers), service-assurance
189 applications may use polling-based methods such as RPC model to fetch
190 performance data on demand.
192 4. Description of the Data Model
194 This document defines the YANG module "ietf-network-vpn-pm", which is
195 an augmentation to the "ietf-network" and "ietf-network-topology".
197 The performance monitoring data is augmented to service topology as
198 shown in Figure 1.
200 +----------------------+ +-----------------------+
201 |ietf-network | |Network and VPN Service|
202 |ietf-network-topology |<---------|Performance Monitoring |
203 +----------------------+ augments | Model |
204 +-----------------------+
206 Figure 1: Module Augmentation
208 [RFC8345]defines a YANG data model for network/service topologies and
209 inventories. The service topology described in [RFC8345] includes
210 the virtual topology for a service layer above Layer 1 (L1), Layer 2
211 (L2), and Layer 3 (L3). This service topology has the generic
212 topology elements of node, link, and terminating point. One typical
213 example of a service topology is described in Figure 3 of [RFC8345]:
214 two VPN service topologies instantiated over a common L3 topology.
215 Each VPN service topology is mapped onto a subset of nodes from the
216 common L3 topology.
218 4.1. Layering Relationship Between Multiple Layers of Topology
220 The data model defined in [RFC8345] can describe vertical layering
221 relationships between networks. That model can be augmented to cover
222 network/service topologies.
224 Figure 2 illustrates an example of a topology mapping between the VPN
225 service topology and an underlying network:
227 VPN-SVC 1 VPN-SVC 2
228 / \
229 VPN-Service-topology 1 VPN-Service-topology-2
230 / | \ / | \
231 Site-1A Site-1B Site1-C Site-2A Site-2B Site-2C Top-Down
232 | | | | | | Service Topology
233 CE CE CE CE CE CE
234 | | | | | |
235 PE PE PE PE PE PE
236 ====|==========|=======|=======|=========|=====|======================
237 +-------+ | \ / / |
238 Bottom-up | | \ / / |
239 Network | | /\ / |
240 topology | | / \ | |
241 | | | | | |
242 node1 node2 node3 node4 node5 node6
244 Figure 2: Example of topology mapping between VPN Service Topo and
245 Underlying network
247 As shown in Figure 2, two VPN services topologies are both built on
248 top of one common underlying physical network:
250 o VPN-SVC 1: supporting "hub-spoke" communications for Customer 1
251 connecting the customer's access at 3 sites. Site-1A, Site-1B,
252 and Site-1C are connected to PEs that are mapped to nodes 1, 2,
253 and 3 in the underlying physical network.
255 Site-1 A plays the role of hub while Site-2 B and C plays the role
256 of spoke.
258 o VPN-SVC 2: supporting "hub-spoke disjoint" communications for
259 Customer 2 connecting the customer's access at 3 sites. Site-2A,
260 Site-2B, and Site-2C are connected to PEs that are mapped to nodes
261 4, 5, and 6 in the underlying physical network.
263 Site-2 A and B play the role of hub while Site-2 C plays the role
264 of spoke.
266 4.2. Network Level
268 For network performance monitoring, the attributes of "Network Level"
269 that defined in [RFC8345] do not need to be extended.
271 For VPN service performance monitoring, this document defines some
272 new network type: "L3VPN, L2VPN". When a network topology data
273 instance contains the L3VPN or L2VPN network type, it represents an
274 VPN instance that can perform performance monitoring.
276 This model defines only the following minimal set of Network level
277 network topology attributes:
279 o "l3nm-vpn-id": Refers to an identifier of L3NM service. This
280 identifier allows to correlate the performance status with the
281 network service configuration.
283 o "vpn-topo": The type of VPN service topology, this model supports
284 "any-to-any", "Hub and Spoke" (where Hubs can exchange traffic),
285 and "Hub and Spoke disjoint" (where Hubs cannot exchange traffic).
286 [RFC8299] defines a YANG model for L3VPN Service Delivery. Three
287 types of VPN service topologies are supported in : "any to any",
288 "hub and spoke", and "hub and spoke disjoint". These VPN topology
289 types can be used to describe how VPN sites communicate with each
290 other.
292 module: ietf-network-vpn-pm
293 augment /nw:networks/nw:network/nw:network-types:
294 +--rw network-service-type!
295 +--rw network-service-type? identityref
296 augment /nw:networks/nw:network:
297 +--rw vpn-topo-attributes
298 +--rw l3nm-vpn-id? vpn-common:vpn-id
299 +--rw vpn-topology? identityref
301 Figure 3: Network Level View of the hierarchies
303 4.3. Node Level
305 For network performance monitoring, the attributes of "Node Level"
306 that defined in [RFC8345] do not need to be extended.
308 For VPN service performance monitoring, this model defines only the
309 following minimal set of Node level network topology attributes:
311 o "node-type" (Attribute): Indicates the type of the node, such as
312 PE or ASBR. This "node-type" can be used to report performance
313 metric between any two nodes each with specific node-type.
315 o "site-id" (Constraint): Uniquely identifies the site within the
316 overall network infrastructure.
318 o "site-role" (Constraint): Defines the role of the site in a
319 particular VPN topology.
321 o "vpn-summary-statistics": IPv4 statistics, and IPv6 statisticshave
322 been specified separately. And MAC statistics could be extended
323 for L2VPN.
325 augment /nw:networks/nw:network/nw:node:
326 +--rw node-attributes
327 | +--rw node-type? identityref
328 | +--rw site-id? string
329 | +--rw site-role? identityref
330 +--rw vpn-summary-statistics
331 +--rw ipv4
332 | +--rw total-routes? uint32
333 | +--rw total-active-routes? uint32
334 +--rw ipv6
335 +--rw total-routes? uint32
336 +--rw total-active-routes? uint32
338 Figure 4: Node Level View of the hierarchies
340 4.4. Link and Termination Point Level
342 The link nodes are classified into two types: one is topology link
343 defined in [RFC8345] , and the other is abstract link of a VPN
344 between PEs.
346 The performance statistics of the topology links can be based on BGP-
347 LS [RFC8571]. The statistics of the VPN abstract links can be
348 collected based on VPN OAM mechanisms, e.g. TWAMP etc.
349 Alternatively, the data cen based on the underlay technology OAM
350 mechanism, for example, GRE tunnel OAM.
352 "link-type": Refers to an identifier of L3NM "underlay-transport".
353 This identifier describes the transport technology to carry the
354 traffic of the VPN service.
356 augment /nw:networks/nw:network/nt:link:
357 +--rw link-type? identityref
358 augment /nw:networks/nw:network/nt:link:
359 +--rw low-percentile percentile
360 +--rw high-percentile percentile
361 +--rw middle-percentile percentile
362 +--ro reference-time yang:date-and-time
363 +--ro measurement-interval uint32
364 +--ro link-telemetry-attributes
365 +--ro loss-statistics
366 | +--ro packet-loss-count? uint32
367 | +--ro loss-ratio? percentage
368 | +--ro packet-reorder-count? uint32
369 | +--ro packets-out-of-seq-count? uint32
370 | +--ro packets-dup-count? uint32
371 +--ro delay-statistics
372 | +--ro direction? identityref
373 | +--ro unit-value identityref
374 | +--ro min-delay-value? yang:gauge64
375 | +--ro max-delay-value? yang:gauge64
376 | +--ro high-delay-percentile? yang:gauge64
377 | +--ro middle-delay-percentile? yang:gauge64
378 | +--ro low-delay-percentile? yang:gauge64
379 +--ro jitter-statistics
380 +--ro unit-value identityref
381 +--ro min-jitter-value? yang:gauge64
382 +--ro max-jitter-value? yang:gauge64
383 +--ro low-jitter-percentile? yang:gauge64
384 +--ro high-jitter-percentile? yang:gauge64
385 +--ro middle-jitter-percentile? yang:gauge64
386 augment /nw:networks/nw:network/nw:node/nt:termination-point:
387 +--ro tp-telemetry-attributes
388 +--ro in-octets? uint32
389 +--ro out-octets? uint32
390 +--ro inbound-unicast? uint32
391 +--ro inbound-nunicast? uint32
392 +--ro inbound-discards? uint32
393 +--ro inbound-errors? uint32
394 +--ro in-unknown-protocol? uint32
395 +--ro outbound-unicast? uint32
396 +--ro outbound-nunicast? uint32
397 +--ro outbound-discards? uint32
398 +--ro outbound-errors? uint32
399 +--ro outbound-qlen? uint32
401 Figure 5: Link and Termination point Level View of the hierarchies
403 The Network and VPN service performance monitoring model defines only
404 the following minimal set of Link level network topology attributes:
406 o "link-type" (Attribute): Indicates the type of the link, such as
407 GRE or IP-in-IP.
409 o "low-percentile": Indicates low percentile to report. Setting
410 low-percentile into 0.00 indicates the client is not interested in
411 receiving low percentile.
413 o "middle-percentile": Indicates middle percentile to report.
414 Setting middle-percentile into 0.00 indicates the client is not
415 interested in receiving middle percentile.
417 o "high-percentile": Indicates high percentile to report. Setting
418 low-percentile into 0.00 indicates the client is not interested in
419 receiving high percentile.
421 o Loss Statistics: A set of loss statistics attributes that are used
422 to measure end to end loss between VPN sites or between any two
423 network nodes.
425 o Delay Statistics: A set of delay statistics attributes that are
426 used to measure end to end latency between VPN sites or between
427 any two network nodes..
429 o Jitter Statistics: A set of IP Packet Delay Variation [RFC3393]
430 statistics attributes that are used to measure end to end jitter
431 between VPN sites or between any two network nodes..
433 The Network and VPN service performance monitoring defines the
434 following minimal set of Termination point level network topology
435 attributes:
437 o Inbound statistics: A set of inbound statistics attributes that
438 are used to measure the inbound statistics of the termination
439 point, such as "the total number of octets received on the
440 termination point", "The number of inbound packets which were
441 chosen to be discarded", "The number of inbound packets that
442 contained errors", etc.
444 o Outbound statistics: A set of outbound statistics attributes that
445 are used to measure the outbound statistics of the termination
446 point, such as "the total number of octets transmitted out of the
447 termination point", "The number of outbound packets which were
448 chosen to be discarded", "The number of outbound packets that
449 contained errors", etc.
451 5. Example of I2RS Pub/Sub Retrieval
453 This example shows the way for a client to subscribe for the
454 Performance monitoring information between node A and node B in the
455 L3 network topology built on top of the underlying network . The
456 performance monitoring parameter that the client is interested in is
457 end to end loss attribute.
459
461
463
464
465
466 l3-network
467
468 L3VPN
469
470
471 A
472
473 pe
474
475
476 1-0-1
477
478 100
479 150
480
481
482
483
484 B
485
486 pe
487
488
489 2-0-1
490
491 150
492 100
493
494
495
496
497 A-B
498
501
502 B
503
504 mpls-te
505
507
508 100
509
510
511
512
513
514
515 500
516
517
519 6. Example of RPC-based Retrieval
521 This example shows the way for the client to use RPC model to fetch
522 performance data on demand, e.g., the client requests "packet-loss-
523 count" between PE1 in site 1 and PE2 in site 2 belonging to the same
524 VPN1.
526
528
529
530
531 vpn1
532
533 A
534
535 pe
536
537
538 1-0-1
539
540 100
541 150
542
543
544
545
546 B
547
548 pe
549
550
551 2-0-1
552
553 150
554 100
555
556
557
558 A-B
559
562
563 B
564
565 mpls-te
566
567
568 120
569
570
571
572
573
574
576 7. Network and VPN Service Assurance YANG Module
578 This module uses types defined in [RFC8345], [RFC8299] and [RFC8532].
580 file "ietf-network-vpn-pm@2020-10-30.yang"
581 module ietf-network-vpn-pm {
582 yang-version 1.1;
583 namespace "urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm";
584 prefix nvp;
586 import ietf-yang-types {
587 prefix yang;
588 reference
589 "RFC 6991: Common YANG Types.";
590 }
591 import ietf-vpn-common {
592 prefix vpn-common;
593 }
594 import ietf-network {
595 prefix nw;
596 reference
597 "Section 6.1 of RFC 8345: A YANG Data Model for Network
598 Topologies";
599 }
600 import ietf-network-topology {
601 prefix nt;
602 reference
603 "Section 6.2 of RFC 8345: A YANG Data Model for Network
604 Topologies";
605 }
606 import ietf-lime-time-types {
607 prefix lime;
608 reference
609 "RFC 8532: Generic YANG Data Model for the Management of
610 Operations, Administration, and Maintenance (OAM) Protocols
611 That Use Connectionless Communications";
612 }
614 organization
615 "IETF OPSAWG Working Group";
616 contact
617 "Editor: Qin Wu
618
619 Editor: Mohamed Boucadair
620 ";
621 description
622 "This module defines a model for Network and VPN Service Performance
623 monitoring.
625 Copyright (c) 2020 IETF Trust and the persons identified as
626 authors of the code. All rights reserved.
628 Redistribution and use in source and binary forms, with or
629 without modification, is permitted pursuant to, and subject
630 to the license terms contained in, the Simplified BSD License
631 set forth in Section 4.c of the IETF Trust's Legal Provisions
632 Relating to IETF Documents
633 (http://trustee.ietf.org/license-info).
635 This version of this YANG module is part of RFC XXXX; see
636 the RFC itself for full legal notices.";
638 revision 2020-10-28 {
639 description
640 "Initial revision.";
641 reference
642 "RFC XXXX: A YANG Model for Network and VPN Service Performance
643 Monitoring";
644 }
646 identity pe {
647 base vpn-common:role;
648 description
649 "Identity for PE type";
650 }
652 identity ce {
653 base vpn-common:role;
654 description
655 "Identity for CE type";
656 }
658 identity asbr {
659 base vpn-common:role;
660 description
661 "Identity for ASBR type";
662 }
664 identity p {
665 base vpn-common:role;
666 description
667 "Identity for P type";
668 }
670 identity link-type {
671 base vpn-common:protocol-type;
672 description
673 "Base identity for link type, e.g.,GRE, MPLS TE, VXLAN.";
674 }
676 identity VXLAN {
677 base link-type;
678 description
679 "Base identity for VXLAN Tunnel.";
680 }
682 identity ip-in-ip {
683 base link-type;
684 description
685 "Base identity for IP in IP Tunnel.";
686 }
688 identity direction {
689 description
690 "Base Identity for measurement direction including
691 one way measurement and two way measurement.";
692 }
694 identity one-way {
695 base direction;
696 description
697 "Identity for one way measurement.";
698 }
700 identity two-way {
701 base direction;
702 description
703 "Identity for two way measurement.";
704 }
706 typedef percentage {
707 type decimal64 {
708 fraction-digits 5;
709 range "0..100";
710 }
711 description
712 "Percentage.";
713 }
715 typedef percentile {
716 type decimal64 {
717 fraction-digits 2;
718 }
719 description
720 "The nth percentile of a set of data is the
721 value at which n percent of the data is below it.";
722 }
724 grouping vpn-summary-statistics {
725 description
726 "VPN Statistics grouping used for network topology
727 augmentation.";
728 container vpn-summary-statistics {
729 description
730 "Container for VPN summary statistics.";
731 container ipv4 {
732 leaf total-routes {
733 type uint32;
734 description
735 "Total routes in the RIB from all protocols.";
736 }
737 leaf total-active-routes {
738 type uint32;
739 description
740 "Total active routes in the RIB.";
741 }
742 description
743 "IPv4-specific parameters.";
744 }
745 container ipv6 {
746 leaf total-routes {
747 type uint32;
748 description
749 "Total routes in the RIB from all protocols.";
750 }
751 leaf total-active-routes {
752 type uint32;
753 description
754 "Total active routes in the RIB.";
755 }
756 description
757 "IPv6-specific parameters.";
758 }
759 }
760 }
762 grouping link-error-statistics {
763 description
764 "Grouping for per link error statistics.";
765 container loss-statistics {
766 description
767 "Per link loss statistics.";
768 leaf packet-loss-count {
769 type uint32 {
770 range "0..4294967295";
771 }
772 default "0";
773 description
774 "Total received packet drops count.
775 The value of count will be set to zero (0)
776 on creation and will thereafter increase
777 monotonically until it reaches a maximum value
778 of 2^32-1 (4294967295 decimal), when it wraps
779 around and starts increasing again from zero.";
780 }
781 leaf loss-ratio {
782 type percentage;
783 description
784 "Loss ratio of the packets. Express as percentage
785 of packets lost with respect to packets sent.";
786 }
787 leaf packet-reorder-count {
788 type uint32 {
789 range "0..4294967295";
790 }
791 default "0";
792 description
793 "Total received packet reordered 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-out-of-seq-count {
801 type uint32 {
802 range "0..4294967295";
803 }
804 description
805 "Total received out of sequence 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 leaf packets-dup-count {
813 type uint32 {
814 range "0..4294967295";
815 }
816 description
817 "Total received packet duplicates count.
818 The value of count will be set to zero (0)
819 on creation and will thereafter increase
820 monotonically until it reaches a maximum value
821 of 2^32-1 (4294967295 decimal), when it wraps
822 around and starts increasing again from zero.";
823 }
824 }
825 }
827 grouping link-delay-statistics {
828 description
829 "Grouping for per link delay statistics";
830 container delay-statistics {
831 description
832 "Link delay summarised information. By default,
833 one way measurement protocol (e.g., OWAMP) is used
834 to measure delay.";
836 leaf direction {
837 type identityref {
838 base direction;
839 }
840 default "one-way";
841 description
842 "Define measurement direction including one way
843 measurement and two way measurement.";
844 }
845 leaf unit-value {
846 type identityref {
847 base lime:time-unit-type;
848 }
849 default "lime:milliseconds";
850 description
851 "Time units, where the options are s, ms, ns, etc.";
852 }
853 leaf min-delay-value {
854 type yang:gauge64;
855 description
856 "Minimum delay value observed.";
857 }
858 leaf max-delay-value {
859 type yang:gauge64;
860 description
861 "Maximum delay value observed.";
862 }
863 leaf low-delay-percentile {
864 type yang:gauge64;
865 description
866 "Low percentile of the delay observed with
867 specific measurement method.";
868 }
869 leaf middle-delay-percentile {
870 type yang:gauge64;
871 description
872 "Middle percentile of the delay observed with
873 specific measurement method.";
874 }
875 leaf high-delay-percentile {
876 type yang:gauge64;
877 description
878 "High percentile of the delay observed with
879 specific measurement method.";
880 }
881 }
882 }
883 grouping link-jitter-statistics {
884 description
885 "Grouping for per link jitter statistics";
886 container jitter-statistics {
887 description
888 "Link jitter summarised information. By default,
889 jitter is measured using IP Packet Delay Variation
890 (IPDV).";
891 leaf unit-value {
892 type identityref {
893 base lime:time-unit-type;
894 }
895 default "lime:milliseconds";
896 description
897 "Time units, where the options are s, ms, ns, etc.";
898 }
899 leaf min-jitter-value {
900 type yang:gauge64;
901 description
902 "Minimum jitter value observed.";
903 }
904 leaf max-jitter-value {
905 type yang:gauge64;
906 description
907 "Maximum jitter value observed.";
908 }
909 leaf low-jitter-percentile {
910 type yang:gauge64;
911 description
912 "Low percentile of the jitter observed.";
913 }
914 leaf middle-jitter-percentile {
915 type yang:gauge64;
916 description
917 "Middle percentile of the jitter observed.";
918 }
919 leaf high-jitter-percentile {
920 type yang:gauge64;
921 description
922 "High percentile of the jitter observed.";
923 }
924 }
925 }
927 grouping tp-svc-telemetry {
928 leaf in-octets {
929 type uint32;
930 description
931 "The total number of octets received on the
932 interface, including framing characters.";
933 }
934 leaf inbound-unicast {
935 type uint32;
936 description
937 "Inbound unicast packets were received, and delivered
938 to a higher layer during the last period.";
939 }
940 leaf inbound-nunicast {
941 type uint32;
942 description
943 "The number of non-unicast (i.e., subnetwork-
944 broadcast or subnetwork-multicast) packets
945 delivered to a higher-layer protocol.";
946 }
947 leaf inbound-discards {
948 type uint32;
949 description
950 "The number of inbound packets which were chosen
951 to be discarded even though no errors had been
952 detected to prevent their being deliverable to a
953 higher-layer protocol.";
954 }
955 leaf inbound-errors {
956 type uint32;
957 description
958 "The number of inbound packets that contained
959 errors preventing them from being deliverable to a
960 higher-layer protocol.";
961 }
962 leaf outbound-errors {
963 type uint32;
964 description
965 "The number of outbound packets that contained
966 errors preventing them from being deliverable to a
967 higher-layer protocol.";
968 }
969 leaf in-unknown-protocol {
970 type uint32;
971 description
972 "The number of packets received via the interface
973 which were discarded because of an unknown or
974 unsupported protocol.";
975 }
976 leaf out-octets {
977 type uint32;
978 description
979 "The total number of octets transmitted out of the
980 interface, including framing characters.";
981 }
982 leaf outbound-unicast {
983 type uint32;
984 description
985 "The total number of packets that higher-level
986 protocols requested be transmitted to a
987 subnetwork-unicast address, including those that
988 were discarded or not sent.";
989 }
990 leaf outbound-nunicast {
991 type uint32;
992 description
993 "The total number of packets that higher-level
994 protocols requested be transmitted to a non-
995 unicast (i.e., a subnetwork-broadcast or
996 subnetwork-multicast) address, including those
997 that were discarded or not sent.";
998 }
999 leaf outbound-discards {
1000 type uint32;
1001 description
1002 "The number of outbound packets which were chosen
1003 to be discarded even though no errors had been
1004 detected to prevent their being transmitted. One
1005 possible reason for discarding such a packet could
1006 be to free up buffer space.";
1007 }
1008 leaf outbound-qlen {
1009 type uint32;
1010 description
1011 " Length of the queue of the interface from where
1012 the packet is forwarded out. The queue depth could
1013 be the current number of memory buffers used by the
1014 queue and a packet can consume one or more memory buffers
1015 thus constituting device-level information.";
1016 }
1017 description
1018 "Grouping for interface service telemetry.";
1019 }
1021 augment "/nw:networks/nw:network/nw:network-types" {
1022 description
1023 "Defines the service topologyies types";
1024 container network-service-type {
1025 presence "Indicates Network service topology";
1026 leaf network-service-type {
1027 type identityref {
1028 base vpn-common:service-type;
1029 }
1030 description
1031 "The presence identifies the network service type, e.g., L3VPN,
1032 L2VPN, etc.";
1033 }
1034 }
1035 }
1037 augment "/nw:networks/nw:network" {
1038 description
1039 "Augment the network with service topology attributes";
1040 when 'nw:network-types/nvp:network-service-type' {
1041 description
1042 "Augment only for VPN Network topology.";
1043 }
1044 container vpn-topo-attributes {
1045 leaf l3nm-vpn-id {
1046 type vpn-common:vpn-id;
1047 description
1048 "Pointer to the parent L3NM service,
1049 if any.";
1050 }
1051 leaf vpn-topology {
1052 type identityref {
1053 base vpn-common:vpn-topology;
1054 }
1055 description
1056 "VPN service topology, e.g., hub-spoke, any-to-any,
1057 hub-spoke-disjoint";
1058 }
1059 description
1060 "Container for vpn topology attributes.";
1061 }
1062 }
1064 augment "/nw:networks/nw:network/nw:node" {
1065 description
1066 "Augment the network node with overlay topology attributes";
1067 when '../nw:network-types/nvp:network-service-type' {
1068 description
1069 "Augment only for VPN Network topology.";
1070 }
1071 container node-attributes {
1072 leaf node-type {
1073 type identityref {
1074 base vpn-common:role;
1076 }
1077 description
1078 "Node type, e.g., PE, P, ASBR.";
1079 }
1080 leaf site-id {
1081 type string;
1082 description
1083 "Associated vpn site";
1084 }
1085 leaf site-role {
1086 type identityref {
1087 base vpn-common:role;
1088 }
1089 default "vpn-common:any-to-any-role";
1090 description
1091 "Role of the site in the VPN.";
1092 }
1093 description
1094 "Container for overlay topology attributes.";
1095 }
1096 uses vpn-summary-statistics;
1097 }
1099 augment "/nw:networks/nw:network/nt:link" {
1100 description
1101 "Augment the network topology link with overlay topology attributes";
1102 when '../nw:network-types/nvp:network-service-type' {
1103 description
1104 "Augment only for VPN Network topology.";
1105 }
1106 leaf link-type {
1107 type identityref {
1108 base vpn-common:routing-protocol-type;
1109 }
1110 description
1111 "Underlay-transport type, e.g., GRE, LDP, etc.";
1112 }
1113 }
1115 augment "/nw:networks/nw:network/nt:link" {
1116 description
1117 "Augment the network topology link with overlay topology attributes";
1118 leaf low-percentile {
1119 type percentile;
1120 default "10.00";
1121 description
1122 "Low percentile to report.Setting low-percentile into 0.00 indicates
1123 the client is not interested in receiving low percentile.";
1125 }
1126 leaf middle-percentile {
1127 type percentile;
1128 default "50.00";
1129 description
1130 "Middle percentile to report.Setting middle-percentile into 0.00 indicates
1131 the client is not interested in receiving middle percentile.";
1132 }
1133 leaf high-percentile {
1134 type percentile;
1135 default "90.00";
1136 description
1137 "High percentile to report.";
1138 }
1139 leaf reference-time {
1140 type yang:date-and-time;
1141 description
1142 "The time that the current Measurement Interval started.Setting high-percentile
1143 into 0.00 indicates the client is not interested in receiving high percentile.";
1144 }
1145 leaf measurement-interval {
1146 type uint32;
1147 units "seconds";
1148 default "60";
1149 description
1150 "Interval to calculate performance metric.";
1151 }
1152 container link-telemetry-attributes {
1153 config false;
1154 uses link-error-statistics;
1155 uses link-delay-statistics;
1156 uses link-jitter-statistics;
1157 description
1158 "Container for service telemetry attributes.";
1159 }
1160 }
1162 augment "/nw:networks/nw:network/nw:node/nt:termination-point" {
1163 description
1164 "Augment the network topology termination point with vpn service attributes";
1165 container tp-telemetry-attributes {
1166 config false;
1167 uses tp-svc-telemetry;
1168 description
1169 "Container for termination point service telemetry attributes.";
1170 }
1171 }
1172 }
1173
1175 8. Security Considerations
1177 The YANG modules defined in this document MAY be accessed via the
1178 RESTCONF protocol [RFC8040] or NETCONF protocol ([RFC6241]). The
1179 lowest RESTCONF or NETCONF layer requires that the transport-layer
1180 protocol provides both data integrity and confidentiality, see
1181 Section 2 in [RFC8040] and [RFC6241]. The lowest NETCONF layer is
1182 the secure transport layer, and the mandatory-to-implement secure
1183 transport is Secure Shell (SSH)[RFC6242] . The lowest RESTCONF layer
1184 is HTTPS, and the mandatory-to-implement secure transport is TLS
1185 [RFC5246].
1187 The NETCONF access control model [RFC6536] provides the means to
1188 restrict access for particular NETCONF or RESTCONF users to a
1189 preconfigured subset of all available NETCONF or RESTCONF protocol
1190 operations and content.
1192 There are a number of data nodes defined in this YANG module that are
1193 writable/creatable/deletable (i.e., config true, which is the
1194 default). These data nodes may be considered sensitive or vulnerable
1195 in some network environments. Write operations (e.g., edit-config)
1196 to these data nodes without proper protection can have a negative
1197 effect on network operations. These are the subtrees and data nodes
1198 and their sensitivity/vulnerability:
1200 o /nw:networks/nw:network/svc-topo:svc-telemetry-attributes
1202 o /nw:networks/nw:network/nw:node/svc-topo:node-attributes
1204 9. IANA Considerations
1206 This document requests IANA to register the following URI in the "ns"
1207 subregistry within the "IETF XML Registry" [RFC3688]:
1209 URI: urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm
1210 Registrant Contact: The IESG.
1211 XML: N/A, the requested URI is an XML namespace.
1213 This document requests IANA to register the following YANG module in
1214 the "YANG Module Names" subregistry [RFC6020] within the "YANG
1215 Parameters" registry.
1217 Name: ietf-network-vpn-pm
1218 Namespace: urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm
1219 Maintained by IANA: N
1220 Prefix: nvp
1221 Reference: RFC XXXX
1223 10. Acknowledgements
1225 Thanks to Adrian Farrel for reviewing this draft and providing
1226 important input to this document.
1228 11. Contributors
1230 Michale Wang
1231 Huawei
1232 Email:wangzitao@huawei.com
1234 Roni Even
1235 Huawei
1236 Email: ron.even.tlv@gmail.com
1238 12. References
1240 12.1. Normative References
1242 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1243 Requirement Levels", BCP 14, RFC 2119,
1244 DOI 10.17487/RFC2119, March 1997,
1245 .
1247 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
1248 Metric for IP Performance Metrics (IPPM)", RFC 3393,
1249 DOI 10.17487/RFC3393, November 2002,
1250 .
1252 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1253 DOI 10.17487/RFC3688, January 2004,
1254 .
1256 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
1257 the Network Configuration Protocol (NETCONF)", RFC 6020,
1258 DOI 10.17487/RFC6020, October 2010,
1259 .
1261 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
1262 and A. Bierman, Ed., "Network Configuration Protocol
1263 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
1264 .
1266 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
1267 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
1268 .
1270 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
1271 Profile (MPLS-TP) Identifiers", RFC 6370,
1272 DOI 10.17487/RFC6370, September 2011,
1273 .
1275 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
1276 Measurement for MPLS Networks", RFC 6374,
1277 DOI 10.17487/RFC6374, September 2011,
1278 .
1280 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
1281 Protocol (NETCONF) Access Control Model", RFC 6536,
1282 DOI 10.17487/RFC6536, March 2012,
1283 .
1285 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
1286 RFC 6991, DOI 10.17487/RFC6991, July 2013,
1287 .
1289 [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements
1290 for Subscription to YANG Datastores", RFC 7923,
1291 DOI 10.17487/RFC7923, June 2016,
1292 .
1294 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
1295 RFC 7950, DOI 10.17487/RFC7950, August 2016,
1296 .
1298 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG",
1299 RFC 7952, DOI 10.17487/RFC7952, August 2016,
1300 .
1302 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1303 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1304 May 2017, .
1306 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
1307 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
1308 .
1310 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
1311 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
1312 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
1313 2018, .
1315 [RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S.
1316 Raghavan, "Generic YANG Data Model for the Management of
1317 Operations, Administration, and Maintenance (OAM)
1318 Protocols That Use Connectionless Communications",
1319 RFC 8532, DOI 10.17487/RFC8532, April 2019,
1320 .
1322 12.2. Informative References
1324 [I-D.ietf-netconf-yang-push]
1325 Clemm, A. and E. Voit, "Subscription to YANG Datastores",
1326 draft-ietf-netconf-yang-push-25 (work in progress), May
1327 2019.
1329 [I-D.ietf-opsawg-model-automation-framework]
1330 WU, Q., Boucadair, M., Lopez, D., Xie, C., and L. Geng, "A
1331 Framework for Automating Service and Network Management
1332 with YANG", draft-ietf-opsawg-model-automation-
1333 framework-10 (work in progress), October 2020.
1335 [RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K.,
1336 and A. Gonguet, "Framework for Layer 3 Virtual Private
1337 Networks (L3VPN) Operations and Management", RFC 4176,
1338 DOI 10.17487/RFC4176, October 2005,
1339 .
1341 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
1342 Previdi, "OSPF Traffic Engineering (TE) Metric
1343 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
1344 .
1346 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and
1347 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions",
1348 RFC 7810, DOI 10.17487/RFC7810, May 2016,
1349 .
1351 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki,
1352 "Extensions to the Path Computation Element Communication
1353 Protocol (PCEP) to Compute Service-Aware Label Switched
1354 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September
1355 2017, .
1357 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
1358 "YANG Data Model for L3VPN Service Delivery", RFC 8299,
1359 DOI 10.17487/RFC8299, January 2018,
1360 .
1362 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and
1363 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of
1364 IGP Traffic Engineering Performance Metric Extensions",
1365 RFC 8571, DOI 10.17487/RFC8571, March 2019,
1366 .
1368 Authors' Addresses
1370 Bo Wu
1371 Huawei
1372 101 Software Avenue, Yuhua District
1373 Nanjing, Jiangsu 210012
1374 China
1376 Email: lana.wubo@huawei.com
1378 Qin Wu
1379 Huawei
1380 101 Software Avenue, Yuhua District
1381 Nanjing, Jiangsu 210012
1382 China
1384 Email: bill.wu@huawei.com
1386 Mohamed Boucadair
1387 Orange
1388 Rennes 35000
1389 France
1391 Email: mohamed.boucadair@orange.com
1393 Oscar Gonzalez de Dios
1394 Telefonica
1395 Madrid
1396 ES
1398 Email: oscar.gonzalezdedios@telefonica.com
1400 Bin Wen
1401 Comcast
1403 Email: bin_wen@comcast.com
1404 Change Liu
1405 China Unicom
1407 Email: liuc131@chinaunicom.cn
1409 Honglei Xu
1410 China Telecom
1412 Email: xuhl.bri@chinatelecom.cn