Re: [OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02

[Evans, John]

Thank you Henk / Chairs.  We have resubmitted the draft as 
draft-ietf-opsawg-discardmodel-00.

Thank you also to the Group for the constructive feedback.

Looking forward to working with you all on this.

Cheers

John


On 02/02/2024, 12:41, "OPSAWG on behalf of Henk Birkholz" 
mailto:opsawg-boun...@ietf.org> on behalf of 
henk.birkh...@ietf.cont act> wrote:

Dear OPSAWG members,

this email concludes the call for Working Group Adoption on
https://datatracker.ietf.org/doc/html/draft-opsawg-evans-discardmodel-02 
.

We received a significant amount of positive replies, no objections, and
willingness to review.

The chairs believe this I-D is ready for adoption and for the working
group to work on. One common theme in the feedback was the topic of
disambiguation of loss and discard (e.g., controlled or uncontrolled
availability of transfer units), which is a good direction to further
address cause and effect w.r.t. SLOs.

Authors, please rename the I-D to draft-ietf-opsawg-discardmodel-00,
keeping the content as is, and resubmit.


For the OPSAWG co-chairs,

Henk


On 17.01.24 13:51, Henk Birkholz wrote:
> Dear OPSAWG members,
>
> this email starts a call for Working Group Adoption of
>
>> https://www.ietf.org/archive/id/draft-opsawg-evans-discardmodel-02.html 
>> 
>
> 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 







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

Re: [OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02

[Henk Birkholz]

Dear OPSAWG members,

this email concludes the call for Working Group Adoption on 
https://datatracker.ietf.org/doc/html/draft-opsawg-evans-discardmodel-02.


We received a significant amount of positive replies, no objections, and 
willingness to review.


The chairs believe this I-D is ready for adoption and for the working 
group to work on. One common theme in the feedback was the topic of 
disambiguation of loss and discard (e.g., controlled or uncontrolled 
availability of transfer units), which is a good direction to further 
address cause and effect w.r.t. SLOs.


Authors, please rename the I-D to draft-ietf-opsawg-discardmodel-00, 
keeping the content as is, and resubmit.



For the OPSAWG co-chairs,

Henk

On 17.01.24 13:51, Henk Birkholz wrote:

Dear OPSAWG members,

this email starts a call for Working Group Adoption of


https://www.ietf.org/archive/id/draft-opsawg-evans-discardmodel-02.html


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

Re: [OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02

[Evans, John]

Hi Qin,

> 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.

Ah - I see your point; yes - agree will change accordingly.

Cheers

John

On 01/02/2024, 06:59, "Qin Wu" mailto:bill...@huawei.com>> wrote:


-邮件原件-
发件人: Evans, John [mailto:jevanamz=40amazon.co...@dmarc.ietf.org 
<mailto:40amazon.co...@dmarc.ietf.org>]
发送时间: 2024年1月31日 20:25
收件人: Qin Wu mailto:bill...@huawei.com>>; Evans, John 
mailto:jevan...@amazon.co.uk>>; Henk Birkholz 
mailto:henk.birkh...@sit.fraunhofer.de>>; 
OPSAWG mailto: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
 
<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
 
<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" 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, 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" mailto:opsawg-boun...@ietf.org> <mailto:opsawg-boun...@ietf.org 
<mailto:opsawg-boun...@ietf.org>> <mailto: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>> 
<mailto:40huawei@dmarc.ietf.org <mailto:40huawei@dmarc.ietf.org> 
<mailto:40huawei@dmarc.ie

Re: [OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02

[Qin Wu]

-邮件原件-
发件人: Evans, John [mailto:jevanamz=40amazon.co...@dmarc.ietf.org] 
发送时间: 2024年1月31日 20:25
收件人: Qin Wu ; Evans, John ; Henk 
Birkholz ; OPSAWG 
主题: 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" 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" 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 i

Re: [OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02

[Evans, John]

pt 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 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.htm>
> <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

Re: [OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02

[Qin Wu]

发件人: OPSAWG [mailto:opsawg-boun...@ietf.org <mailto:opsawg-boun...@ietf.org>] 
代表 Henk Birkholz
发送时间: 2024年1月17日 20:52
收件人: OPSAWG 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>
> 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> 
https://www.ietf.org/mailman/listinfo/opsawg 
<https://www.ietf.org/mailman/listinfo/opsawg>
___
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

Re: [OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02

[Evans, John]

h 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:opsawg-boun...@ietf.org <mailto:opsawg-boun...@ietf.org>] 
代表 Henk Birkholz
发送时间: 2024年1月17日 20:52
收件人: OPSAWG 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.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 <mailto:OPSAWG@ietf.org>
https://www.ietf.org/mailman/listinfo/opsawg 
<https://www.ietf.org/mailman/listinfo/opsawg>
___
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

Re: [OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02

[Qin Wu]

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]  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

Re: [OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02

[Evans, John]

Hi Benoit,

Thanks for your feedback.

> I mean: what is the value of an information model without a respective
> data model, or a mapping to data model(s)?

Whilst it's true that having a data model is essential for implementing an 
information model effectively, our focus is 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.  Separating the process into two 
phases allows us to ensure that the information model itself is well defined 
for network operations use cases and can be used across multiple data models.

Cheers

John


On 24/01/2024, 05:07, "OPSAWG on behalf of Benoit Claise" 
mailto:opsawg-boun...@ietf.org> on behalf of 
benoit.claise=40huawei@dmarc.ietf.org > 
wrote:


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.


Dear all,


See in-line.


On 1/17/2024 12:51 PM, Henk Birkholz wrote:
> Dear OPSAWG members,
>
> this email starts a call for Working Group Adoption of
>
>> https://www.ietf.org/archive/id/draft-opsawg-evans-discardmodel-02.html 
>> 
>
> 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.
I read the previous version, and even provided feedback to John.
This is interesting work and I like the way the information it's
structured.
However, I am asking myself: what is the value of information model
these days?
I mean: what is the value of an information model without a respective
data model, or a mapping to data model(s)?


Regards, Benoit
>
> 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 







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

Re: [OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02

[Benoit Claise]

Dear all,

See in-line.

On 1/17/2024 12:51 PM, Henk Birkholz wrote:

Dear OPSAWG members,

this email starts a call for Working Group Adoption of


https://www.ietf.org/archive/id/draft-opsawg-evans-discardmodel-02.html


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.

I read the previous version, and even provided feedback to John.
This is interesting work and I like the way the information it's 
structured.
However, I am asking myself: what is the value of information model 
these days?
I mean: what is the value of an information model without a respective 
data model, or a mapping to data model(s)?


Regards, Benoit


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

Re: [OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02

[Tianran Zhou]

Hi Authors,

I read this draft and I think this work is valuable. 
There are several comments for your consideration.
1.  We have YANG as the modeling language for configuration DM. For this draft, 
do you have any formal language for the IM? While I think the tree diagram is 
also clear, I am afraid the expression is not very strict.
2. The title indicates the content is about discard. And in fact section 4.1 
only described the discard class. However, the IM you proposed includes 
"traffic"  as a large part. So, I am thinking if you would consider to remove 
the "traffic" part, or your document is actually a more generic traffic IM.
3. In section 5, all your Signal-Cause-Mitigation mapping examples are actually 
"discard". Is there any use case for "good traffic"? I.e., maybe there is no 
need for the "good traffic" report, hence no need to include the "traffic" in 
your draft for your scenario.
4. In section 5, the Signal-Cause-Mitigation table is confusing. It's not clear 
what's the signal, cause, mitigation respectively. So it's better to indicate 
this information explicitly in the table.

Best,
Tianran

-Original Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Henk Birkholz
Sent: Wednesday, January 17, 2024 8:52 PM
To: OPSAWG 
Subject: [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

Re: [OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02

[David Barmann]

Hi Everyone,

I also support adoption of this document.  Thank you to the authors for 
accepting my suggestions for a small part of its content!


-David


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02

[Marcos Sanz]

Dear all,

I also support adopting this document and appreciate its value for IXs.
(Full disclosure: I contributed to the document in earlier versions before it 
was presented here).

Best regards,
Marcos Sanz

> -Mensaje original-
> De: Henk Birkholz 
> Enviado el: miércoles, 17 de enero de 2024 13:52
> Para: OPSAWG 
> Asunto: [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.html
> 
> 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



smime.p7s
Description: S/MIME cryptographic signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02

[mohamed . boucadair]

Hi all, 

I support adopting this document.

The authors kindly addressed many of my comments in -02. 

Cheers,
Med

> -Message d'origine-
> De : OPSAWG  De la part de Henk Birkholz
> Envoyé : mercredi 17 janvier 2024 13:52
> À : OPSAWG 
> Objet : [OPSAWG]  WG Adoption Call for draft-opsawg-evans-
> discardmodel-02
> 
> Dear OPSAWG members,
> 
> this email starts a call for Working Group Adoption of
> 
> >...
> 
> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fwww.ietf.org%2Fmailman%2Flistinfo%2Fopsawg=05%7C02%7Cmohame
> d.boucadair%40orange.com%7Ceb16c148d3b842238cb108dc175b30d7%7C90c
> 7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638410927624831726%7CUnkn
> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=XRWG1pDgYi9R9FHSrY4tnzn
> V3rhYlq%2BAvR%2BjN3QlZG0%3D=0

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02

[Diego R. Lopez]

Hi,

As I think I already had the opportunity to express in past meetings, this 
proposal is of high interest for service providers. I support adoption.

Be goode,

--
“Esta vez no fallaremos, Doctor Infierno”

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/dr2lopez/

e-mail: diego.r.lo...@telefonica.com
Mobile: +34 682 051 091
-

On 17/1/24, 12:52,  wrote:

Dear OPSAWG members,

this email starts a call for Working Group Adoption of

> https://www.ietf.org/archive/id/draft-opsawg-evans-discardmodel-02.html

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



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please immediately reply to the sender that you have received this 
communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode 
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa 
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica 
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização 
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem 
por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
proceda a sua destruição
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02

[Thomas.Graf]

Dear OPSAWG,



I read the document and think it is very valuable for network operators. I like 
that it is defined as information module so later we can see how this would be 
applicable in IPFIX and YANG.



Best wishes

Thomas



-Original Message-
From: OPSAWG  On Behalf Of Henk Birkholz
Sent: Wednesday, January 17, 2024 1:52 PM
To: OPSAWG 
Subject: [OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02





Be aware: This is an external email.







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<mailto:OPSAWG@ietf.org>

https://www.ietf.org/mailman/listinfo/opsawg


smime.p7s
Description: S/MIME Cryptographic Signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG]  WG Adoption Call for draft-opsawg-evans-discardmodel-02

[Henk Birkholz]

Dear OPSAWG members,

this email starts a call for Working Group Adoption of


https://www.ietf.org/archive/id/draft-opsawg-evans-discardmodel-02.html


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