Adapting to new layer 3 peers

[kmorin18]

More and more IXP peers like Google VPP desire to have a single L3 interface for peering.
This is a growing trend that now impacts ALL IXPs.
If an IXP wants to remain relevant, either for Google VPP or host cache servers like Valve, Apple or others, they need to setup something like this, especially if they are not in a major metro with 50+ ASNs that can keep the IXP sustainable.

This brings significant complexity to small IXPs since they need to operate a full L3 router with auto generated IRRDB prefix filters and more.

The most efficient way to do this is to connect said L3 router to the IXP LAN and have it peer on the exchange. However, managing 1 on 1 BGP sessions is not scalable. The next logical step is to have said L3 router peer on the Route Servers. That way the L3 router can benefit from the already existing IRRDB, prefix count and RPKI filtering.

That brings another problem: not all peers may want to send/recieve said routes:

• Maybe said peer already has an PNI with Google
• Maybe they don't want the extra AS hop
• Many other reasons. Recieving something through the RS without having it clearly labeled in the portal that the RS will be sending you routes for said ASN could be problematic, especially for already established IXPs adding this feature.

Manually controlling these routes adds some burden:

• The IXP manually communicate with all peers regarding the presence of said caching servers
• The IXP must tag the routes with 0:rs-asn to avoid sending the routes by default
• The IXP must then tag the routes with rs-asn:peer-as when a peer wants to recieve said routes
• The peer must tag the routes with XYZ:XYZ so that the L3 router sends their routes to the service of their choice (Google, Caching server, etc)

This complexity adds work, slows services/caching adoption, etc

Here is the proposed solution:

• Under Member information, add a "Services Member" section.
  This would be maintained by the IXP since those Services Members aren't actually on the IXP. They are maintained by the IXP.
  Said profile would have a space for a logo and information regarding behind what ASN on the IXP these services are hosted.

• For each Services Member, peers could enable peering with said Services Member just like the "RS client" and "AS112 Client" knobs.
  In the best of worlds peers could enable these knobs themselves, unlike the current knobs mentionned above.

There are 2 ways this could he handled

• Option 1 is to enable a session between the peer and a dedicated set of RS for said service. Those RS would have a special template where the RS would only share routes between the peer and the L3 Services ASN, not between peer like the standard RS template.
  This is probably easier to code, but more work to maintain (extra RS pair)

• Option 2 (preferred in my mind) would be to add some special functions to the standard RS template
  By default, the RS would not redistribute routes to peers that are coming from the L3 Services ASN.
  For each L3 services knob, we configure a BGP community (ex: xyz:15169 for google)
  When a peer enables this knob, the RS would start redistributing routes that have said communities to the peer.
  On the flip side, the RS would tag that peer's incoming routes with another tag, that the IXP could use in their L3 router configuration to send to the desired service.
  That way, a single L3 services router could host multiple different caching services or L3 routes and the peer can select which ones they want.

In the end, all of this:

• Removes the need for the peer and the IXP to manage BGP communities manually
• Visually promotes the availability of said services

If the technical complexity of the proposed solutions is too big, at least having a visual, dedicated section that clearly shows peers the availability of said L3 services would be super practical. Adding Google AS15169 in the list of peers although they are not directly connected to the IXP would be missleading.

I would love to help with the development of this, I simply do not have the coding skills to do so.

[kmorin18]

For added background, this is not a hypothetical, but a real scenario. We've connected AS25870 to CANIX Toronto's RS

Being a brand new IXP, we've been able to put in place a community peers can use to stop AS25870 from sending their routes to AS15169. Peers can also filter out those routes or contact the NOC to have them stop advertising said routes to their ASN via the RS. But again, manual work and not super scalable.

However, for an established IXP like CANIX Montreal, we simply cannot come in and start pushing Google routes to everyone that's on the RS, we may create unplanned traffic shifts or even congestion if there is more traffic than planned. A feature like this would solve that.