Cisco’s Take on 5G Packet Architectures

The Important

  • Is hard-slicing too complex?
  • IP/MPLS, SR MPLS or SRv6?
  • Should SPs be building converged infrastructure for all wireline and wireless services?
  • Packet/optical convergence and pluggables – how fast, how soon?
  • When will end-to-end automation be a reality?


In Telco networking, 5G is the biggest driver of change that most in the industry point too. For Router suppliers, the big capacity demands may be a couple of years into the future, but the conversation on network design and technology is well underway, as is some of the infrastructure investment, and certainly a multitude of explorations.

Two important conversations are the underlay design and automation. Cisco has recently given webinars on both. The former was clear without that many surprises. The latter remains a little challenging. Not so much because of anything Cisco has or has not done, but because of the complexity of multidomain, multivendor (and perhaps even multilayer) automation, especially in the context of an ecosystem that has historically been reasonably closed / tightly integrated by one supplier, and unclear commitments from all actors, on open approaches, like O-RAN.

“We’re already active. But for the high performance applications, today we do not see O-RAN as a way to speed up the rollout. It’s rather a way to slow down right now. When O-RAN is ready, we’re gonna be there”. Ericsson’s CEO Borje Eckholm, JULY 20, 2020, rcrwireless, “Ericsson CEO: Europe is behind on 5G and O-RAN won’t speed anything up”.

Numerous aspects of 5G facilitate that old industry saying that it is the even number generations that are the big successful step-function changes, and not the odd ones. Is the industry aligned on the best approach to low-latency slicing? When will multiple competitive suppliers be ready to fully support SRv6? Will operators take the plunge into fully converged packet/optical transport architectures? When will multivendor automation be a reliable reality? Are operators ready to invest in millimeter radio technology ubiquitously? The answers to these and other questions are the difference between whether 5G is just a trial ground for future directions, or itself, a step-function step forward. This article examines some of these questions in the context of the material presented by Cisco in their webinars.

Is Hard Slicing Too Complex?

Cisco is exploring support for Flex-E / on their products but are clear that they believe end to end segment routing is a better approach. This position is complementary to their view that network operators should have a converged router network for all services: business, residential, and mobility – more on that later.

Flex-E / are specifications for creating logical channels out of multiple links. These specifications have been most associated with mobility/fronthaul networks, but there is also discussion about wireline service applications. Broadcom chips are used by all major suppliers for mobility access routers. Different suppliers have products based on different chips, but if a supplier wants a chip that supports Flex-E / G.Mtn, then all they have to do is work with Broadcom on the right chip (and of course do the software work). Some suppliers have already announced that they will have hardware platforms available this year that support Flex-E / G.Mtn.

There are a number of sub issues wrapped up in the question “is hard slicing too complex?”. For some operators, hard slicing feels like a bit of a step backwards, after moving to a carrier Ethernet architectures for 4G. Having operationalized a packet approach, do they now want to go back to fixed channel allocations of the type provided with hard slicing. Then there is the question of whether there are significant drivers for ultra low latency. Against these pushbacks are the reality that a) telcos are conservative, b) multiple generations of mobility need support, c) and last but not least, there are multiple approaches to front-haul, and an already complex implementation including eCPRI, CPRI, TSN, RoE, and all the packet tech.

For my part, 4G, and other service networks, demonstrated that a packet network can provide both low latency and deterministic latency (especially if both directions of communication follow the same path). When I think about the complexity of an end to end 5G network, operators should be looking to simplify wherever possible. Given that, drivers for hard slicing need to be compelling, especially as the industry will most likely start with soft slicing first, at least until all the major suppliers have hard slicing supported, debugged, and perhaps even, supported by automation.

On balance, I suspect hard slicing support will be part of the decision criteria in numerous networks, so the industry will have comparison points between hard and soft slicing from 5G to apply to 6G.


