On Sat, Jul 09, 2022 at 6:33 AM, Robert Raszuk <rob...@raszuk.net> wrote:
> Hi, > > While it may sound like I am against it - I am not. I am just trying to > make sure what we ship can actually effectively work. > > One key question for example which no one answered so far is this: > > If I have one very important service for which I would like to use ANYCAST > address across my geo distributed load balancers does this make my entire > /24 or /22 I advertise any ANYCAST prefix ? I hope not. > Unless I'm misunderstanding this completely, the community doesn't "make" a prefix an ANYCAST prefix, it simply **marks** (denotes) it as being used for anycast — this is subtle, but important to note, and seems to have caused some confusion in discussions. It an informational tag that people can use for debugging to to apply policy... But, getting back to your question — the smallest v4 prefix you can realistically announce[0] on the Internet is a /24, and so the smallest granularity you can mark at is the same. So, if you are only using one address out of a /24 as an "anycast" address **and for some reason you want to use this to mark the address as being anycast** you will have to tag the whole /24. If you are only announcing a /22, you could have to have 2 announcements, with one of the /24's tagged, or you could tag the whole /22. Generally when one is talking about Anycast one is talking about it at a prefix level anyway (and often it is "these sites are announcing the same address space and aren't intending to carry traffic between sites"). E.g: Let's say you have 192.0.2.0/24, and most of the addresses are assigned to single machines, other than 192.0.2.17, which you has assigned both to a machine in LA and Singapore. Technically 192.0.2.17 is anycast, but that's not something that you need to or should share with the outside world - it's not helpful for other people to use to build their routing policy towards you... W [0]: Pedant: Acshually, you can announce fairly much whatever, but the the smallest prefix people are likely to accept… > 100s of hosts within my blocks may use high volume torrent which I really > do not need to ANYCAST at the network/routing layer - I use geo > extensions in the DNS for it. > > So just asking simple operational question - when do we mark prefix block > as ANYCAST ? > > I think if we are serious about actually helping ANYCASTs perhaps we > should allow to advertise those addresses separate from allocated PI or PA > blocks .... For PA it will get aggregated. For PI it will a little bit > pollute the table - I guess this is why the current version of the draft > says that ANYCAST prefixes will be advertised with NO-EXPORT community. > > Thx, > R. > > > > > > > > > On Sat, Jul 9, 2022 at 11:37 AM Alejandro Acosta <alejandroacostaalamo@ > gmail.com> wrote: > >> Hello, >> >> After reading the draft and the comments on the list. I think this is >> going to be useful and will make BGP take better decisions. +1 to move >> this draft forward. >> >> I wonder about the misuse of the community ANYCAST when the prefix >> being announced is not actually an anycast prefix, can be there a kind >> of abuse from some operators?. Do we need -if not out there already- a >> list of public anycasted prefixes (and I believe I have seem this >> question somewhere). >> >> >> Regards, >> >> >> Alejandro, >> >> >> On 5/7/22 5:40 AM, Maximilian Wilhelm wrote: >> > Hey folks, >> > >> > after some discussion at RIPE84 we took the time to formalize a draft >> > to define a well-known BGP community to indicate a given prefix is >> > carrying Anycast traffic. The intent is to allow ISPs to do well >> > informed TE, especially in cases where they want to diverge from the >> > hot potato principle. >> > >> > You can find the draft at >> > >> > https://datatracker.ietf.org/doc/draft-wilhelm-grow-anycast-community/ >> > >> > Happy to share this at the upcoming meeting and hear your thoughts! >> > >> > Thanks and best, >> > Max >> > >> > _______________________________________________ >> > GROW mailing list >> > GROW@ietf.org >> > https://www.ietf.org/mailman/listinfo/grow >> >> _______________________________________________ >> GROW mailing list >> GROW@ietf.org >> https://www.ietf.org/mailman/listinfo/grow >> > > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow >
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
