> > 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.
My point is that as far as an application is concerned, an address may not be usable. The significant cost is in managing the notion of such a state, and not in whether IFF_UP or IFF_DUPLICATE has to be checked to determine it (though IFF_DUPLICATE is even more peculiar to Solaris). > 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. Yes -- and we're overdue for some better APIs here. > > 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. Of course not -- but we also must not have a mismatch between our core APIs and the way the system actually operates. That is, if we're going to make fundamental changes to the way the system behaves, that needs to be reflected in the inner workings of the stack too. If making those stack changes are out-of-scope for Brussels II, then I think we'll make things worse. > > 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. How does the MIB represent an address that's failed DAD -- and why wouldn't the same representation suffice here? -- meem _______________________________________________ networking-discuss mailing list [email protected]
