Hi, draft-ietf-netmod-intf-ext-yang-08.txt should fix most of the issues raised during the WG LC. Please can you check the diff (https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/history/) to ensure that your comments have been correctly addressed, closed issues are tracked at https://github.com/netmod-wg/interface-extensions-yang/issues?q=is%3Aissue+is%3Aclosed .
There are still some open issues, at https://github.com/netmod-wg/interface-extensions-yang/issues that need to be resolved, with proposed resolutions below: 1. Do we rename "Carrier-delay". Possibly, this could be renamed to something like "link-flap-suppression" or "state-flap-suppression"? 2. Do we add in-pkts and out-pkts counters? Effectively, these counters would be equivalent to the sum of the in-unicast-pkts + in-broadcast-pkts + in-multicast-pkts. In hindsight, I wish the counters had been defined as: in-pkts, in-broadcast-pkts, in-multicast-pkts. I.e. where the broadcast and multicast counters are a subset of in-pkts. This approach works for interfaces that don't distinguish between the types. However, I'm not sure whether adding these counters into interface extensions is the right place. If we were to add these counters, I think that it would be better to add them to a new revision of ietf-interfaces.yang. 3. Do we add a new "in-discards-overflow" counter? I propose that we add this counter, with the following definition: leaf in-discards-overflow { type yang:counter32; description "The number of inbound packets that could have been deliverable to a high-layer protocol but have been discarded due to lack of resources to process the packet. This counter does not change the meaning of the 'in-discards' counter, and hence discarded packets Counted against this counter MUST also be counted in the 'in-discards' counter. This counter does not include packets that are discarded due to exceeding a QoS policy, only those dropped due to resource constraints. Discontinuities in the values of this counter 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 8343)."; reference "RFC 2863: The Interfaces Group MIB - ifInDiscards"; } If we add this counter for ingress, then I suggest that we also define a similar counter for egress as well. 4. As discussed at IETF 105, I propose adding the following discard counter, unless there are strong objections: /* * Add discard counter for unknown sub-interface encapsulation */ augment "/if:interfaces/if:interface/if:statistics" { 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:ifPwType')" { description "Applies to interfaces that can demux to sub-interfaces"; } if-feature "sub-interfaces"; description "Augment the interface model statistics with a sub-interface demux discard counter."; leaf in-discard-unknown-encaps { type yang:counter64; units frames; description "A count of the number of frames that were well formed, but otherwise discarded because their encapsulation does not classify to the interface or any child sub-interface. E.g., a packet might be discarded because the it has an unknown VLAN Id, or does not have a VLAN Id when one is expected. For consistency, frames counted against this counter 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 counter 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 8343)."; } } 5. l2-mtu leaf I've changed the name and definition from "l2-mtu" to "max-frame-size". I've changed the definition to be more encaps agnostic, so it included FCS bytes, and doesn't have any special IEEE 802.3 VLAN definition, and increased its size to uint32 to accommodate the Linux loopback MTU of 65536 bytes. The propose new text is: 2.5. Maximum frame size A maximum frame size configuration leaf (max-frame-size) is provided to specify the maximum size of a layer 2 frame that may be transmitted or received on an interface. The value includes the overhead of any layer 2 header, the maximum length of the payload, and any frame check sequence (FCS) bytes. If configured, the max- frame-size leaf on an interface also restricts the max-frame-size of any child sub-interfaces, and the available MTU for protocols. And the YANG: /* * Allows the maximum frame size to be configured or reported. */ leaf max-frame-size { if-feature "max-frame-size"; type uint32 { range "64 .. max"; } description "The maximum size of layer 2 frames that may be transmitted or received on the interface (including any frame header, maximum frame payload size, and frame checksum sequence). If configured, the max-frame-size also limits the maximum frame size of any child sub-interfaces. The MTU available to higher layer protocols is restricted to the maximum frame payload size, and MAY be further restricted by explicit layer 3 or protocol specific MTU configuration."; reference "RFC XXX, Section 2.5 Maximum Frame Size"; } Thanks for all of your review comments, Rob -----Original Message----- From: netmod <netmod-boun...@ietf.org> On Behalf Of internet-dra...@ietf.org Sent: 04 November 2019 21:40 To: i-d-annou...@ietf.org Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-intf-ext-yang-08.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : Common Interface Extension YANG Data Models Authors : Robert Wilton David Ball Tapraj Singh Selvakumar Sivaraj Filename : draft-ietf-netmod-intf-ext-yang-08.txt Pages : 32 Date : 2019-11-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. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-intf-ext-yang-08 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-intf-ext-yang-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-intf-ext-yang-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
