Subject: [rbridge] VLAN tag for the encapsulated packets

From: rute.sofia at siemens.com (Sofia, Rute)
Date: Wed, 15 Mar 2006 10:31:48 +0100

Saikat,

the issues you are raising have in fact nothing to do with Rbridges but
with the regular operation of STP/RSTP, etc.
Answering your questions next, because there is no reason to do this on
the Rbridges mlist:

> 
> > In this case, you are talking about a LAN segment that is a link 
> > between RBridges R1 and R2.  Presumably is has other 
> connectivity as 
> > well (hosts, routers, other RBridges, etc.).
> 
> First, how many spanning tree instances will there be in this 
> LAN segment if some physical links (ports of legacy bridges) 
> are marked as VLAN1 and the rest as VLAN2?
> 

A VLAN is *always* associated to a ST. In other words, you cannot have a
ST extending for two VLANs. This is in fact why STP is not suitable for
scenarios where MSTP works better. Some time ago, I gave you an
unpolished draft of a document which summarized most of the approaches
and the differences between them. In this case you have to divert a bit
from the algorithmic part and dig deeper into the protocolar. When you
have a protocol that relies on multiple-STs, like MSTP, then you need of
course either 1) a generic ST where you perform the broadcasts -
forwarding of unknown/multicast traffic 2) two STs per bridge, etc.

For instance, MSTP creates several STs (different VLANs) which may or
not consist of the same bridges. This is great, allows load-balancing,
etc, but requires a different ST when traffic has unknown destination
(or multicast destination). So they do it with a common tree. The same
goes for GOE: they create, for known traffic, a ST instance (associated
to a different VLAN ID) per edge bridge, and then use a common ST for
backward compatibility and for unknwon traffic.

> 
> That's the problem. How do legacy handle a packet that has no VLAN ID?
> 

Trying to go to your issue about VLAN tagging (I did not fully
understand it, like the rest of the people). Rbridges performs Ethernet
*encapsulation*, not VLAN stacking. There is a difference. They may or
not rely on VLAN IDs, but can you please further clarify the question
you have?

Also, a remark: in the future, I hope that these type of questions can
first be exchanged among *us*, me included. It would possibly be
quicker...then, if I cannot answer some question you have about some
mechanism, there's the rest of the people :P

Rute

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Wed, 15 Mar 2006 10:46:24 +0100

I will not discuss the point, but only express the feeling that 
questions like this are  an indication that the combination of  spanning 
tree protocols, VLANs and  IS-IS  increases the complexity of the proposal.
Guillermo 

Sofia, Rute wrote:

>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

-- 
Prof. Dr. Guillermo Ib??ez
Departamento de Ingenier?a Telem?tica
Universidad Carlos III de Madrid
http://www.it.uc3m.es/netcom/
609177932