Has virtualization become obsolete in 5G?

Wed Aug 5 14:15:02 UTC 2020

I was actually talking about routing on the host and virtual control-plane and virtualized data-plane.

Currently we either have a VM combining both or a separate VM for each. Alternatively we can have a container for the control-plane.

I was wondering if the idea behind containerization is to do virtual data-plane as a container as well.

In terms of containerization on vendor HW or opening up data-plane, seems like XR7 from Cisco is leading the way:

- System runs in containers on RE and Line-cards, allows one to run 3rd party containers, 

- Allows one to run 3rd party routing protocols to program RIB

- Allows one to program FIB via Open Forwarding Abstraction (OFA) APIs

- And XR itself can run on selected 3rd party HW. 

That pretty much covers all the avenues we as operators are interested in, of course it’s not all just roses and unicorns and there will be further development and streamlining necessary. 

adam

From: NANOG <nanog-bounces+adamv0025=netconsultings.com at nanog.org> On Behalf Of Mark Tinka
Sent: Wednesday, August 5, 2020 1:05 PM
To: nanog at nanog.org
Subject: Re: Has virtualization become obsolete in 5G?

On 4/Aug/20 17:38, adamv0025 at netconsultings.com <mailto:adamv0025 at netconsultings.com>  wrote:

Wondering whether the industry will consider containerised data-plane in addition to control-plane (like cRDP). 

Having just control-plane and then hacking to kernel for doing the data-plane bit is …well not as straight forward as having a dedicated data-plane VM or potentially container. 

Well, there has been some discussion in the past 2 years about whether vendors can open up some of their data planes and allow those with enough energy and clue (that means not me, hehe) to have their take on what they can do with the chips in some kind of form factor, even without their OS.

Outside of that, merchant silicon is the next step, before we try to hack it on general-purpose CPU's, as we've been doing for some time.

Mark. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200805/cbb175e0/attachment.html>