Thanks Ruediger for you feedback and apologies for my slow reply.

> I'd assume, that's L3 QoS/DiffServ only. The Classification scheme however 
> also includes L2 (QoS based drops are a sub-class of
> traffic, not a separate sub-class of L3 only). Does this imply a separate L2 
> QoS configuration - based on Ethernet Prio Bits - too?

We specify class independent of L2 or L3 so the model is adaptable to both.

> 2. All packet receipt, transmission and drops SHOULD be attributed to the 
> physical or logical interface *of the device* where they occur.

Amended accordingly in the next revision.

Cheers

John



On 30/10/2023, 11:32, "ruediger.g...@telekom.de 
<mailto:ruediger.g...@telekom.de>" <ruediger.g...@telekom.de 
<mailto:ruediger.g...@telekom.de>> 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.






Hi John,


thanks for your draft, I excuse for my delayed response. I appreciate your 
draft based on operational experience.


I'm having two comments:


1) https://datatracker.ietf.org/doc/html/draft-evans-discardclass#section-3 
<https://datatracker.ietf.org/doc/html/draft-evans-discardclass#section-3>


| | |-- traffic/
| | | |-- l2/
| | | |-- l3/
| | | |
| | | `-- qos/
| | | |-- class_0/


From your QoS/buffer management related references of
https://datatracker.ietf.org/doc/html/draft-evans-discardclass#section-3.1 
<https://datatracker.ietf.org/doc/html/draft-evans-discardclass#section-3.1>
https://datatracker.ietf.org/doc/html/draft-evans-discardclass#section-3.2 
<https://datatracker.ietf.org/doc/html/draft-evans-discardclass#section-3.2>


I'd assume, that's L3 QoS/DiffServ only. The Classification scheme however also 
includes L2 (QoS based drops are a sub-class of traffic, not a separate 
sub-class of L3 only). Does this imply a separate L2 QoS configuration - based 
on Ethernet Prio Bits - too?


#############


2) https://datatracker.ietf.org/doc/html/draft-evans-discardclass#section-3.2 
<https://datatracker.ietf.org/doc/html/draft-evans-discardclass#section-3.2>


List
2. All packet receipt, transmission and drops SHOULD be attributed to the 
physical or logical interface where they occur.


Maybe (*..*) just to highlight added text - what is captured is device/phys 
int/logical int, as component can be interface|device (ignore if you feel the 
comment to be pedantic).


2. All packet receipt, transmission and drops SHOULD be attributed to the 
physical or logical interface *of the device* where they occur.


Regards,


Ruediger




-----Ursprüngliche Nachricht-----
Von: tsvwg <tsvwg-boun...@ietf.org <mailto:tsvwg-boun...@ietf.org>> Im Auftrag 
von Evans, John
Gesendet: Dienstag, 15. August 2023 19:55
An: ts...@ietf.org <mailto:ts...@ietf.org>
Betreff: [tsvwg] FW: New Version Notification for 
draft-evans-discardclass-03.txt


Hi All - we just posted a draft which may be of interest to this group. This is 
currently an individual submission. Please feel free to contact us with any 
feedback.


Thanks


John


--------


A new version of I-D, draft-evans-discardclass-03.txt has been successfully 
submitted by John Evans and posted to the IETF repository.


Name: draft-evans-discardclass
Revision: 03
Title: Experience from implementing a new packet discard classification scheme 
Document date: 2023-08-15
Group: Individual Submission
Pages: 15
URL: https://www.ietf.org/archive/id/draft-evans-discardclass-03.txt 
<https://www.ietf.org/archive/id/draft-evans-discardclass-03.txt> 
<https://www.ietf.org/archive/id/draft-evans-discardclass-03.txt> 
<https://www.ietf.org/archive/id/draft-evans-discardclass-03.txt&gt;>
Status: https://datatracker.ietf.org/doc/draft-evans-discardclass/ 
<https://datatracker.ietf.org/doc/draft-evans-discardclass/> 
<https://datatracker.ietf.org/doc/draft-evans-discardclass/> 
<https://datatracker.ietf.org/doc/draft-evans-discardclass/&gt;>
Htmlized: https://datatracker.ietf.org/doc/html/draft-evans-discardclass 
<https://datatracker.ietf.org/doc/html/draft-evans-discardclass> 
<https://datatracker.ietf.org/doc/html/draft-evans-discardclass> 
<https://datatracker.ietf.org/doc/html/draft-evans-discardclass&gt;>
Diff: https://author-tools.ietf.org/iddiff?url2=draft-evans-discardclass-03 
<https://author-tools.ietf.org/iddiff?url2=draft-evans-discardclass-03> 
<https://author-tools.ietf.org/iddiff?url2=draft-evans-discardclass-03> 
<https://author-tools.ietf.org/iddiff?url2=draft-evans-discardclass-03&gt;>




Abstract:
Router reported packet loss is the primary signal of when a network is not 
doing its job. Some packet loss is normal or intended in TCP/ IP networks, 
however. To minimise network packet loss through automated network operations 
we need clear and accurate signals of all packets which are dropped and why. 
This document describes our experience from implementing a packet loss 
classification scheme to provide these signals and enable automated network 
mitigation of unintended packet loss.
















The IETF Secretariat




















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.










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

Reply via email to