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

Re: Phase 1 KB lifetime

>>>>> "Dan" == Dan Harkins <dharkins@network-alchemy.com> writes:

 Dan> On Wed, 19 Jan 2000 13:31:25 EST you wrote
 >> ...
 >> What about people who want to delete their phase 1s under low
 >> memory conditions? ...

 Dan> Those are quite different that what you said. And it is not at
 Dan> all what I said.

 Dan> You can delete your SAs anytime you want. You can set a panic
 Dan> timer to reboot your box every hour on the hour. That does not
 Dan> violate the protocol. What I was saying is that when someone
 Dan> sends you a message telling you that the lifetime you just
 Dan> negotiated should be less you should not just skip over it and
 Dan> go merrrily on your way assuming that the SA will be deleted
 Dan> when, in fact, it will not. That way lies problems.

If the other end tells you it's using a smaller lifetime and you
ignore that message, this means you will be assuming the SA will not
be delete when, in fact, it will be.  The reverse of what you said.

That puts the protocol in the same state as the examples Andrew
mentioned.  Which is why I said what I said -- it seems overkill to
add a protocol mechanism that blocks ONE of the possible transitions
into state X without affecting a half dozen transitions into that same 
state X.  Yes, as Shawn pointed out, state X is not a good place to
be, since the protocol doesn't necessarily recover nicely.  But as
you said, you are allowed to go there.

 Dan> I'm not talking about forbidding perfectly common sense things
 Dan> (which, by the way don't really have much to do with the
 Dan> protocol) I'm talking about requiring perfectly common sense
 Dan> things (which do).

That depends on which aspect of common sense you're after.

One aspect says "take action on all the information you have".  This
is what you advocate.

Another view says "do not add complexity if doing so doesn't gain you
much".  This is my point -- the global state machine still has the
same number of states, and in particular still has the same
undesirable state.  There are still plenty of ways to get into that
state. 

Now, if there were a proposal to get rid of this state, and a
requirement to synchronize expirations comes as part of that, that
would be a different matter, but I don't see that that's particularly
doable.  (More likely we'd have a way to recovery quickly from getting 
into that state -- in which case it doesn't much matter if there are 5 
or 6 ways to get there.)

	paul
Follow-Ups: References: