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

Robin Whittle <rw@firstpr.com.au> writes:
> Whether a LISP or Ivip ITR uses push (has the complete database at
> all times) or pull (has to query, learning not to query about
> prefixes for which it recently got a "not mapped" response), the FIB
> function has a lot of work to do and a large amount of data to
> store.  My current feeling is that this can and should be done by a
> smaller number of really advanced routers, such as the CRS-1, with
> lots of memory and flexible dedicated CPUs (188 32 bit CPUs on a
> single ASIC, the world's largest) - rather than on a larger number
> of smaller ones.

I think that as an employee of a hardware company, selling big hardware is
a good; however, in practise, 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..

The typical arguments against pull solution are as follows:

- there is connection delay

- routers cannot store packets due to NGbps interface(s) it is saturating

 - => there is packet loss if the router in middle needs to do lookup

However, the connection delay is there already in significant number of
cases (DNS), and it isn't making the world a much worse place.

About the packet storage, or percentage of meaningful packets that need to
be stored during pull lookup - in typical case, 

- frequently more than one connection per destination, (HTTP, FTP, some P2P
  protocols),

- more than one source per destination, (some destinations being more equal
  than others), and

- traffic would most likely stop around first packet until lookup was
  completed anyway due to very few protocols blasting (meaningful) traffic
  without replies from the other end. (in case of HTTP, the client wouldn't
  even open more connections before the first request completes.)

I know for a fact that the ~1 packet caching pull has been used in
on-demand L2TP and VPN solutions. I'm curious about how the numbers would
work in core or large customer networks though. Anyone have any concrete
data? 

For anything smaller scale, it is clearly doable given modern hardware. 

Cheers,

-Markus

(*) I tried to look up some on the intarweb, but unfortunately all netflow
repositories I could find seemed to be of 'if you are researcher, snailmail
us with application in triplicate for processing' nature..

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