netdev - Re: Time to revisit LISP?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20161103.170018.314857405677363551.davem@davemloft.net>
Date:   Thu, 03 Nov 2016 17:00:18 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     tom@...bertland.com
Cc:     chris@...icalelegance.com, netdev@...r.kernel.org
Subject: Re: Time to revisit LISP?

From: Tom Herbert <tom@...bertland.com>
Date: Thu, 3 Nov 2016 13:57:59 -0700

> On Thu, Nov 3, 2016 at 1:37 PM, David Miller <davem@...emloft.net> wrote:
>> Userspace resolution of paths in response to data path signalling
>> simply does not scale and is fundamentally an extremely poor design
>> choice.  We're trying to move away from, rather than towards, these
>> kinds of architectures.
> 
> OVS is quite different I think. LISP is a specific resolution protocol
> of identifier to locator as opposed to be some open ended mechanism to
> resolve some arbitrary definition of flows like OVS. Also, I don't
> think there's any specific requirement in LISP that prevents on from
> implementing the mapping protocol in the kernel, it should just be a
> simple UDP communication.
> 
> Do you see anything in the protocol itself that would be a showstopper?

I'd have to see the code and how it works.  I can't review hypothetical
implementations.