Greg Greg Daley wrote: > Hi Vlad, > > I'm not sure that there is a requirement to use a fastra flag. > > There may be situations where multiple nodes come up on a link > in the duration between multicast advertisements but this may be > handled by the MAX_FAST_RAS being set high enough to handle this. > In the case where many nodes come up on the link, it may > be more effective to schedule a multicast RA in any case.
This is really the situation. When the nodes that come up really need a ultra fast configuration they can request the fast RA. When the nodes don't care, multiple solicits may answered with a single multicast RA. > > I'm pretty sure that there's no problem on a network configured > for fastra to give a few of the advertisements to non-mobile nodes. Yes, but I consider that wasting resources that could be better used otherwise. > > I believe that the presence of an 'F' bit in a router solicitation > was discussed when the FastRA came up. In that solution, nodes > desiring FastRA (MIPv6 MN's?) set the bit in every RS, since they > could not determine whether the network supported FastRA or not, > or (possibly) where they were (otherwise they wouldn't be sending the > RS). > > If the bit is used, why wouldn't anyone just ask for fast response > anyway? Isn't it reasonable to expect that all nodes desire > fastest possible autoconfiguration? Not really. Most stationarry nodes (my workstation, file server, etc...) don't really need the fast RAs. They work fine with basic ND mechanisms. The goal behind the Fast RA draft, as I see it, is to help mobile nodes identify new links that became available. > > I don't see any reason to create an optimization which only applies > to especially configured subnets (access networks?) and then tell > people not to implement it in clients, since it's for MIPv6 mobile > nodes only. No, we can't tell people not to implement them. Anyone can implement anything. It's just that it has to be implemented to be used. The way the draft is written right now, a node that may not gain the full benefit of the fast RA may get a fast response. That may lead to condition where a node that really wants a fast RA to get a delayed multicast RA defeating the point of the draft. -vlad > > Greg Daley > > > Vladislav Yasevich wrote: > >> James >> >> I think that the draft is missing a trigger mechanism for a fast RA >> response. What I mean is, that if any node not requiring a fast RA >> joins the link, it will use up a fast RA that will potentially cause >> delays for a node that would really like a fast answer. >> >> You could take one of the reserved bits from the RS (there are 32 of >> them) >> and turn it in to the fast RA flag. The node that would really like >> a fast answer must set the flag. The flag will be ignored by routers >> that do not support fast RAs (according to 2461). >> >> This doesn't get rid of the malicious node consuming all of the fast >> RAs, but it provides the ablility to send the RAs sparingly. >> >> -vlad >> >> > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > -------------------------------------------------------------------- > > -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
