Network configuration archiving

Fri Oct 25 18:27:35 UTC 2013

The vendor config->abstract data (really structured data) is the point of
YANG definitions.  I think I'm correct but Tail-F's system works by
importing the YANG definitions from the router and it builds the CLI
interpreter based on those definitions.  The trick is getting the
standards bodies and vendors to support common definitions for common
protocols like they sorta have with SNMP.  So when I need to put a route
on a router it's the same common definition and I guess the pie in the sky
goal is then using common NETCONF syntax as well to do the configuration.
So the router itself is doing the translation into whatever native format
it uses, not someone having to write translation scripts which are a PITA
when vendor syntax changes, or some new feature is added, etc.

Phil 

On 10/25/13 11:03 AM, "Saku Ytti" <saku at ytti.fi> wrote:

>On (2013-10-25 10:22 -0400), Phil Bedard wrote:
>
>> There are companies like Tail-F who are trying to use things like YANG
>
>Tail-F is very cool, but it needs support for both direction.
>
>Abstract data -> Vendor Config    (easy problem, just agnostic ascii
>template)
>Vendor Config -> Abstract data    (hard problem)
>
>I don't think the latter is needed, why verify what is wrong in the
>config,
>either it is what you want it to be or it's something else, in which case
>you
>make it what you want it to be.
>The price of knowing exactly what to fix to bring it up-to standard is
>very
>high. It's definitely nice thing to have and necessary thing to have
>unless
>100% is from system.
>If 100% is from system, we can ommit the hard problem. To support new
>vendor,
>you just write simple new vendor-specific templates focusing on exactly
>just
>the subset of stuff your abstract data needs. Instead if you need to
>understand vendor config, you need to understand every nyance of it,
>vendors
>own parser gets it wrong, my chances are very small to get it right.
>
>
>-- 
>  ++ytti
>