Re: [RAM] draft-lear-lisp-nerd-01

[Iljitsch van Beijnum <iljitsch at muada.com>]

On 13-jun-2007, at 16:27, Eliot Lear wrote:

> I've put together an internet draft that talks about a push-based  
> distribution method for LISP.  I call it NERD (Not-so-novel EID- 
> RLOC Database).

Hm, is it worth the effort to do push and:

   In order to specify a mapping it is important to understand how it
   will be used, and the nature of the data being mapped.  In the case
   of LISP, the following assumptions are pertinant:

   o  The data contained within the mapping changes only on  
provisioning
      or configuration operations, and is not intended to change when a
      link either fails or is restored.  Some other mechanism (via LISP
      or other) handles healing operations, particularly when a tail
      circuit within an service provider's aggregate goes down.

With this limitation, ALL encapsulation devices must somehow track  
the reachability status of locators. In my opinion, you're solving  
the easy problem here and leaving the hard one.

A better way to avoid solving the hard problem is to do pull and  
cache for some amount of time. That's probably not good enough for  
multihoming, but it is good enough for portable address space.

   This memo does not specify who the database authority is.  That is
   because there are several possible operational models.  In each case
   the number of database authorities is meant to be small so that ITRs
   need only keep a small list of authorities, similar to the way a  
name
   server might cache a list of root servers.

   o  A single database authority exists.
   o  Each region runs a database authority.
   o  Each country runs a database authority.

I REALLY don't like this. Whenever stuff comes together in a central  
place, that means the people that run that place are important, there  
need to be policies, arbitrary restrictions pop up etc etc.

The size figures don't seem to include data structure overhead.  
Depending on the allocation policies, these could be negligible or  
huge. I.e., a routing table for 2^32 /32s could be a 4 GB array, but  
a routing table for 200k prefixes of all possible sizes requires a  
good deal of overhead to accommodate varying prefix sizes and to  
compress unused holes in the address space.

   with 10% daily change spread over 24 hourly updates

This is a dangerous assumption if there are no mechanisms to enforce it.

Last but not least, doing the crypto for hundreds of megabytes worth  
of information that is signed could easily be a bottleneck.

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