Data Center Interconnect

NFV & The Data Center: Top 10 Takeaways

SANTA CLARA, Calif. -- NFV & the Data Center -- There was more to this week's NFV and the Data Center event then barfing unicorns, seven-minute abs and conga lines -- although those were all part of it as well.

Light Reading's day-long deep dive into data centers provided a realistic look at timelines for virtualization, the new security requirements for NFV and the migration path from a telco data center to a cloud-based environment. There were a lot of great perspectives and content from the event, but here is a list of my top 10 takeaways for telcos navigating NFV and the data center.

For all the coverage from NFV & the Data Center, go to the dedicated show site here on Light Reading.

10) SDN must be open.
If SDN is not open, it defeats the original purpose of the technology and prevents it from scaling. Not surprisingly, this thought came from the chairman of the Open Networking Foundation 's migration working group, Justin Dustzadeh. The ONF is all about openness -- it's right there in its name -- but it's a good reminder as vendors pitch software-driven platforms that are open in name only. (See How Virtualization Transforms Network Needs.)

9) Complexity should be tackled in the service layer.
Just as going from hardware to software doesn't ensure openness, it doesn't guarantee less complexity either. "If all we do is trade off complex hardware to complex software, we've really done nothing to get us down the road of what NFV is supposed to deliver," Christopher Liljenstolpe, director of solutions architecture for Metaswitch Networks ' networking business unit, said at the show. He believes the most time and money should be invested in dealing with complexity at the service layer. Customers don't care how complex the network is (unless it fails, that is). They need simplicity in the service infrastructure, i.e., only a couple of choices for storage, compute and connectivity that can then adapt to what needs to be delivered. "If complexity is required, it's best to push it up the stack," Liljenstolpe said.

8) NFV, SDN and cloud are inextricable.
Operators are planning for SDN, NFV and the cloud at the same time, although it's because they will complement each other, rather than heading for collision. They can be done separately, but work best together. SDN helps make NFV possible, Heavy Reading analyst Roz Roseboro said, and both are eventually going to a cloud architecture. "Eventually it will all be considered one thing with an interdependence," she said. "You can do all them separately but, if you do them all together, there is the biggest benefit." (See Brocade: There's Something About the Cloud and Ixia's New CEO to Telcos: Read Up On Cloud.)

7) NFV is already here, but far from mainstream.
NFV is already here in some forms today, but expecting telco services to be entirely migrated to NFV by 2020 is a bit aggressive. That was the general consensus amongst many of the panelists at the show. Even for early adopters, it will be a challenge as they work through internal issues like breaking down their organizational silos and adapting their business models. (See NFV Lets NTT America Flex Its Networks.)

6) Automation matters in the cloud.
CenturyLink Inc. (NYSE: CTL)'s VP of Network Strategy and Development James Feger put it best when he said, "if you're on a nine-month release strategy, your network isn't really programmable." Timelines must become a lot shorter, and programmability and automation are necessary components to allow for self service in a complex environment. (See CenturyLink Pushing Faster Service Cycles.)

"Agility is an asset. You can only tame complexity," added Heavy Reading analyst and event host Jim Hodges, quoting Brocade Communications Systems Inc. (Nasdaq: BRCD)'s Kelly Herrell from an earlier presentation. "As an industry, we realize complexity is an inherent part of what we're doing, but it's something we have to address."

5) Business case drives everything.
Nothing gets done at an operator -- related to NFV or otherwise -- if the cost cannot be proved out. Every decision on what gets funding is driven by cost, a point Sprint Corp. (NYSE: S)'s Manager of Emerging Opportunities Anne-Louise Kardas reiterated at the Women in Telecom breakfast. And, Roseboro added, what gets funded is the stuff that affects the top line, meaning NFV is much more likely to see funding because it helps an operator make money, while SDN is all about opex and efficiency. (See Pics: LR's Women in Telecom Breakfast and Introducing 'The New IP' .)

4) Get surgical about how security is inserted into the network.
Moving to a more cloud-like data center that is scalable and malleable blurs the lines for where security should be inserted, according to Adam Geller, vice president of product management at Palo Alto Networks Inc. Decisions made on ports and destinations ignore fluid apps and activity outside the core of the network. A recent study of Palo Alto's customers found that 95% of attacks logged against customers came from only 10 apps, nine of which are commonly used and can't just be blocked. That's why telcos have to be able to inspect traffic at a deeper level, he said. Security can't be based on physical appliances, and it can't be generic.

