Re: [dhcwg] comments on draft-ietf-dhc-dna-ipv4-04.txt

[Ted Lemon <mellon@fugue.com>]

Some people have made a lot of what I would consider a misreading of 
RFC2131 - that INIT-REBOOT is optional.   I believe it's optional 
because some hosts may not have stable store, not because hosts that 
*do* have stable store should ever skip INIT-REBOOT.

I think that in order to get good behavior in the case where we have 
flapping going on on an 802.11 link, it's going to require a compromise 
on one of three directions.   The choices are (remember, this is just 
for 802.11):

- Try to do it right.   This means that when we see a change, we look 
for a new configuration but don't immediately throw out the old, in the 
sense that we keep the old address configured alongside the new, and 
only kill it off after a timeout has passed.   I don't think that 
anybody is going to implement this, and I'm not seriously proposing it 
- just wanted to mention it.
- Compromise in the direction of switching quickly.   This means that 
when we detect a possible change in attachment, we assume that the old 
connection is gone and never coming back.   So we throw it away 
immediately and switch.   MacOS X does this now.   My wife Andrea was 
unable to get her email for quite a while this afternoon as a result, 
because she has a Titanium, which has, shall we say, antenna issues.   
She kept losing her access point in the middle of downloading her 
email, so she got the same ten messages quite a few times before she 
gave up.
- Compromise in the direction of switching slowly.  AFAIK nobody does 
this now.   What this means is that when we notice a network 
transition, we keep it in mind, but don't try to reconfigure 
immediately - we wait 90 seconds, long enough for any active TCP 
sessions to time out.   If, during that timeout period, the old network 
comes back, we continue using it.   After this period has passed, we 
give up and move to the new network.

This is a point solution for 802.11.   I think that aggressive 
switching probably works fine for ethernet and similar media, because a 
change in media is usually a physical process.  The solutions proposed 
in DNAv4 having to do with not trying to reconfigure until we actually 
detect a new link, as opposed to the loss of the old link, make a lot 
of sense - this means that if the switch is power cycled, we don't lose 
our address, but if we're plugged into a different switch, we get a new 
address quickly.


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg