Hi, I have read the latest version of this draft and have the following comments: 1. what is the difference between packet loss and packet discard, it seems this two terms are used interchangeably in the draft, in some places packet discard reporting is used, while in some other places, packet loss reporting, which I think lack consistency. Suggest to introduce two terms defintiion in the terminology section. 2. Section 1, 1st paragraph said: " Router-reported packet loss is the most direct signal for network operations to identify customer impact from unintended packet loss. " I feel packet loss is just one of signals for network operators to identify customer impact? How about network latency, jitter? 3.Section 1, 2nd paragraph said: " The existing metrics for packet loss as defined in [RFC1213] - namely ifInDiscards, ifOutDiscards, ifInErrors, ifOutErrors - do not provide sufficient precision to be able to automatically identify the cause of the loss and mitigate the impact. From a network operators' perspective, ifindiscards can represent both intended packet loss (i.e., packets discarded due to policy) and unintended packet loss (e.g., packets dropped in error). " It looks not only metrics for packet loss defined in [RFC1213] has its limitation, but also YANG model for interface management defined in [RFC8343], I am wondering whether this draft should update [RFC8343] to address such limitation. 4. If my understanding is correct, the solution described in Section 2 include three key elements, packet loss, cause, and auto-mitigation actions the cause can be seen as trigger or condition, which will trigger different auto-mitigation actions, these concept is similar to ECA concept in (https://datatracker.ietf.org/doc/draft-ietf-netmod-eca-policy/) which include Event, condition and action three elements, when the event meets specific condition, e.g., packet loss is greater than specific threshold value, the action will be triggered, the action can be sending an notification, or sending a snapshot of device statistics. Different from ECA, in this draft, auto-mitigation actions and cause is not modelled in the packet loss model, I am wondering how packet loss reporting trigger auto-mitigation action? Do you need to populate specific policy in the device, this policy will be associated with specific monitoring object such as "discards/error/l2/rx/", is such policy corresponding to specific python code, which can be excuted based on the logic described in the policy? 5. Section 4 defines a information model, I am wondering whether this packet discard model should augment interface YANG model defined in [RFC8343]? For the current shape, I feel it lack sufficient details on the definition for each attributes. 6. Section 4.3 specific requirements rather than rules for packet loss reporting
7 Section 5, can we model both packet loss statistics and auto-mitigation action in the same model, similar to what ECA model is doing in draft-ietf-netmod-eca-policy. -Qin -----้ฎไปถๅไปถ----- ๅไปถไบบ: OPSAWG [mailto:opsawg-boun...@ietf.org] ไปฃ่กจ Henk Birkholz ๅ้ๆถ้ด: 2024ๅนด1ๆ17ๆฅ 20:52 ๆถไปถไบบ: OPSAWG <opsawg@ietf.org> ไธป้ข: [OPSAWG] ๐ WG Adoption Call for draft-opsawg-evans-discardmodel-02 Dear OPSAWG members, this email starts a call for Working Group Adoption of > https://www.ietf.org/archive/id/draft-opsawg-evans-discardmodel-02.htm > l ending on Wednesday, January 31st. As a reminder, this I-D describes an information model in support of automated network mitigation on what and how to report about unintentional packet discards/losses that can have an impact on service level objectives. Implementation of the informational model, which could manifest, e.g., via NETCONF/YANG, SNMP or IPFIX, is out-of-scope. The chairs acknowledge feedback to and interest for the topic during the IETF118 meeting and on the list after afterwards. We would like to gather feedback from the WG if there is interest to further contribute and review. Please reply with your support and especially any substantive comments you may have. For the OPSAWG co-chairs, Henk _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
