Cloud Outages and the Flattening of the Internet

router errors within the NaaS are simply not possible. All POP routers are just forwarding stateless routes without routing, encryptions, VRF, etc. At the same time, they all understand how to route traffic to the cloud provider’s next hops. The customer just needs to send traffic to the cloud provider network, while pointing it to the stateless core of the NaaS provider. 

NaaS provider will only advertise a route to the next hop of the cloud provider it directly connects with. Now the underlay of the NaaS provider only sends the next hops it connects with, while the source and destination routes are only known to the customer and cloud provider. I learned this during my SDWAN days for business class internet. Unless we involve underlay through SDN principles, we will never provide service guarantees.

Referencing figure 4 below, the peering between the enterprise and the provider is at the off-path control layer. This peering will exchange routes and all the related security keys. For example, the cloud ASN 64512 will advertise 172.31.0.0/16 to the customer, and the customer will advertise the route of 10.16.1.0/24 to the cloud provider.

This is where the NaaS concepts become interesting. For the prefix 172.31.0.0/24, the next hop is the link between the NaaS provider and the customer. The customer builds an overlay to the closest POP of the NaaS provider, so the next hop for 172.31.0.0 would be 192.1681.1. The tunnel is built to the POP, and at the POP, the packet is routed to the exit of the cloud provider.

Traffic from the enterprise reaches the NaaS over the internet. The NaaS will provide details and visibility about how traffic traverses the NaaS network. The enterprise tells the NaaS to route traffic to the closest exit to the provider.

Now what we can do inside the NaaS provider is, instead of running hop-by-hop routing, we can use SDN tactics along with segment routing. Once the traffic enters the NaaS provider, a label stack is put in the header, and it routes the traffic to the peering interface of the NaaS and cloud provider. The traffic will use the prefix and adjacency labels until it reaches the exit interface. This helps eliminate transit issues even within the NaaS provider. Also, the NaaS provider only offers connectivity to the services it can directly connect to.

We can eliminate a lot of convergence, scale, and even security issues by deploying stateless networks within the NaaS and in the future with any transit providers. SDN came to solve networking issues, and it was about more than just network automation and configuration monitoring.

The practice of providers getting their users into their networks earlier and keeping them there for more of the journey is called “flattening the internet.”

Before we go into how the internet is flattening, we can flatten it further through state abstraction using SDN concepts.

In the past decade, we have seen the growth of FAANG (Facebook, Amazon, Apple, Netflix, Google), and now we should call them MAANA (Meta, Amazon, Apple, Netflix, Alphabet). These companies want to get traffic to their network as quickly as possible, and keep it in their networks. Similarly, the cloud providers have done the same.

Why? After all, large service providers want to get the traffic out of their network as quickly as possible to preserve capacity. Why would FAANG (and the larger cloud companies) be so interested in getting their users into their networks more quickly and keeping them there? The answer is that’s the only way they can improve reliability. There is a growing consensus that reliability isn’t likely in our digital wilderness of the public internet.