On 7/9/22 10:11, Warren Kumari wrote:
On Sat, Jul 09, 2022 at 6:33 AM, Robert Raszuk <[email protected]> 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...
So, I have some prefixes where the backing aggregate is anycast
(2a04:4e42::/32 <https://bgp.he.net/net/2a04:4e42::/32>for example) and
the more specifics are unicast or anycast. I would be fine notionally,
marking prefix announcements based on how they are announced; we tag
them with an opaque community value that indicates which pop the
announcement comes from already for example which we can observe via
various looking glasses etc...
This might be convenient for an outsider looking at the routes but it
doesn't really tell you anything about what to do with them (nor should it).
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 <http://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
<[email protected]
<mailto:[email protected]>> 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/
<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
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/grow
<https://www.ietf.org/mailman/listinfo/grow>
_______________________________________________
GROW mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/grow
<https://www.ietf.org/mailman/listinfo/grow>
_______________________________________________
GROW mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/grow
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
