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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Wed, 12 Aug 2020 06:13:09 -0700

É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.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 12 Aug 2020 19:48:04 +0000

Hi éric,

Thanks for your comments, please see replies and proposed resolutions below.
They are all implemented in the working text now.

Al

> -----Original Message-----
> From: Éric Vyncke via Datatracker [mailto:[email-masked]]
> Sent: Wednesday, August 12, 2020 9:13 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> Brian Trammell <[email-masked]>; [email-masked]
> Subject: Éric Vyncke's No Objection on draft-ietf-ippm-route-09: (with
> COMMENT)
> 
...
> 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).
[acm] 
of course

> rather than a reference to [PT] (I assume it is Paris Traceroute). 
[acm] 
Yes it is, OK.

> Also, I suggest to s/TTL/hop limit/ (or use the same verbiage as for "cloud
> subpath".
[acm] 
ok

> Please fix "that decrement TTL or Hop Count" into "hop limit" ;-)
[acm] 
ok

> detected based on the discovery mechanism or did I miss anything ?
[acm] 
I see that 5837 is in our reference list (Informative) but not cited here.

Let's append:
For example, if the RFC 5837 ICMP extension mechanism is implemented, then  parallel links can be
detected with the discovery traceroute-style methods.

> measurement but probably worth adding more description). The way the
> sentence is worded sounds like 'only scamper can do IPv6 traceroutes.
> 
[acm] 
Yes, I think we have resolved those comments now.

> 
> 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 ?
> 
[acm] 
I added:

Use of IPv6 Extension headers may add critical fields, and SHOULD be avoided.

> Other reviews have raised a DISCUSS about "The IP identification field." that
[acm] 
We have clarified the scope of that list (v4) as a result.

> 
> -- Section 6 --
> This section is written by using only IPv4 vocabulary while other sections
> are also mentioning IPv6 concepts.
[acm] 
Ok, added "(or Hop Limit)" where appropriate.
> 
> == NITS ==
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_idnits-3Furl-3Dhttps-3A__tools.ietf.org_id_draft-
> 2Dietf-2Dippm-2Droute-2D09.txt&d=DwIDaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=GEZiiJ-
> fEeg7-HKF5sTGECgoVEuusS1URoPy3y7ylNs&s=TYjH-XKtm1kid7PLZx6nPBns247p-
> nRI2jUigIw1jFY&e=
[acm] 

  ** Downref: Normative reference to an Informational RFC: RFC 2330:  IPPM Framework RFC

  ** Downref: Normative reference to an Informational RFC: RFC 2991:  Should have been Informative

  ** Downref: Normative reference to an Informational RFC: RFC 7799:  IPPM Definitions

  ** Downref: Normative reference to an Informational RFC: RFC 8468:  IPPM Framework Update (IPv6)

Some of the Refs above are on the Exceptions List for IETF Last Call, such as RFC 2330.

> ECMP and UCMP are expanded multiple times.
[acm] 
probably not a bad thing.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 12 Aug 2020 19:52:37 +0000

Al

Thank you for your quick reply. It addresses all my COMMENT points.

Again, good piece of work !

-éric

-----Original Message-----
From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wednesday, 12 August 2020 at 21:48
To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Brian Trammell <[email-masked]>
Subject: RE: Éric Vyncke's No Objection on draft-ietf-ippm-route-09: (with COMMENT)

    Hi éric,

    Al

    ...
    [acm] 
    of course

    [acm] 
    Yes it is, OK.

    [acm] 
    ok

    [acm] 
    ok

    [acm] 

    Let's append:

    [acm] 

    [acm] 
    I added:

    [acm] 

    [acm] 
    [acm] 

    [acm]