[sfc-dev] [SFC] Why doesn't OpenDaylight use Ether/NSH encapsulation?

Zhou, Danny danny.zhou at intel.com
Wed Aug 19 01:14:29 UTC 2015


Dave,

I agree with you there is no hard limitation for NSH to be carried by VxLAN-GPE transport only. The NSH draft mentioned NSH is transport independent but the current implementation in OVS and ODL only supports VxLAN-GPE-NSH.

In current available SFC demos using NSH-aware OVS, when receiving a packet with VxLAN-GPE-NSH tunneling header from the classifier (NSH-aware OVS) or the last-hop SFF,  the SFF (NSH-aware OVS) decapsulates the VxLAN-GPE-NSH header completely (which is the default behavior of all VTEPs) and saves the information in the tunneling header as the packet’ metadata on a per packet basis, then it re-encapsulates the packet with VxLAN-GPE-NSH header by using the packet’ metadata followed by forwarding the packet to destination VNF which is supposed to be NSH-aware meaning it could handle (e.g. decrement Service Index) VxLAN-GPE-NSH header.

This is very heavyweight in my humble option, the total length of VxLAN-GPE-NSH (MD Type = 1) header is 74B which is even bigger than typical 64B small packet. We have an alternative approach which instead of doing VxLAN-GPE-NSH decap/re-encap mentioned above it actually translates VxLAN-GPE-NSH header to Ethernet-NSH header after decapsulation. In this way, it not only replace heavyweight VxLAN-GPE header with lightweight Ethernet-NSH header so more payload (original L2 frame) can be carried, but also avoids involving VTEP if the connected next-hop SFF is on the same physical L2 network. If the next-hop SFF is not on the same physical L2 network, then VTEP is needed by translating Ethernet-NSH back to VxLAN-GPE-NSH format. The key point is that NSH has to be always along with the original L2 frame, and VxLAN-GPE is used as transport when necessary. We have this prototype on DPDK-netdev based dataplane (to be submitted as patch to Openvswitch.org soon) but not on the kernel based dataplane yet.

-Danny

From: sfc-dev-bounces at lists.opendaylight.org [mailto:sfc-dev-bounces at lists.opendaylight.org] On Behalf Of Keith Burns
Sent: Wednesday, August 19, 2015 5:40 AM
To: Dave Dolson
Cc: opendaylight sfc
Subject: Re: [sfc-dev] [SFC] Why doesn't OpenDaylight use Ether/NSH encapsulation?


If the SFF / classifiers are outside the OVS then the OVS in that instance is just underlay.

In that case NSH support is largely irrelevant for OVS as underlay.
On Aug 18, 2015 11:54 AM, "Dave Dolson" <ddolson at sandvine.com<mailto:ddolson at sandvine.com>> wrote:
I’m saying that the classifiers and SFFs could be external to the switching layer.
For packets leaving a host, choose the destination MAC address before submitting the packet to the switch.

Is it the case that OVS provides a convenient module because it already has the control-plane interfaces?


From: Keith Burns [mailto:alagalah at gmail.com<mailto:alagalah at gmail.com>]
Sent: Tuesday, August 18, 2015 2:45 PM
To: Dave Dolson
Cc: opendaylight sfc
Subject: Re: [sfc-dev] [SFC] Why doesn't OpenDaylight use Ether/NSH encapsulation?


Dave,

The purpose of the OVS classifier (GBP) and OVS SFF (SFC) is to ensure packets get to the right SF based on NSH fields.

If OVS can't MATCH/ACTION on these fields, it can't do those functions.

Matching and acting on ethertype would only let us fwd to an (in fact potentially all) connected external classifier or SFF which would have to have NSH visibility.
On Aug 18, 2015 11:26 AM, "Dave Dolson" <ddolson at sandvine.com<mailto:ddolson at sandvine.com>> wrote:

The current approach to SFC in OpenDaylight seems to require a new Open vSwitch, but it should be possible to have NSH without any changes to OVS.
Here’s my reasoning:

The encapsulation of NSH directly in Ethernet, (or in Ethernet/VLAN) is defined in the NSH draft: https://tools.ietf.org/html/draft-ietf-sfc-nsh-01#section-9.3

(Ethertype 0x894F)

So any old switch or virtual LAN segment can deliver these packets between Ethernet end-points.

Why not go with that? Keep NSH out of the switching and keep the NSH processing only in the machines, virtual or otherwise.
Why is it believed that VxLAN orchestration must be involved with NSH?

(I realize of course that some packets may be carried over VxLAN networks, but that should be transparent to protocols riding as Ethernet payload.)


David Dolson
Senior Software Architect, Sandvine Inc.


_______________________________________________
sfc-dev mailing list
sfc-dev at lists.opendaylight.org<mailto:sfc-dev at lists.opendaylight.org>
https://lists.opendaylight.org/mailman/listinfo/sfc-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendaylight.org/pipermail/sfc-dev/attachments/20150819/a1cb1379/attachment.html>


More information about the sfc-dev mailing list