Re: Reducing the battery impact of ND

[Ole Troan <[e-mail]>]

Erik,

again, no hats.

>> not trying to speak for Lorenzo, but I don't think he is proposing replacing periodic RAs with periodic RSs.
> 
> Ole,
> 
> I think that is the effective result of what you two are cooking up.

I cannot claim credit for cooking up that dish.
aren't you proposing to do exactly that, replace periodic RAs with periodic RSs in:
draft-chakrabarti-nordmark-6man-efficient-nd

>> example: a host successfully does router discovery. RA lifetime is relatively short, e.g. 3 * router advertisement interval.
>> host doesn't receive any of the multicast RAs (network drops them or whatever).
> 
> You are speculating about some particular failure or misfeature in the network that makes it (persistently? sometimes?) drop multicast RAs. It would be good to flesh out that particular failure mode to see
> - whether it is realistic, and
> - what impact it has elsewhere.

it's relatively trivial to reproduce, but I suppose you can argue that setting timers that way is a misconfiguration.
802.11 networks are multicast challenged, so I would expect drops to be somewhat common.
a more robust RS retransmit mechanism will help that somewhat.

> For instance, the failure could be that all ICMP packets to the host are dropped (due to some misconfigured security policy - we've seen those in IPv4). That would drop unicast RAs as well, and affect the old path MTU discovery protocol.
> 
> Or it could be that link-local multicast is misconfigured or broken, resulting in DNSSD and other protocols breaking.
> 
> Having every host on the planet send a RS every 30 seconds "just in case" doesn't sound helpful.

true, although it wouldn't be 'just in case'. I think you are making a good argument that the current RS/RA mechanism is designed quite well.

cheers,
Ole