(I was working through a holistic writeup of concerns and proposed resolutions, but will drop that for a bit to respond here.)
Alan Maguire writes: > hi Mike > > >- Multiple instances for IPv4 and v6 are bad: it's needlessly confusing > > admins with low-level details, and making it annoyingly hard to manipulate > > the service in what I suspect is the common use case: disable routing > > or enable it. i.e. that becomes multiple weird steps as opposed to just o > ne. > > this can be done, with the caveat that for routeadm backwards compatibility w > e'd > need to support "ipv4-enabled" and "ipv6-enabled" properties. v4/v6 daemons > could then query these properties on startup to determine if they run (so we > 'd > support the same level of granularity as before - we just wouldn't expose it > in > SMF) while disabling routing:default via smf would disable all routing daemo > ns. > we'd lose the ability to express the fact that a v4 routing daemon requires > ipv4-routing to be enabled to run, but can replace this with an "ipv4(6)-enab > led" > property query in the start method of the daemon. does this seem ok? To be clear, is your proposed model basically: - there's one 'big switch' routing:default service - routing:default contains configuration for what protocols to route - each individual routing daemon has its own service - individual routing daemons are dependent on routing:default - the routing:default service does magic enable/disable of the appropriate routing daemons ? (I'm not yet sure I'm comfortable with that, but want to confirm it's what you're describing before working though my unease.) > > > - I strongly agree w/ Jim about the semantic difference between forwarding > > and routing: he explained this earlier. Don't confuse or conjoin them. > > absolutely. now would it be useful to collapse the v4/v6 service distinction > here > also? i.e. we use properties to specify ipv4(6)-enabled, and if enabled the > appropriate ndd flags are set. Yes. > > > So I'd much prefer to just see network/routing:default (where instance othe > r > > than :default could be used by someone else to add another routing daemon > > or protocol that were a useful thing to do), and have it support properties > > to permit tuning v4/v6 separately if you truly feel that is needed, and als > o > > a property group of static routes to add. > > hmm, mixing static/dynamic routing is not something that we've done in the pa > st. > from an implementation perspective, it's certainly doable (the current > persistent storage location of static routes in /etc/inet/static_routes is > project-private, so moving these to SMF properties would be a fairly > simple change to "route -B"), but i'd like to see how other people feel about > this. > > if we wish to preserve the static/dynamic distinction, we could go for someth > ing > along the lines of > > svc:/network/static-routing:default > svc:/network/dynamic-routing:default > > or even > > svc:/network/routing:static > svc:/network/routing:dynamic Using instances is preferred over using the services, if I have to pick between the two. See below, though... > > with this setup, we could add a require_any dependency to svc:/network/forwar > ding such that for forwarding flags to be set, either > static or dynamic routing need to be enabled. this would also allow > users to control static and dynamic routing independently via SMF. ... but, what's the benefit of separate services/instances for static and dynamic routing? If there's no fault-boundary issues to consider (daemons which fail independently), it seems a property on a routing:default service is sufficient. liane -- Liane Praza, Solaris Kernel Development liane.praza at sun.com - http://blogs.sun.com/lianep