3) Security needs to be virtual, segmented and on-demand.
The importance of security was reiterated throughout the day, creeping into every panel session and keynote. While SDNs can respond to threats a lot faster, their design also means that if a criminal hacks into the network's vCenter, they can control the telco's entire data center. That's a scary thought. Deb Banerjee, chief architect of data center security at Symantec Corp. (Nasdaq: SYMC), said that segmentation is key for security so that it's not tied to a set of racks. Segmentation lets telcos use policy to pick and chose which sets of traffic to scan through firewall. They also need virtual security appliances deployed in the fabric of the data center on every host. "Risk is more dynamic; not as static as it used to be," Banerjee said, adding that combining virtualization, SDN and NFV can enable security on demand.

2) Avoid the security app conga line.
Finally, when implementing security, keep in mind that service chaining only goes so far. Palo Alto Network's Geller said that a good security solution has to fit into various technology architectures today and in the future. If not, operators will just end up with the "security app conga line," which will be a challenge to manage. "Any good security solution that's going to fit in has to be orchestrated and tie into existing solutions," he said. And, he added, a centralized policy management platform is required to do anything at scale, and it must also use context awareness and sharing, which isn't happening much today. "Two-way communication is still at early stages for a lot of organizations. When they see that, they see there is significant opportunity to add security dynamically."

1) NFV must be 'operationalized.'
The good news is that a year ago everyone said NFV would never be "operationalized," and this year that conversation has changed to how to do it. The bad news is there is still a lot of work to be done. Roseboro explained, "All the technology in the world is great, but if you can't operationalize it, it will be crap that just sits in the data center, and you can't use it. If you just take processes today and automate them, it's garbage in and garbage out." Networks have to be re-architected to do things differently, and she believes it's still very early. Operators are starting to automate the easy parts of their network, but it'll be a long time before they tackle the entire thing.

— Sarah Reedy, Senior Editor, Light Reading

brooks7 9/18/2014 | 8:36:04 PM
Re: My top two Mitch,

I posted this in the other thread but...you basically get to this kind of open system when there is somebody in charge of architecture.  This means that all products of category X will meet these requirements and will have been tested to meet those requirements.  That is what our OLD system with Bell Labs (Architecture) and BellCore/Telcordia (Specification and Testing) did. 

So, here is what it would mean...we would define what a Core Router through an abstract specification.  All vendors that wanted to apply to the RFP would need to meet and have been tested to meet ALL the functions required in the specification (unless specifically waived).  

In my old DLC days, that meants we ALL had to meet TR-57, GR-303, TR-08 and other reams of specifications because somebody decided this is the spot in the network for a thing we will call a Digital Loop Carrier (aka a DLC).  All the DLCs in the day (and I can't speak for Calix or Adtran today because I don't know if they have been certified by what used to be Telcordia) - a Litespan or a UMC or a AccessNode or Reltec or SLC-5 - were all directly replaceable functionally  we competed on price/performance in the implementation of those specifications.

And nobody called it open because guess what, vendors did not get to choose the architecture.  Bell Labs laid down the rules and we all had to play by them.  Same thing was true with LSSGR or SONET.  

So - is everybody willing to give to a single group architectural control for telco networks?  (See Cablelabs).


DHagar 9/18/2014 | 4:12:51 PM
Re: Just a few thoughts on the post Art King, I like your points as well, especially the last one on the impact on architecture, operations, and organization structure - I fully agree.

I like Sarah's thoughtful review and "granular" insight on the developments.  I believe if these points are properly understood, NFV will become operational and demonstrate true value with data centers.
Mitch Wagner 9/18/2014 | 2:54:52 PM
My top two I absolutely loved Marc the ONF's Marc Cohn's rough-and-ready definition of openness: Openness isn't about having open APIs. Openness is about giving the carrier the option to change vendors. 

Any vendor can say they have APIs and customers have a wide range or partners to choose from. Bu the carrier is still locked in if they have to buy the underlying infrastructure from the vendor. 

