[rbridge] Preview of changes for VLANs, etc.

[Russ White]

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


> - For ports that support both bridged and TRILL
>   traffic we have to go with what 802.1 says
>   (otherwise the traffic won't go through bridges).
> 
> Thus far, all RBridge ports are assumed to be 
> of the last type.  That means the encapsulation has
> to follow rules defined by 802.1 - i.e. you have
> a set of VLANs on that port.  We only transmit
> traffic on those VLANs.  Some of those VLANs belong
> to the "tagged set" in which case we transmit frames
> for those VLANs in tagged format; other VLANs belong
> to the "untagged" set in which case we transmit 
> frames without a tag.

In all implementations that I know of, such interfaces are always:

1. Trunk ports, which I've already covered.
2. A single physical interface with multiple logical "subinterfaces."

Can you point to a single case where a device can send multiple vlan
traffic on a single logical interface, or where it treats a single
interface as a link with multiple vlans while not calling it a "trunk,"
and putting special operational rules around it (such as no end host
devices)?

> I think what we have defined so far is fine.
> There is no need to change it.  Making it optional
> won't work.

What has been defined so far is very complex--you're recreating
subinterfaces without subinterfaces, for no reason I can see.

> Even routers have to follow those rules or
> their packets don't make it through the LAN!

Routers don't follow these rules.... They don't simply put "some random
vlan number" on any packet they are transmitting to "get the packet
through the LAN." There is no "common vlan" assigned to each link to
allow routers to communicate. There is no concept of a "single hello"
for multiple virtual topologies on a single link, with all sorts of
stuff added so everyone on the link knows which virtual network everyone
else is on.

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.

Whether or not there's a vlan tag that needs to be added plays no part
in the forwarding decision.

IMHO, rbridges _should_ operate as much like routers as possible, rather
than using some new forwarding paradigm. Once the traffic is placed in a
tunnel, it should be carried--as much as possible--just like an IP
packet is carried.

:-)

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

iD8DBQFHMQIxER27sUhU9OQRAo51AJ4wilUVzWflNoanrdcX7U/nCtICMwCbBog6
50JNAS2hu/otps6EXwSZ4lc=
=6yb5
-----END PGP SIGNATURE-----