diff --git a/SUMMARY.md b/SUMMARY.md
index 5da0124..ba8f447 100644
--- a/SUMMARY.md
+++ b/SUMMARY.md
@@ -20,8 +20,8 @@
     * [Fabric Software Setup](fabric-setup.md)
     * [Bringing Up CORD](profiles/intro.md)
         * [R-CORD](profiles/rcord/install.md)
-            * [OLT Setup](openolt/README.md)
-                * [Emulated OLT/ONU](profiles/rcord/emulate.md)
+            * [EdgeCore (OpenOLT driver) Setup](openolt/README.md)
+            * [Emulated OLT/ONU](profiles/rcord/emulate.md)
         * [M-CORD](profiles/mcord/install.md)
             * [EnodeB Setup](profiles/mcord/enodeb-setup.md)
     * [Helm Reference](charts/helm.md)
@@ -53,6 +53,7 @@
         * [RCORD](rcord/README.md)
         * [vOLT](olt-service/README.md)
         * [vRouter](vrouter/README.md)
+    * [Attach containers to external NICs](operating_cord/veth_intf.md)
 * [Development Guide](developer/developer.md)
     * [Getting the Source Code](developer/getting_the_code.md)
     * [Writing Models and Synchronizers](xos/intro.md)
diff --git a/fabric-setup.md b/fabric-setup.md
index d0de4c2..4fb19b6 100644
--- a/fabric-setup.md
+++ b/fabric-setup.md
@@ -45,6 +45,7 @@
 Three OFDPA drivers are available:
 
 * [EdgeCore 5712-54X / 5812-54X / 6712-32X](https://github.com/onfsdn/atrium-docs/blob/master/16A/ONOS/builds/ofdpa_3.0.5.5%2Baccton1.7-1_amd64.deb?raw=true) - *checksum: sha256:db228b6e79fb15f77497b59689235606b60abc157e72fc3356071bcc8dc4c01f*
+* [EdgeCore 7712-32X](https://github.com/onfsdn/atrium-docs/blob/master/16A/ONOS/builds/ofdpa_3.0.5.5%2Baccton1.7-1_amd64.deb) - *checksum: sha256:4f78e8f43976dc86ab1cdc2f98afa743ce2e0cc5923e429c91f96b0edc3ddf4b*
 * [QuantaMesh T3048-LY8](https://github.com/onfsdn/atrium-docs/blob/master/16A/ONOS/builds/ofdpa-ly8_0.3.0.5.0-EA5-qct-01.01_amd64.deb?raw=true) - *checksum: sha256:f8201530b1452145c1a0956ea1d3c0402c3568d090553d0d7b3c91a79137da9e*
 * [QuantaMesh BMS T7032-IX1/IX1B](https://github.com/onfsdn/atrium-docs/blob/master/16A/ONOS/builds/ofdpa-ix1_0.3.0.5.0-EA5-qct-01.00_amd64.deb?raw=true) *checksum: sha256:278b8ffed8a8fc705a1b60d16f8e70377e78342a27a11568a1d80b1efd706a46*
 
diff --git a/operating_cord/veth_intf.md b/operating_cord/veth_intf.md
new file mode 100644
index 0000000..4ccf526
--- /dev/null
+++ b/operating_cord/veth_intf.md
@@ -0,0 +1,112 @@
+# Manually connect containers to a network card
+
+Sometimes you may need to attach some containers NICs to the network cards of the machines hosting them, for example to run some data plane traffic through them.
+
+Although CORD doesn't fully support this natively there are some (hackish) ways to do this manually.
+
+## Create a bridge and a veth
+
+The easiest way to do this is to skip Kubernetes and directly attach the Docker container link it to the host network interface, through a Virtual Ethernet Interface Pair (veth pair).
+
+Let's see how.
+
+For completeness, let's assume you're running a three nodes Kubernetes deployment, and that you're trying to attach a container *already deployed* called *vcore-5b4c5478f-lxrpb* to a physical interface *eth1* (already existing on one of the three hosts, running your container). The virtual interface inside the container will be called *eth2*.
+
+You got the name of the container running
+
+```shell
+$ kubectl get pods [-n NAMESPACE]
+NAME                      READY     STATUS    RESTARTS   AGE
+vcore-5b4c5478f-lxrpb     1/1       Running   1          7d
+```
+
+Find out on which of the three nodes the container has been deployed
+
+```shell
+$ kubectl describe pod  vcore-5b4c5478f-lxrpb | grep Node
+Node:           node3/10.90.0.103
+Node-Selectors:  <none>
+```
+As you can see from the first line, the container has been deployed by Kubernetes on the Docker daemon running on node 3 (this is just an example). In this case, with IP *10.90.0.103*.
+
+Let's SSH into the node and let's look for the specific Docker container ID
+
+```shell
+$ container_id=$(sudo docker ps | grep vcore-5b4c5478f-lxrpb | head -n 1 | awk '{print $1}')
+85fed7deea7b
+```
+
+The interface on the hosting machine should be turned off first
+
+```shell
+sudo ip link set eth1 down
+```
+
+Create a veth called *veth0* and let's add to it the new virtual interface *eth2*
+
+```shell
+sudo ip link add veth0 type veth peer name eth2
+```
+
+Add the virtual network interface *eth2* to the container namespace
+
+```shell
+sudo ip link set eth2 netns ${container_id}
+```
+
+Bring up the virtual interface
+
+```shell
+sudo ip netns exec ${container_id} ip link set eth2 up
+```
+
+Bring up *veth0*
+
+```shell
+sudo ip link set veth0 up
+```
+
+Create a bridge named *br1*. Add *veth0* to it and the host interface *eth1*
+
+```shell
+sudo ip link add br1 type bridge
+sudo ip link set veth0 master br1
+sudo ip link set eth1 master br1
+
+```
+
+Bring up again the host interface and the bridge
+
+```shell
+sudo ip link set eth1 up
+sudo ip link set br1 up
+```
+
+At this point, you should see an additional interface *eth2* inside the container
+
+```shell
+$ kubectl exec -it vcore-5b4c5478f-lxrpb /bin/bash
+$ ip link show
+$ node3:~$ ip link show
+1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
+    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
+2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
+    link/ether c4:54:44:8f:b7:74 brd ff:ff:ff:ff:ff:ff
+3: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
+    link/ether d6:84:33:2f:8c:92 brd ff:ff:ff:ff:ff:ff
+```
+
+## Cleanup (remove veth and bridge)
+
+As a follow up of the previous example, let's now try to delete what has been created so far, to bring the system back to the original state.
+
+```shell
+ip link set veth0 down
+ip link delete veth0
+ip netns exec ${container_id} ip link set eth2 down
+ip netns exec ${container_id} ip link delete eth2
+ip link set eth1 down
+ip link set br1 down
+brctl delbr br1
+ip link set eth1 up
+```
diff --git a/prereqs/hardware.md b/prereqs/hardware.md
index 820ff9a..06e6ab0 100644
--- a/prereqs/hardware.md
+++ b/prereqs/hardware.md
@@ -88,6 +88,9 @@
             * AlphaNetworks PON-34000B (for more info <ed-y_chen@alphanetworks.com>)
                 * Compatible **ONU optics**
                     * Hisense/Ligent: LTF7225-BC, LTF7225-BH+
+            * Iskratel Innbox G108 (for more info <info@innbox.net>)
+                * Compatible **ONU optics**
+                    * SUNSTAR D22799-STCC, EZconn ETP69966-7TB4-I2
 
 * **M-CORD Specific Requirements**
     * **Servers**: Some components of CORD require at least a Intel XEON CPU with Haswell microarchitecture or better.
diff --git a/versioning.md b/versioning.md
index dd1a00c..1c821b2 100644
--- a/versioning.md
+++ b/versioning.md
@@ -12,8 +12,9 @@
 [PEP440](https://www.python.org/dev/peps/pep-0440/) syntax (`.dev#` instead of
 `-dev#`) if using Python code are the recommended formats.
 
-To avoid confusion, all components that existed prior to 6.0 started their
-independent versioning at version `6.0.0`.
+As this is the first time that many of these components received a version
+number, most of them started with version `1.0.0`, except for the `xos` core,
+which starts at `2.0.0`.
 
 ## CORD Releases
 
@@ -48,6 +49,58 @@
    version string, and Docker images with the tag will be built and sent to
    Docker Hub.
 
+## How to create a new CORD release
+
+For 6.0 and later releases, please follow these steps to create a new release.
+
+### Pre-release steps
+
+Per the instructions above, create versioned releases of all the individual
+components, primarily the docker images.
+
+In the `helm-charts` repo, check that all charts use only released versions of
+container images (no `master` or `candidate` tags), and that the `Chart.yaml`
+has the correct *new* `version` field set for the release.
+
+Test the release with this version of the charts, making sure to not override
+the image versions.
+
+### Release steps
+
+Update the `VERSION` file on both the `automation-tools` and `helm-charts`
+repos then commit and merge the patch. Jenkins will then create git tags from
+the contents of the `VERSION` file.
+
+Create a branch in Gerrit using the form `cord-#.#` on those repos starting
+with the new tagged commit.
+
+In the `docs` project, on the `master` branch add an entry to the `book.json`
+to add the new branch, and create a directory on the `guide.opencord.org` site
+for the branch docs.  Create a `cord-#.#` branch on the `docs` repo in Gerrit,
+then update the `git_refs` file within that repo with the commits that have
+the most pertinent documentation.  The `make freeze` command can help generate
+the contents of the `git_refs` file by listing the current git `HEAD` of each
+repo.
+
+Create a `cord-#.#` branch on the `manifest` repo, setting the `revision`
+attribute to `cord-#.#` on the `automation-tools`, `docs`, and `helm-charts`
+projects (and any other projects that have that patch branch).
+
+### Updates to a released branch
+
+Patches to individual components are generally done on the `master` branch of
+their respective projects and given component versions.
+
+Once released, these component versions are integrated into charts, the
+`version` field of the `Chart.yaml` for the chart is updated, and a new point
+release of the `helm-charts` repo is created on the `cord-#.#` branch.
+
+All patches on a released branch of the `helm-charts` and `automation-tools`
+repos should be SemVer release versions, not development versions.
+
+Documentation updates are less strict, with changes within the repo or to
+`git_refs` happening on the patch branch as needed.
+
 ## Details of the release process
 
 To create a new version, the version string is updated in the language or
@@ -64,10 +117,10 @@
 version string in the `VERSION` file, Jenkins jobs have been put in place to
 prevent this from happening. The implementation is as follows:
 
-- When a patchset is submitted to Gerrit, the `tag-collision-reject` Jenkins
-  job runs. This checks that the version string in `VERSION` is does not
-  already exist as a git tag, and rejects any patchsets that have duplicate
-  released versions. It ignores development and non-SemVer version strings.
+- When a patchset is submitted to Gerrit, the `tag-collision` Jenkins job runs.
+  This checks that the version string in `VERSION` is does not already exist as
+  a git tag, and rejects any patchsets that have duplicate released versions.
+  It ignores development and non-SemVer version strings.
 
   This job also checks that if a released version number is used, any
   Dockerfile parent images are also using a fixed parent version, to better