Peter Memishian wrote:
Yes, Erik and I spoke about this last week. My take is that interface
up/down is an unnecessary administrative concept and that address up/down
has more value. That is an administrator should not need to concern
themselves with whether an IP interface is up for the same reason they
don't concern themselves with whether a datalink is up today. Instead,
this can be something managed by the operating system internally (e.g.,
if an address is up, then the operating system can bring the interface
up -- this is not something the admin needs to be involved in).
I note that the above, as stated, is your take, and not a summary of our
discussion.
As far as address up/down goes, my take is that (a) the operating system
will need to have this concept internally to support DAD
Why is that?
I see no problem having IFF_DUPLICATE (which maps to the duplicate value
in IpAddressStatusTC) to mean that the address isn't usable.
There is an issue of how applications (which use SIOCGLIFCONF and/or
routing sockets) make sense out of the addresses it finds out, and I
think there is room for improvement in that space.
and (b) if you
have it then it's easy to do things like retry DAD or temporarily disable
an address without having to add more subcommands or force the admin to
tear down the related address configuration (e.g., deprecated markings,
shared-stack zoneid and so forth). It also is a closer match for the
way the stack currently behaves and thus has fewer warts.
Let last sentence made made me laugh. I hope you don't consider the
current behavior of the stack in this respect the gold standard.
All that said, I think the default should be for addresses to be up --
that is, the admin should not need to go through an explicit "up" step.
Agreed.
Removing this step simplifies the process without removing the utility
of address up/down.
I still don't see sufficient utility to have a concept which is
different than everybody else and can't be represented in the MIB.
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
