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

[Lorenzo Colitti <[e-mail]>]

On Thu, Jan 9, 2014 at 11:57 AM, Samita Chakrabarti <
[e-mail]> wrote:

>  *A revised/improved ND is needed for IPv6.*
>
>  *We started on this draft  sometime ago, after an IOT IAB workshop where
>  people felt that clearly there is a need to clarify IPv6 ND behavior to 1)
> reduce multicast messages 2) allow removal of DAD in some situations 3)
> allow registration of nodes for reliable ND operation when multicast is
> reduced.*
>

Samita,

I think statements like "is needed" and "people felt" are not enough to
justify substantial changes to a core part of the protocol. The rationale
should be clearly stated in technical terms in the document, and should be
convincing on its own merits. For this sort of changes to core protocols,
the bar should be set very high.


>  *There are some real wireless and  wired  deployments which will benefit
> if the ND registration/optimization for IPv6 is specified in one document
> as a standard without affecting the legacy ND implementations or
> deployment. [ Check out the appendix section]*
>

Sorry, I didn't provide comments on the rationale in the appendix. Here are
some comments now:

1. Datacenter deployments. Really? A datacenter is a place where machines
have high-bandwidth interconnects and plentiful CPU because they are
engaged in production activities - otherwise you don't build a datacenter.
I cannot imagine that even if a datacenter at trough consumes 1/10 of the
compute power of one at peak, that the energy saved by efficient ND is even
a drop in the ocean of cooling, power conversion losses, energy used by
network equipment, etc.

If a machine in sleep mode cannot receive ND packets, then it cannot
receive unicast packets either and there's no point proxying ND requests
for it. Remember - ND is only performed *when someone wants to send you a
packet anyway*. If the machine *can* receive ND packets, then presumably
going into and out of sleep mode is fast, so to save energy it's enough to
ensure that ND is only triggered rarely - which there are ways to do as
listed in my previous email.

2. NUD scaling on the BNG. What's the use case here? Is it to reduce the NS
messages sent to the CPE to make it easier for the CPU? Is there any
evidence that the load is significant enough to care, and if it is, that
something like this can't just be done on the linecards? As for wired and
wireless devices, I think I addressed that point in my previous email.

3. M2M. Agreed, but that's what 6lowpan is for, right?

4. Wifi. I already addressed this, but let me address it again. a) Do you
run IPv4? If you run out of multicast bandwidth, IPv4 is broken. b) In
large wifi networks, which is the only place that this is really an issue
exists, the infrastructure is usually more than capable of converting
multicast to unicast. c) If the concern is power draw on devices, then the
wifi chipsets of those devices are are receiving packets all the time,
right? There are constant beacons, and so on. So it's just a matter of
telling the wifi chipsets to drop packets that aren't addressed to
multicast addresses that the device hasn't registered for. Wifi chipsets
already have RX filtering that can do this.


>  *Our solution is looking into minimal changes to the clients and most of
> the changes are in the Router implementation and  some implementations
> already exist through RFC6775 – however that does not directly address IPv6
> legacy networks.*
>

By definition, legacy networks can't use new technology. If what you mean
is "non-6LowPAN IPv6 networks", then the question is - do we really need
such a level of energy efficiency in these networks?

If those networks happen to run IPv4 - which basically *all* hosts on
broadcast networks do, then the answer is a clear no - because ARP is much
more wasteful than ND. When we move to IPv6-only, then we should definitely
reconsider this optimization, but until then, there will be no benefit.

Cheers,
Lorenzo