--- 1/draft-ietf-netmod-intf-ext-yang-06.txt 2019-03-05 03:13:10.575173093 -0800 +++ 2/draft-ietf-netmod-intf-ext-yang-07.txt 2019-03-05 03:13:10.631174459 -0800 @@ -1,105 +1,105 @@ Internet Engineering Task Force R. Wilton, Ed. Internet-Draft D. Ball Intended status: Standards Track T. Singh -Expires: January 3, 2019 Cisco Systems +Expires: September 6, 2019 Cisco Systems S. Sivaraj Juniper Networks - July 2, 2018 + March 5, 2019 Common Interface Extension YANG Data Models - draft-ietf-netmod-intf-ext-yang-06 + draft-ietf-netmod-intf-ext-yang-07 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 - features are not formally defined in any published standard. + + The YANG data model in this document conforms to the Network + Management Datastore Architecture (NMDA) defined in RFC 8342. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 https://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 January 3, 2019. + This Internet-Draft will expire on September 6, 2019. Copyright Notice - Copyright (c) 2018 IETF Trust and the persons identified as the + Copyright (c) 2019 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 (https://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. Carrier Delay . . . . . . . . . . . . . . . . . . . . . . 6 - 3.2. Dampening . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.2.1. Suppress Threshold . . . . . . . . . . . . . . . . . 8 - 3.2.2. Half-Life Period . . . . . . . . . . . . . . . . . . 8 - 3.2.3. Reuse Threshold . . . . . . . . . . . . . . . . . . . 8 - 3.2.4. Maximum Suppress Time . . . . . . . . . . . . . . . . 8 + 3.1. Carrier Delay . . . . . . . . . . . . . . . . . . . . . . 5 + 3.2. Dampening . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.2.1. Suppress Threshold . . . . . . . . . . . . . . . . . 7 + 3.2.2. Half-Life Period . . . . . . . . . . . . . . . . . . 7 + 3.2.3. Reuse Threshold . . . . . . . . . . . . . . . . . . . 7 + 3.2.4. Maximum Suppress Time . . . . . . . . . . . . . . . . 7 3.3. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 8 - 3.4. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.5. Layer 2 MTU . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.4. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.5. Layer 2 MTU . . . . . . . . . . . . . . . . . . . . . . . 8 3.6. Sub-interface . . . . . . . . . . . . . . . . . . . . . . 9 - 3.7. Forwarding Mode . . . . . . . . . . . . . . . . . . . . . 10 - 4. Interfaces Ethernet-Like Module . . . . . . . . . . . . . . . 11 - 5. Interfaces Common YANG Module . . . . . . . . . . . . . . . . 11 - 6. Interfaces Ethernet-Like YANG Module . . . . . . . . . . . . 22 - 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 25 - 7.1. Carrier delay configuration . . . . . . . . . . . . . . . 25 - 7.2. Dampening configuration . . . . . . . . . . . . . . . . . 26 - 7.3. MAC address configuration . . . . . . . . . . . . . . . . 27 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 - 9. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 29 - 9.1. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 29 - 9.2. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 29 - 9.3. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 29 - 9.4. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 29 - 9.5. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 29 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 - 11.1. interfaces-common.yang . . . . . . . . . . . . . . . . . 30 - 11.2. interfaces-ethernet-like.yang . . . . . . . . . . . . . 31 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 31 - 12.2. Informative References . . . . . . . . . . . . . . . . . 32 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 + 3.7. Forwarding Mode . . . . . . . . . . . . . . . . . . . . . 9 + 4. Interfaces Ethernet-Like Module . . . . . . . . . . . . . . . 10 + 5. Interfaces Common YANG Module . . . . . . . . . . . . . . . . 10 + 6. Interfaces Ethernet-Like YANG Module . . . . . . . . . . . . 21 + 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 7.1. Carrier delay configuration . . . . . . . . . . . . . . . 24 + 7.2. Dampening configuration . . . . . . . . . . . . . . . . . 25 + 7.3. MAC address configuration . . . . . . . . . . . . . . . . 26 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 + 9. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 9.1. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 28 + 9.2. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 28 + 9.3. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 28 + 9.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 28 + 9.5. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 28 + 9.6. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 28 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 28 + 11.1. interfaces-common.yang . . . . . . . . . . . . . . . . . 29 + 11.2. interfaces-ethernet-like.yang . . . . . . . . . . . . . 30 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 30 + 12.2. Informative References . . . . . . . . . . . . . . . . . 31 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction This document defines two NMDA compatible [RFC8342] YANG 1.1 [RFC7950] modules for the management of network interfaces. It defines various augmentations to the generic interfaces data model [RFC8343] 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 @@ -141,37 +141,22 @@ 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Tree Diagrams - A simplified graphical representation of the data model is used in - this document. The meaning of the symbols in these diagrams is as - follows: - - o Brackets "[" and "]" enclose list keys. - - o Abbreviations before data node names: "rw" means configuration - (read-write), and "ro" means state data (read-only). - - o Symbols after data node names: "?" means an optional node, "!" - 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. + Tree diagrams used in this document follow the notation defined in + [RFC8340]. 2. Objectives 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 @@ -236,31 +221,31 @@ 3.1. Carrier Delay The carrier delay feature augments the IETF interfaces data model with configuration for a simple algorithm that is used, generally on physical interfaces, to suppress short transient changes in the interface link state. It can be used in conjunction with the dampening feature described in Section 3.2 to provide effective control of unstable links and unwanted state transitions. - The principal of the carrier delay feature is to use a short per + The principle of the carrier delay feature is to use a short per interface timer to ensure that any interface link state transition that occurs and reverts back within the specified time interval is entirely suppressed without providing any signalling to any upper layer protocols that the state transition has occurred. E.g. in the case that the link state transition is suppressed then there is no change of the /if:interfaces-state/if:interface/oper-status or /if:interfaces-state/if:interfaces/last-change leaves for the interface that the feature is operating on. One obvious side effect - of using this feature that is worth noting is that any state - transition will always be delayed by the specified time interval. + of using this feature that is that any state transition will always + be delayed by the specified time interval. The configuration allows for separate timer values to be used in the suppression of down->up->down link transitions vs up->down->up link transitions. The carrier delay down timer leaf specifies the amount of time that an interface that is currently in link up state must be continuously down before the down state change is reported to higher level protocols. Use of this timer can cause traffic to be black holed for the configured value and delay reconvergence after link failures, @@ -382,21 +367,21 @@ 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. + matched by a child sub-interface) 802.1Q VLAN tags. 3.6. 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. @@ -472,21 +457,21 @@ +--rw 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 8343 [RFC8343]. - file "ietf-interfaces-common@2018-07-02.yang" + file "ietf-interfaces-common@2019-03-05.yang" module ietf-interfaces-common { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces-common"; prefix if-cmn; import ietf-yang-types { prefix yang; } @@ -512,41 +498,41 @@ WG Chair: Kent Watsen Editor: Robert Wilton "; description "This module contains common definitions for extending the IETF - interface YANG model (RFC 7223) with common configurable layer 2 + interface YANG model (RFC 8343) with common configurable layer 2 properties. - Copyright (c) 2016-2018 IETF Trust and the persons identified + Copyright (c) 2016-2019 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 2018-07-02 { + revision 2019-03-05 { description "Initial version"; - reference "Internet draft: draft-ietf-netmod-intf-ext-yang-06"; + reference "Internet draft: draft-ietf-netmod-intf-ext-yang-07"; } feature carrier-delay { description "This feature indicates that configurable interface carrier delay is supported, which is a feature is used to limit the propagation of very short interface link state flaps."; reference "RFC XXX, Section 3.1 Carrier Delay"; } @@ -912,23 +896,24 @@ 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."; + a child sub-interface) 802.1Q VLAN tags."; reference "RFC XXX, Section 3.5 Layer 2 MTU"; } + /* * 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; } @@ -962,30 +946,31 @@ type if:interface-ref; mandatory true; description "This is the reference to the parent interface of this sub-interface."; reference "RFC XXX, Section 3.6 Sub-interface"; } } } + 6. Interfaces Ethernet-Like YANG Module This YANG module augments the interface container defined in RFC 8343 [RFC8343] 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@2017-07-03.yang" + file "ietf-interfaces-ethernet-like@2019-03-05.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; @@ -1002,51 +987,54 @@ organization "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; contact "WG Web: WG List: WG Chair: Lou Berger + WG Chair: Joel Jaeggli + + WG Chair: Kent Watsen Editor: Robert Wilton "; description "This module contains YANG definitions for configuration for 'Ethernet-like' interfaces. It is applicable to all interface types that use Ethernet framing and expose an Ethernet MAC layer, and includes such interfaces as physical Ethernet interfaces, Ethernet LAG interfaces and VLAN sub-interfaces. - Copyright (c) 2016 IETF Trust and the persons identified as - authors of the code. All rights reserved. + Copyright (c) 2016-2019 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 2017-07-03 { - description "Updated to conform to NMDA architecture"; + revision 2019-03-05 { + description "Initial revision"; reference - "Internet draft: draft-ietf-netmod-intf-ext-yang-05"; + "Internet draft: draft-ietf-netmod-intf-ext-yang-07"; } /* * 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')" { @@ -1128,21 +1116,21 @@ eth0 ianaift:ethernetCsmacd 0 - 1000 + 50 The following example shows explicit carrier delay up and down values have been configured. A 50 msec down leaf value has been used to potentially allow optical protection to recover the link before the higher layer protocol state is flapped. A 1 second (1000 milliseconds) up leaf value has been used to ensure that the link is always reasonably stable before allowing traffic to be carried over @@ -1264,51 +1252,55 @@ The authors wish to thank Eric Gray, Ing-Wher Chen, Juergen Schoenwaelder, Ladislav Lhotka, Mahesh Jethanandani, Michael Zitao, Neil Ketley, Qin Wu, William Lupton, Xufeng Liu, and Andy Bierman for their helpful comments contributing to this draft. 9. ChangeLog XXX, RFC Editor, please delete this change log before publication. -9.1. Version -06 +9.1. Version -07 + + o Minor editorial updates + +9.2. Version -06 o Remove reservable-bandwidth, based on Acee's suggestion o Add examples o Add additional state parameters for carrier-delay and dampening -9.2. Version -05 +9.3. Version -05 o Incorporate feedback from Andy Bierman -9.3. Version -04 +9.4. Version -04 o Incorporate feedback from Lada, some comments left as open issues. -9.4. Version -03 +9.5. Version -03 o Fixed incorrect module name references, and updated tree output -9.5. Version -02 +9.6. Version -02 o Minor changes only: Fix errors in when statements, use derived- from-or-self() for future proofing. 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". + politely request that IANA assigns unique names to the two YANG + module files contained within this draft, and also appropriate URIs + in the "IETF XML Registry". 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. @@ -1366,21 +1357,21 @@ 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 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 + all types of Ethernet-like interfaces. The module currently 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 12. References @@ -1407,22 +1398,22 @@ [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, . 12.2. Informative References [I-D.ietf-netmod-sub-intf-vlan-model] Wilton, R., Ball, D., tapsingh@cisco.com, t., and S. Sivaraj, "Sub-interface VLAN YANG Data Models", draft- - ietf-netmod-sub-intf-vlan-model-03 (work in progress), - October 2017. + ietf-netmod-sub-intf-vlan-model-04 (work in progress), + July 2018. [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, . @@ -1432,30 +1423,34 @@ . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", RFC 7224, DOI 10.17487/RFC7224, May 2014, . + [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", + BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, + . + Authors' Addresses Robert Wilton (editor) Cisco Systems Email: rwilton@cisco.com - David Ball Cisco Systems Email: daviball@cisco.com Tapraj Singh Cisco Systems Email: tapsingh@juniper.net + Selvakumar Sivaraj Juniper Networks Email: ssivaraj@juniper.net