> On 9 Aug 2017, at 22:01, Kasper Adel <karim.a...@gmail.com> wrote:
> We are a group of networking engineers  less experience with software) in
> the middle of the process of procuring a network automation/orchestration
> controller, if that is even a good definition and we are clueless on how to
> evaluate them.

There are quite a number of vendors out there.  And what you select will 
probably depend heavily on your budget and network size and abilities.  And 
whether you prefer open source, closed source, or need some mix of home grown 

On the heavy duty commercial side, I have heard the name Nuage quite a bit, but 
no personal experience.

> Other than the obvious, which is to try them out, i wonder what else is
> important to consider/watch out for.

When relating this email message to your other message, you may need to be 
thinking about your network automation at a number of different conceptual 

In my mind, OpenDaylight is more of a low level tool for ‘telling packets where 
to go’.  And is open source.  But useful for orchestrating packet movement 
within overall infrastructure.  The other tools mentioned in the subject line 
are probably closed source and lock you into their way of thinking.

To be overwhelmed with SDN style stuff, visit https://www.sdxcentral.com to see 
if some enlightenment can be found.

But as you mentioned in your other message, you may be concerned not only about 
packet management, but you may have a need to deal with a heterogenous 
environment of devices, which the applications in the subject line may or may 
not easily work with.

You may need to integrate a number of different tools together.  Do you have a 
‘wish it could do this’ style of list?

> We are presented with 3 different vendors and even OpenDayLight was
> considered as the open source alternative.

A big question is how well do they integrate with other automation tools?  
Vendors like to say they have RESTful interfaces and such.  Which means you may 
need to create a lot of your own glue.  Which may or may not be a good thing, 
depending upon time and skill sets.

> My humble thoughts are given below and i would appreciate getting
> 'schooled' on what i need to ask the vendors:
> 1) Are they Model driven : But i still don't know how to evaluate that.

The latest buzz word I have heard is ‘intent based networking’.  Again that is 
low level packet handling and infrastructure provisioning.  And how well does 
it integrate with IPAM, DNS, LAN, WAN, security, monitoring, telemetry, 
alarming, resiliency, … Which, as I write this, reminds me of another layer of 
sophistication: automatic load levelling.  For example, when building Openflow 
style networks (which OpenDayLight is designed for), and where ECMP is a 
desired feature, and where failures/upgrades/maintenance/change occurs, it 
would be nice to have flows routed based upon not only source/destination 
address/ports, but also on link utilization.  Which requires integration with 
interface and load statistics.  There are some linear programming models around 
which help to turn this into a distributed packet management solution.

Is anyone on this implemented solutions like that?

> 2) Do they parse Cisco/Juniper CLI or they are limited to SNMP and YANG.

Gets in a Napalm style configuration management  — open source.

> 3) If they do parse, we want to check if they'll hold us by the balls if
> the current parsers need to be updated, i.e: can we change the code
> ourselves and add new features to be parsed.

Can you work with open source?  Then you get to contribute back solutions as 
you encounter unique scenarios.

> 4) Can they work/orchestrate between CLI devices and Non CLI devices (SNMP)

As someone said recently, SNMP is very popular, but may be waning in certain 
use scenarios.  There may be other ways around this problem.

> 5) How flexible are they to support different Vendors (Cisco, Juniper,
> some-weird-firewall…etc)

If you need vendor supported solutions, then the field narrows somewhat.  On 
the other hand, there are tool sets available which provide good baseline 
coverage, while allowing you to open the hood and get your hands dirty.

Anyway, it sounds like you need to think about many different things:  
traditional routing / switch protocols, new fangled open flow style packet 
management, device configuration management, orchestrating 
upgrades/migrations/repairs, telemetry/monitoring, alarm management … and 
orchestrating all the bits and pieces to minimise ‘touch’ as network elements 
are changed.

Raymond Burkholder
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Reply via email to