idnits 2.17.1 draft-ietf-netmod-intf-ext-yang-06.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 235 has weird spacing: '...terface if:...' == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (July 2, 2018) is 2125 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: 'RFC6991' is defined on line 1434, but no explicit reference was found in the text == Unused Reference: 'RFC7224' is defined on line 1438, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-netmod-sub-intf-vlan-model-03 -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 0 errors (**), 0 flaws (~~), 6 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 3, 2019 Cisco Systems 6 S. Sivaraj 7 Juniper Networks 8 July 2, 2018 10 Common Interface Extension YANG Data Models 11 draft-ietf-netmod-intf-ext-yang-06 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. 19 These properties are common to many types of interfaces on network 20 routers and switches and are implemented by multiple network 21 equipment vendors with similar semantics, even though some of the 22 features are not formally defined in any published standard. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 3, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Interfaces Common Module . . . . . . . . . . . . . . . . . . 4 63 3.1. Carrier Delay . . . . . . . . . . . . . . . . . . . . . . 6 64 3.2. Dampening . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.2.1. Suppress Threshold . . . . . . . . . . . . . . . . . 8 66 3.2.2. Half-Life Period . . . . . . . . . . . . . . . . . . 8 67 3.2.3. Reuse Threshold . . . . . . . . . . . . . . . . . . . 8 68 3.2.4. Maximum Suppress Time . . . . . . . . . . . . . . . . 8 69 3.3. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 8 70 3.4. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 9 71 3.5. Layer 2 MTU . . . . . . . . . . . . . . . . . . . . . . . 9 72 3.6. Sub-interface . . . . . . . . . . . . . . . . . . . . . . 9 73 3.7. Forwarding Mode . . . . . . . . . . . . . . . . . . . . . 10 74 4. Interfaces Ethernet-Like Module . . . . . . . . . . . . . . . 11 75 5. Interfaces Common YANG Module . . . . . . . . . . . . . . . . 11 76 6. Interfaces Ethernet-Like YANG Module . . . . . . . . . . . . 22 77 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 25 78 7.1. Carrier delay configuration . . . . . . . . . . . . . . . 25 79 7.2. Dampening configuration . . . . . . . . . . . . . . . . . 26 80 7.3. MAC address configuration . . . . . . . . . . . . . . . . 27 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 82 9. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 29 83 9.1. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 29 84 9.2. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 29 85 9.3. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 29 86 9.4. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 29 87 9.5. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 29 88 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 89 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 90 11.1. interfaces-common.yang . . . . . . . . . . . . . . . . . 30 91 11.2. interfaces-ethernet-like.yang . . . . . . . . . . . . . 31 92 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 93 12.1. Normative References . . . . . . . . . . . . . . . . . . 31 94 12.2. Informative References . . . . . . . . . . . . . . . . . 32 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 draft is to provide a standard namespace and 106 path for these configuration items regardless of the underlying 107 interface type. For example a standard namespace and path for 108 configuring or reading the MAC address associated with an interface 109 is provided that can be used for any interface type that uses 110 Ethernet framing. 112 Several of the augmentations defined here are not backed by any 113 formal standard specification. Instead, they are for features that 114 are commonly implemented in equivalent ways by multiple independent 115 network equipment vendors. The aim of this draft is to define common 116 paths and leaves for the configuration of these equivalent features 117 in a uniform way, making it easier for users of the YANG model to 118 access these features in a vendor independent way. Where necessary, 119 a description of the expected behavior is also provided with the aim 120 of ensuring vendors implementations are consistent with the specified 121 behaviour. 123 Given that the modules contain a collection of discrete features with 124 the common theme that they generically apply to interfaces, it is 125 plausible that not all implementors of the YANG module will decide to 126 support all features. Hence separate feature keywords are defined 127 for each logically discrete feature to allow implementors the 128 flexibility to choose which specific parts of the model they support. 130 The augmentations are split into two separate YANG modules that each 131 focus on a particular area of functionality. The two YANG modules 132 defined in this internet draft are: 134 ietf-interfaces-common.yang - Defines extensions to the IETF 135 interface data model to support common configuration data nodes. 137 ietf-interfaces-ethernet-like.yang - Defines a module for any 138 configuration and operational data nodes that are common across 139 interfaces that use Ethernet framing. 141 1.1. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 147 appear in all capitals, as shown here. 149 1.2. Tree Diagrams 151 A simplified graphical representation of the data model is used in 152 this document. The meaning of the symbols in these diagrams is as 153 follows: 155 o Brackets "[" and "]" enclose list keys. 157 o Abbreviations before data node names: "rw" means configuration 158 (read-write), and "ro" means state data (read-only). 160 o Symbols after data node names: "?" means an optional node, "!" 161 means a presence container, and "*" denotes a list or leaf-list. 163 o Parentheses enclose choice and case nodes, and case nodes are also 164 marked with a colon (":"). 166 o Ellipsis ("...") stands for contents of subtrees that are not 167 shown. 169 2. Objectives 171 The aim of the YANG modules contained in this draft is to provide 172 standard definitions for common interface based configuration on 173 network devices. 175 The expectation is that the YANG leaves that are being defined are 176 fairly widely implemented by network vendors. However, the features 177 described here are mostly not backed by formal standards because they 178 are fairly basic in their behavior and do not need to interoperate 179 with other devices. Where required a concise explanation of the 180 expected behavior is also provided to ensure consistency between 181 vendors. 183 3. Interfaces Common Module 185 The Interfaces Common module provides some basic extensions to the 186 IETF interfaces YANG module. 188 The module provides: 190 o A carrier delay feature used to provide control over short lived 191 link state flaps. 193 o An interface link state dampening feature that is used to provide 194 control over longer lived link state flaps. 196 o An encapsulation container and extensible choice statement for use 197 by any interface types that allow for configurable L2 198 encapsulations. 200 o A loopback configuration leaf that is primarily aimed at loopback 201 at the physical layer. 203 o MTU configuration leaves applicable to all packet/frame based 204 interfaces. 206 o A forwarding mode leaf to indicate the OSI layer at which the 207 interface handles traffic 209 o A parent interface leaf useable for all types of sub-interface 210 that are children of parent interfaces. 212 The "ietf-interfaces-common" YANG module has the following structure: 214 module: ietf-interfaces-common 215 augment /if:interfaces/if:interface: 216 +--rw carrier-delay {carrier-delay}? 217 | +--rw down? uint32 218 | +--rw up? uint32 219 | +--ro carrier-transitions? yang:counter64 220 | +--ro timer-running? enumeration 221 +--rw dampening! {dampening}? 222 | +--rw half-life? uint32 223 | +--rw reuse? uint32 224 | +--rw suppress? uint32 225 | +--rw max-suppress-time? uint32 226 | +--ro penalty? uint32 227 | +--ro suppressed? boolean 228 | +--ro time-remaining? uint32 229 +--rw encapsulation 230 | +--rw (encaps-type)? 231 +--rw loopback? identityref {loopback}? 232 +--rw l2-mtu? uint16 {configurable-l2-mtu}? 233 +--rw forwarding-mode? identityref {forwarding-mode}? 234 augment /if:interfaces/if:interface: 235 +--rw parent-interface if:interface-ref {sub-interfaces}? 237 3.1. Carrier Delay 239 The carrier delay feature augments the IETF interfaces data model 240 with configuration for a simple algorithm that is used, generally on 241 physical interfaces, to suppress short transient changes in the 242 interface link state. It can be used in conjunction with the 243 dampening feature described in Section 3.2 to provide effective 244 control of unstable links and unwanted state transitions. 246 The principal of the carrier delay feature is to use a short per 247 interface timer to ensure that any interface link state transition 248 that occurs and reverts back within the specified time interval is 249 entirely suppressed without providing any signalling to any upper 250 layer protocols that the state transition has occurred. E.g. in the 251 case that the link state transition is suppressed then there is no 252 change of the /if:interfaces-state/if:interface/oper-status or 253 /if:interfaces-state/if:interfaces/last-change leaves for the 254 interface that the feature is operating on. One obvious side effect 255 of using this feature that is worth noting is that any state 256 transition will always be delayed by the specified time interval. 258 The configuration allows for separate timer values to be used in the 259 suppression of down->up->down link transitions vs up->down->up link 260 transitions. 262 The carrier delay down timer leaf specifies the amount of time that 263 an interface that is currently in link up state must be continuously 264 down before the down state change is reported to higher level 265 protocols. Use of this timer can cause traffic to be black holed for 266 the configured value and delay reconvergence after link failures, 267 therefore its use is normally restricted to cases where it is 268 necessary to allow enough time for another protection mechanism (such 269 as an optical layer automatic protection system) to take effect. 271 The carrier delay up timer leaf specifies the amount of time that an 272 interface that is currently in link down state must be continuously 273 up before the down->up link state transition is reported to higher 274 level protocols. This timer is generally useful as a debounce 275 mechanism to ensure that a link is relatively stable before being 276 brought into service. It can also be used effectively to limit the 277 frequency at which link state transition events may occur. The 278 default value for this leaf is determined by the underlying network 279 device. 281 3.2. Dampening 283 The dampening feature introduces a configurable exponential decay 284 mechanism to suppress the effects of excessive interface link state 285 flapping. This feature allows the network operator to configure a 286 device to automatically identify and selectively dampen a local 287 interface which is flapping. Dampening an interface keeps the 288 interface operationally down until the interface stops flapping and 289 becomes stable. Configuring the dampening feature can improve 290 convergence times and stability throughout the network by isolating 291 failures so that disturbances are not propagated, which reduces the 292 utilization of system processing resources by other devices in the 293 network and improves overall network stability. 295 The basic algorithm uses a counter that is nominally increased by 296 1000 units every time the underlying interface link state changes 297 from up to down. If the counter increases above the suppress 298 threshold then the interface is kept down (and out of service) until 299 either the maximum suppression time is reached, or the counter has 300 reduced below the reuse threshold. The half-life period determines 301 that rate at which the counter is periodically reduced. 302 Implementations are not required to use a penalty of 1000 units in 303 their dampening algorithm, but should ensure that the Suppress 304 Threshold and Reuse Threshold values are scaled relative to the 305 nominal 1000 unit penalty to ensure that the same configuration 306 values provide consistent behaviour. The configurable values are 307 described in more detail below. 309 3.2.1. Suppress Threshold 311 The suppress threshold is the value of the accumulated penalty that 312 triggers the device to dampen a flapping interface. The flapping 313 interface is identified by the device and assigned a penalty for each 314 up to down link state change, but the interface is not automatically 315 dampened. The device tracks the penalties that a flapping interface 316 accumulates. When the accumulated penalty reaches the default or 317 configured suppress threshold, the interface is placed in a dampened 318 state. 320 3.2.2. Half-Life Period 322 The half-life period determines how fast the accumulated penalties 323 can decay exponentially. Any penalties that have been accumulated on 324 a flapping interface are reduced by half after each half-life period. 326 3.2.3. Reuse Threshold 328 If, after one or more half-life periods, the accumulated penalty 329 decreases below the reuse threshold and the underlying interface link 330 state is up then the interface is taken out of dampened state and 331 allowed to go up. 333 3.2.4. Maximum Suppress Time 335 The maximum suppress time represents the maximum amount of time an 336 interface can remain dampened when a penalty is assigned to an 337 interface. The default of the maximum suppress timer is four times 338 the half-life period. The maximum value of the accumulated penalty 339 is calculated using the maximum suppress time, reuse threshold and 340 half-life period. 342 3.3. Encapsulation 344 The encapsulation container holds a choice node that is to be 345 augmented with datalink layer specific encapsulations, such as HDLC, 346 PPP, or sub-interface 802.1Q tag match encapsulations. The use of a 347 choice statement ensures that an interface can only have a single 348 datalink layer protocol configured. 350 The different encapsulations themselves are defined in separate YANG 351 modules defined in other documents that augument the encapsulation 352 choice statement. For example the Ethernet specific basic 'dot1q- 353 vlan' encapsulation is defined in ietf-if-l3-vlan.yang and the 354 'flexible' encapsulation is defined in ietf-flexible- 355 encapsulation.yang, both modules from 356 [I-D.ietf-netmod-sub-intf-vlan-model]. 358 3.4. Loopback 360 The loopback configuration leaf allows any physical interface to be 361 configured to be in one of the possible following physical loopback 362 modes, i.e. internal loopback, line loopback, or use of an external 363 loopback connector. The use of YANG identities allows for the model 364 to be extended with other modes of loopback if required. 366 The following loopback modes are defined: 368 o Internal loopback - All egress traffic on the interface is 369 internally looped back within the interface to be received on the 370 ingress path. 372 o Line loopback - All ingress traffic received on the interface is 373 internally looped back within the interface to the egress path. 375 o Loopback Connector - The interface has a physical loopback 376 connector attached that loops all egress traffic back into the 377 interface's ingress path, with equivalent semantics to internal 378 loopback. 380 3.5. Layer 2 MTU 382 A layer 2 MTU configuration leaf (l2-mtu) is provided to specify the 383 maximum size of a layer 2 frame that may be transmitted or received 384 on an interface. The layer 2 MTU includes the overhead of the layer 385 2 header and the maximum length of the payload, but excludes any 386 frame check sequence (FCS) bytes. The payload MTU available to 387 higher layer protocols is calculated from the l2-mtu leaf after 388 taking the layer 2 header size into account. 390 For Ethernet interfaces carrying 802.1Q VLAN tagged frames, the 391 l2-mtu excludes the 4-8 byte overhead of any known (e.g. explicitly 392 matched by a child sub-interface) 801.1Q VLAN tags. 394 3.6. Sub-interface 396 The sub-interface feature specifies the minimal leaves required to 397 define a child interface that is parented to another interface. 399 A sub-interface is a logical interface that handles a subset of the 400 traffic on the parent interface. Separate configuration leaves are 401 used to classify the subset of ingress traffic received on the parent 402 interface to be processed in the context of a given sub-interface. 403 All egress traffic processed on a sub-interface is given to the 404 parent interface for transmission. Otherwise, a sub-interface is 405 like any other interface in /if:interfaces and supports the standard 406 interface features and configuration. 408 For some vendor specific interface naming conventions the name of the 409 child interface is sufficient to determine the parent interface, 410 which implies that the child interface can never be reparented to a 411 different parent interface after it has been created without deleting 412 the existing sub-interface and recreating a new sub-interface. Even 413 in this case it is useful to have a well defined leaf to cleanly 414 identify the parent interface. 416 The model also allows for arbitrarily named sub-interfaces by having 417 an explicit parent-interface leaf define the child -> parent 418 relationship. In this naming scenario it is also possible for 419 implementations to allow for logical interfaces to be reparented to 420 new parent interfaces without needing the sub-interface to be 421 destroyed and recreated. 423 3.7. Forwarding Mode 425 The forwarding mode leaf provides additional information as to what 426 mode or layer an interface is logically operating and forwarding 427 traffic at. The implication of this leaf is that for traffic 428 forwarded at a given layer that any headers for lower layers are 429 stripped off before the packet is forwarded at the given layer. 430 Conversely, on egress any lower layer headers must be added to the 431 packet before it is transmitted out of the interface. 433 YANG Modules can conditionally use this leaf as a simple mechanism to 434 determine whether particular types of configuration are valid. YANG 435 modules can write 'must' statements to check whether the forwarding 436 mode leaf has been configured, and if it is, then validate that the 437 specified configuration is consistent with any forwarding mode that 438 has also been configured. E.g., a layer 2 QoS policy YANG module 439 could ensure that it is only applied to a interface forwarding 440 traffic at layer 2 by checking whether the forwarding-mode leaf 441 exists, and if it does then also ensure that it has been set to 442 'layer-2-forwarding'. 444 The following forwarding modes are defined: 446 o Optical Layer - Traffic is being forwarded at the optical layer. 447 This includes DWDM or OTN based switching. 449 o Layer 2 - Layer 2 based forwarding, such as Ethernet/VLAN based 450 switching, or L2VPN services. 452 o Network Layer - Network layer based forwarding, such as IP, MPLS, 453 or L3VPNs. 455 4. Interfaces Ethernet-Like Module 457 The Interfaces Ethernet-Like Module is a small module that contains 458 all configuration and operational data that is common across 459 interface types that use Ethernet framing as their datalink layer 460 encapsulation. 462 This module currently contains leaves for the configuration and 463 reporting of the operational MAC address and the burnt-in MAC address 464 (BIA) associated with any interface using Ethernet framing. 466 The "ietf-interfaces-ethernet-like" YANG module has the following 467 structure: 469 module: ietf-interfaces-ethernet-like 470 augment /if:interfaces/if:interface: 471 +--rw ethernet-like 472 +--rw mac-address? yang:mac-address 473 +--ro bia-mac-address? yang:mac-address 474 +--ro statistics 475 +--ro in-drop-unknown-dest-mac-pkts? yang:counter64 477 5. Interfaces Common YANG Module 479 This YANG module augments the interface container defined in RFC 8343 480 [RFC8343]. 482 file "ietf-interfaces-common@2018-07-02.yang" 483 module ietf-interfaces-common { 484 yang-version 1.1; 486 namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces-common"; 488 prefix if-cmn; 490 import ietf-yang-types { 491 prefix yang; 492 } 493 import ietf-interfaces { 494 prefix if; 495 } 497 import iana-if-type { 498 prefix ianaift; 499 } 501 organization 502 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 504 contact 505 "WG Web: 506 WG List: 508 WG Chair: Lou Berger 509 511 WG Chair: Joel Jaeggli 512 514 WG Chair: Kent Watsen 515 517 Editor: Robert Wilton 518 "; 520 description 521 "This module contains common definitions for extending the IETF 522 interface YANG model (RFC 7223) with common configurable layer 2 523 properties. 525 Copyright (c) 2016-2018 IETF Trust and the persons identified 526 as authors of the code. All rights reserved. 528 Redistribution and use in source and binary forms, with or 529 without modification, is permitted pursuant to, and subject 530 to the license terms contained in, the Simplified BSD License 531 set forth in Section 4.c of the IETF Trust's Legal Provisions 532 Relating to IETF Documents 533 (http://trustee.ietf.org/license-info). 535 This version of this YANG module is part of XXX; see the RFC 536 itself for full legal notices."; 538 revision 2018-07-02 { 539 description 540 "Initial version"; 542 reference "Internet draft: draft-ietf-netmod-intf-ext-yang-06"; 543 } 545 feature carrier-delay { 546 description 547 "This feature indicates that configurable interface 548 carrier delay is supported, which is a feature is used to 549 limit the propagation of very short interface link state 550 flaps."; 551 reference "RFC XXX, Section 3.1 Carrier Delay"; 552 } 554 feature dampening { 555 description 556 "This feature indicates that the device supports interface 557 dampening, which is a feature that is used to limit the 558 propagation of interface link state flaps over longer 559 periods"; 560 reference "RFC XXX, Section 3.2 Dampening"; 561 } 563 feature loopback { 564 description 565 "This feature indicates that configurable interface loopback 566 is supported."; 567 reference "RFC XXX, Section 3.4 Loopback"; 568 } 570 feature configurable-l2-mtu { 571 description 572 "This feature indicates that the device supports configuring 573 layer 2 MTUs on interfaces. Such MTU configurations include 574 the layer 2 header overheads (but exclude any FCS overhead). 575 The payload MTU available to higher layer protocols is either 576 derived from the layer 2 MTU, taking into account the size of 577 the layer 2 header, or is further restricted by explicit layer 578 3 or protocol specific MTU configuration."; 579 reference "RFC XXX, Section 3.5 Layer 2 MTU"; 580 } 582 feature sub-interfaces { 583 description 584 "This feature indicates that the device supports the 585 instantiation of sub-interfaces. Sub-interfaces are defined 586 as logical child interfaces that allow features and forwarding 587 decisions to be applied to a subset of the traffic processed 588 on the specified parent interface."; 589 reference "RFC XXX, Section 3.6 Sub-interface"; 591 } 593 feature forwarding-mode { 594 description 595 "This feature indicates that the device supports the 596 configurable forwarding mode leaf"; 597 reference "RFC XXX, Section 3.7 Forwarding Mode"; 598 } 600 /* 601 * Define common identities to help allow interface types to be 602 * assigned properties. 603 */ 604 identity sub-interface { 605 description 606 "Base type for generic sub-interfaces. 608 New or custom interface types can derive from this type to 609 inherit generic sub-interface configuration"; 610 reference "RFC XXX, Section 3.6 Sub-interface"; 611 } 613 identity ethSubInterface{ 614 base ianaift:l2vlan; 615 base sub-interface; 617 description 618 "This identity represents the child sub-interface of any 619 interface types that uses Ethernet framing (with or without 620 802.1Q tagging)"; 621 } 623 identity loopback { 624 description "Base identity for interface loopback options"; 625 reference "RFC XXX, section 3.4"; 626 } 627 identity loopback-internal { 628 base loopback; 629 description 630 "All egress traffic on the interface is internally looped back 631 within the interface to be received on the ingress path."; 632 reference "RFC XXX, section 3.4"; 633 } 634 identity loopback-line { 635 base loopback; 636 description 637 "All ingress traffic received on the interface is internally 638 looped back within the interface to the egress path."; 640 reference "RFC XXX, section 3.4"; 641 } 642 identity loopback-connector { 643 base loopback; 644 description 645 "The interface has a physical loopback connector attached 646 that loops all egress traffic back into the interface's 647 ingress path, with equivalent semantics to loopback-internal"; 648 reference "RFC XXX, section 3.4"; 649 } 651 identity forwarding-mode { 652 description "Base identity for forwarding-mode options."; 653 reference "RFC XXX, section 3.7"; 654 } 655 identity optical-layer { 656 base forwarding-mode; 657 description 658 "Traffic is being forwarded at the optical layer. This 659 includes DWDM or OTN based switching."; 660 reference "RFC XXX, section 3.7"; 661 } 662 identity layer-2-forwarding { 663 base forwarding-mode; 664 description 665 "Layer 2 based forwarding, such as Ethernet/VLAN based 666 switching, or L2VPN services."; 667 reference "RFC XXX, section 3.7"; 668 } 669 identity network-layer { 670 base forwarding-mode; 671 description 672 "Network layer based forwarding, such as IP, MPLS, or L3VPNs."; 673 reference "RFC XXX, section 3.7"; 674 } 676 /* 677 * Augments the IETF interfaces model with leaves to configure 678 * and monitor carrier-delay on an interface. 679 */ 680 augment "/if:interfaces/if:interface" { 681 description 682 "Augments the IETF interface model with optional common 683 interface level commands that are not formally covered by any 684 specific standard."; 686 /* 687 * Defines standard YANG for the Carrier Delay feature. 688 */ 689 container carrier-delay { 690 if-feature "carrier-delay"; 691 description 692 "Holds carrier delay related feature configuration"; 693 leaf down { 694 type uint32; 695 units milliseconds; 696 description 697 "Delays the propagation of a 'loss of carrier signal' event 698 that would cause the interface state to go down, i.e. the 699 command allows short link flaps to be suppressed. The 700 configured value indicates the minimum time interval (in 701 milliseconds) that the carrier signal must be continuously 702 down before the interface state is brought down. If not 703 configured, the behaviour on loss of carrier signal is 704 vendor/interface specific, but with the general 705 expectation that there should be little or no delay."; 706 } 707 leaf up { 708 type uint32; 709 units milliseconds; 710 description 711 "Defines the minimum time interval (in milliseconds) that 712 the carrier signal must be continuously present and error 713 free before the interface state is allowed to transition 714 from down to up. If not configured, the behaviour is 715 vendor/interface specific, but with the general 716 expectation that sufficient default delay should be used 717 to ensure that the interface is stable when enabled before 718 being reported as being up. Configured values that are 719 too low for the hardware capabilties may be rejected."; 720 } 721 leaf carrier-transitions { 722 type yang:counter64; 723 units transitions; 724 config false; 725 description 726 "Defines the number of times the underlying carrier state 727 has changed to, or from, state up. This counter should be 728 incremented even if the high layer interface state changes 729 are being suppressed by a running carrier-delay timer."; 730 } 731 leaf timer-running { 732 type enumeration { 733 enum none { 734 description 735 "No carrier delay timer is running."; 736 } 737 enum up { 738 description 739 "Carrier-delay up timer is running. The underlying 740 carrier state is up, but interface state is not 741 reported as up."; 742 } 743 enum down { 744 description 745 "Carrier-delay down timer is running. Interface state 746 is reported as up, but the underlying carrier state is 747 actually down."; 748 } 749 } 750 default "none"; 751 config false; 752 description 753 "Reports whether a carrier delay timer is actively running, 754 in which case the interface state does not match the 755 underlying carrier state."; 756 } 758 reference "RFC XXX, Section 3.1 Carrier Delay"; 759 } 761 /* 762 * Augments the IETF interfaces model with a container to hold 763 * generic interface dampening 764 */ 765 container dampening { 766 if-feature "dampening"; 767 presence 768 "Enable interface link flap dampening with default settings 769 (that are vendor/device specific)"; 770 description 771 "Interface dampening limits the propagation of interface link 772 state flaps over longer periods"; 773 reference "RFC XXX, Section 3.2 Dampening"; 774 leaf half-life { 775 type uint32; 776 units seconds; 777 description 778 "The Time (in seconds) after which a penalty reaches half 779 its original value. Once the interface has been assigned 780 a penalty, the penalty is decreased by half after the 781 half-life period. For some devices, the allowed values may 782 be restricted to particular multiples of seconds. The 783 default value is vendor/device specific."; 784 reference "RFC XXX, Section 3.3.2 Half-Life Period"; 785 } 786 leaf reuse { 787 type uint32; 788 description 789 "Penalty value below which a stable interface is 790 unsuppressed (i.e. brought up) (no units). The default 791 value is vendor/device specific. The penalty value for a 792 link up->down state change is nominally 1000 units."; 793 reference "RFC XXX, Section 3.2.3 Reuse Threshold"; 794 } 796 leaf suppress { 797 type uint32; 798 description 799 "Limit at which an interface is suppressed (i.e. held down) 800 when its penalty exceeds that limit (no units). The value 801 must be greater than the reuse threshold. The default 802 value is vendor/device specific. The penalty value for a 803 link up->down state change is nominally 1000 units."; 804 reference "RFC XXX, Section 3.2.1 Suppress Threshold"; 805 } 807 leaf max-suppress-time { 808 type uint32; 809 units seconds; 810 description 811 "Maximum time (in seconds) that an interface can be 812 suppressed. This value effectively acts as a ceiling that 813 the penalty value cannot exceed. The default value is 814 vendor/device specific."; 815 reference "RFC XXX, Section 3.2.4 Maximum Suppress Time"; 816 } 818 leaf penalty { 819 type uint32; 820 config false; 821 description 822 "The current penalty value for this interface. When the 823 penalty value exceeds the 'suppress' leaf then the 824 interface is suppressed (i.e. held down)."; 825 reference "RFC XXX, Section 3.2 Dampening"; 826 } 828 leaf suppressed { 829 type boolean; 830 default "false"; 831 config false; 832 description 833 "Represents whether the interface is suppressed (i.e. held 834 down) because the 'penalty' leaf value exceeds the 835 'suppress' leaf."; 836 reference "RFC XXX, Section 3.2 Dampening"; 837 } 839 leaf time-remaining { 840 when '../suppressed = "true"' { 841 description 842 "Only suppressed interfaces should have a time remaining."; 843 } 844 type uint32; 845 units seconds; 846 config false; 847 description 848 "For a suppressed interface, this leaf represents how long 849 (in seconds) that the interface will remain suppressed 850 before it is allowed to go back up again."; 851 reference "RFC XXX, Section 3.2 Dampening"; 852 } 853 } 855 /* 856 * Various types of interfaces support a configurable layer 2 857 * encapsulation, any that are supported by YANG should be 858 * listed here. 859 * 860 * Different encapsulations can hook into the common encaps-type 861 * choice statement. 862 */ 863 container encapsulation { 864 when 865 "derived-from-or-self(../if:type, 866 'ianaift:ethernetCsmacd') or 867 derived-from-or-self(../if:type, 868 'ianaift:ieee8023adLag') or 869 derived-from-or-self(../if:type, 'ianaift:pos') or 870 derived-from-or-self(../if:type, 871 'ianaift:atmSubInterface') or 872 derived-from-or-self(../if:type, 'ethSubInterface')" { 874 description 875 "All interface types that can have a configurable L2 876 encapsulation"; 877 } 878 description 879 "Holds the OSI layer 2 encapsulation associated with an 880 interface"; 881 choice encaps-type { 882 description 883 "Extensible choice of layer 2 encapsulations"; 884 reference "RFC XXX, Section 3.3 Encapsulation"; 885 } 886 } 888 /* 889 * Various types of interfaces support loopback configuration, 890 * any that are supported by YANG should be listed here. 891 */ 892 leaf loopback { 893 when "derived-from-or-self(../if:type, 894 'ianaift:ethernetCsmacd') or 895 derived-from-or-self(../if:type, 'ianaift:sonet') or 896 derived-from-or-self(../if:type, 'ianaift:atm') or 897 derived-from-or-self(../if:type, 'ianaift:otnOtu')" { 898 description 899 "All interface types that support loopback configuration."; 900 } 901 if-feature "loopback"; 902 type identityref { 903 base loopback; 904 } 905 description "Enables traffic loopback."; 906 reference "RFC XXX, Section 3.4 Loopback"; 907 } 909 /* 910 * Many types of interfaces support a configurable layer 2 MTU. 911 */ 912 leaf l2-mtu { 913 if-feature "configurable-l2-mtu"; 914 type uint16 { 915 range "64 .. 65535"; 916 } 917 description 918 "The maximum size of layer 2 frames that may be transmitted 919 or received on the interface (excluding any FCS overhead). 920 In the case of Ethernet interfaces it also excludes the 921 4-8 byte overhead of any known (i.e. explicitly matched by 922 a child sub-interface) 801.1Q VLAN tags."; 923 reference "RFC XXX, Section 3.5 Layer 2 MTU"; 924 } 925 /* 926 * Augments the IETF interfaces model with a leaf that indicates 927 * which mode, or layer, is being used to forward the traffic. 928 */ 929 leaf forwarding-mode { 930 if-feature "forwarding-mode"; 931 type identityref { 932 base forwarding-mode; 933 } 935 description 936 "The forwarding mode that the interface is operating in."; 937 reference "RFC XXX, Section 3.7 Forwarding Mode"; 938 } 939 } 941 /* 942 * Add generic support for sub-interfaces. 943 * 944 * This should be extended to cover all interface types that are 945 * child interfaces of other interfaces. 946 */ 947 augment "/if:interfaces/if:interface" { 948 when "derived-from(if:type, 'sub-interface') or 949 derived-from-or-self(if:type, 'ianaift:atmSubInterface') or 950 derived-from-or-self(if:type, 'ianaift:frameRelay')" { 951 description 952 "Any ianaift:types that explicitly represent sub-interfaces 953 or any types that derive from the sub-interface identity"; 954 } 955 if-feature "sub-interfaces"; 957 description 958 "Add a parent interface field to interfaces that model 959 sub-interfaces"; 960 leaf parent-interface { 962 type if:interface-ref; 964 mandatory true; 965 description 966 "This is the reference to the parent interface of this 967 sub-interface."; 968 reference "RFC XXX, Section 3.6 Sub-interface"; 969 } 970 } 971 } 972 974 6. Interfaces Ethernet-Like YANG Module 976 This YANG module augments the interface container defined in RFC 8343 977 [RFC8343] for Ethernet-like interfaces. This includes Ethernet 978 interfaces, 802.3 LAG (802.1AX) interfaces, VLAN sub-interfaces, 979 Switch Virtual interfaces, and Pseudo-Wire Head-End interfaces. 981 file "ietf-interfaces-ethernet-like@2017-07-03.yang" 982 module ietf-interfaces-ethernet-like { 983 yang-version 1.1; 985 namespace 986 "urn:ietf:params:xml:ns:yang:ietf-interfaces-ethernet-like"; 988 prefix ethlike; 990 import ietf-interfaces { 991 prefix if; 992 } 994 import ietf-yang-types { 995 prefix yang; 996 } 998 import iana-if-type { 999 prefix ianaift; 1000 } 1002 organization 1003 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1005 contact 1006 "WG Web: 1007 WG List: 1009 WG Chair: Lou Berger 1010 1012 WG Chair: Kent Watsen 1013 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 Copyright (c) 2016 IETF Trust and the persons identified as 1026 authors of the code. All rights reserved. 1028 Redistribution and use in source and binary forms, with or 1029 without modification, is permitted pursuant to, and subject 1030 to the license terms contained in, the Simplified BSD License 1031 set forth in Section 4.c of the IETF Trust's Legal Provisions 1032 Relating to IETF Documents 1033 (http://trustee.ietf.org/license-info). 1035 This version of this YANG module is part of XXX; see the RFC 1036 itself for full legal notices."; 1038 revision 2017-07-03 { 1039 description "Updated to conform to NMDA architecture"; 1041 reference 1042 "Internet draft: draft-ietf-netmod-intf-ext-yang-05"; 1043 } 1045 /* 1046 * Configuration parameters for Ethernet-like interfaces. 1047 */ 1048 augment "/if:interfaces/if:interface" { 1049 when "derived-from-or-self(if:type, 'ianaift:ethernetCsmacd') or 1050 derived-from-or-self(if:type, 'ianaift:ieee8023adLag') or 1051 derived-from-or-self(if:type, 'ianaift:l2vlan') or 1052 derived-from-or-self(if:type, 'ianaift:ifPwType')" { 1053 description "Applies to all Ethernet-like interfaces"; 1054 } 1055 description 1056 "Augment the interface model with parameters for all 1057 Ethernet-like interfaces"; 1059 container ethernet-like { 1060 description 1061 "Contains parameters for interfaces that use Ethernet framing 1062 and expose an Ethernet MAC layer."; 1063 leaf mac-address { 1064 type yang:mac-address; 1065 description 1066 "The MAC address of the interface."; 1067 } 1069 leaf bia-mac-address { 1070 type yang:mac-address; 1071 config false; 1072 description 1073 "The 'burnt-in' MAC address. I.e the default MAC address 1074 assigned to the interface if no MAC address has been 1075 explicitly configured on it."; 1076 } 1078 container statistics { 1079 config false; 1080 description 1081 "Packet statistics that apply to all Ethernet-like 1082 interfaces"; 1083 leaf in-drop-unknown-dest-mac-pkts { 1084 type yang:counter64; 1085 units frames; 1086 description 1087 "A count of the number of frames that were well formed, 1088 but otherwise dropped because the destination MAC 1089 address did not pass any ingress destination MAC address 1090 filter. 1092 For consistency, frames counted against this drop 1093 counters are also counted against the IETF interfaces 1094 statistics. In particular, they are included in 1095 in-octets and in-discards, but are not included in 1096 in-unicast-pkts, in-multicast-pkts or in-broadcast-pkts, 1097 because they are not delivered to a higher layer. 1099 Discontinuities in the values of this counters in this 1100 container can occur at re-initialization of the 1101 management system, and at other times as indicated by 1102 the value of the 'discontinuity-time' leaf defined in 1103 the ietf-interfaces YANG module (RFC 8343)."; 1104 } 1105 } 1106 } 1107 } 1108 } 1109 1111 7. Examples 1113 The following sections give some examples of how different parts of 1114 the YANG modules could be used. Examples are not given for the more 1115 trivial configuration, or for sub-interfaces, for which examples are 1116 contained in [I-D.ietf-netmod-sub-intf-vlan-model]. 1118 7.1. Carrier delay configuration 1120 The following example shows how the operational state datastore could 1121 look like for an Ethernet interface without any carrier delay 1122 configuration. The down leaf value of 0 indicates that link down 1123 events as always propagated to high layers immediately, but an up 1124 leaf value of 50 indicates that the interface must be up and stable 1125 for at least 50 msecs before the interface is reported as being up to 1126 the high layers. 1128 1129 1133 1134 eth0 1135 ianaift:ethernetCsmacd 1136 1137 0 1138 1000 1139 1140 1141 1143 The following example shows explicit carrier delay up and down values 1144 have been configured. A 50 msec down leaf value has been used to 1145 potentially allow optical protection to recover the link before the 1146 higher layer protocol state is flapped. A 1 second (1000 1147 milliseconds) up leaf value has been used to ensure that the link is 1148 always reasonably stable before allowing traffic to be carried over 1149 it. This also has the benefit of greatly reducing the rate at which 1150 higher layer protocol state flaps could occur. 1152 1153 1154 1158 1159 eth0 1160 ianaift:ethernetCsmacd 1161 1162 50 1163 1000 1164 1165 1166 1167 1169 7.2. Dampening configuration 1171 The following example shows what the operational state datastore may 1172 look like for an interface configured with interface dampening. The 1173 'suppressed' leaf indicates that the interface is currently 1174 suppressed (i.e. down) because the 'penalty' is greater than the 1175 'suppress' leaf threshold. The 'time-remaining' leaf indicates that 1176 the interface will remain suppressed for another 103 seconds before 1177 the 'penalty' is below the 'reuse' leaf value and the interface is 1178 allowed to go back up again. 1180 1181 1184 1185 eth0 1186 ianaift:ethernetCsmacd 1187 1189 60 1190 750 1191 2000 1192 240 1193 2480 1194 true 1195 103 1196 1197 1198 1200 7.3. MAC address configuration 1202 The following example shows how the operational state datastore could 1203 look like for an Ethernet interface without an explicit MAC address 1204 configured. The mac-address leaf always reports the actual 1205 operational MAC address that is in use. The bia-mac-address leaf 1206 always reports the default MAC address assigned to the hardware. 1208 1209 1212 1213 eth0 1214 ianaift:ethernetCsmacd 1215 1217 00:00:5E:00:53:30 1218 00:00:5E:00:53:30 1219 1220 1221 1223 The following example shows an explicit MAC address being configured 1224 on interface eth0. 1226 1227 1228 1231 1232 eth0 1233 ianaift:ethernetCsmacd 1234 1236 00:00:5E:00:53:35 1237 1238 1239 1240 1242 After the MAC address configuration has been successfully applied, 1243 the operational state datastore reporting the interface MAC address 1244 properties would contain the following, with the mac-address leaf 1245 updated to match the configured value, but the bia-mac-address leaf 1246 retaining the same value - which should never change. 1248 1249 1252 1253 eth0 1254 ianaift:ethernetCsmacd 1255 1257 00:00:5E:00:53:35 1258 00:00:5E:00:53:30 1259 1260 1261 1263 8. Acknowledgements 1265 The authors wish to thank Eric Gray, Ing-Wher Chen, Juergen 1266 Schoenwaelder, Ladislav Lhotka, Mahesh Jethanandani, Michael Zitao, 1267 Neil Ketley, Qin Wu, William Lupton, Xufeng Liu, and Andy Bierman for 1268 their helpful comments contributing to this draft. 1270 9. ChangeLog 1272 XXX, RFC Editor, please delete this change log before publication. 1274 9.1. Version -06 1276 o Remove reservable-bandwidth, based on Acee's suggestion 1278 o Add examples 1280 o Add additional state parameters for carrier-delay and dampening 1282 9.2. Version -05 1284 o Incorporate feedback from Andy Bierman 1286 9.3. Version -04 1288 o Incorporate feedback from Lada, some comments left as open issues. 1290 9.4. Version -03 1292 o Fixed incorrect module name references, and updated tree output 1294 9.5. Version -02 1296 o Minor changes only: Fix errors in when statements, use derived- 1297 from-or-self() for future proofing. 1299 10. IANA Considerations 1301 This document defines several new YANG module and the authors 1302 politely request that IANA assigns unique names to the YANG module 1303 files contained within this draft, and also appropriate URIs in the 1304 "IETF XML Registry". 1306 11. Security Considerations 1308 The YANG module defined in this memo is designed to be accessed via 1309 the NETCONF protocol RFC 6241 [RFC6241]. The lowest NETCONF layer is 1310 the secure transport layer and the mandatory to implement secure 1311 transport is SSH RFC 6242 [RFC6242]. The NETCONF access control 1312 model RFC 6536 [RFC6536] provides the means to restrict access for 1313 particular NETCONF users to a pre-configured subset of all available 1314 NETCONF protocol operations and content. 1316 There are a number of data nodes defined in this YANG module which 1317 are writable/creatable/deletable (i.e. config true, which is the 1318 default). These data nodes may be considered sensitive or vulnerable 1319 in some network environments. Write operations (e.g. edit-config) to 1320 these data nodes without proper protection can have a negative effect 1321 on network operations. These are the subtrees and data nodes and 1322 their sensitivity/vulnerability: 1324 11.1. interfaces-common.yang 1326 The interfaces-common YANG module contains various configuration 1327 leaves that affect the behavior of interfaces. Modifying these 1328 leaves can cause an interface to go down, or become unreliable, or to 1329 drop traffic forwarded over it. More specific details of the 1330 possible failure modes are given below. 1332 The following leaf could cause the interface to go down, and stop 1333 processing any ingress or egress traffic on the interface: 1335 o /if:interfaces/if:interface/loopback 1337 The following leaves could cause instabilities at the interface link 1338 layer, and cause unwanted higher layer routing path changes if the 1339 leaves are modified, although they would generally only affect a 1340 device that had some underlying link stability issues: 1342 o /if:interfaces/if:interface/carrier-delay/down 1344 o /if:interfaces/if:interface/carrier-delay/up 1346 o /if:interfaces/if:interface/dampening/half-life 1348 o /if:interfaces/if:interface/dampening/reuse 1350 o /if:interfaces/if:interface/dampening/suppress 1352 o /if:interfaces/if:interface/dampening/max-suppress-time 1354 The following leaves could cause traffic loss on the interface 1355 because the received or transmitted frames do not comply with the 1356 frame matching criteria on the interface and hence would be dropped: 1358 o /if:interfaces/if:interface/encapsulation 1360 o /if:interfaces/if:interface/l2-mtu 1362 o /if:interfaces/if:interface/forwarding-mode 1364 Normally devices will not allow the parent-interface leaf to be 1365 changed after the interfce has been created. If an implementation 1366 did allow the parent-interface leaf to be changed then it could cause 1367 all traffic on the affected interface to be dropped. The affected 1368 leaf is: 1370 o /if:interfaces/if:interface/parent-interface 1372 11.2. interfaces-ethernet-like.yang 1374 Generally, the configuration nodes in the interfaces-ethernet-like 1375 YANG module are concerned with configuration that is common across 1376 all types of Ethernet-like interfaces. Currently, the module only 1377 contains a node for configuring the operational MAC address to use on 1378 an interface. Adding/modifying/deleting this leaf has the potential 1379 risk of causing protocol instability, excessive protocol traffic, and 1380 general traffic loss, particularly if the configuration change caused 1381 a duplicate MAC address to be present on the local network . The 1382 following leaf is affected: 1384 o interfaces/interface/ethernet-like/mac-address 1386 12. References 1388 12.1. Normative References 1390 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1391 Requirement Levels", BCP 14, RFC 2119, 1392 DOI 10.17487/RFC2119, March 1997, 1393 . 1395 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1396 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1397 . 1399 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1400 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1401 May 2017, . 1403 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1404 and R. Wilton, "Network Management Datastore Architecture 1405 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1406 . 1408 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1409 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1410 . 1412 12.2. Informative References 1414 [I-D.ietf-netmod-sub-intf-vlan-model] 1415 Wilton, R., Ball, D., tapsingh@cisco.com, t., and S. 1416 Sivaraj, "Sub-interface VLAN YANG Data Models", draft- 1417 ietf-netmod-sub-intf-vlan-model-03 (work in progress), 1418 October 2017. 1420 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1421 and A. Bierman, Ed., "Network Configuration Protocol 1422 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1423 . 1425 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1426 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1427 . 1429 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1430 Protocol (NETCONF) Access Control Model", RFC 6536, 1431 DOI 10.17487/RFC6536, March 2012, 1432 . 1434 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1435 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1436 . 1438 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1439 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1440 . 1442 Authors' Addresses 1444 Robert Wilton (editor) 1445 Cisco Systems 1447 Email: rwilton@cisco.com 1449 David Ball 1450 Cisco Systems 1452 Email: daviball@cisco.com 1454 Tapraj Singh 1455 Cisco Systems 1457 Email: tapsingh@juniper.net 1458 Selvakumar Sivaraj 1459 Juniper Networks 1461 Email: ssivaraj@juniper.net