It does seem the industry is aligned on segment routing as the technology of choice for routing, in 5G. I mention IP/MPLS because you never know how long a matured solution may still be considered while operators kick the tires on segment routing. That aside, the conversation is today mostly about SR MPLS or SRv6.

Cisco is viewed by competitors as strongly pushing SRv6, both through Cisco’s efforts in the IETF and also in customer engagements. The Webinar Cisco gave last week generically positioned segment routing and was not tilted towards SR MPLS or SRv6, if anything, marginally towards SR MPLS.

My own view is SR MPLS will be more dominant than SRv6 over the next three years, for a multitude of reasons: reuse of MPLS equipment, smoother transition from IP/MPLS, reuse of many IP/MPLS mechanisms, conservatism, more vendor choices, inconsistency with respect to IPv6 transition readiness, and some lingering debates about the impact of 128-bit segment ids. To all these issues there are SRv6 rebuttals, but on balance, I would still put my money on SR MPLS in the short-term. Cisco can of course support IP/MPLS, SR MPLS, or SRv6. In terms of the various flavors of SRv6 being discussed in the IETF, I choose, for the sake of brevity, not to get into that here 🙂 Cisco’s view is that SRv6 will provide the best scalability and simplicity, but also understand SR MPLS is a good path forward for many operators in the short term. See also my article: Segment Routing: The Journey Back Home.

Figure 1. Segment Routing Network Simplification, Source: Cisco Systems.

Cisco’s view of the network simplification provided by segment routing is aligned with the direction industry thinking has been trending in. See my articles:

A couple of questions do remain from the Cisco view of simplification. I’m generally in favor of the shift to Netconf/Yang to support more programmable / automated networks, however, the timeline for CLIs going away is far from clear. I know of at least two vendors that built products with Netconf/Yang and without substantial CLIs, only to have to go back and do a more substantial CLI implementation. For sure, CLIs seem to be still relevant in lab/testing work. Are they still relevant in production networks? Based on what I have seen, they will still be a requirement for the next few years, and no doubt Cisco products will support them. Similar observations for SNMP.

As I mentioned in “Segment routing: Less state, less capability. IP/MPLS RSVP-TE: More state, more capability” There is a granularity of traffic engineering supported by IP/MPLS RSVP-TE that is not characteristic of segment routing, as currently standardized (there are some QoS-like segment identifier standards discussions going on). Is this granularity of TE a requirement, or simply a challenge to scale that the industry has to work out a different answer for?

As discussed in the article “NETWORK ARCHITECTURE: A THREE OLIVE MARTINI”, I view segment routing in the optimization area, shown in figure 2, where operators can play with a number of variables, so that the granularity provided by SR for TE, is sufficient.

Figure 2. Optimization opportunities across risk, cost, and outcomes

One of the big wild cards in this discussion is of course small cells: when will they be in sufficient numbers, and how much Radio to Radio routing is required, to drive scale requirements that push industry momentum well in the segment routing direction, if it is not already.

While there remains concern within the industry that BGP is being used for too much, the reality is that most vendors are on board with BGP being a layer 2 / layer 3 VPN layer, operating over IP/MPLS, SR MPLS, and SRv6 networks, enabling a smoother migration than LDP-based layer 2 VPNs, as LDP is not part of the segment routing networking approach. See: BGP for Service Layer Migration and Perhaps More

With all the LDP already deployed, it is a little bit reckless of me to simply say BGP is the way to go for L2, and leave it at that. One unknown at this time is whether operators will choose vendors that just have segment routing or will they require vendors to have all the current stuff as well. There are approaches to mapping IP/MPLS domains to Segment Routing domains, the question is will network operators simply show preferences for vendors/solutions that do everything, or will they take the opportunity to consider vendors/solutions that do segment routing only.

Figure 3. Segment Routing Network Simplification, Source: Cisco Systems.

