By having a large centralized and monolithic system, aren't they guaranteeing that mistakes cause huge splash damage and don't separate concerns?
You are effectively asking is why is there a single routing table for the internet.
To put in simple terms having a single routing table is what it makes it the internet we can share, otherwise it would just be a bunch of independent networks.
It certainly does not. If I peer with you, neither of us (generally) announce that route to our other peers, but often announce to our customers. There are many routes that are not visible to everyone, and there is no single routing table for the internet. Each BGP speaker ends up with their own routing table, although there are a lot of similarities.
BGP in this context implicitly meant external BGP . Yes, no single router necessarily sees all the routes, but all routers combined generally see the internet as a single network of networks was my point.
Convergence in this context is how most ASN will resolve on where/how to route a specific ASN traffic.
It is hard to peer with someone and not trust the routing table they publish, that is why Pakistan could by mistake block YouTube for everyone few years back.
In this case if you peered with Facebook, and they published incorrect routing for their AS you would accept it.
This doesn't mean FB couldn't have used multiple ASNs did some rolling updates etc, however without knowing what exactly fb screwed up for five hours it is hard to say what they could done differently.
No, they're asking why a single set of routers is in charge of announcing BGP routes for all of facebook. If you have multiple ASes, with independent configuration sources and independent routers broadcasting them, it's a lot harder to break everything at once.
However if even one set of routers were misconfigured and it was announcing incorrect routes for all their ASes as result of the issue then their peers will not typically drop that set alone automatically.
BGP doesn't have a Paxos / Raft style smart consensus algorithms, it runs on trust. Either their peers had to trust what FB published or they won't be peering with FB ASes in the first place.
That's what I was meant when I said it comes down to one network web of trust, and if there is a breakdown of that redundancy cannot typically help
The config database would reject routes for the wrong ASes. The router would reject it. The peers would be told "add filters so you only accept these ASes from these routers".
Maybe they have all that and it somehow broke anyway? But what it looks like from the outside is that all the ASes are controlled by the same system.
> their peers will not typically drop that set alone automatically.
I'm not sure what this sentence means.
> router would reject it.
Any of these hardware could have bugs, if one of them announces wrongly it will be propagated wrongly by all other ASes peering with them and to the next level so on and on. That is the point, at this level it is possible to fuck up globally.
> peers would be told "add filters so you only accept these ASes from these routers".
There are hundreds of ISPs , all of them peer cannot directly with each other. Routes are propagated downstream and upstream it is a web of networks running on trust.
While filtering is built into most implementations ( sadly not the protocol itself), practically ISPs have no easy way to determine which AS can actually originate which other AS'es traffic, so they don't actually implement a lot of filtering. Remember traffic can have more than 2 hops. Effectively that means you would be routing traffic for AS 3/4 hops away. Neither you nor your peer would know anything about it or whether you can trust it etc.
Even if some ISPs do drop/block the announcements, unless every single AS also implements the block there won't be an impact. Traffic would route through ASes which don't have filtering and announce the routes incorrectly . For example say AT&T blocks an incorrectly announced FB route, but British Telecom does not, BGP is designed to assume that FB has lost peering with AT&T and route all traffic for FB via British telecom.
If filtering was robustly possible we wouldn't have periodic BGP hijacking incidents as we do whether accidental or maliciously. The famous Pakistan Telecom Youtube hijacking [2] or as recently as April-2021 [3] or incidents over the last few years usually authoritative governments (such as China/Russia etc) but with impact well beyond their networks.
[1] http://www.bgpexpert.com/article.php?article=145
[2] https://www.ripe.net/publications/news/industry-developments...
[3] https://blog.apnic.net/2021/04/26/a-major-bgp-route-leak-by-...
This is partially due to design limitations of BGP, and partially due to it being nearly impossible to eliminate all sources of large scale failures in any highly complex system, and increasing the uptime of a system that already has a few nines costs an additional order of magnitude for each new nine. At some point you set your risk tolerance and have catastrophic failures now and then.
For all it’s flaws, BGP is the piece of the Internet that truly makes it decentralized. Without it, there would be a centralized routing table of some sort.
I recall major ISP's screwing up their routing tables in the past but never globally on this level.
https://www.bleepingcomputer.com/news/technology/ibm-cloud-g... (this one isn't clear, maybe BGP hijacking, and if so, not sure who the responsible party was)
https://www.catchpoint.com/blog/vodafone-idea-bgp-leak (not sure how major this one was)
You can practically search ISP bgp outage and get news about the last couple times they screwed up BGP and caused a big problem. Or service BGP and get a 50/50 chance of the service screwing up BGP or an ISP/country hijacking their routes and causing a big problem.
BGP is one of the best ways to break things at scale.
The anti-anti-pattern would be to have country specific AS's, kind of like a franchised restaurant pattern, where each country's version of fb owns their own AS that loosely forms back into the facebook mothership org, but from infrastructure point of view points to their own set of AS netspace.
Of course, we can't really know for sure until/if they release exactly what caused this issue.