docs: Update FIB documentation

Type: docs

Signed-off-by: Neale Ranns <nranns@cisco.com>
Change-Id: I3dfde4520a48c945ca9707accabbe1735c1a8799

1 files changed, 78 insertions, 0 deletions

diff --git a/docs/gettingstarted/developers/fib20/barnacles.rst b/docs/gettingstarted/developers/fib20/barnacles.rst
new file mode 100644
index 00000000000..b5b89a34b36
--- /dev/null
+++ b/docs/gettingstarted/developers/fib20/barnacles.rst
@@ -0,0 +1,78 @@
+.. _barnacles:
+
+Barnacles
+---------
+
+Features that are stuck on the side of the FIB. Those that directly use
+the services that the FIB provides.
+
+In the section on FIB fundamentals it was mentioned  that there is a
+separation between what to match and how to forward. In an IP FIB what
+to match is the packet's destination address against a table of IP
+prefixes, and how to forward is described by a list of paths (the
+**fib_path_list_t**).
+
+ACL Based Forwarding
+^^^^^^^^^^^^^^^^^^^^
+
+ACL Based Forwarding (ABF) is also know as policy based routing
+(PBR). In ABF what to match is described by an ACL.
+
+ABF uses two VPP services; ACL as a service, as provided by the ACL
+plugin and FIB path-lists. It just glues them together.
+
+An ABF policy is the combination of an ACL with the forwarding
+description of a FIB path-list. An ABF attachment is the association
+of [an ordered set of] ABF policies to an interface. The attachment is
+consulted on the ingress path of the IP DP (as an input
+feature). If the ACL matches then the associated forwarding is
+followed, if not, the packet continues along the DP. Simples.
+
+Layer 3 Cross Connect
+^^^^^^^^^^^^^^^^^^^^^
+
+An L3 cross-connect (L3XC) matches all packets
+that ingress the interface and then forwards using the supplied FIB
+path-list. Naturally it runs as an input feature in the IP
+path. Super simples.
+
+IP Punt
+^^^^^^^
+
+Matches all IP packets that VPP has punted. Why they are punted is not
+relevant. All IP punted packets are sent by VPP to the punt feature
+arc. This feature 'matches' all packets that it receives and forwards
+using the FIB path-list.
+
+
+Unicast Reverse Path Forwarding
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Unicast Reverse Path Forwarding (uRPF) is the process of ensuring that
+a packet has a conforming source address. It comes in two
+flavours:
+
+- loose: The source address must be reachable, i.e. FIB must have a
+  route that will forward to the source address. The default route
+  counts as long as it does not drop.
+- strict: The source address is reachable via the interface on which
+  the packet arrived, i.e. the FIB's route for the source address must
+  include the input interface as an output interface.
+
+The uRPF feature can run on either the input or output IP feature
+arc. In both cases it serves as an anti-spoofing check, though the
+semantics are slightly different. On the input arc it enforces that
+peers on that link are only using source addresses that they should -
+a network admin should employ at the access edge. On the output
+arc it enforces that a packet is sourced from a prefix that belongs to
+the network, i.e. that is has originated from within an SP's
+network, a network admin could use at its peering points.
+
+To perform a uRPF check, the DP performs an IP FIB lookup on the
+source address, this always results in a load-balance (LB) object. If
+the LB has only 1 bucket and that bucket stacks on a drop DPO, then
+both a loose and strict check will fail, otherwise a loose check
+will pass. Each LB object has an associated uRPF list object. This
+object holds the list of interfaces through which the prefix is
+reachable. To pass the strict check, the input/output interface must
+be in this list.