[RRG] LISP-EMACS & LISP-ALT

[Robin Whittle <rw@firstpr.com.au>]

I will discuss my limited understanding of these two new facets of
LISP with respect to IPv4.  I also criticise LISP for being
over-complex - and contrast it with Ivip's simpler approach, which
is predicated on the idea that it will be practical and desirable to
rapidly distribute mapping data on a global scale.

I understand that LISP-ALT (AKA LAT = LISP Alternate Topology):

  http://tools.ietf.org/html/draft-fuller-lisp-alt-01

is a short-term (for deployment, or just for research) alternative
to LISP-CONS and LISP-NERD.

A new set of "LISP-ALT routers" is created, forming an overlay
network using GRE.  These LISP-ALT routers form a network using the
same IPv4 address space, but this is a different, separate network
from the global Internet.  This network runs its own BGP system with
a separate ASN number space, completely unrelated to the current BGP
and ASN numbering systems.  The connectivity patterns of these
LISP-ALT routers is somehow determined by address structure, rather
than physical proximity as it is in the current Internet.

ETRs are the authoritative source of mapping information.  (I don't
understand how this would work, especially with respect to
redundancy and the fact that ETRs may be cut off from the rest of
the Net.)

I understand that the purpose of the LISP-ALT network is to:

1 - Enable an ITR to send a packet it has no mapping for into the
    LAT network, which will tunnel it to the correct ETR - with the
    ETR returning mapping information which the ITR will cache.

2 - Enable the ITR to request mapping information.

3 - Something else in the 3 paragraphs after the "5" heading - to do
    with pushing mapping data to ITRs which want it.

There is also something in 5.2 (3.) about LISP-ALT routers acting as
a "proxy-ITR to "support non-LISP sites".  I understand this is to
handle packets sent from networks without any LISP upgrades -
specifically, without an ITR.  As I have written recently (mssg
529), I don't see how any such scheme can work unless the prefixes
in which EIDs are found are advertised in ordinary BGP - which is at
odds with the original conception of LISP.

There are so many options within this proposal, and so few examples,
 I can't clearly understand it.  However, I see there is no mention
of how to cope with MTU, PMTUD etc. problems and that there is no
discussion of why anyone would want to build this network.

