|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: oh k can you see
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
|