Voltar 
In previous blogs on the Netskope NewEdge network, we’ve discussed concepts including Secure Access Service Edge (SASE) architecture and why counting data centers alone is meaningless when trying to understand cloud service coverage. Now that we’ve laid the foundation it seems like a good time to get into what’s needed in terms of architecting the actual network and the connections required. When you navigate this territory, it is common for topics like peering relationships or transit provider selection to come up. For the uninitiated, a quick simplified primer: A transit provider sells you access to any IP destination on the internet, whereas peering only enables two networks to exchange traffic destined for each other. Peering is like two buildings installing a skyway to get from one to the other without having to use the street. It doesn’t give you access to any building in the world, just the one.
For the sake of this blog, I’d like to simplify this by referring to peering and transit collectively as “interconnects,” and the regional selection of transit providers and peering relationships as “interconnection strategy.”
In advance of writing this blog, I noodled with different analogies to use for conveying why interconnection strategy matters. The simplest one I could come up with is a comparison to air travel–which even with the current COVID-19 shutdowns in many parts of the world and our general reluctance to travel nowadays–is an activity many of us can still remember and relate to. Without the Netskope NewEdge network and relying 100% on the public in