An Architectural Perspective on Hierarchy In IP Networks - A Complex Puzzle Comprising Protocols, Topologies, Addressing & Systems (A Short Post)

 

If you ever bump into a Network Design book, course, blog or a webinar - most likely you are going to get introduced to this interesting & an important concept of " Network Hierarchy aka Hierarchical Networks Design Principle ".

Now depending upon which study materials and authors you follow, you would likely to come across different view points in terms of it's needs, pros & cons. Which in general not only contributes into more confusion among audience but also when I speak around with experiences Network Architects & Design Engineers, I often find them:

1. Having different interpretations of this concept and different view points

2. Considering this to be a very theoretical concept which you are likely to encounter in most Architecture & Design books but don't know about:

A. How to practice it (By applying theory to practice) 

B. How to measure it 

C. Missing the deep understanding of the topic at hand beside failing to understand its tradeoffs

So Idea behind this post is to offer you some architectural decision pointers to think through the problem statement and break it down into few tangible pieces by following another important network design principle " Separate the Complexity from the Complexity - Russ White " beside examining the rule 8 from RFC-1925

One of the model I personally always find handy is the SOS model from Russ White and you can use it too as a good ref. point.

So here is the quick list for you to think through in a more pragmatic manner:

1. What problems are you really trying to solve by introducing hierarchy into the Network (Go beyond theory) ?

2. Is it always possible to follow hierarchy? Specially in brown fields or during transitions (Think of old gear with still some lifetime left, mergers )

3. What are the downsides of introducing hierarchy ? (What harm it can cause and tradeoffs such us downgrade Agility, Flexibility, Organic Growth etc.)

4. Difference between Hierarchy vs. Symmetry vs. Modularity vs. Abstractions 

5. Different types of hierarchy/ layered approach to it ( physical level hierarchy,  logical level hierarchy,  hierarchy in addressing scheme, Protocol Level Hierarchy (ISIS Levels & Addressing ?) and so forth)

6. What data points you have in place to test your hypothesis to measure its impact on network

7. How these concepts are applied to different network environments - Enterprises (Campus <Wired and Wireless>, WAN/SDWAN, DC) vs Teclos vs CDNs vs Cloud Providers vs Web Scales vs Within public cloud virtual DC + Controller vs. Controller Less Architectures

8. Impact of introducing hierarchy on Visibility, Reporting and Performance mgmt. of the network

9. Impact on hierarchy on information hiding <reachability information> vs. topological information hiding (Aggregation vs. Summarization)

10. How all these choices will flow into your equipment sizing and potentially have an impact on your decision process

11. How will you apply all these concepts in a IPv10 network (IPv4 + IPv6 aka Dual Stack)

12. And if you are still brave enough :) , read through the further readings list to get to the bottom of this rat hole

Further Readings:

P-FatTree: A Multi-channel Datacenter Network Topology

Enabling Wide-spread Communications on Optical Fabric with MegaSwitch

Abstraction in Networks with Russ White

Hierarchical Network Design Overview

Engineer Versus Complexity

Optimal Routing Design

Navigating Network Complexity

Network Topologies

Five Number Summary for Network Topologies

Scaling MPLS Networks

The Side Effects Of Route Summarization

Avoid Summarization in Leaf-and-Spine Fabrics

Valley-Free Routing

Intra-Spine Links in Leaf-and-Spine Fabrics

Nonblocking versus Noncontending

Hierarchical IP Address Design and Summarization

Hierarchical IPv4 Framework

Fabric versus Network: What’s the Difference?

Liskov Substitution and Modularity in Network Design

Dragonfly+: Low Cost Topology for Scaling Datacenters

Reliability Basics- Part1

Network Centrality and Robustness

Swimlanes, Read-Write Transactions and Session State

Fifty Shades of High Availability

HTH...

A Network Artist 🎨

Marrying SASE (SDWAN) with 5G - The Marketing, The Myths & The Fallacies & How to Get it Right (An Architectural Perspective)

When almost 3 years ago I wrote about why having an inbuilt LTE interface inside a SD-WAN device doesn't really matter, the 5G thingy was still relatively new.

During a recent Enterprise Architecture Consulting engagement, I was asked by one of my client if they should really care about 5G and 5G interfaces on the variety of SD-WAN platforms that were pitched to them by different Systems Integrators (SIs) & MSP (Managed Service Providers)/Telcos.

So let's start with a simple question - "What problem we are trying to solve?"

