Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt

[Ralph Droms <[e-mail]>]

On Jan 23, 2014, at 1:52 PM 1/23/14, Lorenzo Colitti <[e-mail]> wrote:

> On Thu, Jan 23, 2014 at 9:48 AM, Ralph Droms <[e-mail]> wrote:
> > This may be difficult to specify correctly. Specifically, it may be hard to distinguish something that is being deprecated by the network (e.g., an RA whose lifetime is counting down because it comes from a PD) from an RA that is about to expire.
> 
> Might not be necessary to differentiate.  Regardless of why the prefix lifetime expired and whether the host has configured other , the host will likely want to send periodic RSs in case a new prefix becomes available and "unsolicited multicast Router Advertisements are never sent" implies no RA to announce new prefixes.
> 
> That's true, but then you get into Erik's concern that whenever a host sees that $SOMETHING is about to expire then it sends out an RS with exponential backoff (until what? until it gets an RA - any RA, from anyone?).
> 
> The concern is that basically ends up with hosts sending RSes all the time - in other words, you implement dynamic reconfiguration via polling. This is not necessarily a good use of hosts' CPU and battery resources.

You and I are pretty much in agreement here.  I'm not trying to argue in favor of sending RSes all the time.  I'm just making the observation that the basic assumptions lead to the use of periodic RSes.  I don't see that solution as an improvement over periodic RAs.

- Raph

> 
> I do think that nodes should be free to send RSes if they so choose, and I think we should say that a host MAY do so in this draft, but I don't think we should attempt to design an architecture that depends on polling.
> 
> Any objection to saying that hosts MAY send RSes when they want to refresh information (e.g., when it's about to expire)?