Re: [MBONED] Spencer Dawkins' No Objection on draft-ietf-mboned-mtrace-v2-22: (with COMMENT)

[Kerry Meyer <[e-mail]>]

Hi Spencer,


> On Feb 7, 2018, at 7:26 PM, Spencer Dawkins at IETF <[e-mail]> wrote:
> 
> Hi, Kerry,
> 
> On Wed, Feb 7, 2018 at 6:06 PM, Kerry Meyer <[e-mail] <mailto:[e-mail]>> wrote:
> Hi Spencer,
> 
> Please see inline below for responses to some of your comments and questions.
> 
>              Kerry
> 
>> On Jan 24, 2018, at 8:44 AM, Spencer Dawkins <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Spencer Dawkins 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 <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/ <https://datatracker.ietf.org/doc/draft-ietf-mboned-mtrace-v2/>
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> I support Mirja's Discuss ballot point on IANA.
>> 
>> In addition, I have a few comments.
>> 
>> I'm looking in the Introduction for an unambiguous statement as to whether this
>> mechanism can be initiated by a source, and I'm not seeing one. Just based on
>> the Introduction, I'm guessing not, but the Introduction starts by mentioning
>> that it's difficult to trace from the source, so I'm confused.
>> 
> 
> It is fine for a source to initiate a trace by sending an mtrace Query to a given receiver. This results in an upstream (reverse) hop-by-hop trace that will yield the correct result. The introductory comment is intended to contrast the requirements of doing this type of tracing for multicast (which uses Reverse Path Forwarding to make routing determinations) versus the unicast form of traceroute, which works as required by doing hop by hop downstream tracing toward the destination.
> 
> Would it be helpful if the following introductory sentence were rephrased to clarify this point?
> 
> *********
> 
> Current:
> 
> Given a multicast distribution tree, tracing from a multicast source
>  to a receiver is difficult, since we do not know on which branch of
>  the multicast tree the receiver lies.  
> 
> *********
> Proposed:
> 
> Given a multicast distribution tree, tracing hop-by-hop downstream from a multicast source
> to a given multicast receiver is difficult because there is no efficient and deterministic way to
> determine the branch of the multicast routing tree on which that receiver lies.  
> 
> That helps. Thanks.
>  
> 
> ********* 
> 
>> In section 3, I'm seeing
>> 
>>   If an
>>   implementation receives an unknown TLV type for the first TLV in a
>>   message (i.e., the header TLV), it SHOULD ignore and silently discard
>>   the entire packet.  If an implementation receives an unknown TLV type
>>   for a subsequent TLV within a message, it SHOULD ignore and silently
>>   discard the entire packet.
>> 
>> and trying to understand why these two cases are listed separately. I'm also
>> trying to understand why they're SHOULDs, but please help me understand the
>> differences you have in mind.
>> 
> 
> These sentences initially specified different actions.  when the actions were edited
> to specify the same thing for both, they should have been combined . We will
> combine them and will also modify the SHOULD to MUST.
> 
> Thanks!
>  
> 
>> I share the question about mixing IPv4 and IPv6.
>> 
> 
> Please clarify: What is your question regarding mixing of IPv4 and IPv6? 
> 
> Sorry, I should have bounded your search space. I meant the question in Alia's ballot, which was 
> 
> "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."
> 
> but I'll let you two talk that one out.

Okay. We will handle this issue on the thread with Alia. Quick synopsis: An IPv4 address mapped to IPv6
is okay in an IPv4 mtrace message. The document also states that unnumbered interfaces are
represented using the “0” address for the underlying address family. (See the related section quoted
below in this email.) Actual mixing of address families, however, would create parsing ambiguities
that could only be resolved by adding fields to the message to explicitly specify the address family.
 
>  
> 
>> Is the last sentence in
>> 
>>   Upstream Router Address: 32 bits
>>      This field specifies the address of the upstream router from which
>>      this router expects packets from this source.  This may be a
>>      multicast group (e.g., ALL-[protocol]-ROUTERS group) if the
>>      upstream router is not known because of the workings of the
>>      multicast routing protocol.  However, it should be 0 if the
>>      incoming interface address is unknown or unnumbered.
>> 
>> normative?
>> 
>> 
> Are you suggesting that the “may” and “should” in the preceding
> paragraph would be more appropriately stated as MAY and SHOULD?
> (Please confirm.) If so, we will change these terms accordingly.
> 
> That would help, but what I was asking was whether that was true by definition, and not just an interoperation requirement.
> 
> If the incoming interface address is unknown or unnumbered, is there a reason why the Upstream Router Address would not be zero?

Thanks for clarifying. For the case where the upstream interface is not known or is unnumbered, there is really no reasonable
option other than to specify an address of 0, so we will change the “should” above to a “MUST”. For the case where the upstream
interface is known, but the RPF neighbor address is not known, we can use “MAY” to indicate that use of a multicast address
is an implementation option.

> 
> Thanks!
> 
> Spencer 
> 
> _______________________________________________
> MBONED mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mboned