Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F0A12020A for ; Tue, 13 Aug 2019 09:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emWpAhsm8Sb6 for ; Tue, 13 Aug 2019 09:05:26 -0700 (PDT) Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BED391200FA for ; Tue, 13 Aug 2019 09:05:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 961A348036AB; Tue, 13 Aug 2019 18:05:23 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id PilWJwiU0u6T; Tue, 13 Aug 2019 18:05:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 6FCAF48036AC; Tue, 13 Aug 2019 18:05:23 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id oFXN3GcIE-tF; Tue, 13 Aug 2019 18:05:23 +0200 (CEST) Received: from [192.168.0.21] (cm-84.209.19.126.getinternet.no [84.209.19.126]) by mail.transpacket.com (Postfix) with ESMTPSA id 4547248036A9; Tue, 13 Aug 2019 18:05:23 +0200 (CEST) To: Kent Watsen , "netmod@ietf.org" References: <0100016bd93bfe12-b7c7407d-7c5f-4d61-a714-3aa38b0d1da7-000000@email.amazonses.com> From: Vladimir Vassilev Message-ID: Date: Tue, 13 Aug 2019 18:05:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <0100016bd93bfe12-b7c7407d-7c5f-4d61-a714-3aa38b0d1da7-000000@email.amazonses.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 16:05:28 -0000 I have reviewed the draft. I have the following (19) IMO useful proposals= : 1. Dedicated module (ietf-if-oper-status-debounce.yang) for the=20 oper-status debouncing/dampening functionality currently in=20 ietf-interfaces-common.yang. 2. In sec "3.1 Carrier delay" use of the under-defined "Carrier"=20 definition can be replaced with direct reference to the oper-status leaf=20 (which is what is actually targeted by the algorithm) "Operational=20 status transition debouncing". 3. "timer-running" and "suppressed" leafs are both "config false" and=20 have "default" statements. Although this is valid YANG I do not think=20 the "default" statements are intended. 4. Dedicated module (ietf-if-loopback.yang) for the loopback=20 functionality currently in ietf-interfaces-common.yang. 5. Less verbose loopback identities. With dedicated module the=20 (loopback-* identities can be shortened skipping the prefix). 6. The draft introduces "loopback-internal", "loopback-line" and=20 "loopback-connector" loopback identities. What is confusing is that=20 "internal loopback" is historically the opposite of "external loopback"=20 which is a loopback with a connector. I think terminology already in use=20 like "near-end" and "far-end" is less confusing. 7. I am not sure standardizing the "loopback-connector" identity is=20 justified. All usecases of connecting a loopback connector I can think=20 of require the system to not be aware there is special external loopback=20 connector on the interface. 8. Some interfaces that implement "loopback-internal" do not implement=20 "loopback-line" - e.g. classical ethernetCsmacd (Carrier-sense multiple=20 access with collision detection) has a physical layer that by design can=20 not implement such loopback. Maybe introducing a dedicated feature to=20 enable the "loopback-line" is a good idea. 9. Appropriate entry in the "11. Security Considerations" noting the=20 possibility of DoS attacks and broadcast traffic storms resulting from=20 loopbacks: OLD: =C2=A0=C2=A0 The following leaf could cause the interface to go down, an= d stop =C2=A0=C2=A0 processing any ingress or egress traffic on the interface: =C2=A0=C2=A0 o=C2=A0 /if:interfaces/if:interface/loopback NEW: =C2=A0=C2=A0 The following leaf could cause the interface to go down, an= d stop =C2=A0=C2=A0 processing any ingress or egress traffic on the interface. = It could =C2=A0=C2=A0 cause broadcast traffic storms. =C2=A0=C2=A0 o=C2=A0 /if:interfaces/if:interface/loopback 10. Introducing config true "forwarding-mode" leaf breaks clients that=20 support e.g. rfc8344 ietf-ip (which has its dedicated forwarding leafs=20 e.g. /ietf-interfaces:interfaces/interface/ietf-ip:ipv4/forwarding ) by=20 introducing this new module with a new leaf they know nothing about. I=20 support this leaf as config false. If NETCONF was not transactional a=20 global leaf enabling the forwarding configuration would be a feature.=20 But NETCONF is transactional. 11. The "forwarding-mode" leaf has the following set of identities=20 {optical-layer, l2-forwarding, network-layer}. We could make the=20 identity names shorter and consistent. l1,l2,l3 or=20 physical,data-link,network. 12. I do not agree we need this text. Normally NETCONF devices should=20 accept transactions to any valid configuration: OLD: =C2=A0=C2=A0 ... =C2=A0=C2=A0 Normally devices will not allow the parent-interface leaf t= o be =C2=A0=C2=A0 changed after the interfce has been created.=C2=A0 If an im= plementation =C2=A0=C2=A0 did allow the parent-interface leaf to be changed then it c= ould cause =C2=A0=C2=A0 all traffic on the affected interface to be dropped.=C2=A0 = The affected =C2=A0=C2=A0 leaf is: =C2=A0=C2=A0 o=C2=A0 /if:interfaces/if:interface/parent-interface =C2=A0=C2=A0 ... NEW: =C2=A0=C2=A0 ... =C2=A0=C2=A0 Changing the parent-interface leaf could cause =C2=A0=C2=A0 all traffic on the affected interface to be dropped. =C2=A0=C2=A0 The affected leaf is: =C2=A0=C2=A0 o=C2=A0 /if:interfaces/if:interface/parent-interface =C2=A0=C2=A0 ... 13. The in-drop-unknown-dest-mac-pkts changes the behavior of the=20 in-unicast-pkts,in-multicast-pkts and in-broadcast-pkts. I do not agree=20 any discarded packets in the forwarding process should be subtracted=20 from the interface counters. Here is the current description: OLD: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 For consistency, frames counted against this drop =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 counters are also counted against the IETF interfaces =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 statistics.=C2=A0 In particular, they are included in =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 in-octets and in-discards, but are not included in =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 in-unicast-pkts, in-multicast-pkts or in-broadcast-pkt= s, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 because they are not delivered to a higher layer. NEW: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 The implementation of this counter does not =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 change the behavior of the counters defined in =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 IETF interfaces statistics. 14. I propose the in-pkts and out-pkts counters standardized too.=20 https://github.com/YangModels/yang/blob/master/vendor/cisco/xe/1641/ietf-= interfaces-ext.yang.=20 And yes someone forgot to update the boilerplate text. 15. I propose that new "ietf-interfaces-common:in-discards-overflow"=20 counter is added. Currently the "ietf-interfaces:in-discards" can=20 contain both discards like the ones accumulated in=20 in-drop-unknown-dest-mac-pkts and discards caused by overflows=20 (performance related loss of packets like freeing buffer space in=20 devices that in certain cases are forwarding slower then the line=20 speed). Turns out knowing if device is discarding (loosing) packets due=20 to performance shortage and discarding (filtering) unwanted packets are=20 two different events that one needs to differentiate between are=20 currently in the same in-discards counter. We can fix that with the=20 introduction of in-discards-overflow counter. 16. We can replace=20 "ietf-interfaces-ethernet-like:in-drop-unknown-dest-mac-pkts" with=20 (in-discards - in-discards-overflow) for MAC Bridges or any other=20 Ethernet interface plus save us the introduction of technology specific=20 similar counters for the rest of the Bridges and non-Ethernet interfaces. 17. I have separately posted my arguments against introduction of leaf=20 named l2-mtu and the need of a config false leaf that has similar=20 semantics as the ifMtu object from IF-MIB. 18. Some references to relevant IEEE standards and IEEE maintained YANG=20 modules should be added (in the scope of ietf-interfaces-ethernet-like).=20 Also a few lines explaining the policy change and why none of the=20 RFC3635 managed objects are part of the new=20 ietf-interfaces-ethernet-like YANG module. 19. ietf-if-common.yang and ietf-if-ethernet-like.yang instead of=20 ietf-interfaces-common.yang and ietf-interfaces-ethernet-like.yang.=20 Setting a shorter naming precedent for future modules augmenting=20 ietf-interfaces. /Vladimir On 10/07/2019 02.15, Kent Watsen wrote: > All, > > This starts a twelve-day working group last call for draft-ietf-netmod-= intf-ext-yang-07 > > The working group last call ends on July 21 (the day before the NETMOD = 105 sessions). Please send your comments to the working group mailing li= st. > > Positive comments, e.g., "I've reviewed this document and believe it is= ready for publication", are welcome! This is useful and important, even= from authors. > > Thank you, > NETMOD Chairs > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod