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

Re: [RRG] ALT + NERD is inelegant & inefficient, compared to APT or Ivip



Robin,

On Jan 23, 2008, at 6:03 PM, Robin Whittle wrote:
I agree with you in some respects.  For LISP, the mapping data won't
change at a huge rate, and even though the mapping data is more
complex than for Ivip, the communications volume required is
probably not a problem for ISPs and for larger routers.

Wouldn't it be more correct to say that if you make the assumption that the mapping data won't change at a huge rate and/or the map itself isn't overly large, then it is probably safe to say that communications volume won't be a problem.

The problem I personally have is that I don't feel comfortable in making either of those assumptions. In fact, one might argue that making both of these assumptions is what has gotten us into trouble in the first place.

What do you think of the idea of making that query server function
available to nearby devices?

It is something I think should be explored.

Anyone who believes in a pure ALT system must be expecting end-users
to put up with initial packets being dropped or delayed so much as
to be useless or worse than useless if and when they arrive.

I will note that back when Proteon was the router maker of choice, it was fairly common for the first packet in a new incoming conversation to get dropped due to the need to do an ARP lookup, yet people got by (most didn't notice). As the technology improved, the need to drop packets waiting for ARP lookups was removed. It isn't clear to me why history wouldn't repeat itself.

There are probably no free lunches, but there are combinations of
techniques which work elegantly and efficiently by complementing
and/or supporting each other.

As others have noted, the downside is that you're adding a fourth vector the the triplet of (rate, state, latency), namely complexity. It may be that this is necessary and a mixed model is the best way forward, but it is yet another factor in a "no free lunch" tradeoff.

Probably the way to cope with the costs of handling large numbers of
end-user-generated EID divisions (micronets) and mapping changes is
is to have some kind of charging scheme for each mapping change.

I suspect along this path lay madness. Assuming the imposition of a particular operational business model in order to alleviate a downside of an architecture hasn't worked very well in the past.

Regards,
-drc


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg