Repost: State of Lisp Implementations (2024)
You might remember Béla Várkonyi’s use of LISP to build resilient ground-to-airplane networks from last week’s repost. It seems he’s not exactly happy with the current level of LISP support, at least based on what he wrote as a response to Jeff McLaughlin’s claim that “I can tell you that our support for EVPN does not, in any way, indicate the retirement of LISP for SD-Access.”:
Nice to hear the Cisco intends to support LISP. However, it is removed from IOS XR already. So it is not that clear…
If Cisco will stop supporting LISP, then we will be forced to create our own LISP routers, since we need it for extreme mobility environments.
It would be still beneficial to have a second LISP router supplier. Unfortunately, the early LISP implementers stopped all development many years ago, so they are useless as alternative suppliers, since PUBSUB is not provided and some other features are also missing. ONOS and ODL implementations are also orphaned and useless.
In safety critical networks, we always need diversity in suppliers, too. However, now we are forced to work on technology diversity, so we have to find a way to make PMIPv6 to work reasonably well. It will be a challenging task.
We will have to present a combined mobility network with parallel LISP and PMIPv6 mobility backbones, where the end user would not see any functional limitations in multi-link mobility.
Béla is experiencing a common problem when trying to use a niche technology for a niche use case. You might be the only one doing it, so no vendor is interested in supporting you. After all, vendors have to justify R&D investments and will throw money at whatever is selling best, dropping technologies with insignificant adoption like hot potatoes (remember Cisco IOS Performance Routing?).
The only way to survive in this ridiculous world is to keep your network design as simple as possible and solve interesting challenges at the network edge using software you can control.
I think Cisco might have published configuration guides for BGP EVPN on the Cat 9K platforms before any LISP guides. Both control planes are supported, but it was originally the case that choosing LISP meant a DNA and ISE lock in. Other vendors seem to be choosing BGP EVPN for network virtualisation, so will choosing LISP still mean a form of vendor lock in?
From my personal perspective, Cisco launched the campus switches with the LISP control plane only, created tons of whitepapers "proving" LISP is better than EVPN, and probably implemented EVPN control plane only after a large-enough customer complained loudly enough (or threatened to look at alternatives).
You can go through my older LISP blog posts (OK, rants) and the comments to get a bit more history.
As for viability of LISP, as you can see from Bela's comment, they have a really hard time finding a LISP implementation, and might have to build their own routers. AFAIK, no other major vendor implemented LISP in production gear, and (again, according to Bela) even Cisco is dropping it from some products.
Interesting to hear there is a lack of LISP suport from other vendors. From my point of view SDA was the vehicle for wider LISP adoption. However, it would appear SDA has not been widely adopted. Cisco's DNA centre has also been going through a re-branding, and is now known as the Catalyst Centre, removing empasis on it original role. This seems to have happened around the same time that BGP EVPN support crept into IOS-XE. Despite Jeffs comment, these things do raise questions regarding future plans for LISP and the SDA solution.