Re: [v6ops] draft-ietf-6man-grand : saving lookups

[Gyan Mishra <[e-mail]>]

As these issues can get overwhelming complex as we dig into the weeds, I
agree a series of small drafts to address these issues makes sense.

Thanks

Gyan

On Wed, Aug 12, 2020 at 10:32 AM Pascal Thubert (pthubert) <pthubert=
[e-mail]> wrote:

> Sleeping devices should have a helper that covers for them; the more
> troubling case is that if a silent device, like this printer in the
> corner.
>
> Not sleeping just sitting there and very sure that it will get packets for
> a very long time. As opposed to a phone that would fully benefit from
> grand, that guy will not benefit at all after day one? Unless it renews the
> binding.
>
> To Jen’s point, the host does not need to guess the lifetime in the BCE.
> When something is needed we must add a protocol element to pass it, that’s
> what protocols do.
>
> Now I’d argue that all addresses should not get the same service from the
> router, and only the host k owe if the address should be short or long
> lived. This is why the lifetime in of the binding in the router should be
> requested by the host and granted by the router. This is nothing new,
> mobile IP works exactly like that.
>
>
> Regards,
>
> Pascal
>
> Le 12 août 2020 à 16:10, Lorenzo Colitti <lorenzo=
> [e-mail]> a écrit :
>
> 
>
> On Wed, Aug 12, 2020 at 12:55 PM Jen Linkova <[e-mail]> wrote:
>
>> > 2) I think MAY is too weak to rely on. One possibility to deal with 1)
>> >    and 2) is to have an RA option that specifies the interval. Then we
>> >    can make sending the NAs if the option is present a SHOULD or MUST
>>
>> I'm not convinced we shall be doing it in the first place ;) And MUST
>> or even SHOULD look like a very strong requirement on all hosts just
>> to cover the very special case of sleeping devices.
>>
>
> +1 to not doing this, because some of those "sleeping devices" might also
> be routers (e.g., a phone that is sharing the wifi connection). Per spec,
> any packet to ff02::2 will reach and potentially wake up those devices. If
> these packets become common, the devices will be forced to choose between
> a) bad battery life and b) violating the spec (or at least nullifying its
> utility) by dropping the packets.
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD