Re: Alia Atlas' No Objection on draft-ietf-mboned-mtrace-v2-22: (with COMMENT)

Hi Alia,

Thanks for your review and comments.

> 2018/01/24 7:11, Alia Atlas <[email protected]> wrote:
> 
> 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.

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.

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

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.

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

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

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

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

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

Thanks. We reword as you suggested.

Best regards,
--
Hitoshi Asaeda




_______________________________________________
MBONED mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mboned