Herewith some review comments on draft-ietf-opsawg-ipfix-on-path-telemetry-08 :
Throughout: "TDB3" should be "TBD3".
3.1.1.3. URI / RFC EDITOR NOTE - there are no TBD to be replaced in this
section.
In section 6.2.4. since PathDelaySumDeltaMicroseconds is a sum of deltas,
should the Data Type Semantics: be "totalCounter" rather than "deltaCounter" ?
Typo in section 4:
PathDelayMeanDeltaMicroseconds
32-bit unsigned integer that identifies the mean path delay of all
packets in the Flow, in microseconds, between the IOAM
encapsulation n ode and the local node with the IOAM domain
(either an IOAM transit node or an IOAM decapsulation node).
Typo: "TBD5" should be "TBD8", and "collection" should be "Collector":
7.2. Mean Delay
The mean (average) path delay can be calculated by dividing the
PathDelaySumDeltaMicroseconds(TBD5) by the packetDeltaCount(2) at the
IPFIX data collection in order to offload the IPFIX Exporter from
calculating the mean for every Flow at export time.
Should "microseconds" be "milliseconds"? Because 100 x 1000 x 42949 is about
2^32:
7.3. Reduced-size encoding
Unsigned64 has been chosen as type for PathDelaySumDeltaMicroseconds
to support cases with large delay numbers and where many packets are
being accounted. As an example, a specific flow record with path
delay of 100 microseconds can not observe more than 42949 packets
without overflowing the unsigned32 counter.
Section 7.4: should "nano second" be one word?
For the Enhanced Alternate Marking Method, Section 2 of
[I-D.zhou-ippm-enhanced-alternate-marking] defines that within the
metaInfo a nano second timestamp can be encoded in the encapsulation
Section 8, Security Considerations:
* "no significant" implies there may be some insignificant issues. If there
are no issues then simply say, "There are no extra security considerations".
* There's nothing insecure about the "allocation" of the IDs: issues only
arise when they are in use. So also remove "allocation".
There are no significant extra security considerations regarding the
allocation of these new IPFIX IEs compared to [RFC7012].
A.1.1. Figure 1 and Figure 2: it would be god to continue to use the IEs in
the same order as earlier in the draft, rather than suddenly moving
PathDelayMeanDeltaMicroseconds to the end (ie, continue use {TBD5, TBD6, TBD7}
rather than {TBD6, TBD7, TBD5}.
A.1.2. The "Figure 2" title should be "Figure 4".
In this figure, PathDelaySumDeltaMicroseconds has a length of 8 (per Figure 3
above), so it should be depicted in two lines. Accordingly, the set length is
64:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SET ID = 257 | Length = 64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PathDelayMinDeltaMicroseconds = 22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PathDelayMaxDeltaMicroseconds = 74 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PathDelaySumDeltaMicroseconds = 180 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P.
On 08/07/24 19:40, Benoit Claise wrote:
Dear all,
We reviewed one more time the double IANA registrations, both for the IP
Performance Registry and for the IPFIX Registry.
I feel (more) confident (than before) that the IANA procedure on the right
track.
This document is ready for WGLC IMO.
I would like to have a 10 min presentation to over the last changes, and mainly
the IANA aspects.
Regards, Benoit
On 7/8/2024 6:33 PM, internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>
wrote:
Internet-Draft draft-ietf-opsawg-ipfix-on-path-telemetry-08.txt is now
available. It is a work item of the Operations and Management Area Working
Group (OPSAWG) WG of the IETF.
Title: Export of On-Path Delay in IPFIX
Authors: Thomas Graf
Benoit Claise
Alex Huang Feng
Name: draft-ietf-opsawg-ipfix-on-path-telemetry-08.txt
Pages: 29
Dates: 2024-07-08
Abstract:
This document introduces new IP Flow Information Export (IPFIX)
information elements to expose the On-Path Telemetry measured delay
on the IOAM transit and decapsulation nodes.
The IETF datatracker status page for this Internet-Draft is:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-on-path-telemetry/__;!!OSsGDw!Le05o0xSnk3tLWWI-HZsR37eA5OBYozwFUD33U9MOhQ42qrjBrmi3ZXOwDxigCkshgzxgce0YHJUNxivFQmi5A$
[datatracker[.]ietf[.]org]
There is also an HTMLized version available at:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-on-path-telemetry-08__;!!OSsGDw!Le05o0xSnk3tLWWI-HZsR37eA5OBYozwFUD33U9MOhQ42qrjBrmi3ZXOwDxigCkshgzxgce0YHJUNxg2DlvOVw$
[datatracker[.]ietf[.]org]
A diff from the previous version is available at:
https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-on-path-telemetry-08__;!!OSsGDw!Le05o0xSnk3tLWWI-HZsR37eA5OBYozwFUD33U9MOhQ42qrjBrmi3ZXOwDxigCkshgzxgce0YHJUNxgrn5Wliw$
[author-tools[.]ietf[.]org]
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
_______________________________________________
OPSAWG mailing list -- opsawg@ietf.org<mailto:opsawg@ietf.org>
To unsubscribe send an email to
opsawg-le...@ietf.org<mailto:opsawg-le...@ietf.org>
_______________________________________________
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
