Nicolas Williams writes: > > I think that misses the point that some people are _really_ afraid of > > routing protocols. They like the fact that /etc/defaultrouter is a > > big hammer: it disables dynamic routing protocols. > > I thought that default routes (static or discovered through DHCP or what > have you) should be handled by a svc:/network/initial, say... > > > If you get rid of the big hammer, the first question will be: "so, how > > do I get this back, because I want to be really sure?" > > ...then your big hammer is: is the routing service's enabled/disabled > state.
I'm confused again. You've tied together forwarding and routing, so that I can't enable them independently, and you've tied together static and dynamic routing so that I can't control those independently either. So what good does a big hammer that smashes the system to bits (disables everything) do? > > Perhaps the answer is that we need to supply a service profile that > > disables all known routing protocols. > > Certainly when profiles can do more than enable/disable services we > could do that. In this case, that's all that needs to be done. I don't see why you'd need more here. > > When you are doing static routing _only_, you typically just arrange > > for a series of "route add" commands to get run at boot time, and then > > forget about it. That's what the new "route -p" option is about. > > 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. Given the lengthy history here (and the enormous amounts of FUD regarding dynamic routing), I'm not sure this is possible. But if you (and the folks proposing these changes) are willing to tilt at this windmill, I'll certainly cheer you on. I think you're in the right. I just don't think many customers (or even service folks) will agree. > > When you configure "traditional" static routes, you don't get any of > > that goodness. It's just a next hop and an interface. That's it. > > 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. > > > 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. In particular, if there are networking services that depend (in an SMF sense) on routing, then they're just plain broken, because there's no real way to do that. > > 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. > I'm considering the possibility of a service that decides, when its > start method runs, whether it will be transient or not. "ick." > > 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. -- 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
