[rbridge] Preview of changes for VLANs, etc.

[Eric Gray]

Anoop,

	I think you make the mistake of thinking that - because 
all of the comments appear to be at a high level and none are
specifically calling out flaws in the existing text - there 
are no issues with the existing text.

	It may very well be the case that some of us feel that 
the existing text is heading in a way that will lead to a 
hopeless tangle and that pursuing detailed evaluation of the
existing text only helps to make that happen.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Anoop Ghanwani
> Sent: Wednesday, November 07, 2007 11:40 AM
> To: Russ White
> Cc: Developing a hybrid router/bridge.; Radia Perlman
> Subject: Re: [rbridge] Preview of changes for VLANs, etc.
> 
> > -----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
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>