On 11/8/24 21:00, Nick Hilliard wrote:
gonna disagree on this one. Route servers are aimed at leaf networks, networks with simple routing policies, and arguably also networks with complex routing requirements, but where the RS provides reachability to ASNs which they're not picking up elsewhere. They can cause a good deal heartache for networks which have complex policy requirements and in situations where there's already dense interconnection between the ASNs visible on the RS. Several of the larger content networks don't want to use RS's, and they have good technical reasons for not wanting to do so.
The original intention for route servers is to simplify turn-up for the majority of networks, most of whom will be eyeball-focused. They did offer cloud & content folk utility as they quickly ramped up their CDN deployments globally over the past decade-and-a-bit. While their challenges are as well as documented as their benefits, moving away from them can "uncomplicate" the routing topology of large operations like those of cloud & content. The unintended side effect is that it can lower traffic load on IXP-specific caches (that traffic would move over to transit until the remote peer can re-establish peering via a bi-lateral session), which bodes well for cost and resource control.
The flip side of this is that unless you're prepared to implement the sort of routing security configuration that route servers typically implement these days, or to trust that the other party has done this, then bilateral peering sessions will open you up to wide range of routing security problems. I'd be fairly hesitant to implement bilateral peering sessions as a general rule, except with networks that are large enough that they've made the effort to implement good quality filtering at their ixp presence.
I'm not sure that bi-lateral sessions are necessarily any less secure than route server sessions, but mandating that peering happens over bi-lateral sessions means that the cloud & content folk will screen requests to peer for that very reason :-). Mark.