Randy's description of the issue with NO_EXPORT is correct. It has never appeared to be particularly widespread. It is not specific to anycast. 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. This is clearly a routing problem and routing policy is clearly the responsibility of ISPs. The local ISPs should make sure that routes of local nodes do not propagate far enough to cause unwanted load. Consequently we could just announce one route without doing anything to it and "wash our hands" as far as routing and network load is concerned. Server load is not a concern here because in the case of local nodes the network will saturate far more quickly than the server. This is a very clean solution. It keeps responsibility where it belongs and does not introduce extra complexity in BOP routing. I like it. ;-) However we try to be helpful and provide tools to the ISPs by tagging the routes from such "local nodes" with NO_EXPORT and we artificially lengthen the AS-paths to the global nodes in order to make the local nodes more attractive to ASes that hear both. The latter is problematic too because it can cause non-optimal node selection but does not lead to anything worse than that. Remember that these are nothing but hints to ISPs who determine their own routing policy and are responsible for it. So if someone barks at K for this it is the wrong tree for the most part. What should we do? Stop giving the hints? Add complexity by announcing another less specific covering prefix like F does? Any better ideas? We are currently in an evaluation phase of our anycast deployment. We are taking measurements and are analysing them. Early results: http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51-anycast_k... We are also seriously considering to reduce the number of local nodes where this is feasible. This is a good time to hear good ideas. Let us have them. Daniel PS: Bill, I hope this also answers your question on why we do this. We have been doing it for a long time too. As I said: suggestions are welcome.