Hi All, I am collaborating with Kyle and Lori on the LISP implementation in OVS. We are planing to start work on the LISP control plane in OVS, and it would be great if we can get some early feedback on the approach. There are a few options that I described below. Please let us know if you have any suggestions or thoughts on this.
Thanks, Vina Ermagan From: Vina Ermagan <verma...@cisco.com<mailto:verma...@cisco.com>> Date: Friday, May 31, 2013 11:50 AM To: "<dev@openvswitch.org<mailto:dev@openvswitch.org>>" <dev@openvswitch.org<mailto:dev@openvswitch.org>> Cc: Lori Jakab <lja...@ac.upc.edu<mailto:lja...@ac.upc.edu>> Subject: [ovs-dev] Support for LISP Control Plane Hi All, This is a follow up on the discussion in late January about next steps for LISP support in OVS. We want to start executing on the medium term plans, namely support for LISP control plane (I copied the past conversation below for reference). We are interested in your feedback on this. We see two non-exclusive approaches to enable LISP cp in OVS: 1 – Use Open Flow to query the OF controller and install new mappings. This requires support for the flow-based tunneling (action=set_field:<OVSx_IP>->tun_dst) in open flow protocol/controller. 2 – Extend vswitchd to support a light weight LISP cp, enabling vswitchd to query a (open source/commercial) LISP Map Server using the LISP protocol (RFC 6830). We are thinking of starting with the second option, extending vswitchd with a light weight LISP cp. Thoughts? If this sounds good we can put together a more detailed plan on extending vswitchd, and share it sometime next week. Thanks, Vina >On Fri, Jan 25, 2013 at 2:13 PM, Kyle Mestery (kmestery) <kmestery at cisco.com<http://openvswitch.org/mailman/listinfo/dev>> wrote: > On Jan 23, 2013, at 12:02 PM, Jesse Gross <jesse at > nicira.com<http://openvswitch.org/mailman/listinfo/dev>> wrote: >> On Tue, Jan 22, 2013 at 10:36 AM, Kyle Mestery <kmestery at >> cisco.com<http://openvswitch.org/mailman/listinfo/dev>> 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? This sounds like a reasonable plan to me. Does it make sense to mark this as experimental or otherwise subject to change? It seems likely that there will be user visible changes as new pieces are added (for example, the changes to make it less Ethernet specific will affect the flows) and we don't really want to have to maintain backwards compatibility in that regard. The other area that I'm somewhat concerned about is with upstreaming. Once we get OVS for GRE and VXLAN upstream (which Pravin is working on now), the delta between the out of tree module and in tree module will be very small. I'd like to keep on decreasing the differences but we may want to wait a little while for LISP until we get down further down your plan.
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
