[MBONED] Adam Roach's No Objection on draft-ietf-mboned-mtrace-v2-22: (with COMMENT)
Adam Roach <adam@nostrum.com> Thu, 25 January 2018 05:10 UTC
Return-Path: <adam@nostrum.com>
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 949AC12D775; Wed, 24 Jan 2018 21:10:40 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach <adam@nostrum.com>
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.70.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151685704056.15818.1509476396382108295.idtracker@ietfa.amsl.com>
Date: Wed, 24 Jan 2018 21:10:40 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/kHcp2ZFm4iTNt_oRZzyCNflbkQw>
Subject: [MBONED] Adam Roach's No Objection on draft-ietf-mboned-mtrace-v2-22: (with 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: Thu, 25 Jan 2018 05:10:41 -0000
Adam Roach has entered the following ballot position for draft-ietf-mboned-mtrace-v2-22: 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-mboned-mtrace-v2/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to everyone who put in the work to improve the overall mtrace mechanism. I have a handful of substantive questions and comments, most of which I believe require clarifying text in the document. --------------------------------------------------------------------------- §3: > All Mtrace2 messages are UDP packets. For IPv4, Mtrace2 Query and > Request messages MUST NOT be fragmented. Since Query messages can transit intermediate routers on the way to the LHR, this requirement seems to imply that Mtrace2 clients MUST set the IP do-not-fragment (DF) bit in Query messages. That should probably be called out explicitly here. To be clear, the above text seems to intentionally allow fragmentation of Reply messages. Was that on purpose? Finally, the corresponding IPv6 text puts a parallel restriction of 1280 bytes on "the Mtrace2 messages", which would imply all message types, not ust Query and Request. Again: is that the intention? --------------------------------------------------------------------------- §3.1: All of the TLVs defined in this document appear to take pains to end on four-byte boundaries (e.g., inserting "must be zero" bytes as necessary). This document establishes an IANA registry for TLVs, presumably so new ones can be defined elsewhere. When new TLVs are defined, is is a requirement that their lengths are a multiple of four? If so, please indicate as much here, as it allows implementations to make certain simplifying assumptions. If this isn't the case, it should also be indicated here so that implementations don't make such assumptions based on the six TLVs defined in this document. --------------------------------------------------------------------------- §3.2.4: > This field contains a forwarding information/error code. Values > with the high order bit set (0x80-0xff) are intended for use as > error or exception codes. ... > 0x06 WRONG_LAST_HOP This router is not the proper LHR. Given that the "WRONG_LAST_HOP" forwarding code appears to be a fatal condition based on client misconfiguration (per the description in §4.1.1), I'm a bit confused about what is meant by "error or exception codes." Assuming the assignment of 0x06 (rather than, say, 0x86) was intentional, I believe the description of when the high order bit is set needs additional text to explain more precisely what criteria is used to make such a determination. --------------------------------------------------------------------------- §3.2.6: > The Augmented Response Type is defined as follows: > > Code Type > ==== =============================================== > 0x01 # of the returned Standard Response Blocks As this is a 16-byte field, it would be less confusing if this were: > Code Type > ====== =============================================== > 0x0001 # of the returned Standard Response Blocks --------------------------------------------------------------------------- §8: I am surprised not to see an IANA registry created for the 16-bit "Augmented Response Type" field defined in §3.2.6. How are these values intended to be managed?