Someone left a “killer” comment¹ after reading the Should We Use LISP blog post. It start with…

I must sadly say that your view on what VPN is all about is pretty rusty and archaic :( Sorry! Modern VPNs are all pub-sub based and are already turning into NaaS.

Nothing new there. I’ve been called old-school guru from an ivory tower when claiming TRILL is the wrong direction and we should use good old layer-3-based design², but let’s unpack the “pub-sub” bit.

According to Wikipedia, “publish–subscribe is a messaging pattern where senders of messages, called publishers, do not program the messages to be sent directly to specific receivers, called subscribers, but instead categorize published messages into classes without knowledge of which subscribers, if any, there may be”. The author of that comment somehow failed to realize that’s a perfect description of an L3VPN or EVPN design using BGP route reflectors and RT-based Outbound Route Filters. I already mentioned that in the LISP blog post, but it’s obviously too much of a nuisance to read the whole article before writing a dismissive comment.

As for network-as-a-service, I’m old enough to remember industry pundits telling us how networking is dead because every endpoint will use mobile networks with LTE VPNs. More than a decade later, we’re still slogging through the networking morass even though it should be easier to build networks with no wires. Also, according to the pundits, routing is dead because we have SD-WAN, and BGP and MPLS are obsolete. What’s funny is that people having these opinions couldn’t publish them without BGP and (oftentimes) MPLS doing their job in the background.

But wait, it gets better:

VPN overlays starts at the end points compute or mobile device and seamlessly and dynamically interconnects endpoints.

Time to go back to taxonomy. There are endpoint VPNs that the author of this comment is so excited about, and infrastructure VPNs implemented in routers³, firewalls, or dedicated encryption boxes… All of them could be implemented as an overlay on top of another network⁴, and all of them need some sort of control plane or orchestration system.

From the VPN traffic flow perspective, we have hub-and-spoke VPNs where all devices communicate through a set of central servers and peer-to-peer VPNs where the VPN devices can communicate directly. Traditional IPsec endpoint VPNs with VPN concentrators are a perfect example of hub-and-spoke VPN. Interestingly, BGP/MPLS L3VPN⁵ was one of the first peer-to-peer VPNs.

It’s also worth pointing out that endpoint peer-to-peer VPNs are nothing new. My kids were playing Minecraft using Hamachi (released in 2004) a decade ago, and I’m positive Hamachi was not the first peer-to-peer VPN⁶.

Finally, there are customer-operated VPNs (DMVPN, SD-WAN…) and provider-operated VPNs (Carrier Ethernet, VPLS, BGP/MPLS L3VPN…). We even build VPNs within data centers to implement virtual networks (VXLAN/EVPN, Cisco ACI, VMware NSX, all public cloud infrastructure).

There are great use cases for any technology or product I mentioned above, and saying “one of them sucks, you should only use the other one” makes as much sense as saying “Python and C/C++ are dead, you should use Swift or TypeScript”. There’s a slight difference between a fanboy and an engineer – an engineer considers the requirements and selects the optimal set of technologies that meet the requirements with minimum complexity.

We’re not done yet. Next comes a jab at the service providers:

Examples of VPNs are not EVPN or L3VPNs – those are SP customer locking tools.

L3VPN is a lock-in tool if you’re gullible enough to believe marketing slides and outsource your core routing to a third party. Numerous CxOs are in that category to the delights of various service providers. Smart customers use L2VPN and build their own networks on top of that, or use L3VPN as pure IP transport and build their own overlay on top of that transport (see also: SD-WAN).

EVPN is usually used to implement L2VPN (aka Carrier Ethernet) and if you manage to get locked into a single Carrier Ethernet… I’ll stop right there.

For a more thorough overview of VPN technologies, their applicability, and associated gotchas (including lock-in considerations) watch the Choose the Optimal VPN Service webinar.

Now for the final bit of that wonderful comment:

Real VPNs of current times are ZeroTier, TailScale etc.., LISP falls into the same modern camp.

ZeroTier and TailScale excel as endpoint VPNs, although both of them support gateway (relay) nodes⁷. If I had to implement an endpoint VPN these days, I would definitely consider them before thinking about IPsec clients and concentrators.

LISP is a totally different story. While there are endpoint LISP implementations, the only products pushing LISP (that I’m aware of) use it to implement infrastructure VPNs. Furthermore, based on the comments I got to recent blog posts, it looks like LISP refocused from cache-based forwarding towards a control plane that’s functionally equivalent to EVPN or L3VPN control plane.

To round up the VPN confusion: there are endpoint EVPN implementations (we discussed them in December 2021 Design Clinic), so what’s the difference between real VPNs and SP customer locking tools⁸? It’s obviously not the technology, but the way it’s used.