Apologies for the delayed response. Thanks for your time reading the draft and
for the feedback. See some comments inline.
On 3/5/18, 4:42 PM, "Tom Herbert" <t...@quantonium.net> wrote:
Thanks for posting the draft!
Overall, I think the approach straightforward, and it's very nice that
there is no change required to the ILA architecture.
I have some concerns about the LISP control plane in terms of
DOSability and scalability. Btw, LISP is not in Linux kernel because
of concerns about DOSability, so there was some prior discussion on
this topic in related mailing lists,
From the draft: "When an ILA-N has to send traffic towards a remote
Identifier for which it does not have the associated Locator, it has
to obtain it first from a MS."
This is not actually true. The forwarding cache in the ILA-N is a
routing optimization, if there is no entry on the cache then the
packet is forwarded. If it needs to be transformed then that will be
done by an ILA-R in the path. Until the cache is populated the routing
might be sub-optimal but packets still flow.
As you point below, we're not saying otherwise in the draft. Sending the
traffic to an ILA-R while the mapping is being retrieved is certainly an
option. We'll update the text to be clearer on this.
This is reflected below in: "While the mapping is being resolved via
the Map-Request/ Map-Reply process, the ILA-N can send the data
packets to the underlay using the SIR address."
I think it should be assumed in ILA that not queuing packets and not
dropping packets because of resolution are requirements (too much
IMHO, these should not be hard requirements. Leveraging ILA-Rs for mapping
resolution has another set of tradeoffs to be considered. An operator should be
able to decide which set of tradeoffs makes sense for his/her particular
If the map request is sent and the packet is forwarded, that means
that a packet received at the ILA-N can generate two packets to be
forwarded in the network. An obvious DOS attack is for a host to send
random to destinations in the network to try to generate cache misses.
Section 8.2 discusses this, but the solution to implement heavy
hitters counters is not detailed. It would be nice to see more detail
how this would work and how it will mitigate the DOS attack.
Heavy hitters counters are a well-known technique to mitigate DOS attacks in
the data-plane (used not only in LISP). There are several papers on that in the
literature, see  for a recent example. Regarding LISP in particular, you can
find some research on the modeling of the LISP map-cache in . Following
that work, we did some designs on how to apply heavy hitters counters to the
LISP map-cache back in the day. We'll try to make that research also available.
In ILAMP, a redirect method is defined. On a chache miss the packet is
forwarded and no other action is taken. If an ILA-R does
transformation it may send back a mapping redirect informing the ILA-N
of a transformation. The redirects must be completely secure (one
reason I'm partial to TCP) and are only sent to inform an ILA-N about
a positive response. To a large extent this neutralizes the above
random address DOS attack. There are other means of attack on the
cache, but the exposure is narrowed I believe.
That model is supported in LISP via the use of Map-Notifies. However, moving
the mapping resolution to the ILA-R comes at a cost. It's putting more load (in
terms of both data and control plane) into an architectural component that it's
not easy to scale out, since it requires (for instance) reconfiguring the
"LISP as defined in [I-D.ietf-lisp-rfc6833bis] runs over a UDP
transport, however the exact same signaling can be used over a TCP
transport without affecting the protocol operation."
What is the status of TCP support? I believe the trend in datacenter
control protocols is towards TCP and even RPC. Integrated security,
congestion control, authentication, and tooling are strong points in
favor of TCP. Is it reasonable to say that TCP is the preferred
protocol? Can the LISP message easily be converted to RPC (REST,
Thrift, GRPC, ...?
LISP can run as it is over TCP. It can also be extended with the mechanisms
described in  when a reliable transport is in place. If TCP makes more sense
for your particular scenario, then you can make it your preferred transport. In
general, which transport to use will depend on the characteristics of each
individual deployment. On you last point, please note that OpenDaylight already
supports LISP over REST .
Looking at the map-reply message format, I am concerned about its
size. By my count, it's 40 bytes to provide one record with one
locator where record and locator are 8 bytes. If we need to scale a
system to billions of nodes this overhead could be an issue even if
it's the control plane. Is there any plan to have a compressed version
of this. For instance ,if there is only one RLOC returned wouldn't the
priorities and weights be useless?
One thing that we can (and should) discuss is the best way to encode ILA
Identifier/Locators into LISP messages. Regarding removing fields from the
Map-Reply, I'm unsure that the cost of reducing protocol functionality,
increasing signaling machinery and adding parsing complexity is worth saving a
few bits. Specially if you are planning to later use an RPC version of the
Thanks again for your comments Tom. This is an interesting discussion :)
lisp mailing list