[195463] in North American Network Operators' Group
Re: (Network Orchestrators evaluation) : tail-f vs Anuta vs UBIqube
daemon@ATHENA.MIT.EDU (Raymond Burkholder)
Thu Aug 10 13:15:57 2017
X-Original-To: nanog@nanog.org
X-OneUnified-MailScanner-From: ray@oneunified.net
From: Raymond Burkholder <ray@oneunified.net>
In-Reply-To: <CALb2afOY7vzRwwxNb_f=KwBU6KoH1wtS6nFL+bkNmX1_RaJ9KQ@mail.gmail.com>
Date: Thu, 10 Aug 2017 14:15:44 -0300
To: Kasper Adel <karim.adel@gmail.com>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
> On 9 Aug 2017, at 22:01, Kasper Adel <karim.adel@gmail.com> wrote:
>=20
> 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 pr=
obably depend heavily on your budget and network size and abilities. And w=
hether you prefer open source, closed source, or need some mix of home grow=
n solutions.
On the heavy duty commercial side, I have heard the name Nuage quite a bit,=
but no personal experience.
>=20
> 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 =
levels.=20=20
In my mind, OpenDaylight is more of a low level tool for =E2=80=98telling p=
ackets where to go=E2=80=99. And is open source. But useful for orchestra=
ting packet movement within overall infrastructure. The other tools mentio=
ned 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 a=
bout 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 hav=
e a =E2=80=98wish it could do this=E2=80=99 style of list?
>=20
> 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.
>=20
> My humble thoughts are given below and i would appreciate getting
> 'schooled' on what i need to ask the vendors:
>=20
> 1) Are they Model driven : But i still don't know how to evaluate that.
The latest buzz word I have heard is =E2=80=98intent based networking=E2=80=
=99. Again that is low level packet handling and infrastructure provisioni=
ng. And how well does it integrate with IPAM, DNS, LAN, WAN, security, mon=
itoring, telemetry, alarming, resiliency, =E2=80=A6 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 d=
esigned for), and where ECMP is a desired feature, and where failures/upgra=
des/maintenance/change occurs, it would be nice to have flows routed based =
upon not only source/destination address/ports, but also on link utilizatio=
n. Which requires integration with interface and load statistics. There a=
re some linear programming models around which help to turn this into a dis=
tributed 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 =E2=80=94 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 a=
s you encounter unique scenarios.
> 4) Can they work/orchestrate between CLI devices and Non CLI devices (SNM=
P)
As someone said recently, SNMP is very popular, but may be waning in certai=
n use scenarios. There may be other ways around this problem.
> 5) How flexible are they to support different Vendors (Cisco, Juniper,
> some-weird-firewall=E2=80=A6etc)
If you need vendor supported solutions, then the field narrows somewhat. O=
n 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: trad=
itional routing / switch protocols, new fangled open flow style packet mana=
gement, device configuration management, orchestrating upgrades/migrations/=
repairs, telemetry/monitoring, alarm management =E2=80=A6 and orchestrating=
all the bits and pieces to minimise =E2=80=98touch=E2=80=99 as network ele=
ments are changed.
Raymond Burkholder
https://blog.raymond.burkholder.net
--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
