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

Dave Dolson ddolson at sandvine.com
Fri Aug 21 18:00:08 UTC 2015


Reinaldo,

The original MAC doesn't need to be preserved. Destination Ethernet addresses are rewritten at each step from the lookup table.

In the Ether+NSH approach, each of the SFs and SFFs require only a single Ethernet interface, all on a single layer2 segment.

Steps followed by a packet:
- SFF receives an NSH packet, looks up the (Service-Path-ID, Service-Index) in forwarding table to get the SF, and rewrites the destination MAC to the SF and source MAC to self.
- SF receives the NSH packet, processes it, decrements Service index, and sets destination MAC to SFF, and source MAC to self and sends.
- the SFF receives the NSH packet, looks up the (Service-Path-ID, Service-Index) in its forwarding table, which specifies the destination MAC of the next SFF or SF.

Each SFF has a forwarding table like this:

   +----------------------------------+
   |  SPI |  SI |  Next Hop MAC       |
   +----------------------------------+
   |  10  | 255 |  01:23:45:67:89:a1  | <- this could be to SF1
   |  10  | 254 |  01:33:45:67:89:a2  | <- this could be for packets from SF1
   |  10  | 251 |  01:43:45:67:89:a3  |
   |  40  | 251 |  01:53:45:67:89:a4  |
   |  50  | 200 |  01:63:45:67:89:a5  |
   |  ...                             |
   |  15  | 212 |  Null (end of path) |
   +----------------------------------+

If you notice, an SFF doesn't even need to know which next hops are SFs and which are SFFs, since the same forwarding table applies to both.
This works because the SF decrements the SI, so the returning packet is not the same.

In each forwarding step, the packet has the source MAC of the sender and the destination MAC of the next SF or SFF.

-Dave


From: Reinaldo Penno [mailto:rapenno at gmail.com]
Sent: Friday, August 21, 2015 1:21 PM
To: Zhou, Danny; Dave Dolson; Keith Burns
Cc: opendaylight sfc
Subject: Re: [sfc-dev] [SFC] Why doesn't OpenDaylight use Ether/NSH encapsulation?

One thing is not clear to me in this pure L2 approach.

If you are using L2+NSH and the source inserts the destination MAC of the end host in the L2 frame, how would packet be forwarded hop by hop?

The first SFF would need to swap the MAC address in the frame by the MAC address of the SF.  Where it would preserve the original MAC? Would it add to the metadata? Or save it on a per RSP basis?

I know there are many approaches to solve this problem, but which one is folks are recommending and what is the impact in OVS?

Thanks,



From: "Zhou, Danny" <danny.zhou at intel.com<mailto:danny.zhou at intel.com>>
Date: Tuesday, August 18, 2015 at 6:14 PM
To: Dave Dolson <ddolson at sandvine.com<mailto:ddolson at sandvine.com>>, Keith Burns <alagalah at gmail.com<mailto:alagalah at gmail.com>>
Cc: opendaylight sfc <sfc-dev at lists.opendaylight.org<mailto:sfc-dev at lists.opendaylight.org>>
Subject: Re: [sfc-dev] [SFC] Why doesn't OpenDaylight use Ether/NSH encapsulation?

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> [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
_______________________________________________ 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/20150821/1d8e4ce2/attachment-0001.html>


More information about the sfc-dev mailing list