Hi Qin, Thank you for your feedback.
> 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 definition in the terminology section. This text is currently at the bottom of section 1 (Introduction); I agree that it's not sufficient - will clarify and move to section 2 (Terminology): "The terms 'packet drop' and 'discard' are considered equivalent and are used interchangeably in this document." > 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? We're not suggesting here that packet loss is the only form of customer impact, but rather than router reported packet loss is most direct signal of the customer impact which is due to unintended packet loss. We will clarify the text. > I am wondering whether this draft should update [RFC8343] to address such > limitation. Ultimately, I think we should update the corresponding data models to reflect whatever we agree in this draft, should we progress it. In this specific case, RFC8343 has reflected what is in RFC1213. Hence, our focus is first on standardising a framework for packet loss reporting. Once the information model is agreed, we can proceed to apply that to the corresponding data models, which we currently define as out of scope in section 1: "There are multiple ways that this information model could be implemented (i.e., data models), including SNMP [RFC1157], NETCONF [RFC6241] / YANG [RFC7950], and IPFIX [RFC5153], but they are outside of the scope of this document." I will update section 1 to reference RFC8343 in addition to RFC1213. > 4. If my understanding is correct, the solution described in Section 2 > include three key elements, packet loss, cause, and auto-mitigation actions ... > 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? The table in section 5 is an example; the intent here was to ensure that the packet loss reporting classification was fit for the purpose of determining the appropriate auto-mitigation action to take, i.e. working backwards from the outcome we are trying to achieve. The lack of a standardised classification scheme and clear semantics for packet loss reporting is a real pain point for network operators today. Hence, whilst we could expand the scope of this document, I think it's better to keep how the actions are modelled, triggered and implemented out of scope of this document, in the interest gaining consensus on the information model for packet loss reporting. This leaves scope to address them in follow-on work. Related current text in section 1: "This document considers only the signals that may trigger automated mitigation plans and not how they are defined or executed." > 5. Section 4 defines a information model, I am wondering whether this packet > discard model should augment interface YANG model defined in [RFC8343]? Please see earlier answer on RFC8343. > 6. Section 4.3 specific requirements rather than rules for packet loss > reporting I'm not sure what you mean here - could you please clarify your feedback? > 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. I think it's better to keep how the actions are modelled, triggered and implemented out of scope of this document and focus on gaining consensus on the information model for packet loss reporting first. Cheers John ๏ปฟOn 31/01/2024, 08:06, "OPSAWG on behalf of Qin Wu" <[email protected] <mailto:[email protected]> on behalf of [email protected] <mailto:[email protected]>> wrote: 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/ <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:[email protected] <mailto:[email protected]>] ไปฃ่กจ Henk Birkholz ๅ้ๆถ้ด: 2024ๅนด1ๆ17ๆฅ 20:52 ๆถไปถไบบ: OPSAWG <[email protected] <mailto:[email protected]>> ไธป้ข: [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 > <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 [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/opsawg <https://www.ietf.org/mailman/listinfo/opsawg> _______________________________________________ OPSAWG mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/opsawg <https://www.ietf.org/mailman/listinfo/opsawg> 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] https://www.ietf.org/mailman/listinfo/opsawg
