--- 1/draft-ietf-netmod-intf-ext-yang-03.txt 2017-03-13 09:15:05.924489978 -0700 +++ 2/draft-ietf-netmod-intf-ext-yang-04.txt 2017-03-13 09:15:05.984491391 -0700 @@ -1,21 +1,21 @@ Internet Engineering Task Force R. Wilton, Ed. Internet-Draft D. Ball Intended status: Standards Track T. Singh -Expires: April 30, 2017 Cisco Systems +Expires: September 14, 2017 Cisco Systems S. Sivaraj Juniper Networks - October 27, 2016 + March 13, 2017 Common Interface Extension YANG Data Models - draft-ietf-netmod-intf-ext-yang-03 + draft-ietf-netmod-intf-ext-yang-04 Abstract This document defines two YANG modules that augment the Interfaces data model defined in the "YANG Data Model for Interface Management" with additional configuration and operational data nodes to support common lower layer interface properties, such as interface MTU. These properties are common to many types of interfaces on network routers and switches and are implemented by multiple network equipment vendors with similar semantics, even though some of the @@ -29,79 +29,81 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 30, 2017. + This Internet-Draft will expire on September 14, 2017. Copyright Notice - Copyright (c) 2016 IETF Trust and the persons identified as the + Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Interfaces Common Module . . . . . . . . . . . . . . . . . . 4 3.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.2. Carrier Delay . . . . . . . . . . . . . . . . . . . . . . 7 - 3.3. Dampening . . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.3.1. Suppress Threshold . . . . . . . . . . . . . . . . . 8 + 3.2. Carrier Delay . . . . . . . . . . . . . . . . . . . . . . 6 + 3.3. Dampening . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.3.1. Suppress Threshold . . . . . . . . . . . . . . . . . 7 3.3.2. Half-Life Period . . . . . . . . . . . . . . . . . . 8 - 3.3.3. Reuse Threshold . . . . . . . . . . . . . . . . . . . 9 - 3.3.4. Maximum Suppress Time . . . . . . . . . . . . . . . . 9 - 3.4. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 9 - 3.5. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.3.3. Reuse Threshold . . . . . . . . . . . . . . . . . . . 8 + 3.3.4. Maximum Suppress Time . . . . . . . . . . . . . . . . 8 + 3.4. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 8 + 3.5. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 8 3.6. MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.7. Sub-interface . . . . . . . . . . . . . . . . . . . . . . 10 - 3.8. Transport Layer . . . . . . . . . . . . . . . . . . . . . 10 - 4. Interfaces Ethernet-Like Module . . . . . . . . . . . . . . . 11 - 5. Interfaces Common YANG Module . . . . . . . . . . . . . . . . 11 - 6. Interfaces Ethernet-Like YANG Module . . . . . . . . . . . . 20 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 - 8. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 8.1. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 23 - 8.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 23 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 - 10.1. interfaces-common.yang . . . . . . . . . . . . . . . . . 24 - 10.2. interfaces-ethernet-like.yang . . . . . . . . . . . . . 25 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 - 11.2. Informative References . . . . . . . . . . . . . . . . . 26 + 3.7. Sub-interface . . . . . . . . . . . . . . . . . . . . . . 9 + 3.8. Forwarding Mode . . . . . . . . . . . . . . . . . . . . . 9 + 4. Interfaces Ethernet-Like Module . . . . . . . . . . . . . . . 10 + 5. Interfaces Common YANG Module . . . . . . . . . . . . . . . . 10 + 6. Interfaces Ethernet-Like YANG Module . . . . . . . . . . . . 19 + 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 + 9. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 9.1. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 23 + 9.2. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 23 + 9.3. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 23 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 + 11.1. interfaces-common.yang . . . . . . . . . . . . . . . . . 24 + 11.2. interfaces-ethernet-like.yang . . . . . . . . . . . . . 25 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 25 + 12.2. Informative References . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction - This document defines two YANG RFC 7950 [RFC7950] modules for the + This document defines two YANG 1.1 [RFC7950] modules for the management of network interfaces. It defines various augmentations - to the generic interfaces data model defined in RFC 7223 [RFC7223] to - support configuration of lower layer interface properties that are - common across many types of network interface. + to the generic interfaces data model [RFC7223] to support + configuration of lower layer interface properties that are common + across many types of network interface. One of the aims of this draft is to provide a standard namespace and path for these configuration items regardless of the underlying interface type. For example a standard namespace and path for configuring or reading the MAC address associated with an interface is provided that can be used for any interface type that uses Ethernet framing. Several of the augmentations defined here are not backed by any formal standard specification. Instead, they are for features that @@ -153,21 +155,21 @@ means a presence container, and "*" denotes a list or leaf-list. o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":"). o Ellipsis ("...") stands for contents of subtrees that are not shown. 2. Objectives - The aim of of the YANG modules contained in this draft is to provide + The aim of the YANG modules contained in this draft is to provide standard definitions for common interface based configuration on network devices. The expectation is that the YANG leaves that are being defined are fairly widely implemented by network vendors. However, the features described here are mostly not backed by formal standards because they are fairly basic in their behavior and do not need to interoperate with other devices. Where required a concise explanation of the expected behavior is also provided to ensure consistency between vendors. @@ -191,52 +193,46 @@ o An encapsulation container and extensible choice statement for use by any interface types that allow for configurable L2 encapsulations. o A loopback configuration leaf that is primarily aimed at loopback at the physical layer. o MTU configuration leaves applicable to all packet/frame based interfaces. - o A transport layer leaf to indicate whether the interface handles - traffic at L1, L2 or L3. + o A forwarding mode leaf to indicate the OSI layer at which the + interface handles traffic o A parent interface leaf useable for all types of sub-interface that are children of parent interfaces. The "ietf-interfaces-common" YANG module has the following structure: module: ietf-interfaces-common augment /if:interfaces/if:interface: +--rw bandwidth? uint64 {bandwidth}? - augment /if:interfaces/if:interface: +--rw carrier-delay {carrier-delay}? - +--rw down? uint32 - +--rw up? uint32 - augment /if:interfaces/if:interface: + | +--rw down? uint32 + | +--rw up? uint32 +--rw dampening! {dampening}? - +--rw half-life? uint32 - +--rw reuse? uint32 - +--rw suppress? uint32 - +--rw max-suppress-time? uint32 - augment /if:interfaces/if:interface: + | +--rw half-life? uint32 + | +--rw reuse? uint32 + | +--rw suppress? uint32 + | +--rw max-suppress-time? uint32 +--rw encapsulation - +--rw (encaps-type)? - augment /if:interfaces/if:interface: + | +--rw (encaps-type)? +--rw loopback? identityref {loopback}? - augment /if:interfaces/if:interface: +--rw l2-mtu? uint16 {configurable-l2-mtu}? + +--rw forwarding-mode? identityref {forwarding-mode}? augment /if:interfaces/if:interface: +--rw parent-interface if:interface-ref {sub-interfaces}? - augment /if:interfaces/if:interface: - +--rw transport-layer? enumeration {transport-layer}? 3.1. Bandwidth The bandwidth configuration leaf allows the specified bandwidth of an interface to be reduced from the inherent interface bandwidth. The bandwidth leaf affects the routing metric cost associated with the interface. Note that the bandwidth leaf does not actually limit the amount of traffic that can be sent/received over the interface. If required, @@ -366,46 +362,32 @@ 3.5. Loopback The loopback configuration leaf allows any physical interface to be configured to be in one of the possible following physical loopback modes, i.e. internal loopback, line loopback, or use of an external loopback connector. The use of YANG identities allows for the model to be extended with other modes of loopback if required. 3.6. MTU - Two MTU configuration leaves are provided to program the layer 2 - interface in two different ways. Different mechanisms are provided - to reflect the fact that devices handle their MTU configuration in - different ways. A given device would only normally be expected to - support MTU configuration using one of these mechanisms. - - The preferable way to configure MTU is using the l2-mtu leaf that - specifies the maximum size of a layer 2 frame including header and - payload, but excluding any frame check sequence (FCS) bytes. The - payload MTU available to higher layer protocols is calculated from - the l2-mtu after taking the layer 2 header size into account. + A layer 2 MTU configuration leaf (l2-mtu) is provided to specify the + maximum size of a layer 2 frame that may be transmitted or received + on an interface. The layer 2 MTU includes the overhead of the layer + 2 header and the maximum length of the payload, but excludes any + frame check sequence (FCS) bytes. The payload MTU available to + higher layer protocols is calculated from the l2-mtu leaf after + taking the layer 2 header size into account. For Ethernet interfaces carrying 802.1Q VLAN tagged frames, the l2-mtu excludes the 4-8 byte overhead of any known (e.g. explicitly matched by a child sub-interface) 801.1Q VLAN tags. - The alternative way to configure MTU is using the l3-mtu leaf that - specifies the maximum size of payload carried by a layer 2 frame. - The maximum size of the layer 2 frame can then be derived by adding - on the size of the layer 2 header overheads. - - Note for reviewers: Is it correct/beneficial to support l3-mtu? It - would be easier for clients if they only had a single MTU that they - could configure. Can all devices sensibly handle an l2-mtu - configuration leaf? - 3.7. Sub-interface The sub-interface feature specifies the minimal leaves required to define a child interface that is parented to another interface. A sub-interface is a logical interface that handles a subset of the traffic on the parent interface. Separate configuration leaves are used to classify the subset of ingress traffic received on the parent interface to be processed in the context of a given sub-interface. All egress traffic processed on a sub-interface is given to the @@ -421,34 +403,34 @@ Even in this case it is useful to have a well defined leaf to cleanly identify the parent interface. The model also allows for arbitrarily named sub-interfaces by having an explicit parent-interface leaf define the child -> parent relationship. In this naming scenario it is also possible for implementations to allow for logical interfaces to be reparented to new parent interfaces without needing the sub-interface to be destroyed and recreated. -3.8. Transport Layer +3.8. Forwarding Mode - The transport layer leaf provides additional information as to which - layer an interface is logically operating and forwarding traffic at. - The implication of this leaf is that for traffic forwarded at a given - layer that any headers for lower layers are stripped off before the - packet is forwarded at the given layer. Conversely, on egress any - lower layer headers must be added to the packet before it is - transmitted out of the interface. + The forwarding mode leaf provides additional information as to what + mode or layer an interface is logically operating and forwarding + traffic at. The implication of this leaf is that for traffic + forwarded at a given layer that any headers for lower layers are + stripped off before the packet is forwarded at the given layer. + Conversely, on egress any lower layer headers must be added to the + packet before it is transmitted out of the interface. This leaf can also be used as a simple mechanism to determine whether particular types of configuration are valid. E.g. a layer 2 QoS - policy could ensure that it is only applied to a interface running at - transport layer 2. + policy could ensure that it is only applied to a interface forwarding + traffic at layer 2. 4. Interfaces Ethernet-Like Module The Interfaces Ethernet-Like Module is a small module that contains all configuration and operational data that is common across interface types that use Ethernet framing as their datalink layer encapsulation. This module currently contains leaves for the configuration and reporting of the operational MAC address and the burnt-in MAC address @@ -458,37 +440,37 @@ structure: module: ietf-interfaces-ethernet-like augment /if:interfaces/if:interface: +--rw ethernet-like +--rw mac-address? yang:mac-address augment /if:interfaces-state/if:interface: +--ro ethernet-like +--ro mac-address? yang:mac-address +--ro bia-mac-address? yang:mac-address + +--ro statistics + +--ro in-drop-unknown-dest-mac-pkts? yang:counter64 5. Interfaces Common YANG Module This YANG module augments the interface container defined in RFC 7223 [RFC7223]. - file "ietf-interfaces-common@2016-10-27.yang" + file "ietf-interfaces-common@2017-03-13.yang" module ietf-interfaces-common { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces-common"; - prefix if-cmn; import ietf-interfaces { prefix if; - } import iana-if-type { prefix ianaift; } organization "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; contact @@ -502,38 +484,38 @@ Editor: Robert Wilton "; description "This module contains common definitions for extending the IETF interface YANG model (RFC 7223) with common configurable layer 2 properties. - Copyright (c) 2016 IETF Trust and the persons identified as - authors of the code. All rights reserved. + Copyright (c) 2016, 2017 IETF Trust and the persons identified + as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of XXX; see the RFC itself for full legal notices."; - revision 2016-10-27 { + revision 2017-03-13 { description "Initial version"; - reference "Internet draft: draft-ietf-netmod-intf-ext-yang-03"; + reference "Internet draft: draft-ietf-netmod-intf-ext-yang-04"; } feature bandwidth { description "This feature indicates that the device supports configurable interface bandwidth."; reference "Section 3.1 Bandwidth"; } feature carrier-delay { @@ -576,102 +558,122 @@ feature sub-interfaces { description "This feature indicates that the device supports the instantiation of sub-interfaces. Sub-interfaces are defined as logical child interfaces that allow features and forwarding decisions to be applied to a subset of the traffic processed on the specified parent interface."; reference "Section 3.7 Sub-interface"; } - feature transport-layer { + feature forwarding-mode { description - "This feature indicates that the device supports configurable - transport layer."; - reference "Section 3.8 Transport Layer"; + "This feature indicates that the device supports the + configurable forwarding mode leaf"; + reference "Section 3.8 Forwarding Mode"; } /* * Define common identities to help allow interface types to be * assigned properties. */ identity sub-interface { description "Base type for generic sub-interfaces. New or custom interface types can derive from this type to inherit generic sub-interface configuration"; } identity ethSubInterface{ base ianaift:l2vlan; base sub-interface; - description "Sub-interface of any interface types that uses - Ethernet framing (with or without 802.1Q tagging)"; + description + "Sub-interface of any interface types that uses Ethernet + framing (with or without 802.1Q tagging)"; } identity loopback { - description "Base type for interface loopback options"; + description "Base identity for interface loopback options"; } identity loopback-internal { base loopback; - description "All egress traffic on the interface is internally - looped back within the interface to be received on - the ingress path."; + description + "All egress traffic on the interface is internally looped back + within the interface to be received on the ingress path."; } identity loopback-line { base loopback; - description "All ingress traffic received on the interface is - internally looped back within the interface to the - egress path."; + description + "All ingress traffic received on the interface is internally + looped back within the interface to the egress path."; } identity loopback-connector { base loopback; - description "The interface has a physical loopback connector - attached to that loops all egress traffic back into - the interface's ingress path, with equivalent - semantics to loopback-internal"; + description + "The interface has a physical loopback connector attached to + that loops all egress traffic back into the interface's + ingress path, with equivalent semantics to loopback-internal"; + } + + identity forwarding-mode { + description "Base identity for forwarding-mode options"; + } + identity optical-layer { + base forwarding-mode; + description + "Traffic is being forwarded at the optical layer. This + includes DWDM or OTN based switching"; + } + identity layer-2-forwarding { + base forwarding-mode; + description + "Layer 2 based forwarding, such as Ethernet/VLAN based + switching, or L2VPN services."; + } + identity network-layer { + base forwarding-mode; + description + "Network layer based forwarding, such as IP, MPLS, or L3VPNs"; } /* * Augments the IETF interfaces model with a leaf to explicitly * specify the bandwidth available on an interface. */ augment "/if:interfaces/if:interface" { - if-feature "bandwidth"; + description + "Augments the IETF interface model with optional common + interface level commands that are not formally covered by any + specific standard"; - description "Add a top level node for interface bandwidth."; leaf bandwidth { + if-feature "bandwidth"; type uint64; units kbps; description "The bandwidth available on the interface in Kb/s. This configuration is used by routing protocols to adjust the metrics associated with the interface, but does not limit the amount of traffic that can be sent or received on the interface. A separate QoS policy would need to be configured to limit the ingress or egress traffic. If not configured, the default bandwidth is the maximum available bandwidth of the underlying interface."; } - } /* * Defines standard YANG for the Carrier Delay feature. */ - augment "/if:interfaces/if:interface" { - if-feature "carrier-delay"; - description "Augments the IETF interface model with - carrier delay configuration for interfaces that - support it."; container carrier-delay { - description "Holds carrier delay related feature - configuration"; + if-feature "carrier-delay"; + description + "Holds carrier delay related feature configuration"; leaf down { type uint32; units milliseconds; description "Delays the propagation of a 'loss of carrier signal' event that would cause the interface state to go down, i.e. the command allows short link flaps to be suppressed. The configured value indicates the minimum time interval (in milliseconds) that the carrier signal must be continuously down before the interface state is brought down. If not @@ -688,36 +690,33 @@ error free before the interface state is allowed to transition from down to up. If not configured, the behaviour is vendor/interface specific, but with the general expectation that sufficient default delay should be used to ensure that the interface is stable when enabled before being reported as being up. Configured values that are too low for the hardware capabilties may be rejected."; } } - } /* * Augments the IETF interfaces model with a container to hold * generic interface dampening */ - augment "/if:interfaces/if:interface" { + container dampening { if-feature "dampening"; + presence + "Enable interface link flap dampening with default settings + (that are vendor/device specific)"; description - "Add a container for interface dampening configuration"; - - container dampening { - presence "Enable interface link flap dampening with default - settings (that are vendor/device specific)"; - description "Interface dampening limits the propagation of - interface link state flaps over longer periods"; + "Interface dampening limits the propagation of interface link + state flaps over longer periods"; leaf half-life { type uint32; units seconds; description "The Time (in seconds) after which a penalty reaches half its original value. Once the interface has been assigned a penalty, the penalty is decreased by half after the half-life period. For some devices, the allowed values may be restricted to particular multiples of seconds. The default value is vendor/device specific."; @@ -744,170 +743,150 @@ leaf max-suppress-time { type uint32; units seconds; description "Maximum time (in seconds) that an interface can be suppressed. This value effectively acts as a ceiling that the penalty value cannot exceed. The default value is vendor/device specific."; } } - } /* * Various types of interfaces support a configurable layer 2 * encapsulation, any that are supported by YANG should be * listed here. * * Different encapsulations can hook into the common encaps-type * choice statement. */ - augment "/if:interfaces/if:interface" { - when "derived-from-or-self(if:type, 'ianaift:ethernetCsmacd') or - derived-from-or-self(if:type, 'ianaift:ieee8023adLag') or - derived-from-or-self(if:type, 'ianaift:pos') or - derived-from-or-self(if:type, 'ianaift:atmSubInterface') or - derived-from-or-self(if:type, 'ethSubInterface')" { - description "All interface types that can have a configurable - L2 encapsulation"; + container encapsulation { + when + "derived-from-or-self(../if:type, + 'ianaift:ethernetCsmacd') or + derived-from-or-self(../if:type, + 'ianaift:ieee8023adLag') or + derived-from-or-self(../if:type, 'ianaift:pos') or + derived-from-or-self(../if:type, + 'ianaift:atmSubInterface') or + derived-from-or-self(../if:type, 'ethSubInterface')" { + + description + "All interface types that can have a configurable L2 + encapsulation"; /* * TODO - Should we introduce an abstract type to make this - * extensible to new interface types, or vendor specific - * interface types? + * extensible to new interface types, or vendor + * specific interface types? */ } - description "Add encapsulation top level node to interface types - that support a configurable L2 encapsulation"; - - container encapsulation { description - "Holds the L2 encapsulation associated with an interface"; + "Holds the OSI layer 2 encapsulation associated with an + interface"; choice encaps-type { description "Extensible choice of L2 encapsulations"; } } - } /* - * Various types of interfaces support loopback configuration, any - * that are supported by YANG should be listed here. + * Various types of interfaces support loopback configuration, + * any that are supported by YANG should be listed here. */ - augment "/if:interfaces/if:interface" { - when "derived-from-or-self(if:type, 'ianaift:ethernetCsmacd') or - derived-from-or-self(if:type, 'ianaift:sonet') or - derived-from-or-self(if:type, 'ianaift:atm') or - derived-from-or-self(if:type, 'ianaift:otnOtu')" { + leaf loopback { + when "derived-from-or-self(../if:type, + 'ianaift:ethernetCsmacd') or + + derived-from-or-self(../if:type, 'ianaift:sonet') or + derived-from-or-self(../if:type, 'ianaift:atm') or + derived-from-or-self(../if:type, 'ianaift:otnOtu')" { description "All interface types that support loopback configuration."; } if-feature "loopback"; - description "Augments the IETF interface model with loopback - configuration for interfaces that support it."; - - leaf loopback { type identityref { base loopback; } description "Enables traffic loopback."; } - } /* * Many types of interfaces support a configurable layer 2 MTU. */ - augment "/if:interfaces/if:interface" { - description "Add configurable layer 2 MTU to all appropriate - interface types."; - leaf l2-mtu { if-feature "configurable-l2-mtu"; type uint16 { range "64 .. 65535"; } description "The maximum size of layer 2 frames that may be transmitted or received on the interface (excluding any FCS overhead). In the case of Ethernet interfaces it also excludes the 4-8 byte overhead of any known (i.e. explicitly matched by a child sub-interface) 801.1Q VLAN tags."; } + + /* + * Augments the IETF interfaces model with a leaf that indicates + * which mode, or layer, is being used to forward the traffic. + */ + leaf forwarding-mode { + if-feature "forwarding-mode"; + type identityref { + base forwarding-mode; + } + + description + "The forwarding mode that the interface is operating in"; + } } /* * Add generic support for sub-interfaces. * * This should be extended to cover all interface types that are * child interfaces of other interfaces. */ augment "/if:interfaces/if:interface" { when "derived-from(if:type, 'sub-interface') or derived-from-or-self(if:type, 'ianaift:atmSubInterface') or derived-from-or-self(if:type, 'ianaift:frameRelay')" { description "Any ianaift:types that explicitly represent sub-interfaces or any types that derive from the sub-interface identity"; } if-feature "sub-interfaces"; - description "Add a parent interface field to interfaces that - model sub-interfaces"; + + description + "Add a parent interface field to interfaces that model + sub-interfaces"; leaf parent-interface { + type if:interface-ref; mandatory true; description "This is the reference to the parent interface of this sub-interface."; } } - - /* - * Augments the IETF interfaces model with a leaf that indicates - * which layer traffic is to be transported at. - */ - augment "/if:interfaces/if:interface" { - if-feature "transport-layer"; - description "Add a top level node to appropriate interfaces to - indicate which tranport layer an interface is - operating at"; - - leaf transport-layer { - type enumeration { - enum layer-1 { - value 1; - description "Layer 1 transport."; - } - enum layer-2 { - value 2; - description "Layer 2 transport"; - } - enum layer-3 { - value 3; - description "Layer 3 transport"; - } - } - default layer-3; - description - "The transport layer at which the interface is operating at"; - } - } } 6. Interfaces Ethernet-Like YANG Module This YANG module augments the interface container defined in RFC 7223 [RFC7223] for Ethernet-like interfaces. This includes Ethernet interfaces, 802.3 LAG (802.1AX) interfaces, VLAN sub-interfaces, Switch Virtual interfaces, and Pseudo-Wire Head-End interfaces. - file "ietf-interfaces-ethernet-like@2016-10-27.yang" + file "ietf-interfaces-ethernet-like@2017-03-13.yang" module ietf-interfaces-ethernet-like { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces-ethernet-like"; prefix ethlike; import ietf-interfaces { prefix if; @@ -951,25 +930,24 @@ Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of XXX; see the RFC itself for full legal notices."; - revision 2016-10-27 { + revision 2017-03-13 { description "Updated reference to new internet draft name."; - reference - "Internet draft: draft-ietf-netmod-intf-ext-yang-03"; + "Internet draft: draft-ietf-netmod-intf-ext-yang-04"; } /* * Configuration parameters for Ethernet-like interfaces. */ augment "/if:interfaces/if:interface" { when "derived-from-or-self(if:type, 'ianaift:ethernetCsmacd') or derived-from-or-self(if:type, 'ianaift:ieee8023adLag') or derived-from-or-self(if:type, 'ianaift:l2vlan') or derived-from-or-self(if:type, 'ianaift:ifPwType')" { description "Applies to all Ethernet-like interfaces"; @@ -1005,79 +983,123 @@ for all Ethernet-like interfaces."; container ethernet-like { description "Contains operational state parameters for interfaces that use Ethernet framing and expose an Ethernet MAC layer."; leaf mac-address { type yang:mac-address; description "The operational MAC address of the interface, if applicable"; - } leaf bia-mac-address { type yang:mac-address; description "The 'burnt-in' MAC address. I.e the default MAC address assigned to the interface if none is explicitly configured."; } + + container statistics { + description + "Packet statistics that apply to all Ethernet-like + interfaces"; + leaf in-drop-unknown-dest-mac-pkts { + type yang:counter64; + units frames; + description + "A count of the number of frames that were well formed, + but otherwise dropped because the destination MAC + address did not pass any ingress destination MAC address + filter. + + For consistency, frames counted against this drop + counters are also counted against the IETF interfaces + statistics. In particular, they are included in + in-octets and in-discards, but are not included in + in-unicast-pkts, in-multicast-pkts or in-broadcast-pkts, + because they are not delivered to a higher layer. + + Discontinuities in the values of this counters in this + container can occur at re-initialization of the + management system, and at other times as indicated by + the value of the 'discontinuity-time' leaf defined in + the ietf-interfaces YANG module (RFC 7223)."; + } + } } } } -7. Acknowledgements +7. Open Issues + + Open issues: + + 1. Should the loopback leaf be extended to also cover features such + as dataplane loopback? + + 2. Does loopback need a action statement to allow it to be enabled + in an ephemeral way (specifically lost on reboot)? + + 3. Should the bandwidth leaf be renamed 'reported-bandwidth'? + Should this leaf be defined in a routing YANG module? + +8. Acknowledgements The authors wish to thank Eric Gray, Ing-Wher Chen, Juergen - Schoenwaelder, Mahesh Jethanandani, Michael Zitao, Neil Ketley, Qin - Wu, William Lupton, and Xufeng Liu for their helpful comments - contributing to this draft. + Schoenwaelder, Ladislav Lhotka, Mahesh Jethanandani, Michael Zitao, + Neil Ketley, Qin Wu, William Lupton, and Xufeng Liu for their helpful + comments contributing to this draft. -8. ChangeLog +9. ChangeLog -8.1. Version -03 +9.1. Version -04 + + o Incorporate feedback from Lada, some comments left as open issues. + +9.2. Version -03 o Fixed incorrect module name references, and updated tree output -8.2. Version -02 +9.3. Version -02 o Minor changes only: Fix errors in when statements, use derived- from-or-self() for future proofing. -9. IANA Considerations +10. IANA Considerations This document defines several new YANG module and the authors politely request that IANA assigns unique names to the YANG module files contained within this draft, and also appropriate URIs in the "IETF XML Registry". -10. Security Considerations +11. Security Considerations The YANG module defined in this memo is designed to be accessed via the NETCONF protocol RFC 6241 [RFC6241]. The lowest NETCONF layer is the secure transport layer and the mandatory to implement secure transport is SSH RFC 6242 [RFC6242]. The NETCONF access control model RFC 6536 [RFC6536] provides the means to restrict access for particular NETCONF users to a pre-configured subset of all available NETCONF protocol operations and content. There are a number of data nodes defined in this YANG module which are writable/creatable/deletable (i.e. config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g. edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: -10.1. interfaces-common.yang +11.1. interfaces-common.yang The interfaces-common YANG module contains various configuration leaves that affect the behavior of interfaces. Modifying these leaves can cause an interface to go down, or become unreliable, or to drop traffic forwarded over it. More specific details of the possible failure modes are given below. The following leaf could cause the interface to go down, and stop processing any ingress or egress traffic on the interface: @@ -1098,78 +1120,76 @@ o /if:interfaces/if:interface/carrier-delay/down o /if:interfaces/if:interface/carrier-delay/up o /if:interfaces/if:interface/dampening/half-life o /if:interfaces/if:interface/dampening/reuse o /if:interfaces/if:interface/dampening/suppress - o /if:interfaces/if:interface/dampening/max-suppress-time + The following leaves could cause traffic loss on the interface because the received or transmitted frames do not comply with the frame matching criteria on the interface and hence would be dropped: o /if:interfaces/if:interface/encapsulation o /if:interfaces/if:interface/l2-mtu - o /if:interfaces/if:interface/l3-mtu - - o /if:interfaces/if:interface/transport-layer + o /if:interfaces/if:interface/forwarding-mode Normally devices will not allow the parent-interface leaf to be changed after the interfce has been created. If an implementation did allow the parent-interface leaf to be changed then it could cause all traffic on the affected interface to be dropped. The affected leaf is: o /if:interfaces/if:interface/parent-interface -10.2. interfaces-ethernet-like.yang +11.2. interfaces-ethernet-like.yang Generally, the configuration nodes in the interfaces-ethernet-like YANG module are concerned with configuration that is common across all types of Ethernet-like interfaces. Currently, the module only contains a node for configuring the operational MAC address to use on an interface. Adding/modifying/deleting this leaf has the potential risk of causing protocol instability, excessive protocol traffic, and general traffic loss, particularly if the configuration change caused a duplicate MAC address to be present on the local network . The following leaf is affected: o interfaces/interface/ethernet-like/mac-address -11. References +12. References -11.1. Normative References +12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7223] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, . [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", RFC 7224, DOI 10.17487/RFC7224, May 2014, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . -11.2. Informative References +12.2. Informative References [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, .