Subject: Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?)

From: [email-masked] (Noel Chiappa)
Date: Thu, 14 Jul 2011 18:07:50 -0400 (EDT)

> From: Ross Callon <[email-masked]>

    > The papers that I read both assume that the granularity of the
    > EID-to-RLOC tables will be the same as the granularity of the current
    > top level BGP routing table. If this assumption is wrong, then the
    > results will be correspondingly inaccurate.
    > To me it seems highly unlikely that this assumption is within an order
    > of magnitude of being correct.

Yes and no. The papers do assume that the granularity is basically (see
below) the same (i.e. the size profile of the mapping entries matches that of
BGP routing table), but apart from that, I'm not sure they support the
implicit contention that caches will therefore usually be much larger than
BGP routing tables.

Looking at, for instance, "LISP-TREE: A DNS Hierarchy to Support the LISP
Mapping System" (which has extensive trace-drive simulations) we read the
following (pp. 13, 16):

 "we removed from the iPlane dataset the more specific prefixes that are
  mostly advertised for traffic engineering purposes [2] and wouldn't be
  advertised with LISP. A total number of 112,233 prefixes are assigned
  based on originating AS to their respective xTR[s]
  ...
  During our simulations the maximum number of mapping cache entries reached
  was 22,993 and 15,011 for the two traces. This is an order of magnitude
  less than routes in the DFZ"

A couple of observations. First, the first step taken (dropping TE
more-specifics) likely biased their BGP dataset towards larger prefixes (i.e.
somewhat violating the assumption that "the size profile of the mapping
entries matches that of BGP routing table"), but I will hereafter ignore this
since it's probably second order.

The more interesting observtion is that the cache size (on two quite large,
eclectic sites) is a factor of at least 5 smaller than the overall routing
table. So even if there is some 'mapping table bloat' compared to the BGP DFZ
routing table as a whole (i.e. more mapping entries, system-wide, than there
are BGP routes), these measured results suggest that even a eventual overall
quite large bloat factor will still not result in tables that are larger than
existing BGP tables.

Of course, this 'downsized working set' pattern (which is a topic in itself,
which is not explored at length here - there are good reasons why most sites
will have smaller working sets, proportionately, in a growing Internet) will
not hold for absolutely all sites; large content providers will likely see
working sets which are much larger.  However, such sites almost always have
specialized infrastructure anyway, and it's not clear to me that their
inability to use 'off the peg' solutions which work for everyone else is
really a problem - it certainly doesn't seem to be for other aspects of their
operations.

	Noel

---

From: Damien Saucez <[email-masked]>
Date: Fri, 15 Jul 2011 21:38:38 +0200

Noel,

> since it's probably second order.

You are right, and we had a long discussion to determine if it was ok to
do so. At the end, I think that in the particular case of LISP-Tree it was
reasonable to do so. (i) de-aggregation is an artifact of BGP (e.g., impossible
to do requester specific Map-Replies, only one best route...) (ii) half of BGP
is /24, meaning that the other halt is not /24 and an important proportion of
the non /24 prefixes are less-specific than other BGP prefixes. (iii) the
LISP-Tree paper assumed that the prefixes could be assigned in a smart
way (no legacy). On the contrary the Conext'07 and Networking'11 papers
of Iannone et al. consider /BGP granularity as theses papers are focusing
on the cache stress, the results do not show a dramatic difference in the
results between the papers (one trace in the LISP-Tree paper comes from
the same network than in the "On the Cost of Caching Locator/ID Mappings
(Conext'07)" paper, except that LISP-Tree uses a more recent trace with an
higher bandwidth consumption so more packets).

> quite large bloat factor will still not result in tables that are larger than

Yes, and one even more interesting observation made by Luigi in his
Networking'11 paper is that even if we also install mappings for the incoming
traffic (for security checks) the size remains acceptable even though scans
were present.

So the conclusion I would have is that the cache size is not really a problem
as long as we ensure that it cannot be attacked (this is why we are actively
working on the security topic). And actually this result is not bound to LISP
or the cache technology but to the traffic's characteristic. Indeed, the traffic
is known to have a relatively strong spacial and temporal locality. So I think
that the real question with the cache is related to the mapping retrieval: what
if we do not have a mapping in the cache. Drop is not always a good option,
buffering is not always possible and forwarding is maybe not achievable for
scalability reasons (r.i.p. data-probe).

Thank you,

Damien Saucez