Hi Joe, Thanks for your review and feedback.
> Wouldn’t invalid-frame and invalid-packet encompass CRC errors and checksum > errors? We classified them separately (rather than hierarchically) because the actions we would take as a result of them are different. That is one of the principles we applied in defining the classification scheme, i.e. to work backwards from the action we need to take in operations. For example, frame crc errors typically indicates a problem with the attached link or interface – i.e. where in mitigation we would take the interface out of service. Whereas invalid frame (malformed frame, frame-size-violation) is more commonly an issue with the source of the frame. >In the IM, you have a feature for flow-reporting, but you do not include this >in the DM. We submitted a separate draft for this as an IE, rather than a YANG model: https://datatracker.ietf.org/doc/draft-evans-opsawg-ipfix-discard-class-ie/ > Why? I would imagine this feature might be used > by certain vendors’ implementations to reflect per-flow drop statistics. And > having a common feature defined, even if not immediately > used by this module could be useful. Yes, completely agree - it’s a natural ops workflow to corelate certain types of discards with the flows being discarded. We’re only on 01, but would like to see if there is interest in adopting this as a opsawg draft. We hadn’t planned to present at IETF124, but if there’s interest we could present the draft (we did previously, but it was rushed). > Nits: > In Section 3, expand “pps”. > In Section 3, maybe s/crucial for selecting the appropriate of > mitigation/crucial for selecting the appropriate type of mitigation/ Will correct – thanks Cheers John From: "Joe Clarke (jclarke)" <[email protected]> Date: Monday, 20 October 2025 at 19:21 To: opsawg <[email protected]> Subject: [EXTERNAL] [OPSAWG]Review of draft-ietf-opsawg-discardmodel-09 CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. This is a contributor review of draft-ietf-opsawg-discardmodel-09. Overall, I found the draft in pretty good shape. The authors have done a great job incorporating feedback. I do have a few suggestions, and I found a couple nits. Wouldn’t invalid-frame and invalid-packet encompass CRC errors and checksum errors? Prior to introducing the YANG data model, you address that frames/packets cannot be double-counted, but I think it would be beneficial to add some mention of that to the IM. Maybe in the description of the invalid-* you explicitly state these count frames/packets other than when a CRC or checksum error has been detected. In the IM, you have a feature for flow-reporting, but you do not include this in the DM. Why? I would imagine this feature might be used by certain vendors’ implementations to reflect per-flow drop statistics. And having a common feature defined, even if not immediately used by this module could be useful. Nits: In Section 3, expand “pps”. In Section 3, maybe s/crucial for selecting the appropriate of mitigation/crucial for selecting the appropriate type of mitigation/ Joe 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]
