[rbridge] Preview of changes for VLANs, etc.

[Russ White]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> It's been a while since I looked at it, but it looked
> reasonable in terms of forwarding rules.  We've had 
> some discussions around minor issues but nothing to
> the extent of revamping the whole thing.

The draft has been updated to include the discussion of the last two
weeks, and the idea of including a vlan tag on all packets, unicast and
multicast, in order to get across broadcast links?

>> Why do you need the vlan context in the cloud? You are 
>> forwarding to an egress rbridge, not along a vlan.
> 
> You don't for unicast (assuming you're talking
> about the inner tag).  For multicast, it's needed
> as an optimization to limit propagation to only
> those egress RBridges that are interested in 
> the frame.  A lot of this information is discussed
> in the draft.

But, the recent discussion has been to add it for _all_ packets, unicast
and multicast.

First, I think we may have overoptimized for multicast--when we get to
the point where we're adding context that's no needed in unicast to
optimize for multicast, we're eating the bandwidth we thought we'd be
saving through the optimization. Second, I think we may be overthinking
the problem in general. There's no reason, I don't think, for vlan
context tags even for multicast within the rbridge cloud. I suspect a
lot of this doesn't revolve around multicast optimization, but rather
around the idea of having fully mixed rbridge/bridge environments.

:-)

Russ

- --
riw at cisco.com CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHMe8qER27sUhU9OQRAnIzAKDJSn+2i/3NlJCbIvX0Ab/G03yRNACg1hIL
Jxrd1GmKiZ1amTJx+W5Tk1Q=
=E9Hy
-----END PGP SIGNATURE-----