On Mon, 2011-07-04 at 16:34 +0930, Mark Smith wrote: > I missed this earlier - > > > Note that the subnet router anycast address doesn't > > even ensure that the "nearest" router is contacted, which would arguably > > have been useful, because the current spec deliberately builds in a > > small random delay in responding, to avoid network congestion. > > > > Are you referring to rfc4861, section 7.2.7? The thing that makes the > first/quickest response "stick" is the Override flag being set to 0 -
That's correct, the first/quickest response will stick. The thing that stops that working in the sense of getting to the "nearest" router is this: "Nodes that have an anycast address assigned to an interface treat them exactly the same as if they were unicast addresses with two exceptions. First, Neighbor Advertisements sent in response to a Neighbor Solicitation SHOULD be delayed by a random time between 0 and MAX_ANYCAST_DELAY_TIME to reduce the probability of network congestion. Second, the Override flag in Neighbor Advertisements SHOULD be set to 0, so that when multiple advertisements are received, the first received advertisement is used rather than the most recently received advertisement." Because of that random delay, the nearest router may not be the one that "wins". It's a SHOULD, so I suppose implementations could choose to ignore that. Unless there are a LOT of routers on the link, network congestion is most unlikely to be a problem, and leaving out the delay would help the nearest router "win". But I simply see no point to the subnet router anycast address. Is there any use case that could not be equally well dealt with using all-routers-on-link or normal routed anycast? Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
signature.asc
Description: This is a digitally signed message part
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
