From: Randy Bush (no email)
Date: Tue Nov 01 2005 - 10:41:25 EST
mornin' daniel:
> You also describe the rationale correctly by saying "it would
> be good if a server in Kenya did not take load from nyc".
> I'll expand a little more on that. K does anycast with two
> objectives: primarily to increase robustness of the service
> in the face of serious load increases, secondarily provide
> better service to some local areas in the Internet topology.
> It is the secondary objective that poses the problem. We
> operate "local nodes" which are intended to serve only a
> local area.
when it is connected to global providers, this does not work.
and do not count on the hope that small local provider p0 does
not pass the marked prefix to a global provider - that's like
saying 1918 prefixes will never leak.
[ note: i have friends in kenya, and would be happy if this
stuff would work well. this does not mean that i will
pretend that it does. ]
> This is clearly a routing problem and routing policy is
> clearly the responsibility of ISPs.
as you have deployed something that participates in the global
routing mesh, this ploy should be embarrassing. as what you
have deployed attempts to take clever advantage of a kinky, and
not widely used (guess why!), feature of the global routing
system, you would be polite to take responsibility for what
happens.
> What should we do?
at the core of the problem is the assumption that anycast will
find the closest server. thus, if the service is deployed in
many places in the topology and geography, each will only take
local load. it is critical to note that this relies on an
assumption of *very* topologically and geographically rich
deployment. it also gets bitten by the abundance of providers
with linear topologies with large geographic reach (but this
will be a short-term problem as tony hain from cisco plans to
abolish us as part of cisco's ipv6 marketing campaign:-).
> Add complexity by announcing another less specific covering
> prefix like F does?
although this further descends into the dangerous purgatory of
cleverness, you would probably be advised to do something such
as this. otherwise, even if k connected directly to all of
multi-homed t0's upstreams, by default, none of them would give
t0 your prefix because it is poisoned.
my naive view of your current deployment means that k can not
be seen from any multi-homed sites unless one or more of their
upstreams (recurse for tier-n) is even more clever and
implements "t0 is our customer and we ignore NO_EXPORT toward
customers," thus piling on yet another bit of cleverness, the
implications of which we can discover in the next level of
purgatory.
randy
|
|
|