Transition to Cloud-Native and Distributed Edge Architectures in Service Provider Networks
Juniper Cloud-Native Solutions: Go beyond basic connectivity.
As network operators increasingly move towards becoming more cloud-native, all networking domains (transport, RAN and CORE) will be profoundly impacted. In this episode of the Get Connected podcast, Juniper’s Pavan Kurapati talks with host Chris Lewis about the various aspects of transitioning to cloud-native and how it’s accelerated by disaggregation and distributed architecture strategies from service providers.
Listen as they discuss what opportunities Juniper sees in the virtualization of the 5G SA Core Network, how Juniper fits into the new hyperscaler ecosystem, and how Juniper is bringing visibility that will allow all of the different flows to work correctly in the long run to create reliability for customers.
You’ll learn
The four key trends and high level transitions shaping the marketplace, according to Pavan
Kubernetes is going to be the de facto orchestration platform, whether for RAN or the CORE
The benefits Open-RAN brings to service providers as Juniper sees it
Who is this for?
Host
Guest speakers
Transcript
0:00 [Music]
0:03 get connected
0:06 you're listening to get connected
0:09 thanks for joining us
0:13 in this series we discuss the various
0:16 issues shaping your industry how the
0:18 changes in supplier ecosystems impact
0:20 the way you work on a daily basis how
0:23 your customers consume the services you
0:25 create and how the industry as a whole
0:27 steps up to the demands of the digital
0:29 marketplace let's get connected
0:36 hello listener let's get connected
0:41 my name is chris lewis
0:43 by day i'm an independent industry
0:45 analyst
0:46 by night as i'm sure you know by now i'm
0:49 a podcaster
0:53 welcome to get connected where we delve
0:56 into the issues shaping the networking
0:58 industry and the experiences we all
1:01 benefit from by being better connected
1:05 in this episode we're continuing the
1:06 journey into cloud the transition to
1:09 cloud native and the shift to this more
1:11 distributed architecture for the service
1:13 provider environment
1:15 i'm delighted to welcome pavan kurapati
1:18 chief architect sp global architecture
1:21 at juniper back to get connected welcome
1:24 back pavan and please remind us of your
1:26 background and your role within juniper
1:29 thank you chris this is uh indeed my
1:31 pleasure to talk to you again i am the
1:33 chief architect of global sp
1:35 architecture for juniper and in my role
1:38 me and my team are responsible for all
1:40 the emerging technologies that our
1:43 service provider customers are investing
1:45 in and we make sure we develop the
1:47 solutions that are more forward-looking
1:50 for the sp customers
1:51 so to start us off then we're talking
1:54 about this continued journey into the
1:56 cloud and the migration the move the
1:58 change in architectures what are the
2:00 high level transitions that you're
2:01 seeing that are shaping the marketplace
2:03 for you so the biggest trends in 5g is
2:06 the transition to virtualization and
2:08 cloud native network functions let me
2:11 start with the ran virtualizing of ran
2:13 and running on general purpose hardware
2:16 instead of the appliances that are more
2:18 standard until 5g came so that's the
2:21 biggest trend i'm seeing in the ran you
2:23 know virtualizing of ran is going to
2:25 take place irrespective of whether you
2:27 talk about the orion ecosystem or not
2:30 desegregation through open ran ecosystem
2:33 is again taking off i was in barcelona
2:36 you know mobile world congress where
2:37 everybody is talking about how
2:39 virtualization of ran is going to save a
2:42 ton of cost for service providers
2:44 the sa core the standalone core in 5g
2:47 that's designed to be fully cloud native
2:50 and based on the cloud native principles
2:52 along with the services-based
2:54 architecture so that's going to change
2:56 how 5g is deployed kubernetes we were
2:59 talking about a lot of cloud native
3:01 principles here so kubernetes is going
3:04 to be the de facto orchestration
3:06 platform whether it is for the ran or
3:08 for the core
3:09 and in order to deploy all these things
3:12 before 5g
3:14 most of the mobility traffic used to be
3:16 backhaul to a centralized data center
3:19 where you would bring all the traffic to
3:20 a central location and from there you
3:22 would serve but that is changing quite a
3:25 bit now so telco cloud is transitioning
3:28 from centralized to distributed edge
3:30 architecture to be able to host these
3:32 cloud native network functions that i
3:34 just talked about the ran and the core
3:37 so i think in my opinion virtualization
3:40 of ran the 5g standalone core kubernetes
3:43 becoming a de facto orchestration
3:45 platform and
3:46 moving from centralized to distributed
3:48 edge architecture these are the key
3:50 trends that we are tracking and working
3:52 actively on i totally agree and the fact
3:54 is that we're talking about this more
3:56 distributed architecture where we're
3:58 moving the resources to where it's
4:00 required to actually execute right you
4:02 mentioned rand virtualization
4:04 specifically in there at the cell site
4:07 you know juniper is known for its work
4:09 around the transport as you said and the
4:11 traditional routing that we've seen in
4:12 place how are you seeing the cloud
4:15 native
4:16 developing and how is run virtualization
4:18 impacting that
4:20 that's a great question chris so
4:22 the ran as i said is getting virtualized
4:25 and especially with iran desegregation
4:28 there are cases where you run the dus at
4:30 the cell site itself and if it's a
4:32 virtualized u it runs on a general
4:34 purpose x86 based server
4:37 so we do have physical sell side routers
4:40 juniper provides these physical sell
4:42 side routers for front hall and mid-hall
4:44 connectivity and two main important
4:47 aspects of sell side routers are timing
4:49 and synchronization especially
4:51 classy timing and hardened cell side
4:54 routers as well as the routing stack
4:56 required
4:57 to support the network slicing
4:58 capabilities
5:00 now for some distributed ran
5:01 architectures especially where you know
5:04 you only require sub 25 gig or sub 50
5:07 gig mid hall capacity this is where
5:10 things become lot more interesting
5:12 because here you might save operational
5:15 expenses if you eliminate an additional
5:17 physical device at the sell side and
5:20 that's where juniper is working on what
5:22 we call as a cloud native router
5:24 the idea here is to take best of both
5:27 worlds which is junos routing that runs
5:30 on all our routers
5:32 we take that and we containerize that
5:34 which is our containerized routing stack
5:36 as a control plane and then we take our
5:39 contrail dpdk forwarding plane and
5:41 deploy it as two different parts which
5:44 forms the brain of junos and the
5:47 forwarding plane of contrail and that's
5:49 integrated with the kubernetes cni
5:51 framework that i talked about before so
5:55 that cloud native router is where we
5:57 think the dram deployments with the sub
6:01 50gb hall will go and it's so
6:04 interesting because we're bringing so
6:05 many things into into the mix here so
6:07 cloud native routing does sound very
6:09 interesting at the sale side but what
6:11 kind of integration are you looking for
6:13 and expecting from the ran and the
6:14 hardware vendors oh great question again
6:17 very minimal integration from the rand
6:19 vendors in fact the networking for the
6:22 ran especially when you're looking at
6:24 the du and let's say you require three
6:27 slices one say going to vpn green
6:31 another to blue another to red going to
6:33 three different locations
6:35 typically you would tend to put all that
6:37 information in kubernetes manifest and
6:40 we automatically translate that into
6:42 junos construct without you doing
6:45 anything as a rand vendor you don't have
6:47 to do any additional configurations for
6:50 example to make that happen
6:52 from hardware again we understand that
6:54 this is a resource constrained
6:56 environment we are talking about having
6:58 very less cores for routing
7:01 and we do understand that and we operate
7:03 in a very limited core budget so for
7:05 example today we only need about two
7:07 cores to run our entire routing stack
7:10 and still be able to provide the
7:12 required mid hall capacity
7:14 in addition to that we are also
7:15 exploring the offloads for example on uh
7:18 offloading the entire data plane on
7:20 fpgas as well as on the smart mix
7:23 what i always like about this
7:24 development in the industry is that
7:26 nobody can do everything but the skills
7:29 being brought to the table by everybody
7:31 really complement each other it's a
7:33 convergence of of it of transport of
7:36 networking of all of these things but i
7:38 think what really comes to mind when we
7:40 talk about this is that the scale of
7:41 these virtual elements is going to be
7:43 absolutely enormous
7:45 how are you going to automate the
7:46 install and the provisioning of all of
7:48 these pieces oh you are absolutely right
7:51 as we talked about before we are talking
7:53 about tens of thousands of cell sites
7:55 that will require this kind of
7:58 features and functionality so yes the
8:00 scale is enormous so again the key idea
8:04 here is to follow kubernetes best
8:06 practices because kubernetes has
8:08 built-in aspects that will take care of
8:10 the life cycle management just to give
8:12 you some examples so we provide helm
8:15 charts that will define and you know
8:17 install
8:18 all the routing stack the parts that are
8:20 required so we use helm charts it's
8:22 literally just a one line that will
8:24 bring up the entire parts in terms of
8:27 provisioning i talked to you about that
8:29 before we can take
8:31 the networking constructs from the
8:33 kubernetes manifest and we automatically
8:35 translate that terraform is very popular
8:38 these days junos supports terraform
8:41 providers so you can actually come in
8:43 and provision things using terraform in
8:46 addition to that it is a regular junos
8:49 it's just in a cloud native form so we
8:51 support all the interfaces that are
8:53 exposed in junos for example
8:55 either netconf and you can come through
8:58 psap you can talk bgp you can use our
9:01 rpd apis you can use exactly the same
9:04 way that you would use any other juniper
9:06 device so that's really the key for us
9:09 automation is very very important at
9:12 this scale and we are doing everything
9:14 to utilize kubernetes ecosystem you're
9:17 talking tens of thousands potentially
9:19 even more than that the densification of
9:21 the network has been moving to the 5g
9:23 world and farther on into the 6g world
9:25 means that we're going to get denser and
9:26 denser and denser so forward-looking we
9:28 really have to nail this in terms of
9:30 making sure we can automate and deliver
9:32 it right right exactly absolutely so
9:34 that looks to be from a desegregation
9:36 perspective a great story in the
9:38 transport
9:39 but talking about disaggregation more
9:41 generally and especially in the ran
9:43 how do you see the open ran and how does
9:45 juniper see the open run environment and
9:47 the benefits it brings to the service
9:49 providers right as i said i was in
9:51 mobile world congress and i could hear a
9:54 lot of people being very positive about
9:57 oran
9:58 taking off especially the open
10:00 interfaces that are essential
10:02 for the oren ecosystem right so
10:04 disaggregation
10:05 traditionally when you talk about tran
10:07 it's vertically integrated into an
10:09 appliance
10:10 now the disaggregation allows you to
10:13 divide it into multiple components and
10:15 you can mix and match right you can mix
10:17 and match the ru's du's and cu's with
10:20 multiple vendor ecosystem so that's
10:22 really really healthy for the service
10:25 provider networks
10:26 one of the key aspects we are also
10:28 noticing is you know the decoupling of
10:30 ran intelligence and removing some part
10:33 of the intelligence away from the
10:35 traditional appliance and deploying it
10:37 as applications like use aiml to get the
10:41 data from the ran and deploy it as an
10:43 application ecosystem so we see that
10:46 rick which is the ran intelligence
10:48 controller
10:49 that provides a thriving application
10:51 ecosystem in the form of x apps and r
10:53 apps in the marketplace so all the
10:56 intelligence is going to be i think in
10:58 the applications we're talking about
11:01 spectrum utilization efficiencies for
11:04 example like 30 to 40 percent of savings
11:06 in spectrum utilization sustainability
11:09 as an aspect sla management and so many
11:12 applications that can be developed in
11:15 this environment especially in the rand
11:17 desegregation so we
11:19 do believe oran especially in the ric
11:21 and the application ecosystem
11:23 that
11:24 is provided through the oran approach is
11:27 going to be
11:28 crucial for 5g deployments
11:31 that supply ecosystem is so important
11:33 but speaking specifically about rick
11:35 which is getting such a lot of attention
11:36 at the moment how do you see that being
11:38 deployed we are designing rick to be
11:41 cloud native from day one the platform
11:43 itself is being built on cloud native
11:45 principles so what it means is rick can
11:47 run on service provider private cloud
11:50 platform that is there in their on-prem
11:53 or if they're using a hyperscaler
11:55 platform in their premises the rick can
11:57 run on that platform as well that
12:00 flexibility of where the ran is running
12:02 obviously fits in with what we're seeing
12:04 in the server provider community where
12:06 they're looking at all sorts of
12:07 different implementations their own
12:09 environments as you said or indeed in
12:10 the hyperscaler world
12:12 now we've talked a lot about ram
12:15 in mobile networks the epc in the 4g
12:18 world is where virtualization really
12:20 started
12:21 the 5g standalone core is cloud and
12:23 microservices based what opportunities
12:26 does juniper see in the virtualization
12:28 of the 5g sa core great question chris
12:31 so 5g core vendors as i talked to you
12:33 about
12:34 5g core previously it is designed to be
12:37 services based and you will require an
12:40 orchestration platform to host these
12:42 network functions and typically 5g core
12:44 vendors try to sell their own vertically
12:46 integrated platforms to host their core
12:49 applications claiming that you will get
12:51 better performance of their core running
12:54 on their platform but i think we are
12:56 seeing operators looking at this as an
12:59 opportunity to disaggregate and
13:01 build a horizontal cloud platform where
13:04 they can run these 5g core network
13:07 functions to avoid the vendor lock-in
13:09 and this is where we see a big
13:11 opportunity for contrail so today
13:15 we have
13:16 5g core even the 4g virtualized core
13:19 running on contrail based horizontal
13:21 cloud platforms where contrail provides
13:24 the overlay networking initially we did
13:27 all this work with openstack but now we
13:29 are seeing this migrate to kubernetes
13:31 based ecosystem so from our point of
13:34 view we think contrail networking
13:37 provides huge differentiation especially
13:40 with respect to providing advanced
13:42 networking features such as you know bgp
13:44 as a service advanced security
13:47 especially in the multi-tenant and the
13:49 name space network isolation and other
13:51 aspects the multi-cluster networking
13:54 which is very important in the 5g
13:56 standalone code deployment so all of
13:58 these are key differentiators from
14:01 networking point of view when you are
14:02 talking about building these horizontal
14:04 platforms and that's where we think
14:06 contrail networking is evolving into
14:09 more cloud native
14:10 form we call it cloud native control
14:12 networking or cn2 or cn square
14:15 the other aspect which is also very
14:17 important is the underlay networking
14:20 where you have leaf and spine you need
14:22 to provision and configure but more
14:24 importantly it need to integrate well
14:27 with the orchestration platforms that
14:29 you are using
14:30 for the standalone core and here is
14:32 where we think our intent based fabric
14:35 management which is abstract that
14:37 juniper acquired plays a very important
14:40 role
14:40 and we have been helping various
14:42 operators with the appstra as well as
14:45 contrail based horizontal cloud
14:48 platforms
14:49 to be able to host these 5g cloud native
14:51 applications especially in the
14:53 standalone core what is fascinating here
14:55 is as you quietly write pointed out the
14:57 underlay and the overlay building these
14:58 things together and you brought those
15:00 into juniper to help in the in your
15:02 delivery but what we're also seeing is
15:05 announcements about some of the telcos
15:06 working with the hyperscalers to move
15:08 workloads such as 5g core into those
15:11 hyperscale environments so we've seen it
15:13 with dish with aws and we've seen it
15:14 with att with azure how do you see
15:18 juniper fitting into this this
15:20 hyperscaler ecosystem
15:22 again another great question we do see
15:24 these strengths as you said moving into
15:27 hyperscalers especially running these
15:29 virtualized network functions in the 5g
15:32 space whether it is ran or core requires
15:35 you to invest in the infrastructure and
15:37 the platform so one of the aspects that
15:39 some operators feel
15:41 is easier to do is simply run it in the
15:43 hyperscaler environment right where
15:46 hyperscalers would provide the required
15:48 infrastructure and platform and you can
15:50 just take care of the network functions
15:52 or the applications here whether it is
15:54 the core or the ran
15:56 i think some of the challenges that we
15:58 are seeing is
16:00 it's not just about having the 5g core
16:02 running in a hyperscaler environment
16:04 things just come up but it's about
16:07 connecting these 5g core network
16:09 functions or interconnecting them
16:12 that's where there are a lot of
16:14 challenges because the networking
16:16 requirements for example to host the
16:18 standalone core you will need network
16:20 segmentation you will need to extend
16:23 your current vpns in your on-prem data
16:26 centers into the hyperscaler data
16:28 centers so terminating those overlay
16:32 tunnels as well as to be able to provide
16:34 network segmentation these are
16:36 challenges that you will find in all
16:38 three hyperscalers to be honest and
16:40 that's where we come into picture we are
16:43 very actively working with all the three
16:45 hyperscalers to address these networking
16:48 requirements i talked about juniper
16:50 cloud native router in the oran space
16:53 before it's actually the same cloud
16:56 native router that we are
16:58 working with the hyperscalers to be able
17:00 to deploy in an auto scale cluster which
17:04 will provide these network segmentation
17:06 capabilities
17:07 and be able to
17:09 interconnect these vpcs that are hosting
17:13 the 5g core elements so in a nutshell we
17:16 think that is an opportunity for us
17:19 where if the service providers are
17:21 looking at hyperscalers to host these
17:23 network functions we come in and help
17:25 them in connectivity and automate all
17:28 the connectivity aspects whether it is
17:31 between their edge cloud and public
17:33 cloud or between the vpcs within the
17:35 public cloud
17:36 and it's fascinating isn't it it's these
17:38 little elements in between so it's
17:40 working with the hyperscalers so it's
17:42 not one part of the ecosystem imposing a
17:44 way of working on the other is the
17:46 visibility that you're bringing to the
17:47 table which will allow all of these
17:49 different flows to work correctly in the
17:51 long run absolutely absolutely yeah and
17:54 we've talked primarily here about the
17:56 wireless environment because of course
17:57 5g gets a lot of that attention from the
17:59 marketplace but what about the y line
18:02 side do you see similar trends on the
18:04 wireline side of the the argument oh
18:06 yeah i mean the desegregation that is
18:08 true even in the wireline world take an
18:10 example of bng we are talking about cups
18:14 which is the control and user plane
18:15 separation that's already happening so
18:18 the bng control plane is already
18:20 separated and it can be run as micro
18:23 services in any cloud platform so today
18:27 we have our bng control plane which is
18:29 completely micro services based it can
18:32 run on on-prem cloud um if you are using
18:35 any on-prem hyperscaler infrastructure
18:38 like aws wavelength for example we can
18:41 run the bngc even on hyperscaler
18:44 infrastructure the key is you need to
18:46 design it right follow the kubernetes
18:48 based ecosystem and the same principles
18:51 apply to wire line world as well
18:53 it's great to hear because i think all
18:54 too often we don't think about the fact
18:56 that as consumers we take wi-line
18:58 services we take wireless services we
19:00 want that quality of service to be
19:02 delivered throughout and what is
19:04 becoming increasingly evident is that we
19:06 need the different players in the
19:07 ecosystem so people like yourselves
19:09 people like the hype scalers and of
19:10 course the service providers themselves
19:12 to be working much more closely together
19:14 to have that management to make sure
19:16 that reliability gets delivered through
19:18 to all of us as users
19:20 pavan
19:21 fantastic to have you with us again
19:22 thank you so much for having joined us
19:24 on get connected it was great talking to
19:27 you chris uh thank you so much for
19:28 having me
19:30 so there you have it listener we
19:32 continue this journey into cloud we
19:34 continue bringing together the elements
19:36 of the cloud environment the service
19:38 providers and the ecosystem of suppliers
19:41 to be able to work with everybody to
19:43 deliver the quality of service that
19:45 underpins the future of the digital
19:47 marketplace
19:48 not only is it required in the wireless
19:50 world it's required in the fixed world
19:51 as well we bring together the benefits
19:53 of having this continuous integration
19:56 the continuous management of all of the
19:57 services we're beginning to build that
19:59 momentum as cloud brings all of these
20:01 capabilities to give the scale that we
20:04 need to support all of those services in
20:06 the future
20:09 thank you for joining us on get
20:10 connected thank you to pavan thank you
20:13 to juniper and thank you too for
20:15 listening
20:18 you've been listening to get connected
20:21 you've heard from us now we'd love to
20:23 hear from you
20:24 tell us what you think via twitter using
20:27 the handle at juniper networks
20:30 and if you like what you've heard
20:31 remember to tell your colleagues and
20:33 friends
20:34 thanks for listening to get connected