-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-ietf-netmod-intf-ext-yang-12.xml
1476 lines (1374 loc) · 65 KB
/
draft-ietf-netmod-intf-ext-yang-12.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true" docName="draft-ietf-netmod-intf-ext-yang-12" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.15.0 -->
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Interface Extensions YANG">Common Interface Extension YANG Data Models</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-netmod-intf-ext-yang-12"/>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Robert Wilton" initials="R.G." surname="Wilton">
<organization>Cisco Systems</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<author fullname="Scott Mansfield" initials="S" surname="Mansfield">
<organization>Ericsson</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<date year="2023"/>
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>template</keyword>
<abstract>
<t>This document defines two YANG modules that augment the Interfaces
data model defined in the "YANG Data Model for Interface Management"
with additional configuration and operational data nodes to support
common lower layer interface properties, such as interface MTU.</t>
<t>The YANG modules in this document conform to the Network Management
Datastore Architecture (NMDA) defined in RFC 8342.</t>
</abstract>
</front>
<middle>
<section numbered="true" toc="default">
<name>Introduction</name>
<t>This document defines two <xref target="RFC8342" format="default">NMDA
compatible</xref> <xref target="RFC7950" format="default">YANG 1.1</xref> modules for the
management of network interfaces. It defines various augmentations to
the <xref target="RFC8343" format="default">generic interfaces data model</xref> to
support configuration of lower layer interface properties that are
common across many types of network interface.</t>
<t>One of the aims of this document is to provide a standard definition
for these configuration items regardless of the underlying interface
type. For example, a definition for configuring or reading the MAC
address associated with an interface is provided that can be used for
any interface type that uses Ethernet framing.</t>
<t>Several of the augmentations defined here are not backed by any
formal standard specification. Instead, they are for features that are
commonly implemented in equivalent ways by multiple independent network
equipment vendors. The aim of this document is to define common paths and
leaves for the configuration of these equivalent features in a uniform
way, making it easier for users of the YANG model to access these
features in a vendor independent way. Where necessary, a description of
the expected behavior is also provided with the aim of ensuring vendors
implementations are consistent with the specified behavior.</t>
<t>Given that the modules contain a collection of discrete features with
the common theme that they generically apply to interfaces, it is
plausible that not all implementers of the YANG module will decide to
support all features. Hence, separate feature keywords are defined for
each logically discrete feature to allow implementers the flexibility to
choose which specific parts of the model they support.</t>
<t>The augmentations are split into two separate YANG modules that each
focus on a particular area of functionality. The two YANG modules
defined in this document are:
</t>
<ul empty="true" spacing="normal">
<li>ietf-if-extensions.yang - Defines extensions to the IETF
interface data model to support common configuration data nodes.</li>
<li>ietf-if-ethernet-like.yang - Defines a module for any
configuration and operational data nodes that are common across
interfaces that use Ethernet framing.</li>
</ul>
<section numbered="true" toc="default">
<name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
<xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/>
when, and only when, they appear in all capitals, as shown here.</t>
</section>
<section numbered="true" toc="default">
<name>Tree Diagrams</name>
<t>Tree diagrams used in this document follow the notation defined in
<xref target="RFC8340" format="default"/>.</t>
</section>
</section>
<section numbered="true" toc="default">
<name>Interface Extensions Module</name>
<t>The Interfaces Extensions YANG module provides some basic
extensions to the IETF interfaces YANG module.</t>
<t>The module provides:
</t>
<ul spacing="normal">
<li>A link flap suppression feature used to provide control over
short-lived link state flaps.</li>
<li>An interface link state dampening feature that is used to
provide control over longer lived link state flaps.</li>
<li>An encapsulation container and extensible choice statement for
use by any interface types that allow for configurable L2
encapsulations.</li>
<li>A loopback configuration leaf that is primarily aimed at
loopback at the physical layer.</li>
<li>MTU configuration leaves applicable to all packet/frame based
interfaces.</li>
<li>A forwarding mode leaf to indicate the OSI layer at which the
interface handles traffic.</li>
<li>A generic "sub-interface" identity that an interface identity
definition can derive from if it defines a sub-interface.</li>
<li>A parent interface leaf useable for all types of sub-interface
that are children of parent interfaces.</li>
</ul>
<t keepWithNext="true">The "ietf-if-extensions" YANG module has the following
structure:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
module: ietf-if-extensions
augment /if:interfaces/if:interface:
+--rw link-flap-suppression {link-flap-suppression}?
| +--rw down? uint32
| +--rw up? uint32
| +--ro carrier-transitions? yang:counter64
| +--ro timer-running? enumeration
+--rw dampening! {dampening}?
| +--rw half-life? uint32
| +--rw reuse? uint32
| +--rw suppress? uint32
| +--rw max-suppress-time? uint32
| +--ro penalty? uint32
| +--ro suppressed? boolean
| +--ro time-remaining? uint32
+--rw encapsulation
| +--rw (encaps-type)?
+--rw loopback? identityref {loopback}?
+--rw max-frame-size? uint32 {max-frame-size}?
+--ro forwarding-mode? identityref
augment /if:interfaces/if:interface:
+--rw parent-interface if:interface-ref {sub-interfaces}?
augment /if:interfaces/if:interface/if:statistics:
+--ro in-discard-unknown-encaps? yang:counter64
{sub-interfaces}?
]]></artwork>
<section numbered="true" toc="default">
<name>Link Flap Suppression</name>
<t>The link flap suppression feature augments the IETF interfaces data model
with configuration for a simple algorithm that is used, generally on
physical interfaces, to suppress short transient changes in the
interface link state. It can be used in conjunction with the
dampening feature described in <xref target="dampening" format="default"/> to provide
effective control of unstable links and unwanted state
transitions.</t>
<t>The principle of the link flap suppression feature is to use a short per
interface timer to ensure that any interface link state transition
that occurs and reverts back within the specified time interval is
entirely suppressed without providing any signalling to any upper
layer protocols that the state transition has occurred. E.g. in the
case that the link state transition is suppressed then there is no
change of the /if:interfaces/if:interface/oper-status or
/if:interfaces/if:interfaces/last-change leaves for the
interface that the feature is operating on. One obvious side effect
of using this feature that is that any state transition will always be
delayed by the specified time interval.</t>
<t>The configuration allows for separate timer values to be used in
the suppression of down->up->down link transitions vs
up->down->up link transitions.</t>
<t>The link flap suppression down timer leaf specifies the amount of time that
an interface that is currently in link up state must be continuously
down before the down state change is reported to higher level
protocols. Use of this timer can cause traffic to be black holed for
the configured value and delay reconvergence after link failures,
therefore its use is normally restricted to cases where it is
necessary to allow enough time for another protection mechanism (such
as an optical layer automatic protection system) to take effect.</t>
<t>The link flap suppression up timer leaf specifies the amount of time that
an interface that is currently in link down state must be continuously
up before the down->up link state transition is reported to higher
level protocols. This timer is generally useful as a debounce
mechanism to ensure that a link is relatively stable before being
brought into service. It can also be used effectively to limit the
frequency at which link state transition events may occur. The
default value for this leaf is determined by the underlying network
device.</t>
</section>
<section anchor="dampening" numbered="true" toc="default">
<name>Dampening</name>
<t>The dampening feature introduces a configurable exponential decay
mechanism to suppress the effects of excessive interface link state
flapping. This feature allows the network operator to configure a
device to automatically identify and selectively dampen a local
interface which is flapping. Dampening an interface keeps the
interface operationally down until the interface stops flapping and
becomes stable. Configuring the dampening feature can improve
convergence times and stability throughout the network by isolating
failures so that disturbances are not propagated, which reduces the
utilization of system processing resources by other devices in the
network and improves overall network stability.</t>
<t>The basic algorithm uses a counter that is increased by 1000 units
every time the underlying interface link state changes from up to
down. If the counter increases above the suppress threshold then the
interface is kept down (and out of service) until either the maximum
suppression time is reached, or the counter has reduced below the
reuse threshold. The half-life period determines that rate at which
the counter is periodically reduced by half.</t>
<section numbered="true" toc="default">
<name>Suppress Threshold</name>
<t>The suppress threshold is the value of the accumulated penalty
that triggers the device to dampen a flapping interface. The
flapping interface is identified by the device and assigned a
penalty for each up to down link state change, but the interface is
not automatically dampened. The device tracks the penalties that a
flapping interface accumulates. When the accumulated penalty
reaches or exceeds the suppress threshold, the interface is placed
in a suppressed state.</t>
</section>
<section numbered="true" toc="default">
<name>Half-Life Period</name>
<t>The half-life period determines how fast the
accumulated penalties can decay exponentially. The
accumulated penalty decays at a rate that causes its value
to be reduced by half after each half-life period.</t>
</section>
<section numbered="true" toc="default">
<name>Reuse Threshold</name>
<t>If, after one or more half-life periods, the accumulated penalty
decreases below the reuse threshold and the underlying interface
link state is up then the interface is taken out of suppressed state
and is allowed to go up.</t>
</section>
<section numbered="true" toc="default">
<name>Maximum Suppress Time</name>
<t>The maximum suppress time represents the maximum amount of time
an interface can remain dampened when a new penalty is assigned to
an interface. The default of the maximum suppress timer is four
times the half-life period. The maximum value of the accumulated
penalty is calculated using the maximum suppress time, reuse
threshold and half-life period.</t>
</section>
</section>
<section numbered="true" toc="default">
<name>Encapsulation</name>
<t>The encapsulation container holds a choice node that is to be
augmented with datalink layer specific encapsulations, such as HDLC,
PPP, or sub-interface 802.1Q tag match encapsulations. The use of a
choice statement ensures that an interface can only have a single
datalink layer protocol configured.</t>
<t>The different encapsulations themselves are defined in separate
YANG modules defined in other documents that augment the
encapsulation choice statement. For example the Ethernet specific
basic 'dot1q-vlan' encapsulation is defined in ietf-if-l3-vlan.yang
and the 'flexible' encapsulation is defined in
ietf-flexible-encapsulation.yang, both modules from <xref target="I-D.ietf-netmod-sub-intf-vlan-model" format="default"/>.</t>
</section>
<section numbered="true" toc="default">
<name>Loopback</name>
<t>The loopback configuration leaf allows any physical interface to be
configured to be in one of the possible following physical loopback
modes, i.e. internal loopback, line loopback, or use of an external
loopback connector. The use of YANG identities allows for the model
to be extended with other modes of loopback if required.</t>
<t>The following loopback modes are defined:
</t>
<ul spacing="normal">
<li>Internal loopback - All egress traffic on the interface is
internally looped back within the interface to be received on the
ingress path.</li>
<li>Line loopback - All ingress traffic received on the interface
is internally looped back within the interface to the egress
path.</li>
<li>Loopback Connector - The interface has a physical loopback
connector attached that loops all egress traffic back into the
interface's ingress path, with equivalent semantics to internal
loopback.</li>
</ul>
</section>
<section numbered="true" toc="default">
<name>Maximum frame size</name>
<t>A maximum frame size configuration leaf (max-frame-size) is
provided to specify the maximum size of a layer 2 frame that may be
transmitted or received on an interface. The value includes the
overhead of any layer 2 header, the maximum length of the payload, and
any frame check sequence (FCS) bytes. If configured, the
max-frame-size leaf on an interface also restricts the max-frame-size
of any child sub-interfaces, and the available MTU for protocols.</t>
</section>
<section numbered="true" toc="default">
<name>Sub-interface</name>
<t>The sub-interface feature specifies the minimal leaves required to
define a child interface that is parented to another interface.</t>
<t>A sub-interface is a logical interface that handles a subset of the
traffic on the parent interface. Separate configuration leaves are
used to classify the subset of ingress traffic received on the parent
interface to be processed in the context of a given sub-interface.
All egress traffic processed on a sub-interface is given to the parent
interface for transmission. Otherwise, a sub-interface is like any
other interface in /if:interfaces and supports the standard interface
features and configuration.</t>
<t>For some vendor specific interface naming conventions the name of
the child interface is sufficient to determine the parent interface,
which implies that the child interface can never be reparented to a
different parent interface after it has been created without deleting
the existing sub-interface and recreating a new sub-interface. Even in
this case it is useful to have a well-defined leaf to cleanly identify
the parent interface.</t>
<t>The model also allows for arbitrarily named sub-interfaces by
having an explicit parent-interface leaf define the child -> parent
relationship. In this naming scenario it is also possible for
implementations to allow for logical interfaces to be reparented to
new parent interfaces without needing the sub-interface to be
destroyed and recreated.</t>
</section>
<section numbered="true" toc="default">
<name>Forwarding Mode</name>
<t>The forwarding mode leaf provides additional information as to what
mode or layer an interface is logically operating and forwarding
traffic at. The implication of this leaf is that for traffic
forwarded at a given layer that any headers for lower layers are
stripped off before the packet is forwarded at the given layer.
Conversely, on egress any lower layer headers must be added to the
packet before it is transmitted out of the interface.</t>
<t>The following forwarding modes are defined:
</t>
<ul spacing="normal">
<li>Physical - Traffic is being forwarded at the physical layer.
This includes DWDM or OTN based switching.</li>
<li>Data-link - Layer 2 based forwarding, such as Ethernet/VLAN
based switching, or L2VPN services.</li>
<li>Network - Network layer based forwarding, such as IP, MPLS, or
L3VPNs.</li>
</ul>
</section>
</section>
<section numbered="true" toc="default">
<name>Interfaces Ethernet-Like Module</name>
<t>The Interfaces Ethernet-Like Module is a small module that contains
all configuration and operational data that is common across interface
types that use Ethernet framing as their datalink layer
encapsulation.</t>
<t>This module currently contains leaves for the configuration and
reporting of the operational MAC address and the burnt-in MAC address
(BIA) associated with any interface using Ethernet framing.</t>
<t keepWithNext="true">The "ietf-if-ethernet-like" YANG module has the
following structure:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
module: ietf-if-ethernet-like
augment /if:interfaces/if:interface:
+--rw ethernet-like
+--rw mac-address? yang:mac-address
| {configurable-mac-address}?
+--ro bia-mac-address? yang:mac-address
augment /if:interfaces/if:interface/if:statistics:
+--ro in-drop-unknown-dest-mac-pkts? yang:counter64
+--ro in-discard-overflows? yang:counter64
]]></artwork>
</section>
<section numbered="true" toc="default">
<name>Interface Extensions YANG Module</name>
<t>
This YANG module augments the interface container
defined in <xref target="RFC8343" format="default"/>. It also
contains references to <xref target="RFC6991" format="default"/>
and <xref target="RFC7224" format="default"/>.
</t>
<sourcecode name="[email protected]" type="" markers="true"><![CDATA[
module ietf-if-extensions {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-if-extensions";
prefix if-ext;
import ietf-yang-types {
prefix yang;
reference "RFC 6991: Common YANG Data Types";
}
import ietf-interfaces {
prefix if;
reference
"RFC 8343: A YANG Data Model For Interface Management";
}
import iana-if-type {
prefix ianaift;
reference "RFC 7224: IANA Interface Type YANG Module";
}
organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:[email protected]>
Editor: Robert Wilton
<mailto:[email protected]>";
description
"This module contains common definitions for extending the IETF
interface YANG model (RFC 8343) with common configurable layer 2
properties.
Copyright (c) 2023 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
revision 2023-01-26 {
description
"Initial revision.";
reference
"RFC XXXX, Common Interface Extension YANG Data Models";
}
feature link-flap-suppression {
description
"This feature indicates that configurable interface link
delay is supported, which is a feature is used to limit the
propagation of very short interface link state flaps.";
reference "RFC XXXX, Section 2.1 Link Flap Suppression";
}
feature dampening {
description
"This feature indicates that the device supports interface
dampening, which is a feature that is used to limit the
propagation of interface link state flaps over longer
periods.";
reference "RFC XXXX, Section 2.2 Dampening";
}
feature loopback {
description
"This feature indicates that configurable interface loopback is
supported.";
reference "RFC XXXX, Section 2.4 Loopback";
}
feature max-frame-size {
description
"This feature indicates that the device supports configuring or
reporting the maximum frame size on interfaces.";
reference "RFC XXXX, Section 2.5 Maximum Frame Size";
}
feature sub-interfaces {
description
"This feature indicates that the device supports the
instantiation of sub-interfaces. Sub-interfaces are defined
as logical child interfaces that allow features and forwarding
decisions to be applied to a subset of the traffic processed
on the specified parent interface.";
reference "RFC XXXX, Section 2.6 Sub-interface";
}
/*
* Define common identities to help allow interface types to be
* assigned properties.
*/
identity sub-interface {
description
"Base type for generic sub-interfaces.
New or custom interface types can derive from this type to
inherit generic sub-interface configuration.";
reference "RFC XXXX, Section 2.6 Sub-interface";
}
identity ethSubInterface{
base ianaift:l2vlan;
base sub-interface;
description
"This identity represents the child sub-interface of any
interface types that uses Ethernet framing (with or without
802.1Q tagging).";
}
identity loopback {
description "Base identity for interface loopback options";
reference "RFC XXXX, Section 2.4";
}
identity internal {
base loopback;
description
"All egress traffic on the interface is internally looped back
within the interface to be received on the ingress path.";
reference "RFC XXXX, Section 2.4";
}
identity line {
base loopback;
description
"All ingress traffic received on the interface is internally
looped back within the interface to the egress path.";
reference "RFC XXXX, Section 2.4";
}
identity connector {
base loopback;
description
"The interface has a physical loopback connector attached that
loops all egress traffic back into the interface's ingress
path, with equivalent semantics to loopback internal.";
reference "RFC XXXX, Section 2.4";
}
identity forwarding-mode {
description "Base identity for forwarding-mode options.";
reference "RFC XXXX, Section 2.7";
}
identity physical {
base forwarding-mode;
description
"Physical layer forwarding. This includes DWDM or OTN based
optical switching.";
reference "RFC XXXX, Section 2.7";
}
identity data-link {
base forwarding-mode;
description
"Layer 2 based forwarding, such as Ethernet/VLAN based
switching, or L2VPN services.";
reference "RFC XXXX, Section 2.7";
}
identity network {
base forwarding-mode;
description
"Network layer based forwarding, such as IP, MPLS, or L3VPNs.";
reference "RFC XXXX, Section 2.7";
}
/*
* Augments the IETF interfaces model with leaves to configure
* and monitor link-flap-suppression on an interface.
*/
augment "/if:interfaces/if:interface" {
description
"Augments the IETF interface model with optional common
interface level commands that are not formally covered by any
specific standard.";
/*
* Defines standard YANG for the Link Flap Suppression feature.
*/
container link-flap-suppression {
if-feature "link-flap-suppression";
description
"Holds link flap related feature configuration.";
leaf down {
type uint32;
units milliseconds;
description
"Delays the propagation of a 'loss of carrier signal' event
that would cause the interface state to go down, i.e. the
command allows short link flaps to be suppressed. The
configured value indicates the minimum time interval (in
milliseconds) that the link signal must be continuously
down before the interface state is brought down. If not
configured, the behavior on loss of link signal is
vendor/interface specific, but with the general
expectation that there should be little or no delay.";
}
leaf up {
type uint32;
units milliseconds;
description
"Defines the minimum time interval (in milliseconds) that
the link signal must be continuously present and error
free before the interface state is allowed to transition
from down to up. If not configured, the behavior is
vendor/interface specific, but with the general
expectation that sufficient default delay should be used
to ensure that the interface is stable when enabled before
being reported as being up. Configured values that are
too low for the hardware capabilties may be rejected.";
}
leaf carrier-transitions {
type yang:counter64;
units transitions;
config false;
description
"Defines the number of times the underlying link state
has changed to, or from, state up. This counter should be
incremented even if the high layer interface state changes
are being suppressed by a running link flap suppression
timer.";
}
leaf timer-running {
type enumeration {
enum none {
description
"No link flap suppression timer is running.";
}
enum up {
description
"link-flap-suppression up timer is running. The
underlying link state is up, but interface state is
not reported as up.";
}
enum down {
description
"link-flap-suppression down timer is running.
Interface state is reported as up, but the underlying
link state is actually down.";
}
}
config false;
description
"Reports whether a link flap suppression timer is actively
running, in which case the interface state does not match
the underlying link state.";
}
reference "RFC XXXX, Section 2.1 Link Flap Suppression";
}
/*
* Augments the IETF interfaces model with a container to hold
* generic interface dampening
*/
container dampening {
if-feature "dampening";
presence
"Enable interface link flap dampening with default settings
(that are vendor/device specific).";
description
"Interface dampening limits the propagation of interface link
state flaps over longer periods.";
reference "RFC XXXX, Section 2.2 Dampening";
leaf half-life {
type uint32;
units seconds;
description
"The time (in seconds) after which a penalty would be half
its original value. Once the interface has been assigned
a penalty, the penalty is decreased at a decay rate
equivalent to the half-life. For some devices, the
allowed values may be restricted to particular multiples
of seconds. The default value is vendor/device
specific.";
reference "RFC XXXX, Section 2.3.2 Half-Life Period";
}
leaf reuse {
type uint32;
description
"Penalty value below which a stable interface is
unsuppressed (i.e. brought up) (no units). The default
value is vendor/device specific. The penalty value for a
link up->down state change is 1000 units.";
reference "RFC XXXX, Section 2.2.3 Reuse Threshold";
}
leaf suppress {
type uint32;
description
"Limit at which an interface is suppressed (i.e. held down)
when its penalty exceeds that limit (no units). The value
must be greater than the reuse threshold. The default
value is vendor/device specific. The penalty value for a
link up->down state change is 1000 units.";
reference "RFC XXXX, Section 2.2.1 Suppress Threshold";
}
leaf max-suppress-time {
type uint32;
units seconds;
description
"Maximum time (in seconds) that an interface can be
suppressed before being unsuppressed if no further link
up->down state change penalties have been applied. This
value effectively acts as a ceiling that the penalty value
cannot exceed. The default value is vendor/device
specific.";
reference "RFC XXXX, Section 2.2.4 Maximum Suppress Time";
}
leaf penalty {
type uint32;
config false;
description
"The current penalty value for this interface. When the
penalty value exceeds the 'suppress' leaf then the
interface is suppressed (i.e. held down).";
reference "RFC XXXX, Section 2.2 Dampening";
}
leaf suppressed {
type boolean;
config false;
description
"Represents whether the interface is suppressed (i.e. held
down) because the 'penalty' leaf value exceeds the
'suppress' leaf.";
reference "RFC XXXX, Section 2.2 Dampening";
}
leaf time-remaining {
when '../suppressed = "true"' {
description
"Only suppressed interfaces have a time remaining.";
}
type uint32;
units seconds;
config false;
description
"For a suppressed interface, this leaf represents how long
(in seconds) that the interface will remain suppressed
before it is allowed to go back up again.";
reference "RFC XXXX, Section 2.2 Dampening";
}
}
/*
* Various types of interfaces support a configurable layer 2
* encapsulation, any that are supported by YANG should be
* listed here.
*
* Different encapsulations can hook into the common encaps-type
* choice statement.
*/
container encapsulation {
when
"derived-from-or-self(../if:type,
'ianaift:ethernetCsmacd') or
derived-from-or-self(../if:type,
'ianaift:ieee8023adLag') or
derived-from-or-self(../if:type, 'ianaift:pos') or
derived-from-or-self(../if:type,
'ianaift:atmSubInterface') or
derived-from-or-self(../if:type, 'ianaift:l2vlan') or
derived-from-or-self(../if:type, 'ethSubInterface')" {
description
"All interface types that can have a configurable L2
encapsulation.";
}
description
"Holds the OSI layer 2 encapsulation associated with an
interface.";
choice encaps-type {
description
"Extensible choice of layer 2 encapsulations";
reference "RFC XXXX, Section 2.3 Encapsulation";
}
}
/*
* Various types of interfaces support loopback configuration,
* any that are supported by YANG should be listed here.
*/
leaf loopback {
when "derived-from-or-self(../if:type,
'ianaift:ethernetCsmacd') or
derived-from-or-self(../if:type, 'ianaift:sonet') or
derived-from-or-self(../if:type, 'ianaift:atm') or
derived-from-or-self(../if:type, 'ianaift:otnOtu')" {
description
"All interface types that support loopback configuration.";
}
if-feature "loopback";
type identityref {
base loopback;
}
description "Enables traffic loopback.";
reference "RFC XXXX, Section 2.4 Loopback";
}
/*
* Allows the maximum frame size to be configured or reported.
*/
leaf max-frame-size {
if-feature "max-frame-size";
type uint32 {
range "64 .. max";
}
description
"The maximum size of layer 2 frames that may be transmitted
or received on the interface (including any frame header,
maximum frame payload size, and frame checksum sequence).
If configured, the max-frame-size also limits the maximum
frame size of any child sub-interfaces. The MTU available
to higher layer protocols is restricted to the maximum frame
payload size, and MAY be further restricted by explicit
layer 3 or protocol specific MTU configuration.";
reference "RFC XXXX, Section 2.5 Maximum Frame Size";
}
/*
* Augments the IETF interfaces model with a leaf that indicates
* which mode, or layer, is being used to forward the traffic.
*/
leaf forwarding-mode {
type identityref {
base forwarding-mode;
}
config false;
description
"The forwarding mode that the interface is operating in.";
reference "RFC XXXX, Section 2.7 Forwarding Mode";
}
}
/*
* Add generic support for sub-interfaces.
*
* This should be extended to cover all interface types that are
* child interfaces of other interfaces.
*/
augment "/if:interfaces/if:interface" {
when "derived-from(if:type, 'sub-interface') or
derived-from-or-self(if:type, 'ianaift:l2vlan') or
derived-from-or-self(if:type, 'ianaift:atmSubInterface') or
derived-from-or-self(if:type, 'ianaift:frameRelay')" {
description
"Any ianaift:types that explicitly represent sub-interfaces
or any types that derive from the sub-interface identity.";
}
if-feature "sub-interfaces";
description
"Adds a parent interface field to interfaces that model
sub-interfaces.";
leaf parent-interface {
type if:interface-ref;
mandatory true;
description
"This is the reference to the parent interface of this
sub-interface.";
reference "RFC XXXX, Section 2.6 Sub-interface";
}
}
/*
* Add discard counter for unknown sub-interface encapsulation
*/
augment "/if:interfaces/if:interface/if:statistics" {
when "derived-from-or-self(../if:type,
'ianaift:ethernetCsmacd') or
derived-from-or-self(../if:type,
'ianaift:ieee8023adLag') or
derived-from-or-self(../if:type, 'ianaift:ifPwType')" {
description
"Applies to interfaces that can demultiplex ingress frames to
sub-interfaces.";
}
if-feature "sub-interfaces";
description
"Augment the interface model statistics with a sub-interface
demux discard counter.";
leaf in-discard-unknown-encaps {
type yang:counter64;
units frames;
description
"A count of the number of frames that were well formed, but
otherwise discarded because their encapsulation does not
classify the frame to the interface or any child
sub-interface. E.g., a frame might be discarded because the
it has an unknown VLAN Id, or does not have a VLAN Id when
one is expected.
For consistency, frames counted against this counter are
also counted against the IETF interfaces statistics. In
particular, they are included in in-octets and in-discards,
but are not included in in-unicast-pkts, in-multicast-pkts
or in-broadcast-pkts, because they are not delivered to a
higher layer.
Discontinuities in the values of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of the 'discontinuity-time'
leaf defined in the ietf-interfaces YANG module
(RFC 8343).";
}
}
}
]]></sourcecode>
</section>
<section numbered="true" toc="default">
<name>Interfaces Ethernet-Like YANG Module</name>
<t>This YANG module augments the interface container defined in
<xref target="RFC8343" format="default">RFC 8343</xref> for Ethernet-like
interfaces. This includes Ethernet interfaces, 802.3 LAG (802.1AX)
interfaces, Switch Virtual interfaces, and Pseudo-Wire Head-End
interfaces. It also contains references to <xref target="RFC6991" format="default"/>, <xref target="RFC7224" format="default"/>, and <xref target="IEEE_802.3.2_2019" format="default"/>.</t>
<sourcecode name="[email protected]" type="" markers="true"><![CDATA[
module ietf-if-ethernet-like {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-if-ethernet-like";
prefix ethlike;
import ietf-interfaces {
prefix if;
reference
"RFC 8343: A YANG Data Model For Interface Management";
}
import ietf-yang-types {
prefix yang;
reference "RFC 6991: Common YANG Data Types";
}
import iana-if-type {
prefix ianaift;
reference "RFC 7224: IANA Interface Type YANG Module";
}
organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:[email protected]>
Editor: Robert Wilton
<mailto:[email protected]>";
description
"This module contains YANG definitions for configuration for
'Ethernet-like' interfaces. It is applicable to all interface
types that use Ethernet framing and expose an Ethernet MAC
layer, and includes such interfaces as physical Ethernet
interfaces, Ethernet LAG interfaces and VLAN sub-interfaces.
Additional interface configuration and counters for physical
Ethernet interfaces are defined in
ieee802-ethernet-interface.yang, as part of IEEE Std
802.3.2-2019.