In general you will see a few types of customers in SASE/SD-WAN market :

1. Which have Technical/Solutions architects those are completely sold on vendors marketing (50% of the crowd)

2. Those who wants to jump on the bandwagon due to fear of being left behind in the similar industry or by the competition (25% of the crowd)

3. Those who always are either too excited by technology or have a lot of money to throw onto the problem (the next 20%)

4. Those who can really map business capabilities to technology capabilities (the rare and the last 5%)

In general, you would often find a few ways the 5G gets included into the solution by solution providers such as :

Design 1 - You have a site (mid/large size) which either has got hybrid connectivity (MPLS + Internet) or 2 x Internet connects, while keeping 5G cellular as a last resort backup link in an event of a total failure.

Design 2 - A small site that usually runs on a single internet link and keeping 5G as back for last resort.

Design 3 - 5G as backup of last resort onto your DC WAN edge

Now in general it doesn't look like a bad idea to have a 5G interface but here are few of the important considerations:

- In general your DCs/COLOs and Campus networks would be setting on racks behind thick physical building structures (remember your Wi-Fi coverage problems even while your APs are sitting inside), so very often you would expect coverage issues. Now one of the argument here might be that I can install an external antenna of some sort on top of building or floor and run a fiber cable connection from there. Fair...but:

> Now you got to get approval for installations, cable runs, have administrative processes and safety processes in place and what not (What if the lightening hit the antenna?).

- To my understanding, most SASE/SD-WAN solutions don't offer any visual monitoring, reporting & troubleshooting tools for - Checking 5G signal strength, 5G interface troubleshooting, Dummy traffic probes etc.

- Interestingly enough now you need even a more complex traffic distribution, traffic prioritization, traffic failover, traffic desired SLA/performance metrics and other set of policies into the mix. And even if you end up doing that successfully, how you are going to document it for the operations ?, Is your EMS/NMS equipped with such capabilities ? 

- From the network architecture perspective, you just added an another layer of complexity. Assuming this 5G interface is an HW module, you got to now deal with: New stack of software and protocols within your fancy WAN edge device (3GPP standards), New interaction surfaces, New potential grey failures.

- You just end up adding the more state into the network (State, Surface & Optimization tradeoffs) 

- You need to now have life cycle mgmt. in place for your 5G interface (HW/SW Upgrades, Monitoring, Management, Refresh etc.) beside that fact that the 5G specifications often vary country to country (even from Telco to Telco) and now you need to keep track of Data Plans, Data Usage, Availability & Performance Mgmt., Cost Mgmt. and what not. (Remember your data plans are pretty limited in general?)...imagine to solve these problems at a global scale deployment dealing with different MSP.

> How to you move to 6G if it comes out in the next few years ?

Now after all these interesting questions, we may still ask:

1. What are the better alternatives today ?

2. Where 5G might still make sense ?

Answering the first question, IMHO I would still recommend you to opt for a broadband connection and avoid 5G unless you have a very particular problem or scenario because:

- With broadband you are still dealing with Ethernet connection between your CPE and broadband router/device which is a pretty familiar connectivity model and protocol stack to deal with.

- In general your broadband data plans are much bigger 

- You don't need to deal with another MSP for service management perspective as in general your ISP would have a common portal to give you a view of all MPLS, Enterprise Class Internet and Broadband based Internet connections. (Also mind that historically your SPs were building two parallel networks for ISP (Internet Service Provider) and MSP (Mobile Service Provider) business units, though those are converging now more and more)

- With everyone hit by pandemic that accelerated WFH culture, in both developing and developed countries you would expect to have broadband being available very easily and at the affordable prices. The only places you might still face availability issues are Tier-3 cities and so forth. But for most part that is not a technology problem but your SPs wanting you to stick with cellular connectivity to drive more profits (So its an intent problem rather)

- My own research suggests that in many developed countries getting a broadband will cost you far less compare to the enterprise class 4G/LTE/5G/Private 5G connection

Answering the second question, here are few use cases for your consideration:

- 5G as part of your SD-WAN transition plan (Legacy to SD-WAN)

- Your last mile hybrid or other wired connectivity model still runs on same fiber or shared media (true path diversity problem)

- One or both of you last miles are on Microwave (Should be pretty rare now)

- 5G as a OOB (Out of Band) management option

- Movable workplace and offices (Eg. Marketing/Sales & Promotion offices or moving semi-trailer trucks often used in variety of businesses)

