Re: Attractiveness of LISP-NERD, was Re: [RRG] Is 12 bytes really so scary?

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

Hi Iljitsch,

I agree with you that the more complex (than Ivip) mapping data
formats, such as for LISP, could be structured in a reasonably
compact manner in a push situation (NERD).

That is an argument for push (NERD and Ivip), and against the
cumbersome, non-deterministic, global scale query networks of
LISP-CONS and LISP-ALT - which seem to be predicated on the
assumption that pushing all mapping data to a bunch of ITRs all
round the world is more trouble than it is worth.

Keeping with the "all-in-one" approach of LISP, you probably don't
need "fast" push (as Ivip is intended to do), because the ITRs are
supposed to figure out how to restore service via a second ITR when
the primary one becomes reachable.  So your proposal could lighten
the push data volume of NERD and/or enable it to scale to larger
numbers of ITRs and micronets.

The assumptions behind Ivip which make it very different from the
other ITR-ETR schemes to date include:

1 - It will be practical and desirable to push data fast to
    ITRDs and QSDs (local query servers with full databases)
    all around the Net, to support caching ITRCs and ITFH
    (ITRs in hosts, not behind NAT) which fast, low-cost,
    reliable, local access those QSDs.

2 - Doing it fast enables the decision about how to restore
    service to be made outside the ITR-ETR system.  The user's
    systems can do this, and drive the mapping database.  This is
    nice and modular, rather than monolithic with built-in
    multihoming service restoration functions like LISP, APT and
    TRRP.

3 - Then the mapping data can be really simple - making
    it faster to push.

4 - Then the system can provide a new, gutsy, IPv4/6 form
    of mobility with little change to mobile hosts and with
    no change to correspondent hosts.

So the challenge remains:  What is so difficult about fast pushing
12 or so bytes to ITRDs and QSDs all round the Net?  It is
non-trivial, but I don't see that it is so impossible as to justify
the great focus on pull systems.

Dino wrote (msg00860) he can send video these days:

> I wasn't able to send quality video about 12 years ago and I can 
> now. Technology upgrades allow this to happen.

So why do most folk in this field seem to assume that it is
unworkable to have a global, multicast-like, stream of mapping
updates, 12 bytes a piece?

2Mbps video would give over 20,000 mapping updates a second.  That
is 630 billion mapping updates a year.  One change of network every
3 or 4 days for every person on the planet.  With 240 million
micronets, this is a change in mapping every 3.3 hours.

There are not going to be massive peaks in mapping updates, since
the BGP system is the one which adapts to ISPs etc. changing their
advertisements and to actual router outages.  The changed mapping
will result mainly from mobile end-users (paying per change) and in
the rare instances where an ISP actually becomes unreachable, and
all the end-users currently using its ETRs change their mapping to
another ISP's ETRs.  That will have peaks, but not the storms and
waves of stuff which the BGP cellular automata generates whenever
there is an outage or change in router connectivity.


> And it (LISP-ALT) uses existing BGP to boot, so there are no
> guarantees we won't see all the unpleasantness we see in the
> current global routing table in the ALT overlay network.

Yes, and I take it you agree with my critique of ALT: that by
mandating aggressive aggregation of addresses, that the path to the
final authoritative mapping query server will necessarily be (often,
perhaps typically) geographically very long.


Regarding LISP-NERD being configured to be something akin to
LISP-ALT, with ITRs taking only a fraction of the mapped address
space, and with significant distances to those ITRs, I think this is
not really like ALT, because all the traffic needs to go to those
(typically) somewhat distant ITRs, whereas in ALT, only the "first"
packets (those the ITRs have no mapping for, but will have in a few
seconds) go via the ALT network.


>> Yet when the customer decides on a new ISP, they need to change
>> the IP address and the administrator of their ETRs.
> 
> Just go to your address provider, tell them the new addresses for
> your ETRs (either yours that have new addresses or your new
> ISP's), pay a small processing fee, wait for the update to
> propagate throughout the network in due course. (Having this
> happen every hour seems reasonable.)

Since the address provider is running some ALT router which
aggregates all the micronet address space of this MAB (Mapped
Address Block), assuming they need to have BGP links to the ETRs,
then this sounds like a major trust and configuration drama having
that ALT router accept BGP messages over the ALT network from this
often changing, globally dispersed, list of ETRs.  (Not to mention
the long paths which are possible or likely from the address
provider's router to those ETRs.)

However, I recall ALT allows for the authoritative query server(s)
to be some special server, not the ETRs.  In that case, my critique
doesn't apply.  In that case, the customer somehow gets their
mapping data to this query server, such as by using user names and
passwords.

But in that scenario, the authoritative query server still needs to
deliver packets to the correct ETRs, and my earlier critique applies
again - this ALT router is someplace, and the ETRs are generally
going to be far from someplace, so there is on average a fractional
global tunnel to each ETR to get these early packets to the host.
This is in addition to whatever number of typically fractional
global tunnels are between ALT routers higher up the aggregation
hierarchy, through which the hapless early packet, functioning also
as a map request message, must make its way.

 - Robin


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