\chapter*{Conclusion}
\addcontentsline{toc}{chapter}{Conclusion}

We developed a simple and standalone tool for visualising OSPF topologies. The
program is functional and can visualise network systems of medium size. The
project's design will allow additional features to be added in the future.

The project also meets the goals stated in chapter~\ref{ch:motivation}:

\begin{itemize}
	\item Birdvisu utilises BIRD to collect data about the whole network system from a single host,
	\item the project can be easily run from any Linux machine, not requiring any server-based setup, and
	\item its topology-centric approach has successfully discovered minor issues with an existing OSPF deployment.
\end{itemize}

The only stated goal Birdvisu fails to fulfil at this time is the ability to
exchange data with other projects. However, the project's design expects such
functionality, so enhancing Birdvisu in this way should be easy in the future.

\bgroup
\def\yes{\checkmark}
\def\no{\texttimes}
\def\maybe{?}
\begin{table}[h]
	\centering
	\begin{tabular}{lccccc}\hline
		Approach                  & CD   & RS     & CoH    & EoD    & T    \\\hline
		Only visualisation        & \no  & \maybe & \no    & \maybe & \no  \\
		Traffic visualisation     & \yes & \yes   & \yes   & \no    & \no  \\
		Host monitoring           & \yes & \maybe & \yes   & \maybe & \no  \\
		Integrated management     & \yes & \yes   & \maybe & \no    & \yes \\
		Topolograph + Ospfwatcher & \yes & \yes   & \no    & \no    & \yes \\\hline
		\textit{Birdvisu}         & \yes & \no    & \no    & \yes   & \yes \\
	\hline\end{tabular}
	\caption{Comparison of Birdvisu's approach compared to other known approaches. See also table~\ref{t:comparison1}.}
	\label{t:comparison2}
\end{table}
\egroup

\section*{Future work}
\addcontentsline{toc}{section}{Future work}

There are many ways Birdvisu can be expanded in the future. Apart from the
stated ones (exports, better vertex placements, \dots), it could be possible to
support other routing daemons and even other link-state protocols like Babel.

Another interresting possible use case could be running Birdvisu headless. When
combined with the export feature, this could allow using the project as a data
source for other visualisation tools. While this is currently not possible,
because the GUI controls all the parts of the program, it might be possible to
separate the GUI and the coordination part.

More Annotators could also be written to provide other functions, like
detecting single points of failure. And last, but not least, the user interface
can definitely be prettier.