The base of introduction

The table and specific requirements are not yet writen, but that should
be simple…

en/chap01.tex

@@ -1 +1,87 @@
 \chapter{Motivation}\label{ch:motivation}
+
+%First, we need to further specify, what Birdvisu should be. This section
+%describes what is the missing project and why such project would be useful.
+
+In this chapter we explore existing solutions for visualising and monitoring
+network systems and describe the requirements of network administrators. From
+this we derive a set of properties Birdvisu should fulfil.
+
+\section{Existing approaches to network monitoring}
+
+Several approaches to network monitoring and status visalisation already exist.
+These can be approximately split into several types: visualisation of existing
+data, traffic visualisation, host monitoring systems and integrated system
+management platforms. We \X{uuuuuuuuuu}.
+
+\subsection{Visualisation of existing data}
+
+Tools in this category do not collect any data on their own, rather only
+focusing on visualising data from other tools. These projects are often small,
+can be easy to run and allow visualisation of various data, but they require
+other infrastructure to provide the data. For example, the Network
+Weathermap\cite{weathermap} project can be used to provide overview based on
+data in Cacti or other tools. Grafana\cite{grafana} provides many different
+methods of visualising data from various databases.
+
+This does not seem to be usable for visualising OSPF state, because we are not
+aware of any collectors of OSPF state data.
+
+\subsection{Traffic visualisation}
+
+Various software packages can collect and graph utilisation of network links.
+This often provides information about link state, but requires collection of
+data on all hosts. Also, in some cases, this might not provide accurate data of
+the system state, as we will see in section~\ref{s:net-broken}.
+
+These projects usually store a time series of utilisation and therefore need to
+be deployed on some central server as long-running services.
+
+Examples of this approach include Cacti\cite{cacti} and Munin\cite{munin}.
+Although both mentioned projects can graph other data, plugins for data
+collection are available, so this differentiates them from the previous group.
+
+\subsection{Host monitoring systems}
+
+Projects in tis category do not necessarily consider the whole network system,
+but check state of individual hosts. It is possible for them to run locally, as
+is the case for Plotnetcfg\cite{plotnetcfg}, or check the host over the network
+(CaLStats\cite{calstats}, Icinga\cite{icinga}), but they do not provide
+overall picture. The capabilities of these tools also differ, from just
+checking reachability (CaLStats) to being able to retreive various details from
+the hosts (Icinga, plotnetcfg).
+
+This approach can also miss some issues with the system, as described in the
+section~\ref{s:net-broken}.
+
+\subsection{Integrated system management platforms}
+
+Some network administrators have created platforms for managing the hosts
+across the network system. These systems usually know various aspects of the
+system and may provide features like configuration generation or topology
+visualisation\cite{nodewatcher-paper}. However, many of these are tailored for
+the specific system and are therefore not reusable in other environments.
+
+Also, since large number of people need to access such platforms, they are
+usually server based with web interface\cite{nodewatcher-paper}.
+
+\subsection{Topolograph}
+
+We are aware of the only project that would allow visualisation of OSPF
+topology, Topolograph\cite{topolograph}. While it does not collect its own
+data, its companion project, Ospfwatcher\cite{ospfwatcher}, is able to retrieve
+current topology data from a Quagga\cite{quagga} routing daemon. The deployment
+involves setting up Logstash\cite{logstash}, so this is only suitable to be run
+on a server.
+
+Also, we find the interface of Topolograph impractical to use in Firefox 116.0b2.
+
+\subsection{Summary of existing tools}
+
+\X{table}
+
+\subsection{Goals of Birdvisu}
+
+\begin{itemize}
+\item\X{TODO}
+\end{itemize}

en/intro.tex

@@ -26,7 +26,7 @@ An \emph{administrator} is a person or a group of people, who provide the
 routers with configuration and who make sure that the routers (and other
 infrastructure) functions correctly.
 
-The word \emph{network} will always denote a set of hosts, that can exchange
+The word \emph{network}, when used as a noun, will always denote a set of hosts, that can exchange
 packets \uv{directly}, without forwarding, under normal circumstances. While
 this is somewhat synonymous with the term \emph{network segment}, when the
 network splits, there may be multiple link-layer segments belonging to the same