[rbridge] Preview of changes for VLANs, etc.

[Russ White]

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


> The subinterfaces are there because an RBridge
> is also a bridge.  Just like a bridge has VLANs
> configured on ports, an RBridge will also have
> VLANs configured on ports.  The reason this is
> needed is because we have to know which VLANs
> are configured on a port when we receive
> a multicast packet from another RBridge that
> needs to be forwarded on the port.

I don't see where this matters.... All that matters is which egress
devices are within the correct vlan for the multicast packet you've just
received. You are forwarding to egress devices, not along vlans within
the cloud.

IMHO, this is why this entire confusion has arisen.... You don't need to
forward along a given tree, and along a given vlan, and glue vlans
together.... Choose one, not all three. The entire point of rbridges is
that the entire "core" of the rbridge network forwards towards egress
bridges, rather than mimicking the virtual topologies along the edge.
You're now introducing requirements to do both--treat the core as a vlan
free space, and only forward along vlans within the core.

It makes no sense.

> We are not talking about putting a random number.
> We are talking about putting some VLAN ID that is
> configured on the port.

The phrase "some random vlan number, just to get the packet through the
LAN," has been used multiple times on list. Second, restricting all
traffic flowing between any set of rbridges on a single link to one vlan
across that link makes no sense.

>> Routers operate exactly as I described previously. If a 
>> router receives
>> a packet on an interface, it will:
>>
>> 1. Find the next hop, by looking at the tree.
>> 2. Figure out the outbound interface.
>> 3. Encap the packet with the correct layer 2 header for that 
>> interface.
>> 3a. If the outbound interface is a subinterface, the layer 2 
>> header will
>> include, of course, a vlan header.
>> 3b. If the outbound interface is not a subinterface, the 
>> layer 2 header
>> will not include a vlan header.
> 
> I agree with this.

Then you don't need all this vlan stuff in the middle. You are
forwarding through the underlying cloud to the address of an egress
device. That address should be in the tunnel encap once the packet
enters the cloud.

It appears we are creating different forwarding rules for multicast than
for unicast, without considering the implications of such alternate rule
sets on the forwarding hardware, or the simplicity of managing and
troubleshooting this stuff.

:-)

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

iD8DBQFHMacNER27sUhU9OQRAufBAKCdPJ9VLoa+cP4Ue6RBuvzLpug37gCfer53
58WguUcL6VZD7VwTjnGT/Jo=
=hrXM
-----END PGP SIGNATURE-----