[rbridge] Preview of changes for VLANs, etc.

[Radia Perlman]

Russ...as much as I share your love of the complexity of VLANs...

I think the reason RBridges are more complicated with the VLAN stuff 
than IP routers are
is that in IP a VLAN is an IP subnet, so a router would only be talking 
on a single VLAN
at a time over a particular port-as-seen-by-IP. If an IP node (whether it be
a router or a logically-multi-link endnode) were on multiple VLANs 
through the
same port, it would be configured so that the higher level software 
wouldn't have
to know anything about that stuff. If an IP node used a single port as 4 
logical ports,
by having each in a different VLAN, then each of those "ports" would be 
associated
with a single VLAN.

RBridges, on the other hand, like bridges, are simultaneously supporting 
multiple VLANs
over the same port. VLANs that the RBridge itself is not a member of in 
any sense -- just
that the RBridge is supposed to support to glue it to other pieces of 
the VLAN in other
parts of the campus.

Radia


Russ White wrote:
> -----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-----
>