Re: 6MAN Adoption call on raft-chakrabarti-nordmark-6man-efficient-nd-04

[Lorenzo Colitti <[e-mail]>]

On Tue, Nov 19, 2013 at 7:45 PM, Ole Troan <[e-mail]> wrote:

> Please provide a view with reasons as to whether the WG should adopt this
> or not.
>
> This message starts a one week 6MAN Working Group call on adopting:
>
>         Title           : Wired and Wireless IPv6 Neighbor Discovery
> Optimizations
>

I do not support adoption of this draft. I do see the problem, but I think
the proposed solution is the wrong trade-off.

Let's consider examine the benefit. In most networks, the problems cited
can be addressed using existing technology without requiring such a major
overhaul of a core IPv6 protocol. For example, to take the problem areas
mentioned in section 1.1:

   - It's true that periodic RA messages consume battery power, but this
   can be fixed by sending periodic RAs much less often and sending solicited
   RAs unicast, or by using DHCPv6 with long leases for address assignments.
   - It's true that NS/NA messages and RS do consume battery power, but
   unlike IPv4, ND cache entries don't time out, and thanks to the use of
   solicited-node multicast, NS messages are easy to filter either in the
   switches/APs or in the receiving devices' radio firmware. Also, the impact
   can be limited by using fewer nodes per link.
   - In many cases, it's possible to remove ND load entirely by setting the
   prefix to be off-link and having everything go through the first-hop
   router. In the case where the router is the same box as the AP, this has no
   scalability limitations at all.
   - It's true that on wifi, multicast/broadcast bandwidth is limited.
   However, this is not a problem in general-purpose networks. General-purpose
   networks typically run IPv4 as well, and IPv4 with ARP is way less
   efficient than standard ND.

I think it's fair to say that in most networks, these measures will be
sufficient to resolve most of the problems without having to alter the ND
protocol.


The cost of the proposed solution is significantly increasing the
complexity and statefulness of the ND protocol, which is implemented, often
in kernel space, in billions of general-purpose nodes. I think that's
something that requires much more compelling reasons than the ones provided
here. The concerns are not just implementation complexity, but also
operational complexity, flexibility, and reliability.  For example: part of
the promise of IPv6 is that it allows networks to be simpler and more
reliable. Putting more state in the network nullifies that promise.


Don't get me wrong - I agree that in some networks these issues are
critical, and something like this is needed. However, that's what 6lowpan
is for. I think a much better tradeoff is for power-constrained devices to
use their own ND protocol in their own low-power network (which connects to
the rest of the network via a gateway), and to leave the general purpose ND
protocol unchanged.