Hi Benoit, Thanks for your feedback and apologies for my slow response.
Please see inline: je# Your feedback is in the next revision: https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-opsawg-discardmodel&url_2=https://o-pylypenko.github.io/draft-ietf-opsawg-discardmodel/draft-ietf-opsawg-discardmodel.txt Reply on part 2 of your feedback to follow. cheers John From: [email protected] <[email protected]> Date: Wednesday, 29 October 2025 at 17:41 To: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: [OPSAWG]Review of draft-ietf-opsawg-discardmodel-09 - part 1 Dear authors, I reviewed the first part of the draft, up to the IM. This draft reads easily. Good job. Some feedback/questions. - Abstract This document defines an Information Model and specifies a corresponding YANG data model for packet discard reporting. The Information Model provides an implementation-independent framework for classifying packet loss — both intended (e.g., due to policy) and unintended (e.g., due to congestion or errors) — to enable automated network mitigation of unintended packet loss. The YANG data model specifies an implementation of this framework for network elements. PROPOSAL: an implementation of this information model je# ack - changed - terminology section Packet Discard total = Intended Discards total + Unintended Discards total? je# This is explicitly said as such in the definition. Why do I ask? Because, when I read "Intended discards are packets dropped due", I was thinking: should it be "Intended discards are Packet Discard dropped due"? je# I don’t think so. We changed “Intended Discards” to “Intended packet discards (Intended discards, for short)” (idem for unintended). And then, Discard dropped... this is redundant. Maybe it doesn't read nice, but I was wondering whether Intended/Unintended Discards definitions should be based on the Packet Discard one? Also, make it clear what the definition is. For example, in "Device discard counters do not by themselves establish operator", what is the definition: the Device Discard or Device Discard Counters? Reading the "Device discard counters" entry, it doesn't look like a definition. You see how I used capitalized definition to make it clearer what the definition is. - FEATURE-DISCARD-CLASS: The type or class of discards, which is crucial for selecting the appropriate of mitigation - for example: error discards may require taking faulty components out of service; no-buffer discards may require traffic redistribution; intended policy discards typically require no automated action ... no automated action, except trying to sell a better service ... which requires automation :-) je# The intent here was operational action, i.e. to mitigate impact. We deleted “automated” to clarify. Also added pointer to the table in the appendix to show examples where no action is needed. - FEATURE-DISCARD-SCOPE: Determines which devices, interfaces, and/or flows are impacted. ... While FEATURE-DISCARD-SCOPE, FEATURE-DISCARD-RATE, and FEATURE- DISCARD-DURATION are implicitly supported by MIB-II [RFC2863] and the YANG Data Model for Interface Management [RFC8343], I disagree with this broad statement: flows are not handled by those two references je# s/ While FEATURE-DISCARD-SCOPE/ While most of FEATURE-DISCARD-SCOPE/ to soften the statement. - structure packet-discard-reporting: +-- control-plane {control-plane-stats}? | +-- traffic* [direction] | | ... | +-- discards* [direction] | ... * Component: - control-plane: discards of traffic to or from a device's control plane. With control plane policing (CoPP) in mind, I was thinking that it would be applicable to incoming traffic only. Would you have an example of outgoing control plane traffic, which would be recognized a control plane traffic, not simply outgoing interface errors. je# Joe already covered this. - 4.2. Sub-type Definitions In some entries, you wrote "in the received packet” je# Yes, those under “rx » So there are applicable only to the ingress direction? je# the direction is indicated in the model. The ones with receives are under “rx” sub-classes. In some entries, I was expecting "in the received packet" but I don't see it discards/error/l3/rx/ttl-expired discards/error/l3/no-route/ Interestingly, the YANG leaf mentioned "received packets" leaf ttl-expired { type yang:counter64; description "The number of received packets discarded due to expired TTL."; } Some consistency would help. je# Made a check. - in the IM YANG model, I am surprised that you had to define those identities je# We may use the identity from RFC9181, but that will add a dependency on other modules (e.g. ietf-routing-types) not needed. We just went with simplicity. identity address-family { description "Defines a type for the address family."; } identity ipv4 { base address-family; description "Identity for an IPv4 address family."; } identity ipv6 { base address-family; description "Identity for an IPv6 address family."; } identity all { base address-family; description "Identity for all address families."; } I would have been expecting that it was defined already in an existing IETF YANG modules. The YANG doctors will tell. - | | | +-- address-family-stat* [address-family] | | | +-- address-family identityref | | | +-- packets? yang:counter64 | | | +-- bytes? yang:counter64 | | | +-- unicast | | | | +-- packets? yang:counter64 | | | | +-- bytes? yang:counter64 | | | +-- multicast | | | +-- packets? yang:counter64 | | | +-- bytes? yang:counter64 broadcast and anycast discards are not valuable to you? je# OK for broadcast (l2, ipv4), but don’t think we need dedicated counters for anycast. NITS: OLD: For example, [RFC7270] provides support for reporting discards per flow in IP Flow Information Export (IPFIX) [RFC7011] using forwardingStatus NEW: For example, [RFC7270] provides support for reporting discards per flow in IP Flow Information Export (IPFIX) [RFC7011] using the forwardingStatus IPFIX Information Element je# ack - changed Regards, Benoit Amazon Data Services UK Limited. Registered in England and Wales with registration number 09959151 with its registered office at 1 Principal Place, Worship Street, London, EC2A 2FA, United Kingdom.
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
