Bi-Lateral benefit is for when there is an issue with the route servers. Example, Equinix IBX Chicago changed filtering policies shortly after ARIN introduced the new IRR database. If your BGP peered customers had not created new entries in the new IRR database their routes were dropped. This dumped a lot of IX traffic for us other than the few bi-laterals we had established. We called all our BGP peered customers that day and they quickly were able to update their entries in the new IRR database. This wasn't a catastrophic event, but you do need to know that things could go wrong with an IX's route servers. Thank you, Kevin McCormick -----Original Message----- From: NANOG <nanog-bounces+kmccormick=mdtc.net@nanog.org> On Behalf Of Mark Tinka Sent: Friday, November 15, 2024 7:52 PM To: Nick Hilliard <nick@foobar.org> Cc: North American Network Operators' Group <nanog@nanog.org> Subject: Re: Can an IXP sell IP transit? CAUTION: This email originated from outside your organization. Exercise caution when opening attachments or clicking links, especially from unknown senders. 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.