Peter Memishian writes: > > > The following document describes the changes to dladm and SMF that > > we're proposing for the RBridges project. We'd appreciate any > > comments you might have on this plan (either privately or on any of > > the open lists) prior to submission for ARC review. > > The proposal seems pretty reasonable on first read to me. A couple of > comments and questions: > > * Given that bridges represent an entirely new type of object, > was consideration given to a bridgeadm command? If so, what > were the factors that ultimately swayed the team to extending > dladm?
I should have included that in the "Alternatives" section. Yes, we considered that. The main problem is that the configuration of the bridge would end up being split between two different utilities in a somewhat incoherent manner. Why would IEEE 802 aggregations be part of dladm but IEEE 802 bridges be configured elsewhere? Parts of the configuration of a bridge (such as the set of allowed VLANs and the default VLAN tag for a given link) are naturally part of the link configuration, and not a common property of the bridge. The creation of VLANs (logically located "above" links and bridges) and regular Ethernet links (logically located "below" VLANs and bridges) via dladm while bridging itself is in bridgeadm seems like a very strange result. We could create a separate bridgeadm, but then we'd likely have to deal with the VLAN issues some other way ... and I don't see a way that's anywhere near as clear. Most likely, I think we'd end up with either duplicate configuration in bridgeadm or the bulk of bridge configuration actually going on in dladm per-link properties, and only bridge create/destroy done via bridgeadm. In other words, there are several IEEE-specified parameters for bridges, but they're rarely of much interest, so that utility wouldn't do very much. The main thing users need to manipulate for bridges are the VLANs, and we need to figure out how to represent that manipulation. I choose to equate dladm-created-VLAN with bridge-allowed-VLAN because it seems to produce the most natural results: there's only one way to "create" or "destroy" a VLAN. The alternative is to break those apart, and allow users to create VLANs for potential use with IP via dladm, and separately assign VLANs to bridge ports via bridgeadm, but that runs the _very_ likely risk of misconfiguration: either forgetting to enable a bridge link for a VLAN while having IP plumbed atop, or thinking that destroying the VLAN removes it from the bridge. Since neither scenario seems to be particularly useful, allowing for them doesn't seem like a good goal. Or, for a really short answer: dladm is the location of all things datalinkish, and bridging is (like VLANs and aggregations) a datalink function. > * As is noted, the bridge name needs to be constrained due to > its observability device node name. Given that legal DLPI > character set is just [A-Z][a-z][0-9]_, it seems tighter > constraints may be needed to ensure compatibility. OK; seems reasonable. > * How will applications using dlpi_open() indicate they want > a node in /dev/bridge? For /dev/ipnet we're adding a > DLPI_IPNET flag; is DLPI_BRIDGE planned? Adding a flag like that seems like the right solution to me. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
