Paul, see below
On 5/19/2016 4:48 AM, Paul Jakma wrote: > 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. Interesting. I didn't get that from reading the design doc -- should have read the code ;-) How does import/export work between protocols? -- that's all via zebra now >> 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. Sure, but now OVSDB restarts get really interesting. BTW Standalone routing tables (and RTMs) showed up in commercial routers that I know of in the mid 90s. >> 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. ;) Actually, we specifically didn't. The VNC code implements the BGP-VPN application, which is purely BGP. We do add the hooks to add remote forward protocols, such as OpenFLow, via a c api. Turning this into a DLL interface or exposing it via a message bus such as zMQ or schema such as capn proto are certainly possible - and would be good additions. The code is there for use by other developers at this point. The first piece that would be straight forward to add is inter-VRF route leaking/policy. Again no new protocols here, just some configuration (and related pointer passing). > 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. - Use case 1 is inter VRF route leaking with policy support - Use case 2 MPLS-based L3/L2 VPNs - Use case 3 NVO3 controller using openflow - Use case 4 NVO3 controller using some agreed upon message bus > > 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... isn't that what different routing protocols are all about ;-) >> 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, This is all good, but clearly a work in progress -- 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? Lou _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