As with the other LISP proposals (unless they adopt an "anycast ITRs
in the core" approach, as perhaps they might - see message 529) it
is not obvious how packets from non-upgraded networks can get to a
"proxy-ITR" so they can be tunneled to the correct ETR.

Since the number of separate micronets (see mssgs 533 & 535) and
therefore ETRs is likely to grow to vastly higher than the ~240k
prefixes of the current BGP system, it is not clear to me why BGP is
a good choice to cope with this larger number in the LISP-ALT
overlay network.  (I understand this new network has some
simplifications which might help.)

If the final desired result is LISP-CONS or LISP-NERD, I don't see
the point of creating some other architecture in the meantime.  It
is not clear how research with a temporary architecture can help
much with designing the final one, which is fundamentally different.

Overall, I think the LISP proposals (not so much NERD) are hard to
understand, with terse, conceptual descriptions with many options
and not enough examples.   While Ivip has quite a few elements, the
description is fulsome and the architecture can be used flexibly.
This is different from having a variety of principles which can be
combined in various combinations, as in LISP, to create
fundamentally different architectures.

I am surprised that Ivip remains the only proposal which aims for
fast distribution of mapping data to query servers and ITRDs all
over the world.  Bandwidth, RAM and CPU power are cheap and getting
cheaper.  So I don't think the future architecture of the Net should
be constrained by over-complex architectures which have only modest
aims regarding mobility and rapid delivery of packets - as if the
designers are scared by the apparent impossibility of doing what
Ivip aims to achieve.

I think part of the reason people are overly wary of data rates for
mapping updates is that the current BGP system is so awful at
propagating it.  This is a distributed system in which intentionally
dumb routers compare notes with their immediate neighbours - and in
time, often with fits and starts, the proper information eventually
propagates to all corners of the Net.  ("Proper information" is
whatever messages each router needs to make a good-enough decision
on where to forward packets addressed to each prefix.)

I think it will be practical to create a fresh architecture and a
fancy, fast, mapping data distribution system for what we all seem
to agree will soon be needed: a global network of ITRs and ETRs
which enables the main BGP system to keep on working without massive
bloat in the number of advertised prefixes.


LISP-EMACS ("EID-mappings Multicast Across Cooperating Systems for
LISP"):

  http://tools.ietf.org/html/draft-curran-lisp-emacs-00

does not seem to be tied to LISP-ALT, but shares with it the concept
of a global overlay network of routers, using GRE, with its own BGP
system.  In this case, the overlay network supports multicast, using
Bidirectional Protocol Independent Multicast (BIDIR-PIM):

  http://tools.ietf.org/html/rfc5015

which is an extension of Protocol Independent Multicast - Sparse
Mode (PIM-SM):

  http://tools.ietf.org/html/rfc4601

The idea is that an ITR which has no mapping for a particular EID
sends the traffic packet to this EMACS multicast system, which
quickly sends it to the ETR which has the authoritative mapping (and
I guess which is also the ETR which is supposed to handle the packet
- though it makes no sense to me to have mapping authority vested in
such far flung ETRs which are at risk of being unreachable) . . .
and that ETR sends back a message to the ITR with the mapping
information.  Therefore, the LISP-EMACS system is intended only to
handle a low volume of packets, such as the first one or few packets
which an ITR handles, before it gets the mapping information.

This seems somewhat nifty to me, but there are some scaling problems
 - and I think it is a lot of trouble to set up a whole global
network like this, with BGP, ASNs etc.

The problem LISP-EMACS attempts to solve - dropped packets when an
ITR has no mapping information - does not exist for Ivip, because a
caching ITR (ITRC) can always let a packet go if it has no mapping
for its destination address, knowing the packet will naturally flow
to an ITRD, including one outside the current network.  LISP-NERD
has all its ITRs being full database ITRDs, so I think LISP-EMACS is
not applicable to LISP-NERD.

I don't understand how LISP and APT work together, but APT has full
database default mappers in each ISP network - so I don't think an
LISP-EMACS-like system is needed with eFIT-APT.

LISP-EMACS does not solve the primary problem of LISP: that that
packets from non-upgraded networks will never find their way to the
EID addressed destination host, since (in the original conception)
the EID addresses are not part of any conventional BGP advertised
prefix.  (See http://psg.com/lists/rrg/2007/msg00529.html for
possible extensions to CONS and NERD to maintain BGP advertisements
for prefixes containing EID addresses.)

While I don't feel motivated to fully understand LISP-EMACS (or
LISP-ALT - what is the long-term value of it?) I do want to raise a
fundamental scaling / DoS problem.

The ITR gets the 32 bits of destination address and chops off the
least significant 16 bits.  This results in 16 bits 0.0 to 223.255 =
57,344 possibilities.  These 16 bits form the multicast address to
which the packet will be sent.

For instance, the packet is addressed to 44.55.66.77 and the ITR
multicasts it (to use the ID's example) to 238.1.44.55.

Every ITR which is expecting to be the tunnel endpoint for packets
to any EID in 44.55/16 is expected to join the multicast group for
238.1.44.55.

It is my impression that the LISP designers tend to think of
end-user networks similar to those today - which I guess typically
have 256, 512, 1024 etc. addresses.  However, I am convinced that
everyone will need IPv4 space for a long time to come, and that more
and more multihomed, portable address, end-user networks will be
using much smaller blocks of addresses, including 8, 4 and sometimes
1 IP addresses.

Let's say that in the hypothetical LISP future, the 44.16.0.0/16
prefix is all EID space, and that there are a mixture of micronet
sizes, from /20 to /30.  For instance:

   /20    4     (1/4 of the /16)
   /21    8     (1/4 of the /16)
   /22    8     (1/8 of the /16)
   /23   16     (1/8 of the /16)
   /24   32     (1/8 of the /16)
   /30 2048     (1/8 of the /16)

There could easily be more /30s or /32s - say:

   /23   32     (1/4 of the /16)
   /24   64     (1/4 of the /16)
   /28  512     (1/8 of the /16)
   /29 1024     (1/8 of the /16)
   /30 2048     (1/8 of the /16)
   /32 8192     (1/8 of the /16)

Each multicast group could easily have to handle the ETRs of
thousands of micronets - up to 10k or more. Each micronet is likely
to have a different ETR.  (Actually, each micronet typically has 2
or more ETRs in LISP - it is only Ivip which has a single ETR at any
one time for each micronet.)

There is the problem of churn in which ETRs these are - each ETR has
to leave or join the appropriate multicast group as end-user
networks change their set of ETRs.

My main concern is the traffic amplification which this multicast
system entails.  This is a burden for the multicast system itself
(resulting in massive amplification of a small proportion of
legitimate traffic packets), but also would be a powerful amplifier
for someone wishing to launch a DoS attack:

Simply have a modest botnet emit single, short, packets to random or
sequential addresses, and LISP-CONS ITRs (all of them caching) all
over the world would dutifully forward each packet to the multicast
overlay network, which would fan each packet out to a few thousand
or 10k+ ETRs.

By the way, it is not clear to my why nonces are unsuitable (4.9)
for securing mapping replies.


I think a lot of the options and complications of LISP are attempts
to fix problems which are inherent in its conception, including:

1 - An overly ambitious goal of removing BPG advertisements, when
    I think it would be fine to keep a lid on the current number, or
    accept a somewhat higher number, provided we can serve the needs
    of many more end-user networks.

2 - An overly cautious approach to the problem of distributing
    mapping information around the world - either with CONS,
    which does not attempt it, or NERD which does it very slowly.
    (TRRP generally does not attempt it and eFIT-APT intends to
    do it very slowly indeed, over the current BPG network - which
    is not necessarily a consenting partner . . . )

3 - Therefore, LISP mapping distribution is too slow to allow
    mapping database changes to be the means of implementing
    multihoming service restoration.  This leads to the requirement
    for more complex mapping information, ITRs having to make their
    own decisions about which of various ETRs is the best one to
    tunnel packets to etc.

My answer to these problems is a simpler architecture, with a
simpler database, simpler mapping information (just one ETR address,
nothing else) simpler ITRs and ETRs, almost no communication between
ITRs and ETRs (only for PMTUD) - as long as we can devise a system
for getting mapping data out to the ITRDs and QSDs in a few seconds.
 This will probably be less data than a single IPTV stream.

I am still thinking of the best way to do this, but it doesn't seem
impossible.  The data rate of the updates will be dwarfed by the
volume of traffic handled by routers in modest or large networks.
ITRs in smaller networks would be caching ITRCs or ITFHs, and use an
upstream network's QSD query servers.

  - Robin         http://www.firstpr.com.au/ip/ivip/



--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg