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 --- docs/release/configguide/feature.configuration.rst | 4 ++-- docs/release/release-notes/releasenotes.rst | 18 +++++++++--------- .../scenarios/os-odl-sfc-ha/scenario.description.rst | 14 -------------- .../scenarios/os-odl-sfc-noha/scenario.description.rst | 14 -------------- 4 files changed, 11 insertions(+), 39 deletions(-) (limited to 'docs') diff --git a/docs/release/configguide/feature.configuration.rst b/docs/release/configguide/feature.configuration.rst index 8bd39436..da35ee40 100644 --- a/docs/release/configguide/feature.configuration.rst +++ b/docs/release/configguide/feature.configuration.rst @@ -12,9 +12,9 @@ SFC feature desciription For details of the scenarios and their provided capabilities refer to the scenario description documents: -- http://artifacts.opnfv.org/sfc/danube/docs/scenarios_os-odl_l2-sfc-ha/index.html +- http://docs.opnfv.org/en/stable-danube/submodules/sfc/docs/release/scenarios/os-odl_l2-sfc-ha/index.html -- http://artifacts.opnfv.org/sfc/danube/docs/scenarios_os-odl_l2-sfc-noha/index.html +- http://docs.opnfv.org/en/stable-danube/submodules/sfc/docs/release/scenarios/os-odl_l2-sfc-noha/index.html The SFC feature enables creation of Service Fuction Chains - an ordered list diff --git a/docs/release/release-notes/releasenotes.rst b/docs/release/release-notes/releasenotes.rst index da87c384..73b09922 100644 --- a/docs/release/release-notes/releasenotes.rst +++ b/docs/release/release-notes/releasenotes.rst @@ -33,11 +33,11 @@ More information about OpenDaylight and SFC can be found here. - Overall OPNFV documentation - - `Design document `_ + - `Design document `_ - - `User Guide `_ + - `User Guide `_ - - `Installation Instructions `_ + - `Installation Instructions `_ - Release Notes (this document) @@ -82,11 +82,11 @@ Document changes This is the first tracked version of OPNFV SFC Danube. It comes with the following documentation: -- `Design document `_ +- `Design document `_ -- `User Guide `_ +- `User Guide `_ -- `Installation Instructions `_ +- `Installation Instructions `_ - Release notes (This document) @@ -126,11 +126,11 @@ No specific deliverables are created, as SFC is included with Apex and Fuel. Documentation deliverables ~~~~~~~~~~~~~~~~~~~~~~~~~~ -- `Design document `_ +- `Design document `_ -- `User Guide `_ +- `User Guide `_ -- `Installation Instructions `_ +- `Installation Instructions `_ - Release notes (This document) 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 ========== diff --git a/docs/release/scenarios/os-odl-sfc-noha/scenario.description.rst b/docs/release/scenarios/os-odl-sfc-noha/scenario.description.rst index 691c0931..e74e47c4 100644 --- a/docs/release/scenarios/os-odl-sfc-noha/scenario.description.rst +++ b/docs/release/scenarios/os-odl-sfc-noha/scenario.description.rst @@ -94,20 +94,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