Subject: [MBONED] Re: Comments on mtrace version 2 draft

From: Bharat Joshi <[email-masked]>
Date: Thu, 20 Dec 2007 12:22:30 +0530

Hi,

   I sent these comments around last IETF meeting because of which I
think authors has missed this mail as it has not been replied yet. 

   Let me know if you have any questions on these comments.

Thanks,
Bharat

On Thu, 2007-11-29 at 18:22 +0530, Bharat Joshi wrote:
> Hi,
> 
>      I have few comments on this draft:
> 
> * In introduction, in following statement:
> 
> The new multicast traceroute, mtrace version 2
>    or mtrace2, can provide additional information about packet rates and
>    losses that the unicast traceroute cannot, and generally requires
>    fewer packets to be sent.
> 
> Should not we compare it with mtracev1 instead of unicast traceroute? I think it would be good if we can list down the shortcomings in mtracev1 which is addressed in this newer version and also any new features which did not exist in the previous one [Like IPv6 support]
> 
> * In section 3, in following statement:
> 
>    If a PIM-SM router is on the (*,G) tree, it chooses the parent
>    towards the RP as the previous hop.
> 
> Is the 'parent' here is the PIM Neighbor which will be used as next-hop for sending a join towards the RP for a given (*,G)? If so, please make this explicit.
> 
> * There is no 'hops' and 'Checksum' field in the traceroute query header. Please check.
> 
> * Traceroute query header and response block looks same for both IPv4 and IPv6. Why do not we make this address family independent? This has been done in PIM [RFC 4601] and I personally feel is a better way to do it.
> 
> * Why are we having 8 bytes for packet counts while the objects referred here are of 4 bytes?
> 
> * What is the use of 'Destination Address'? Is it used by the router which generates the response in anyway?
> 
> * Where can we find the meaning of 'PIM using special routing table' and others mentioned in Rtg Protocol? Can not we simply have just one value for a given protocol?
> 
> * In Forwarding Code, I think it would be better to have a bit-mask and add all the errors that have occurred on a given hop. Otherwise an administrator may get multiple failures at the same hop one after the other. A 32 bit value is enough to represent 31 error conditions which look sufficient as of now.
> 
> * In section 8.1.1, its mentioned that a duplicate query message can be identified and discarded but request message must not be ignored in this manner. Can we add some text here or somewhere else on how do we identify a duplicate request message and what do we do with them?
> 
> * At couple of places, its mentioned that 'as described in 'Forwarding Tracroute Requests'. I would suggest adding the section number here. This makes it more readable.
> 
> * Can you please add some text about 'Phanotm state' in terminology section?
> 
> * Few places it uses 'traceroute' instead of 'mtrace'. I think its better to not to use 'traceroute' to refer to 'mtrace' as 'traceroute' are mostly referred as unicast traceroute.
> 
> * In section 8.2, point #5, how would a router know if its previous hop router does not understand 'traceroute' request?
> 
> * In section 8.2, point #9, following statement:
> 
> If the router should normally forward traffic for this source and group downstream but is not, it notes forwarding code NOT_FORWARDING.
> 
> What reasons do you see for the above case?
> 
> * In section 8.4, in following statement:
> 
>    If the Previous-hop router is known for this request and the number
>    of response blocks is less than the number requested, the packet is
>    sent to that router.
> 
> Where do we set the number of requested response blocks?
> 
> * In section 8.4, can we put the text for selecting the multicast address in points. For example:
> 
> * MUST be a link-scoped group (i.e. 224/24 for IPv4, FF02::/16 for IPv6),
> * MUST NOT be ALL-SYSTEMS.MCAST.NET (224.0.0.1) for IPv4 and All Nodes Address (FF02::1) for IPv6
> * MAY be ALL-ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All Routers Address (FF02::2) for IPv6 if the routing protocol in use does not define a more appropriate group.
> * Otherwise, it is sent to the Response Address in the header, as described in Section 8.5.
> 
> * In section 8.5, please add some text describing in what all condition, a response can be generated?
> 
> * In section 8.5.4, a router would always send only one response whether the response address is unicast or multicast. So my question is why do we mention this only for 'multicast'?
> 
> * I think it would be great if couple of examples can be added here for diagnosing some specific problems.
> 
> Thanks & Regards,
> Bharat
> 
> 

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

_______________________________________________
MBONED mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mboned

---

From: Bharat Joshi <[email-masked]>
Date: Thu, 20 Dec 2007 12:22:30 +0530

Hi,

Thanks,
Bharat

---

From: Bharat Joshi <[email-masked]>
Date: Sun, 23 Dec 2007 20:56:26 +0530

Hi Hitoshi,

       Please see my replies in line for some comments.

Thanks,
Bharat

> Checksum won't be included in mtrace2 header since it is transferred
> on UDP, which includes the checksum.
>

Actually the text in the document refers to the above two fields but they do not exist in the traceroute query header.

If we are planning to use UDP checksum here we won't need a checksum field but we may still need the 'hops' field.

> In fact, regarding the header format, we may adopt TLV format in the
> revised draft. So, please look at the revised draft again.
>

Yeah. TLVs will certainly be better.

> Having 8 bytes is correct.
>

But this will never exceed a 4 byte value. This is because the MIB object this variable refers to is of 4 bytes only.

