Subject: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 20 Oct 2006 13:28:52 -0400

Dinesh,

	We're making semantic distinctions here.  I can easily define a
VLAN consisting of a group of RBridges that corresponds to the same
semantics as the FTAG.  I am not redefining what an 802.1Q VLAN tag is
by doing this, I am simply defining one or more specific VLANs in ways
I certainly am allowed to by IEEE 802.1Q.

	There is no reason - as I said in my recent reply to Silvano -
why this is inconsistent with using what you are referring to as 
"shared trees." 

	There is no "protocol overhead" in this case, because we have
to deal with the fact that either the tunnel Ethernet, or the native
Ethernet, encapsulation may use 802.1Q.  Where protocol overhead is
introduced is where we introduce bits that may be used in some cases,
but must be present in all cases.

--
Eric

--> -----Original Message-----
--> From: Dinesh G Dutt [mailto:ddutt at cisco.com] 
--> Sent: Friday, October 20, 2006 1:22 PM
--> To: Gray, Eric
--> Cc: Silvano Gai; Joe Touch; Dino Farinacci (dino); 
--> rbridge at postel.org; Radia Perlman
--> Subject: Re: [rbridge] Range of appllicability (was Re: TTL 
--> only - was RE: New fields in shim header?)
--> 
--> Hi Eric,
--> 
--> Gray, Eric wrote:
--> > Silvano,
--> >
--> > 	The VLAN space you mention is larger in the RBridges case.
--> > It is possible to use 802.1Q encapsulation in the RBridge tunnel
--> > encapsulation - in a fashion similar to (but not necessarily the
--> > same as) the way in which it may be used in the native Ethernet.
--> >
--> >   
--> If I understand what you're saying, it is that we can add 
--> an additional 
--> .1Q tag between the outer L2 MAC address (carrying Rbridge 
--> next hop mac 
--> address) and the TRILL shim header and we can use the VLAN 
--> field in this 
--> tag to do what FTAG is being proposed for.
--> 
--> If this is right, let me list the reasons why I think FTAG 
--> is a better 
--> approach:
-->     - Using the VLAN field doesn't permit you to construct 
--> shared trees 
--> and use the FTAG as a tree identifier. Sure, you can 
--> redefine the VLAN 
--> field to be that, but then it's no longer VLAN as defined by .1Q.
-->     - I'm concerned about protocol overhead; this adds 32 
--> bits to the 
--> protocol vs 10 bits by FTAG.
-->     - .1Q is a tag for Ethernet. If I want to use TRILL across 
--> non-Ethernet links, I need something that is independent of the L2 
--> transmission layer being used. While this case may not be the 90% 
--> scenario, it seems to intuitively violate layering in my mind.
--> 
--> Dinesh
--> 
--> -- 
--> We make our world significant by the courage of our 
--> questions and by 
--> the depth of our answers.                               - Carl Sagan
-->