[rbridge] Preview of changes for VLANs, etc.

[Anoop Ghanwani]

> -----Original Message-----
> From: Russ White [mailto:riw at cisco.com] 
> Sent: Wednesday, November 07, 2007 6:44 AM
> To: Anoop Ghanwani
> Cc: Radia Perlman; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Preview of changes for VLANs, etc.
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > I thought that is what the draft does.
> 
> The current draft has all of these different forwarding modes in it?

It's been a while since I looked at it, but it looked
reasonable in terms of forwarding rules.  We've had 
some discussions around minor issues but nothing to
the extent of revamping the whole thing.
 
> >> If an rbridge receives a unicast packet without a VLAN 
> tag, it will:
> > 
> > Assuming we're talking about the inner tag...
> 
> No, the entire process. Look at the outer tag, determine it's 
> not the real vlan (how do you do this?), then you do x, then 
> y, then z....

Well, if the frame is not addressed to the RBridge,
or if it's not addressed to the All-RBridges multicast
address, then you pretty much treat it like
a bridged frame.  I really recommend reading the
draft.  Even in its current version it will tell
you a lot about the issues and the thought process
that has got us to where we are.

> What's the entire decision tree for all possible types of 
> traffic--not little bits and pieces of it, the entire thing? 
> IMHO, once you see the entire tree in one place, you're going 
> to realize this is a very complex forwarding mechanism, 
> compared to anything currently running.
> 
> Forwarding hardware eats power, space, and cooling. Simple 
> forwarding processes are better than complex ones, where you 
> have to do a lot of peeking and poking to figure out what to 
> do with a packet.

No argument there whatsoever!

> > The problem with special casing the no-VLAN case is that we're now 
> > build a new type of bridging that combines 802.1D with 
> 802.1Q, and in 
> > the process will likely break both.  With 802.1Q a packet 
> always has a 
> > VLAN context.  With 802.D there is no VLAN context.  This matters 
> > especially when you encounter situations with the same MAC 
> addresses 
> > in different VLANs.
> 
> Why do you need the vlan context in the cloud? You are 
> forwarding to an egress rbridge, not along a vlan.

You don't for unicast (assuming you're talking
about the inner tag).  For multicast, it's needed
as an optimization to limit propagation to only
those egress RBridges that are interested in 
the frame.  A lot of this information is discussed
in the draft.

Anoop