- Specific operating conditions such as in Oil/Gas & Mining industries

- Edge compute/Cloud

- IoT Platforms

HTH...

A Network Artist 🎨

Further Readings:

SD-WAN Leads to $96,000 4G/LTE Bill

Improve Your Home Internet Performance Using CoDel

More Bandwidth Doesn’t Matter (much)

Are Networks Really Complex ?

Enterprise QOS Design & Deployment - Good, Bad Or Ugly ?

Focus on Your Business, Not Fancy Technologies

Are You Solving the Right Problem?

This Is What Makes Networking So Complex

Are Business Needs Just Excuses for Vendor Shenanigans?

The Three Paths of Enterprise IT

SDN Will Not Solve Real-Life Enterprise Problems

Why Intent Based Networking (IBN) will Not Save Your Network Anytime Soon ?

Complexity and the Thin Waist

It’s Most Complicated than You Think

Details and Complexity

"Things to learn early on in career" - Network Engineering

 

If you on an early stage of your Network Engineering career, learning following things will immensely help You to get up to the speed with real world requirements/skills.

1. Learn about different optical fibers types and subtypes - Single Mode vs. Multi-mode, OS vs. OM specifications.

2. Learn about different Optical & Optical to Ethernet SFP types, Distance they cover, Speeds they offer, Connector types they got.

3. Learn the internal architecture of a Router at least at high level if not deep.  

4. Learn at least basics of ASICs and their high level differences among chip makers.

5. Pick early on "Overlay Protocols" such as - GRE, VxLAN & Geneve fundamentals as they seems to be all around in 2021.

6. Pick on fundamentals of "MPLS" - You will need that pretty much everywhere despite being in Enterprise or SP.

7. Learn about fundamental building blocks of Coding - Don't focus on Networking application of it to keep it clean at the beginning.

8. Learn & Practice "Kepner Tregoe problem solving technique"

HTH...

A Network Artist 🎨

Where & Why did We Lost SDN ?

 

In theory, the core objectives of Software Defined Networking (SDN) & Intent Based Networking (IBN) should have been (As an Integrated Package):

1. Introduce System Thinking

2. Simplified Life Cycle Mgmt.

3. Introduce New Abstraction Layers to Help Businesses People Have a Realtime/Historical View of Business Performance Metrics & Insights

4. Seamless Integration between Technology Metrics & Businesses Metrics to Fill the Gap between The Two

5. Reduced Complexity & Running Cost

6. Flexible Consumption Models

7. Embedded Security

8. Flexibility to Build Innovative Solutions on Top of Given Platform that Meets My Specific Environmental Needs

9. Gel Well with Existing & Legacy Environment and Tools

10. Allow Me to Run Dry Runs, Simulations and Offer Me Insights & Recommendation to Keep Improving + Troubleshooting

11. Reduce my Risk Profile (Technically & Financially)

But...What We Ended Up with:

0. Fancy GUIs Built Around Object Oriented Programmability Principles, You Just Need 10 Clicks to Create VLAN & Map it to a Port 😇

1. Separation of Control Plane & Data Plane

2. Network Virtualization

3. Network Function Virtualization & White Boxes

4. Human Driven Programmability & Automation

5. Controllers

6. Tons of Overlay Protocols

7. Proprietary Solutions

HTH...

A Network Artist 🎨

Why would I care " How does that God Damn Router Really Work ? "

 

    

Interesting enough, You could pass your favorite networking industry vendor's Expert level lab exam and through out the process, they never really tell You how does Router/Switch (or whatever fancy name they may have) really work behind the scenes.

On the flip side, at its core - IP Networking is all about moving packets:
1. From point A to point B
2. Switching packets between Input & Output interfaces

But still You can provide an expert opinion on Control Plane, Data Plane & Mgmt. Plane

Perhaps You believe too much into voodoo magic  😉

HTH...

A Network Artist 🎨

The Tale of Application Aware Networking

 

Almost a decade ago some Networking Industry vendor/people threw this idea of the holy " Application Aware Networking/Infrastructure " thingy and still today it seems of a popular school of thoughts among Network Engineers that follow the Flat Earth Theory.

What they often miss though is:

1. Business runs on top of business platforms, business processes and services as opposed to contrary belief on Applications.

2. Applications comes in different forms, shapes and Architectural choices - SOA, Microservices, Centralized, Distributed etc.

3. If you keep track of Applications or meta data, You must keep and maintain their state which means resources and state sync

