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, 62 insertions, 0 deletions

diff --git a/docs/developer/corefeatures/fib/tunnels.rst b/docs/developer/corefeatures/fib/tunnels.rst
new file mode 100644
index 00000000000..d948a5e2bda
--- /dev/null
+++ b/docs/developer/corefeatures/fib/tunnels.rst
@@ -0,0 +1,62 @@
+.. _tunnels:
+
+Tunnels
+-------
+
+Tunnels share a similar property to recursive routes in that after applying the
+tunnel encapsulation, a new packet must be forwarded, i.e. forwarding is
+recursive. However, as with recursive routes the tunnel's destination is known
+beforehand, so the second lookup can be avoided if the packet can follow the
+already constructed data-plane graph for the tunnel's destination. This process
+of joining to DP graphs together is termed *stacking*.
+
+.. figure:: /_images/fib20fig11.png
+
+Figure 11: Tunnel control plane object diagram
+
+Figure 11 shows the control plane object graph for a route via a tunnel. The two
+sub-graphs for the route via the tunnel and the route for the tunnel's
+destination are shown to the right and left respectively. The red line shows the
+relationship form by stacking the two sub-graphs. The adjacency on the tunnel
+interface is termed a 'mid-chain' since it is now present in the middle of the
+graph/chain rather than its usual terminal location.
+
+The mid-chain adjacency is contributed by the gre_tunnel_t , which also becomes
+part of the FIB control-plane graph. Consequently it will be visited by a
+back-walk when the forwarding information for the tunnel's destination changes.
+This will trigger it to restack the mid-chain adjacency on the new
+*load_balance_t* contributed by the parent *fib_entry_t*.
+
+If the back-walk indicates that there is no route to the tunnel's
+destination, or that the resolving route does not meet resolution
+constraints, then the tunnel can be marked as down, and fast
+convergence can be triggered in the same way as for physical interfaces (see section ...).
+
+
+Multi-Point Tunnels
+^^^^^^^^^^^^^^^^^^^
+
+Multi-point tunnels are an example of a non-broadcast multi-access
+interface. In simple terms this means there are many peers on the link
+but it is not possible to broadcast a single message to all of them at
+once, and hence the usual peer discovery mechanism (as employed,
+e.g. by ARP) is not available. Although an *ip_neighbor_t* is a
+representation of an IP peer on a link, it is not valid in this
+context as it maps the peer's identity to its MAC address. For a
+tunnel peer it is required to map the peer's overlay address (the
+attached address, the one in the same subnet as the device) with the
+peer's underlay address (probably on the other side of the
+internet). In the P2P case where there is only one peer on the link,
+the peer's underlay address is the same as the tunnel's destination
+address.
+The data structure that represents the mapping of the peer's overlay
+with underlay address is an entry in the Tunnel Endpoint Information
+Base (TEIB); the *tieb_entry_t*. TEIB entries are created by the
+control plane (e.g. NHRP (RFC2332)).
+
+Each mid-chain adjacency on a multi-point tunnel is stacked on the
+*fib_entry_t* object that resolves the peer's underlay address. The
+glean adjacency on the tunnel resolves via a drop, since broadcasts
+are not possible. A multicast adjacency on a multi-point tunnel is
+currently a work in progress.
+