diff --git a/docs/gettingstarted/developers/fib20/tunnels.rst b/docs/gettingstarted/developers/fib20/tunnels.rst
index c96b133..f53d622 100644
--- a/docs/gettingstarted/developers/fib20/tunnels.rst
+++ b/docs/gettingstarted/developers/fib20/tunnels.rst
@@ -1,12 +1,12 @@
 .. _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 recursive switch can be avoided if the packet can follow the
+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*.
   
@@ -18,7 +18,7 @@
 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' this it is now present in the middle of the
+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
@@ -27,7 +27,36 @@
 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, or that the
-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 ...).
+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.
+