Subject: [MBONED] Mirja Kühlewind's Discuss on draft-ietf-mboned-mtrace-v2-22: (with DISCUSS and COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 24 Jan 2018 06:32:49 -0800

Mirja Kühlewind has entered the following ballot position for
draft-ietf-mboned-mtrace-v2-22: Discuss

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-mboned-mtrace-v2/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for this well written document! However, I think there are a few things
that need clarification. I also agree with Ekr's discuss and the tsv-art review
(Thanks Brian!) and would like to see stronger access control (as least MUST
filter instead of SHOULD).

Further, the IANA section is not fully specified. Sec 8.2 doesn't define a
registration policy. Sec 8.1. says "Any additions to
   this registry are required to fully describe the conditions under
   which the new Forwarding Code is used."
which sounds like RFC8126 "Specification Required" which would however include
expert review. Is an expert review require/desired here?

Also, I think the entry in the port registry should be updated to point to this
RFC and reassign the port to the IESG as maintainer of this RFC.

Further, based on the feedback provided by the tsv-art review (Thanks Brian
again!): How does a receiver distinguish between mtrace version 1 and mtrace2?

And also on use of UPD ports: Section 3 says:
"The source port is uniquely selected by the local host operating
   system.  The destination port is the IANA reserved Mtrace2 port
   number (see Section 8)."
This sounds like the IANA assigned port is used as destination for all mtrace
messages including a reply. If that would be the case, you don't have to carry
the mtrace client's port #. Can you please clarify?

Section 5.2 needs a bit of clarification. This says:
"If no Reply is received at a
   certain hop, the hop count can continue past the non-responding hop,
   in the hopes that further hops may respond.  These attempts should
   continue until the [Mtrace Reply Timeout] timeout has occurred."
This seems to be contradicting. If no Reply is received that means the Mtrace
Reply Timeout has occurred, so how and when should you try further attempts.
Also I think it would be good to clarify that only one Request MUST be sent at
once. I assume that is how Mtrace Reply Timeout is used to rate limit requests
(while traditional traceroute often sends multiple packets with different TTLs
at once). Right?

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

A few minor comments:

1) Regarding the protocol design: Given all messages types are actually fixed
length (of course depending on what the underlying IP version is), you would
actually not need a length field, but I guess it doesn't hurt. However, if you
have it, shouldn't a receiver actually check if the length field is correct
(based on the underlying IP version)?

2) sec 3.2.4 says:
"Note that Mtrace2 does not require all the routers on the path to
      have synchronized clocks in order to measure one-way latency."
What do you mean by one-way latency? You can measure the time between sending a
request and receiving a reply on an mtrace client but I guess you'd be rather
interested in the one-way delay between the LHR and FHR (which does require
synchronized close at least between the LHR and FHR), no?