On Thu, 19 May 2016, Lou Berger wrote:
How does import/export work between protocols? -- that's all via zebra
now
Clients listen for changes to OVSDB route tables. They pick up the routes
they want to import, and they should only import the routes Zebra has
selected.
I'd have to double check if one route is stored for the source, and one
for the version zebra selects, or if zebra is just updating the selected
status.
Sure, but now OVSDB restarts get really interesting.
There are tools to dump OVSDB data and load it up again though. So you
potentially don't need much code. Dump the OVSDB. Restart the ovsdb
process. Reload.
The OVSDB library the client's are using already keep shadow state, not
sure how well it supports reconnection and resynching.
BTW Standalone routing tables (and RTMs) showed up in commercial routers
that I know of in the mid 90s.
Ack. It's an arch already long in use, I gather. Agreed. ;)
Actually, we specifically didn't. The VNC code implements the BGP-VPN
application, which is purely BGP.
Aha. Cool.
I'm not sure we have the resources to maintain 3+ more different
protocols to extract state...
isn't that what different routing protocols are all about ;-)
Hey, it's just software... ;).
It's just a "full mesh" of protocols into state, each with their own
C-glue to maintain, is quite a high overhead. Export the state /once/ to
something with good tooling and protocols, and then build further clients
on top of that is more decoupled.
That might also allow faster development, by reducing the need for people
to hack state-access protocols into core code.
(I've said this in other emails before I think, but one of the core issues
behind some of the jamms is insuffcient modularisation, and too tightly
coupled code).
This is all good, but clearly a work in progress
In what sense?
This code is going out in an OPS release soon, and commercially supported
at some point thereafter.
From the POV of having a patch to add to Quagga. Yes, there's some
cleaning up to do, and a few different approaches. At a minimum though, I
can bring a diff that adds the #ifdef'd support for OVSDB for BGP, zebra
and OSPFv2 straight out of OPS.
-- are you suggesting
that (a) we consider how to get this into quagga long term, or (b) that
all work on quagga release stop until we have a work solution that
supports such a re-architecture
In an ideal world, I'd want us to agree on one state-access protocol, and
have further protocols build on that, inc. a CLI implementatoin. I'd
suggest OVSDB is suitable for that and is already implemented for 3 of the
daemons, + vtysh/CLI and HTTP clients. However, we can have a discussion
and figure out an architecture that works for everyone. And we could work
out a long term plan.
In a less than ideal world, I'm suggesting that the OVSDB support for BGP,
OSPFv2 and zebra be considered for inclusion as it roughly is now in OPS,
even in its ifdef'd form, on the "get it in first and iterate later" basis
that seemed to be proposed on the call the other day. Alongside all the
other forms of state access people want.
regards,
--
Paul Jakma, HPE Aruba, Advanced Technology Group
Fortune:
And that's the way it is...
-- Walter Cronkite
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
