[ippm] Éric Vyncke's No Objection on draft-ietf-ippm-route-09: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-ippm-route-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-route/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document.

I support many of the previous COMMENT / DISCUSS points raised by Warren and
Erik. I will avoid repeating other ADs' points.

Please find below a couple of non-blocking COMMENTs (and I would appreciate a
reply to each of my COMMENTs).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1.1 --
"path detection methods like [PT] rely on TTL limits", please add the name
rather than a reference to [PT] (I assume it is Paris Traceroute). Also, I
suggest to s/TTL/hop limit/ (or use the same verbiage as for "cloud subpath".

Please fix "that decrement TTL or Hop Count" into "hop limit" ;-)

-- Section 3.5 --
About bullet 3,
          "If a discovered Node always replies using the same network
      address, regardless of the interface a packet arrives on, then
      multiple parallel links cannot be detected in that network domain."
If RFC 5837 is implemented, then in this case parallel links can still be
detected based on the discovery mechanism or did I miss anything ?

-- Section 4.1 --
"[SCAMPER] supports IPv6 traceroute measurements,
   keeping the FlowLabel constant in all packets."
All packets of the same flow or among all flows ? (I guess from the same
measurement but probably worth adding more description). The way the sentence
is worded sounds like 'only scamper can do IPv6 traceroutes.

As noted in other IESG reviews, I would appreciate clarification / fixes in
        "it is sufficient to be routed
   identically if the IP source and destination addresses and the
   FlowLabel are constant" and the following list

About IPv6, I fear that the presence of some extension headers may prevent the
hashing in ECMP/UCMP. Should there be some text around this issue ?

Other reviews have raise a DISCUSS about "The IP identification field." that
does not exist in IPv6, so, I won't raise it again.

-- Section 6 --
This section is written by using only IPv4 vocabulary while other sections are
also mentioning IPv6 concepts.

== NITS ==

https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-ippm-route-09.txt
points to a couple of downrefs.

ECMP and UCMP are expanded multiple times.