[rbridge] Preview of changes for VLANs, etc.

[Russ White]

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


> a) all RBridges on a link can talk to each other using a single (outer) VLAN tag, and
> that VLAN is not allowed to be partitioned. If it is, whichever RBridges can't talk
> to the DRB on that VLAN are just orphaned. All the other RBridges send IS-IS
> messages (Hellos, LSPs, CSNPs) on that link tagged with the one VLAN tag.

Why have this vlan tag at all? If the traffic for any given vlan is
tunneled to the outer edge using the direct layer 2 address of the exit
rbridge, then the "outer" vlan tag is an unnecessary complication. The
simpler rule would be the only traffic on link which should have a vlan
tag will be that originating from a non-rbridge device. Once traffic
hits the first rbridge, there should never be an "outer" vlan tag, just
the destination address in the outer tunnel header.

All the other stuff you talk about seems to be much easier without this
outer header--the way IS-IS runs, the DIS election on each link,
forwarding, etc.

> f) Hellos shouldn't have to be bigger with this proposal. What's in a Hello?
> . my ID
> . my priority for becoming DRB
> . name of the pseudonode if I am DRB
> . VLAN tag "V" to use for outer VLAN tag on this cloud if I am DRB
> . set of neighbors I've heard Hellos from on the specified
> VLAN tag (V)
> . flag "please send CSNP" used when starting up, to ensure that
> you have synchronized LSP databases with your neighbors
> 
> Now there might also be the following in the Hello:
> . "Bidding for VLANs": If I'm not DRB, set of (priority, {set of VLAN tags}) that I would like
> to be assigned to en/decapsulate for

This does make the hello larger. Probably much larger....

> . "VLAN assignments" If I am DRB, en/decapsulator assignments, of the form
> (RBridge neighbor ID, {set of VLANs}) that I want that RBridge
> to encapsulate/decapsulate for.

I don't understand why we need this.... I don't think you're really
going to have a case where a single interface on the user side
"services" multiple vlans, which are generally separated at the edge
through virtual interfaces on the box. IE, if I receive a packet on
interface ethernet 1.1, then it's vlan x, if it's on ethernet 1.2, then
it's vlan y. There's no reason not to stick with this convention--the
chipsets already know how to separate things this way, I think.

IE, forwarding would look like this:

1. Receive packet on interface X.
2. Check to see if there's a 1q header.
3. If so, then look up appropriate edge destination, encap in a tunnel,
and resend.
3. If not, then find correct vlan, look up appropriate edge destination,
place vlan header on packet, encap in tunnel, and resend.

On the receiving side, you just strip off mac headers and process them
normally. There's no need for special processing of any type, is there?

I don't see anything about the "merging" vlans automatically.... I don't
think this should be done, in any case.

:-)

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

iD8DBQFHMHswER27sUhU9OQRAkk+AKDf3LMTQCXPCL3Z7vNy5mmZT9c7bgCfbldB
RYbmkapg1cE1sSlsgQNVneQ=
=1x27
-----END PGP SIGNATURE-----