Inline:
On 8/8/06 10:54 AM, "ext Pars Mutaf" <[EMAIL PROTECTED]> wrote: > Hello, > >> From your draft: > > |Routers that implement the current recommendations would send the > |periodic multicast router advertisements every 30 minutes, which can > |be a significant problem in mobile/cellular network environments. > > Why do you think 1 multicast RA per 30 minutes is a significant problem > for a host? Personally, I would think that 1 RA per 30 mins has a > negligible impact on energy cost. 30 minutes is really longtime IMHO. So if you consider for example a GGSN which may have several hundred thousand hosts attached to it (GGSN the AR for all these hosts), having to send a periodic RA to all these hosts is an expense with no real benefit. In order to deliver the RA, the host has to be paged, radio resources allocated and a traffic channel established to deliver the RA. So what is the benefit of doing this operation? I agree that waking up a host every 30 minutes to deliver an RA is not a significant drain on the battery, but it is a factor. Additionally the fact that you have to deliver the RA as a unicast message to a very large number of hosts is a waste of the radio resources. Having a host establish a traffic channel only for the purpose of receiving the periodic RA is sub-optimal. Why have a specific interval (MAX) of 30 minutes only? Why not let it be 180 mins or 240 mins? 30 Mins is a value IMO which is as random as choosing 180, 240 or something else. > > In addition this may be useful: > Every 30 minutes (or less), my host will wake up, look around i.e. > receive the RA, thus make sure that the access router is *still* > with me, and sleep again. If the host wants to make sure whenever it wakes up (not periodically just for receiving an RA), it can just as well send a RTR solicitation to confirm that it still is connected to the AR and be happy. -Raj > > What's wrong with that? > > Thanks > pars > > > > > > On Mon, 2006-08-07 at 22:33 -0500, Basavaraj Patil wrote: >> Hello, >> >> The I-D: >> http://www.ietf.org/internet-drafts/draft-madanapalli-ipv6-periodic-rtr-advt >> s-00.txt >> >> proposes several changes to ND procedures and parameters. >> >> Pls review and comment. >> >> -Raj >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
