Dear all,
In complement to our TE works already submit, we would implement the BGP
Link State extension (see
https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution). For
that purpose, we need inter-process communication with OSPFd and ISISd
process. Same needs are also necessary to implement Path Computation
Element (PCE - RFC 4655). The primary goal is to exchange Database
contains, in particular OSPF LSA and IS-IS LSP including TE information.
But, such exchange could be useful for other purpose like hot restart,
monitoring ... OSPF already provide such facility through the OSPF_API,
but it is dedicated to OSPFd only and we need to generalize it to other
Quagga daemon. From this API, we would take the capabilities to send
commands to a given process and get back some information, synchronously
(answer to the command) or asynchronously (LSA/LSP update).
We study several option for the implementation and would get some advise
from the community before really start coding. Up to now, we have
identify 4 options:
1/ Extend Zebra protocol. Vincent Jardin already point me that it is not
a good option as the Zebra protocol, and Zebra daemon are heavy
solicited for VPN and adding more traffic will have a bad effect on
performance. But, as it will used in a particular case, perhaps it is
not an issue.
2/ Move OSPF and ISIS database from user space to Shared Memory space.
Such architecture let others process / thread access to the database in
read_only mode, but what will be the impact in term of performance,
especially with large database ? In addition, it not gives the
possibility to send some commands to other process like the OSPF_API do.
3/ Implement a dedicated bus/protocol similar to the Zebra one using
socket. Part of code could be reuse (coming from Zebra and OSPF_API),
but, like Zebra protocol, it uses intensively data copy in memory (at
least 4 to transfer a message to one process). Again, with large
database, there could be some issue with performance.
4/ Implement a dedicated bus using Shared Memory and Semaphore/Mutex to
access the bus managing read/write mode. This option reduce the number
of time we copy data in memory (copy once, read multiple) but introduce
more complexity as we need to synchronise thread and process which could
be hard to debug. The objective is to add a dedicated thread per daemon
to manage the bus which will not disturb other thread in case of lock.
If it is powerful and provide good performance, it could be a candidate
to replace the Zebra communication based on socket to improve performance.
Option 1 and 2 have not our favour, but we are open to discussion. We
hesitate between option 3 and 4 and we appreciate greatly some advises
to help us making decision.
Regards,
Olivier
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
