docs: better docs, mv doxygen to sphinx

This patch refactors the VPP sphinx docs
in order to make it easier to consume
for external readers as well as VPP developers.

It also makes sphinx the single source
of documentation, which simplifies maintenance
and operation.

Most important updates are:

- reformat the existing documentation as rst
- split RELEASE.md and move it into separate rst files
- remove section 'events'
- remove section 'archive'
- remove section 'related projects'
- remove section 'feature by release'
- remove section 'Various links'
- make (Configuration reference, CLI docs,
  developer docs) top level items in the list
- move 'Use Cases' as part of 'About VPP'
- move 'Troubleshooting' as part of 'Getting Started'
- move test framework docs into 'Developer Documentation'
- add a 'Contributing' section for gerrit,
  docs and other contributer related infos
- deprecate doxygen and test-docs targets
- redirect the "make doxygen" target to "make docs"

Type: refactor

Change-Id: I552a5645d5b7964d547f99b1336e2ac24e7c209f
Signed-off-by: Nathan Skrzypczak <nathan.skrzypczak@gmail.com>
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>

1 files changed, 0 insertions, 88 deletions

diff --git a/docs/gettingstarted/developers/fib20/neighbors.rst b/docs/gettingstarted/developers/fib20/neighbors.rst
deleted file mode 100644
index f460955239c..00000000000
--- a/docs/gettingstarted/developers/fib20/neighbors.rst
+++ /dev/null
@@ -1,88 +0,0 @@
-.. _neighbors:
-
-Neighbours
-^^^^^^^^^^^
-
-.. figure:: /_images/ip-neighbor.png
-
-Figure 1: Neighbour data model
-
-Figure 1 shows the data model for IP neighbours. An IP neighbour contains the mapping
-between a peer, identified by an IPv4 or IPv6 address, and its MAC address on a given
-interface. An IP-table (VRF) is not part of the neighbour's
-data/identity. This is because the virtualisation of a router into
-different tables (VRFs) is performed at the interface level, i.e. an
-IP-table is bound to a particular interface. A neighbour, which is
-attached to an interface, is thus implicitly in that table, and
-only in that table. It is also worth noting that IP neighbours
-contribute forwarding for the egress direction, whereas an IP-table
-is an ingress only function.
-
-The *ip_neighbor_t* represents the control-plane addition of the
-neighbour. The *ip_adjacency_t* contains the data derived from the *ip_neighbor_t* that is needed to
-forward packets to the peer. The additional data in the adjacency are the *rewrite*
-and the *link_type*. The *link_type* is a description of the protocol of the packets
-that will be forwarded with this adjacency; e.g. IPv4, IPv6 or MPLS. The *link_type*
-maps directly to the ether-type in an Ethernet header, or the protocol filed in a
-GRE header. The rewrite is a byte string representation of the header that will be
-prepended to the packet when it is sent to that peer. For Ethernet interfaces this
-is be the src,dst MAC and the ether-type. For LISP tunnels, the IP src,dst pair
-and the LISP header.
-
-The *ip_neighbor_t* for an IPv4 peer (learned e.g. over ARP) will
-install a *link_type=IPv4* when the entry is created and a
-link_type=MPLS on demand (i.e. when a route with output labels resolves via the peer).
-
-Adjacency
----------
-
-There are three sub-types of adjacencies. Purists would argue that some
-of these sub-types are not really adjacencies but are instead other
-forms of DPOs, and it would be hard to argue against that, but
-historically (not just in VPP, but in the FIB implementations from
-which VPP draws on for some of its concepts), these have been modelled
-as adjacency types, the one thing they have in common is that they
-have an associated interface and are terminal. The [sub] sub-types are:
-
-* A Neighbour Adjacency (key={interface, next-hop, link-type}). A
-  representation of a peer on a link (as described above). A neighbour adjacency itself has
-  two sub-types; terminal and mid-chain. When one speak of 'an
-  adjacency' one is usually referring to a terminal neighbour
-  sub-type. A mid-chain adjacency represents a neighbor on a virtual
-  interface which relies on the FIB to perform further forwarding. This
-  adjacency is thus not terminal for the FIB object graph but instead
-  appears in the 'middle' (the term chain is a synonym for graph in
-  some contexts).
-  A neighbour adjacency can be in one of two states; complete and
-  incomplete. A complete adjacency knows the rewrite string that
-  should be used to reach the peer, an incomplete adjacency does
-  not. If the adjacency was added as a result of the addition of an
-  *ip_neighbor_t* then the adjacency will be complete (because the
-  *ip_neighbor_t* knows the peer's MAC address). An incomplete
-  adjacency is created on demand by the FIB when a route's path
-  requires to resolve through such an adjacency. It is thus created in
-  order to resolve the missing dependency, it will become complete
-  once the *ip_neighbor_t* is discovered.
-  In the forwarding path a complete adjacency will prepend the rewrite
-  string and transmit on the egress interface, an incomplete adjacency
-  will construct a ARP/ND request to resolve the peer's IP address.
-
-* A Glean Adjacency (key={interface}). This is a representation of the need to discover
-  a peer on the given interface. It is used when it is known that the
-  packet is destined to an undiscoverd peer on that interface. The
-  difference between the glean adjacency and an
-  incomplete neighbour adjacency is that in the forwarding path the
-  glean adjacency will construct an ARP/ND request for the peer as
-  determined from the packet's destination address. The glean
-  adjacency is used to resolve connected prefixes on multi-access
-  interfaces.
-
-* A Multicast Adjacency (key={interface}). This represents the need to send an IP
-  multicast packet out of the adjacency's associated interface. Since
-  IP multicast constructs the destination MAC address from the IP
-  packet's destination/group address, the rewrite is always known and
-  hence the adjacency is always complete.
-
-
-All adjacency types can be shared between routes, hence each type is
-stored in a DB whose key is appropriate for the type.