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 one.
this can be done, with the caveat that for routeadm backwards compatibility we'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 daemons. 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)-enabled" property query in the start method of the daemon. does this seem ok? > - 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. > So I'd much prefer to just see network/routing:default (where instance other > 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 also > a property group of static routes to add. hmm, mixing static/dynamic routing is not something that we've done in the past. 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 something along the lines of svc:/network/static-routing:default svc:/network/dynamic-routing:default or even svc:/network/routing:static svc:/network/routing:dynamic with this setup, we could add a require_any dependency to svc:/network/forwarding 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. alan This message posted from opensolaris.org
