On Thu, Aug 03, 2006 at 03:51:13PM -0400, James Carlson wrote: > Nicolas Williams writes: > > It may that we're stuck with this split, and stuck with it for good. > > But other routers don't have this split, and I find that cleaner. > > Exactly. > > And that's the hurdle that I've been talking about. The issue is > whether we really want to make the effort to bring those folks who > fear routing around to [my|our] way of thinking.
Well, OK, so we agree on what we'd like to see and you claim pragmatism. OK, I can be happy with that. As long as we considered the matter. > > But you could have a daemon manage static routes, and then later you > > might turn on an IGP, say, redistribute some or all of those static > > routes into the IGP, etc... With this static vs. dynamic+static > > dichotomy the switch from one to the other requires using different > > interfaces; that seems lame. Perhaps one would so rarely switch that it > > doesn't matter. > > It is lame. I'm not arguing that. Good, so I'm not alone in thinking it's lame. > > > > But won't these service names be Committed? > > > > > > I hope not. What could possibly depend on them? > > > > Scripts, profiles, people? > > I think we need to dive into the use-case a bit more. I don't think > that depending on routing makes any sense at all. I didn't posit any services that would depend on routing! > > > Possibly ... but I think that works only if we can sell users on the > > > idea of running a routing daemon for static routes. > > > > Er, you misunderstood. > > > > Suppose you have only static routes configured (beyond the default > > route). Then suppose the start method of this service added them to the > > forwarding table using the route(1M) command, and exited without > > starting any daemons -- that would be a problem if the service was not > > declared to be transient, no? > > Yes, it would. > > > Then consider the opposite. You have a dynamic routing protocol > > configured, so the start method should start a daemon. The service > > shouldn't be considered transient then, else it won't be restarted if > > the daemon dies. > > Indeed. But the users who don't like "routing" would be upset about > that daemon. Well, users have been upset about lots of daemons, e.g. rpcbind(1M) (OK, probably a bad example, historically). Will we not stand up and say "sorry, but that daemon, in the configuration you need, is safe to have around and, what's more, it's required." > > I'm considering the possibility of a service that decides, when its > > start method runs, whether it will be transient or not. > > "ick." Well, so, I'd rather have a daemon managing static routes and sitting there waiting for configuration changes. But I can well imagine future services that could benefit from being able to declare transient-ness at service start time. > > > I'm not asking about forwarding at all. I'm asking about dynamic > > > routing protocols. > > > > > > As I mentioned earlier, they're not the same thing, and actually not > > > related. You can do either one, both, or neither, as you choose. > > > > But this doesn't mean that you can't have one service -- the > > transient-ness issue would force you to have more than one service. > > That's one thing I'm getting at. > > I see. I think that's really an implementation detail. FMRIs are interfaces, unless in this case the routeadm command is intended to be the only Committed interface for managing forwarding/routing state and the FMRIs themselve Project Private, then I'd expect the FMRIs to be Commited also. Maybe that's the answer: the FMRIs in question should be Project Private because routeadm is the public interface. In that case I don't mind the split forwarding/routing split at all. Nico --
