[rbridge] RBridge: a case of study
james.d.carlson at sun.com
Wed Oct 31 11:38:39 PDT 2007
Eric Gray writes:
> What we would be saying - if we specify what you suggest - is
> that the VID cannot change in going from A to B (or B to A).
> This ability to change VID values is consistent with
> existing device capabilities. There may be an administrative
> domain boundary at this device, or the device may provide a
> Q-in-Q function. If we are not saying this implementation
> will be non-conformant, it's unreasonable to disallow this.
I think there's a distinction to draw here.
If an implementation has some sort of VLAN mapping function beyond the
typical tagged/untagged distinction, that seems fine to me. The rule
should be written to allow such a thing, because it's trivial to show
that you could construct the same device out of a series of cascaded
That's not what I was understanding Silvano Gai to say. Instead, I
was understanding his proposal as a sort of "pernicious bridging."
By "pernicious bridging," I mean that the RBridge detects that it has
disjoint groups of interfaces in the network that have the same VLAN
ID configured. Based on this detection alone, it then finds shortest
paths between those locations. Where those paths cross an interface
that doesn't support the desired VLAN ID, we simply use a different
one -- perhaps chosen at random (Silvano's slides don't describe this)
-- and drive on.
If it's based on administratively-configured mappings ("VLAN 3 can
appear on this interface using VLAN ID 7"), then it doesn't sound at
all like a problem to me, because the algorithms and administrative
entries still make sense if you change all the numbers. If it just
"happens" by virtue of discovering disjoint VLANs, then I think it's a
> What I thought Donald meant by "the same" was not with
> respect to the "inner" VLAN ID - but with respect to all of
> the frames sent using a particular physical interface. That
> would be REALLY BAD. It would - for example - make it very
> hard to do as good a job with link utilization using RBridges
> as it is already possible to do using MSTP bridges.
Yes; that'd be bad.
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
More information about the rbridge