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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Kerry,

Top posting, but just to say that all this works for me, and thank you for
considering my comments.

Spencer

On Thu, Feb 8, 2018 at 4:11 PM, Kerry Meyer <[e-mail]> wrote:

> 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]> 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]> 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
>> 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:
>> ----------------------------------------------------------------------
>>
>> 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
>
>
>