Re: quick question on draft-vyncke-6man-mcast-not-efficient

[Lorenzo Colitti <[e-mail]>]

On Thu, Feb 27, 2014 at 3:47 AM, 神明達哉 <[e-mail]> wrote:

> If there's actual traffic to/via that neighbor, it *may* involve NS/NA
> ('may' because it could even be optimized out if the node implements
> the optimization for the DELAY state and applies it), but in that case
> the main traffic itself would "wake up mobile devices" anyway, so I
> don't understand the point of this discussion.
>

What he said.

I don't understand what the problem is either.


   1. 1. If it's multicast traffic we're worried about, then this traffic
   is unicast and we shouldn't be worried about it. If the IP to MAC mapping
   has expired from the ND cache, then why did it expire?
      1. If it expired because the router overflowed the ND table (i.e., it
      thought it was keeping too much state and had to throw it away), then
      there's no way to fix that - even address registration won't
help, because
      the amount of state is the same.
      2. If it didn't expire due to state exhaustion, well, implementations
      can fix this problem it by simply *not expiring ND cache entries
when they
      don't need to*.
   2. If it's raw packets and battery impact we're talking about, then...
   you're sending that neighbour unicast packets already, so it's awake and
   using power. The additional traffic caused by one 72-byte unicast packet
   every 30 seconds seems like something that's not worth worrying about
   except in the most remote of corner cases.

If it ain't broke, don't fix it.