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

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

On 3-jul-2007, at 14:47, Eliot Lear 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.

Actually not as much work as you may think:

http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure- 
detection-08.txt

This does pretty much what's needed here. It would have to be adapted  
to run between middleboxes and to make sure that only active  
communication is monitored which means you don't detect a failure  
until you first try to communicate. But I guess that's a reasonable  
limitation.

> > 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.

Hence my reluctance...

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

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

In transit, but in the systems it must be easily searchable, which  
means there will be additional overhead.


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