Hi Paul,
Thanks for the fast answer
On 7/9/2024 10:14 AM, Aitken, Paul wrote:
Herewith some review comments on
draft-ietf-opsawg-ipfix-on-path-telemetry-08 :
Throughout: "TDB3" should be "TBD3".
Well spot.
3.1.1.3. URI / RFC EDITOR NOTE - there are no TBD to be replaced in
this section.
Well spot.
In section 6.2.4. since PathDelaySumDeltaMicroseconds is a sum of
deltas, should the Data Type Semantics: be "totalCounter" rather than
"deltaCounter" ?
It's the sum of the path delay of all packets in the Flow
3.2.3 <https://www.rfc-editor.org/rfc/rfc7012#section-3.2.3>. deltaCounter
"deltaCounter" is an integral value reporting the value of a counter.
Counters are unsigned and wrap back to zero after reaching the limit
of the type. For example, an unsigned64 with counter semantics will
continue to increment until reaching the value of 2**64 - 1. At this
point, the next increment will wrap its value to zero and continue
counting from zero. The semantics of a delta counter is similar to
the semantics of counters used in SNMP, such as Counter32 as defined
in [RFC2578 <https://www.rfc-editor.org/rfc/rfc2578>]. The only difference
between delta counters and
counters used in SNMP is that the delta counters have an initial
value of 0. A delta counter is reset to 0 each time it is exported
and/or expires without export.
Based on the last sentence, I believe the "delta" is right.
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).
Yes.
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.
And again, good catch.
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.
And again ... indeed
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
Yes.
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].
Yes and yes.
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}.
Done.
A.1.2. The "Figure 2" title should be "Figure 4".
Yes.
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 |
*| ... |*
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Done
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 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
To unsubscribe send an email to opsawg-le...@ietf.org
_______________________________________________
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
