Hi Chris,
Looking at netdev archives I see that Dave's response to the LISP
patches from June 2014 was:
"Sorry, I'm not too thrilled about LISP and this patch in particular,
from several different angles. And therefore I'm going to mark this
patch deferred and not apply it at this time."
It seems to the me that he didn't close the door on ever accepting
LISP into the kernel! I am wondering if it is time to take another
look at this, I am starting to see that there is some existing
deployment of LISP.
AFAICT, most of the concerns Dave had were along the lines of the
infrastructure not the protocol. We might be able to address these
now.
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.
Thanks,
Tom
From: Tom Herbert <redacted>
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.
On Thu, Nov 3, 2016 at 1:37 PM, David Miller [off-list ref] wrote:
From: Tom Herbert <redacted>
Date: Thu, 3 Nov 2016 12:22:52 -0700
quoted
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.
One way or another we are going to have to deal with this. If we want
Linux to be serve as router for mobility it is going to have to scale
for having bunches of host routes and they will be quite dynamic
because of mobility.
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.
Quite frankly the DOS issues with OVS were obvious just by looking at
the initial design-- it should have been done better. Yes, if you
upcall every unresolved packet to userspace you're just inviting a DOS
attack.
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?
Tom
From: Tom Herbert <redacted>
Date: Thu, 3 Nov 2016 13:57:59 -0700
On Thu, Nov 3, 2016 at 1:37 PM, David Miller [off-list ref] wrote:
quoted
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.