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

[Hitoshi Asaeda <[e-mail]>]

Hi Mirja,

Thank you for your comments (and sorry for my late response).

> 2018/01/24 23:32, Mirja Kühlewind <[e-mail]> wrote:
> 
> 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).

We’ll change the tone for several parts from SHOULD to MUST in the revision.
We also recognize we need to add/clarify some text for access control. (The related discussion will be replied later.)

> 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?

The beginning of section 8 explicitly states that, "The following new registries are to be created and maintained under the "RFC Required" registry policy as specified in [4].”  It would be better to change this from “RFC Required” to “Specification Required” and this change can be made in the revision. The expert review, however, is desirable and is required in order to ensure that changes to the registry make sense to the users and implementors and that they do not impair interoperability between implementations.

Do you agree?

> 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?

This sentence and others related to this point are ambiguous.
The IANA assigned port number is used as the destination for Query/Request, not for Reply.
In section 3.2.3, we will change the current statements to the following ones;

  it would turn the Request message into a Reply by changing the Type
  field of the Request from 0x02 to 0x03 and by changing the UDP
  destination port to the port number specified in the Client Port number
  field in the Request. The Reply message would then be unicasted to the 
  Mtrace2 client specified in the Mtrace2 Client Address field.

> 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?

Thanks for pointing this out.
The last sentence of section 5.2 should be modified to state that the attempts occur sequentially (not in parallel). This also addresses the rate limiting concern. We’ll say;

  Each of these attempts should continue until either a Reply is received 
  or until the [Mtrace Reply Timeout] timeout has occurred.

Does it make sense?

> 
> ----------------------------------------------------------------------
> 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)?

The IP version of all mtrace TLVs would match the IP version specified in the IP header of the packet containing the mtrace message.
Although this would imply the length for the currently defined TLV types, the “length” field in the TLV is useful because it makes the generic TLV format flexible and capable of supporting future TLV types having variable lengths.

> 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?

Thanks for your comment. We’ll change the statement to;

  Note that synchronized clocks are required on the traced routers to 
  estimate propagation and queueing delays between successive hops. 
  Nevertheless, even without this synchronization, an application can 
  still estimate an upper bound on cumulative one way latency by 
  measuring the time between sending a Query and receiving a Reply.

Is it clearer?

Regards,

Hitoshi