[MBONED] Mirja Kühlewind's Discuss on draft-ietf-mboned-mtrace-v2-22: (with DISCUSS and COMMENT)
Mirja Kühlewind <ietf@kuehlewind.net> Wed, 24 January 2018 14:32 UTC
Return-Path: <ietf@kuehlewind.net>
X-Original-To: mboned@ietf.org
Delivered-To: mboned@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D695124BAC; Wed, 24 Jan 2018 06:32:49 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mirja Kühlewind <ietf@kuehlewind.net>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-mboned-mtrace-v2@ietf.org, Leonard Giuliano <lenny@juniper.net>, mboned-chairs@ietf.org, lenny@juniper.net, mboned@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.69.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151680436916.8063.3025757354151837988.idtracker@ietfa.amsl.com>
Date: Wed, 24 Jan 2018 06:32:49 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/nQWXl-Wp9zYsEvygrmrGt9bYzyY>
Subject: [MBONED] Mirja Kühlewind's Discuss on draft-ietf-mboned-mtrace-v2-22: (with DISCUSS and COMMENT)
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mboned/>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jan 2018 14:32:49 -0000
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?
- [MBONED] Mirja Kühlewind's Discuss on draft-ietf-… Mirja Kühlewind
- Re: [MBONED] Mirja Kühlewind's Discuss on draft-i… Hitoshi Asaeda
- Re: [MBONED] Mirja Kühlewind's Discuss on draft-i… Mirja Kuehlewind (IETF)
- Re: [MBONED] Mirja Kühlewind's Discuss on draft-i… Warren Kumari
- Re: [MBONED] Mirja Kühlewind's Discuss on draft-i… Hitoshi Asaeda
- Re: [MBONED] Mirja Kühlewind's Discuss on draft-i… Warren Kumari