Subject: [rbridge] VLAN tag for the encapsulated packets

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Tue, 14 Mar 2006 15:10:30 -0500

Saikat,

	Unfortunately, by demonstrating that the problem is
not related to operation of RBridges, you make it clear 
that most of this question is out of scope for this working 
group and this mailing list.  For the rest of the question,
see below.

	I'm happy to discuss this with you - to some degree
- off-line.  :-)

	This mailing list is not intended to be a forum for
discussing proper deployment, configuration and operation 
of VLAN equipment - at least not in the general sense.

	That includes specifically (but is not limited to)
how spanning trees work (or don't work) in VLANs involving
existing bridges.

	On the portion of the question concerning the way
in which RBridges that are not on a common VLAN will pass 
frames to each other, see in-line below...

--
Eric

--> -----Original Message-----
--> From: Saikat Ray [mailto:saikat at seas.upenn.edu] 
--> Sent: Tuesday, March 14, 2006 2:31 PM
--> To: 'Gray, Eric'
--> Cc: 'Developing a hybrid router/bridge.'; 'Radia Perlman'
--> Subject: RE: [rbridge] VLAN tag for the encapsulated packets
--> 

... [SNIP] ...

--> Now consider two RBridges attached to this legacy LAN, R1 
--> and R2. Now consider the case when R1 sends the first packet 
--> to R2 which have no VLAN ID. 

Why would this happen?  Some frame sender, somewhere, has to 
know that R2 exists or it would not have sent a frame to R2.

If R2 is known, then its VLAN context is most likely known as
well (R2's MAC would only have been returned in response to an
ARP in the approriate VLAN context).

Remember that a VLAN - like a LAN - is separated from other 
LANs (and VLANs) by a router.

--> At that time [bridges] on this [LAN] do not have an entry 
--> for the MAC address of R2 on their forwarding database.  
--> Thus they need to broadcast on the [LAN]. 

LAN and VLAN contexts are logically identical.  Entities are
either in the same (V)LAN context, or they are not.  If they
are not than they are not in the same broadcast domain and
broadcasts are not used to convey frames beyond the (V)LAN
context.

--> 
--> Which spanning tree will they use (I am assuming that there 
--> are two instances of the spanning tree, one for VLAN1 and 
--> the other for VLAN2)? 

The assumption that there are two spanning trees implies that
the bridges are aware (e.g. - configured) with VLAN information
at least relating to VLAN1 and VLAN2.  In this case, VLAN aware
bridges will not share broadcast traffic between VLANs.

-->
--> Now suppose that VLAN1 does not connect R1 and R2.

Then R1 and R2 are not in the same broadcast domain and
are _necessarily_ separated by a routing function.

In this case, R1 is part of one RBridge campus and R2 is
part of another.

--> 
--> Then if R1 sends a packet for R2 with VLAN ID set to 
--> VLAN1, or if the legacy bridges use VLAN1 for sending

If, by R2, you mean R2's MAC address, this will not happen.
For R1 to send a frame to R2 - in a different VLAN context
- R1 will address the frame to the router whose MAC address
in VLAN1 is returned by ARP when R1 (or the original sender)
first tried to reach R2 (by a higher level <IP> address).

--> a packet with empty VLAN tag, then how will R2 get the 
--> (encapsulated) packet from R1? Put it differently, how 
--> will R1 know that it must use VLAN2 as the VLAN ID to 
--> reach R2?
-->

---

From: saikat at seas.upenn.edu (Saikat Ray)
Date: Tue, 14 Mar 2006 15:18:24 -0500

> know that R2 exists or it would not have sent a frame to R2.

There is an aging mechanism on the legacy bridge entries. It is perfectly
possible that the forwarding entry had been deleted.