-----邮件原件----- 发件人: Evans, John [mailto:jevanamz=40amazon.co...@dmarc.ietf.org] 发送时间: 2024年1月31日 20:25 收件人: Qin Wu <bill...@huawei.com>; Evans, John <jevan...@amazon.co.uk>; Henk Birkholz <henk.birkh...@sit.fraunhofer.de>; OPSAWG <opsawg@ietf.org> 主题: Re: [OPSAWG] 🔔 WG Adoption Call for draft-opsawg-evans-discardmodel-02
Hi Qin, > [Qin Wu] Maybe a new section can be added to clarify the relation with > RFC8343. We will explicitly call out the relationship to data models. > the table in section 3 just provides model structure but doesn't specify > parameters details. Yes - agreed - we will expand on that > [Qin Wu] Sorry not to make me clear, I just feel the 9 rules you set > in section 4.3 is more like you set requirements for packet discard > reporting, to me, the rules are more something related to auto mitigation > actions which is confusing. Section 4.3 is the examples in 02: https://datatracker.ietf.org/doc/html/draft-opsawg-evans-discardmodel-02#section-4.3 I'm assuming you mean the 11 rules in section 4.2? https://datatracker.ietf.org/doc/html/draft-opsawg-evans-discardmodel-02#section-4.2 The rules here are intended to be with respect to packet loss reporting requirements rather than auto-mitigation actions. Could you call out a specific example which is confusing? [Qin Wu] No strong opinion here, just feel the term 'rule' and 'requirement' are interchangeable term, requirement seems more reasonable term to me. Cheers John On 31/01/2024, 11:57, "OPSAWG on behalf of Qin Wu" <opsawg-boun...@ietf.org <mailto:opsawg-boun...@ietf.org> on behalf of bill.wu=40huawei....@dmarc.ietf.org <mailto:40huawei....@dmarc.ietf.org>> wrote: Hi, John: > 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. [Qin Wu] Maybe a new section can be added to clarify the relation with RFC8343. In addition, the table in section 3 just provides model structure but doesn't specify parameters details. Section 5 and section 6 of RFC3060 provide a good example on how these details can be specified. > 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? [Qin Wu] Sorry not to make me clear, I just feel the 9 rules you set in section 4.3 is more like you set requirements for packet discard reporting, to me, the rules are more something related to auto mitigation actions which is confusing. Also not sure you can enumerate all the rules in a single section? On 31/01/2024, 08:06, "OPSAWG on behalf of Qin Wu" <opsawg-boun...@ietf.org <mailto:opsawg-boun...@ietf.org> <mailto:opsawg-boun...@ietf.org <mailto:opsawg-boun...@ietf.org>> on behalf of bill.wu=40huawei....@dmarc.ietf.org <mailto:40huawei....@dmarc.ietf.org> <mailto:40huawei....@dmarc.ietf.org <mailto:40huawei....@dmarc.ietf.org>>> 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/> <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:opsawg-boun...@ietf.org <mailto:opsawg-boun...@ietf.org> <mailto:opsawg-boun...@ietf.org <mailto:opsawg-boun...@ietf.org>>] 代表 Henk Birkholz 发送时间: 2024年1月17日 20:52 收件人: OPSAWG <opsawg@ietf.org <mailto:opsawg@ietf.org> <mailto:opsawg@ietf.org <mailto: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 > <https://www.ietf.org/archive/id/draft-opsawg-evans-discardmodel-02.ht > m> > <https://www.ietf.org/archive/id/draft-opsawg-evans-discardmodel-02.ht > <https://www.ietf.org/archive/id/draft-opsawg-evans-discardmodel-02.ht > > > m> > 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 <mailto:OPSAWG@ietf.org> <mailto:OPSAWG@ietf.org <mailto:OPSAWG@ietf.org>> https://www.ietf.org/mailman/listinfo/opsawg <https://www.ietf.org/mailman/listinfo/opsawg> <https://www.ietf.org/mailman/listinfo/opsawg> <https://www.ietf.org/mailman/listinfo/opsawg>> _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org <mailto:OPSAWG@ietf.org> <mailto:OPSAWG@ietf.org <mailto:OPSAWG@ietf.org>> https://www.ietf.org/mailman/listinfo/opsawg <https://www.ietf.org/mailman/listinfo/opsawg> <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 OPSAWG@ietf.org <mailto:OPSAWG@ietf.org> 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 OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
