Subject: [rbridge] RBridge: a case of study

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Sat, 3 Nov 2007 12:50:04 -0400

Hi,

See below at @@@

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of James Carlson
Sent: Wednesday, October 31, 2007 9:02 AM
To: Silvano Gai
Cc: Developing a hybrid router/bridge.; Radia.Perlman at Sun.COM
Subject: Re: [rbridge] RBridge: a case of study

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 not some new change just coming from Silvano. For some time
now the base protocol specification has assumed that all the islands of
a VLAN seen by an Rbridge get glued together. Bridges can keep them
apart because they are myopic. Rbridges have a global view and it would
add significant complexity to the protocol to somehow defeat the
automatic connection of station on a VLAN by Rbridges. This was
discussed extensively on the list including such ideas as adding a
further qualifying "island-ID" or something to the VLANID+Address that
are the current basis for TRILL routing. There was no support for such
added complexity.

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.

@@@ The only suggestion that was made to preserve VLAN islands was to,
in effect, create a bigger VLAN ID or other higher order qualifier on
top of the 60 bits of VLAN plus address. There was no support in the
working group for this suggestion.

@@@ Thanks,
@@@ Donald

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
_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: james.d.carlson at sun.com (James Carlson)
Date: Mon, 5 Nov 2007 10:21:03 -0500

> are the current basis for TRILL routing. There was no support for such

I'm asking about how Silvano Gai's diagram agrees with the current
spec.

According to the current spec, you have to configure any outer VLAN ID
number that's present.  It's in the realm of manual configuration and
thus doesn't violate anything the administrator has specifically set
up.

If I read Silvano Gai's diagram correctly, that configuration isn't
present.  Instead, the RBridges _automatically_ discover the
non-default connections amongst themselves, and use them as they see
fit.  (At a guess, they do so by sending Hello messages on all 4094
VLAN ID numbers.)

I'm not asking to have islands supported.  I agree that it'd be a
mess.  I'm asking whether he's assuming they'll always be
automatically glued together without manual configuration, even if
there are restricted outer VLANs.