On (04/20/09 14:38), Peter Memishian wrote: > > > > such a DAD mechanism would look like if you had the ability to bring > > > addresses down/up with ipadm. (I haven't looked at the latest design > > > document, so apologies if it covers this). > > > > Not sure what you have in mind, but one of Erik's comments was that > > we should move away from the model of bringing addresses up/down > > (and instead focus on bringing the interface up/down) based on > > the assertion that if an address is undesirable, it should be deleted, > > not downed. > > 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 think both models have pluses and minuses.. wanting to mark a single address as up/down works better when you have a way of addressing a single address (done today as a logical interface). It also allows us sins like simulating the removeif of the 0'th address (without also tearing down all the other addressess), while we work on sorting out the other internal complexities with actual 0'th address deletion. (Whether the ability to hide the real sin is a virtue or not is another debate :-)) OTOH I might want to mark an entire interface as down if, for example, I want to disable any traffic on that datalink without incurring the overhead of unplumbing the link. > 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 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). I think Erik's point was that we should separate this enable/disable address knob for the kernel from the administrative enable/disable knob. For example, the kernel version could be like an IFA_RUNNING flag, whereas the administrative one could be an IFA_UP flag. > 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. > Removing this step simplifies the process without removing the utility > of address up/down. agreed. --Sowmini _______________________________________________ networking-discuss mailing list [email protected]
