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: [email protected]
# Senior Systems Specialist ! Tel: +46 8 - 562 860 12
# Netnod AB, Stockholm ! http://www.netnod.se/
#----------------------------------------------------------------------
[email protected] 2025-11-26 09:59 [+0100]:
> On 26 Nov 2025, at 09:04, Gert Doering <[email protected]> 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
-----
To unsubscribe from this mailing list or change your subscription options,
please visit: https://mailman.ripe.net/mailman3/lists/ripe-list.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the
email matching your subscription before you can change your settings.
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
