[rbridge] Ingress Rbridge and FTAG again

[Gray, Eric]

Sanjay,

	There are no issues with using .1Q tags in the tunnel
encapsulation, any more than there would be issues in using
it in the native bridge segments' encapsulation.  It is just 
one more form of Ethernet commonly supported across RBridges.

	The use of Ethernet encapsulation - beyond the simple
statement that "some form of Ethernet encapsulation will be
used" is orthogonal to TRILL SHIM usage.  As it is orthogonal,
it is invalid to try to "combine this [802.1Q] concept with
TRILL" - because we are using a protocol model that allows us
to ignore how these things are combined.

	This is really the right way to proceed.  Otherwise, we
will be bogged down forever in discussions about how the TRILL
SHIM works in combination with a long list of potential types
of "ethernet" encapsulations.  It just does.

	As for forwarding decision impact, either the frame is
VLAN tagged (in which case all forwarding decisions are scoped
by the VLAN tag - independent of other encapsulations), or it
is not (which is logically equivalent to the "default" VLAN).

	We need to stop trying to find "rocket science" in the
way we do things.  There is nothing difficult about this.

	Finally, I don't think anyone is suggesting that VLAN tags
could be used for "FTAG purposes."  What has been suggested as a
justification for FTAGs is already within scope for VLAN tag use.
That should be taken to mean we don't need to invent a new kind 
of wheel to do what we already can do.  There is no reason to 
define anything for "FTAG purposes."

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Sanjay 
--> Sane (sanjays)
--> Sent: Thursday, October 26, 2006 5:39 PM
--> To: Maltbie, Dan; rbridge at postel.org
--> Subject: Re: [rbridge] Ingress Rbridge and FTAG again
--> 
--> 
--> I think you're suggesting adding one (outer) .1Q Tag, apart from
--> customer's original (inner).1Q tag (the real VLAN tag), and use the
--> outer .1Q as the index to the forwarding table for purposes 
--> of Ftag. 
--> 
--> Issues with this approach could be combining this concept 
--> with TRILL.
--> For e.g. would such a .1Q tag come before TRILL's existing 
--> shim header
--> or after ? Where would original .1Q tag (original VLAN) fit in?
--> Potentially, forwarding decision may need to take all 3 
--> ethertype's into
--> account. 
--> Also .1Q payload portion is 16 bits (12 bits vlan, 3 bit pri, 1 bit
--> CFI). If we really need the Ftag functionality (from the 
--> outer .1Q tag),
--> 10 bits (as proposed in the new shim header) should be enough. 
--> 
--> The new shim header (proposed as per
--> http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-
--> encap-00.txt
--> ) takes all of this into account and packs them into the 
--> TRILL context. 
--> 
--> -Sanjay
--> 
--> 
--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On
--> Behalf Of Maltbie, Dan
--> Sent: Wednesday, October 25, 2006 11:07 PM
--> To: rbridge at postel.org
--> Subject: Re: [rbridge] Ingress Rbridge and FTAG again
--> 
--> The IEEE 802.1Q VLAN TAG should do everything an rbridge 
--> could possibly
--> want to do with an FTAG and it will be much more interoperable with
--> existing and future Ethernet equipment. There's already a 
--> standard way
--> to push/pop VLAN tags. Other standards, like provider bridging, are
--> taking advantage of Ethernet's excellent flexibility. Why 
--> re-invent the
--> wheel?
--> 
--> just a thought...
--> 
--> Dan Maltbie
--> Woven Systems, Inc.
--> 
--> -----Original Message-----
--> Message: 5
--> Date: Wed, 25 Oct 2006 19:30:26 -0700
--> From: "Sanjay Sane \(sanjays\)" <sanjays at cisco.com>
--> Subject: Re: [rbridge] Ingress Rbridge and FTAG again
--> To: "Radia Perlman" <Radia.Perlman at sun.com>
--> Cc: rbridge at postel.org
--> Message-ID:
--> 	
--> <7178B7E237F45D45BE404AFF0AF58D870181BCCF at xmb-sjc-213.amer.c
--> isco.com>
--> Content-Type: text/plain;	charset="us-ascii"
--> 
--> 
--> <<snip>>
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 
--> 
--> End of rbridge Digest, Vol 29, Issue 30
--> ***************************************
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://mailman.postel.org/mailman/listinfo/rbridge
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://mailman.postel.org/mailman/listinfo/rbridge
-->