[ovs-dev] Support for LISP Control Plane
Vina Ermagan (vermagan)
vermagan at cisco.com
Tue Jun 4 22:18:15 UTC 2013
On 6/4/13 3:07 PM, "Jesse Gross" <jesse at nicira.com> wrote:
>On Fri, May 31, 2013 at 11:50 AM, Vina Ermagan (vermagan)
><vermagan at cisco.com> wrote:
>> Hi All,
>> This is a follow up on the discussion in late January about next steps
>> LISP support in OVS. We want to start executing on the medium term
>> namely support for LISP control plane (I copied the past conversation
>> 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.
>> 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
>> 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
>> a light weight LISP cp. Thoughts?
>> If this sounds good we can put together a more detailed plan on
>> vswitchd, and share it sometime next week.
>Sorry, I was traveling last week and am just catching up on email.
No worries, thanks for your response.
>I think either approach is fine and, as you say, they aren't mutually
>exclusive. My only real concern with the second one is that we make
>sure that it is designed in such a way that it is modular - otherwise
>as we add support for more protocols the code will become difficult to
Absolutely right, modularity is a must. Great, then we will start looking
into it and will discuss the implementation plan in more detail on the
list before moving forward.
>Out of curiosity - I know that LISP has several more components in the
>dataplane that aren't implemented currently. Is the protocol useful
>without these or do you have plans to implement them?
Once the basic control plane is implemented, the protocol is useful for
sure. There are a few more flags on the dataplane defined in the RFC, but
most of those are rarely used. There are other components, such as
re-encapsulating tunnel routers (RTR) which can, for instance, be used for
NAT traversal; but the protocol is functional in many use cases without
More information about the dev