FWIW, as the Anycast topic came up again recently in IETF mailing list, I made a comment which I can share also on this list. Disclaimer: not everybody seems to agree with my statement. Quoting myself as of Nov. 2, 2025:

I was not familiar with the processes within IETF when I had the Anycast Community marking idea a few years ago. So I didn’t know how to push it.

Accidentally during RIPE84 in Berlin I happened to discuss the idea with Maximilian, who volunteered to write the draft and submit it. I suppose I was a bit naive then.

I nevertheless learned some aspects about IETF politics meanwhile. Unless an idea is supported by «important» people, nothing will happen. That is why the draft has silently stalled.

It didn’t seem reasonable to invest more time and effort, because I’m too busy with other things more important (choose your battles wisely) and, on the other hand, those «important names» are missing as co-authors on the paper anyway. I simply and naively didn’t care about the required ego feeding which would make things happen.

Nevermind. If anyone wants to rewrite the draft and push it forward, I‘m happy to observe the hopefully successful outcome one day. -- Fredy Künzler

Init7 (Switzerland) Ltd. Technoparkstrasse 5 CH-8406 Winterthur https://www.init7.net/ Am 19.11.25 um 09:58 schrieb Randy Bush:

...

...

i thought i remembered discussion of a community tag for anycast prefixes. anyone have specific reference?

BGP community? There is

https://datatracker.ietf.org/doc/draft-ietf-grow-anycast-community/

... but that seems to have died.

thanks, gert

wonder why it died. seem useful and could be simple. oh, in the ietf, that latter could be a problem.

randy -----

On 19. 11. 25 13:05, Maximilian Wilhelm wrote:

As fate has it, someone just reached out about it recently, and we'll resurrect the draft.

Hi, Is there a practical useful way how to prevent originators to tag all their prefixes as anycast? Cheers, Jan

On 25. 11. 25 18:44, Gert Doering wrote:

The idea about "tagging as anycast" is not to make other networks prioritize these (and prioritize in which way, anyhow?) but to give them the chance to do informed decisions on hot/cold-potato routing, which might look different for anycast and for non-anycast prefixes - or, when faced with "what looks like funny routing", to do better informing debugging.

Hi, What would be your preference about how your upstreams handles your packets? Hot or cold potatoe routing? Cheers, Jan

gert@space.net (Gert Doering) wrote:

If I have an anycast setup, I'd have servers in all the places where our networks meet, so "hot potato, give it to me wherever you can", because that's the point of anycast.

And then there are the long-haul-from-asia-to-the-ixp-in-europe folks... El "IXP TE communities" mar.

actually, i came in the research door. i wanna know if a prefix is anycast so i can account for its oddness in my measurements. but i suspect the anycasters' watershed models are assuming that we will not route their prefixes differently than monocast. randy

Hi All! (Not really wanting to dive into a routing discussion, but anycast is a "special case" for me ;-) ...) Like Joe, I see a double-edged sword in such a tag. On one side, I can see debugging features. When wondering what the h-ck is going on with your traffic, being able to quickly see that the target prefix is being anycasted from several locations _could_ help you understand the situation quicker. So, from this angle, it wouldn't be an automatic routing decision influencer, it would be a debugging tool. OTOH, seeing such a tag on a prefix may want you try to do "stupid things" with it, such as trying to "outclever" BGP by fiddling with the routing. As always: we would thereby create "a system" ... which can be rigged ... Maybe a "flag" in the RIR Registry is a better option, if you want to limit the use to debugging? route: 192.36.148.0/24 descr: Prefix reserved for DNS root name server i.root-servers.net. descr: $Id: route_192.36.148.0-24,v 1.2 2010-05-26 08:52:13 liman Exp $ origin: AS29216 anycast: YES <--------- IDEA! mnt-by: NETNOD-MNT created: 2003-10-23T20:18:47Z last-modified: 2010-05-26T08:57:49Z source: RIPE Cheers, /Liman #---------------------------------------------------------------------- # Lars-Johan Liman, M.Sc. ! E-mail: liman@netnod.se # Senior Systems Specialist ! Tel: +46 8 - 562 860 12 # Netnod AB, Stockholm ! http://www.netnod.se/ #---------------------------------------------------------------------- ripe-list@ripe.net 2025-11-26 09:59 [+0100]:

