Subject: [MBONED] Alia Atlas' No Objection on draft-ietf-mboned-mtrace-v2-22: (with COMMENT)

From: Alia Atlas <[email-masked]>
Date: Tue, 23 Jan 2018 14:11:23 -0800

Alia Atlas 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:
----------------------------------------------------------------------

1) In Sec 3, the first paragraph says: "If an implementation receives an
unknown TLV type
   for a subsequent TLV within a message, it SHOULD ignore and silently
   discard the entire packet."  This appears to me to remove the possibility of
   incremental deployment of new features or TLVs.  A rationale for why
   future-proofing isn't needed would be helpful.  I do see the Augmented
   Response Block and Augmented Query Block have sub-types, which does help
   with extensibility.

2)End of Sec 3: "Additionally, Mtrace2 supports both IPv4 and IPv6, but not
mixed.
   For example, if an Mtrace2 Query or Request message arrives in as an
   IPv4 packet, all addresses specified in the Mtrace2 messages MUST be
   IPv4 as well.  Same rule applies to IPv6 Mtrace2 messages."
I do not understand the rationale for forbidding some addresses being IPv4 and
some IPv6. Presumably, some could even be unnumbered interfaces.  Many networks
are dual-stack or may have IPv4 in one part of the network and IPv6 in another
part.  What is the reason for ruling this out as a valid situation?  I do see
that the encodings are problematic if partly IPv4 and partly IPv6 - but I do
not see a reason that IPv4 addresses could not be sent as mapped into IPv6.

3) Sec 3.2.1: "If the actual number of hops is not
   known, an Mtrace2 client could send an initial Query message with a
   large # Hops (e.g., 0xffffffff), in order to try to trace the full
   path."
   Since the #Hops field is an octet long - the largest value should be 255;
   specifying for a uint32 instead of a uint8 is incorrect.

4) Sec 3.2.1: If all the addresses in the Query message must be either IPv4 or
all must be IPv6, the
    way of determining which it is from the length should be clearly specified.
     I.e. The length field MUST be either 8 plus 3*4 (IPv4 addresses) or 8 +
    3*16 (IPv6 addresses); if the length is 20, then IPv4 addresses MUST be
    assumed and if the length is 56, then IPv6 addresses MUST be assumed. One
    could - of course, simply force all IPv6 addresses since an IPv4 address
    can be represented as an IPv6 address.  That would allow any of these
    addresses to be either IPv4 or IPv6 while formatted as IPv6.

5) Sec 3.2.2: "The format of an Mtrace2 Request message is similar to an Mtrace2
   Query except the Type field is 0x02."   This should be clearer and more
   normative.  The Mtrace2 Request TLV is exactly the same as an Mtrace2 Query
   except for the identifying Type field of  0x02. The same applies to 3.2.3
   for Mtrace2 Reply.

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 25 Jan 2018 11:19:40 +0900

Hi Alia,

Thanks for your review and comments.

> 2018/01/24 7:11, Alia Atlas <[email-masked]> wrote:
> 

Right.
We can use the Augmented Response Block and Augmented Query Block for future extension, but as mentioned at the bottom of Section 1 as follows;

   This document describes the base specification of Mtrace2 that can
   serve as a basis for future proposals such as Mtrace2 for Automatic
   Multicast Tunneling (AMT) [9] and Mtrace2 for Multicast in MPLS/BGP
   IP VPNs (MVPN) [10].  They are therefore out of the scope of this
   document.

additional Query/Response blocks may be defined in other documents in the near future.

> not see a reason that IPv4 addresses could not be sent as mapped into IPv6.

An Mtrace client usually assumes to get Mtrace Response with the same address family. The Response with the different address family may be useless for the client as s/he may not have the different one. Hence routers receiving IPv4 Mtrace Query should reply back IPv4 Response even if the routers have IPv6 address.
If the client receives meaningless IPv4 Responses and has IPv6 addresses, s/he may re-run IPv6 Mtrace Query.

We also think that the suggested use of IPv4 addresses mapped into IPv6 addresses is not inconsistent. An IPv6 query could receive IPv6 mapped IPv4 addresses in the response block for “IPv4 only” network segments and this would be fine. An IPv4 query, however, cannot be expected to correctly handle a response block containing IPv6 addresses.

>   specifying for a uint32 instead of a uint8 is incorrect.

Thanks. We correct it (i.e., 0xff) in the revised document.

>    addresses to be either IPv4 or IPv6 while formatted as IPv6.

Above text will be inserted in the revised document. Thanks!

>   except for the identifying Type field of  0x02. The same applies to 3.2.3

Thanks. We reword as you suggested.

Best regards,
--
Hitoshi Asaeda