Re: [lisp] LISP SDN

Have to say that I agree with Lori on that point. 

It's possible to specify a flow based lisp, ie cached-lookup, pub-sub, as Dino says very accurately and consequently all around efficient low-cost, low-footprint hardware, high performance software on generic hardware implementation...
All that without committing to OpenFlow.

And it's possible to specify federated, data-driven, consistent distribution of OpenFlow based on distributed overlays, without committing to LISP (multicast transparent bridging, route-reflector as directory, or some other weird method).

Its probably a good idea to unify LISP & OpenFlow at least as a reference with consistent cross reference to tuples, transient aging time / watch-dogs, etc.    

But add text to the LISP draft that explains the generalization made here with respect to looking up whole network conversations in the mapping and not per-packet, and sticking to common conventions as to the definition of these conversations (TCP/UDP) for such and such time while active packets prolog aging..

In the flowMapping NFV specs we take the concepts further to per subscriber flow function affinity, function chaining, app specific mapping schemas..
But Alberto's draft is a much needed pre-step, generates the right discussion.

--szb

On Feb 18, 2014, at 3:39 AM, "Lori Jakab" <lori@lispmob.org> wrote:

> On 02/18/2014 01:17 PM, Alberto Rodriguez-Natal wrote:
> Hi Lori,
> 
> Thanks for the comments, see below.
> 
> On Tue, Feb 18, 2014 at 7:57 PM, Lori Jakab <lori@lispmob.org
> <mailto:lori@lispmob.org>> wrote:

[...]

>> Besides, please note that we may won't cover the same types that OF
>> covers. We don't want to compete with OF, but rather to complement it.
> 
>    I don't think you would be competing with OF by specifying the same
>    match types as the ONF does, you would be using (implementing?)
>    OpenFlow, and that would lead to less fragmentation and more code reuse.
> 
> 
> Don't get me wrong here. Maybe I explained myself poorly. I didn't want
> to say that we need to cover different fields. What I meant to say is
> that maybe we don't need to cover ALL the fields that OF covers. Perhaps
> a subset of those is enough for LISP. Of course, in the future maybe we
> see the need for covering more (all?) OF fields or maybe beyond OF ones.

Understand.

My main consideration here is that many (most?) SDN software packages
today (for whatever definition of SDN) has support for OpenFlow (mostly
1.0). Hardware is also starting to support OpenFlow. So I think that
simply from the implementation point of view you have an advantage if
you just can reuse a versatile existing matching engine.

> 
> 
>> It's about using the right tool for the job. OF is (generally
>    speaking)
>> focused on L2, while LISP is (generally speaking) focused on L3.
>    That's
>> why the 5-tuple makes more sense for LISP as a flow identifier than,
>> let's say, ETH or ARP fields. Hope I had brought some light here ;)
> 
>    Well, OpenFlow is slowly adding support for L3 only flows, and LISP is
>    slowly adding support for L2 encaps. 
> 
> 
> That's why I said "generally speaking" ;)

I thought so :)  But I still wrote the comment because I think we should
be forward looking!

Thanks for the discussion,
-Lori

_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp