1) Section 3.2 should motivate better why Path MTU Discovery doesn't already solve this problem. Certainly one issue is that the router has to communicate a value larger than the link MTU in the IP-over-foo document, no question about that. But once that is done, why do you need the ND probing mechanism as opposed to PMTU discovery? As pointed out in 3.2 already, the main scenario for this draft is on-link communication (since anything else will be limited by the minimum path MTU which will generally be a standard number), in which case ICMP blocking isn't really an issue, and PMTU Discovery can already discover a per-neighbor MTU that's lower than the link MTU. So more motivating text seems warranted.
2) Section 4.1: Why put the number "600 Mbps" in the doc? Seems like this number would become obsolete over time, and it would just just as easy to put the threshold in the option. 3) Section 4.5 says: > However, the node MUST be prepared to receive packets up to the > SAFEMTU size. Per RFC 2460, it is not a requirement that a node be able to receive packets larger than 1500 bytes. This MUST seems to change that without explicitly saying so. I also have a couple minor editorial comments which I will just send to the author. -Dave _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
