On 5/19/2016 11:20 AM, Paul Jakma wrote: > 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. There are reasons to import routes not selected for routing too. I'm not sure what's in quagga today, but the new code shouldn't break current functionality.
> 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. persistence, upgrades and redundancy (hot/cold/warm) gets interesting and complex fast. >> 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 think we're just moving the API and problem -- but hopefully with a more scalable result. > (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? it breaks some of the existing routing protocols, e.g. ospfv6, rip, pim... > 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. I think this is a more viable/reasonable in the near-term. It'll also enables folks to get more familiar with the changes and implied architecture. But it does mean that others in the community may end up modifying the OPS code (perhaps to support the unsupported daemons), i.e., it's not just a downstream import... Lou > > regards, _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
