Next message: John Curran: "Re: cogent+ Level(3) are ok now"
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-root.pdf
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.
