--- 1/draft-ietf-netmod-intf-ext-yang-02.txt 2016-10-27 09:16:10.287898777 -0700 +++ 2/draft-ietf-netmod-intf-ext-yang-03.txt 2016-10-27 09:16:10.339900083 -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 S. Sivaraj Juniper Networks October 27, 2016 Common Interface Extension YANG Data Models - draft-ietf-netmod-intf-ext-yang-02 + draft-ietf-netmod-intf-ext-yang-03 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 @@ -48,49 +48,52 @@ (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 . . . . . . . . . . . . . . . . . . . . . . . . 2 - 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Interfaces Extensions Module . . . . . . . . . . . . . . . . 4 - 3.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.2. Carrier Delay . . . . . . . . . . . . . . . . . . . . . . 6 - 3.3. Dampening . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.3.1. Suppress Threshold . . . . . . . . . . . . . . . . . 7 + 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.3.2. Half-Life Period . . . . . . . . . . . . . . . . . . 8 - 3.3.3. Reuse Threshold . . . . . . . . . . . . . . . . . . . 8 - 3.3.4. Maximum Suppress Time . . . . . . . . . . . . . . . . 8 - 3.4. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 8 - 3.5. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.6. MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.7. Sub-interface . . . . . . . . . . . . . . . . . . . . . . 9 + 3.3.3. Reuse Threshold . . . . . . . . . . . . . . . . . . . 9 + 3.3.4. Maximum Suppress Time . . . . . . . . . . . . . . . . 9 + 3.4. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 9 + 3.5. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.6. MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.7. Sub-interface . . . . . . . . . . . . . . . . . . . . . . 10 3.8. Transport Layer . . . . . . . . . . . . . . . . . . . . . 10 - 4. Interfaces Ethernet-Like Module . . . . . . . . . . . . . . . 10 - 5. Interfaces Common YANG Module . . . . . . . . . . . . . . . . 10 - 6. Interfaces Ethernet-Like YANG Module . . . . . . . . . . . . 19 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 - 9.1. interfaces-common.yang . . . . . . . . . . . . . . . . . 23 - 9.2. interfaces-ethernet-like.yang . . . . . . . . . . . . . . 24 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 24 - 10.2. Informative References . . . . . . . . . . . . . . . . . 25 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 + 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 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction This document defines two YANG RFC 7950 [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. One of the aims of this draft is to provide a standard namespace and @@ -115,26 +118,26 @@ the common theme that they generically apply to interfaces, it is plausible that not all implementors of the YANG module will decide to support all features. Hence separate feature keywords are defined for each logically discrete feature to allow implementors the flexibility to choose which specific parts of the model they support. The augmentations are split into two separate YANG modules that each focus on a particular area of functionality. The two YANG modules defined in this internet draft are: - interface-extensions.yang - Defines extensions to the IETF + ietf-interfaces-common.yang - Defines extensions to the IETF interface data model to support common configuration data nodes. - etherlike-interfaces.yang - Defines a module for any configuration - and operational data nodes that are common across interfaces that - use Ethernet framing. + ietf-interfaces-ethernet-like.yang - Defines a module for any + configuration and operational data nodes that are common across + interfaces that use Ethernet framing. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2. Tree Diagrams A simplified graphical representation of the data model is used in @@ -162,21 +165,21 @@ 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. -3. Interfaces Extensions Module +3. Interfaces Common Module The Interfaces Common module provides some basic extensions to the IETF interfaces YANG module. The module provides: o A bandwidth configuration leaf to specify the bandwidth available on an interface to control routing metrics. o A carrier delay feature used to provide control over short lived @@ -194,46 +197,46 @@ 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 parent interface leaf useable for all types of sub-interface that are children of parent interfaces. - The "interface-extensions" YANG module has the following structure: + The "ietf-interfaces-common" YANG module has the following structure: module: ietf-interfaces-common augment /if:interfaces/if:interface: - +--rw bandwidth? uint64 + +--rw bandwidth? uint64 {bandwidth}? augment /if:interfaces/if:interface: - +--rw carrier-delay + +--rw carrier-delay {carrier-delay}? +--rw down? uint32 +--rw up? uint32 augment /if:interfaces/if:interface: - +--rw dampening! + +--rw dampening! {dampening}? +--rw half-life? uint32 +--rw reuse? uint32 +--rw suppress? uint32 +--rw max-suppress-time? uint32 augment /if:interfaces/if:interface: +--rw encapsulation +--rw (encaps-type)? augment /if:interfaces/if:interface: - +--rw loopback? identityref + +--rw loopback? identityref {loopback}? augment /if:interfaces/if:interface: +--rw l2-mtu? uint16 {configurable-l2-mtu}? augment /if:interfaces/if:interface: - +--rw parent-interface? if:interface-ref + +--rw parent-interface if:interface-ref {sub-interfaces}? augment /if:interfaces/if:interface: - +--rw transport-layer? enumeration + +--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, @@ -444,21 +447,21 @@ 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 (BIA) associated with any interface using Ethernet framing. - The "interfaces-ethernet-like" YANG module has the following + The "ietf-interfaces-ethernet-like" YANG module has the following 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 @@ -514,21 +519,21 @@ 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 { description "Initial version"; - reference "Internet draft: draft-ietf-netmod-intf-ext-yang-02"; + reference "Internet draft: draft-ietf-netmod-intf-ext-yang-03"; } feature bandwidth { description "This feature indicates that the device supports configurable interface bandwidth."; reference "Section 3.1 Bandwidth"; } feature carrier-delay { @@ -886,21 +889,21 @@ 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 Etherlike interfaces. This includes Ethernet + [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" module ietf-interfaces-ethernet-like { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces-ethernet-like"; @@ -950,25 +955,24 @@ 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 { description "Updated reference to new internet draft name."; reference - "Internet draft: draft-ietf-netmod-intf-ext-yang-02"; + "Internet draft: draft-ietf-netmod-intf-ext-yang-03"; } - /* - * Configuration parameters for Etherlike interfaces. + * 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"; } description "Augment the interface model with configuration parameters for @@ -980,21 +984,21 @@ MAC layer."; leaf mac-address { type yang:mac-address; description "The configured MAC address of the interface."; } } } /* - * Operational state for Etherlike interfaces. + * Operational state for Ethernet-like interfaces. */ augment "/if:interfaces-state/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"; } description "Augments the interface model with operational state parameters @@ -1017,50 +1022,62 @@ assigned to the interface if none is explicitly configured."; } } } } 7. Acknowledgements - The authors wish to thank Juergen Schoenwaelder, Mahesh Jethanandani, - Michael Zitao, Neil Ketley and Qin Wu for their helpful comments + 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. -8. IANA Considerations +8. ChangeLog + +8.1. Version -03 + + o Fixed incorrect module name references, and updated tree output + +8.2. Version -02 + + o Minor changes only: Fix errors in when statements, use derived- + from-or-self() for future proofing. + +9. 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". -9. Security Considerations +10. 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: -9.1. interfaces-common.yang +10.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: @@ -1103,56 +1120,56 @@ o /if:interfaces/if:interface/transport-layer 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 -9.2. interfaces-ethernet-like.yang +10.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 -10. References +11. References -10.1. Normative References +11.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, . -10.2. Informative References +11.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, .