Hi all,

This set of patches contains adaptations to BGP daemon, to bring a new API of 
management, based on capnproto protocol.

The API implementation relies on capnproto protocol for data serialisation, 
since it is able to receive and send simple and complex data structures. The 
emission relies on on  an other protocol called zeroMQ, which is a fast data 
exchange mecanism, that is very efficient. The pairing of both technologies 
offers BGP, but also the whole QUAGGA framework, a fast and easy mecanism for 
management, without having to rely on vty. 
Note that capnproto owns its own code generator. Based on a scheme file, it is 
able to generate code so that the application can be hidden of the internal 
complexity of capnproto generated code. As example, it is possible to carry in 
messages some structures like prefixes or ip addresses. As of today, 
unfortunately, there is not yet any publicly available tool that generates c 
code, based on the proposed scheme files available in that patch series ( 
qzc.capnp can with standard c-capnproto compiler, but not bgp.capnp). So 
currently, the code has been hardset, and the scheme file is maintained along 
with the generated source code. More information about capnproto and zeromq on 
respective web sites : http://capnproto.org and http://zeromq.org. 
The API implementation does not limit to capnproto/zeromq protocol, but can 
host a wide variety of other RPC protocols. 

The BGP API implemented currently offers capabilities for configuring the main 
data structures that can be found on BGP: BGP start, BGP instances, BGP peers. 
Basically, with a capnproto interface, one can create, configure, delete the 
whole BGP. This API implementation relies on the BGP VRF extension used in 
conjonction with VPNv4 configuration. By this sentence, the intention is to use 
that API to dynamically provision in BGP networking information about 
MPLS/VXLAN tunnels. As such, it is also possible to configure VRF import 
processing. In addition to configuration, BGP API offers a notification entry 
so that the remote manager can receive notifications from BGP, when an event 
occured. That can be a peer that is being shutdown, or the notification that a 
new entry has been received. BGP API finally permits doing exploitation, since 
an algorithm has been put in place so as to iterate on the list of entries 
contained in VRF RIB tables.

Note also that a build dependency has been added on zeromq and c-capnproto. You 
have to force configuration in order to enable the usage of capnproto with the 
following: --with-ccapnproto --with-zeromq. While zeromq is usually available 
in many distributions ( however a recent version is needed - tested on zeromq 
4.1 - ), it is not the case for ccapnproto. This library is officially 
maintained : https://github.com/opensourcerouting/c-capnproto.

Note also that in order to apply this patch, you will need to get also 
following patches before:
https://lists.quagga.net/pipermail/quagga-dev/2016-October/016266.html
https://lists.quagga.net/pipermail/quagga-dev/2016-December/016504.html
https://lists.quagga.net/pipermail/quagga-dev/2016-October/016349.html
https://lists.quagga.net/pipermail/quagga-dev/2016-October/016375.html
https://lists.quagga.net/pipermail/quagga-dev/2016-October/016382.html


Currently, In order to manage quagga framework by using capnproto, it is needed 
to have an other capnproto implementation able to communicate with the various 
quagga daemons, and using the same capnproto scheme files. 

Cheers,

Philippe


_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

Reply via email to