Paul, Lots of really interesting stuff here. Can you clarify the intent of your mail? I read it as an intro to OpenSwitch use of quagga, until the last paragraph which implies it is a submission -- but not in a usable form.
Thanks, Lou PS I'm personally tracking this work and have even tried it out on hardware... On May 18, 2016 5:37:05 AM Paul Jakma <[email protected]> wrote: > Hi, > > HPE Networks^W^WHPE Aruba have been working on the OpenSwitch project for > a while. It was launched as a public, open-source project late last year, > and is in the process of becoming a Linux Foundation project. OpenSwitch > exists to build a Linux based, open-source operating system for L3 > switches and routers. > > OpenSwitch uses an OVSDB based architecture to tie together its > components. OVSDB is the embedded database from the OpenVSwitch (OVS) > project. The OVSDB core provides a JSON-encoded, Pub/Sub RPC protocol and > is described in IETF informational RFC. Additionally, there are ovsdb* > command-line tools to interact with and monitor changes to an OVSDB > instance. See the diagramme in: > > http://openswitch.net/documents/user/architecture > > This architecture allows functionality to be distributed across small > components, while still providing unified access to their state, and > allowing state and function to be kept separate. > > OpenSwitch (OPS) is using Quagga for BGP and OSPF. Quagga in OPS has been > adapted to store and retrieve its configuration state to and from the > OVSDB, as well as its routing state. The vtysh CLI has been adapted to use > the OVSDB, and the modern and well-defined schemas and protocols it > provides, to provide the traditional UI. There is an additional JSON/HTTP > based ReST API, again going via the OVSDB. > > The advantages of this architecture are: > > * Modern, well-defined and general protocol to interact with Quagga > components, via the OVSDB JSON/PubSub RPC protocol (not HTTP). > > * vtysh based on this architecture, along with other interfaces such as a > JSON/HTTP ReST API. > > * The ability to configure Quagga components either via the traditional > CLI like configuration, or OVSDB, or the ReST API. > > * The UI is *out* of the protocol daemons - e.g. the "show ip bgp" > table-walking command does /not/ cause bgpd to have do anything. > Instead, the UI just talks to the OVSDB. > > * Separation of state and function makes things like graceful-restart of > daemons much easier (e.g. implemented for zebra). > > - Separation of state from function also will make it easier to further > sub-divide existing daemons into different processes, e.g. this > infrastructure could be built to run the BGP LocRIB handling in a > seperate process to peer-facing BGP protocol IO. > > * Tight integration with other open-source networking components via the > OVSDB, with a cohesive UI to all. E.g. OpenSwitch also has adapted > Vincent Bernat's LLDP, and HPE Aruba have contributed their own > technologies. > > The code is available at: > > http://git.openswitch.net/cgit/openswitch > > The Quagga modifications are in: > > http://git.openswitch.net/cgit/openswitch/ops-quagga > > and come with design documents and extensive tests. > > The OPS Quagga version is based on 0.99.24.1, and the diff to that version > of Quagga is: > > > http://git.openswitch.net/cgit/openswitch/ops-quagga/diff/?id=master&id2=vendor&context=6&ignorews=1&dt=0 > > HPE Aruba have a large team of people working on OpenSwitch generally. HPE > Aruba would be keen to get this technology upstreamed. In which event, HPE > Aruba engineering would be able to do further work on Quagga upstream > first. > > The diff above may contain other changes. Some work is needed to separate > out the non-OVSDB stuff, to reconcile some work that was done by > copying-and-modifying existing files, and to move the old telnet UI to > seperate files and make it a compile time option for backward > compatibility. > > Also, to try do the split-brain thing, [email protected] would probably want > the code split into a series of logical commits, and the interfaces > generalised a bit, along with other issues. However, based on the > discussion on the Quagga monthly call yesterday, it seems appropriate to > post this contribution now and ask to have it considered as it is now > (sans minor tidy-ups as in previous para). > > regards, > -- > Paul Jakma, HPE Aruba, Advanced Technology Group > Fortune: > Reality -- what a concept! > -- Robin Williams > > _______________________________________________ > Quagga-dev mailing list > [email protected] > https://lists.quagga.net/mailman/listinfo/quagga-dev > _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