Not naming names here (*koff* Cisco *koff*)

I loved Kelly Herrell's There's Something About Mary story. I'm surprised that story isn't used more in business presentations, because it's so spot on. Although I cringed when he first brought up the movie, because there are so many inappropraite directions that movie goes. 
jhodgesk1s 9/18/2014 | 10:35:09 AM
This list goes to 11 Sarah, If we extended the list to 11, I would add that there is considerable interest in running orchestrated VNFs outside the DC, aligned with the D-NFV model.
brooks7 9/18/2014 | 10:07:51 AM
Re: Just a few thoughts on the post... Let me ask a question,  Are the following Network Functions:

- Web Server

- Mail Server

- Firewall

- Load Balancer

These functions have been virtualized for years.  The way that the IT side of the house gets to this is that it has eseentially moved everything to the top of the stack for processing and used standard protocols to interconnect them.  In a data center with virtualized functions, you essentially end up with infinite connectivity between processing functions.  Transport over IP networks becomes a commodity that is bought from a series of providers.

If carriers adopt that model, poof there is no need to wait around to do things.  What I see is that they are trying to bury processing inside the network.  That is much, much harder.  Imagine for example (ignoring redundancy) that CenturyLink built 1 massive data center and moved ALL processing to that data center.  It then connected every server in the data center with at least 1 GbE.  Then, they structured a massive 10GbE/100GbE switching infrastructure to create essentially universal connectivity.  The problem becomes much, much simpler in that model.

Then take a look at an Enterprise deploying in Rackspace or Amazon (or a hard data center).  That is essentially what they get.  Now they have multiple centers, but the scale of each processing center is much, much greater than any application.  It means that there is always processing and network available.

sarahthomas1011 9/18/2014 | 9:55:30 AM
Re: Just a few thoughts on the post... Thanks, Art! Excellent list from you too. Glad you agree with most of the takeaways. It was interesting to see how far the industry has come since last year, at least in how they are thinking about all these opportunities and challenges.
sarahthomas1011 9/18/2014 | 9:54:54 AM
Re: Complexity Disclosure Thanks, Jim! I updated the quote to reflect that it was from Kelly's excellent keynote earlier in the day. A good point worth repeating, either way.
Art King 9/18/2014 | 9:46:00 AM
Just a few thoughts on the post... Sarah,

Wow, sorry to miss the event. Was just thinking about the points while reading it.



10) Of course.

9) Fast and kind of dumb in lower stack is not a bad thing. Makes comprehension by operations easy.

8) They are somewhat on parallel tracks and may be implemented by different parts of the organization. If the architects are at least planning together...

7) It's a journey with much learning to occur. Pioneers break the first trail through the snow (hard), following in the tracks they have left is, maybe, easier. 

6) This is also an opportunity to question everything in configurations before they are carried forward.

5) There is also the lateral effect of Capex deferral in other areas driving the investment. Data center out of electrical and HVAC capacity drove first virtualization project I was involved in. 

4) Security apparatus when overdone and/or not well understood by day to day operations folk can cause enormous grief when making changes. Fluid apps and good targeting keep the world "interesting".

3) Agree, but worry about too many in-path security things (like 2 below)

2) So true, especially when someone in-path has transient performance issues that can't be isolated.

1) Agreed. Architecture, operations, and org structures are going to be turned upside down on way to destination. That may not be a bad thing if a truly cross-functional team must emerge from the transition. 
cnwedit 9/18/2014 | 9:39:33 AM
Re: Complexity Disclosure This is a great list, Sarah. I think the over-riding thing I came away pondering is the automation piece - that is essential to everything else. Automation means extracting the people, who are the biggest part of the complexity. I think both Kelly Herrell of Brocade and James Feger of CenturyLink stressed those points. 

AT&T's announcement yesterday intrigues me on that front - they are delivering self-service to business customers built on an SDN, and I hope to find out how and how much they have automated all of that. 
jhodgesk1s 9/18/2014 | 8:11:40 AM
Complexity Disclosure Sarah, "you can only tame complexity" was a direct quote from Kelly Herrell I extended to capture input from the panels that reinforced this is a key implementation topic.
Sign In