On Wed, 18 May 2016, Lou Berger wrote:
That's why I said rib manager, i.e., the thing that is used to pass
routes between the protocols. Zebra is really there as just the slow
path fib manager.
Well, the OVSDB isn't managing the RIB, it's just acting as a data-store.
The zebra daemon is still doing route selection and further updating
routes in the OVSDB to mark which is the best and update the kernel. In
OPS, switchd picks up on that to programme the hardware, if there's
separate L3 forwarding ASICs.
Also if best path selection gets out of sync between OVSDB and zebra,
things will get really weird/bad.
We already have that issue. ;)
One nice aspect of having client protocol routes stored in a separate DB,
graceful restart of zebra is easier to implement, without client protocol
changes. OPS zebra has this now.
would have the benefit of not disrupting overall rib management
(including how VRFs and import/export works between protocols works) as
well as ensuring consistent FIB -- which is fairly important.
I'm willing to bet recovering from desynchronisation bugs (or any other
bugs in zebra that require it to be restarted) is a whole lot more
graceful with the "separate data store" model in OPS than in Quagga.
Currently in Quagga, restarting zebra requires restarting everything. To
allow graceful zebra restart would require modifying every client. OPS
implemented graceful zebra restart with changes only to zebra.
you mean make it so ovsdb is always required?
Indeed, that'd be a concern I have with a number of recent patches adding
new custom and semi-custom protocols to inside Quagga components.
should I take this to mean my recent patch?
I noticed it was adding another protocol. ;) That's not a problem of
itself. You need to get data out to support some use-case, and so you have
to add a protocol. You're not going to want solve the general case per se.
That's fine.
There is clearly a wider desire to export and modify state to other
agents. The issue for Quagga generally is that adding ever more custom
protocols, or various application/agent specific protocols over some
low-level structure protocol is not ideal. From prior experience in
Quagga, the maintenance overheads of protocols are not insignificant. They
can be hard to test - especially if they're protocols to agents that have
few or no free/open implementations.
Having one state-access protocol is preferable to having to many of them,
and having to maintain multiple sets of C glue between internal state and
protocols.
Even maintaining Zserv has been an issue. It has had (still?)
inconsistencies between client and server. It's had incompatible changes
made, intentionally and unintentionally. Etc. See also SNMP, and even the
kernel protocols.
I'm not sure we have the resources to maintain 3+ more different protocols
to extract state...
This sounds like QuaggaNG to me...
Not opposed to heading in such a direction, but it is a *massive*
re-architecture of quagga internals.
I think it's inevitable. People are working on it. People have worked on
it. Mostly behind closed doors it seems (OPS has been in the open, though
I hadn't raised it here yet). We've patches for some more focused state
access.
The thing is to do it just once and well though. Rather than have a bunch
of different protocols, each reliant on different APIs to different
low-level encoder libraries, and each offering access to different subsets
of Quagga.
Set out the requirements and criteria. Discuss. Pick the best match.
Update the internals *once* (however big a job that is, it's surely easier
than trying to do it for /several/ different protocols). Allow other
protocols to be built on top of that.
E.g., in OPS, the JSON/HTTP ReST client[1] and the vtysh based CLI client
both use the OVSDB protocol into the OVSDB data-store. OPS doesn't support
an SNMP agent, but it too could be built on that. So, an architecture that
separates state out, and decouples external-access protocols from Quagga
internals is quite possible, and such an implementation exists (for BGP,
OSPF and zebra anyway).
1. This means you can monitor and configure things with 'curl', using
PATCH commands. :) E.g., to fetch the config:
curl -s 'http://172.17.0.2:8091/rest/v1/system?selector=configuration' \
| json_reformat
# to update '/hostname' attribute, say:
curl --request PATCH \
--data '[{ "op": "replace",
"path": "/hostname",
"value": "curl-hostname2"}]' \
'http://172.17.0.2:8091/rest/v1/system?selector=configuration'
etc..
Note, JSON/HTTP ReST has some intrinsic limitations on more complex
updates, compared to the JSON-based OVSDB RPC.
regards,
--
Paul Jakma, HPE Aruba, Advanced Technology Group
Fortune:
Optimism is the content of small men in high places.
-- F. Scott Fitzgerald, "The Crack Up"
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
