[rbridge] Preview of changes for VLANs, etc.

[Russ White]

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


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

Since this is obviously not the forwarding path for rbridges, I think it
would be very useful if you could outline the actual forwarding path,
with all the possible "if" statements involved.

If an rbridge receives a unicast packet without a VLAN tag, it will:

1. Examine the local tree to determine the egress rbridge.
2. Examine the local tree to determine the next hop towards that rbridge.
3. Encapsulate the packet in a tunnel header with the next hop being the
egress rbridge.
4. (add another tunnel header to get to the next hop with a "common
vlan" tag, to "get through the network???")

If an rbridge receives a multicast packet without a VLAN tag, it will:

1. Examine the local tree to determine the set of egress rbridges.
2. Examine the local tree to determine the next hop towards that set of
egress rbridges.
3. Add a VLAN tag to denote the VLAN on which this multicast belongs.
4. (add another VLAN tag to get the packet to the next hop, one per next
hop????)

If an rbridge receives a unicast packet with a VLAN tag, it will:

....

If an rbridge receives a multicast packet with a VLAN tag, it will:


....

I think it would be very useful to combine all of this into a single
forwarding path, so we can see what the complexity of this proposal is.
It would also be useful to explain the full process from the attachment
of a new IS onto a broadcast link through the ability of that IS to
forward rbridge traffic--every step involved. Again, it would be useful
to see the complexity level involved of all the different pieces being
proposed.

:-)

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

iD8DBQFHMbMnER27sUhU9OQRAnaeAKCoxunj3mM6hoBXWZrrQ1ZWR1VzRQCgkiis
VpfuqQ3KpAOiHGKa4WZ+HMQ=
=nQ3o
-----END PGP SIGNATURE-----