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/
