[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Iljitsch van Beijnum wrote:
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.

In part I'd have to say, "Guilty as charged", but I am thinking about the other problem. We'll need some sort of feedback mechanism between ETR and ITR to indicate when an ETR is or is not available. Dino has posited some form of ICMP unreachable message. Some people don't like ICMP. Another approach is simply a periodic acknowledgment of some form built into the tunneling mechanism, where one would expect an acknowledgment initially and then periodically. But I heartily agree this area needs more work.



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.

You live with these already from the context of the RIRs. However, I think it would be quite possible for these things to not be regionally based at all, and so you could shop for an authority whose policies you trust and like. I still maintain, however, that you want to keep the number relatively small or life gets ugly.



The size figures don't seem to include data structure overhead. 

The only overhead not included is database header, which is insignificant.

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. 

This seems overly complex.  We know how to store this stuff today.



   with 10% daily change spread over 24 hourly updates

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

Remember: this is a provisioned database. Show me a day in the last twenty years when the Internet's connectivity changed more than 1%.


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

You're not doing it that often such that it would matter. The only time you check the entire database is when you have none to start with. Otherwise you have an incremental update. However, suppose you didn't want to check the entire database. It would be possible to have signatures and versions of each EID entry. That would involve a fair amount more storage overhead, of course, and one would have to wonder if it were worth it.

Eliot

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