idnits 2.17.1
draft-www-bess-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 16 instances of too long lines in the document, the longest
one being 24 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 (March 8, 2019) is 1848 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 893, but not defined
== Missing Reference: 'RFC5246' is mentioned on line 897, but not defined
** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446)
== Unused Reference: 'RFC6370' is defined on line 968, but no explicit
reference was found in the text
== Unused Reference: 'RFC7950' is defined on line 988, but no explicit
reference was found in the text
== Unused Reference: 'RFC7952' is defined on line 992, 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: September 9, 2019 Huawei
6 B. Wen
7 Comcast
8 C. Liu
9 China Unicom
10 March 8, 2019
12 A YANG Model for Network and VPN Service Performance Monitoring
13 draft-www-bess-yang-vpn-service-pm-02
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 September 9, 2019.
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 . . . . . . . . . . . . 11
76 9. Network and VPN Service Assurance YANG Module . . . . . . . . 11
77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
78 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
79 12. Normative References . . . . . . . . . . . . . . . . . . . . 21
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 The Network and VPN service performance monitoring model defines only
267 the following minimal set of Network level service topology
268 attributes:
270 o svc-topo-type: Indicate the network type is service topology type
271 such as L3VPN service topology, L2VPN service topology.
273 o vpn-topo: The type of VPN service topology, this model supports
274 any-to-any, Hub and Spoke (where Hubs can exchange traffic), and
275 "Hub and Spoke disjoint" (where Hubs cannot exchange traffic).
277 6.2. Node Level
278 augment /nw:networks/nw:network/nw:node:
279 +--rw node-attributes
280 +--rw node-type? identityref
281 +--rw site-id? string
282 +--rw site-role? Identityref
284 Node Level View of the hierarchies
286 The Network and VPN service performance monitoring model defines only
287 the following minimal set of Node level service topology attributes
288 and constraints:
290 o Node-type (Attribute): Indicate the type of the node, such as PE
291 or ASBR.
293 o Site-id (Constraint): Uniquely identifies the site within the
294 overall network infrastructure.
296 o Site-role (Constraint): Defines the role of the site in a
297 particular VPN topology.
299 6.3. Link and Termination Point Level
300 augment /nw:networks/nw:network/nt:link:
301 +--ro svc-telemetry-attributes
302 +--ro loss-statistics
303 | +--ro direction identityref
304 | +--ro packet-loss-count? uint32
305 | +--ro loss-ratio? percentage
306 | +--ro packet-reorder-count? uint32
307 | +--ro packets-out-of-seq-count? uint32
308 | +--ro packets-dup-count? uint32
309 +--ro delay-statistics
310 | +--ro direction? identityref
311 | +--ro min-delay-value? uint32
312 | +--ro max-delay-value? uint32
313 | +--ro average-delay-value? uint32
314 +--ro jitter-statistics
315 +--ro direction? identityref
316 +--ro min-jitter-value? uint32
317 +--ro max-jitter-value? uint32
318 +--ro average-jitter-value? uint32
319 augment /nw:networks/nw:network/nw:node/nt:termination-point:
320 +--ro tp-telemetry-attributes
321 +--ro in-octets? uint32
322 +--ro inbound-unicast? uint32
323 +--ro inbound-nunicast? uint32
324 +--ro inbound-discards? uint32
325 +--ro inbound-errors? uint32
326 +--ro inunknow-protos? uint32
327 +--ro out-octets? uint32
328 +--ro outbound-unicast? uint32
329 +--ro outbound-nunicast? uint32
330 +--ro outbound-discards? uint32
331 +--ro outbound-errors? uint32
332 +--ro outbound-qlen? uint32
334 Link and Termination point Level View of the hierarchies
336 The Network and VPN service performance monitoring model defines only
337 the following minimal set of Link level service topology attributes:
339 Loss Statistics: A set of loss statistics attributes that are used
340 to measure end to end loss between VPN sites.
342 Delay Statistics: A set of delay statistics attributes that are
343 used to measure end to end latency between VPN sites.
345 Jitter Statistics: A set of jitter statistics attributes that are
346 used to measure end to end jitter between VPN sites.
348 The Network and VPN service performance monitoring defines the
349 following minimal set of Termination point level service topology
350 attributes:
352 Inbound statistics: A set of inbound statistics attributes that
353 are used to measure the inbound statistics of the termination
354 point, such as "the total number of octets received on the
355 termination point", "The number of inbound packets which were
356 chosen to be discarded", "The number of inbound packets that
357 contained errors", etc.
359 Outbound statistics: A set of outbound statistics attributes that
360 are used to measure the outbound statistics of the termination
361 point, such as "the total number of octets transmitted out of the
362 termination point", "The number of outbound packets which were
363 chosen to be discarded", "The number of outbound packets that
364 contained errors", etc.
366 7. Example of I2RS Pub/Sub Retrieval [RFC7923]
368 This example shows the way for a client to subscribe for the
369 Performance monitoring information between node A and node B in the
370 L3 network topology built on top of the underlying optical network .
371 The performance monitoring parameter that the client is interested in
372 is end to end loss attribute.
374
376
378
379
380
381 l3-network
382
383 A
384
385 pe
386
387
388
389 B
390
391 pe
392
393
394
395 A-B
396
399
400 B
401
402
404
405 100
406
407
408
409
410
411
412 500
413
414
416 8. Example of RPC model based Retrieval
418 This example shows the way for the client to use RPC model to fetch
419 performance data on demand,e.g., the client requests packet-loss-
420 count between PE1 in site 1 and PE2 in site 2 belonging to VPN1.
422
424
425
426
427 vpn1
428
429 A
430
431 pe
432
433
434
435 B
436
437 pe
438
439
440 A-B
441
444
445 B
446
447
448
449 120
450
451
452
453
454
455
457 9. Network and VPN Service Assurance YANG Module
459 file "ietf-network-vpn-svc-pm.yang"
460 module ietf-network-vpn-svc-pm {
461 yang-version 1.1;
462 namespace "urn:ietf:params:xml:ns:yang:ietf-network-vpn-svc-pm";
463 prefix svc-topo;
464 import ietf-network {
465 prefix nw;
466 }
467 import ietf-network-topology {
468 prefix nt;
469 }
470 import ietf-l3vpn-svc {
471 prefix l3vpn-svc;
472 }
474 organization
475 "IETF xxx Working Group";
476 contact
477 "Zitao Wang: wangzitao@huawei.com
478 Qin Wu: bill.wu@huawei.com";
479 description
480 "This module defines a model for the VPN Service Performance monitoring.";
482 revision 2019-03-01 {
483 description
484 "Initial revision.";
485 reference
486 "foo";
487 }
489 identity service-type {
490 description
491 "Base type for service topology";
492 }
494 identity l3vpn-svc {
495 base service-type;
496 description
497 "Indentity for layer3 vpn service";
498 }
500 identity l2vpn-svc {
501 base service-type;
502 description
503 "Identity for layer2 vpn service";
504 }
506 identity node-type {
507 description
508 "Base identity for node type";
509 }
511 identity pe {
512 base node-type;
513 description
514 "Identity for PE type";
515 }
517 identity ce {
518 base node-type;
519 description
520 "Identity for CE type";
521 }
523 identity asbr {
524 base node-type;
525 description
526 "Identity for ASBR type";
527 }
529 identity p {
530 base node-type;
531 description
532 "Identity for P type";
533 }
535 identity direction {
536 description
537 "Base Identity for measurement direction including
538 one way measurement and two way measurement.";
539 }
541 identity oneway {
542 base direction;
543 description
544 "Identity for one way measurement.";
545 }
547 identity twoway {
548 base direction;
549 description
550 "Identity for two way measurement.";
551 }
553 typedef percentage {
554 type decimal64 {
555 fraction-digits 5;
556 range "0..100";
557 }
558 description
559 "Percentage.";
561 }
563 grouping link-error-statistics {
564 description
565 "Grouping for per link error statistics";
566 container loss-statistics {
567 description
568 "Per link loss statistics.";
569 leaf direction {
570 type identityref {
571 base direction;
572 }
573 default "oneway";
574 description
575 "Define measurement direction including one way
576 measurement and two way measurement.";
577 }
578 leaf packet-loss-count {
579 type uint32 {
580 range "0..4294967295";
581 }
582 default "0";
583 description
584 "Total received packet drops count.
585 The value of count will be set to zero (0)
586 on creation and will thereafter increase
587 monotonically until it reaches a maximum value
588 of 2^32-1 (4294967295 decimal), when it wraps
589 around and starts increasing again from zero.";
590 }
591 leaf loss-ratio {
592 type percentage;
593 description
594 "Loss ratio of the packets. Express as percentage
595 of packets lost with respect to packets sent.";
596 }
597 leaf packet-reorder-count {
598 type uint32 {
599 range "0..4294967295";
600 }
601 default "0";
602 description
603 "Total received packet reordered count.
604 The value of count will be set to zero (0)
605 on creation and will thereafter increase
606 monotonically until it reaches a maximum value
607 of 2^32-1 (4294967295 decimal), when it wraps
608 around and starts increasing again from zero.";
610 }
611 leaf packets-out-of-seq-count {
612 type uint32 {
613 range "0..4294967295";
614 }
615 description
616 "Total received out of sequence count.
617 The value of count will be set to zero (0)
618 on creation and will thereafter increase
619 monotonically until it reaches a maximum value
620 of 2^32-1 (4294967295 decimal), when it wraps
621 around and starts increasing again from zero..";
622 }
623 leaf packets-dup-count {
624 type uint32 {
625 range "0..4294967295";
626 }
627 description
628 "Total received packet duplicates count.
629 The value of count will be set to zero (0)
630 on creation and will thereafter increase
631 monotonically until it reaches a maximum value
632 of 2^32-1 (4294967295 decimal), when it wraps
633 around and starts increasing again from zero.";
634 }
635 }
636 }
638 grouping link-delay-statistics {
639 description
640 "Grouping for per link delay statistics";
641 container delay-statistics {
642 description
643 "Link delay summarised information. By default,
644 one way measurement protocol (e.g., OWAMP) is used
645 to measure delay.";
646 leaf direction {
647 type identityref {
648 base direction;
649 }
650 default "oneway";
651 description
652 "Define measurement direction including one way
653 measurement and two way measurement.";
654 }
655 leaf min-delay-value {
656 type uint32;
657 description
658 "Minimum delay value observed.";
659 }
660 leaf max-delay-value {
661 type uint32;
662 description
663 "Maximum delay value observed.";
664 }
665 leaf average-delay-value {
666 type uint32;
667 description
668 "Average delay is calculated on all the packets of a sample
669 and is a simple computation to be performed for single marking method.";
670 }
671 }
672 }
674 grouping link-jitter-statistics {
675 description
676 "Grouping for per link jitter statistics";
677 container jitter-statistics {
678 description
679 "Link jitter summarised information. By default,
680 jitter is measured using IP Packet Delay Variation
681 (IPDV) as defined in RFC3393.";
682 leaf direction {
683 type identityref {
684 base direction;
685 }
686 default "oneway";
687 description
688 "Define measurement direction including one way
689 measurement and two way measurement.";
690 }
691 leaf min-jitter-value {
692 type uint32;
693 description
694 "Minimum jitter value observed.";
695 }
696 leaf max-jitter-value {
697 type uint32;
698 description
699 "Maximum jitter value observed.";
700 }
701 leaf average-jitter-value {
702 type uint32;
703 description
704 "Average jitter is calculated on all the packets of a sample
705 and is a simple computation to be performed for single marking method.";
707 }
708 }
709 }
711 grouping tp-svc-telemetry {
713 leaf in-octets {
714 type uint32;
715 description
716 "The total number of octets received on the
717 interface, including framing characters.";
718 }
719 leaf inbound-unicast {
720 type uint32;
721 description
722 "Inbound unicast packets were received, and delivered
723 to a higher layer during the last period.";
724 }
725 leaf inbound-nunicast {
726 type uint32;
727 description
728 "The number of non-unicast (i.e., subnetwork-
729 broadcast or subnetwork-multicast) packets
730 delivered to a higher-layer protocol.";
731 }
732 leaf inbound-discards {
733 type uint32;
734 description
735 "The number of inbound packets which were chosen
736 to be discarded even though no errors had been
737 detected to prevent their being deliverable to a
738 higher-layer protocol.";
739 }
740 leaf inbound-errors {
741 type uint32;
742 description
743 "The number of inbound packets that contained
744 errors preventing them from being deliverable to a
745 higher-layer protocol.";
746 }
747 leaf inunknow-protos {
748 type uint32;
749 description
750 "The number of packets received via the interface
751 which were discarded because of an unknown or
752 unsupported protocol";
753 }
754 leaf out-octets {
755 type uint32;
756 description
757 "The total number of octets transmitted out of the
758 interface, including framing characters";
759 }
760 leaf outbound-unicast {
761 type uint32;
762 description
763 "The total number of packets that higher-level
764 protocols requested be transmitted to a
765 subnetwork-unicast address, including those that
766 were discarded or not sent.";
767 }
768 leaf outbound-nunicast {
769 type uint32;
770 description
771 "The total number of packets that higher-level
772 protocols requested be transmitted to a non-
773 unicast (i.e., a subnetwork-broadcast or
774 subnetwork-multicast) address, including those
775 that were discarded or not sent.";
776 }
777 leaf outbound-discards {
778 type uint32;
779 description
780 "The number of outbound packets which were chosen
781 to be discarded even though no errors had been
782 detected to prevent their being transmitted. One
783 possible reason for discarding such a packet could
784 be to free up buffer space.";
785 }
786 leaf outbound-errors {
787 type uint32;
788 description
789 "The number of outbound packets that contained
790 errors preventing them from being deliverable to a
791 higher-layer protocol.";
792 }
793 leaf outbound-qlen {
794 type uint32;
795 description
796 " Length of the queue of the interface from where
797 the packet is forwarded out. The queue depth could
798 be the current number of memory buffers used by the
799 queue and a packet can consume one or more memory buffers
800 thus constituting device-level information.";
801 }
802 description
803 "Grouping for interface service telemetry";
804 }
806 augment "/nw:networks/nw:network/nw:network-types" {
807 description
808 "Augment the network-types with service topologyies types";
809 leaf svc-topo-type {
810 type identityref {
811 base service-type;
812 }
813 description
814 "Identify the topology type to be composited service topology";
815 }
816 }
817 augment "/nw:networks/nw:network" {
818 description
819 "Augment the network with service topology attributes";
820 container svc-topo-attributes {
821 leaf vpn-topology {
822 type identityref {
823 base l3vpn-svc:vpn-topology;
824 }
825 description
826 "VPN service topology, e.g. hub-spoke, any-to-any, hub-spoke-disjoint, etc";
827 }
828 description
829 "Container for vpn services";
830 }
831 }
832 augment "/nw:networks/nw:network/nw:node" {
833 description
834 "Augment the network node with serice attributes";
835 container node-attributes {
836 leaf node-type {
837 type identityref {
838 base node-type;
839 }
840 description
841 "Node type, e.g. PE, P, ASBR, etc";
842 }
843 leaf site-id {
844 type string;
845 description
846 "Asscoiated vpn site";
847 }
848 leaf site-role {
849 type identityref {
850 base l3vpn-svc:site-role;
852 }
853 default "l3vpn-svc:any-to-any-role";
854 description
855 "Role of the site in the IP VPN.";
856 }
857 description
858 "Container for service topology attributes";
859 }
860 }
861 augment "/nw:networks/nw:network/nt:link" {
862 description
863 "Augment the network topology link with vpn service attributes";
864 container svc-telemetry-attributes {
865 config false;
866 uses link-error-statistics;
867 uses link-delay-statistics;
868 uses link-jitter-statistics;
869 description
870 "Container for service telemetry attributes";
871 }
872 }
873 augment "/nw:networks/nw:network/nw:node/nt:termination-point" {
874 description
875 "Augment the network topology termination point with vpn service attributes";
876 container tp-telemetry-attributes {
877 config false;
878 uses tp-svc-telemetry;
879 description
880 "Container for termination point service telemetry attributes.";
881 }
882 }
883 }
885
887 10. Security Considerations
889 The YANG modules defined in this document MAY be accessed via the
890 RESTCONF protocol [RFC8040] or NETCONF protocol ([RFC6241]). The
891 lowest RESTCONF or NETCONF layer requires that the transport-layer
892 protocol provides both data integrity and confidentiality, see
893 Section 2 in [RFC8040] and [RFC6241]. The lowest NETCONF layer is
894 the secure transport layer, and the mandatory-to-implement secure
895 transport is Secure Shell (SSH)[RFC6242] . The lowest RESTCONF layer
896 is HTTPS, and the mandatory-to-implement secure transport is TLS
897 [RFC5246].
899 The NETCONF access control model [RFC6536] provides the means to
900 restrict access for particular NETCONF or RESTCONF users to a
901 preconfigured subset of all available NETCONF or RESTCONF protocol
902 operations and content.
904 There are a number of data nodes defined in this YANG module that are
905 writable/creatable/deletable (i.e., config true, which is the
906 default). These data nodes may be considered sensitive or vulnerable
907 in some network environments. Write operations (e.g., edit-config)
908 to these data nodes without proper protection can have a negative
909 effect on network operations. These are the subtrees and data nodes
910 and their sensitivity/vulnerability:
912 o /nw:networks/nw:network/svc-topo:svc-telemetry-attributes
914 o /nw:networks/nw:network/nw:node/svc-topo:node-attributes
916 11. IANA Considerations
918 This document registers a URI in the IETF XML registry [RFC3688].
919 Following the format in [RFC3688], the following registration is
920 requested to be made:
922 ---------------------------------------------------------------------
923 URI: urn:ietf:params:xml:ns:yang:ietf-network-vpn-svc-pm
925 Registrant Contact: The IESG.
927 XML: N/A, the requested URI is an XML namespace.
928 ---------------------------------------------------------------------
930 This document registers a YANG module in the YANG Module Names
931 registry [RFC6020].
933 ---------------------------------------------------------------------
934 Name: ietf-vpn-svc-pm
935 Namespace: urn:ietf:params:xml:ns:yang:ietf-network-vpn-svc-pm
936 Prefix: vnrsc
937 Reference: RFC xxxx
938 ---------------------------------------------------------------------
940 12. Normative References
942 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
943 Requirement Levels", March 1997.
945 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
946 DOI 10.17487/RFC3688, January 2004,
947 .
949 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
950 Element (PCE) Communication Protocol (PCEP)", RFC 5440,
951 DOI 10.17487/RFC5440, March 2009,
952 .
954 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
955 the Network Configuration Protocol (NETCONF)", RFC 6020,
956 DOI 10.17487/RFC6020, October 2010,
957 .
959 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
960 and A. Bierman, Ed., "Network Configuration Protocol
961 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
962 .
964 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
965 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
966 .
968 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
969 Profile (MPLS-TP) Identifiers", RFC 6370,
970 DOI 10.17487/RFC6370, September 2011,
971 .
973 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
974 Measurement for MPLS Networks", RFC 6374,
975 DOI 10.17487/RFC6374, September 2011,
976 .
978 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
979 Protocol (NETCONF) Access Control Model", RFC 6536,
980 DOI 10.17487/RFC6536, March 2012,
981 .
983 [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements
984 for Subscription to YANG Datastores", RFC 7923,
985 DOI 10.17487/RFC7923, June 2016,
986 .
988 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
989 RFC 7950, DOI 10.17487/RFC7950, August 2016,
990 .
992 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG",
993 RFC 7952, DOI 10.17487/RFC7952, August 2016,
994 .
996 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
997 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
998 .
1000 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
1001 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
1002 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
1003 2018, .
1005 Authors' Addresses
1007 Michael Wang
1008 Huawei Technologies,Co.,Ltd
1009 101 Software Avenue, Yuhua District
1010 Nanjing 210012
1011 China
1013 Email: wangzitao@huawei.com
1015 Qin Wu
1016 Huawei
1017 101 Software Avenue, Yuhua District
1018 Nanjing, Jiangsu 210012
1019 China
1021 Email: bill.wu@huawei.com
1023 Roni Even
1024 Huawei Technologies,Co.,Ltd
1025 Tel Aviv
1026 Israel
1028 Email: roni.even@huawei.com
1030 Bin Wen
1031 Comcast
1033 Email: bin_wen@comcast.com
1034 Change Liu
1035 China Unicom
1037 Email: liuc131@chinaunicom.cn