Subject: Re: RS Delays (was Re: [mobile-ip] Mobile IPv6 Issue 154: ND Constants (Router Advertisement))

From: Erik Nordmark <[email-masked]>
Date: Thu, 23 Jan 2003 00:10:50 +0100 (CET)

> The other issues related to RS's are the
> MAX_RTR_SOLICITATION_DELAY, which is used for both
> DAD delays and RS delay on link-up (maybe RA reception
> in DAD).  The MN 'SHOULD' wait a random period up to
> MAX_RTR_SOLICITATION_DELAY (per 2461) in order to prevent
> multicast bombing of links and routers on link-up.

Another issue (which I think belongs in the fastRS work) is
the random delay when a router responds to a RS. RFC 2461 says:

   In all cases, Router Advertisements sent in response to a Router
   Solicitation MUST be delayed by a random time between 0 and
   MAX_RA_DELAY_TIME seconds. (If a single advertisement is sent in
   response to multiple solicitations, the delay is relative to the
   first solicitation.)

            MAX_RA_DELAY_TIME                 .5 seconds

This random delay is in RFC 2461 to handle links with multiple routers
where, without delay, all routers would send a RA at the same time
in response to the multicast RS.

If the routers were manually configured to know how many routers are
attached to the same link, or if there is a single "RS responder" 
being elected from among the routers, then this delay would not be needed.

  Erik

---

From: Greg Daley <[email-masked]>
Date: Fri, 24 Jan 2003 09:16:58 +1100

Hi Erik,

This issue is being looked at in:

draft-mkhalil-ipv6-fastra-02.txt

and it also has been looking at the
de-synchronization of response from routers
(allows only one router to work without delay,
through manual configuration).
Certainly, there may be some benefit in looking
further at Fast RS Responses in the scenario
of synchronized movement though.

Greg