Hi Benoit,
Thanks for your feedback – very valid points re how to apply to flow which we
planned to cover on Wednesday.
> However, the " structure packet-discard-reporting" shows that the
> control-plane is actually inside the interface. It's not clear why you made
> that design choice.
That is indeed incorrect.
We will address that and add specific example for device and flow for Wednesday.
Cheers
John
From: Benoit Claise <benoit.claise=40huawei....@dmarc.ietf.org>
Date: Thursday, 31 October 2024 at 22:52
To: "draft-ietf-opsawg-discardmo...@ietf.org"
<draft-ietf-opsawg-discardmo...@ietf.org>
Cc: opsawg <opsawg@ietf.org>
Subject: [EXTERNAL] [OPSAWG]Feedback on draft-ietf-opsawg-discardmodel-04
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 authors,
As a contributor, here is my feedback on draft-ietf-opsawg-discardmodel-04
- Information Model
The subject (and title) speaks about an information model
"This document defines an information model for packet loss reporting"
But you also define a YANG module
Same remark for the introduction: "Hence, this document presents an information
model for "
- "The specific implementations of this information model (i.e., protocols and
associated data models) are outside the scope of this document."
I don't understand how this could work because the YANG module is clearly
normative.
You even register the YANG module in IANA
- MIB-II [1213] => a better reference is RFC 2863
- section 4.2
Component: Specifies where in the device the discards are
accounted. It can be:
- interface: discards of traffic to or from a specific network
interface.
- device: discards of traffic transiting the device.
- control-plane: discards of traffic to or from the device's
control plane.
- flow: discards of traffic associated with a specific traffic
flow.
I don't see how a flow would be captured in the structure, because the flow
depends on its definition (ex: 5 tuples). There are no example of it. I am
actually interested into the flow because your problem statement is about
precision and aggregation:
Existing metrics for reporting packet loss, such as ifInDiscards,
ifOutDiscards, ifInErrors, and ifOutErrors defined in [RFC1213], are
insufficient for several reasons. First, they lack precision; for instance,
ifInDiscards aggregates all discarded inbound packets without specifying the
cause
To me, only flows have the required precision for its flow definition (hence no
aggegration)
- Section 4.2, coming back on the components.
So I was thinking that we have 4 top level components.
However, the " structure packet-discard-reporting" shows that the control-plane
is actually inside the interface. It's not clear why you made that design
choice. Then would a device be represented. I am actually confused by those
components, two of them not being the structure.
- would be great to have some control-plane and device component examples
Regards, Benoit
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
To unsubscribe send an email to opsawg-le...@ietf.org
