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

[Michael <mahuaiyuan at huawei.com>]

Hi, Eliot, Iljitsch,

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. 

This would have some scalability issue, like RSVP soft state.


Michael


----- Original Message ----- 
From: "Eliot Lear" <lear at cisco.com>
To: "Iljitsch van Beijnum" <iljitsch at muada.com>
Cc: <ram at iab.org>
Sent: Tuesday, July 03, 2007 8:47 PM
Subject: 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
>

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