[rbridge] Preview of changes for VLANs, etc.

[Russ White]

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


> I thought that is what the draft does.

The current draft has all of these different forwarding modes in it?

>> If an rbridge receives a unicast packet without a VLAN tag, it will:
> 
> Assuming we're talking about the inner tag...

No, the entire process. Look at the outer tag, determine it's not the
real vlan (how do you do this?), then you do x, then y, then z....

What's the entire decision tree for all possible types of traffic--not
little bits and pieces of it, the entire thing? IMHO, once you see the
entire tree in one place, you're going to realize this is a very complex
forwarding mechanism, compared to anything currently running.

Forwarding hardware eats power, space, and cooling. Simple forwarding
processes are better than complex ones, where you have to do a lot of
peeking and poking to figure out what to do with a packet.

> The problem with special casing the no-VLAN case
> is that we're now build a new type of bridging 
> that combines 802.1D with 802.1Q, and in the 
> process will likely break both.  With 802.1Q
> a packet always has a VLAN context.  With 802.D
> there is no VLAN context.  This matters especially
> when you encounter situations with the same
> MAC addresses in different VLANs.

Why do you need the vlan context in the cloud? You are forwarding to an
egress rbridge, not along a vlan.

:-)

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

iD8DBQFHMc8zER27sUhU9OQRArt9AJ0ebnvnnRhJeOKqiDDiLlCsU9UDvwCfTZmB
V/Ny5UnlRpFEW0/UgxROX1A=
=S3ar
-----END PGP SIGNATURE-----