4. You as networking engineer have never been taught about how to gather Application requirements

5. Your favorite OEM/Vendor doesn't provider you with any of good tools, procedures and methods to capture any of above information effectively.

6. Do you speak the language that Business folks understand ?

HTH...

A Network Artist 🎨

Few Questions You Should Ask Your fav Self-Driving Networks Vendor

Since everyone is talking about Intent Based or Data Driven Networks for a while, I spent some time recently going through work done by Cisco, Juniper, Apstra, Veriflow & Forward Networks in the Area of Intent Based Networking AKA Data Driven Network AKA Self Driving Networks.

So far seems like everyone is trying to solve the different sets of problems with some overlap. Also mostly they use ML/AI in some form or shape. But my assumption is Algorithms under ML/AI umbrella are proprietary (Secret Sauce) for most part with little details available publicly.

Also the common buzzword " Automation " would mean totally different set of things in such world IMHO. So In the mean while below are quick questions you can ask to your fav. OEM vendor guys next time you go for a product/training session around same :) to get more clarity.

> What they really mean by Intent Based Networking ? (Everyone has some different definition for this)

> How do they describe the Intent to the system ?

> How do they map Business Intent & Technology intent and describe it to system ?

> Does the system translate the intent into configurations/policies on it's own or they use some sort of policy language for admin to be used to describe Business and Technical intents to system ?

> What sort of checks that system has to verify described intent and returns feedback to admin ?

> Are there any dry run capabilities into the system ?

> How they maintain the consistency for the intent throughout the life-cycle - Plan, Design, Deploy, Verify, Operate & Optimize ?

> How Intent gets documented and updated over time ?

> How do you describe intent for things like Backup path etc. ?

> How do they create visualization for Intent to present to management & Network Architects ?

> How to modify Intent over the period and what would be the touch points ?

> How their Intent Based Networking is different from policy based network (Remember Promise Theory that ACI Works on) ?

> OEMs AI/ML/DL & Algorithm Details (I doubt they would be willing though) ?

