Nicolas Williams writes:
> On Mon, Jan 28, 2008 at 04:58:28PM -0500, James Carlson wrote:
> >     dladm create-bridge [-t] [-R <root-dir>] [-p <priority>]
> >       [-m <max-age>] [-h <hello-time>] [-d <forward-delay>]
> >       [-f <force-protocol>] [-l <link>]... <bridge-name>
> 
> Will the future RBRIDGES project re-use the *-bridge commands or will it
> introduce new *-rbridge commands?

The former.

>  If the former, shouldn't all those
> STP-specific getops options be treated as properties instead because
> they may not have equivalents in RBRIDGE?

That should not be necessary, but it's a good question.  RBridges also
need to be able to act as traditional bridges in order to allow for
mixed-mode networks, and because some of the detailed operation of
TRILL requires STP data.  (In particular, you need to know the root
bridge node ID in order to detect whether there are RBridge links
attached to the same externally-bridged network but where filtering or
VLAN configuration prevents direct communication between the RBridges
themselves.)

We may need to add one or two new parameters here (not quite scoped
yet), but the STP ones should stay.

>  (Or for that matter, RSTP and
> MSTP, but I know nothing about them.)

RSTP is mostly a minor refinement on STP.  MSTP presents a more
substantial change: it allows the administrator to create a handful of
STP instances, and then manually assign VLANs to these instances.  The
idea is to allow for a few different possible topologies within the
network that somehow form the basis for selected sets of VLANs.

It looks pretty hard to administer to me, and substantially less
capable and flexible than RBridges.  I'm not entirely sure why you'd
want it, except perhaps to be buzzword compliant.  But if someone does
want it, then we may eventually need to do it.  The effect on the
configuration would be to need some way of assigning VLANs to STP
instance, which is what's outlined in this document.

-- 
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

Reply via email to