Subject: Re: An approach for detachable interfaces.
To: Bill Sommerfeld <>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-net
Date: 11/05/1999 14:58:46

>Given what i'm proposing, plus appropriate support for userland events
>on card insertion/ejection and carrier detect and carrier loss, I
>think you can implement just about any policy you want in userland.

I'm talking about what happens when  there's tsill no userland
event support.

>Is there really a meaningful difference between
>	ep0 with parameter set A at home
>	ep0 with parameter set B at work.
>	ep0 with parameter set A at home
>	ep1 with parameter set B at work.
>if at most one card is ever inserted at any given instant?

Yes, there is.  If interface state is sticky *and* sticks to MAC
address, I do the static configuration `right', and I have ep0 and
ep1, ep0 gets the IP address, netmask, arp state for home, and ep1
gets the IP address, netmask, arp state &c for work.

Your way, I only ever have ep0. I can only identify one parameter set
with that interface. So *every* time I move (home to work, or work to
home), I *have* to change the `parameter set'. Every time. In which
case, what's the point keeping any state with the interface struct?

Which leads right back to doing the config dynamically: if you only
have one card and roam around with it, you pretty much *have* to do
that. Again, there's no point keeping interface state around if
you just have to change it on attachment.  

BTW, I agree that what constitutes ``attachment'' need not be the same
as popping a card in and out. But card-popping is what the Mosquitonet
design used, and it works damn well.  I can think of one case, even
for wireless, where card-popping is a better signal than media sense:
when you roam with wavelan from one campus to another, and the two
wireless domains use different 16-bit magic cookies.
Provided you can throw two wireless cards at the problem :-).

(BTW, the mosquitonet people really do end up with multiple instances