> How do they control AI and ML since they can create their own algorithms and break this closed loop over time ? (Remember what happened with Facebook's AI attempt)

> How do they track changes in such networks such as created by AI/ML dynamically ?

> How does AI/ML understand if it's actual pattern change in network during attack or just traffic pattern change driven by an special event such as heavy load on billing systems during financial year end for example ?

> Do they use graph approach (By building Network Graph such as Link State Protocol Does) or they use relation approach (Such as describing links with properties ) across network components to describe intent ?

> Which Data model they follow to describe intent and push/change configurations ? (Also understanding Data Normalization Techniques & Data Model details will be key to understand support across multiple vendors )

> Do they support APIs to describe intent and to work with other systems as part of larger eco-system ?

> How do they deal with scale ? (Everyone has different sets of limitations here)

> How do they deal with mix of legacy networks & Cloud Networks in hybrid environment ?

> How do they handle Leaky abstraction & Grey failures ?

> How do they operate across multi OEM platforms with different HW/SW capabilities ? (Which essentially means they must form a eco system with selective set of partners as it's going to be an ongoing effort)

> Does the intent description part only takes care of configuration side of things or they even go further with Network Design as part of another abstraction layer ?

Let's park Telemetry related stuff of solution for a while which is another area to dig into in order to fit all pieces together.  :) (Maybe another follow up post)

HTH...
Deepak Arora
Evil CCIE

Data Centre Fabric Design Considerations

Let's continue the SDN series.

Fabric based Data Centre architectures are becoming more and more common these days. While I mentioned in my earlier articles that some of the terminologies and other stuff that you hear under SDN umbrella are not technically new, it still gives us ability to solve some of Business and Design problems that were hard to solve in past probably for different reasons.

While some of large players like Microsoft, Facebook, Linkedin, Google and Amazon built their DC fabrics using Open Source ideas to meet their Hyper-scale Data Centre requirements, most mid and large Enterprise still seem to be little far going down that direction considering it's not an easy task to begin with. While people might be able to get things working to an extent, but in most cases the solution doesn't look very clean.

So as an alternate they have options like using someone else's brain child. For example Cisco ACI, VMware NSX, Juniper Contrail , Nokia Nuage are some of products that are designed and built to cater same set of requirements.

While there is plenty of material available on Web where people suggest different reasons to claim why one vendor solution is better than another. While I am sure some of things might be true considering someone with hands on exp. around these products might have encountered interesting issues along the way, I was recently asked by one friend to share my suggestions to figure out which solution they should pick over another while putting my love aside for a given vendor ;)

So here is my quick list, It's not very detailed but still give you some pointers to help with thought process:

- Network based overlay (ACI) vs. Host based overlay (understand pros and cons of each approach)

- Would you need overlap between these two overlay models at some point , if so - would that require additional licensing, upgrades etc.

- How availability domains will be supported in solution

- What scale you would expect to hit down the line from control plane and data plane perspective 

- What sort of Orchestration and Automation your customer require and how those needs map with particular solution capabilities

- How controller to controller communication happens, what are pre-requisites and do they allow overlay tunnels to go across different domains

- How particular OEM is going to avoid bug disasters. In theory if you are running same CODE, hitting any bug would potentially bring entire controller cluster down and defeat the purpose of running controllers in cluster or HA per say

- How open or close the API support is (Open doesn't mean completely open)

- How strong the partner ecosystem is in terms of integration and how well it ties with your Orchestrator

- How well your overlay model integrates with rest of network and what approaches they have to suggest as OEMs

- Do they allow to integrate the solution with other OEM solution down the line. For example Overlays like VxLAN don't specify the control plane. So while two OEMs may support VxLAN as possible common piece they might be taking different approaches to build control plane or might have some vendor specific twist added

- How well the solution works under multi hypervisor vendor environment

- Learning curve involved with new solution 

- Integration with current NMS deployment

- How your DCI connects and integrates between DC-DR or DC-DC (Active-Active)

- How well your fabric handles situations like customer using DR on cloud

- Support for containers (Corner case)

- How well solution is able to tie the virtual and physical workloads

- How fabric protects east west traffic (Micro-segmentation)

- How you move your virtual/physical workloads from OLD Architecture to New fabric architecture

HTH...

Deepak Arora

Evil CCIE

Clos Fabrics AKA Spine & Leaf Architecture

Let's start the series with discussion of CLOS Fabrics AKA Spine & Leaf Architectures.

Now CLOS design is not fundamentally new, but most of the Network Engineers were not talking about it till recent times (Well...this is true to an extent). So as Network Engineer should you really care ?

Well you should start by asking why CLOS in first place ?

The major problem that CLOS fabric solves is about solving scalability issues. While scalability is a matter of context, it's not necessary that everyone needs or to be precise going too far about it.

Also CLOS fabric also doesn't define your Layer2 - Layer 3 boundaries itself. So you are pretty much dependent upon what works best for you from vendor implementation perspective while keeping your overall goal in mind. Now in theory Layer 3 Fabrics scale much better than Layer 2 Fabric. Here are some questions/Things you figure out about CLOS if you decide to go for it :

- What is the scale that you got to deal with ?
- What are technical and business requirements ?
- Your DC traffic is mostly east-west or north-south ?
- How you can minimize the state of the Core (Spine) to minimum ?
- How flooding works in your fabric ?
- How multicast is handled in fabric ?
- Where to define Layer2-Layer 3 boundary ?
- Your network is going to multi vendor now/In future ?
- How you gonna manage and monitor such large network ?
- How you gonna introduce security & Services such as Load Balancer ?
- How you gonna connect to external world ? (Border Spine Vs. Border Leaf) 
- Define you convergence requirements 
- You gonna need single or multi stage CLOS ?
- Your over subscription ratio ? (Usually 3:1 is good for most part)
- Understand your failure domains and impact they may have
- Do you need Spine to Spine or Leaf to Leaf connections to mitigate some of     
   failure scenario ?
- If you are going with Layer 3 fabric, is it going to be good idea to use 
   summarization ?
- EBGP vs IBGP (Also RR placement) in Layer 3 fabric ?


Even as an example, Cisco's famous buzzword these days ACI (Application Centric Infrastructure ) also uses Spine & Leaf design. It uses BGP EVPN (Some secret souce but soon EVPN will be there too) control plane and on top of which it uses VXLAN as Data Plane. So between Spine & Leaf (Single Stage) it uses Layer 3 fabric. The entire fabric is managed with a centralized command and control system called Cisco APIC Controller. With ACI you can go as far as 6 Spines at the moment and all services (e.g. load balancer), firewalls, external connectivity gets terminated on Leaf switches. For server redundancy (Bare Metal Or Virtual ) it uses our old friend Virtual Port Channel (vPC) but this time doesn't require directly connected interfaces among leaf switches for peer link and peer keep alive link functions. 

Cisco ACI is kind of build around another buzz word that you hear more often these days called SDN (Software Defined Networks). Now whether it fits into true SDN definition or not needs another discussion :).

In the mean while below is the list of URLs which you may find very handy to get started with CLOS:

http://packetpushers.net/podcast/podcasts/datanauts-011-understanding-leaf-spine-networks/

https://code.facebook.com/posts/360346274145943/introducing-data-center-fabric-the-next-generation-facebook-data-center-network

http://www.networkworld.com/article/2226122/cisco-subnet/clos-networks--what-s-old-is-new-again.html

http://searchdatacenter.techtarget.com/feature/The-case-for-a-leaf-spine-data-center-topology

http://searchdatacenter.techtarget.com/answer/Whats-the-best-data-center-network-topology

http://searchdatacenter.techtarget.com/feature/Data-center-network-design-moves-from-tree-to-leaf

http://www.excitingip.com/4490/distributed-coreleaf-spine-network-architecture-an-intro/

http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4448982&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F90%2F4359146%2F04448982.pdf%3Farnumber%3D4448982

http://etherealmind.com/which-network-topology/

http://packetpushers.net/network-topologies/

http://blog.ipspace.net/2014/04/security-in-leaf-and-spine-fabrics.html

http://www.thenetworkingdom.net/bgp-clos-networks/

http://thenetworksurgeon.com/cisco-spine-and-leaf-architecture-discussion-nexus-5500-vs-6001/

http://blog.ipspace.net/2012/04/full-mesh-is-worst-possible-fabric.html

http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p183.pdf

http://conferences.sigcomm.org/co-next/2013/program/p49.pdf

https://www.ietf.org/id/draft-ietf-rtgwg-bgp-routing-large-dc-09.txt

https://www.nanog.org/meetings/nanog55/presentations/.../Lapukhov.pdf

http://content.blubrry.com/packetpushers/Show_164-Cool_or_Hot-Lapukhov_Nkposong_s_BGP_SDN.mp3

http://www.juniper.net/us/en/local/pdf/whitepapers/2000565-en.pdf

https://cumulusnetworks.com/blog/routed-vmotion-why/

https://www.youtube.com/watch?v=nPKLe0M5yJU

https://www.youtube.com/watch?v=O8wU1qNlsyI

https://www.youtube.com/watch?v=fQ2l_v_53qQ

HTH...
Deepak Arora
Evil CCIE

How To Be Network Ninja In 21st Century

I have been asked so many times by Network Engineers right from starter level to Expert level people about how network industry is changing at rapid pace in last few years and questions like if certification and in particular CCIE holds any value any longer. I also spoke with couple of friends that I truly admire and are working in US , Europe & Australia to get feedback on how Network industry is evolving there.

Now to start with, following technologies are definitely picking up in some form or shape :

- SDX like (SDN - Software Defined Networks)
- CLOS/ Spine & Leaf Designs
- NFV (Network Function Virtualization)
- Virtualization ( In Areas like Network, Compute & Storage)
- Automation ( Chef, Puppet etc...)
- Scripting & Programming ( Python, Bash, Java etc...)
- Cloud Computing
- Network Visibility 
- Overlay Networks/Tunneling Technologies (VXLAN, NvGRE etc...)
- Network Modeling Methods
- API (Application Program Interface like REST )
- Understanding on Unix & Linux
- Big Data
- Active Active Data Centres
- Machine Learning
- Segment Routing 
- Containers ( Docker...)
- Deep Understanding of Applications Structures/Component & Life Cycle 

And last but not least deep understanding of protocols like TCP, HTTP etc...

But again the impact these may have on current network industry (What they call traditional networking now) may vary by large margin depending upon:

- Which part of the world you are living in
- How IT Industry is driven there and Network Industry in particular
- Which company you work for
- What are your personal/political views
- Company's IT Strategy & Road Maps
- Your current skill set & fears about these new technologies
- Is there any simulation tool to get familiar with these technologies
- What is the maturity level of given technology (RFC ?, New Model ? etc...)
- How you want to manage these solution (Afraid of Open Source ? Multi vendor   blame game ? etc...)
- Do you really have a good business case 

Now there are of course other factors including budget/cost, ROI, How to get your operational staff ready etc...

But hope you get the idea. In the coming series of posts I would express my personal opinions around all these but those articles are going to be semi technical rather being completely technical since I am more of a Pre-Sales guy now.

Regards,
Deepak Arora
Evil CCIE