On 26 Nov 2025, at 09:04, Gert Doering <gert@space.net> wrote:

...

...

What would be your preference about how your upstreams handles your packets? Hot or cold potatoe routing?

That really depends on where I am located. If I'm in just one place, but do connect in a remote location, I would prefer the local-to-me ("cold potato" for them), because that would reduce my backhaul costs.

I think what you are talking about is a signal that indicates potato temperature. I think linking this to anycast makes assumptions about other people's routing policies and what traffic management suits their network. If we are just talking about potatoes, let's just talk about potatoes.

However, I admit I am slightly perplexed about all of this. I am not sure I understand why a standard signal here is useful or who would use it. People already choose from a menu of provider-specific, bilateral signals between adjacent ASes so it is not like one more provider-specific signal creates a brand new workflow (if indeed it's a new signal at all and not one you already use). Different transit providers (of different shapes and sizes) seem likely to have different ways of interpreting such a signal (and different incentives for accepting it all). Why would we expect people to use or implement policy based on a single, standard community string? Why would we expect a consistent interpretation of the signal across different networks? What is the incentive beyond what people already do?

...

If I have an anycast setup, I'd have servers in all the places where our networks meet, so "hot potato, give it to me wherever you can", because that's the point of anycast.

I seem to think normal exit selection works just fine for this in most cases, but perhaps you have seen problems that I am not aware of. What scenarios do you see where a special routing policy would make things better? As a network provider, how would you treat a route you learn from multiple places differently if it had a hot potato signal attached to it? If you don't learn it from multiple places, why do you need to worry?

If the idea was not to request some particular routing policy, but instead to be able to tag anycast routes from origination for the purposes of measurement or troubleshooting, that seems maybe more interesting. People who are in the business of measuring the routing system do this with active measurements though, and I'm not sure if I was interested in accuracy I would stop doing that just because I saw an untested assertion from the originator of a prefix. Also, community string attributes are transitive, but I seem to think it's common practice to strip attributes you don't have a local use for (or it was once upon a time, back when I was allowed to configure routers in production). Is there reason to expect a community string attribute to be globally visible in a consistent way? If it's not a signal that can be relied upon, is it still interesting?

Joe

Jan Zorz - Go6 wrote on 27/11/2025 13:33:

No-export to that tier1 fixed the problem, but still...

you're fortunate that no-export solved it. Some people strip off all communities on ingress - including no-export. IOW, this is a signaling mechanism. You can raise a signal, but you shouldn't depend on other people seeing it or reacting to it. In real life, once a prefix passes outside your own network, all bets are off. I.e. networks should consider carefully whether or not to depend on signaling like this as a reliable mechanism for traffic control. Nick

Hi Jan, On 27 Nov 2025, at 14:33, Jan Zorz - Go6 <jan@go6.si> wrote:

On 26. 11. 25 09:59, Joe Abley wrote:

...

I seem to think normal exit selection works just fine for this in most cases, but perhaps you have seen problems that I am not aware of. What scenarios do you see where a special routing policy would make things better? Khm... We had a case where we announced our anycast prefixes to our upstream in Johannesburg and that upstream was a paying customer of a large tier1 (that we all know... :( ) and due to the fact that that tier1 received prefixes from a paying customer thye got higher preference

I have helped deploy a number of anycast services over the years. I think it's definitely true that managing a routing policy for your prefix (anycast or otherwise) through other people's networks takes care and vigilance; sometimes it takes money; it is rarely easy. I remember deploying root server nodes twenty years ago and finding that large, incumbent network operators who would only peer outside their territory caused a lot of increased latency and surprising paths. I remember European telcos who would prefer to route to other continents rather than peer within their capital cities to reach root servers, for entirely well-informed but ultimately non-technical reasons. Choosing heavy hammers like LOCAL_PREF for exit selection rather than leaving the door open to considering AS_PATH length is sometimes another example of non-technical cause and effect. It is not clear to me these kinds of thing are always (or even often) good examples of simple technical problems that can be solved with simple technical solutions. The idea that defining a well-known "anycast" community string attribute could make all of this better seems a little over-hopeful, shall we say. Joe