@woody "simplify peering operations"
...by increasing their explicit peer count by who-knows-how-many?
"and increase routing security"
...by not leveraging the routing security some IXes have implemented? 🤨 (I'm looking at you, MICE. 😘)
This seems, yes: backwards. Which is maybe on-brand for Google, these days.
@woody saw this at the tiny SOLIX in Stockholm yesterday. Google has a 30G link there that a single RS peer (INETCOM🇷🇺) was completely saturating all day every day, and that relationship was the bulk of the traffic for the whole IX.
Now that Google no longer accepts the RS routes they're down to under 5Gbps of traffic—the links are no longer saturated. Things got a lot better for those peering bilaterally with Google.
@Drwave @woody overall, no—Google requiring bilateral peering agreements with operators rather than automatically peering with anyone over a route server at an internet exchange will increase the average route distance between Google and eyeball networks and thus makes the Internet slower.
But I highlighted a case where the change had a silver lining because it had a side effect of eliminating congestion on this particular set of 3x10G Google network ports.
@woody I worked at a company that took this stance (direct peering only, no route server peering unless required). At the time, responsiveness to IX peering requests was not great, so some folks decided to just static route the appropriate traffic to our exchange address at a few locations. You can imagine how awesome that was when we were trying to take a router out of service. 😆
I can't imagine this going much better for Google.
@woody The justification at my former employer was "better control over traffic," but I think given a little bit of extra time we could have had the same level of granularity with route servers using AS path filtering.
In hindsight, it was mostly a "because we can, and we can't be bothered to put in more effort" move, which given the size and culture of the company is less than surprising.
@woody i think the effect and reasoning behind it very much depends on if they accept private peering for nearly all IX members or not. Getting to know their peering partners better and getting reliable contact data about them could be reasonable points behind this change.
On the URL you show in your image there are a few conditions they mention. I think they don't sound unreasonable. There is just one critical point: "- Sufficient traffic volume (as determined by Google, at its discretion)"
So, what traffic volume is that? Does that also cover the traffic very small ASes have with Google?
@woody I had much the same reaction when we received notice of this programme a few months ago as a LONAP peer.
However, in practice;
* through their portal (much as I am not a fan of every bloody network making me sign up for their portal) they were responsive,
* the portal is nowhere near as much hassle as the azure one was,
* they actually turned up peering with us no questions asked despite not meeting their stated policy of minimum 2 locations
I guess the policy is out of date?
⬇️ "As part of Google's effort to simplify peering operations and increase routing security we have decided to stop advertising and receiving prefix information from Route-Servers in Internet Exchanges. The BGP session with the route servers will remain established. We are planning to implement the change in your IX in the next few weeks.
We won't disconnect from the IX and we will keep current BGP bilateral sessions with individual peers on the IX. We invite other networks that rely on Route-Servers to request a bilateral session. Bilateral session request can be done at: https://isp.google.com/iwantpeering
We kindly request you to inform peers in your Internet Exchange of these future changes so they can request bilateral sessions with us if they desire to do so."