[rbridge] RBridge: a case of study

[James Carlson]

Silvano Gai writes:
> James,
> 
> -- snip --
> 
> > 
> >   3.  Suppose we were to configure VLAN 7 within Cloud L.  Would you
> >       expect H1 to be able to access nodes within the backbone Cloud G
> >       at that point?  (I'm trying to figure out whether the "X" and
> >       "Y" interfaces are of fundamentally different types or if the
> >       RBridges are just bridges.  I suspect they're different.)
> > 
> 
> I have produced an updated drawing to cover the case of "hybrid ports".
> 
> http://www.ip6.com/example-v2.ppt
> 
> In this drawing I assume that H5 is able to talk with H6.

That new diagram still does not show the confusing situation that I
was referring to above.  In fact, it shows a situation that is
essentially _identical_ to the previous one you showed in terms of
added bridge functionality.

To replicate the confusing functionality, consider what happens when
adding a host (call it H7) attached to Cloud P.  Without VLAN 7 in
Cloud P, H7 will not be able to participate in VLAN 7 even though all
attached RBridges are in fact transiting VLAN 7 traffic on that
network.  If VLAN 7 is provisioned onto Cloud P (exactly how does this
happen?), then H7 can play.  I see no functionality comparable to this
in the existing draft.

The core change that I think you're asserting here is that when the
user deploys RBridges, the network automatically discovers all of the
far-flung and disjoint islands of VLAN ID usage, and glues those
together by tunneling over whatever VLANs might be in the way between
them.  It no longer matters what configuration separates them.

This is quite a departure from traditional bridging, and I think it's
likely to be both confusing and dangerous, so I'm not sure it ought to
be the default behavior.  In today's bridges, if I configure a trunk
port such that VLAN 3 traffic does not traverse the link, then --
quite simply -- no packets with VLAN ID set to 3 go over that link.
In the new model, that restriction does not apply.

If I say "allow VLAN ID 3," then both an O-RBridge (original RBridge
as I understood it) and the new G-RBridge (Silvano Gai modified
RBridge) will allow VLAN ID 3 across the link.  If I say "disallow
VLAN ID 3 and allow only VLAN 7," then the O-RBridge would stop
passing VLAN ID 3 traffic, but the G-RBridge would simply switch the
outer VLAN ID number and use VLAN 7 effectively as a tunnel to pass
VLAN 3.  The TRILL-encapsulated packets will have VLAN 3 on the inside
and VLAN 7 on the outside.

I'm not at all sure that's a good thing.  I can see why folks who are
struggling with the unkempt nature of VLAN ID provisioning across
complex (and politically divided) networks would be excited about a
"do what I mean" option -- particularly if it means that I don't have
to tell my local IT group to reconfigure switches to allow separated
chunks of my new VLAN to connect together -- but the side-effects seem
extreme.

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