Hi Vlad, Vladislav Yasevich wrote: > 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.
It really depends on your multicast advertisement interval. We're unlikely to see ANY rs's from fixed nodes within a relatively short interval (say 10s on networks supporting MN's). So the only situation where this will be a problem is if the network is just coming up, and all devices are (re?)configuring their addresses. In the unlikely event that an MN changes to that network during these few seconds, if it doesn't do the 'SHOULD wait before sending RS' which all other nodes will be doing, then it is likely to be one of the first to receive response in any case. >> 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. Since the resource is renewed continuously, we're only talking about fallback to multicast in the case of DoS or the link coming up. >> 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. As far as I can see, there's only an issue with sharing fastRA's: When a link comes up and multiple nodes all need access. In this case, stationary nodes are already running and are just as likely to have existing conversations as MN's. They will all need as fast a response as possible. >> 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. I'll have to say that I really don't see a problem on links which have few fixed nodes. In the case where a router is configured especially for supporting MN's, I don't think that there is any harm in generating a fastRA even when it is not asked for. Also, I don't see the harm in explicitly requesting fastRA in RS's, so, any recommendation short of a "MUST NOT reply with fast RA to packets where 'F' bit is 0" is fine with me. I'm just trying to make minimal changes to node function. Greg -------------------------------------------------------------------- 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] --------------------------------------------------------------------
