I thought the bigger /32 prefix should be advertised from AS64511 to both AS13335 and AS64510.
Is there free BGP peering for the purpose of only passing on the NLRIs?
It's interesting that on the "open positions" page, the location filter appears to be strictly string matching, e.g. "US" does not cover "New York, US"
I don't think it makes sense for AS64511 (example customer) to advertise the /32 to AS13335 (Cloudflare) when they only want the /48 to be routed through Cloudflare.
The /32 is going to matter for the addresses outside the /48. The customer only wants one /48 to go through Cloudflare; from the article context, probably because that /48 is under DDoS. DDoS scrubbing services are expensive in dollars and latency (and sometimes network features), so you only want to expose your traffic to that when necessary. When the DDoS is over, you don't want any of your traffic going through Cloudflare, so you withdraw the /48, you wouldn't want to advertise the /32 through Cloudflare at that point either.
Using the article's example ranges:
If the customer's IP 2001:db8::1 is being DDoSed, then they advertise 2001:db8::/48 through cloudflare, but 2001:db8:1::1 doesn't want that; it'll be handled by their 2001:db8::/32 announcement on their usual ISP(s)
> Things get more interesting when AS64510 signals for 2001:db8::/48 to be withdrawn by Cloudflare (AS13335)
Typo - shouldn't that be AS64511?
...and...
> The MRAI specifies the minimum amount of time ... between each BGP advertisement update.
Each update _per prefix, per peer_. RFC4271 sec.9.2.1.1 says
---
[MRAI] determines the minimum amount of time that must elapse between an advertisement
and/or withdrawal of routes to a particular destination by a BGP speaker to a peer
---
I thought the bigger /32 prefix should be advertised from AS64511 to both AS13335 and AS64510.
Is there free BGP peering for the purpose of only passing on the NLRIs?
It's interesting that on the "open positions" page, the location filter appears to be strictly string matching, e.g. "US" does not cover "New York, US"
I don't think it makes sense for AS64511 (example customer) to advertise the /32 to AS13335 (Cloudflare) when they only want the /48 to be routed through Cloudflare.
/32 is not gonna matter when /48 is present. When /48 is not present, why wouldn’t /32 be advertised?
The /32 is going to matter for the addresses outside the /48. The customer only wants one /48 to go through Cloudflare; from the article context, probably because that /48 is under DDoS. DDoS scrubbing services are expensive in dollars and latency (and sometimes network features), so you only want to expose your traffic to that when necessary. When the DDoS is over, you don't want any of your traffic going through Cloudflare, so you withdraw the /48, you wouldn't want to advertise the /32 through Cloudflare at that point either.
Using the article's example ranges:
If the customer's IP 2001:db8::1 is being DDoSed, then they advertise 2001:db8::/48 through cloudflare, but 2001:db8:1::1 doesn't want that; it'll be handled by their 2001:db8::/32 announcement on their usual ISP(s)
You are right I missed the DDoS part and that cf is not a typical uplink in this use case.
Interesting that this comment was added 9 days ago all of a sudden it pops up now with a 3hour stamp.
This happens when a story is revitalized through the second chance pool.
https://news.ycombinator.com/item?id=26998308
https://news.ycombinator.com/pool
A zombie comment? How appropriate…
> Things get more interesting when AS64510 signals for 2001:db8::/48 to be withdrawn by Cloudflare (AS13335)
Typo - shouldn't that be AS64511?
...and...
> The MRAI specifies the minimum amount of time ... between each BGP advertisement update.
Each update _per prefix, per peer_. RFC4271 sec.9.2.1.1 says
--- [MRAI] determines the minimum amount of time that must elapse between an advertisement and/or withdrawal of routes to a particular destination by a BGP speaker to a peer ---