> > * Where can we find the meaning of 'PIM using special routing table'
> > and others mentioned in Rtg Protocol? Can not we simply have just
> > one value for a given protocol?
>
> Do you mention; 1) it is sufficient that mtrace2 only mentions the
> used protocol, or 2) it is difficult that mtrace2 recognizes the
> conditions in which each routing protocol is working, or 3) others?
>

Yes. I mean 1. I think its sufficient to just mention the Multicast Routing protocol.

> > * In Forwarding Code, I think it would be better to have a bit-mask
> > and add all the errors that have occurred on a given hop. Otherwise
> > an administrator may get multiple failures at the same hop one after
> > the other. A 32 bit value is enough to represent 31 error conditions
> > which look sufficient as of now.
>
> I tend to agree. We'll think about it. Thanks.
>

In this case, you may want to add a error TLV with all the possible errors.

> > * In section 8.1.1, its mentioned that a duplicate query message can
> > be identified and discarded but request message must not be ignored
> > in this manner. Can we add some text here or somewhere else on how
> > do we identify a duplicate request message and what do we do with
> > them?
>
> Mtrace2 header includes Query ID, and a router recognizes the
> duplicate request message (with IP source address and Query ID).
>
> "Duplicate Request messages MUST NOT be ignored in this manner."
> Well, I don't understand this statement.
> Bill, could you tell us the reason?
>
> > * In section 8.2, point #5, how would a router know if its previous
> > hop router does not understand 'traceroute' request?
>
> No response is its signal.
>

But IIRC, responses are sent back to the originator and not to the last hop. Right?

> > If the router should normally forward traffic for this source and
> > group downstream but is not, it notes forwarding code
> > NOT_FORWARDING.
> >
> I cannot clearly expect this situation.
> Could you show us the situation and reason, Bill?
>

If we do not get a sufficient reason for this, Please remove it.

> This may be implemented using a simple cache as with a cache
> remembering duplicate queries. We'll clarify this point in the revised
> draft.

But should not this information be available in the request packet itself?

---

From: Bharat Joshi <[email-masked]>
Date: Sun, 23 Dec 2007 20:56:26 +0530

Hi Hitoshi,

Thanks,
Bharat

---

From: Bharat Joshi <[email-masked]>
Date: Mon, 24 Dec 2007 07:53:44 +0530

It seems Hitoshi's following mail was rejected by mail server while my response to his mail went through. So here is the mail sent by Hitoshi.

Thanks,
Bharat
________________________________________
From: Hitoshi Asaeda [[email-masked]]
Sent: Saturday, December 22, 2007 8:46 AM
To: Bharat Joshi
Cc: [email-masked]
Subject: Re: [MBONED] Re: Comments on mtrace version 2 draft

Hi Bharat,

Sorry for the late reply.

> Should not we compare it with mtracev1 instead of unicast
> traceroute? I think it would be good if we can list down the
> shortcomings in mtracev1 which is addressed in this newer version
> and also any new features which did not exist in the previous one
> [Like IPv6 support]

Thanks. We'll do it.

> Is the 'parent' here is the PIM Neighbor which will be used as
> next-hop for sending a join towards the RP for a given (*,G)? If so,
> please make this explicit.

Will do.

> * Traceroute query header and response block looks same for both
> IPv4 and IPv6. Why do not we make this address family independent?
> This has been done in PIM [RFC 4601] and I personally feel is a
> better way to do it.

I agree. I already mentioned this point in the last mboned meeting.
Thanks for your comment. We will adopt it.

> which generates the response in anyway?

Destination Address is the address of an mtrace2 query sender. It may
be or may not be the same of the Response Address, which is the
address mtrace2 response will be returned.

In fact, my personal feeling here is some privacy issue or problem
caused by some DoS attack. Because IP dest addr of mtrace2 query must
be the same address of Destination Address, while Response Addr is an
arbitrary unicast address.
As shown in Sect.12.3. Unicast Replies, we must take care of this
issue.

> * At couple of places, its mentioned that 'as described in
> 'Forwarding Tracroute Requests'. I would suggest adding the section
> number here. This makes it more readable.

Ok.

> * Can you please add some text about 'Phanotm state' in terminology section?

Or we eliminate this word and clarify the meaning. I got it.

> * Few places it uses 'traceroute' instead of 'mtrace'. I think its
> better to not to use 'traceroute' to refer to 'mtrace' as
> 'traceroute' are mostly referred as unicast traceroute.

Will do.

> * MAY be ALL-ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All Routers
> Address (FF02::2) for IPv6 if the routing protocol in use does not
> define a more appropriate group.

Ok. Thanks.

> condition, a response can be generated?

Well, we will think about it.

> * In section 8.5.4, a router would always send only one response
> whether the response address is unicast or multicast. So my question
> is why do we mention this only for 'multicast'?

Because it is obvious that a unicast request yields one response.
But, anyway, we may want to refine the text.

> for diagnosing some specific problems.

Understand.

Thanks,
--
Hitoshi Asaeda

---

From: Bharat Joshi <[email-masked]>
Date: Mon, 24 Dec 2007 07:53:44 +0530

Thanks,
Bharat

Hi Bharat,

Thanks. We'll do it.

Will do.

Ok.

Will do.

Ok. Thanks.

Understand.

Thanks,
--
Hitoshi Asaeda