Re: IPv6 Anycast has been killed by LINUX patch in 2016 - who cares?

[Robert Raszuk <[e-mail]>]

> In practice, routing on the Internet does never change this way.

I recommend you spend a moment on RIPE BGP Play to observe how real life
routing paths change to any anycast address sourced by more then one ASN.

If my TCP session is supposed to last 1s - maybe routing changes will not
impact it. But if someone uses anycast to establish long lasting TCP
sessions (say 12h) - Good Luck !

And that is with or without stable flow lable. Just look at IPv4 where flow
label does not exist.

Thx,
R.

On Sun, Aug 8, 2021 at 1:27 AM Töma Gavrichenkov <[e-mail]> wrote:

> Peace,
>
> Now, speaking of compromises,
>
> On Sun, Aug 8, 2021 at 1:09 AM Robert Raszuk <[e-mail]> wrote:
> > Every second routing may decide for you to prefer some other BGP path
> and your anycast destination may end up in different destination naturally
> only by following the destination routing paradigm.
>
> In my opinion, this is a perfect sample of a bad engineering approach.
> Here's why.
>
> In practice, routing on the Internet does never change this way.  A
> single BGP route announcement takes some 30 seconds to propagate, and
> sometimes a route withdrawal takes more than 4 minutes.  Severe
> routing changes by an AS are just not expected to happen more
> frequently than a few times in an hour, and massive changes shouldn't
> happen more often than once in a few hours, because they might cause
> routing loops, weird routing issues, and prolonged network
> unavailability otherwise.
>
> This is the limitation to rely on for an application, or, somewhat
> worse, for a transport protocol.
>
> Engineering is basically a process of developing compromises over
> limitations.  You need to thoroughly understand the latter to build a
> system.  Engineers don't build houses capable of resisting the energy
> of an intergalactic meteor landing.  Your car would break and kill you
> if you smash it into the wall cruising 900 mph, and I don't even need
> to know the make to tell you that, because I already know your car
> certainly isn't a Batmobile, and it's therefore built on compromises,
> over limitations, and there are warning signs on every road because of
> that.
>
> An attempt to pretend the Internet engineering doesn't have to keep
> any limitations in mind just leads to bad engineering practices.
> There's always a compromise, and you need to know the limitations.
>
> And there are no limitations on the Internet of the past, present, or
> the future, which could possibly make the anycast impractical.
> Application designs may do, because of poor engineering practices, but
> that's it.
>
> --
> Töma
>