SFC Release Notes

1. Abstract

This document compiles the release notes for the Colorado release of OPNFV SFC.

2. Important notes

These notes provide release information for the use of SFC with the Fuel and Apex installer tools for the Colorado release of OPNFV.

3. Summary

The goal of the SFC Colorado release is to integrate the OpenDaylight SFC project into an OPNFV environment, with either the Fuel or Apex installer. In subsequent releases, other OPNFV installers will be considered.

More information about OpenDaylight and SFC can be found here.

4. Release Data

Project sfc
Repo/tag colorado.1.0
Release designation Colorado base release
Release date September 22 2016
Purpose of the delivery Improve functionality provided in Brahmaputra release. Increased test coverage with new Funtest cases. Make SFC/Tacker work on multiple compute nodes

4.1. Version change

4.1.1. Module version changes

This is the second tracked release of OPNFV sfc. It is based on following upstream versions:

  • OpenStack Mitaka release
  • OpenDaylight Boron release
  • Open vSwitch 2.5.90 with Yi Yang NSH patch

4.1.2. Document changes

This is the second tracked version of OPNFV SFC. It comes with the following documentation:

4.2. Reason for version

4.2.1. Feature additions

JIRA TICKETS:

JIRA EPIC with the new features in SFC Colorado

4.2.2. Bug corrections

JIRA TICKETS:

Bug-fixes

4.3. Deliverables

4.3.1. Software deliverables

No specific deliverables are created, as SFC is included with Apex and Fuel.

4.3.2. Documentation deliverables

5. Known Limitations, Issues and Workarounds

5.1. System Limitations

The Colorado 1.0 release has several limitations:

1 - OPNFV SFC only works in non-HA environments with the Fuel installer. Tacker is currently not registered in the HA Proxy, so the calls to it fail.

2 - It only works in one-compute deployments. Tacker fixed the multicompute support in the last weeks but it has not been tested yet.

3 - The first time a classification rule is created, it does not work. This is a known issue in Netvirt-ODL. Create the classification once again and it should work. This issue will be fixed in ODL Boron SR1, which will be included in Colorado 2.0.

4 - Any VM (e.g. SFs) must have only one security group. There is a bug in ODL Boron which only one security group is read. The rest are silently ignored. This issue will be fixed in ODL Boron SR1, which will be included in Colorado 2.0.

5.2. Known issues

OpenDaylight SFC relies on a version of Open vSwitch (OVS) with Network Service Headers (NSH). A version of OVS with NSH currently exists, but it is in a branched version of OVS. Extensive upstream work has been done to merge the NSH patches into mainstream OVS, but the work is still not complete. More information about this can be found in the OPNFV SFC design document (link provided above).

5.3. Workarounds

The way OpenStack handles VXLAN-GPE tunnels doesnt work well with SFC, since OpenStack terminates the VXLAN tunnels in the br-int bridge instead of the SF VM. Ideally, the tunnel should be terminated in the VM so the SF has access to the NSH header carried in the tunnel. A workaround was created to send the packets to the SF VM with the VXLAN-GPE headers intact and can be found in the OPNFV SFC design document (link provided above).

6. Test results

The Colorado release of SFC has undergone QA test runs with Functest tests on the Fuel and Apex installers.

7. References

For more information on the OPNFV Colorado release, please see:

7.3. OpenDaylight

  1. OpenDaylight artifacts