idnits 2.17.1 draft-ietf-netmod-intf-ext-yang-08.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 208 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 (November 4, 2019) is 1635 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) == Unused Reference: 'IEEE802.3.2' is defined on line 1398, but no explicit reference was found in the text == Unused Reference: 'RFC6991' is defined on line 1416, but no explicit reference was found in the text == Unused Reference: 'RFC7224' is defined on line 1420, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-netmod-sub-intf-vlan-model-05 -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 0 errors (**), 0 flaws (~~), 7 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: May 7, 2020 Cisco Systems 6 S. Sivaraj 7 Juniper Networks 8 November 4, 2019 10 Common Interface Extension YANG Data Models 11 draft-ietf-netmod-intf-ext-yang-08 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 May 7, 2020. 40 Copyright Notice 42 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . 20 75 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 24 76 6.1. Carrier delay configuration . . . . . . . . . . . . . . . 24 77 6.2. Dampening configuration . . . . . . . . . . . . . . . . . 25 78 6.3. MAC address configuration . . . . . . . . . . . . . . . . 26 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 80 8. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 28 81 8.1. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 28 82 8.2. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 28 83 8.3. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 28 84 8.4. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 28 85 8.5. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 28 86 8.6. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 28 87 8.7. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 28 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 89 10. Security Considerations . . . . . . . . . . . . . . . . . . . 29 90 10.1. ietf-if-extensions.yang . . . . . . . . . . . . . . . . 29 91 10.2. ietf-if-ethernet-like.yang . . . . . . . . . . . . . . . 30 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 93 11.1. Normative References . . . . . . . . . . . . . . . . . . 30 94 11.2. Informative References . . . . . . . . . . . . . . . . . 31 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 97 1. Introduction 99 This document defines two NMDA compatible [RFC8342] YANG 1.1 100 [RFC7950] modules for the management of network interfaces. It 101 defines various augmentations to the generic interfaces data model 102 [RFC8343] to support configuration of lower layer interface 103 properties that are common across many types of network interface. 105 One of the aims of this document is to provide a standard definition 106 for these configuration items regardless of the underlying interface 107 type. For example, a definition for configuring or reading the MAC 108 address associated with an interface is provided that can be used for 109 any interface type that uses Ethernet framing. 111 Several of the augmentations defined here are not backed by any 112 formal standard specification. Instead, they are for features that 113 are commonly implemented in equivalent ways by multiple independent 114 network equipment vendors. The aim of this document is to define 115 common paths and leaves for the configuration of these equivalent 116 features in a uniform way, making it easier for users of the YANG 117 model to access these features in a vendor independent way. Where 118 necessary, a description of the expected behavior is also provided 119 with the aim of ensuring vendors implementations are consistent with 120 the specified behaviour. 122 Given that the modules contain a collection of discrete features with 123 the common theme that they generically apply to interfaces, it is 124 plausible that not all implementors of the YANG module will decide to 125 support all features. Hence separate feature keywords are defined 126 for each logically discrete feature to allow implementors the 127 flexibility to choose which specific parts of the model they support. 129 The augmentations are split into two separate YANG modules that each 130 focus on a particular area of functionality. The two YANG modules 131 defined in this document are: 133 ietf-if-extensions.yang - Defines extensions to the IETF interface 134 data model to support common configuration data nodes. 136 ietf-if-ethernet-like.yang - Defines a module for any 137 configuration and operational data nodes that are common across 138 interfaces that use Ethernet framing. 140 1.1. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in BCP 145 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 146 appear in all capitals, as shown here. 148 1.2. Tree Diagrams 150 Tree diagrams used in this document follow the notation defined in 151 [RFC8340]. 153 2. Interface Extensions Module 155 The Interfaces Extensions YANG module provides some basic extensions 156 to the IETF interfaces YANG module. 158 The module provides: 160 o A carrier delay feature used to provide control over short lived 161 link state flaps. 163 o An interface link state dampening feature that is used to provide 164 control over longer lived link state flaps. 166 o An encapsulation container and extensible choice statement for use 167 by any interface types that allow for configurable L2 168 encapsulations. 170 o A loopback configuration leaf that is primarily aimed at loopback 171 at the physical layer. 173 o MTU configuration leaves applicable to all packet/frame based 174 interfaces. 176 o A forwarding mode leaf to indicate the OSI layer at which the 177 interface handles traffic. 179 o A generic "sub-interface" identity that an interface identity 180 definition can derive from if it defines a sub-interface. 182 o A parent interface leaf useable for all types of sub-interface 183 that are children of parent interfaces. 185 The "ietf-if-extensions" YANG module has the following structure: 187 module: ietf-if-extensions 188 augment /if:interfaces/if:interface: 189 +--rw carrier-delay {carrier-delay}? 190 | +--rw down? uint32 191 | +--rw up? uint32 192 | +--ro carrier-transitions? yang:counter64 193 | +--ro timer-running? enumeration 194 +--rw dampening! {dampening}? 195 | +--rw half-life? uint32 196 | +--rw reuse? uint32 197 | +--rw suppress? uint32 198 | +--rw max-suppress-time? uint32 199 | +--ro penalty? uint32 200 | +--ro suppressed? boolean 201 | +--ro time-remaining? uint32 202 +--rw encapsulation 203 | +--rw (encaps-type)? 204 +--rw loopback? identityref {loopback}? 205 +--rw max-frame-size? uint32 {max-frame-size}? 206 +--ro forwarding-mode? identityref 207 augment /if:interfaces/if:interface: 208 +--rw parent-interface if:interface-ref {sub-interfaces}? 210 2.1. Carrier Delay 212 The carrier delay feature augments the IETF interfaces data model 213 with configuration for a simple algorithm that is used, generally on 214 physical interfaces, to suppress short transient changes in the 215 interface link state. It can be used in conjunction with the 216 dampening feature described in Section 2.2 to provide effective 217 control of unstable links and unwanted state transitions. 219 The principle of the carrier delay feature is to use a short per 220 interface timer to ensure that any interface link state transition 221 that occurs and reverts back within the specified time interval is 222 entirely suppressed without providing any signalling to any upper 223 layer protocols that the state transition has occurred. E.g. in the 224 case that the link state transition is suppressed then there is no 225 change of the /if:interfaces/if:interface/oper-status or 226 /if:interfaces/if:interfaces/last-change leaves for the interface 227 that the feature is operating on. One obvious side effect of using 228 this feature that is that any state transition will always be delayed 229 by the specified time interval. 231 The configuration allows for separate timer values to be used in the 232 suppression of down->up->down link transitions vs up->down->up link 233 transitions. 235 The carrier delay down timer leaf specifies the amount of time that 236 an interface that is currently in link up state must be continuously 237 down before the down state change is reported to higher level 238 protocols. Use of this timer can cause traffic to be black holed for 239 the configured value and delay reconvergence after link failures, 240 therefore its use is normally restricted to cases where it is 241 necessary to allow enough time for another protection mechanism (such 242 as an optical layer automatic protection system) to take effect. 244 The carrier delay up timer leaf specifies the amount of time that an 245 interface that is currently in link down state must be continuously 246 up before the down->up link state transition is reported to higher 247 level protocols. This timer is generally useful as a debounce 248 mechanism to ensure that a link is relatively stable before being 249 brought into service. It can also be used effectively to limit the 250 frequency at which link state transition events may occur. The 251 default value for this leaf is determined by the underlying network 252 device. 254 2.2. Dampening 256 The dampening feature introduces a configurable exponential decay 257 mechanism to suppress the effects of excessive interface link state 258 flapping. This feature allows the network operator to configure a 259 device to automatically identify and selectively dampen a local 260 interface which is flapping. Dampening an interface keeps the 261 interface operationally down until the interface stops flapping and 262 becomes stable. Configuring the dampening feature can improve 263 convergence times and stability throughout the network by isolating 264 failures so that disturbances are not propagated, which reduces the 265 utilization of system processing resources by other devices in the 266 network and improves overall network stability. 268 The basic algorithm uses a counter that is increased by 1000 units 269 every time the underlying interface link state changes from up to 270 down. If the counter increases above the suppress threshold then the 271 interface is kept down (and out of service) until either the maximum 272 suppression time is reached, or the counter has reduced below the 273 reuse threshold. The half-life period determines that rate at which 274 the counter is periodically reduced by half. 276 2.2.1. Suppress Threshold 278 The suppress threshold is the value of the accumulated penalty that 279 triggers the device to dampen a flapping interface. The flapping 280 interface is identified by the device and assigned a penalty for each 281 up to down link state change, but the interface is not automatically 282 dampened. The device tracks the penalties that a flapping interface 283 accumulates. When the accumulated penalty reaches or exceeds the 284 suppress threshold, the interface is placed in a suppressed state. 286 2.2.2. Half-Life Period 288 The half-life period determines how fast the accumulated penalties 289 can decay exponentially. The accumulated penalty decays at a rate 290 that causes its value to be reduced by half after each half-life 291 period. 293 2.2.3. Reuse Threshold 295 If, after one or more half-life periods, the accumulated penalty 296 decreases below the reuse threshold and the underlying interface link 297 state is up then the interface is taken out of suppressed state and 298 is allowed to go up. 300 2.2.4. Maximum Suppress Time 302 The maximum suppress time represents the maximum amount of time an 303 interface can remain dampened when a new penalty is assigned to an 304 interface. The default of the maximum suppress timer is four times 305 the half-life period. The maximum value of the accumulated penalty 306 is calculated using the maximum suppress time, reuse threshold and 307 half-life period. 309 2.3. Encapsulation 311 The encapsulation container holds a choice node that is to be 312 augmented with datalink layer specific encapsulations, such as HDLC, 313 PPP, or sub-interface 802.1Q tag match encapsulations. The use of a 314 choice statement ensures that an interface can only have a single 315 datalink layer protocol configured. 317 The different encapsulations themselves are defined in separate YANG 318 modules defined in other documents that augument the encapsulation 319 choice statement. For example the Ethernet specific basic 'dot1q- 320 vlan' encapsulation is defined in ietf-if-l3-vlan.yang and the 321 'flexible' encapsulation is defined in ietf-flexible- 322 encapsulation.yang, both modules from 323 [I-D.ietf-netmod-sub-intf-vlan-model]. 325 2.4. Loopback 327 The loopback configuration leaf allows any physical interface to be 328 configured to be in one of the possible following physical loopback 329 modes, i.e. internal loopback, line loopback, or use of an external 330 loopback connector. The use of YANG identities allows for the model 331 to be extended with other modes of loopback if required. 333 The following loopback modes are defined: 335 o Internal loopback - All egress traffic on the interface is 336 internally looped back within the interface to be received on the 337 ingress path. 339 o Line loopback - All ingress traffic received on the interface is 340 internally looped back within the interface to the egress path. 342 o Loopback Connector - The interface has a physical loopback 343 connector attached that loops all egress traffic back into the 344 interface's ingress path, with equivalent semantics to internal 345 loopback. 347 2.5. Maximum frame size 349 A maximum frame size configuration leaf (max-frame-size) is provided 350 to specify the maximum size of a layer 2 frame that may be 351 transmitted or received on an interface. The value includes the 352 overhead of any layer 2 header, the maximum length of the payload, 353 and any frame check sequence (FCS) bytes. If configured, the max- 354 frame-size leaf on an interface also restricts the max-frame-size of 355 any child sub-interfaces, and the available MTU for protocols. 357 2.6. Sub-interface 359 The sub-interface feature specifies the minimal leaves required to 360 define a child interface that is parented to another interface. 362 A sub-interface is a logical interface that handles a subset of the 363 traffic on the parent interface. Separate configuration leaves are 364 used to classify the subset of ingress traffic received on the parent 365 interface to be processed in the context of a given sub-interface. 366 All egress traffic processed on a sub-interface is given to the 367 parent interface for transmission. Otherwise, a sub-interface is 368 like any other interface in /if:interfaces and supports the standard 369 interface features and configuration. 371 For some vendor specific interface naming conventions the name of the 372 child interface is sufficient to determine the parent interface, 373 which implies that the child interface can never be reparented to a 374 different parent interface after it has been created without deleting 375 the existing sub-interface and recreating a new sub-interface. Even 376 in this case it is useful to have a well defined leaf to cleanly 377 identify the parent interface. 379 The model also allows for arbitrarily named sub-interfaces by having 380 an explicit parent-interface leaf define the child -> parent 381 relationship. In this naming scenario it is also possible for 382 implementations to allow for logical interfaces to be reparented to 383 new parent interfaces without needing the sub-interface to be 384 destroyed and recreated. 386 2.7. Forwarding Mode 388 The forwarding mode leaf provides additional information as to what 389 mode or layer an interface is logically operating and forwarding 390 traffic at. The implication of this leaf is that for traffic 391 forwarded at a given layer that any headers for lower layers are 392 stripped off before the packet is forwarded at the given layer. 393 Conversely, on egress any lower layer headers must be added to the 394 packet before it is transmitted out of the interface. 396 The following forwarding modes are defined: 398 o Physical - Traffic is being forwarded at the physical layer. This 399 includes DWDM or OTN based switching. 401 o Data-link - Layer 2 based forwarding, such as Ethernet/VLAN based 402 switching, or L2VPN services. 404 o Network - Network layer based forwarding, such as IP, MPLS, or 405 L3VPNs. 407 3. Interfaces Ethernet-Like Module 409 The Interfaces Ethernet-Like Module is a small module that contains 410 all configuration and operational data that is common across 411 interface types that use Ethernet framing as their datalink layer 412 encapsulation. 414 This module currently contains leaves for the configuration and 415 reporting of the operational MAC address and the burnt-in MAC address 416 (BIA) associated with any interface using Ethernet framing. 418 The "ietf-if-ethernet-like" YANG module has the following structure: 420 module: ietf-if-ethernet-like 421 augment /if:interfaces/if:interface: 422 +--rw ethernet-like 423 +--rw mac-address? yang:mac-address 424 | {configurable-mac-address}? 425 +--ro bia-mac-address? yang:mac-address 426 augment /if:interfaces/if:interface/if:statistics: 427 +--ro in-drop-unknown-dest-mac-pkts? yang:counter64 429 4. Interface Extensions YANG Module 431 This YANG module augments the interface container defined in RFC 8343 432 [RFC8343]. 434 file "ietf-if-extensions@2019-11-04.yang" 435 module ietf-if-extensions { 436 yang-version 1.1; 438 namespace "urn:ietf:params:xml:ns:yang:ietf-if-extensions"; 440 prefix if-ext; 442 import ietf-yang-types { 443 prefix yang; 444 reference "RFC 6991: Common YANG Data Types"; 445 } 447 import ietf-interfaces { 448 prefix if; 449 reference 450 "RFC 8343: A YANG Data Model For Interface Management"; 451 } 453 import iana-if-type { 454 prefix ianaift; 455 reference "RFC 7224: IANA Interface Type YANG Module"; 456 } 458 organization 459 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 461 contact 462 "WG Web: 463 WG List: 465 Editor: Robert Wilton 466 "; 468 description 469 "This module contains common definitions for extending the IETF 470 interface YANG model (RFC 8343) with common configurable layer 2 471 properties. 473 Copyright (c) 2019 IETF Trust and the persons identified as 474 authors of the code. All rights reserved. 476 Redistribution and use in source and binary forms, with or 477 without modification, is permitted pursuant to, and subject to 478 the license terms contained in, the Simplified BSD License set 479 forth in Section 4.c of the IETF Trust's Legal Provisions 480 Relating to IETF Documents 481 (https://trustee.ietf.org/license-info). 483 This version of this YANG module is part of RFC XXXX 484 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 485 for full legal notices. 487 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 488 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 489 'MAY', and 'OPTIONAL' in this document are to be interpreted as 490 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 491 they appear in all capitals, as shown here."; 493 revision 2019-11-04 { 494 description 495 "Initial revision."; 497 reference 498 "RFC XXX, Common Interface Extension YANG Data Models"; 499 } 501 feature carrier-delay { 502 description 503 "This feature indicates that configurable interface 504 carrier delay is supported, which is a feature is used to 505 limit the propagation of very short interface link state 506 flaps."; 507 reference "RFC XXX, Section 2.1 Carrier Delay"; 508 } 510 feature dampening { 511 description 512 "This feature indicates that the device supports interface 513 dampening, which is a feature that is used to limit the 514 propagation of interface link state flaps over longer 515 periods."; 516 reference "RFC XXX, Section 2.2 Dampening"; 517 } 519 feature loopback { 520 description 521 "This feature indicates that configurable interface loopback 522 is supported."; 523 reference "RFC XXX, Section 2.4 Loopback"; 524 } 526 feature max-frame-size { 527 description 528 "This feature indicates that the device supports configuring 529 or reporting the maximum frame size on interfaces."; 530 reference "RFC XXX, Section 2.5 Maximum Frame Size"; 531 } 533 feature sub-interfaces { 534 description 535 "This feature indicates that the device supports the 536 instantiation of sub-interfaces. Sub-interfaces are defined 537 as logical child interfaces that allow features and forwarding 538 decisions to be applied to a subset of the traffic processed 539 on the specified parent interface."; 540 reference "RFC XXX, Section 2.6 Sub-interface"; 541 } 543 /* 544 * Define common identities to help allow interface types to be 545 * assigned properties. 546 */ 547 identity sub-interface { 548 description 549 "Base type for generic sub-interfaces. 551 New or custom interface types can derive from this type to 552 inherit generic sub-interface configuration."; 553 reference "RFC XXX, Section 2.6 Sub-interface"; 554 } 556 identity ethSubInterface{ 557 base ianaift:l2vlan; 558 base sub-interface; 559 description 560 "This identity represents the child sub-interface of any 561 interface types that uses Ethernet framing (with or without 562 802.1Q tagging)."; 563 } 565 identity loopback { 566 description "Base identity for interface loopback options"; 567 reference "RFC XXX, Section 2.4"; 568 } 569 identity internal { 570 base loopback; 571 description 572 "All egress traffic on the interface is internally looped back 573 within the interface to be received on the ingress path."; 574 reference "RFC XXX, Section 2.4"; 575 } 576 identity line { 577 base loopback; 578 description 579 "All ingress traffic received on the interface is internally 580 looped back within the interface to the egress path."; 581 reference "RFC XXX, Section 2.4"; 582 } 583 identity connector { 584 base loopback; 585 description 586 "The interface has a physical loopback connector attached that 587 loops all egress traffic back into the interface's ingress 588 path, with equivalent semantics to loopback internal."; 589 reference "RFC XXX, Section 2.4"; 590 } 592 identity forwarding-mode { 593 description "Base identity for forwarding-mode options."; 594 reference "RFC XXX, Section 2.7"; 595 } 596 identity physical { 597 base forwarding-mode; 598 description 599 "Physical layer forwarding. This includes DWDM or OTN based 600 optical switching."; 601 reference "RFC XXX, Section 2.7"; 602 } 603 identity data-link { 604 base forwarding-mode; 605 description 606 "Layer 2 based forwarding, such as Ethernet/VLAN based 607 switching, or L2VPN services."; 608 reference "RFC XXX, Section 2.7"; 609 } 610 identity network { 611 base forwarding-mode; 612 description 613 "Network layer based forwarding, such as IP, MPLS, or L3VPNs."; 614 reference "RFC XXX, Section 2.7"; 615 } 617 /* 618 * Augments the IETF interfaces model with leaves to configure 619 * and monitor carrier-delay on an interface. 620 */ 621 augment "/if:interfaces/if:interface" { 622 description 623 "Augments the IETF interface model with optional common 624 interface level commands that are not formally covered by any 625 specific standard."; 627 /* 628 * Defines standard YANG for the Carrier Delay feature. 629 */ 630 container carrier-delay { 631 if-feature "carrier-delay"; 632 description 633 "Holds carrier delay related feature configuration."; 634 leaf down { 635 type uint32; 636 units milliseconds; 637 description 638 "Delays the propagation of a 'loss of carrier signal' event 639 that would cause the interface state to go down, i.e. the 640 command allows short link flaps to be suppressed. The 641 configured value indicates the minimum time interval (in 642 milliseconds) that the carrier signal must be continuously 643 down before the interface state is brought down. If not 644 configured, the behaviour on loss of carrier signal is 645 vendor/interface specific, but with the general 646 expectation that there should be little or no delay."; 647 } 648 leaf up { 649 type uint32; 650 units milliseconds; 651 description 652 "Defines the minimum time interval (in milliseconds) that 653 the carrier signal must be continuously present and error 654 free before the interface state is allowed to transition 655 from down to up. If not configured, the behaviour is 656 vendor/interface specific, but with the general 657 expectation that sufficient default delay should be used 658 to ensure that the interface is stable when enabled before 659 being reported as being up. Configured values that are 660 too low for the hardware capabilties may be rejected."; 661 } 662 leaf carrier-transitions { 663 type yang:counter64; 664 units transitions; 665 config false; 666 description 667 "Defines the number of times the underlying carrier state 668 has changed to, or from, state up. This counter should be 669 incremented even if the high layer interface state changes 670 are being suppressed by a running carrier-delay timer."; 671 } 672 leaf timer-running { 673 type enumeration { 674 enum none { 675 description 676 "No carrier delay timer is running."; 677 } 678 enum up { 679 description 680 "Carrier-delay up timer is running. The underlying 681 carrier state is up, but interface state is not 682 reported as up."; 683 } 684 enum down { 685 description 686 "Carrier-delay down timer is running. Interface state 687 is reported as up, but the underlying carrier state is 688 actually down."; 689 } 690 } 691 config false; 692 description 693 "Reports whether a carrier delay timer is actively running, 694 in which case the interface state does not match the 695 underlying carrier state."; 696 } 698 reference "RFC XXX, Section 2.1 Carrier Delay"; 699 } 700 /* 701 * Augments the IETF interfaces model with a container to hold 702 * generic interface dampening 703 */ 704 container dampening { 705 if-feature "dampening"; 706 presence 707 "Enable interface link flap dampening with default settings 708 (that are vendor/device specific)."; 709 description 710 "Interface dampening limits the propagation of interface link 711 state flaps over longer periods."; 712 reference "RFC XXX, Section 2.2 Dampening"; 714 leaf half-life { 715 type uint32; 716 units seconds; 717 description 718 "The time (in seconds) after which a penalty would be half 719 its original value. Once the interface has been assigned 720 a penalty, the penalty is decreased at a decay rate 721 equivalent to the half-life. For some devices, the 722 allowed values may be restricted to particular multiples 723 of seconds. The default value is vendor/device 724 specific."; 725 reference "RFC XXX, Section 2.3.2 Half-Life Period"; 726 } 728 leaf reuse { 729 type uint32; 730 description 731 "Penalty value below which a stable interface is 732 unsuppressed (i.e. brought up) (no units). The default 733 value is vendor/device specific. The penalty value for a 734 link up->down state change is 1000 units."; 735 reference "RFC XXX, Section 2.2.3 Reuse Threshold"; 736 } 738 leaf suppress { 739 type uint32; 740 description 741 "Limit at which an interface is suppressed (i.e. held down) 742 when its penalty exceeds that limit (no units). The value 743 must be greater than the reuse threshold. The default 744 value is vendor/device specific. The penalty value for a 745 link up->down state change is 1000 units."; 746 reference "RFC XXX, Section 2.2.1 Suppress Threshold"; 747 } 748 leaf max-suppress-time { 749 type uint32; 750 units seconds; 751 description 752 "Maximum time (in seconds) that an interface can be 753 suppressed before being unsuppressed if no further link 754 up->down state change penalties have been applied. This 755 value effectively acts as a ceiling that the penalty value 756 cannot exceed. The default value is vendor/device 757 specific."; 758 reference "RFC XXX, Section 2.2.4 Maximum Suppress Time"; 759 } 761 leaf penalty { 762 type uint32; 763 config false; 764 description 765 "The current penalty value for this interface. When the 766 penalty value exceeds the 'suppress' leaf then the 767 interface is suppressed (i.e. held down)."; 768 reference "RFC XXX, Section 2.2 Dampening"; 769 } 771 leaf suppressed { 772 type boolean; 773 config false; 774 description 775 "Represents whether the interface is suppressed (i.e. held 776 down) because the 'penalty' leaf value exceeds the 777 'suppress' leaf."; 778 reference "RFC XXX, Section 2.2 Dampening"; 779 } 781 leaf time-remaining { 782 when '../suppressed = "true"' { 783 description 784 "Only suppressed interfaces have a time remaining."; 785 } 786 type uint32; 787 units seconds; 788 config false; 789 description 790 "For a suppressed interface, this leaf represents how long 791 (in seconds) that the interface will remain suppressed 792 before it is allowed to go back up again."; 793 reference "RFC XXX, Section 2.2 Dampening"; 794 } 795 } 796 /* 797 * Various types of interfaces support a configurable layer 2 798 * encapsulation, any that are supported by YANG should be 799 * listed here. 800 * 801 * Different encapsulations can hook into the common encaps-type 802 * choice statement. 803 */ 804 container encapsulation { 805 when 806 "derived-from-or-self(../if:type, 807 'ianaift:ethernetCsmacd') or 808 derived-from-or-self(../if:type, 809 'ianaift:ieee8023adLag') or 810 derived-from-or-self(../if:type, 'ianaift:pos') or 811 derived-from-or-self(../if:type, 812 'ianaift:atmSubInterface') or 813 derived-from-or-self(../if:type, 'ethSubInterface')" { 815 description 816 "All interface types that can have a configurable L2 817 encapsulation."; 818 } 820 description 821 "Holds the OSI layer 2 encapsulation associated with an 822 interface."; 823 choice encaps-type { 824 description 825 "Extensible choice of layer 2 encapsulations"; 826 reference "RFC XXX, Section 2.3 Encapsulation"; 827 } 828 } 830 /* 831 * Various types of interfaces support loopback configuration, 832 * any that are supported by YANG should be listed here. 833 */ 834 leaf loopback { 835 when "derived-from-or-self(../if:type, 836 'ianaift:ethernetCsmacd') or 837 derived-from-or-self(../if:type, 'ianaift:sonet') or 838 derived-from-or-self(../if:type, 'ianaift:atm') or 839 derived-from-or-self(../if:type, 'ianaift:otnOtu')" { 840 description 841 "All interface types that support loopback configuration."; 842 } 843 if-feature "loopback"; 844 type identityref { 845 base loopback; 846 } 847 description "Enables traffic loopback."; 848 reference "RFC XXX, Section 2.4 Loopback"; 849 } 851 /* 852 * Allows the maximum frame size to be configured or reported. 853 */ 854 leaf max-frame-size { 855 if-feature "max-frame-size"; 856 type uint32 { 857 range "64 .. max"; 858 } 859 description 860 "The maximum size of layer 2 frames that may be transmitted 861 or received on the interface (including any frame header, 862 maximum frame payload size, and frame checksum sequence). 864 If configured, the max-frame-size also limits the maximum 865 frame size of any child sub-interfaces. The MTU available 866 to higher layer protocols is restricted to the maximum frame 867 payload size, and MAY be further restricted by explicit 868 layer 3 or protocol specific MTU configuration."; 870 reference "RFC XXX, Section 2.5 Maximum Frame Size"; 871 } 873 /* 874 * Augments the IETF interfaces model with a leaf that indicates 875 * which mode, or layer, is being used to forward the traffic. 876 */ 877 leaf forwarding-mode { 878 type identityref { 879 base forwarding-mode; 880 } 881 config false; 883 description 884 "The forwarding mode that the interface is operating in."; 885 reference "RFC XXX, Section 2.7 Forwarding Mode"; 886 } 887 } 889 /* 890 * Add generic support for sub-interfaces. 891 * 892 * This should be extended to cover all interface types that are 893 * child interfaces of other interfaces. 894 */ 895 augment "/if:interfaces/if:interface" { 896 when "derived-from(if:type, 'sub-interface') or 897 derived-from-or-self(if:type, 'ianaift:atmSubInterface') or 898 derived-from-or-self(if:type, 'ianaift:frameRelay')" { 899 description 900 "Any ianaift:types that explicitly represent sub-interfaces 901 or any types that derive from the sub-interface identity."; 902 } 903 if-feature "sub-interfaces"; 905 description 906 "Adds a parent interface field to interfaces that model 907 sub-interfaces."; 908 leaf parent-interface { 910 type if:interface-ref; 912 mandatory true; 913 description 914 "This is the reference to the parent interface of this 915 sub-interface."; 916 reference "RFC XXX, Section 2.6 Sub-interface"; 917 } 918 } 919 } 920 922 5. Interfaces Ethernet-Like YANG Module 924 This YANG module augments the interface container defined in RFC 8343 925 [RFC8343] for Ethernet-like interfaces. This includes Ethernet 926 interfaces, 802.3 LAG (802.1AX) interfaces, VLAN sub-interfaces, 927 Switch Virtual interfaces, and Pseudo-Wire Head-End interfaces. 929 file "ietf-if-ethernet-like@2019-11-04.yang" 930 module ietf-if-ethernet-like { 931 yang-version 1.1; 933 namespace 934 "urn:ietf:params:xml:ns:yang:ietf-if-ethernet-like"; 936 prefix ethlike; 937 import ietf-interfaces { 938 prefix if; 939 reference 940 "RFC 8343: A YANG Data Model For Interface Management"; 941 } 943 import ietf-yang-types { 944 prefix yang; 945 reference "RFC 6991: Common YANG Data Types"; 946 } 948 import iana-if-type { 949 prefix ianaift; 950 reference "RFC 7224: IANA Interface Type YANG Module"; 951 } 953 organization 954 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 956 contact 957 "WG Web: 958 WG List: 960 Editor: Robert Wilton 961 "; 963 description 964 "This module contains YANG definitions for configuration for 965 'Ethernet-like' interfaces. It is applicable to all interface 966 types that use Ethernet framing and expose an Ethernet MAC 967 layer, and includes such interfaces as physical Ethernet 968 interfaces, Ethernet LAG interfaces and VLAN sub-interfaces. 970 Additional interface configuration and counters for physical 971 Ethernet interfaces are defined in 972 ieee802-ethernet-interface.yang, as part of IEEE Std 973 802.3.2-2019. 975 Copyright (c) 2019 IETF Trust and the persons identified as 976 authors of the code. All rights reserved. 978 Redistribution and use in source and binary forms, with or 979 without modification, is permitted pursuant to, and subject to 980 the license terms contained in, the Simplified BSD License set 981 forth in Section 4.c of the IETF Trust's Legal Provisions 982 Relating to IETF Documents 983 (https://trustee.ietf.org/license-info). 985 This version of this YANG module is part of RFC XXXX 986 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 987 for full legal notices."; 989 revision 2019-11-04 { 990 description "Initial revision."; 992 reference 993 "RFC XXX, Common Interface Extension YANG Data Models"; 994 } 996 feature configurable-mac-address { 997 description 998 "This feature indicates that MAC addresses on Ethernet-like 999 interfaces can be configured."; 1000 reference "RFC XXX, Section 3 Interfaces Ethernet-Like Module"; 1001 } 1003 /* 1004 * Configuration parameters for Ethernet-like interfaces. 1005 */ 1006 augment "/if:interfaces/if:interface" { 1007 when "derived-from-or-self(if:type, 'ianaift:ethernetCsmacd') or 1008 derived-from-or-self(if:type, 'ianaift:ieee8023adLag') or 1009 derived-from-or-self(if:type, 'ianaift:ifPwType')" { 1010 description "Applies to all Ethernet-like interfaces"; 1011 } 1012 description 1013 "Augment the interface model with parameters for all 1014 Ethernet-like interfaces."; 1016 container ethernet-like { 1017 description 1018 "Contains parameters for interfaces that use Ethernet framing 1019 and expose an Ethernet MAC layer."; 1021 leaf mac-address { 1022 if-feature "configurable-mac-address"; 1023 type yang:mac-address; 1024 description 1025 "The MAC address of the interface. The operational value 1026 matches the /if:interfaces/if:interface/if:phys-address 1027 leaf defined in ietf-interface.yang."; 1028 } 1030 leaf bia-mac-address { 1031 type yang:mac-address; 1032 config false; 1033 description 1034 "The 'burnt-in' MAC address. I.e the default MAC address 1035 assigned to the interface if no MAC address has been 1036 explicitly configured on it."; 1037 } 1038 } 1039 } 1041 /* 1042 * Configuration parameters for Ethernet-like interfaces. 1043 */ 1044 augment "/if:interfaces/if:interface/if:statistics" { 1045 when "derived-from-or-self(../if:type, 1046 'ianaift:ethernetCsmacd') or 1047 derived-from-or-self(../if:type, 1048 'ianaift:ieee8023adLag') or 1049 derived-from-or-self(../if:type, 'ianaift:ifPwType')" { 1050 description "Applies to all Ethernet-like interfaces"; 1051 } 1052 description 1053 "Augment the interface model statistics with additional 1054 counters related to Ethernet-like interfaces."; 1056 leaf in-drop-unknown-dest-mac-pkts { 1057 type yang:counter64; 1058 units frames; 1059 description 1060 "A count of the number of frames that were well formed, but 1061 otherwise dropped because the destination MAC address did 1062 not pass any ingress destination MAC address filter. 1064 For consistency, frames counted against this drop counters 1065 are also counted against the IETF interfaces statistics. In 1066 particular, they are included in in-octets and in-discards, 1067 but are not included in in-unicast-pkts, in-multicast-pkts 1068 or in-broadcast-pkts, because they are not delivered to a 1069 higher layer. 1071 Discontinuities in the values of this counter can occur at 1072 re-initialization of the management system, and at other 1073 times as indicated by the value of the 'discontinuity-time' 1074 leaf defined in the ietf-interfaces YANG module (RFC 8343)."; 1075 } 1076 } 1077 } 1078 1080 6. Examples 1082 The following sections give some examples of how different parts of 1083 the YANG modules could be used. Examples are not given for the more 1084 trivial configuration, or for sub-interfaces, for which examples are 1085 contained in [I-D.ietf-netmod-sub-intf-vlan-model]. 1087 6.1. Carrier delay configuration 1089 The following example shows how the operational state datastore could 1090 look like for an Ethernet interface without any carrier delay 1091 configuration. The down leaf value of 0 indicates that link down 1092 events as always propagated to high layers immediately, but an up 1093 leaf value of 50 indicates that the interface must be up and stable 1094 for at least 50 msecs before the interface is reported as being up to 1095 the high layers. 1097 1098 1102 1103 eth0 1104 ianaift:ethernetCsmacd 1105 1106 0 1107 50 1108 1109 1110 1112 The following example shows explicit carrier delay up and down values 1113 have been configured. A 50 msec down leaf value has been used to 1114 potentially allow optical protection to recover the link before the 1115 higher layer protocol state is flapped. A 1 second (1000 1116 milliseconds) up leaf value has been used to ensure that the link is 1117 always reasonably stable before allowing traffic to be carried over 1118 it. This also has the benefit of greatly reducing the rate at which 1119 higher layer protocol state flaps could occur. 1121 1122 1123 1127 1128 eth0 1129 ianaift:ethernetCsmacd 1130 1131 50 1132 1000 1133 1134 1135 1136 1138 6.2. Dampening configuration 1140 The following example shows what the operational state datastore may 1141 look like for an interface configured with interface dampening. The 1142 'suppressed' leaf indicates that the interface is currently 1143 suppressed (i.e. down) because the 'penalty' is greater than the 1144 'suppress' leaf threshold. The 'time-remaining' leaf indicates that 1145 the interface will remain suppressed for another 103 seconds before 1146 the 'penalty' is below the 'reuse' leaf value and the interface is 1147 allowed to go back up again. 1149 1150 1153 1154 eth0 1155 ianaift:ethernetCsmacd 1156 down 1157 1159 60 1160 750 1161 2000 1162 240 1163 2480 1164 true 1165 103 1166 1167 1168 1170 6.3. MAC address configuration 1172 The following example shows how the operational state datastore could 1173 look like for an Ethernet interface without an explicit MAC address 1174 configured. The mac-address leaf always reports the actual 1175 operational MAC address that is in use. The bia-mac-address leaf 1176 always reports the default MAC address assigned to the hardware. 1178 1179 1182 1183 eth0 1184 ianaift:ethernetCsmacd 1185 00:00:5E:00:53:30 1186 1188 00:00:5E:00:53:30 1189 00:00:5E:00:53:30 1190 1191 1192 1194 The following example shows the intended configuration for interface 1195 eth0 with an explicit MAC address configured. 1197 1198 1199 1202 1203 eth0 1204 ianaift:ethernetCsmacd 1205 1207 00:00:5E:00:53:35 1208 1209 1210 1211 1213 After the MAC address configuration has been successfully applied, 1214 the operational state datastore reporting the interface MAC address 1215 properties would contain the following, with the mac-address leaf 1216 updated to match the configured value, but the bia-mac-address leaf 1217 retaining the same value - which should never change. 1219 1220 1223 1224 eth0 1225 ianaift:ethernetCsmacd 1226 00:00:5E:00:53:35 1227 1229 00:00:5E:00:53:35 1230 00:00:5E:00:53:30 1231 1232 1233 1235 7. Acknowledgements 1237 The authors wish to thank Eric Gray, Ing-Wher Chen, Jon Culver, 1238 Juergen Schoenwaelder, Ladislav Lhotka, Lou Berger, Mahesh 1239 Jethanandani, Martin Bjorklund, Michael Zitao, Neil Ketley, Qin Wu, 1240 William Lupton, Xufeng Liu, Andy Bierman, and Vladimir Vassilev for 1241 their helpful comments contributing to this document. 1243 8. ChangeLog 1245 XXX, RFC Editor, please delete this change log before publication. 1247 8.1. Version -08 1249 o Initial updates after WG LC comments. 1251 8.2. Version -07 1253 o Minor editorial updates 1255 8.3. Version -06 1257 o Remove reservable-bandwidth, based on Acee's suggestion 1259 o Add examples 1261 o Add additional state parameters for carrier-delay and dampening 1263 8.4. Version -05 1265 o Incorporate feedback from Andy Bierman 1267 8.5. Version -04 1269 o Incorporate feedback from Lada, some comments left as open issues. 1271 8.6. Version -03 1273 o Fixed incorrect module name references, and updated tree output 1275 8.7. Version -02 1277 o Minor changes only: Fix errors in when statements, use derived- 1278 from-or-self() for future proofing. 1280 9. IANA Considerations 1282 This document defines several new YANG module and the authors 1283 politely request that IANA assigns unique names to the two YANG 1284 module files contained within this document, and also appropriate 1285 URIs in the "IETF XML Registry". 1287 10. Security Considerations 1289 The YANG module defined in this memo is designed to be accessed via 1290 the NETCONF protocol RFC 6241 [RFC6241]. The lowest NETCONF layer is 1291 the secure transport layer and the mandatory to implement secure 1292 transport is SSH RFC 6242 [RFC6242]. The NETCONF access control 1293 model RFC 6536 [RFC6536] provides the means to restrict access for 1294 particular NETCONF users to a pre-configured subset of all available 1295 NETCONF protocol operations and content. 1297 There are a number of data nodes defined in this YANG module which 1298 are writable/creatable/deletable (i.e. config true, which is the 1299 default). These data nodes may be considered sensitive or vulnerable 1300 in some network environments. Write operations (e.g. edit-config) to 1301 these data nodes without proper protection can have a negative effect 1302 on network operations. These are the subtrees and data nodes and 1303 their sensitivity/vulnerability: 1305 10.1. ietf-if-extensions.yang 1307 The ietf-if-extensions YANG module contains various configuration 1308 leaves that affect the behavior of interfaces. Modifying these 1309 leaves can cause an interface to go down, or become unreliable, or to 1310 drop traffic forwarded over it. More specific details of the 1311 possible failure modes are given below. 1313 The following leaf could cause the interface to go down and stop 1314 processing any ingress or egress traffic on the interface. It could 1315 also cause broadcast traffic storms. 1317 o /if:interfaces/if:interface/loopback 1319 The following leaves could cause instabilities at the interface link 1320 layer, and cause unwanted higher layer routing path changes if the 1321 leaves are modified, although they would generally only affect a 1322 device that had some underlying link stability issues: 1324 o /if:interfaces/if:interface/carrier-delay/down 1326 o /if:interfaces/if:interface/carrier-delay/up 1327 o /if:interfaces/if:interface/dampening/half-life 1329 o /if:interfaces/if:interface/dampening/reuse 1331 o /if:interfaces/if:interface/dampening/suppress 1333 o /if:interfaces/if:interface/dampening/max-suppress-time 1335 The following leaves could cause traffic loss on the interface 1336 because the received or transmitted frames do not comply with the 1337 frame matching criteria on the interface and hence would be dropped: 1339 o /if:interfaces/if:interface/encapsulation 1341 o /if:interfaces/if:interface/max-frame-size 1343 o /if:interfaces/if:interface/forwarding-mode 1345 Changing the parent-interface leaf could cause all traffic on the 1346 affected interface to be dropped. The affected leaf is: 1348 o /if:interfaces/if:interface/parent-interface 1350 10.2. ietf-if-ethernet-like.yang 1352 Generally, the configuration nodes in the ietf-if-ethernet-like YANG 1353 module are concerned with configuration that is common across all 1354 types of Ethernet-like interfaces. The module currently only 1355 contains a node for configuring the operational MAC address to use on 1356 an interface. Adding/modifying/deleting this leaf has the potential 1357 risk of causing protocol instability, excessive protocol traffic, and 1358 general traffic loss, particularly if the configuration change caused 1359 a duplicate MAC address to be present on the local network . The 1360 following leaf is affected: 1362 o interfaces/interface/ethernet-like/mac-address 1364 11. References 1366 11.1. Normative References 1368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1369 Requirement Levels", BCP 14, RFC 2119, 1370 DOI 10.17487/RFC2119, March 1997, 1371 . 1373 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1374 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1375 . 1377 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1378 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1379 May 2017, . 1381 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1382 and R. Wilton, "Network Management Datastore Architecture 1383 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1384 . 1386 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1387 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1388 . 1390 11.2. Informative References 1392 [I-D.ietf-netmod-sub-intf-vlan-model] 1393 Wilton, R., Ball, D., tapsingh@cisco.com, t., and S. 1394 Sivaraj, "Sub-interface VLAN YANG Data Models", draft- 1395 ietf-netmod-sub-intf-vlan-model-05 (work in progress), 1396 March 2019. 1398 [IEEE802.3.2] 1399 IEEE WG802.3 - Ethernet Working Group, "IEEE 1400 802.3.2-2019", 2019. 1402 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1403 and A. Bierman, Ed., "Network Configuration Protocol 1404 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1405 . 1407 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1408 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1409 . 1411 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1412 Protocol (NETCONF) Access Control Model", RFC 6536, 1413 DOI 10.17487/RFC6536, March 2012, 1414 . 1416 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1417 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1418 . 1420 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1421 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1422 . 1424 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1425 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1426 . 1428 Authors' Addresses 1430 Robert Wilton (editor) 1431 Cisco Systems 1433 Email: rwilton@cisco.com 1435 David Ball 1436 Cisco Systems 1438 Email: daviball@cisco.com 1440 Tapraj Singh 1441 Cisco Systems 1443 Email: tapsingh@cisco.com 1445 Selvakumar Sivaraj 1446 Juniper Networks 1448 Email: ssivaraj@juniper.net