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

[Ole Troan <[e-mail]>]

Erik,

>>> [Resending with hopefully correct author mailing list]
>>> 
>>> 
>>> On Wed, Jan 22, 2014 at 11:46 AM, Lorenzo Colitti <[e-mail]> wrote:
>>> On Mon, Oct 21, 2013 at 4:38 PM, <[e-mail]> wrote:
>>>    When an interface on a host is initialized, the host transmits Router
>>>    Solicitations in order to minimize the amount of time it needs to
>>>    wait until the next unsolicited multicast Router Advertisement is
>>>    received.  In certain scenarios, these router solicitations
>>>    transmitted by the host might be lost.  This document specifies a
>>>    mechanism for hosts to cope with the loss of the initial Router
>>>    Solicitations.  Furthermore, on some links, unsolicited multicast
>>>    Router Advertisements are never sent and the mechanism in this
>>>    document is intended to work even in such scenarios.
>>> 
>>> Authors,
>>> 
>>> One comment here.
>>> 
>>> If the intent is that we should be able to run networks that do not send periodic RAs at all, then this document will need to require that hosts send router solicitations when their RAs (or whatever is in the RA contents, including lifetimes of PIOs, RIOs, RDNSS options, etc.) are about to expire - otherwise the hosts will lose connectivity.
>> 
>> I think it's worse than that.
>> 
>> A host on a multicast-capable link on which "unsolicited multicast Router Advertisements are never sent" will have to use the same transmission behavior as a host on a non-multicast-capable link, so that the host can learn of changes in the link prefixes in a timely fashion.
>> 
>> Furthermore, a host on a multicast-capable link won't know if multicast RAs are being sent on the link, so all hosts will have to send periodic RSs.
> 
> Even if you jump to a period RS from every host approach, there would still be operational questions on what timer to use, and whether there is a way for the operator to quickly introduce a new prefix (and retire an old prefix).
> 
> With multicast RAs the operator can change the list of prefixes (to handle some problem) quite quickly. To accomplish the same thing without the multicast RA option would imply either
> - frequent periodic RSs from all the hosts, or
> - robustly tracking the set of hosts in the routers so that unicast RAs can be used for such changes.

I don't think this document should make any reference to links that does not send unsolicited RAs.
that doesn't mean it cannot say how router discovery can work more robustly.

cheers,
Ole