Re: [RAM] Ivip (was ViP ...)

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

Hi Markus,

You wrote:

> I think that it would be more reasonable to provide support
> for both pull and push, especially if you plan to add churn
> to the system. The churn numbers caused by more mobile
> (and/or TE-using?) users on centralized routers (and the
> communication channel between them used for 'push' traffic)
> would be insane, and non-core router could not handle that
> sort of non-scoped 'push' traffic anyway. The pure-push model
> with per-host information granularity sounds likely to make
> the scalability problem bigger, not smaller..

I agree there needs to be an option for smaller ITRs to operate
with less state and to use a "pull" query-based approach.

This would also enable a host to do its own ITR function.  If
this was implemented widely in operating systems, the system
(LISP or Ivip) would be highly scalable, since each host doesn't
have to store much state, unless perhaps it is a big server.

However, the system would still work fine for hosts without
built-in encapsulation.

Peer-to-peer file-sharing networks may send packets to lots of
hosts all over the Net.  This could be quite a burden on
LISP/Ivip compared to traditional two-way communication.


On one hand I am attracted by the idea of fewer really fast
ITRs, each with the whole mapping database in their FIB.  But
when I think about millions or hundreds of millions of separate
mappings, for individual IP addresses and for small and large
subnets, it becomes very daunting to receive these updates, and
to change the FIB accordingly, not to mention having an FIB
which could actually store them.

I think the FIB always needs to know what ranges of addresses
are being mapped via Ivip (the one or probably hundreds or
thousands of "master-subnets", each of which may be split into
different mappings).  Otherwise, whenever a packet arrives which
is not in one of these subnets and not matched by a BGP prefix,
the ITR has to query the central database.  The central database
would need to tell all the ITRs what subnets of the whole
address space are currently covered by the LISP/Ivip mapping
system.  I figure this would change only slowly.

When a "pull" ITR receives a packet whose destination is an IP
address within a "master-subnet" and the ITR doesn't have
up-to-date mapping information for that address, it queries the
central database (or a distributed database or whatever).  The
replies need to come with a caching time and a description of
the subnet they refer to.

For instance, if there is a subnet all mapped to the IP address
of one ETR and the ITR queries the database about a specific IP
address within this range, then the database needs to reply not
just with the IP address of the ETR, but with:

  This address to reach the ETR should be used for the range of
  IP addresses X to Y.
  Cache this result for 300 seconds.

If the database has no mapping for the IP address which the
query concerns, it needs to tell the ITR something like:

  There is no mapping for this IP address or for the surrounding
  range of addresses X to Y.
  Cache this result for 3600 seconds.

> I think that as an employee of a hardware company, selling big
> hardware is a good; . . .

I have some idea of the heroics of the CRS-1's 188-CPU ASIC and
its banks of reduced latency DRAM, running the Tree-Bitmap
algorithm:

http://www.firstpr.com.au/ip/sram-ip-forwarding/router-fib/#Cisco_CRS_1

The FIB of a busy ITR is a daunting prospect - and it must be
done with one or more CPUs and multiple fast RAM lookups using
something like Tree-Bitmap, because TCAM can't do it.  TCAM
can't scale to the number of Ivip/LISP mappings.  These will be
in the millions to hundreds of millions over time, and it has
some really nasty update gotchas when there is a need to move a
lot of rules to different locations in the TCAM.

I guess the CRS-1's SPP chip is highly flexible and would be as
good a basis for doing the fancy ITR FIB as any other piece of
hardware which currently exists.  Before deciding that LISP,
Ivip or whatever was the way forward, it would be best to have a
reliable estimate of how many mappings and packets per second
the CRS-1 MSC's Ingress FIB SPP system could be programmed to
handle.  I guess that new firmware would be required for the
best results.


At least the FIB, central CPU and communications heroics of a
LISP or Ivip ITR only need to be implemented on a fraction of
the routers in the Net.  Without something like this, we would
have to go to about this much trouble for all the DFZ routers
before too long.

As far as I know, the ETR function of decapsulating an IP-in-IP
packet is pretty easy.  Can routers with current firmware be
configured to do this?

Maybe the overall LISP/Ivip system would require some extra
functionality in the ETR, perhaps to confirm that the
destination host was reachable - if ping or some alternative
techniques were blocked for security reasons.


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










_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram