Hi All,
Those of you that use NETCONF and YANG (or something similar [1]), how
are you (or are you not?) "managing" that process? Just pushing out
config is the tip of the iceberg for most networks looking to automate
operations...
A classic example: I need to bring up a new eBGP session on a rou
I forgot to say, I'm looking at vendor agnostic ways to approach this
using open standards.
Cheers,
James.
Hi James,
First off, it’s really important to remember that NETCONF and YANG are just
tools - they don’t make up a whole NMS, which is what I think you are trying to
describe. YANG is a data modelling language that defines the schema for data of
a device’s management plane; and NETCONF is one o
On 25 September 2015 at 09:46, James Bensley wrote:
> Cheers,
> James.
Got side tracked and never actually said, thanks for your time and input :)
Cheers,
James.
On 23 September 2015 at 03:07, Rob Shakir wrote:
> Hi James,
>
> First off, it’s really important to remember that NETCONF and YANG are just
> tools - they don’t make up a whole NMS, which is what I think you are trying
> to describe. YANG is a data modelling language that defines the schema for
On 25/09/2015 09:46, James Bensley wrote:
> I'm looking to build a tool that is vendor agnostic
Along the lines of e.g. https://github.com/spotify/napalm
?
Nick
On 25 September 2015 at 10:19, Nick Hilliard wrote:
> On 25/09/2015 09:46, James Bensley wrote:
>> I'm looking to build a tool that is vendor agnostic
>
> Along the lines of e.g. https://github.com/spotify/napalm
>
> ?
>
> Nick
Hi Nick,
I watched the Spotify talk at NANOG and that was one of th
> Agreed, networks are so far behind server and application development
> and automation in my opinion. Whilst I have seen a dozen presentations
> from operators or hosting providers, content providers etc on how they
> have automated zero-touch-provisioning or automated service
> deployment, thes
On 25/09/2015 14:14, Neil J. McRae wrote:
> On the network side each individual atom is simple enough to automate
> (but rarely provides any value) but the area we have completely failed
> as an industry is pulling those atoms together as a set of services or a
> capability outcome, mostly down to
On September 25, 2015 at 15:45:16, Nick Hilliard (n...@foobar.org) wrote:
> it's easy enough to complain about tools and constructs not being there,
> but there's another fundamental problem, namely that the config semantic
> requirements of the network are complicated relative to the simplicity
That's why we need to take this back from the vendors so that we don't have
that mess - or atleast less mess - oh and no openconfig support then your kit
won't be deployed into the network - great news on Junipers work - they have
really got this and are doing a great job.
Sent from my iPhone
11 matches
Mail list logo