idnits 2.17.1
draft-www-bess-yang-vpn-service-pm-03.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 24 instances of too long lines in the document, the longest
one being 33 characters in excess of 72.
** The abstract seems to contain references ([RFC8345]), which it
shouldn't. Please replace those with straight textual mentions of the
documents in question.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (July 5, 2019) is 1729 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'RFC8299' is mentioned on line 192, but not defined
== Missing Reference: 'Z' is mentioned on line 155, but not defined
== Missing Reference: 'RFC8194' is mentioned on line 227, but not defined
== Missing Reference: 'I-D.ietf-netconf-yang-push' is mentioned on line
236, but not defined
== Missing Reference: 'RFC8040' is mentioned on line 920, but not defined
== Missing Reference: 'RFC5246' is mentioned on line 924, but not defined
** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446)
== Unused Reference: 'RFC6370' is defined on line 995, but no explicit
reference was found in the text
== Unused Reference: 'RFC7950' is defined on line 1015, but no explicit
reference was found in the text
== Unused Reference: 'RFC7952' is defined on line 1019, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341)
** Downref: Normative reference to an Informational RFC: RFC 7923
Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 BESS Working Group M. Wang
3 Internet-Draft Q. Wu
4 Intended status: Standards Track R. Even
5 Expires: January 6, 2020 Huawei
6 B. Wen
7 Comcast
8 C. Liu
9 China Unicom
10 July 5, 2019
12 A YANG Model for Network and VPN Service Performance Monitoring
13 draft-www-bess-yang-vpn-service-pm-03
15 Abstract
17 The data model defined in [RFC8345] introduces vertical layering
18 relationships between networks that can be augmented to cover
19 network/service topologies. This document defines a YANG model for
20 Network and VPN Service Performance Monitoring that can be used to
21 monitor and manage network performance on the topology at different
22 layer or the overlay topology between VPN sites. This model is an
23 augmentation to the network topology YANG data model defined in
24 [RFC8345].
26 Status of This Memo
28 This Internet-Draft is submitted in full conformance with the
29 provisions of BCP 78 and BCP 79.
31 Internet-Drafts are working documents of the Internet Engineering
32 Task Force (IETF). Note that other groups may also distribute
33 working documents as Internet-Drafts. The list of current Internet-
34 Drafts is at https://datatracker.ietf.org/drafts/current/.
36 Internet-Drafts are draft documents valid for a maximum of six months
37 and may be updated, replaced, or obsoleted by other documents at any
38 time. It is inappropriate to use Internet-Drafts as reference
39 material or to cite them other than as "work in progress."
41 This Internet-Draft will expire on January 6, 2020.
43 Copyright Notice
45 Copyright (c) 2019 IETF Trust and the persons identified as the
46 document authors. All rights reserved.
48 This document is subject to BCP 78 and the IETF Trust's Legal
49 Provisions Relating to IETF Documents
50 (https://trustee.ietf.org/license-info) in effect on the date of
51 publication of this document. Please review these documents
52 carefully, as they describe your rights and restrictions with respect
53 to this document. Code Components extracted from this document must
54 include Simplified BSD License text as described in Section 4.e of
55 the Trust Legal Provisions and are provided without warranty as
56 described in the Simplified BSD License.
58 Table of Contents
60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
61 2. Conventions used in this document . . . . . . . . . . . . . . 3
62 2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3
63 3. Network and VPN service assurance model . . . . . . . . . . . 3
64 4. Layering relationship between underlay topology and overlay
65 topology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
66 5. Model Usage Guideline . . . . . . . . . . . . . . . . . . . . 5
67 5.1. Performance Monitoring Data Source . . . . . . . . . . . 5
68 5.2. Retrieval via I2RS Pub/Sub [RFC7923] . . . . . . . . . . 5
69 5.3. On demand Retrieval via RPC model . . . . . . . . . . . . 6
70 6. Design of the Data Model . . . . . . . . . . . . . . . . . . 6
71 6.1. Network Level . . . . . . . . . . . . . . . . . . . . . . 6
72 6.2. Node Level . . . . . . . . . . . . . . . . . . . . . . . 6
73 6.3. Link and Termination Point Level . . . . . . . . . . . . 7
74 7. Example of I2RS Pub/Sub Retrieval [RFC7923] . . . . . . . . . 9
75 8. Example of RPC model based Retrieval . . . . . . . . . . . . 10
76 9. Network and VPN Service Assurance YANG Module . . . . . . . . 12
77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
78 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
79 12. Normative References . . . . . . . . . . . . . . . . . . . . 22
80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
82 1. Introduction
84 [RFC8345] defines an abstract YANG data model for network/service
85 topologies and inventories. Service topology in [RFC8345] includes
86 the a virtual topology for a service layer above the L1, L2, and L3
87 layers. This virtual topology has the generic topology elements of
88 node, link, and terminating point. One typical example of a service
89 topology is described in figure 3 of [RFC8345], two VPN service
90 topologies instantiated over a common L3 topology. Each VPN service
91 topology is mapped onto a subset of nodes from the common L3
92 topology.
94 In [RFC8299], 3 types of VPN service topologies are defined for the
95 L3VPN service data model: any to any; hub and spoke; and hub and
96 spoke disjoint. These VPN topology types can be used to describe how
97 VPN sites communicate with each other.
99 This document defines a YANG Model for Network performance monitoring
100 and VPN Service Performance Monitoring that can be used to monitor
101 and manage network Performance on the topology at different layer or
102 the overlay topology between VPN sites and it is an augmentation to
103 the network topology YANG data model defined in [RFC8345].
105 2. Conventions used in this document
107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
109 document are to be interpreted as described in [RFC2119]. In this
110 document, these words will appear with that interpretation only when
111 in ALL CAPS. Lower case uses of these words are not to be
112 interpreted as carrying [RFC2119] significance.
114 2.1. Tree Diagrams
116 Tree diagrams used in this document follow the notation defined in
117 [RFC8340].
119 3. Network and VPN service assurance model
121 This module describes Network and VPN Service assurance that can be
122 used to monitor and manage the network Performance in the underlying
123 network or between VPN sites and it is a augmentation to the "ietf-
124 network" and "ietf-network-topology" YANG data model [RFC8345]. The
125 performance monitoring data is augmented to service topology.
127 +----------------------+ +-----------------------+
128 |ietf-network | |Network and VPN Service|
129 |ietf-network-topology |<---------|Peformance Monitoring |
130 +----------------------+ augments | Model |
131 +-----------------------+
133 4. Layering relationship between underlay topology and overlay topology
135 The data model defined in [RFC8345] can describe vertical layering
136 relationships between networks. That model can be augmented to cover
137 network/service topologies. Figure 1 describes an example on
138 layering relationship between L3 topology and the Optical topology:
140 +----:--------------:----:--------------+
141 / : : : "L3" /
142 / : : : /
143 / : : : /
144 / [Y1]_____________[Y2] /
145 / * * * /
146 / * * * /
147 +--------------*-------------*--*-------+
148 * * *
149 +--------*----------*----*--------------+
150 / [Z1]_______________[Z2] "Optical" /
151 / \_ * _/ /
152 / \_ * _/ /
153 / \_ * _/ /
154 / \ * / /
155 / [Z] /
156 +---------------------------------------+
158 Example of Layering relationship between the L3 Topology and the
159 Optical topology
161 The "L3" topology shows network elements at Layer 3 (IP), and the
162 "Optical" topology shows network elements at Layer 1. Network
163 elements in the "L3" topology are mapped onto network elements in the
164 "Optical" topology.
166 Figure 2 describes another example on relationships between the L3VPN
167 service topology and the underlying network:
169 VPN-SVC 1 VPN-SVC 2
170 / \
171 L3VPN-Service-topology 1 L3VPN-Service-topology-2
172 / | \ / | \
173 Site-1A Site-1B Site1-C Site-2A Site-2B Site-2C Top-Down
174 | | | | | | Service Topology
175 CE CE CE CE CE CE
176 | | | | | |
177 PE PE PE PE PE PE
178 ====|==========|=======|=======|=========|=====|======================
179 +-------+ | \ / / |
180 Bottom-up | | \ / / |
181 Network | | /\ / |
182 topology | | / \ | |
183 | | | | | |
184 node1 node2 node3 node4 node5 node6
186 Example of Layering relationships between L3VPN Service Topo and
187 Underlying network
189 As shown in Figure 2, Site-1A, Site-1B, and Site-1C are mapped to
190 nodes 1, 2, and 3, while Site-2A, Site-2B, and Site-2C are mapped to
191 nodes 4, 5, and 6 in the underlying physical network. In this
192 figure, a L3VPN Service Model (L3SM) [RFC8299] has two VPN services
193 topologies with both built on top of one common underlying physical
194 network.
196 VPN-SVC 1: supporting hub-spoke communication for Customer 1
197 connecting the customers access at 3 sites
199 VPN-SVC 2: supporting hub-spoke disjoint communication for
200 Customer 2 connecting the customers access at 3 sites
202 L3VPN service topology 1 is hub and spoke topology while L3VPN
203 service topology 2 is hub and spoke disjoint topology. In L3VPN
204 service topology 1, Site-1 A plays the role of hub while Site-2 B and
205 C plays the role of spoke. In L3VPN service topoogy 2, Site-2 A and
206 B play the role of hub while Site-2 C plays the role of spoke.
208 5. Model Usage Guideline
210 An SP must be able to manage the capabilities and characteristics of
211 their Network/VPN services when Network connection is established or
212 VPN sites are setup to communicate with each other. Network and VPN
213 service topology such as hub and spoke describes how these VPN sites
214 are communicating with each other.
216 5.1. Performance Monitoring Data Source
218 As described in section 2, once the mapping between overlay network
219 topology/VPN Service topology and underlying physical network has
220 been setup, the performance monitoring data per link in the
221 underlying network can be collected using network performance
222 measurement method such as MPLS Loss and Delay Measurement [RFC6374].
223 The performance monitoring information reflecting the quality of the
224 Network or VPN service such as end to end network performance data
225 between source node and destination node in the network or between
226 VPN sites can be aggregated or calculated using PCEP solution
227 [RFC5440] or LMAP solution [RFC8194]. The information can be fed
228 into data source such as the management system or network devices.
229 The measurement interval and report interval associated with these
230 performance data usually depends on configuration parameters.
232 5.2. Retrieval via I2RS Pub/Sub [RFC7923]
234 Some applications such as service-assurance applications, which must
235 maintain a continuous view of operational data and state, can use
236 subscription model [I-D.ietf-netconf-yang-push] to subscribe to the
237 Network and VPN service performance data they are interested in, at
238 the data source.
240 The data source can then use the Network and VPN service assurance
241 model defined in this document and push model [I-D.ietf-netconf-yang-
242 push] to publish specific telemetry data to target recipients.
244 5.3. On demand Retrieval via RPC model
246 To obtain a snapshot of a large amount of performance data from the
247 network element, service-assurance applications can also use polling
248 based solution such as RPC model to fetch performance data on demand.
250 6. Design of the Data Model
252 This document defines the YANG module "ietf-network-vpn-svc-pm",
253 which has the following structure
255 6.1. Network Level
257 module: ietf-network-vpn-svc-pm
258 augment /nw:networks/nw:network/nw:network-types:
259 +--rw svc-topo-type? identityref
260 augment /nw:networks/nw:network:
261 +--rw svc-topo-attributes
262 +--rw vpn-topo? identityref
264 Network Level View of the hierarchies
266 For VPN service performance monitoring, this model defines only the
267 following minimal set of Network level service topology attributes:
269 o svc-topo-type: Indicate the network type is service topology type
270 such as L3VPN service topology, L2VPN service topology.
272 o vpn-topo: The type of VPN service topology, this model supports
273 any-to-any, Hub and Spoke (where Hubs can exchange traffic), and
274 "Hub and Spoke disjoint" (where Hubs cannot exchange traffic).
276 For network performance monitoring, the attributes of "Network Level"
277 that defined in [RFC8345] do not need to be extended.
279 6.2. Node Level
280 augment /nw:networks/nw:network/nw:node:
281 +--rw node-attributes
282 +--rw node-type? identityref
283 +--rw site-id? string
284 +--rw site-role? Identityref
286 Node Level View of the hierarchies
288 The Network and VPN service performance monitoring model defines only
289 the following minimal set of Node level service topology attributes
290 and constraints:
292 o Node-type (Attribute): Indicate the type of the node, such as PE
293 or ASBR.
295 o Site-id (Constraint): Uniquely identifies the site within the
296 overall network infrastructure.
298 o Site-role (Constraint): Defines the role of the site in a
299 particular VPN topology.
301 6.3. Link and Termination Point Level
302 augment /nw:networks/nw:network/nt:link:
303 +--ro svc-telemetry-attributes
304 +--ro loss-statistics
305 | +--ro direction identityref
306 | +--ro packet-loss-count? uint32
307 | +--ro loss-ratio? percentage
308 | +--ro packet-reorder-count? uint32
309 | +--ro packets-out-of-seq-count? uint32
310 | +--ro packets-dup-count? uint32
311 +--ro delay-statistics
312 | +--ro direction? identityref
313 | +--ro min-delay-value? uint32
314 | +--ro max-delay-value? uint32
315 | +--ro average-delay-value? uint32
316 +--ro jitter-statistics
317 +--ro direction? identityref
318 +--ro min-jitter-value? uint32
319 +--ro max-jitter-value? uint32
320 +--ro average-jitter-value? uint32
321 augment /nw:networks/nw:network/nw:node/nt:termination-point:
322 +--ro tp-telemetry-attributes
323 +--ro in-octets? uint32
324 +--ro inbound-unicast? uint32
325 +--ro inbound-nunicast? uint32
326 +--ro inbound-discards? uint32
327 +--ro inbound-errors? uint32
328 +--ro inunknow-protos? uint32
329 +--ro out-octets? uint32
330 +--ro outbound-unicast? uint32
331 +--ro outbound-nunicast? uint32
332 +--ro outbound-discards? uint32
333 +--ro outbound-errors? uint32
334 +--ro outbound-qlen? uint32
336 Link and Termination point Level View of the hierarchies
338 The Network and VPN service performance monitoring model defines only
339 the following minimal set of Link level service topology attributes:
341 Loss Statistics: A set of loss statistics attributes that are used
342 to measure end to end loss between VPN sites.
344 Delay Statistics: A set of delay statistics attributes that are
345 used to measure end to end latency between VPN sites.
347 Jitter Statistics: A set of jitter statistics attributes that are
348 used to measure end to end jitter between VPN sites.
350 The Network and VPN service performance monitoring defines the
351 following minimal set of Termination point level service topology
352 attributes:
354 Inbound statistics: A set of inbound statistics attributes that
355 are used to measure the inbound statistics of the termination
356 point, such as "the total number of octets received on the
357 termination point", "The number of inbound packets which were
358 chosen to be discarded", "The number of inbound packets that
359 contained errors", etc.
361 Outbound statistics: A set of outbound statistics attributes that
362 are used to measure the outbound statistics of the termination
363 point, such as "the total number of octets transmitted out of the
364 termination point", "The number of outbound packets which were
365 chosen to be discarded", "The number of outbound packets that
366 contained errors", etc.
368 7. Example of I2RS Pub/Sub Retrieval [RFC7923]
370 This example shows the way for a client to subscribe for the
371 Performance monitoring information between node A and node B in the
372 L3 network topology built on top of the underlying optical network .
373 The performance monitoring parameter that the client is interested in
374 is end to end loss attribute.
376
378
380
381
382
383 l3-network
384
385 A
386
387 pe
388
389
390 1-0-1
391
392 100
393 150
394
395
396
397
398 B
399
400 pe
401
402
403 2-0-1
404
405 150
406 100
407
408
409
410
411 A-B
412
415
416 B
417
418
420
421 100
422
423
424
425
426
427
428 500
429
430
432 8. Example of RPC model based Retrieval
434 This example shows the way for the client to use RPC model to fetch
435 performance data on demand,e.g., the client requests packet-loss-
436 count between PE1 in site 1 and PE2 in site 2 belonging to VPN1.
438
440
441
442
443 vpn1
444
445 A
446
447 pe
448
449
450 1-0-1
451
452 100
453 150
454
455
456
457
458 B
459
460 pe
461
462
463 2-0-1
464
465 150
466 100
467
468
469
470 A-B
471
474
475 B
476
477
478
479 120
480
481
482
483
484
485
487 9. Network and VPN Service Assurance YANG Module
489 file "ietf-network-vpn-svc-pm.yang"
490 module ietf-network-vpn-svc-pm {
491 yang-version 1.1;
492 namespace "urn:ietf:params:xml:ns:yang:ietf-network-vpn-svc-pm";
493 prefix svc-topo;
495 import ietf-network {
496 prefix nw;
497 }
498 import ietf-network-topology {
499 prefix nt;
500 }
501 import ietf-l3vpn-svc {
502 prefix l3vpn-svc;
503 }
505 organization
506 "IETF xxx Working Group";
507 contact
508 "Zitao Wang: wangzitao@huawei.com
509 Qin Wu: bill.wu@huawei.com";
510 description
511 "This module defines a model for the VPN Service Performance monitoring.";
513 revision 2019-03-01 {
514 description
515 "Initial revision.";
516 reference
517 "foo";
518 }
520 identity service-type {
521 description
522 "Base type for service topology";
523 }
525 identity l3vpn-svc {
526 base service-type;
527 description
528 "Indentity for layer3 vpn service";
529 }
531 identity l2vpn-svc {
532 base service-type;
533 description
534 "Identity for layer2 vpn service";
536 }
538 identity node-type {
539 description
540 "Base identity for node type";
541 }
543 identity pe {
544 base node-type;
545 description
546 "Identity for PE type";
547 }
549 identity ce {
550 base node-type;
551 description
552 "Identity for CE type";
553 }
555 identity asbr {
556 base node-type;
557 description
558 "Identity for ASBR type";
559 }
561 identity p {
562 base node-type;
563 description
564 "Identity for P type";
565 }
567 identity direction {
568 description
569 "Base Identity for measurement direction including
570 one way measurement and two way measurement.";
571 }
573 identity oneway {
574 base direction;
575 description
576 "Identity for one way measurement.";
577 }
579 identity twoway {
580 base direction;
581 description
582 "Identity for two way measurement.";
583 }
584 typedef percentage {
585 type decimal64 {
586 fraction-digits 5;
587 range "0..100";
588 }
589 description
590 "Percentage.";
591 }
593 grouping link-error-statistics {
594 description
595 "Grouping for per link error statistics";
596 container loss-statistics {
597 description
598 "Per link loss statistics.";
599 leaf direction {
600 type identityref {
601 base direction;
602 }
603 default "oneway";
604 description
605 "Define measurement direction including one way
606 measurement and two way measurement.";
607 }
608 leaf packet-loss-count {
609 type uint32 {
610 range "0..4294967295";
611 }
612 default "0";
613 description
614 "Total received packet drops count.
615 The value of count will be set to zero (0)
616 on creation and will thereafter increase
617 monotonically until it reaches a maximum value
618 of 2^32-1 (4294967295 decimal), when it wraps
619 around and starts increasing again from zero.";
620 }
621 leaf loss-ratio {
622 type percentage;
623 description
624 "Loss ratio of the packets. Express as percentage
625 of packets lost with respect to packets sent.";
626 }
627 leaf packet-reorder-count {
628 type uint32 {
629 range "0..4294967295";
630 }
631 default "0";
632 description
633 "Total received packet reordered count.
634 The value of count will be set to zero (0)
635 on creation and will thereafter increase
636 monotonically until it reaches a maximum value
637 of 2^32-1 (4294967295 decimal), when it wraps
638 around and starts increasing again from zero.";
639 }
640 leaf packets-out-of-seq-count {
641 type uint32 {
642 range "0..4294967295";
643 }
644 description
645 "Total received out of sequence count.
646 The value of count will be set to zero (0)
647 on creation and will thereafter increase
648 monotonically until it reaches a maximum value
649 of 2^32-1 (4294967295 decimal), when it wraps
650 around and starts increasing again from zero..";
651 }
652 leaf packets-dup-count {
653 type uint32 {
654 range "0..4294967295";
655 }
656 description
657 "Total received packet duplicates count.
658 The value of count will be set to zero (0)
659 on creation and will thereafter increase
660 monotonically until it reaches a maximum value
661 of 2^32-1 (4294967295 decimal), when it wraps
662 around and starts increasing again from zero.";
663 }
664 }
665 }
667 grouping link-delay-statistics {
668 description
669 "Grouping for per link delay statistics";
670 container delay-statistics {
671 description
672 "Link delay summarised information. By default,
673 one way measurement protocol (e.g., OWAMP) is used
674 to measure delay.";
675 leaf direction {
676 type identityref {
677 base direction;
678 }
679 default "oneway";
680 description
681 "Define measurement direction including one way
682 measurement and two way measurement.";
683 }
684 leaf min-delay-value {
685 type uint32;
686 description
687 "Minimum delay value observed.";
688 }
689 leaf max-delay-value {
690 type uint32;
691 description
692 "Maximum delay value observed.";
693 }
694 leaf average-delay-value {
695 type uint32;
696 description
697 "Average delay is calculated on all the packets of a sample
698 and is a simple computation to be performed for single marking method.";
699 }
700 }
701 }
703 grouping link-jitter-statistics {
704 description
705 "Grouping for per link jitter statistics";
706 container jitter-statistics {
707 description
708 "Link jitter summarised information. By default,
709 jitter is measured using IP Packet Delay Variation
710 (IPDV) as defined in RFC3393.";
711 leaf direction {
712 type identityref {
713 base direction;
714 }
715 default "oneway";
716 description
717 "Define measurement direction including one way
718 measurement and two way measurement.";
719 }
720 leaf min-jitter-value {
721 type uint32;
722 description
723 "Minimum jitter value observed.";
724 }
725 leaf max-jitter-value {
726 type uint32;
727 description
728 "Maximum jitter value observed.";
729 }
730 leaf average-jitter-value {
731 type uint32;
732 description
733 "Average jitter is calculated on all the packets of a sample
734 and is a simple computation to be performed for single marking method.";
735 }
736 }
737 }
739 grouping tp-svc-telemetry {
741 leaf in-octets {
742 type uint32;
743 description
744 "The total number of octets received on the
745 interface, including framing characters.";
746 }
747 leaf inbound-unicast {
748 type uint32;
749 description
750 "Inbound unicast packets were received, and delivered
751 to a higher layer during the last period.";
752 }
753 leaf inbound-nunicast {
754 type uint32;
755 description
756 "The number of non-unicast (i.e., subnetwork-
757 broadcast or subnetwork-multicast) packets
758 delivered to a higher-layer protocol.";
759 }
760 leaf inbound-discards {
761 type uint32;
762 description
763 "The number of inbound packets which were chosen
764 to be discarded even though no errors had been
765 detected to prevent their being deliverable to a
766 higher-layer protocol.";
767 }
768 leaf inbound-errors {
769 type uint32;
770 description
771 "The number of inbound packets that contained
772 errors preventing them from being deliverable to a
773 higher-layer protocol.";
774 }
775 leaf inunknow-protos {
776 type uint32;
777 description
778 "The number of packets received via the interface
779 which were discarded because of an unknown or
780 unsupported protocol";
781 }
782 leaf out-octets {
783 type uint32;
784 description
785 "The total number of octets transmitted out of the
786 interface, including framing characters";
787 }
788 leaf outbound-unicast {
789 type uint32;
790 description
791 "The total number of packets that higher-level
792 protocols requested be transmitted to a
793 subnetwork-unicast address, including those that
794 were discarded or not sent.";
795 }
796 leaf outbound-nunicast {
797 type uint32;
798 description
799 "The total number of packets that higher-level
800 protocols requested be transmitted to a non-
801 unicast (i.e., a subnetwork-broadcast or
802 subnetwork-multicast) address, including those
803 that were discarded or not sent.";
804 }
805 leaf outbound-discards {
806 type uint32;
807 description
808 "The number of outbound packets which were chosen
809 to be discarded even though no errors had been
810 detected to prevent their being transmitted. One
811 possible reason for discarding such a packet could
812 be to free up buffer space.";
813 }
814 leaf outbound-errors {
815 type uint32;
816 description
817 "The number of outbound packets that contained
818 errors preventing them from being deliverable to a
819 higher-layer protocol.";
820 }
821 leaf outbound-qlen {
822 type uint32;
823 description
824 " Length of the queue of the interface from where
825 the packet is forwarded out. The queue depth could
826 be the current number of memory buffers used by the
827 queue and a packet can consume one or more memory buffers
828 thus constituting device-level information.";
829 }
830 description
831 "Grouping for interface service telemetry";
832 }
834 augment "/nw:networks/nw:network/nw:network-types" {
835 description
836 "Augment the network-types with service topologyies types";
837 leaf svc-topo-type {
838 type identityref {
839 base service-type;
840 }
841 description
842 "Identify the topology type to be composited service topology";
843 }
844 }
845 augment "/nw:networks/nw:network" {
846 description
847 "Augment the network with service topology attributes";
848 container svc-topo-attributes {
849 leaf vpn-topology {
850 type identityref {
851 base l3vpn-svc:vpn-topology;
852 }
853 description
854 "VPN service topology, e.g. hub-spoke, any-to-any, hub-spoke-disjoint, etc";
855 }
856 description
857 "Container for vpn services";
858 }
859 }
860 augment "/nw:networks/nw:network/nw:node" {
861 description
862 "Augment the network node with serice attributes";
863 container node-attributes {
864 leaf node-type {
865 type identityref {
866 base node-type;
867 }
868 description
869 "Node type, e.g. PE, P, ASBR, etc";
870 }
871 leaf site-id {
872 type string;
873 description
874 "Asscoiated vpn site";
875 }
876 leaf site-role {
877 type identityref {
878 base l3vpn-svc:site-role;
879 }
880 default "l3vpn-svc:any-to-any-role";
881 description
882 "Role of the site in the IP VPN.";
883 }
884 description
885 "Container for service topology attributes";
886 }
887 }
888 augment "/nw:networks/nw:network/nt:link" {
889 description
890 "Augment the network topology link with vpn service attributes";
891 container svc-telemetry-attributes {
892 config false;
893 uses link-error-statistics;
894 uses link-delay-statistics;
895 uses link-jitter-statistics;
896 description
897 "Container for service telemetry attributes";
898 }
899 }
900 augment "/nw:networks/nw:network/nw:node/nt:termination-point" {
901 description
902 "Augment the network topology termination point with vpn service attributes";
903 container tp-telemetry-attributes {
904 config false;
905 uses tp-svc-telemetry;
906 description
907 "Container for termination point service telemetry attributes.";
908 }
909 }
910 }
912
914 10. Security Considerations
916 The YANG modules defined in this document MAY be accessed via the
917 RESTCONF protocol [RFC8040] or NETCONF protocol ([RFC6241]). The
918 lowest RESTCONF or NETCONF layer requires that the transport-layer
919 protocol provides both data integrity and confidentiality, see
920 Section 2 in [RFC8040] and [RFC6241]. The lowest NETCONF layer is
921 the secure transport layer, and the mandatory-to-implement secure
922 transport is Secure Shell (SSH)[RFC6242] . The lowest RESTCONF layer
923 is HTTPS, and the mandatory-to-implement secure transport is TLS
924 [RFC5246].
926 The NETCONF access control model [RFC6536] provides the means to
927 restrict access for particular NETCONF or RESTCONF users to a
928 preconfigured subset of all available NETCONF or RESTCONF protocol
929 operations and content.
931 There are a number of data nodes defined in this YANG module that are
932 writable/creatable/deletable (i.e., config true, which is the
933 default). These data nodes may be considered sensitive or vulnerable
934 in some network environments. Write operations (e.g., edit-config)
935 to these data nodes without proper protection can have a negative
936 effect on network operations. These are the subtrees and data nodes
937 and their sensitivity/vulnerability:
939 o /nw:networks/nw:network/svc-topo:svc-telemetry-attributes
941 o /nw:networks/nw:network/nw:node/svc-topo:node-attributes
943 11. IANA Considerations
945 This document registers a URI in the IETF XML registry [RFC3688].
946 Following the format in [RFC3688], the following registration is
947 requested to be made:
949 ---------------------------------------------------------------------
950 URI: urn:ietf:params:xml:ns:yang:ietf-network-vpn-svc-pm
952 Registrant Contact: The IESG.
954 XML: N/A, the requested URI is an XML namespace.
955 ---------------------------------------------------------------------
957 This document registers a YANG module in the YANG Module Names
958 registry [RFC6020].
960 ---------------------------------------------------------------------
961 Name: ietf-vpn-svc-pm
962 Namespace: urn:ietf:params:xml:ns:yang:ietf-network-vpn-svc-pm
963 Prefix: vnrsc
964 Reference: RFC xxxx
965 ---------------------------------------------------------------------
967 12. Normative References
969 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
970 Requirement Levels", March 1997.
972 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
973 DOI 10.17487/RFC3688, January 2004,
974 .
976 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
977 Element (PCE) Communication Protocol (PCEP)", RFC 5440,
978 DOI 10.17487/RFC5440, March 2009,
979 .
981 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
982 the Network Configuration Protocol (NETCONF)", RFC 6020,
983 DOI 10.17487/RFC6020, October 2010,
984 .
986 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
987 and A. Bierman, Ed., "Network Configuration Protocol
988 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
989 .
991 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
992 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
993 .
995 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
996 Profile (MPLS-TP) Identifiers", RFC 6370,
997 DOI 10.17487/RFC6370, September 2011,
998 .
1000 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
1001 Measurement for MPLS Networks", RFC 6374,
1002 DOI 10.17487/RFC6374, September 2011,
1003 .
1005 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
1006 Protocol (NETCONF) Access Control Model", RFC 6536,
1007 DOI 10.17487/RFC6536, March 2012,
1008 .
1010 [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements
1011 for Subscription to YANG Datastores", RFC 7923,
1012 DOI 10.17487/RFC7923, June 2016,
1013 .
1015 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
1016 RFC 7950, DOI 10.17487/RFC7950, August 2016,
1017 .
1019 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG",
1020 RFC 7952, DOI 10.17487/RFC7952, August 2016,
1021 .
1023 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
1024 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
1025 .
1027 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
1028 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
1029 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
1030 2018, .
1032 Authors' Addresses
1034 Michael Wang
1035 Huawei Technologies,Co.,Ltd
1036 101 Software Avenue, Yuhua District
1037 Nanjing 210012
1038 China
1040 Email: wangzitao@huawei.com
1042 Qin Wu
1043 Huawei
1044 101 Software Avenue, Yuhua District
1045 Nanjing, Jiangsu 210012
1046 China
1048 Email: bill.wu@huawei.com
1050 Roni Even
1051 Huawei Technologies,Co.,Ltd
1052 Tel Aviv
1053 Israel
1055 Email: roni.even@huawei.com
1056 Bin Wen
1057 Comcast
1059 Email: bin_wen@comcast.com
1061 Change Liu
1062 China Unicom
1064 Email: liuc131@chinaunicom.cn