idnits 2.17.1 draft-ietf-netmod-intf-ext-yang-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 211 has weird spacing: '...terface if:...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 29, 2020) is 1367 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: 'RFCXXXX' is mentioned on line 1370, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-netmod-sub-intf-vlan-model-07 -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Wilton, Ed. 3 Internet-Draft D. Ball 4 Intended status: Standards Track T. Singh 5 Expires: January 30, 2021 Cisco Systems 6 S. Sivaraj 7 Juniper Networks 8 July 29, 2020 10 Common Interface Extension YANG Data Models 11 draft-ietf-netmod-intf-ext-yang-10 13 Abstract 15 This document defines two YANG modules that augment the Interfaces 16 data model defined in the "YANG Data Model for Interface Management" 17 with additional configuration and operational data nodes to support 18 common lower layer interface properties, such as interface MTU. 20 The YANG modules in this document conform to the Network Management 21 Datastore Architecture (NMDA) defined in RFC 8342. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 30, 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Interface Extensions Module . . . . . . . . . . . . . . . . . 4 61 2.1. Carrier Delay . . . . . . . . . . . . . . . . . . . . . . 5 62 2.2. Dampening . . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.2.1. Suppress Threshold . . . . . . . . . . . . . . . . . 7 64 2.2.2. Half-Life Period . . . . . . . . . . . . . . . . . . 7 65 2.2.3. Reuse Threshold . . . . . . . . . . . . . . . . . . . 7 66 2.2.4. Maximum Suppress Time . . . . . . . . . . . . . . . . 7 67 2.3. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 7 68 2.4. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 8 69 2.5. Maximum frame size . . . . . . . . . . . . . . . . . . . 8 70 2.6. Sub-interface . . . . . . . . . . . . . . . . . . . . . . 8 71 2.7. Forwarding Mode . . . . . . . . . . . . . . . . . . . . . 9 72 3. Interfaces Ethernet-Like Module . . . . . . . . . . . . . . . 9 73 4. Interface Extensions YANG Module . . . . . . . . . . . . . . 10 74 5. Interfaces Ethernet-Like YANG Module . . . . . . . . . . . . 21 75 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 25 76 6.1. Carrier delay configuration . . . . . . . . . . . . . . . 25 77 6.2. Dampening configuration . . . . . . . . . . . . . . . . . 26 78 6.3. MAC address configuration . . . . . . . . . . . . . . . . 27 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 80 8. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 29 81 8.1. Version -10 . . . . . . . . . . . . . . . . . . . . . . . 29 82 8.2. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 29 83 8.3. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 29 84 8.4. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 29 85 8.5. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 29 86 8.6. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 29 87 8.7. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 29 88 8.8. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 30 89 8.9. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 30 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 91 9.1. YANG Module Registrations . . . . . . . . . . . . . . . . 30 92 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 93 10.1. ietf-if-extensions.yang . . . . . . . . . . . . . . . . 31 94 10.2. ietf-if-ethernet-like.yang . . . . . . . . . . . . . . . 32 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 32 97 11.2. Informative References . . . . . . . . . . . . . . . . . 33 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 100 1. Introduction 102 This document defines two NMDA compatible [RFC8342] YANG 1.1 103 [RFC7950] modules for the management of network interfaces. It 104 defines various augmentations to the generic interfaces data model 105 [RFC8343] to support configuration of lower layer interface 106 properties that are common across many types of network interface. 108 One of the aims of this document is to provide a standard definition 109 for these configuration items regardless of the underlying interface 110 type. For example, a definition for configuring or reading the MAC 111 address associated with an interface is provided that can be used for 112 any interface type that uses Ethernet framing. 114 Several of the augmentations defined here are not backed by any 115 formal standard specification. Instead, they are for features that 116 are commonly implemented in equivalent ways by multiple independent 117 network equipment vendors. The aim of this document is to define 118 common paths and leaves for the configuration of these equivalent 119 features in a uniform way, making it easier for users of the YANG 120 model to access these features in a vendor independent way. Where 121 necessary, a description of the expected behavior is also provided 122 with the aim of ensuring vendors implementations are consistent with 123 the specified behaviour. 125 Given that the modules contain a collection of discrete features with 126 the common theme that they generically apply to interfaces, it is 127 plausible that not all implementors of the YANG module will decide to 128 support all features. Hence separate feature keywords are defined 129 for each logically discrete feature to allow implementors the 130 flexibility to choose which specific parts of the model they support. 132 The augmentations are split into two separate YANG modules that each 133 focus on a particular area of functionality. The two YANG modules 134 defined in this document are: 136 ietf-if-extensions.yang - Defines extensions to the IETF interface 137 data model to support common configuration data nodes. 139 ietf-if-ethernet-like.yang - Defines a module for any 140 configuration and operational data nodes that are common across 141 interfaces that use Ethernet framing. 143 1.1. Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in BCP 148 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 149 appear in all capitals, as shown here. 151 1.2. Tree Diagrams 153 Tree diagrams used in this document follow the notation defined in 154 [RFC8340]. 156 2. Interface Extensions Module 158 The Interfaces Extensions YANG module provides some basic extensions 159 to the IETF interfaces YANG module. 161 The module provides: 163 o A carrier delay feature used to provide control over short lived 164 link state flaps. 166 o An interface link state dampening feature that is used to provide 167 control over longer lived link state flaps. 169 o An encapsulation container and extensible choice statement for use 170 by any interface types that allow for configurable L2 171 encapsulations. 173 o A loopback configuration leaf that is primarily aimed at loopback 174 at the physical layer. 176 o MTU configuration leaves applicable to all packet/frame based 177 interfaces. 179 o A forwarding mode leaf to indicate the OSI layer at which the 180 interface handles traffic. 182 o A generic "sub-interface" identity that an interface identity 183 definition can derive from if it defines a sub-interface. 185 o A parent interface leaf useable for all types of sub-interface 186 that are children of parent interfaces. 188 The "ietf-if-extensions" YANG module has the following structure: 190 module: ietf-if-extensions 191 augment /if:interfaces/if:interface: 192 +--rw carrier-delay {carrier-delay}? 193 | +--rw down? uint32 194 | +--rw up? uint32 195 | +--ro carrier-transitions? yang:counter64 196 | +--ro timer-running? enumeration 197 +--rw dampening! {dampening}? 198 | +--rw half-life? uint32 199 | +--rw reuse? uint32 200 | +--rw suppress? uint32 201 | +--rw max-suppress-time? uint32 202 | +--ro penalty? uint32 203 | +--ro suppressed? boolean 204 | +--ro time-remaining? uint32 205 +--rw encapsulation 206 | +--rw (encaps-type)? 207 +--rw loopback? identityref {loopback}? 208 +--rw max-frame-size? uint32 {max-frame-size}? 209 +--ro forwarding-mode? identityref 210 augment /if:interfaces/if:interface: 211 +--rw parent-interface if:interface-ref {sub-interfaces}? 212 augment /if:interfaces/if:interface/if:statistics: 213 +--ro in-discard-unknown-encaps? yang:counter64 214 {sub-interfaces}? 216 2.1. Carrier Delay 218 The carrier delay feature augments the IETF interfaces data model 219 with configuration for a simple algorithm that is used, generally on 220 physical interfaces, to suppress short transient changes in the 221 interface link state. It can be used in conjunction with the 222 dampening feature described in Section 2.2 to provide effective 223 control of unstable links and unwanted state transitions. 225 The principle of the carrier delay feature is to use a short per 226 interface timer to ensure that any interface link state transition 227 that occurs and reverts back within the specified time interval is 228 entirely suppressed without providing any signalling to any upper 229 layer protocols that the state transition has occurred. E.g. in the 230 case that the link state transition is suppressed then there is no 231 change of the /if:interfaces/if:interface/oper-status or 232 /if:interfaces/if:interfaces/last-change leaves for the interface 233 that the feature is operating on. One obvious side effect of using 234 this feature that is that any state transition will always be delayed 235 by the specified time interval. 237 The configuration allows for separate timer values to be used in the 238 suppression of down->up->down link transitions vs up->down->up link 239 transitions. 241 The carrier delay down timer leaf specifies the amount of time that 242 an interface that is currently in link up state must be continuously 243 down before the down state change is reported to higher level 244 protocols. Use of this timer can cause traffic to be black holed for 245 the configured value and delay reconvergence after link failures, 246 therefore its use is normally restricted to cases where it is 247 necessary to allow enough time for another protection mechanism (such 248 as an optical layer automatic protection system) to take effect. 250 The carrier delay up timer leaf specifies the amount of time that an 251 interface that is currently in link down state must be continuously 252 up before the down->up link state transition is reported to higher 253 level protocols. This timer is generally useful as a debounce 254 mechanism to ensure that a link is relatively stable before being 255 brought into service. It can also be used effectively to limit the 256 frequency at which link state transition events may occur. The 257 default value for this leaf is determined by the underlying network 258 device. 260 2.2. Dampening 262 The dampening feature introduces a configurable exponential decay 263 mechanism to suppress the effects of excessive interface link state 264 flapping. This feature allows the network operator to configure a 265 device to automatically identify and selectively dampen a local 266 interface which is flapping. Dampening an interface keeps the 267 interface operationally down until the interface stops flapping and 268 becomes stable. Configuring the dampening feature can improve 269 convergence times and stability throughout the network by isolating 270 failures so that disturbances are not propagated, which reduces the 271 utilization of system processing resources by other devices in the 272 network and improves overall network stability. 274 The basic algorithm uses a counter that is increased by 1000 units 275 every time the underlying interface link state changes from up to 276 down. If the counter increases above the suppress threshold then the 277 interface is kept down (and out of service) until either the maximum 278 suppression time is reached, or the counter has reduced below the 279 reuse threshold. The half-life period determines that rate at which 280 the counter is periodically reduced by half. 282 2.2.1. Suppress Threshold 284 The suppress threshold is the value of the accumulated penalty that 285 triggers the device to dampen a flapping interface. The flapping 286 interface is identified by the device and assigned a penalty for each 287 up to down link state change, but the interface is not automatically 288 dampened. The device tracks the penalties that a flapping interface 289 accumulates. When the accumulated penalty reaches or exceeds the 290 suppress threshold, the interface is placed in a suppressed state. 292 2.2.2. Half-Life Period 294 The half-life period determines how fast the accumulated penalties 295 can decay exponentially. The accumulated penalty decays at a rate 296 that causes its value to be reduced by half after each half-life 297 period. 299 2.2.3. Reuse Threshold 301 If, after one or more half-life periods, the accumulated penalty 302 decreases below the reuse threshold and the underlying interface link 303 state is up then the interface is taken out of suppressed state and 304 is allowed to go up. 306 2.2.4. Maximum Suppress Time 308 The maximum suppress time represents the maximum amount of time an 309 interface can remain dampened when a new penalty is assigned to an 310 interface. The default of the maximum suppress timer is four times 311 the half-life period. The maximum value of the accumulated penalty 312 is calculated using the maximum suppress time, reuse threshold and 313 half-life period. 315 2.3. Encapsulation 317 The encapsulation container holds a choice node that is to be 318 augmented with datalink layer specific encapsulations, such as HDLC, 319 PPP, or sub-interface 802.1Q tag match encapsulations. The use of a 320 choice statement ensures that an interface can only have a single 321 datalink layer protocol configured. 323 The different encapsulations themselves are defined in separate YANG 324 modules defined in other documents that augument the encapsulation 325 choice statement. For example the Ethernet specific basic 'dot1q- 326 vlan' encapsulation is defined in ietf-if-l3-vlan.yang and the 327 'flexible' encapsulation is defined in ietf-flexible- 328 encapsulation.yang, both modules from 329 [I-D.ietf-netmod-sub-intf-vlan-model]. 331 2.4. Loopback 333 The loopback configuration leaf allows any physical interface to be 334 configured to be in one of the possible following physical loopback 335 modes, i.e. internal loopback, line loopback, or use of an external 336 loopback connector. The use of YANG identities allows for the model 337 to be extended with other modes of loopback if required. 339 The following loopback modes are defined: 341 o Internal loopback - All egress traffic on the interface is 342 internally looped back within the interface to be received on the 343 ingress path. 345 o Line loopback - All ingress traffic received on the interface is 346 internally looped back within the interface to the egress path. 348 o Loopback Connector - The interface has a physical loopback 349 connector attached that loops all egress traffic back into the 350 interface's ingress path, with equivalent semantics to internal 351 loopback. 353 2.5. Maximum frame size 355 A maximum frame size configuration leaf (max-frame-size) is provided 356 to specify the maximum size of a layer 2 frame that may be 357 transmitted or received on an interface. The value includes the 358 overhead of any layer 2 header, the maximum length of the payload, 359 and any frame check sequence (FCS) bytes. If configured, the max- 360 frame-size leaf on an interface also restricts the max-frame-size of 361 any child sub-interfaces, and the available MTU for protocols. 363 2.6. Sub-interface 365 The sub-interface feature specifies the minimal leaves required to 366 define a child interface that is parented to another interface. 368 A sub-interface is a logical interface that handles a subset of the 369 traffic on the parent interface. Separate configuration leaves are 370 used to classify the subset of ingress traffic received on the parent 371 interface to be processed in the context of a given sub-interface. 372 All egress traffic processed on a sub-interface is given to the 373 parent interface for transmission. Otherwise, a sub-interface is 374 like any other interface in /if:interfaces and supports the standard 375 interface features and configuration. 377 For some vendor specific interface naming conventions the name of the 378 child interface is sufficient to determine the parent interface, 379 which implies that the child interface can never be reparented to a 380 different parent interface after it has been created without deleting 381 the existing sub-interface and recreating a new sub-interface. Even 382 in this case it is useful to have a well defined leaf to cleanly 383 identify the parent interface. 385 The model also allows for arbitrarily named sub-interfaces by having 386 an explicit parent-interface leaf define the child -> parent 387 relationship. In this naming scenario it is also possible for 388 implementations to allow for logical interfaces to be reparented to 389 new parent interfaces without needing the sub-interface to be 390 destroyed and recreated. 392 2.7. Forwarding Mode 394 The forwarding mode leaf provides additional information as to what 395 mode or layer an interface is logically operating and forwarding 396 traffic at. The implication of this leaf is that for traffic 397 forwarded at a given layer that any headers for lower layers are 398 stripped off before the packet is forwarded at the given layer. 399 Conversely, on egress any lower layer headers must be added to the 400 packet before it is transmitted out of the interface. 402 The following forwarding modes are defined: 404 o Physical - Traffic is being forwarded at the physical layer. This 405 includes DWDM or OTN based switching. 407 o Data-link - Layer 2 based forwarding, such as Ethernet/VLAN based 408 switching, or L2VPN services. 410 o Network - Network layer based forwarding, such as IP, MPLS, or 411 L3VPNs. 413 3. Interfaces Ethernet-Like Module 415 The Interfaces Ethernet-Like Module is a small module that contains 416 all configuration and operational data that is common across 417 interface types that use Ethernet framing as their datalink layer 418 encapsulation. 420 This module currently contains leaves for the configuration and 421 reporting of the operational MAC address and the burnt-in MAC address 422 (BIA) associated with any interface using Ethernet framing. 424 The "ietf-if-ethernet-like" YANG module has the following structure: 426 module: ietf-if-ethernet-like 427 augment /if:interfaces/if:interface: 428 +--rw ethernet-like 429 +--rw mac-address? yang:mac-address 430 | {configurable-mac-address}? 431 +--ro bia-mac-address? yang:mac-address 432 augment /if:interfaces/if:interface/if:statistics: 433 +--ro in-drop-unknown-dest-mac-pkts? yang:counter64 435 4. Interface Extensions YANG Module 437 This YANG module augments the interface container defined in 438 [RFC8343]. It also contains references to [RFC6991] and [RFC7224]. 440 file "ietf-if-extensions@2020-07-29.yang" 441 module ietf-if-extensions { 442 yang-version 1.1; 444 namespace "urn:ietf:params:xml:ns:yang:ietf-if-extensions"; 446 prefix if-ext; 448 import ietf-yang-types { 449 prefix yang; 450 reference "RFC 6991: Common YANG Data Types"; 451 } 453 import ietf-interfaces { 454 prefix if; 455 reference 456 "RFC 8343: A YANG Data Model For Interface Management"; 457 } 459 import iana-if-type { 460 prefix ianaift; 461 reference "RFC 7224: IANA Interface Type YANG Module"; 462 } 464 organization 465 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 467 contact 468 "WG Web: 469 WG List: 471 Editor: Robert Wilton 472 "; 474 description 475 "This module contains common definitions for extending the IETF 476 interface YANG model (RFC 8343) with common configurable layer 2 477 properties. 479 Copyright (c) 2020 IETF Trust and the persons identified as 480 authors of the code. All rights reserved. 482 Redistribution and use in source and binary forms, with or 483 without modification, is permitted pursuant to, and subject to 484 the license terms contained in, the Simplified BSD License set 485 forth in Section 4.c of the IETF Trust's Legal Provisions 486 Relating to IETF Documents 487 (https://trustee.ietf.org/license-info). 489 This version of this YANG module is part of RFC XXXX 490 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 491 for full legal notices. 493 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 494 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 495 'MAY', and 'OPTIONAL' in this document are to be interpreted as 496 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 497 they appear in all capitals, as shown here."; 499 revision 2020-07-29 { 500 description 501 "Initial revision."; 503 reference 504 "RFC XXXX, Common Interface Extension YANG Data Models"; 505 } 507 feature carrier-delay { 508 description 509 "This feature indicates that configurable interface carrier 510 delay is supported, which is a feature is used to limit the 511 propagation of very short interface link state flaps."; 512 reference "RFC XXXX, Section 2.1 Carrier Delay"; 513 } 515 feature dampening { 516 description 517 "This feature indicates that the device supports interface 518 dampening, which is a feature that is used to limit the 519 propagation of interface link state flaps over longer 520 periods."; 521 reference "RFC XXXX, Section 2.2 Dampening"; 522 } 524 feature loopback { 525 description 526 "This feature indicates that configurable interface loopback is 527 supported."; 528 reference "RFC XXXX, Section 2.4 Loopback"; 529 } 531 feature max-frame-size { 532 description 533 "This feature indicates that the device supports configuring or 534 reporting the maximum frame size on interfaces."; 535 reference "RFC XXXX, Section 2.5 Maximum Frame Size"; 536 } 538 feature sub-interfaces { 539 description 540 "This feature indicates that the device supports the 541 instantiation of sub-interfaces. Sub-interfaces are defined 542 as logical child interfaces that allow features and forwarding 543 decisions to be applied to a subset of the traffic processed 544 on the specified parent interface."; 545 reference "RFC XXXX, Section 2.6 Sub-interface"; 546 } 548 /* 549 * Define common identities to help allow interface types to be 550 * assigned properties. 551 */ 552 identity sub-interface { 553 description 554 "Base type for generic sub-interfaces. 556 New or custom interface types can derive from this type to 557 inherit generic sub-interface configuration."; 558 reference "RFC XXXX, Section 2.6 Sub-interface"; 559 } 561 identity ethSubInterface{ 562 base ianaift:l2vlan; 563 base sub-interface; 564 description 565 "This identity represents the child sub-interface of any 566 interface types that uses Ethernet framing (with or without 567 802.1Q tagging)."; 568 } 570 identity loopback { 571 description "Base identity for interface loopback options"; 572 reference "RFC XXXX, Section 2.4"; 573 } 574 identity internal { 575 base loopback; 576 description 577 "All egress traffic on the interface is internally looped back 578 within the interface to be received on the ingress path."; 579 reference "RFC XXXX, Section 2.4"; 580 } 581 identity line { 582 base loopback; 583 description 584 "All ingress traffic received on the interface is internally 585 looped back within the interface to the egress path."; 586 reference "RFC XXXX, Section 2.4"; 587 } 588 identity connector { 589 base loopback; 590 description 591 "The interface has a physical loopback connector attached that 592 loops all egress traffic back into the interface's ingress 593 path, with equivalent semantics to loopback internal."; 594 reference "RFC XXXX, Section 2.4"; 595 } 597 identity forwarding-mode { 598 description "Base identity for forwarding-mode options."; 599 reference "RFC XXXX, Section 2.7"; 600 } 601 identity physical { 602 base forwarding-mode; 603 description 604 "Physical layer forwarding. This includes DWDM or OTN based 605 optical switching."; 606 reference "RFC XXXX, Section 2.7"; 607 } 608 identity data-link { 609 base forwarding-mode; 610 description 611 "Layer 2 based forwarding, such as Ethernet/VLAN based 612 switching, or L2VPN services."; 613 reference "RFC XXXX, Section 2.7"; 614 } 615 identity network { 616 base forwarding-mode; 617 description 618 "Network layer based forwarding, such as IP, MPLS, or L3VPNs."; 619 reference "RFC XXXX, Section 2.7"; 620 } 622 /* 623 * Augments the IETF interfaces model with leaves to configure 624 * and monitor carrier-delay on an interface. 625 */ 626 augment "/if:interfaces/if:interface" { 627 description 628 "Augments the IETF interface model with optional common 629 interface level commands that are not formally covered by any 630 specific standard."; 632 /* 633 * Defines standard YANG for the Carrier Delay feature. 634 */ 635 container carrier-delay { 636 if-feature "carrier-delay"; 637 description 638 "Holds carrier delay related feature configuration."; 639 leaf down { 640 type uint32; 641 units milliseconds; 642 description 643 "Delays the propagation of a 'loss of carrier signal' event 644 that would cause the interface state to go down, i.e. the 645 command allows short link flaps to be suppressed. The 646 configured value indicates the minimum time interval (in 647 milliseconds) that the carrier signal must be continuously 648 down before the interface state is brought down. If not 649 configured, the behaviour on loss of carrier signal is 650 vendor/interface specific, but with the general 651 expectation that there should be little or no delay."; 652 } 653 leaf up { 654 type uint32; 655 units milliseconds; 656 description 657 "Defines the minimum time interval (in milliseconds) that 658 the carrier signal must be continuously present and error 659 free before the interface state is allowed to transition 660 from down to up. If not configured, the behaviour is 661 vendor/interface specific, but with the general 662 expectation that sufficient default delay should be used 663 to ensure that the interface is stable when enabled before 664 being reported as being up. Configured values that are 665 too low for the hardware capabilties may be rejected."; 666 } 667 leaf carrier-transitions { 668 type yang:counter64; 669 units transitions; 670 config false; 671 description 672 "Defines the number of times the underlying carrier state 673 has changed to, or from, state up. This counter should be 674 incremented even if the high layer interface state changes 675 are being suppressed by a running carrier-delay timer."; 676 } 677 leaf timer-running { 678 type enumeration { 679 enum none { 680 description 681 "No carrier delay timer is running."; 682 } 683 enum up { 684 description 685 "Carrier-delay up timer is running. The underlying 686 carrier state is up, but interface state is not 687 reported as up."; 688 } 689 enum down { 690 description 691 "Carrier-delay down timer is running. Interface state 692 is reported as up, but the underlying carrier state is 693 actually down."; 694 } 695 } 696 config false; 697 description 698 "Reports whether a carrier delay timer is actively running, 699 in which case the interface state does not match the 700 underlying carrier state."; 701 } 703 reference "RFC XXXX, Section 2.1 Carrier Delay"; 704 } 705 /* 706 * Augments the IETF interfaces model with a container to hold 707 * generic interface dampening 708 */ 709 container dampening { 710 if-feature "dampening"; 711 presence 712 "Enable interface link flap dampening with default settings 713 (that are vendor/device specific)."; 714 description 715 "Interface dampening limits the propagation of interface link 716 state flaps over longer periods."; 717 reference "RFC XXXX, Section 2.2 Dampening"; 719 leaf half-life { 720 type uint32; 721 units seconds; 722 description 723 "The time (in seconds) after which a penalty would be half 724 its original value. Once the interface has been assigned 725 a penalty, the penalty is decreased at a decay rate 726 equivalent to the half-life. For some devices, the 727 allowed values may be restricted to particular multiples 728 of seconds. The default value is vendor/device 729 specific."; 730 reference "RFC XXXX, Section 2.3.2 Half-Life Period"; 731 } 733 leaf reuse { 734 type uint32; 735 description 736 "Penalty value below which a stable interface is 737 unsuppressed (i.e. brought up) (no units). The default 738 value is vendor/device specific. The penalty value for a 739 link up->down state change is 1000 units."; 740 reference "RFC XXXX, Section 2.2.3 Reuse Threshold"; 741 } 743 leaf suppress { 744 type uint32; 745 description 746 "Limit at which an interface is suppressed (i.e. held down) 747 when its penalty exceeds that limit (no units). The value 748 must be greater than the reuse threshold. The default 749 value is vendor/device specific. The penalty value for a 750 link up->down state change is 1000 units."; 751 reference "RFC XXXX, Section 2.2.1 Suppress Threshold"; 752 } 753 leaf max-suppress-time { 754 type uint32; 755 units seconds; 756 description 757 "Maximum time (in seconds) that an interface can be 758 suppressed before being unsuppressed if no further link 759 up->down state change penalties have been applied. This 760 value effectively acts as a ceiling that the penalty value 761 cannot exceed. The default value is vendor/device 762 specific."; 763 reference "RFC XXXX, Section 2.2.4 Maximum Suppress Time"; 764 } 766 leaf penalty { 767 type uint32; 768 config false; 769 description 770 "The current penalty value for this interface. When the 771 penalty value exceeds the 'suppress' leaf then the 772 interface is suppressed (i.e. held down)."; 773 reference "RFC XXXX, Section 2.2 Dampening"; 774 } 776 leaf suppressed { 777 type boolean; 778 config false; 779 description 780 "Represents whether the interface is suppressed (i.e. held 781 down) because the 'penalty' leaf value exceeds the 782 'suppress' leaf."; 783 reference "RFC XXXX, Section 2.2 Dampening"; 784 } 786 leaf time-remaining { 787 when '../suppressed = "true"' { 788 description 789 "Only suppressed interfaces have a time remaining."; 790 } 791 type uint32; 792 units seconds; 793 config false; 794 description 795 "For a suppressed interface, this leaf represents how long 796 (in seconds) that the interface will remain suppressed 797 before it is allowed to go back up again."; 798 reference "RFC XXXX, Section 2.2 Dampening"; 799 } 800 } 801 /* 802 * Various types of interfaces support a configurable layer 2 803 * encapsulation, any that are supported by YANG should be 804 * listed here. 805 * 806 * Different encapsulations can hook into the common encaps-type 807 * choice statement. 808 */ 809 container encapsulation { 810 when 811 "derived-from-or-self(../if:type, 812 'ianaift:ethernetCsmacd') or 813 derived-from-or-self(../if:type, 814 'ianaift:ieee8023adLag') or 815 derived-from-or-self(../if:type, 'ianaift:pos') or 816 derived-from-or-self(../if:type, 817 'ianaift:atmSubInterface') or 818 derived-from-or-self(../if:type, 'ianaift:l2vlan') or 819 derived-from-or-self(../if:type, 'ethSubInterface')" { 821 description 822 "All interface types that can have a configurable L2 823 encapsulation."; 824 } 826 description 827 "Holds the OSI layer 2 encapsulation associated with an 828 interface."; 829 choice encaps-type { 830 description 831 "Extensible choice of layer 2 encapsulations"; 832 reference "RFC XXXX, Section 2.3 Encapsulation"; 833 } 834 } 836 /* 837 * Various types of interfaces support loopback configuration, 838 * any that are supported by YANG should be listed here. 839 */ 840 leaf loopback { 841 when "derived-from-or-self(../if:type, 842 'ianaift:ethernetCsmacd') or 843 derived-from-or-self(../if:type, 'ianaift:sonet') or 844 derived-from-or-self(../if:type, 'ianaift:atm') or 845 derived-from-or-self(../if:type, 'ianaift:otnOtu')" { 846 description 847 "All interface types that support loopback configuration."; 848 } 849 if-feature "loopback"; 850 type identityref { 851 base loopback; 852 } 853 description "Enables traffic loopback."; 854 reference "RFC XXXX, Section 2.4 Loopback"; 855 } 857 /* 858 * Allows the maximum frame size to be configured or reported. 859 */ 860 leaf max-frame-size { 861 if-feature "max-frame-size"; 862 type uint32 { 863 range "64 .. max"; 864 } 865 description 866 "The maximum size of layer 2 frames that may be transmitted 867 or received on the interface (including any frame header, 868 maximum frame payload size, and frame checksum sequence). 870 If configured, the max-frame-size also limits the maximum 871 frame size of any child sub-interfaces. The MTU available 872 to higher layer protocols is restricted to the maximum frame 873 payload size, and MAY be further restricted by explicit 874 layer 3 or protocol specific MTU configuration."; 876 reference "RFC XXXX, Section 2.5 Maximum Frame Size"; 877 } 879 /* 880 * Augments the IETF interfaces model with a leaf that indicates 881 * which mode, or layer, is being used to forward the traffic. 882 */ 883 leaf forwarding-mode { 884 type identityref { 885 base forwarding-mode; 886 } 887 config false; 889 description 890 "The forwarding mode that the interface is operating in."; 891 reference "RFC XXXX, Section 2.7 Forwarding Mode"; 892 } 893 } 895 /* 896 * Add generic support for sub-interfaces. 898 * 899 * This should be extended to cover all interface types that are 900 * child interfaces of other interfaces. 901 */ 902 augment "/if:interfaces/if:interface" { 903 when "derived-from(if:type, 'sub-interface') or 904 derived-from-or-self(if:type, 'ianaift:l2vlan') or 905 derived-from-or-self(if:type, 'ianaift:atmSubInterface') or 906 derived-from-or-self(if:type, 'ianaift:frameRelay')" { 907 description 908 "Any ianaift:types that explicitly represent sub-interfaces 909 or any types that derive from the sub-interface identity."; 910 } 911 if-feature "sub-interfaces"; 913 description 914 "Adds a parent interface field to interfaces that model 915 sub-interfaces."; 916 leaf parent-interface { 918 type if:interface-ref; 920 mandatory true; 921 description 922 "This is the reference to the parent interface of this 923 sub-interface."; 924 reference "RFC XXXX, Section 2.6 Sub-interface"; 925 } 926 } 928 /* 929 * Add discard counter for unknown sub-interface encapsulation 930 */ 931 augment "/if:interfaces/if:interface/if:statistics" { 932 when "derived-from-or-self(../if:type, 933 'ianaift:ethernetCsmacd') or 934 derived-from-or-self(../if:type, 935 'ianaift:ieee8023adLag') or 936 derived-from-or-self(../if:type, 'ianaift:ifPwType')" { 937 description 938 "Applies to interfaces that can demultiplex ingress frames to 939 sub-interfaces."; 940 } 941 if-feature "sub-interfaces"; 943 description 944 "Augment the interface model statistics with a sub-interface 945 demux discard counter."; 947 leaf in-discard-unknown-encaps { 948 type yang:counter64; 949 units frames; 950 description 951 "A count of the number of frames that were well formed, but 952 otherwise discarded because their encapsulation does not 953 classify the frame to the interface or any child 954 sub-interface. E.g., a frame might be discarded because the 955 it has an unknown VLAN Id, or does not have a VLAN Id when 956 one is expected. 958 For consistency, frames counted against this counter are 959 also counted against the IETF interfaces statistics. In 960 particular, they are included in in-octets and in-discards, 961 but are not included in in-unicast-pkts, in-multicast-pkts 962 or in-broadcast-pkts, because they are not delivered to a 963 higher layer. 965 Discontinuities in the values of this counter can occur at 966 re-initialization of the management system, and at other 967 times as indicated by the value of the 'discontinuity-time' 968 leaf defined in the ietf-interfaces YANG module 969 (RFC 8343)."; 970 } 971 } 972 } 973 975 5. Interfaces Ethernet-Like YANG Module 977 This YANG module augments the interface container defined in RFC 8343 978 [RFC8343] for Ethernet-like interfaces. This includes Ethernet 979 interfaces, 802.3 LAG (802.1AX) interfaces, Switch Virtual 980 interfaces, and Pseudo-Wire Head-End interfaces. It also contains 981 references to [RFC6991], [RFC7224], and [IEEE802.3.2-2019]. 983 file "ietf-if-ethernet-like@2019-11-04.yang" 984 module ietf-if-ethernet-like { 985 yang-version 1.1; 987 namespace 988 "urn:ietf:params:xml:ns:yang:ietf-if-ethernet-like"; 990 prefix ethlike; 992 import ietf-interfaces { 993 prefix if; 994 reference 995 "RFC 8343: A YANG Data Model For Interface Management"; 996 } 998 import ietf-yang-types { 999 prefix yang; 1000 reference "RFC 6991: Common YANG Data Types"; 1001 } 1003 import iana-if-type { 1004 prefix ianaift; 1005 reference "RFC 7224: IANA Interface Type YANG Module"; 1006 } 1008 organization 1009 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1011 contact 1012 "WG Web: 1013 WG List: 1015 Editor: Robert Wilton 1016 "; 1018 description 1019 "This module contains YANG definitions for configuration for 1020 'Ethernet-like' interfaces. It is applicable to all interface 1021 types that use Ethernet framing and expose an Ethernet MAC 1022 layer, and includes such interfaces as physical Ethernet 1023 interfaces, Ethernet LAG interfaces and VLAN sub-interfaces. 1025 Additional interface configuration and counters for physical 1026 Ethernet interfaces are defined in 1027 ieee802-ethernet-interface.yang, as part of IEEE Std 1028 802.3.2-2019. 1030 Copyright (c) 2019 IETF Trust and the persons identified as 1031 authors of the code. All rights reserved. 1033 Redistribution and use in source and binary forms, with or 1034 without modification, is permitted pursuant to, and subject to 1035 the license terms contained in, the Simplified BSD License set 1036 forth in Section 4.c of the IETF Trust's Legal Provisions 1037 Relating to IETF Documents 1038 (https://trustee.ietf.org/license-info). 1040 This version of this YANG module is part of RFC XXXX 1041 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 1042 for full legal notices."; 1044 revision 2019-11-04 { 1045 description "Initial revision."; 1047 reference 1048 "RFC XXXX, Common Interface Extension YANG Data Models"; 1049 } 1051 feature configurable-mac-address { 1052 description 1053 "This feature indicates that MAC addresses on Ethernet-like 1054 interfaces can be configured."; 1055 reference 1056 "RFC XXXX, Section 3, Interfaces Ethernet-Like Module"; 1057 } 1059 /* 1060 * Configuration parameters for Ethernet-like interfaces. 1061 */ 1062 augment "/if:interfaces/if:interface" { 1063 when "derived-from-or-self(if:type, 'ianaift:ethernetCsmacd') or 1064 derived-from-or-self(if:type, 'ianaift:ieee8023adLag') or 1065 derived-from-or-self(if:type, 'ianaift:ifPwType')" { 1066 description "Applies to all Ethernet-like interfaces"; 1067 } 1068 description 1069 "Augment the interface model with parameters for all 1070 Ethernet-like interfaces."; 1072 container ethernet-like { 1073 description 1074 "Contains parameters for interfaces that use Ethernet framing 1075 and expose an Ethernet MAC layer."; 1077 leaf mac-address { 1078 if-feature "configurable-mac-address"; 1079 type yang:mac-address; 1080 description 1081 "The MAC address of the interface. The operational value 1082 matches the /if:interfaces/if:interface/if:phys-address 1083 leaf defined in ietf-interface.yang."; 1084 } 1086 leaf bia-mac-address { 1087 type yang:mac-address; 1088 config false; 1089 description 1090 "The 'burnt-in' MAC address. I.e the default MAC address 1091 assigned to the interface if no MAC address has been 1092 explicitly configured on it."; 1093 } 1094 } 1095 } 1097 /* 1098 * Configuration parameters for Ethernet-like interfaces. 1099 */ 1100 augment "/if:interfaces/if:interface/if:statistics" { 1101 when "derived-from-or-self(../if:type, 1102 'ianaift:ethernetCsmacd') or 1103 derived-from-or-self(../if:type, 1104 'ianaift:ieee8023adLag') or 1105 derived-from-or-self(../if:type, 'ianaift:ifPwType')" { 1106 description "Applies to all Ethernet-like interfaces"; 1107 } 1108 description 1109 "Augment the interface model statistics with additional 1110 counters related to Ethernet-like interfaces."; 1112 leaf in-discard-unknown-dest-mac-pkts { 1113 type yang:counter64; 1114 units frames; 1115 description 1116 "A count of the number of frames that were well formed, but 1117 otherwise discarded because the destination MAC address did 1118 not pass any ingress destination MAC address filter. 1120 For consistency, frames counted against this counter are 1121 also counted against the IETF interfaces statistics. In 1122 particular, they are included in in-octets and in-discards, 1123 but are not included in in-unicast-pkts, in-multicast-pkts 1124 or in-broadcast-pkts, because they are not delivered to a 1125 higher layer. 1127 Discontinuities in the values of this counter can occur at 1128 re-initialization of the management system, and at other 1129 times as indicated by the value of the 'discontinuity-time' 1130 leaf defined in the ietf-interfaces YANG module 1131 (RFC 8343)."; 1132 } 1133 } 1134 } 1135 1137 6. Examples 1139 The following sections give some examples of how different parts of 1140 the YANG modules could be used. Examples are not given for the more 1141 trivial configuration, or for sub-interfaces, for which examples are 1142 contained in [I-D.ietf-netmod-sub-intf-vlan-model]. 1144 6.1. Carrier delay configuration 1146 The following example shows how the operational state datastore could 1147 look like for an Ethernet interface without any carrier delay 1148 configuration. The down leaf value of 0 indicates that link down 1149 events as always propagated to high layers immediately, but an up 1150 leaf value of 50 indicates that the interface must be up and stable 1151 for at least 50 msecs before the interface is reported as being up to 1152 the high layers. 1154 1155 1159 1160 eth0 1161 ianaift:ethernetCsmacd 1162 1163 0 1164 50 1165 1166 1167 1169 The following example shows explicit carrier delay up and down values 1170 have been configured. A 50 msec down leaf value has been used to 1171 potentially allow optical protection to recover the link before the 1172 higher layer protocol state is flapped. A 1 second (1000 1173 milliseconds) up leaf value has been used to ensure that the link is 1174 always reasonably stable before allowing traffic to be carried over 1175 it. This also has the benefit of greatly reducing the rate at which 1176 higher layer protocol state flaps could occur. 1178 1179 1180 1184 1185 eth0 1186 ianaift:ethernetCsmacd 1187 1188 50 1189 1000 1190 1191 1192 1193 1195 6.2. Dampening configuration 1197 The following example shows what the operational state datastore may 1198 look like for an interface configured with interface dampening. The 1199 'suppressed' leaf indicates that the interface is currently 1200 suppressed (i.e. down) because the 'penalty' is greater than the 1201 'suppress' leaf threshold. The 'time-remaining' leaf indicates that 1202 the interface will remain suppressed for another 103 seconds before 1203 the 'penalty' is below the 'reuse' leaf value and the interface is 1204 allowed to go back up again. 1206 1207 1210 1211 eth0 1212 ianaift:ethernetCsmacd 1213 down 1214 1216 60 1217 750 1218 2000 1219 240 1220 2480 1221 true 1222 103 1223 1224 1225 1227 6.3. MAC address configuration 1229 The following example shows how the operational state datastore could 1230 look like for an Ethernet interface without an explicit MAC address 1231 configured. The mac-address leaf always reports the actual 1232 operational MAC address that is in use. The bia-mac-address leaf 1233 always reports the default MAC address assigned to the hardware. 1235 1236 1239 1240 eth0 1241 ianaift:ethernetCsmacd 1242 00:00:5E:00:53:30 1243 1245 00:00:5E:00:53:30 1246 00:00:5E:00:53:30 1247 1248 1249 1251 The following example shows the intended configuration for interface 1252 eth0 with an explicit MAC address configured. 1254 1255 1256 1259 1260 eth0 1261 ianaift:ethernetCsmacd 1262 1264 00:00:5E:00:53:35 1265 1266 1267 1268 1270 After the MAC address configuration has been successfully applied, 1271 the operational state datastore reporting the interface MAC address 1272 properties would contain the following, with the mac-address leaf 1273 updated to match the configured value, but the bia-mac-address leaf 1274 retaining the same value - which should never change. 1276 1277 1280 1281 eth0 1282 ianaift:ethernetCsmacd 1283 00:00:5E:00:53:35 1284 1286 00:00:5E:00:53:35 1287 00:00:5E:00:53:30 1288 1289 1290 1292 7. Acknowledgements 1294 The authors wish to thank Eric Gray, Ing-Wher Chen, Jon Culver, 1295 Juergen Schoenwaelder, Ladislav Lhotka, Lou Berger, Mahesh 1296 Jethanandani, Martin Bjorklund, Michael Zitao, Neil Ketley, Qin Wu, 1297 William Lupton, Xufeng Liu, Andy Bierman, and Vladimir Vassilev for 1298 their helpful comments contributing to this document. 1300 8. ChangeLog 1302 XXX, RFC Editor, please delete this change log before publication. 1304 8.1. Version -10 1306 o Update modules from github and tree diagram. 1308 8.2. Version -09 1310 o Fixed IANA section. 1312 8.3. Version -08 1314 o Initial updates after WG LC comments. 1316 8.4. Version -07 1318 o Minor editorial updates 1320 8.5. Version -06 1322 o Remove reservable-bandwidth, based on Acee's suggestion 1324 o Add examples 1326 o Add additional state parameters for carrier-delay and dampening 1328 8.6. Version -05 1330 o Incorporate feedback from Andy Bierman 1332 8.7. Version -04 1334 o Incorporate feedback from Lada, some comments left as open issues. 1336 8.8. Version -03 1338 o Fixed incorrect module name references, and updated tree output 1340 8.9. Version -02 1342 o Minor changes only: Fix errors in when statements, use derived- 1343 from-or-self() for future proofing. 1345 9. IANA Considerations 1347 9.1. YANG Module Registrations 1349 The following YANG modules are requested to be registred in the IANA 1350 "YANG Module Names" [RFC6020] registry: 1352 The ietf-if-extensions module: 1354 Name: ietf-if-extensions 1356 XML Namespace: urn:ietf:params:xml:ns:yang:ietf-if-extensions 1358 Prefix: if-ext 1360 Reference: [RFCXXXX] 1362 The ietf-if-ethernet-like module: 1364 Name: ietf-if-ethernet-like 1366 XML Namespace: urn:ietf:params:xml:ns:yang:ietf-if-ethernet-like 1368 Prefix: ethlike 1370 Reference: [RFCXXXX] 1372 This document registers two URIs in the "IETF XML Registry" 1373 [RFC3688]. Following the format in RFC 3688, the following 1374 registrations have been made. 1376 URI: urn:ietf:params:xml:ns:yang:ietf-if-extensions 1378 Registrant Contact: The IESG. 1380 XML: N/A, the requested URI is an XML namespace. 1382 URI: urn:ietf:params:xml:ns:yang:ietf-if-ethernet-like 1383 Registrant Contact: The IESG. 1385 XML: N/A, the requested URI is an XML namespace. 1387 10. Security Considerations 1389 The YANG module defined in this memo is designed to be accessed via 1390 the NETCONF protocol RFC 6241 [RFC6241]. The lowest NETCONF layer is 1391 the secure transport layer and the mandatory to implement secure 1392 transport is SSH RFC 6242 [RFC6242]. The NETCONF access control 1393 model RFC 6536 [RFC6536] provides the means to restrict access for 1394 particular NETCONF users to a pre-configured subset of all available 1395 NETCONF protocol operations and content. 1397 There are a number of data nodes defined in this YANG module which 1398 are writable/creatable/deletable (i.e. config true, which is the 1399 default). These data nodes may be considered sensitive or vulnerable 1400 in some network environments. Write operations (e.g. edit-config) to 1401 these data nodes without proper protection can have a negative effect 1402 on network operations. These are the subtrees and data nodes and 1403 their sensitivity/vulnerability: 1405 10.1. ietf-if-extensions.yang 1407 The ietf-if-extensions YANG module contains various configuration 1408 leaves that affect the behavior of interfaces. Modifying these 1409 leaves can cause an interface to go down, or become unreliable, or to 1410 drop traffic forwarded over it. More specific details of the 1411 possible failure modes are given below. 1413 The following leaf could cause the interface to go down and stop 1414 processing any ingress or egress traffic on the interface. It could 1415 also cause broadcast traffic storms. 1417 o /if:interfaces/if:interface/loopback 1419 The following leaves could cause instabilities at the interface link 1420 layer, and cause unwanted higher layer routing path changes if the 1421 leaves are modified, although they would generally only affect a 1422 device that had some underlying link stability issues: 1424 o /if:interfaces/if:interface/carrier-delay/down 1426 o /if:interfaces/if:interface/carrier-delay/up 1428 o /if:interfaces/if:interface/dampening/half-life 1430 o /if:interfaces/if:interface/dampening/reuse 1431 o /if:interfaces/if:interface/dampening/suppress 1433 o /if:interfaces/if:interface/dampening/max-suppress-time 1435 The following leaves could cause traffic loss on the interface 1436 because the received or transmitted frames do not comply with the 1437 frame matching criteria on the interface and hence would be dropped: 1439 o /if:interfaces/if:interface/encapsulation 1441 o /if:interfaces/if:interface/max-frame-size 1443 o /if:interfaces/if:interface/forwarding-mode 1445 Changing the parent-interface leaf could cause all traffic on the 1446 affected interface to be dropped. The affected leaf is: 1448 o /if:interfaces/if:interface/parent-interface 1450 10.2. ietf-if-ethernet-like.yang 1452 Generally, the configuration nodes in the ietf-if-ethernet-like YANG 1453 module are concerned with configuration that is common across all 1454 types of Ethernet-like interfaces. The module currently only 1455 contains a node for configuring the operational MAC address to use on 1456 an interface. Adding/modifying/deleting this leaf has the potential 1457 risk of causing protocol instability, excessive protocol traffic, and 1458 general traffic loss, particularly if the configuration change caused 1459 a duplicate MAC address to be present on the local network . The 1460 following leaf is affected: 1462 o interfaces/interface/ethernet-like/mac-address 1464 11. References 1466 11.1. Normative References 1468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1469 Requirement Levels", BCP 14, RFC 2119, 1470 DOI 10.17487/RFC2119, March 1997, 1471 . 1473 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1474 DOI 10.17487/RFC3688, January 2004, 1475 . 1477 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1478 the Network Configuration Protocol (NETCONF)", RFC 6020, 1479 DOI 10.17487/RFC6020, October 2010, 1480 . 1482 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1483 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1484 . 1486 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1487 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1488 May 2017, . 1490 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1491 and R. Wilton, "Network Management Datastore Architecture 1492 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1493 . 1495 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1496 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1497 . 1499 11.2. Informative References 1501 [I-D.ietf-netmod-sub-intf-vlan-model] 1502 Wilton, R., Ball, D., tapsingh@cisco.com, t., and S. 1503 Sivaraj, "Sub-interface VLAN YANG Data Models", draft- 1504 ietf-netmod-sub-intf-vlan-model-07 (work in progress), 1505 July 2020. 1507 [IEEE802.3.2-2019] 1508 IEEE WG802.3 - Ethernet Working Group, "IEEE 1509 802.3.2-2019", 2019. 1511 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1512 and A. Bierman, Ed., "Network Configuration Protocol 1513 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1514 . 1516 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1517 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1518 . 1520 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1521 Protocol (NETCONF) Access Control Model", RFC 6536, 1522 DOI 10.17487/RFC6536, March 2012, 1523 . 1525 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1526 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1527 . 1529 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1530 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1531 . 1533 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1534 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1535 . 1537 Authors' Addresses 1539 Robert Wilton (editor) 1540 Cisco Systems 1542 Email: rwilton@cisco.com 1544 David Ball 1545 Cisco Systems 1547 Email: daviball@cisco.com 1549 Tapraj Singh 1550 Cisco Systems 1552 Email: tapsingh@cisco.com 1554 Selvakumar Sivaraj 1555 Juniper Networks 1557 Email: ssivaraj@juniper.net