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  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]
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.

Powered by blists - more mailing lists