Alan Maguire writes:
> > - 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, I think it's useful.
We've suffered in the past from needless distinctions between v4 and
v6 (do I have to bring up the /etc/inet/ipnodes fiasco?) at just about
every level in the system. If we can manage to avoid those
distinctions where they don't make a difference, I think that'd be a
good thing.
This is a good instance of a distinction without a difference. From a
high-level view, you can forward or you can run routing protocols, or
both. The cases in which you want to say things like "I forward, but
only for IPv6" are relatively uncommon and seem to me like properties
rather than individual services.
> > 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.
This is actually related to one of my concerns about both the older
/etc/defaultrouter and the new static_routes file. More robust route
computation mechanisms (such as Quagga) use a different mechanism to
handle static routes, and the two aren't neatly tied together. This
isn't a big deal for the configure-once-and-forget-it sorts of
systems, but if you ever find you need to change from one to the
other, it's an annoyance.
I agree that it'd be nice to have a single service to represent "start
computing routes" and have the detail of whether those routes derive
from static or dynamic sources be just part of the service
configuration.
The only hesitation I have is that network and system administrators
tend to have a very different view of this issue. They tend to see
static routes as "no-ops" from a security point of view (incorrect,
but understandable) while dynamic routes are an "issue." Blending
them together makes sense architecturally and from a routing
propeller-head standpoint, but I wonder a bit about what the users
will think.
(As long as they use routeadm, and the right distinctions are made
there, the actual SMF service may matter less, though.)
> 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
It could still be done with properties, I think -- an enable_static
property and either an enable_dynamic or, perhaps better yet,
enable_{zebra|quagga|...} properties.
> 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.
The dependency becomes simpler if the static/dynamic issue is a set of
properties.
--
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
