Document: draft-ietf-opsawg-ipfix-on-path-telemetry
Title: Export of Delay Performance Metrics in IP Flow Information eXport (IPFIX)
Reviewer: Qin Wu
Review result: Ready
This document specifies 4 new IPFIX IEs for on path delay measurement results
reporting. I have read the latest version of this draft and I think the draft
is on the right track. Here are a few comments I would like to ask authors to
consider:
1. Section 3.2.5 T0 and T1 definitions
"
T0: T time, the start of a measurement interval (format "date/time"
as specified in Section 5.6 of [RFC3339]; see also "date-and-time"
in Section 3 of [RFC6991]). The UTC Time Zone is required by
Section 6.1 of [RFC2330]. When T0 is "all-zeros", a start time is
unspecified and Tf is to be interpreted as the duration of the
measurement interval. The start time is controlled through other
means.
Tf: A time, the end of a measurement interval (format "date/time" as
specified in Section 5.6 of [RFC3339]; see also "date-and-time" in
Section 3 of [RFC6991]). The UTC Time Zone is required by
Section 6.1 of [RFC2330]. When T0 is "all-zeros", an ending time
and date is ignored and Tf is interpreted as the duration of the
measurement interval.
"
Both T0 definition and T1 definition emphasize when T0 is "all-zeros", Tf is
interpreted as the duation of the measurement interval, I think it is not
necessary to repeat this statement, suggest to remove such duplication in both
defintions.
2. Measurement method in section 3.4.2.1, Section 3.4.2.2, section 3.4.2.3,
section 3.4.2.4 Since section 3.4.2.3 provide calculation formula for
OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Max, for consistency, I
think section 3.4.2.1, section 3.4.3.2, section 3.4.2.4 should also provide
calculation formula for mean, min and sum related metric.
3. Measurement method for section 3.4.2.4
Section 3.4.2.4 said:
"
However in this case FiniteDelay or MaxDelay MAY be used.
"
Can you clarify in which circumstance the finitedelay or maxdelay will be used?
Also I am wondering whether you use MinDelay or MeanDelay to calculating
statistics, see section 4.2.5 and section 4.3.5 of RFC6049 for calculating
formula.
4. Table 2
"
+-----------+-----------+------+-------------+-------------+-----------+
| ingress | egress | Node | destination | srhActive | Path |
| Interface | Interface | | IPv6Address | SegmentIPv6 | Delay |
+-----------+-----------+------+-------------+-------------+-----------+
| 271 | 276 | R1 | 2001:db8::2 | 2001:db8::4 | 0 us |
+-----------+-----------+------+-------------+-------------+-----------+
| 301 | 312 | R2 | 2001:db8::3 | 2001:db8::4 | 22 us |
+-----------+-----------+------+-------------+-------------+-----------+
| 22 | 27 | R3 | 2001:db8::4 | 2001:db8::4 | 42 us |
+-----------+-----------+------+-------------+-------------+-----------+
| 852 | 854 | R4 | 2001:db8::4 | 2001:db8::4 | 122 us |
+-----------+-----------+------+-------------+-------------+-----------+
Table 2: Example table of measured delay. Ascending by delay.
"
Consider the example depicted in figure 1, I am wondering whether
the destinationIPv6 addresses for both Node R3 and Node R4 should
be the same, i.e., 2001::db8::4, can you clarify this?
5. Section 7.3
Can you clarify why Unsigned64 has been chosen as type for
pathDelaySumDeltaMicroseconds while Unsigned32 has been choosen as type for
IPFIX Information Elements? why not choose unsigned64 or unsigned32 for all new
defined IPFIX IEs?
6. Section 3.1.2
The abbreviation of Observation point (OP) has been repeated multiple times,
also observation point is defined in RFC7011, I don't see RFC7011 defines
abbreviation for Observation point, therefore I suggest to remove such
abbreviation as well. Sometime use OP introducing confusing, e.g., quoted the
following text in section 3.2.1 " With the OP [RFC7011] typically located
between the hosts
participating in the IP Flow, the one-way delay metric requires one
individual measurement between the OP and sourcing host
"
For the first reader, he will not understand what "OP" is and also there is
no OP abbreviation defined in RFC7011.
7. Aggregated On-Path Delay Examples in Appendix
Can I use the same Data Set encoding to carry both
pathDelayMeanDeltaMicroseconds and pathDelaySumDeltaMicroseconds? Or you think
I should use two different Data Set encoding for pathDelayMeanDeltaMicroseconds
and pathDelaySumDeltaMicroseconds respectively?
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
