Mike "Ford" Ditto writes:
> I think if there is any relationship between interface/address plumbing
> and milestone/network, it should be that milestone/network asserts that
> at least an attempt has been made to configure each interface as
> appropriate for the current profile.
It'd be good to have some sort of definition of what "an attempt"
means or doesn't mean.
> This will avoid a stampede of
> activity from well-written services that react to interface changes as
> they happen,
Well-written services understand the stampede effect. That's why most
well-written protocols include initial start delays and timing "fuzz"
factors. Dealing with self-synchronizing behavior on networks is a
fairly well-known problem.
> give the best chance of success for poorly-written services
> that need interfaces/addresses to be configured before they start.
Maybe. Though the utility of it seems quite limited to me. When the
things that must take place as part of this configuration are things
within the local system (for example, plumbing and configuring
interfaces with static addresses), there should be known deadlines for
when those operations will complete. When the things to take place
depend on external factors, such as router advertisements or DHCP, the
whole thing becomes either unbounded or just unreliable.
Moreover, when those things can be ripped away at a moment's notice
and we have no way to go back and restart or renew those "poorly
designed" applications, it's unclear what good we've done by trying to
protect them in the first place.
It's mostly the idea of having an unbounded dependency on external
behavior reflected into the internal operation of the system that
seems to me to be questionable. It makes some sense if you can
express a very narrow dependency ("I have an OSPF instance bound to
hme0, so that instance should wait forever for hme0 to go 'ready'"),
but milestone/network is such a broad stroke that I don't think it's
helpful, except for some special (albeit perhaps famous) cases.
--
James Carlson, KISS Network <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
