(Network Orchestrators evaluation) : tail-f vs Anuta vs UBIqube vs OpenDaylight
Hi, This is not a vendor bashing thread. 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. Other than the obvious, which is to try them out, i wonder what else is important to consider/watch out for. We are presented with 3 different vendors and even OpenDayLight was considered as the open source alternative. 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. 2) Do they parse Cisco/Juniper CLI or they are limited to SNMP and YANG. 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. 4) Can they work/orchestrate between CLI devices and Non CLI devices (SNMP) 5) How flexible are they to support different Vendors (Cisco, Juniper, some-weird-firewall...etc) thanks, Kim
Re: (Network Orchestrators evaluation) : tail-f vs Anuta vs UBIqube vs OpenDaylight
> On 9 Aug 2017, at 22:01, Kasper Adel 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 solutions. 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 levels. 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 https://blog.raymond.burkholder.net -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: (Network Orchestrators evaluation) : tail-f vs Anuta vs UBIqube vs OpenDaylight
On 10 August 2017 at 02:01, Kasper Adel wrote: > Hi, Hi Kim, > This is not a vendor bashing thread. > > 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. If you don't have much in house software expertise buying an off the shelf solution with support could be the best bet for you. ODL is aimed more at somebody who wants to "roll their own" solution as it's really giving you a unified southbound API to your devices but you still need to connect with the ODL via its northbound API in order to orchestrate your tin really fluently. This will require a lot of in house development work (probably more than you want). Also this is “just” (albiet a powerful one) an API to your network. It won’t act as a single source of truth, it’s not a data store, or an IPAM, or an NMS etc. Anuta seems quite good, of all the ones you listed in the subject line I'd recommend that one. We had a demo of Anuta NCX and I was pretty happy with it, it's vendor neutral with support for the big names already built it an you can write Python plugins to extending support to any weird vendor kit you might have lurking in a remote dusty PoP, they also take feature request if enough customers have vendor X they’ll add support for it. It is also semi-service orchestrated, you can define “services” yourself and config templates and push them out to devices. I quite liked it, I'd recommend you get a demo if you want an off the self-product that is vendor neutral with support. It ticks those basic boxes (probably more but I can’t remember as we didn’t choose it – not because it was flawed, it just wasn’t what we needed for the project we had in mind). Like ODL it is just for mass configuration and essentially and zero touch provisioning. You need to glue it to the rest of your OSS stack probably via the API. Tail-f - seeing as they were gobbled up by Cisco, do you mean whatever the Cisco product is called now, NSO I believe (Network Services Orchestrator). We had a meeting with Cisco a while back to arrange a demo, at the time it was very Cisco focused however I think it has become more open (in that it is still a closed source product but more network device vendor agnostic). Don’t know UBiqube – I’ll have a read up on it, thanks! > Other than the obvious, which is to try them out, i wonder what else is > important to consider/watch out for. As mentioned above, get something with an API, if you have multiple systems internally for BSS and OSS, try to move towards only having systems with APIs so that in the long term when say the BSS system accepts an order it can push an update to your OSS stack which configure a port on an edge router ready for that customer to connect to, and connects to your NMS API and pre-emptively starts to graph the port; all that jazz. Service orchestration is more than just automating config deployment which some people seem to forgot, or focus too much on, the service wrap is also very important (after accepting an order for a new CPE from a customer, and having fired the order over your suppliers API, in the response from the supplier with the new CPEs serial number, that needs to go into your asset database and be marked against that customer and the end site it’s being shipped to etc). Flexible products with a standardised API. > We are presented with 3 different vendors and even OpenDayLight was > considered as the open source alternative. NAPALM was already mentioned as an open source alternative. If you want to get your hands a bit more dirty consider Ansible or SaltStack (both of which can be used with and without NAPALM but generally you want to use them with NAPALM) as they are both open source and free to use but you can pay for support. We also looked at Blue Planet from Ciena, it’s an impressive product with some big name customers. It also has a big price tag as it’s really for large deployments. We didn’t go with it because we wanted to start (very) small trials and build up. > 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. By model driven do you mean like YANG models to infer the configuration state, or model driven from a service perspective? Anuta NCX, Blue Planet, Tail-F/NSO, ODL all have support for YANG models if you meant YANG. Anuta and NSO will let you create “services” which can be config templates that are deployed as a whole and verified, if you mean “service” model driven. > 2) Do they parse Cisco/Juniper CLI or they are limited to SNMP and YANG. If you have IOS devices you NEED a product that supports IOS CLI. IOS is a pain in the backside to automate and the CLI is the only really way of doing it sadly. > 3) If they do parse, we want to che
RE: (Network Orchestrators evaluation) : tail-f vs Anuta vs UBIqube vs OpenDaylight
Haven't looked at Cisco DNA yet? -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Kasper Adel Sent: Wednesday, August 9, 2017 8:02 PM To: NANOG list Subject: (Network Orchestrators evaluation) : tail-f vs Anuta vs UBIqube vs OpenDaylight Hi, This is not a vendor bashing thread. 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. Other than the obvious, which is to try them out, i wonder what else is important to consider/watch out for. We are presented with 3 different vendors and even OpenDayLight was considered as the open source alternative. 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. 2) Do they parse Cisco/Juniper CLI or they are limited to SNMP and YANG. 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. 4) Can they work/orchestrate between CLI devices and Non CLI devices (SNMP) 5) How flexible are they to support different Vendors (Cisco, Juniper, some-weird-firewall...etc) thanks, Kim
