[ovs-dev] [PATCH 0/2] Add support for LISP into Open vSwitch

Kyle Mestery (kmestery) kmestery at cisco.com
Fri Jan 25 22:13:20 UTC 2013


On Jan 23, 2013, at 12:02 PM, Jesse Gross <jesse at nicira.com> wrote:
> On Tue, Jan 22, 2013 at 10:36 AM, Kyle Mestery <kmestery at cisco.com> wrote:
>> The following two patches provide support for the LISP tunneling protocol into
>> Open vSwitch. See the latest IETF draft for LISP here:
>> 
>> http://tools.ietf.org/html/draft-ietf-lisp-24
>> 
>> Kyle Mestery (1):
>>  Add support to the tunneling code for a "pre_tunnel" function.
>>    This allows the tunneling code to perform operations on the
>>    packet before the outer IP header is added.
>> 
>> Lorand Jakab (1):
>>  Add support for LISP tunneling
> 
> Hi Kyle,
> 
> I'm curious if you can share your long term plan for LISP.  In
> particular there are three areas that I was wondering about:
> * L3 support.  Obviously OVS is very Ethernet centric at this point,
> resulting in the need to play games with MAC addresses.
> * Additional LISP data plane support.  LISP encodes more control
> information in the protocol itself compared to the existing OVS tunnel
> implementations, which basically only have the tunnel ID.  It looks
> like this implementation generates nonces on transmit but otherwise
> doesn't try to handle the other pieces.
> * LISP control plane components.
> 
> What do you guys see as the ideal end result?

Hi Jesse:

We see the following as the plan for LISP in OVS. I'd be interested to hear
feedback on this.

Short term:
	Make use of the vport-lisp.c which Lori has worked on.

Medium to long term:
	The control plane comes into play here. We see 2 options:
		1. No map server, everything done with static flows. 
		2. A lightweight control plane for mappings lookup. This would allow
		     vswitchd to query a map server (open source or commercial) using
		     the LISP protocol (RFC 6830).

	Make OVS less ethernet specific. This work could be done in parallel to the
	above. I have not scoped this work out yet.

Our high level proposal of how to get this done:
1. Fix comments in Lori's existing patch with the hope of getting it into OVS. This
     does static flow programming and uses static MAC addresses.
2. Update this to work with the NULL port support coming into the tunneling code.
3. Add the control plane work:
	1. Provisioning via an external controller and a light weight EID-to-RLOC
	     mapping lookup in vswitchd.
	2. Hooks to allow for integration with an external map server.
4. In parallel, work on making OVS less ethernet specific.

Thoughts?

Thanks,
Kyle


More information about the dev mailing list