On Wed, 25 Nov 2015, David Lamparter wrote:
easily swapped out. The time needed to discuss the merits of one over
another is longer than the time to just support both.
Agreed, and anyway, different people will want different transports and
storage thingies. So should design to at least allow others to more easily
write code map Quagga's state to and from such.
d1- choosing a method of schema representation
d2- implementing a chosen schema
For d1, YANG seems to be the current method. However, it is rather
complex and not that well suited to match an internal representation of
software written in C like Quagga.
Agreed.
While it may be necessary to adapt a lot of the routing code in order to
provide a good abstraction to its state, rewriting the internal structure
of the routing code should be avoided.
component (which could be written in a more high-level language). That
component could either be in-process (using something like Swig
Swig is interesting alright.
implementation choice. That said, it doesn't neccessarily imply much
for the actual schema, it just decides how that schema works out in
internal operations.
If rewriting the internal structures is to be avoided, then the schema is
already decided by the routing code, mostly. Just have to see how much can
be described in data (and bloat is a consideration too).
P.S.: I do not currently have the time to engage on this thread since my
priority is on acquiring useful real-world datapoints on this topic (and
I haven't seen that in this thread so far ;). I can probably do a more
interesting report in a few months. That said, again, please ping me if
you're writing code.
OpenSwitch has an adapted version of Quagga which retrieves configuration
state from and publishes other state to OVSDB:
https://git.openswitch.net/cgit/openswitch/ops-quagga/
There is a schema, an extended version of the OVSDB format:
https://git.openswitch.net/cgit/openswitch/ops/tree/schema/vswitch.extschema
The modifications to Quagga are pretty direct and unabstracted.
What I (and/or others in HPE Networking) would like to do is to abstract
Quagga's internal state and make it available in a clean, structured way
so that plugins can easily be written to support things like the OPS way,
or Daniel's relational database, or whatever, in addition to the
traditional Quagga things that have to be supported (CLI and its closely
associated config files).
If no one else is doing it, I'm fairly sure we're going to start writing
that code, but this thing is 'big' and high-impact enough that it needs
thrashing out in public first and getting consensus early to have a chance
of success / minimise risks, I suspect.
regards,
--
Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A
Fortune:
I guess the Little League is even littler than we thought.
-- D. Cavett
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
