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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20161103.163758.1592587767905993803.davem@davemloft.net>
Date:   Thu, 03 Nov 2016 16:37:58 -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 12:22:52 -0700

> For instance, one of the his questions is:
> 
> "What is to keep one from having to service a full Map-Request -->
> Map-Reply cycle for every packet received?"
> 
> This can be solved by judicious rate limiting, for instance the
> infrastructure I implemented to rate limit ILA resolver request could
> be applied here.

All of these things work great if you have tables that are either very
tiny or change infrequently.

But once you run into anything seriously dynamic, it has the same
problems that the routing cache had and OVS can have.

And for this reason things like the flow cache are on the chopping
block.  And frankly, I'd remove OVS from the kernel if I could.

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.