Subject: [rbridge] VLAN tag for the encapsulated packets

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Wed, 15 Mar 2006 11:35:30 -0500

Rute,

	I had a brief dialog with Saikat off-line and I think I
can explain the issue that relates to your question below.  In
a sense, that portion of this discussion does relate to RBridges.

	The problem is a result of a combination of confusion on
how VLAN aware bridges are supposed to work when the physical 
topology has bridges participating in multiple overlapping VLANs, 
and some practical implementation issues in these cases.

	Technically, each VLAN is supposed to be treated as if it
is logically distinct from all other VLANs - even when multiple
VLANs share the same facilities and devices.  Practically, this
can lead to difficulty in correctly handling "virtualization" of 
LAN resources - including VLAN aware bridges, links, etc.

	If the virtualization is done correctly, than the "shortest
path" across VLAN aware bridges and RBridges can never include a
bridge or RBridge that is not part of the applicable VLAN. 

	On the other hand, it is possible to produce a realistic
scenario in which the topologically shortest path (in terms of
the physical topology) between two devices that are part of a
specific VLAN includes one or more VLAN aware devices that are 
not part of that VLAN.  It is thus possible for implementations
to (incorrectly) determine a topologically shortest path that 
may take VLAN tagged frames across links/devices, where those
devices would not know what to do with them.

	This simply should not occur in implementations, because
- if it does - the virtualization of VLAN resources is broken.
For RBridges, the way to avoid this is simply not to consider
links that are not part of a specific VLAN when computing the
shortest path Ingress RBridge Tree associated with that VLAN.

--
Eric

-- [SNIP] -- 
--> 
--> 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?
--> 
-- [SNIP] --

---

From: riw at cisco.com (Russ White)
Date: Tue, 21 Mar 2006 08:35:35 -0500

I would say the simplest way to address this would be using the 
mutltitopology extensions proposed for IS-IS.... We might need to tweak 
them some, but, in principle, it's the same problem.

I have to poke at the IS-IS extensions draft:

http://www.ietf.org/internet-drafts/draft-ward-l2isis-01.txt

....anyway, I can look at making certain the extensions we're using 
includes the ability to use the multitopology stuff.

:-)

Russ

Gray, Eric wrote:
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge