[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[MBONED] Comments on mtrace version 2 draft
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
MBONED at ietf.org
https://www1.ietf.org/mailman/listinfo/mboned