Service Function Chaining

Major Features

odl-sfc-netconf

odl-sfc-scf-openflow

odl-sfc-scf-vpp

odl-sfc-openflow-renderer

odl-sfclisp

odl-sfc-sb-rest

odl-sfc-ui

odl-sfc-vnfm-tacker

odl-sfc-ios-xe-renderer

odl-sfc-vpp-renderer

odl-sfc-pot

These features are consumed by the User facing features above

odl-sfc-genius

odl-sfc-model

odl-sfc-pot-netconf-renderer

odl-sfc-provider

odl-sfc-provider-rest

odl-sfc-ovs

odl-sfc-test-consumer

Features removed in this release

  • odl-sfc-bootstrap - used to load an initial configuration that is no longer needed
  • odl-sfcofl2 - was deprecated since it was renamed to odl-sfc-openflow-renderer

Documentation

Security Considerations

None.

Quality Assurance

  • Link to Sonar Report (55.9%)
  • Link to CSIT Jobs
  • All modules have been unit tested. Integration tests have been performed for all major features. System tests have been performed on most major features.

Migration

The impacts on the SFC data models in this release are minimal. Several fields that were marked as deprecated in Beryllium and Boron have been removed in Carbon, as follows. No automatic data migration is supported.

Service Chain Symmetry

Previously a Service Chain could be marked symmetric by using either the symmetric flag in the Service Function Chain (SFC), the Service Function Path (SFP), or the Rendered Service Path (RSP). This approach can be confusing if the SFC, SFP, or RSP have different values for the symmetric flag. The symmetric flag has been removed from the SFC and RSP and can now only be set in the SFP. Additionally, if the symmetric flag is not present in the SFP, if any of the Service Functions is of a Service Funtion Type (SFT) that has the bidirectional flag set true, then the Service Chain will be symmetric. The SFP symmetric flag overides the SFT bidirectional flag. To say that a Service Chain is symmetric means that 2 RSPs will be created internally, one uplink and another downlink.

Deprecated Service Function fields

The Service Function nsh-aware and requires-classification fields have been moved to the Service Function Type.

Compatibility

Other than the API changes mentioned in the previous section, this release is compatible with the previous release.

Known Issues

SFC needs changes in OVS to include the Network Service Headers (NSH) Chaining encapsulation feature. This patch has been ongoing for quite a while (2 years+), and still has not been officially merged. Until NSH is officially merged in OVS, SFC will use a branched version of OVS based on 2.6.1, called the “Yi Yang Patch”, located here. Previous versions of this OVS patch only supported VXLAN-GPE + NSH encapsulation, but this version supports both ETH + NSH and VXLAN-GPE + ETH + NSH.

The following bug was found during Carbon RC testing, which was originally marked as a blocker. Upon further investigation, the MDSAL team decided its not a blocker and decided to postpone fixing it until Carbon SR1.

End-of-life

List of features/APIs which are EOLed, deprecated, and/or removed in this release

  • In the Beryllium release, the Service Function nsh-aware and request-classification API fields were deprecated, and were subsequently removed in Carbon.
    • Use the corresponding fields in the Service Function Type instead.
  • In the Boron release, the symmetrice API field was deprecated in the Service Function Chain and Rendered Service Path data models, and were subsequently removed in Carbon.
    • Use the Service Function Path (SFP) symmetric field instead of the SFC or RSP symmetric field.
    • Or, if the SFP symmetric field is not present and any of the Service Functions has a Service Function type that sets bidirection true, then the resulting Rendered Service Path will be symmetric.

Standards

Release Mechanics