Subject: [MBONED] Comments on draft-asaeda-mboned-mtrace-v2 version 11

From: "Kerry Meyer (kerrymey)" <[email-masked]>
Date: Wed, 12 Aug 2015 22:39:46 +0000

Hi Asaeda-san,

I have reviewed the current version of the Mtrace-V2 specification and am
attaching my comments to this email. Most of my comments are minor, but
there is at least one modification I am suggesting that is needed to
provide a consistent description of how to specify the IPv4 Src Mask field
for ³all sources². (The current specification appears to have
contradictory values specified for this field.) It also seems that the
current specification does not provide an unambiguous algorithm for
tracing hops upstream from the RP for a PIM-SM mroute. I have provided a
couple of suggested alternatives to handle this.

Please let me know if you have questions on these comments or would like
clarification on any of the comments.

           Kerry Meyer

**************

Mtrace V2 Draft Comments

(REF: draft-asaeda-mboned-mtrace-v2 version 11)

___

Section 3.

- If the length of a TLV exceeds
   the length specified in the TLV, the TLV SHOULD be accepted; however,
   any additional data after the TLV SHOULD be ignored.

any additional data after the +specified + TLV +length + SHOULD be ignored.

Comment: The phrase ³the TLV² in the current wording is ambiguous. This
change resolves the ambiguity.
‹‹‹

3.2: ³Šin detailsŠ² ==> ³Šin detailŠ²

‹‹‹

3.2.1/Hops: ³ŠMAY issues another Mtrace2
      Query with the lower number of hopsŠ² ==>

      ³ŠMAY issue another Mtrace2
      Query with a lower number of hops..²

‹‹‹

3.2.4/Total number of packets for this source-group pair:

      If the S bit is set and the Src Mask field is 63,
      indicating no source-specific state, the count is for all sources
      sending to this group.  ==>

      If the S bit is set and the Src Mask field is 127,
      indicating no source-specific state, the count is for all sources
      sending to this group.

Comment: As currently worded, the value of ³63² appears to be inconsistent
with the description of the ³Src Mask² field, which says: ³ŠIf the router
is forwarding solely on group state, this field is set to 127 (0x7f).² If
I am misunderstanding the intent here, please explain and please add the
corresponding additional details to the ³Src Mask² description.
Alternatively, it would be fine to use ³63² in both places. (This would be
consistent with the equivalent specification for IPv6.)

‹‹‹

4.

This section describes the router behavior in the context of Mtrace2
   in details. ==>

This section describes the router behavior in the context of Mtrace2 in
detail.

  Comment: Drop the ending ³s² to obtain the correct form of the
expression ³in detail².

_______

4.2.2 Step 8

What if the RP is on the SPT between the initiating client and the source?
How can the remaining hops be traced? For a router running in PIM Sparse
Mode, shouldn¹t this only be done for a non-source-specific query? See the
related comment for section 6.1. If this is changed, a corresponding
change should be made in the ³Introduction² paragraph immediately
following Figure 1. (Change ³LHR² to ³LHR or PIM-SM RP².)

_______

4.2.2

Should there be a step describing the handling at the FHR? (e.g.

If this router is directly connected to the specified source or source
network on the incoming interface, it sets the incoming interface in the
response block and sets the upstream router field of the response block to
zero. In this case, the router will send an Mtrace2 Reply to the client to
terminate the trace.

)

I realize that the ³Introduction² says this, but it would be useful to put
it in this section also.

_______

6.1

This Mtrace2 Query may be unicasted to the RP.

Comment: Since the client is not, in general, directly connected to the
RP, wouldn¹t this cause the RP to immediately return a WRONG_LAST_HOP
Forwarding Code as described in section 4.1.1? Alternatively, this section
could be changed to explicitly allow unicasting of a query to a PIM SM RP,
specifying that the RP takes the same actions as an LHR.

_______

9.5

In order to prevent abuse, the routers in the traced MAY Š ==>

In order to prevent abuse, the routers in the traced path MAY Š

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 25 Aug 2015 13:48:51 +0900

Hi Kerry,

Thank you very much for your careful review!
(And I’m sorry for the late response.)

> 2015/08/13 7:39, Kerry Meyer (kerrymey) <[email-masked]> wrote:
> 
> Hi Asaeda-san,
> 

Tiny thing. Must be draft-ietf-mboned-mtrace-v2. :)

> change resolves the ambiguity.

Thanks. I’ll correct this.

> 3.2: ³Šin detailsŠ² ==> ³Šin detailŠ²

Thanks.

>      Query with a lower number of hops..²

Thanks.

> consistent with the equivalent specification for IPv6.)

Absolutely.
"If the S bit is set and the Src Mask field is 127,” is correct.

>  Comment: Drop the ending ³s² to obtain the correct form of the

Done.

> following Figure 1. (Change ³LHR² to ³LHR or PIM-SM RP².)

Yes, this should only be done for a non-source-specific query.
Does the following statement address the issue?

"If this router is the RP for the group for a non-source-specific query, note a Forwarding Code of REACHED_RP. The router will send an Mtrace2 Reply and terminate the trace.”

To give the consistency, I’ll also change the statement in the Introduction as follows.

"When an Mtrace2 client initiates a multicast trace anywhere on the  Internet, it sends an Mtrace2 Query packet to the LHR or RP for a   multicast group and a source address."

> I realize that the ³Introduction² says this, but it would be useful to put

I understand. I’ll add it in the section.

> specifying that the RP takes the same actions as an LHR.

Thanks for your point.
I agree that it is good to specify the RP takes the same actions as an LHR in section 6.1.

> In order to prevent abuse, the routers in the traced path MAY Š

Thanks. Will be done.

I’ll submit the revised draft within a week or so.
If you have additional comments, please let me know.
Thank you very much.

Regards,
--
Hitoshi Asaeda