On Mon, 25 Aug 2008, Masataka Ohta wrote:
> Dean Anderson wrote:
>
> > I recently read David Blacka's blog entry on Anycast, where Blacka
> > asserted that Anycast had to be proven UNstable before anyone should
> > consider stability questions. Blacka suggests that non-root
> > operators had no experience or data to prove these things
> > unstable--which is true and root operators aren't sharing their
> > data.
>
> As the, seemingly, only expert on anycast in the world, anycast is
> stable as long as unicast routing is stable.
>
> It should be noted that unicast TCP is unstable if unicast routing is
> unstable.
That is not so. 'Unicast routing' is, by definition, "stable" if
routing complies with RFC1812 and delivers every unicast packet to the
correct unicast host. RFC1812 allows load-splitting, and load-splitting
was the first obvious flaw in the 'anycast stable if unicast routing
stable' assertion, many years ago. Some people have asserted, without
justification, that load-splitting is somehow pathological. However,
load-splitting is not necessary to observe Anycast instablity.
Most routers expire FIB entries every 60 seconds. All routers eventually
expire FIB entries, usually in a similar timeframe. When the FIB entry
is replaced, a different, equal cost path may be installed. This FIB
could come from the interior (e.g. ospf, is-is) or the exterior(e.g.
BGP). The unicast routing system is stable because RFC1812 is
fullfulled and all unicast packets are delivered to the correct unicast
host. However, subsequent Anycast packets can be delivered to different
Anycast hosts; Anycast TCP is not stable. This instability was
explicitly stated by RFC1546. One need only send packets delayed by 60
seconds to see Anycast instability. TCP can delay packets for a long
time. Keep-alives are sent every 2 minutes, well outside the FIB
expiration time. This behavior has been experimentally observed.
--Dean
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
