Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

[Vladimir Vassilev <[e-mail]>]

I have reviewed the draft. I have the following (19) IMO useful proposals:

1. Dedicated module (ietf-if-oper-status-debounce.yang) for the 
oper-status debouncing/dampening functionality currently in 
ietf-interfaces-common.yang.

2. In sec "3.1 Carrier delay" use of the under-defined "Carrier" 
definition can be replaced with direct reference to the oper-status leaf 
(which is what is actually targeted by the algorithm) "Operational 
status transition debouncing".

3. "timer-running" and "suppressed" leafs are both "config false" and 
have "default" statements. Although this is valid YANG I do not think 
the "default" statements are intended.

4. Dedicated module (ietf-if-loopback.yang) for the loopback 
functionality currently in ietf-interfaces-common.yang.

5. Less verbose loopback identities. With dedicated module the 
(loopback-* identities can be shortened skipping the prefix).

6. The draft introduces "loopback-internal", "loopback-line" and 
"loopback-connector" loopback identities. What is confusing is that 
"internal loopback" is historically the opposite of "external loopback" 
which is a loopback with a connector. I think terminology already in use 
like "near-end" and "far-end" is less confusing.

7. I am not sure standardizing the "loopback-connector" identity is 
justified. All usecases of connecting a loopback connector I can think 
of require the system to not be aware there is special external loopback 
connector on the interface.

8. Some interfaces that implement "loopback-internal" do not implement 
"loopback-line" - e.g. classical ethernetCsmacd (Carrier-sense multiple 
access with collision detection) has a physical layer that by design can 
not implement such loopback. Maybe introducing a dedicated feature to 
enable the "loopback-line" is a good idea.

9. Appropriate entry in the "11. Security Considerations" noting the 
possibility of DoS attacks and broadcast traffic storms resulting from 
loopbacks:

OLD:

    The following leaf could cause the interface to go down, and stop
    processing any ingress or egress traffic on the interface:

    o  /if:interfaces/if:interface/loopback

NEW:

    The following leaf could cause the interface to go down, and stop
    processing any ingress or egress traffic on the interface. It could
    cause broadcast traffic storms.

    o  /if:interfaces/if:interface/loopback


10. Introducing config true "forwarding-mode" leaf breaks clients that 
support e.g. rfc8344 ietf-ip (which has its dedicated forwarding leafs 
e.g. /ietf-interfaces:interfaces/interface/ietf-ip:ipv4/forwarding ) by 
introducing this new module with a new leaf they know nothing about. I 
support this leaf as config false. If NETCONF was not transactional a 
global leaf enabling the forwarding configuration would be a feature. 
But NETCONF is transactional.

11. The "forwarding-mode" leaf has the following set of identities 
{optical-layer, l2-forwarding, network-layer}. We could make the 
identity names shorter and consistent. l1,l2,l3 or 
physical,data-link,network.

12. I do not agree we need this text. Normally NETCONF devices should 
accept transactions to any valid configuration:

OLD:
    ...
    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
    ...

NEW:
    ...
    Changing the parent-interface leaf could cause
    all traffic on the affected interface to be dropped.
    The affected leaf is:

    o  /if:interfaces/if:interface/parent-interface
    ...

13. The in-drop-unknown-dest-mac-pkts changes the behavior of the 
in-unicast-pkts,in-multicast-pkts and in-broadcast-pkts. I do not agree 
any discarded packets in the forwarding process should be subtracted 
from the interface counters.

Here is the current description:

OLD:
                 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.
NEW:
                 The implementation of this counter does not
                 change the behavior of the counters defined in
                 IETF interfaces statistics.



14. I propose the in-pkts and out-pkts counters standardized too. 
https://github.com/YangModels/yang/blob/master/vendor/cisco/xe/1641/ietf-interfaces-ext.yang. 
And yes someone forgot to update the boilerplate text.

15. I propose that new "ietf-interfaces-common:in-discards-overflow" 
counter is added. Currently the "ietf-interfaces:in-discards" can 
contain both discards like the ones accumulated in 
in-drop-unknown-dest-mac-pkts and discards caused by overflows 
(performance related loss of packets like freeing buffer space in 
devices that in certain cases are forwarding slower then the line 
speed). Turns out knowing if device is discarding (loosing) packets due 
to performance shortage and discarding (filtering) unwanted packets are 
two different events that one needs to differentiate between are 
currently in the same in-discards counter. We can fix that with the 
introduction of in-discards-overflow counter.

16. We can replace 
"ietf-interfaces-ethernet-like:in-drop-unknown-dest-mac-pkts" with 
(in-discards - in-discards-overflow) for MAC Bridges or any other 
Ethernet interface plus save us the introduction of technology specific 
similar counters for the rest of the Bridges and non-Ethernet interfaces.

17. I have separately posted my arguments against introduction of leaf 
named l2-mtu and the need of a config false leaf that has similar 
semantics as the ifMtu object from IF-MIB.

18. Some references to relevant IEEE standards and IEEE maintained YANG 
modules should be added (in the scope of ietf-interfaces-ethernet-like). 
Also a few lines explaining the policy change and why none of the 
RFC3635 managed objects are part of the new 
ietf-interfaces-ethernet-like YANG module.

19. ietf-if-common.yang and ietf-if-ethernet-like.yang instead of 
ietf-interfaces-common.yang and ietf-interfaces-ethernet-like.yang. 
Setting a shorter naming precedent for future modules augmenting 
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 list.
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod