From e0f569cd2146951f33207141df4576bf98cd5769 Mon Sep 17 00:00:00 2001 From: Manuel Buil Date: Wed, 23 Aug 2017 15:12:01 +0200 Subject: Replace artifacts.opnfv links by docs.opnfv links artifacts.opnfv is not used anymore. We are using now docs.opnfv Apart from that, I removed the OVS-NSH workaround explanation as we don't use it anymore Change-Id: Iaf4f2d97a4252754f5b22709aef653fff0777eae Signed-off-by: Manuel Buil --- .../scenarios/os-odl-sfc-ha/scenario.description.rst | 14 -------------- 1 file changed, 14 deletions(-) (limited to 'docs/release/scenarios/os-odl-sfc-ha/scenario.description.rst') diff --git a/docs/release/scenarios/os-odl-sfc-ha/scenario.description.rst b/docs/release/scenarios/os-odl-sfc-ha/scenario.description.rst index 249b0bd7..11b41434 100644 --- a/docs/release/scenarios/os-odl-sfc-ha/scenario.description.rst +++ b/docs/release/scenarios/os-odl-sfc-ha/scenario.description.rst @@ -92,20 +92,6 @@ The older version of OVS only supported VXLAN-GPE + NSH encapsulation, but the n version supports both ETH + NSH and VXLAN-GPE + ETH + NSH. Currently SFC is only implemented with VXLAN-GPE + ETH + NSH. -Workaround for VXLAN and OpenStack ----------------------------------- - -When using NSH with VXLAN tunnels, its important that the VXLAN tunnel is terminated -in the SF VM. This allows the SF to see the NSH header, allowing it to decrement the -NSI and also to use the NSH metadata. When using VXLAN with OpenStack, the tunnels -are not terminated in the SF VM, but in the “br-int” OVS bridge. A work-around has -been created to address this issue, which can be found here: - -http://artifacts.opnfv.org/sfc/danube/docs/design/architecture.html#ovs-nsh-patch-workaround - -In subsequent versions of SFC, we will change the SFF-SF transport to be ETH + NSH, -which will obviate this work around. - References ========== -- cgit 1.2.3-korg