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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
