Steve Puluka has had a front-row seat to the internet’s evolution since it started taking off in the ‘90s. Throughout it all, only one thing has remained constant.
Change.
“Obviously things change in this business,” the DQE Communications network and security engineer recently told Juniper Networks. “It’s one of those things you have to like if you’re going to be a network engineer.”
Where the early days was about scaling up and connecting the country’s internet infrastructure to move packets, nowadays the number of new protocols, features, use cases and services have snowballed over the better part of the last three decades. 5G and IoT services are starting to crop up left and right, dictating a need for a new way to connect everything.
And this shows no signs of slowing. Already routing tables are exhausting, leading to new protocols from companies like Facebook (Open/R) and Google (P4). Don’t forget the sheer growth of the volume of data; current research suggests that 90 percent of the world’s data has been created in just the last two years. And each new update has traditionally required a reevaluation of infrastructure and sharpening of skills.
That’s enough to make any service provider network operator’s head spin.
But with Juniper’s announcement today of the biggest refresh of its flagship MX series routing platform since its inception in 2007, those challenges could become another thing of the past with high levels of programmability, flexibility and integrated security.
Puluka is a longtime MX user, so we recently sat down with him to talk through his evolving experience as a network engineer over the last decade and see how the new MX 5th Generation (5G) Universal Routing Platform will help him continue to solve complex challenges and keep his business growing.
Q: Steve, thanks for chatting with me today. Tell us a little about your role at DQE Communications.
I work on the IP Services team of about 20 engineers. We design and implement metro ethernet and internet services over MPLS for B2B customers. We focus on both custom solutions and strong customer service.
Q: And how has your role evolved over the last decade?
There is a constant push for improvements in scaling bandwidth, speed to complete implementations, adding resiliency and to enhance the security of the network. These factors drive changes in network topology and design. And they also then influence how we provision and support the network services created.
Q: How do you see your role changing over the next 10 years?
What I have always enjoyed about this business is the constant innovation and change. I love to learn new techniques and implement new protocols and designs. Some of the areas that I am watching closely now are the movements in the further separation of control and forwarding planes. Junos early on adopted this model and now this is being extended to pulling the control plane out to the size of larger network spaces instead of just individual nodes. The “Software-Defined” world is taking this control plane process to the next level.
Q: Tell us a little bit about your experience using the MX router – what does it do in your network? How was it helped your business?
The MX is a real workhorse that scales up nicely as the needs increase over time. And the platform is highly flexible and modular so that it can be setup for the needs of the various areas of the network core and aggregation. Using a ring topology for the customer edge, we try to hone every ring to diverse MXs at the POP around our footprint. The MX also provides a strong platform for upstream peering with our many partners allowing separation via virtual routers and capacity for multiple full table connections.
For us, The MX has given us flexibility more than with commodity chip sets – flexibility in the software and additional capacities in hardware. We use white box commodity chips sets where it makes sense in edge. But in terms of aggregation and core, being able to add services like CG-NAT in our future and also the capacities and flexibilities to mix and match cards for the needs of specific region is huge.
And I think this (new MX 5G) platform from original release of M-series to each of its next generations of the Trio chipset is very responsive to needs from both the processing side of software and features, and the capacity side. I’m continually amazed how we can almost double the MX’s ability to do things with each new generation. What’s great, too, is we don’t ever have to throw away what we already have; you can mix the old guards with new and can drop the new in where needed to protect our existing investment. It’s been very flexible and whole modular approach has worked for us.
This is an exciting offering here. Any time new generation comes out, it’s always exciting.
Q: What do you see as the next big challenge service providers, cloud companies and enterprises will have to cope with when it comes to routing?
The continuing growth of the internet route table size is becoming an issue for enterprise customers along with the growth in bandwidth needs from the cloud locations on more and more data and workloads.
On the service provider side, we are seeing more BGP high-jacking and inadvertent route leaks that cause problems for access. The security of the routing table is becoming more of a problem. The expansion of 5G will also be creating more stress on latency and bandwidth requirements. MPLS TE routing and control is another area with a lot of work in progress. The ability to use Path Computation Element Communication Protocol (PCEP) and the upcoming deploys of SPRING for path controls offer a lot of promise to create both resiliency and more efficient use of network resources.
Cloud and data center operators have worked hard using BGP to setup equal cost full link usage. The next level seems to be coming from partnerships with large operators like Facebook and Juniper with creating new messaging protocols like Open/R as well as with Google’s P4 Runtime.
Q: What’s going to be the most important aspect of routing looking ahead five or 10 years?
With the promise of new control protocols like SPRING and Open/R, I expect network operators will gain more control over paths and better utilization of network resources. I am not sure if these will be the final “winning” protocols or methods, but I am pretty sure that the problems addressed by these will be solved by some new method if not these particular ones.
The internet is becoming standard; early days most circuits were private but the ratio has flipped. More services are internet-related rather than private.
And concurrently, the ability to measure performance as a metric for route selection. Currently some products on the market provide intelligence to probe and measure performance of multiple upstream choices looking beyond the normal route selection metrics. I hope that some performance-based metrics can find their way into routing standards. Important to this effort is also some better tools to signal and control inbound routing path selection. Our options remain limited in this area by the nature of BGP and the route prefix options available.
Q: How important do you think automation is going forward for telcos and enterprises implementing various versions of the cloud?
Automation is already a critical component of network operations. Automation brings a measure of consistency to network operations that is simply not possible with fully hand built services and systems. This provides ways to validate the operations and configurations in place. It provides a method to deploy new configurations and services as needed. And the ability to respond to network events with appropriate remediations or additional configurations.
Network engineers need to be proficient in both the underlying configurations to understand what is happening on the network as well as the standard processes of software development to automate those tasks in the future. This is an area where Junos really shines. From the start, Junos was built to accept programmatic entry. Juniper continues to support virtually all the automation tools that become available – Chef, puppet, ansible, salt and others. Juniper engineers were key members of the teams behind many automation standards like Netconf/restconf and YANG. I expect the industry to continue down the automation path full steam for the foreseeable future.
And for me personally, I just try to improve my own skills and abilities as change progresses. Automation is definitely doing to be a part of this. Going forward I think network engineers will need a basic understanding of software development and databases. I was fortunate coming into the internet in the late 90s when the web was first spinning up and being a programmer for five or six years. Those are skills a lot of network engineers haven’t had time to work on – version control for software development seems like it can be a foreign concept to many.
Steve, thanks a lot for the time today. To learn more about the new MX 5G Universal Routing Platform, be sure to check out our solution page.
Forward-Looking Statements
Statements in this blog post concerning Juniper Networks’ business, strategy and focus; the expected future challenges of customers with respect to networking generally and routing more specifically; the expected direction of networking technologies; the future direction of our products and expected benefits to customers; and our overall future prospects are forward-looking statements that involve a number of uncertainties and risks. Actual results or events could differ materially from those anticipated in those forward-looking statements as a result of several factors, including the factors listed in our most recent report on Form 10-K and subsequent quarterly reports on Form 10-Q filed with the Securities and Exchange Commission. All statements made in this blog are made only as of June 12, 2018. Juniper Networks undertakes no obligation to update the information in this blog post in the event facts or circumstances subsequently change after the date of this blog post.
Statement of Product Direction
In this blog post, we may disclose information related to our development and plans for future products, features or enhancements (“SOPD”). SOPD information is subject to change at any time, without notice. Except as may be set forth in definitive agreements, we are not providing any assurances, or assuming any responsibility, that future products, features or enhancements will be introduced. Except as may be set forth in definitive agreements, customers should not base purchasing decisions upon reliance of timeframes or specifics outlined in an SOPD, because we may delay or never introduce the future products, features or enhancements.
