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

Re: API, was: Question re HIP dependency & some architectural considerations

On 29-jul-04, at 15:10, Pekka Nikander wrote:

Please define "use multihoming". 

To me (and I may well be wrong), it looks natural for wedge/layer 3.5
solutions to maintain a host-to-host (or end-point-to-end-point)
state that is relatively independent on transport state.  That is,
such state is probably created on demand on first TCP connection
(or SCTP or UDP or ...) and it stays around some time after all
connections are known to be closed, just in case that there would be
more communication.

I think Marcelo has made it clear that something like this can only work securely when there is a strong binding between the identifier and the locators, if not the risk of long-time redirection is too big.

But even in a scenario like this and not a per-session one, I'm not very comfortable with mandating extra initial delays if they are avoidable. (I believe they are in a routable identifier setup (where strong bindings aren't easy to come by) but not with unroutable identifiers (which need the strong binding anyway).)

The trouble with doing something right the first time is that nobody
appreciates how difficult it was. - Walt West


Some people say that there there are two schools in CS in the US.
One is the MIT way, "do the right thing".  The other one is the
UCB way, "just do it".  I don't know whether the saying is true or
not.


In other words, I also see some value on incremental and partial
solutions.  Trying to do it right the first time, in a committee,
may well be pretty impossible.

The thing is, if you try to do something perfect you're likely to fail, but if you try to do something imperfect you're likely to succeed. The questions is whether the failed result from the former is better than the successful result from the latter.

There are very real costs involved with the additional steps in going back to add stuff later. There is no excuse for creating a standard with known and fixable (circumstances permitting) flaws, as this creates new legacy problems when the problems are fixed in a later version.