aboutsummaryrefslogtreecommitdiffstats
path: root/src/plugins/srv6-ad
diff options
context:
space:
mode:
authorNathan Skrzypczak <nathan.skrzypczak@gmail.com>2021-10-08 14:05:35 +0200
committerDave Wallace <dwallacelf@gmail.com>2021-10-13 23:22:20 +0000
commitf47122e07e1ecd0151902a3cabe46c60a99bee8e (patch)
tree0c28c0eca2cb17050d6f31fd8f0ca8f78299bf0d /src/plugins/srv6-ad
parent1e4281223ab4d655b54496ae13fbdb68f867e351 (diff)
docs: convert plugins doc md->rst
Type: improvement Change-Id: I7e821cce1feae229e1be4baeed249b9cca658135 Signed-off-by: Nathan Skrzypczak <nathan.skrzypczak@gmail.com>
Diffstat (limited to 'src/plugins/srv6-ad')
-rw-r--r--src/plugins/srv6-ad/ad_plugin_doc.md73
-rw-r--r--src/plugins/srv6-ad/ad_plugin_doc.rst86
2 files changed, 86 insertions, 73 deletions
diff --git a/src/plugins/srv6-ad/ad_plugin_doc.md b/src/plugins/srv6-ad/ad_plugin_doc.md
deleted file mode 100644
index 993eeb63589..00000000000
--- a/src/plugins/srv6-ad/ad_plugin_doc.md
+++ /dev/null
@@ -1,73 +0,0 @@
-# SRv6 endpoint to SR-unaware appliance via dynamic proxy (End.AD) {#srv6_ad_plugin_doc}
-
-## Overview
-
-The dynamic proxy is an improvement over the static proxy (@ref srv6_as_plugin_doc)
-that dynamically learns the SR information before removing it from the incoming
-traffic. The same information can then be re-attached to the traffic returning
-from the SF. As opposed to the static SR proxy, no CACHE information needs to be
-configured. Instead, the dynamic SR proxy relies on a local caching mechanism on
-the node instantiating this segment. Therefore, a dynamic proxy segment cannot
-be the last segment in an SR SC policy. A different SR behavior should thus be
-used if the SF is meant to be the final destination of an SR SC policy.
-
-Upon receiving a packet whose active segment matches a dynamic SR proxy
-function, the proxy node pops the top MPLS label or applies the SRv6 End
-behavior, then compares the updated SR information with the cache entry for the
-current segment. If the cache is empty or different, it is updated with the new
-SR information. The SR information is then removed and the inner packet is sent
-towards the SF.
-
-The cache entry is not mapped to any particular packet, but instead to an SR SC
-policy identified by the receiving interface (IFACE-IN). Any non-link-local IP
-packet or non-local Ethernet frame received on that interface will be
-re-encapsulated with the cached headers as described in @ref srv6_as_plugin_doc. The
-SF may thus drop, modify or generate new packets without affecting the proxy.
-
-For more information, please see
-[draft-xuclad-spring-sr-service-chaining](https://datatracker.ietf.org/doc/draft-xuclad-spring-sr-service-chaining/).
-
-## CLI configuration
-
-The following command instantiates a new End.AD segment that sends the inner
-packets on interface `IFACE-OUT` towards an appliance at address `S-ADDR` and
-restores the encapsulation headers of the packets coming back on interface
-`IFACE-IN`.
-
-```
-sr localsid address SID behavior end.ad nh S-ADDR oif IFACE-OUT iif IFACE-IN
-```
-
-For example, the below command configures the SID `1::A1` with an End.AD
-function for sending traffic on interface `GigabitEthernet0/8/0` to the
-appliance at address `A1::`, and receiving it back on interface
-`GigabitEthernet0/9/0`.
-
-```
-sr localsid address 1::A1 behavior end.ad nh A1:: oif GigabitEthernet0/8/0 iif GigabitEthernet0/9/0
-```
-
-## Pseudocode
-
-The dynamic proxy SRv6 pseudocode is obtained by inserting the following
-instructions between lines 1 and 2 of the static proxy SRv6 pseudocode.
-
-```
-IF NH=SRH & SL > 0 THEN
- Decrement SL and update the IPv6 DA with SRH[SL]
- IF C(IFACE-IN) different from IPv6 encaps THEN ;; Ref1
- Copy the IPv6 encaps into C(IFACE-IN) ;; Ref2
-ELSE
- Drop the packet
-```
-
-**Ref1:** "IPv6 encaps" represents the IPv6 header and any attached extension
-header.
-
-**Ref2:** C(IFACE-IN) represents the cache entry associated to the dynamic SR proxy
-segment. It is identified with IFACE-IN in order to efficiently retrieve the
-right SR information when a packet arrives on this interface.
-
-In addition, the inbound policy should check that C(IFACE-IN) has been defined
-before attempting to restore the IPv6 encapsulation, and drop the packet
-otherwise.
diff --git a/src/plugins/srv6-ad/ad_plugin_doc.rst b/src/plugins/srv6-ad/ad_plugin_doc.rst
new file mode 100644
index 00000000000..cfb6cea7a15
--- /dev/null
+++ b/src/plugins/srv6-ad/ad_plugin_doc.rst
@@ -0,0 +1,86 @@
+.. _srv6_ad_plugin_doc:
+
+SRv6 dynamic proxy
+==================
+
+SRv6 endpoint to SR-unaware appliance via dynamic proxy (End.AD)
+----------------------------------------------------------------
+
+Overview
+~~~~~~~~
+
+The dynamic proxy is an improvement over the static proxy (@ref
+srv6_as_plugin_doc) that dynamically learns the SR information before
+removing it from the incoming traffic. The same information can then be
+re-attached to the traffic returning from the SF. As opposed to the
+static SR proxy, no CACHE information needs to be configured. Instead,
+the dynamic SR proxy relies on a local caching mechanism on the node
+instantiating this segment. Therefore, a dynamic proxy segment cannot be
+the last segment in an SR SC policy. A different SR behavior should thus
+be used if the SF is meant to be the final destination of an SR SC
+policy.
+
+Upon receiving a packet whose active segment matches a dynamic SR proxy
+function, the proxy node pops the top MPLS label or applies the SRv6 End
+behavior, then compares the updated SR information with the cache entry
+for the current segment. If the cache is empty or different, it is
+updated with the new SR information. The SR information is then removed
+and the inner packet is sent towards the SF.
+
+The cache entry is not mapped to any particular packet, but instead to
+an SR SC policy identified by the receiving interface (IFACE-IN). Any
+non-link-local IP packet or non-local Ethernet frame received on that
+interface will be re-encapsulated with the cached headers as described
+in @ref srv6_as_plugin_doc. The SF may thus drop, modify or generate new
+packets without affecting the proxy.
+
+For more information, please see
+`draft-xuclad-spring-sr-service-chaining <https://datatracker.ietf.org/doc/draft-xuclad-spring-sr-service-chaining/>`__.
+
+CLI configuration
+~~~~~~~~~~~~~~~~~
+
+The following command instantiates a new End.AD segment that sends the
+inner packets on interface ``IFACE-OUT`` towards an appliance at address
+``S-ADDR`` and restores the encapsulation headers of the packets coming
+back on interface ``IFACE-IN``.
+
+::
+
+ sr localsid address SID behavior end.ad nh S-ADDR oif IFACE-OUT iif IFACE-IN
+
+For example, the below command configures the SID ``1::A1`` with an
+End.AD function for sending traffic on interface
+``GigabitEthernet0/8/0`` to the appliance at address ``A1::``, and
+receiving it back on interface ``GigabitEthernet0/9/0``.
+
+::
+
+ sr localsid address 1::A1 behavior end.ad nh A1:: oif GigabitEthernet0/8/0 iif GigabitEthernet0/9/0
+
+Pseudocode
+~~~~~~~~~~
+
+The dynamic proxy SRv6 pseudocode is obtained by inserting the following
+instructions between lines 1 and 2 of the static proxy SRv6 pseudocode.
+
+::
+
+ IF NH=SRH & SL > 0 THEN
+ Decrement SL and update the IPv6 DA with SRH[SL]
+ IF C(IFACE-IN) different from IPv6 encaps THEN ;; Ref1
+ Copy the IPv6 encaps into C(IFACE-IN) ;; Ref2
+ ELSE
+ Drop the packet
+
+**Ref1:** “IPv6 encaps” represents the IPv6 header and any attached
+extension header.
+
+**Ref2:** C(IFACE-IN) represents the cache entry associated to the
+dynamic SR proxy segment. It is identified with IFACE-IN in order to
+efficiently retrieve the right SR information when a packet arrives on
+this interface.
+
+In addition, the inbound policy should check that C(IFACE-IN) has been
+defined before attempting to restore the IPv6 encapsulation, and drop
+the packet otherwise.