Cisco asserts that IOS XR 7 is optimized, in many ways, allowing it to be deployed on both small and large routers, including being streamlined for SR/EVPN. Given Cisco has products that can do all flavors of routing, it will be interesting to see how this plays out in real deployments. I believe network operators should take the opportunity to insert products that are streamlined for SR/EVPN, the presumed go-forward architecture, but my crystal ball is a little fuzzy on what they will actually do, broadly.

Converged packet/optical transport

While there are a couple of intertwined issues here, the basic answer, for me, is yes. When I say converged, I am mostly referring to a single packet underlay for all wireline and wireless services. Putting aside the nuance of separately operated networks for wholesale (which is not a significant factor in all geographies), operators want to reduce cost, so they should drive common building blocks, drive utilization, and lean on traffic engineering / logical topologies to reduce their overall router spend. Especially with 5G, CPRI can converted to eCPRI by the fronthaul, worst case circuit emulation can support previous generations of radio, etc. If Cisco’s point about business, residential, and mobility having busy hours at different times of the day holds up (in a post Covid world), then that just puts an exclamation point on the issue.

Perhaps one wild card in this scenario is whether all the “complexity” of 5G would make a common solution more expensive than it needs to be for a wireline transport application (and I have seen a little bit of this as wireline apps look to also leverage a dense 25 GE solution). This is where I feel network design/architecture can support keeping the additional expense 5G tech away from the generic transport tech.

Does convergence of this type favor some vendors more than others? Perhaps. Cisco has been deployed for business edge, residential edge, and mobility. However, it is not as simple as that. Juniper has maybe the best residential edge, with solid business edge capabilities. Cisco is probably the most widely deployed for business edge, and Nokia is widely deployed for aggregation (not saying Nokia does not have edge functionality). All three can support a common approach to aggregation, and where edge functionality belongs going forward, and how it is deployed, is another article. Huawei in the geographies it plays will claim similar functionality as Cisco.

Then there is optical. If I had a dollar for every packet/optical convergence conversation I have had over the last 20 years, well I’d probably be relaxing in Bora Bora right now. That said, there is some interesting stuff happening.

Cisco acquiring Acacia (not yet closed AFAIK) is big news. That combined with 400ZR(+) pluggables creates some real interest in how architectures evolve. 400ZR pluggables are spec’d to work in metro areas (say up to 80km, maybe 400ZR+ goes longer) without the need for a separate transponder shelf; the pluggable is the transponder. This is big news, and the rate and penetration of adoption in routers, plus the impact on the optical equipment market, is something that will be a significant story over the next few years.

That’s not the whole story though. Operators may still choose to deploy WDM components. In addition, Ciena and Infinera have already announced/demonstrated 800 Gbps solutions. How much spectral efficiency continues to be critical, and the distances over which 800 Gbps is used, are part of this conversation as well. Also, who dominates the 400ZR/ZR+ pluggable market will be fascinating too: Ciena, Cisco/Acacia, Nokia, Inphi, Huawei? Much interesting stuff to come, watch this space.

When will end-to-end automation be a reality?

As this article is already long, I will leave this subject for another article. To be clear, my concerns in this area are not Cisco specific. It has more to do with whether the industry is really creating the environment in which this becomes a reality, in open, multivendor, multidomain, multilayer environments – that is a bucket load of complexity to chew off, potentially multiple operations groups (outside of greenfields), and overall, ambitious. Especially if there is any significant legacy involved. However, there are vendors who claim to be able to do this, and 5G will be a chance to see if those claims hold up to the reality of deployment and operation.


Overall, I enjoyed Cisco’s webinar on “5G xHaul & SR-driven Network Slicing” and I don’t have any significant problems with their perspective. That said, my comments above obviously indicate there are some issues which I do not feel are yet settled, industry-wide. It is a time of transition, 5G is an opportunity to explore new tech and new approaches. Many moving parts, much to keep an eye on.

This site uses Akismet to reduce spam. Learn how your comment data is processed.