Because in networking, if you buy two uplinks and don't check the paths they're taking, fate demands that the fiber seeking back hoe just took out that one duct it turns out both of your "redundant" lines go down
even with KMZs supplied, this still happens. complications in some cases. but an IP product (like starlink), i dont see the same equivalence. at what point does fate sharing analysis end in such a scenario?
That's the point. If you want a reliable separate path, you must test it, and you must be prepared to spend time and money on fixing it. The tests include calling up the engineering manager for the separate path and verifying that it has not been "re-groomed" into sharing a path with your primary -- monthly or quarterly, depending on your risk tolerance.
Operations work does not end because the world keeps changing.
it certainly ends in somewhere resembling cost-effective. "reliable" has its meanings in context, and backhoe issues aren't so much of a problem architecturally for starlink.
they have incentive and capability to get that traffic off the shared fate should it occur (even if that extends up to starlink serving one of their IP transit providers for OOB). that's why i question the wisdom of being overly concerned with starlink's particular paths.
I see you haven't met Google's production backbone network(s)... We intentionally didn't connect the Middle East and India (due to a combination of geopolitics and concerns around routing instability), so any traffic between the two would go the long way around the world, incurring a 200+ ms RTT penalty.
Agreed entirely on your point that if you're buying multiple redundant links, you're responsible for making sure that they're actually relying on different underlying fiber spans.
In practice I don’t know how rapidly they’re able to route around damage to the ground network that could be shared, though.