Peter Memishian wrote:
> > wanted to also get rid of the administrative-enable/disable-address knob
> > altogether (partially on the grounds that other Unix variants don't have
> > it, and partially on the grounds that it's more complexity). I think
>
> Yes, and that's a valid argument in defense of interface enable/disable.
> For example, routing daemons like quagga already have code to deal
> with interface up/down notifications, and have historically had to
> maintain special code to deal with the "address up/down" state.
Except that such code will still be needed to correctly deal with an
address that fails DAD -- which is my earlier point: you end up removing
flexibility without being able to actually simplify the architecture
because the state inherently exists.
We have that complexity today. What is broken today is that IFF_UP,
which means administratively enabled, has been overloaded to mean
operationally usable for an address since the kernel clears IFF_UP when
DAD fails. That overloading is highly undesirable and should be fixed.
Prior to that being fixed the admin interface works like this:
1. ifconfig bge0 addif 10.1.2.3/24 up
2. <time goes by, admin detects that IFF_DUPLICATE was set and fixes the
problem and wants to restart DAD immediately instead of waiting for IP
to do this with its timer. Admin does>
3. ifconfig bge0 up
Once the overloading of IFF_UP has been fixed then there will need to be
something else the admin types in #3 since IFF_UP would still be there.
If you suspend disbelief, once the above overloading has been fixed,
what benefits is there in up/down of an address?
> > being able to down/up addresses is both convenient (temporary disable
> > without teardown) and also a reasonable mechanism to do things like
> > retrigger DAD (not to mention that it's also going to still be possible
> > for some time to come via ifconfig), so I'm not in favor of that.
>
> If we separate the retrigger DAD functionality (which is relatively recent
> and afaict is not a documented interface) from the IFF_UP per address
> functionality, do we actually have a valid need to down an address?
As above, I see no value in that separation: we end up with all the same
complexity but less flexibility and generality.
Am I correct in assuming you are talking about implementation
complexity? I'm concerned about the complexity the admin needs to handle
and due to the overloading of IFF_UP that is a lot higher than it needs
to be.
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
