The Multi-Domain Architecture Mind Set

I'm a self-confessed pizza junkie and I virtually never run into someone that will say, "no thanks" to a quality slice.  A friend once told me, "the great thing about pizza is that when it's good, it's really good.  Plus, even when it's not the greatest, you're still eating pizza so things aren't all bad."

That brings me to a story about how I found myself laughing at an unlikely, and ironic, parallel between the dysfunction of a group of people either ordering pizza or modernizing their network.  

Challenge of Legacy Networks

Our traditional way of buying products has been buying to justify a replacement product. This lifecycle approach has been siloed to their own pieces of the infrastructure, which creates a lot of challenges. For example, when we need routers, we buy the next model. When we need firewalls, we buy the next solution that meets our new requirements, etc. Then we plug in the new device, configure, ensure users can access the network and away things went. 

Another issue with legacy networks is the development has been occurring in a silo as well. For example, the data center has gone through the advancement process while the campus didn't evolve much. The data center had traditional routing with the 3-tier design, then to fabric path, and now we are consuming the Leaf-Spine design based on VXLAN with 2-tiers. Due to Software-Defined Network (SDN), the different domains are now progressing to bring together a unified, automated architecture.

The problem with this legacy routine is that all the different silos in our enterprise are acting individually so we end up with a network that looks like a "Franken Pizza." Each of us has our own biases about what makes a great pizza and what a great network looks like.  Much like, how we all work in our own siloes. This siloed approach also creates a highly manual administration, slow deployment process, limited management capabilities, inefficient diagnostic and troubleshooting processes, and fails to keep pace with the agility process our networks need today.

To move away from the legacy mindset and make way for the end-to-end Software Defined Network (SDN), we should look at the infrastructure as a multi-domain architecture. We should utilize the vision SDN is bringing as a way to break down the silos and bring a common framework to bring about a modern network. This new approach will stitch together the end user to the application, wherever it lives, in order to reduce complexity, add agility, and increase security.

The Multi-Domain Architecture

The Patent for Multi-Domain Network and Method for Multi-Domain Network states "Each domain of a multi-domain network collects intra-domain routing information relating to that domain and makes a reduced view of that information available to other domains of the network, and in which each domain of the network uses its own intra-domain routing information together with the reduced-view routing information from the other domains to form a logical view of the network so as to enable that domain to make an end-to-end route selection decision." [1]

These domains are not unfamiliar to us, they are the Campus, Branch, Data Center, Cloud, Security, Service Provider networks, etc. Today's enterprise networks should be moving towards this multi-domain vision and with a layer on top that consists of telemetry and automation to create an end-to-end network for users and applications. Multi-domain is about a unification with SDN and automation, making it one architecture.

Equally, the different networks we are managing are changing at a faster pace than we are accustomed to. End users don't just plug into the network at an office, they are mobile with different means to connect to applications. The users need access to applications in the cloud, our data center, or even a co-location facility. While the IT team has to manage this diverse sprawl with a team that is spread out as well.

In order to manage these changes there is a tremendous effort going on to modernize the network. Implementing Software-defined Networks (SDN), end-to-end segmentation, the coming tidal wave of IoT, and the adoption of cloud are all leading the change, challenging us to adopt a different method of architecting, designing, and buying. In order for an organization to modernize and stay relevant the drive to design a multi-domain architecture should be fundamental. We must commit to moving towards intently building the network architecture that heralds in the multi-domain era and give us an architecture that is beautifully stitched together like a pepperoni pizza.

If you look at the next generation programmable networks such as SD-WAN, cloud network, and Network Function Virtualization (NFV), etc. the concept of multi-domain will give us the ability to manage, automate, push policy, gather intelligence, segment, and secure the infrastructure. It is about bringing the pieces together and managing them in an orchestrated fashion so access to applications is easily consumed in a secured method.

On the Q3 FY2019 earnings call for Cisco, Chuck Robbins iterated "We are building the only integrated multi-domain intent-based architecture with security at the foundation. This is designed to allow our customers to securely connect their users and devices over any network to any application, no matter where they are…" 

Think of the importance of this strategy if an organization was trying to get to that vision of a well-orchestrated, multi-domain infrastructure but continues to work in a siloed fashion. What impact would choosing siloed solutions across the organization have on our ability to get to the vision? The impact would continue to keep an organization building out the "Franken Pie" and create a lot of hardships of getting, if ever, to our destination.

Software-defined networking in a multi-domain architecture is the future for a reason; it gives us a platform to reduce the amount of time we spend on repetitive tasks, make changes to both the network and its security policy quickly and programmatically, and move traffic optimally as applications, the network, and network conditions change.

The challenge of fulfilling this multi-domain architecture starts with the lack of vision and planning. The complexity of our campus, data center, and cloud networks extending across geographies and domains makes it seem like a Herculean effort, but it doesn't have to be. With a plan and clear understanding of the Original Equipment Manufacturers' (OEM) solutions we can start building it out.

Now let's take a look at how we start this process to build our multi-domain architecture.

5 Steps to Getting Started Towards a Multi-Domain Architecture

First, start by drawing out the concept using a high-level diagram of where you are today vs where you are going. With cross-functional representation, define what you want; what optimal looks like. Putting this vision on paper gives everyone a common goal to works towards as well as lets them understand what requirements they need to have listed when choosing products. 

Second, outline the business needs, the IT needs, and the barriers we face in getting to where we want to be. We build these out to keep the IT and Business aligned working towards the same objective when looking at solutions. Build consensus amongst everyone that gets a say in the procurement process and make sure everyone understands what you want to achieve and empathically address their concerns. Take for example the image below:

The construction for this will be more than just what the security team needs or what new access points we are putting in the new building, it will include success criteria and strategy. It will also include a structure to align what the business is doing and how IT will be a part of enabling the success of the business, thus becoming a strategic partner for that success. This will give the team a common framework to build upon.

Third, understand what the OEMs are doing and how they are building out a multi-domain architecture to give you the ability to reach your goal. Then determine, with your technical and business requirements, which multi-domain architecture is going to give your business the best competitive advantage. This will take time and effort, but it will pay dividends over time.

Fourth, consider the ancillary pieces that will impact your ability to consume this modernization effort. Capabilities like automation and end-to-end visibility are tremendously capable of not only helping roll out this multi-domain architecture but also enhancing our ability for operations after implementation on Day 2, Day 3, etc. 

Finally, persistently work towards the goal of building your multi-domain architecture. Approach the project with an infinite mindset.  That is, set the expectation that the goal is to have a network that scales and adapts to support your business, not to deploy a bunch of hardware and/or software, raise a flag, and say, "we're done!" 

If our goal is to implement and keep up with an evolving landscape, there is no time more than now that the technology decisions we make today will affect the outcome for multiple years. Every decision we make will either bridge the gap to get where we need to be or hinder the process to get there. The goal is for your network to be great from now on…improving some every day.

[1]Multi-domain Network And Method For Multi-domain Network - Harmatos, Janos

Janos- Istvan- Juttner- Alpar - http://www.freepatentsonline.com/y2010/0061231.html