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

Zhou, Danny danny.zhou at intel.com
Mon Aug 24 02:07:49 UTC 2015


Guys, I had summarized four dataplane options as below which might make our discussion easier. The control plane support in ODL should not be a big problem as long as we nail down the dataplane implementation. 

Option No.1 "Ethernet + NSH": Ethernet as the transport to carry NSH header. The NSH-aware VNF should be able to handle this type of Ethernet packet no matter DPDK is used or not. 
VxLAN header is added when necessary, for example, if SFF to SFF traffics needs to cross L3 network (in other words, they are not in same layer2 segment), the VxLAN header (rather than VxLAN-GPE) is added before the Ethernet-NSH header by the sending VTEP and removed by the receiving VTEP.

Option No.2 "VxLAN-GPE + NSH": VxLAN-GPE as the transport and packets from SFF to SFF and from SFF to SF are all with VxLAN-GPE transport. BTW, this is the only supported option at the moment by Pritish' forked OvS and current ODL SFC code base. Drawback is the VTEP of the receiving SFF needs to decapsulate (default behavior of any VTEP) tunneling packets followed by a VxLAN-GPE transport re-encapsulation plus NAT (e.g. changed destination IP and MAC of the packet to the one of next-hop SF hosted by the receiving SFF).
	
Options No.3 "VxLAN-GPE + NSH with decapsulation off VTEP knob" : A straightforward enhancement to option No.2 by enabling a decapsulation on/off knob to VTEP. When the knob is off, the receiving VTEP does not perform decapsulation for specific tunneling packet such as VxLAN-GPE-NSH packet with UDP DST port 4790. But it might be a little hard to convince vSwitch community to accept this.

Options No.4 "Mixed VxLAN-GPE + NSH and Ethernet + NSH": In this case, SFF to SFF traffics uses VxLAN-GPE transport, and SFF to SF traffics via Ethernet + NSH transport. The VTEP behavior is sort of bi-directional transport "translation" between VxLAN-GPE-NSN and Ethernet-NSH packets. The benefit comparing to option No.2 is that lightweight Ethernet transport better utilize bandwidth between SFF and SF, though conceptually it is still "decapsulation followed by re-encapsulation" implementation by VTEP. 

Any thought on above four options and any other option in you mind?

-Danny

> -----Original Message-----
> From: Dave Dolson [mailto:ddolson at sandvine.com]
> Sent: Sunday, August 23, 2015 1:43 AM
> To: Yang, Yi Y; Reinaldo Penno; Zhou, Danny; Keith Burns
> Cc: opendaylight sfc
> Subject: Re: [sfc-dev] [SFC] Why doesn't OpenDaylight use Ether/NSH encapsulation?
> 
> It can be used between any SFF and SF on the same layer2 segment.‎ Is this what you mean by "directly attached"?
> 
> Of course layer2 adjacency can be a virtual layer2 segment using VxLAN.
> But the difference is that the SF and SFF don't know about the VxLAN underlay.
> 
> 
> From: Yang, Yi Y
> Sent: Friday, August 21, 2015 8:02 PM
> To: Reinaldo Penno; Zhou, Danny; Dave Dolson; Keith Burns
> Cc: opendaylight sfc
> Subject: RE: [sfc-dev] [SFC] Why doesn't OpenDaylight use Ether/NSH encapsulation?
> 
> 
> I think ETH + NSH only can be used between a SFF and a SF directly attached to this SFF, if it is to be forwarded to next SFF,
> we still have to use VxLAN + NSH, Reinaldo, this is an answer to your concern.
> 
> From: sfc-dev-bounces at lists.opendaylight.org [mailto:sfc-dev-bounces at lists.opendaylight.org] On Behalf Of Reinaldo Penno
> Sent: Saturday, August 22, 2015 1:21 AM
> 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


More information about the sfc-dev mailing list