Subject: [rbridge] VLANs

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Wed, 1 Nov 2006 11:46:22 -0500

Silvano,

	VLAN tag-stacking is something that is done already.  It
requires no special explanation from me, as the way it is done 
is completely orthogonal to anything we are doing here in the
IETF.  That includes anything we are doing here in the TRILL WG.

	However, in the interest of trying not to be too opaque,
ask yourself what it would mean if the "Ethertype" in the 802.1Q
encaspulation indicates that it is followed by an 802.1Q frame.

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:sgai at nuovasystems.com] 
--> Sent: Wednesday, November 01, 2006 11:23 AM
--> To: Gray, Eric
--> Cc: rbridge at postel.org
--> Subject: RE: [rbridge] VLANs
--> 
--> Eric,
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:Eric.Gray at marconi.com]
--> > Sent: Wednesday, November 01, 2006 8:07 AM
--> > To: Silvano Gai
--> > Cc: rbridge at postel.org
--> > Subject: RE: [rbridge] VLANs
--> > 
--> > Silvano,
--> > 
--> > 	I believe I've stated my position on using the IVLAN/OVLAN
--> > terminology, but just in case - I don't think it's necessary and
--> > I don't think it helps.
--> 
--> I think it does.
--> 
--> > 
--> > 	It seems to me that the description you provide below is an
--> > ample demonstration of the confusion that the use of these terms
--> > can introduce.
--> 
--> No, it is a demonstration of the confusion that not 
--> introducing these
--> terms creates.
--> 
--> > 
--> > 	For example, let's really complicate your example by using
--> > stacked VLAN tagging both in the tunnel encapsulation and in the
--> > native encapsulation for portions of the assumed domain. 
--> 
--> You have already mentioned this stacking and other magic that TRILL
--> plans to do with VLANs, but you have never provided a consistent
--> explanation. Is this part of TRILL or not?
--> 
--> Is TRILL defined to be mapped on a single OVLAN or on multiple? 
--> Is this written in any draft?
--> 
--> Can you explain this clearly?
--> 
--> Thank You
--> 
--> -- Silvano
--> 
-->  In the
--> > (deliberately) complicated model I've just described, what does
--> > the IVLAN/OVLAN distinction mean?
--> > 
--> > 	In fact, one reason not to distinguish the two is that - in
--> > the text you're referring to - the impact of which it is that may
--> > apply is nil.  Hence by not making a distinction, we're allowed a
--> > certain economy in communicating.
--> > 
--> > --
--> > Eric
--> > 
--> > --> -----Original Message-----
--> > --> From: Silvano Gai [mailto:sgai at nuovasystems.com]
--> > --> Sent: Wednesday, November 01, 2006 12:55 AM
--> > --> To: Gray, Eric
--> > --> Cc: rbridge at postel.org
--> > --> Subject: RE: [rbridge] VLANs
--> > -->
--> > -->
--> > --> Eric,
--> > -->
--> > --> I disagree and let me give you concrete examples why:
--> > -->
--> > --> draft-ietf-trill-rbridge-protocol-00.txt says:
--> > -->
--> > --> "each RBridge R1
--> > -->    will run a "core" instance of IS-IS for the core RBridge
--> > --> information,
--> > -->
--> > -->    and an instance per VLAN that R1 is attached to, for the
--> endnode
--> > -->    information for those VLANs."
--> > -->
--> > --> If we are speaking of OVLAN, IMO an RBridge runs a 
--> core instance
--> per
--> > --> each OVLAN and on that instance it propagates the endnode
--> > --> information
--> > --> for the IVLANs."
--> > -->
--> > --> " The endnode information for VLAN A, which is carried in
--> > --> the VLAN A
--> > -->    IS-IS instance injected by R1, contains:"
--> > -->
--> > --> This clearly refers to IVLAN.
--> > -->
--> > --> draft-ietf-trill-prob-01.txt says:
--> > -->
--> > --> It may alternately support
--> > -->    direct VLAN support, e.g., by the use of separate 
--> TRILL routing
--> > -->    protocol instances to separate traffic for each VLAN
--> > --> traversing a
--> > -->    TRILL solution.
--> > -->
--> > --> Is this an IVLAN or an OVLAN?
--> > -->
--> > -->
--> > --> draft-ietf-trill-rbridge-arch-01.txt says
--> > -->
--> > --> Ingress RBridge Tree: a tree computed for each edge RBridge -
--> > -->            and potentially for each VLAN in which that RBridge
--> > -->            participates
--> > -->
--> > --> I assume this is an OVLAN, I don't think TRILL computes an
--> > --> IRT for each
--> > --> IVLAN; it can prune an IRT for each VLAN.
--> > -->
--> > --> In an email to Dinesh you wrote:
--> > -->
--> > --> "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.  "
--> > -->
--> > --> Were you referring to an IVLAN or an OVLAN?
--> > -->
--> > --> Also you claim that 16 bits are not sufficient for 
--> the RBridge ID.
--> > --> Is the RBridge ID space replicated per each OVLAN or 
--> is it shared?
--> > --> Does an RBridge have the same RBridge ID on all OVLANs?
--> > -->
--> > --> I think we need to explicitly introduce the IVLAN and OVLAN
--> > --> concepts and
--> > --> use them consistently. We don't want to hide complexity due
--> > --> to the lack
--> > --> of nomenclature.
--> > -->
--> > --> -- Silvano
--> > -->
--> > -->
--> > -->
--> > -->
--> > -->
--> > -->
--> > -->
--> > --> > -----Original Message-----
--> > --> > From: Gray, Eric [mailto:Eric.Gray at marconi.com]
--> > --> > Sent: Tuesday, October 31, 2006 9:04 AM
--> > --> > To: Silvano Gai
--> > --> > Cc: rbridge at postel.org
--> > --> > Subject: RE: [rbridge] VLANs
--> > --> >
--> > --> > Silvano,
--> > --> >
--> > --> > 	Actually, both "types" of VLANs are the same - applying
--> at
--> > --> > different layers, but defined using the same terminology.
--> Logic,
--> > --> > semantics and applicability are the same.
--> > --> >
--> > --> > 	For historic reasons, we are trying to avoid the terms
--> you
--> > --> > propose.  In fact, similar terms have been used 
--> previously and
--> > --> > removed as confusing.  Without constant reminders, 
--> "inner" and
--> > --> > "outer" will be taken in some instances as placement in the
--> frame
--> > --> > (as you are suggesting) or position relative to the CRED (a
--> usage
--> > --> > issue with the terms "ingress" and "egress" meaning 
--> "way in" and
--> > --> > "way out" respectively).
--> > --> >
--> > --> > 	Hence you are suggesting replacement with one potential
--> > --> > are of confusion with another one we've earlier discarded.
--> > --> >
--> > --> > 	The architecture document defines the term VLAN and - I
--> am
--> > --> > reasonably sure - uses that definition 
--> consistently.  Moreover,
--> > --> > the architecture document tries to be agnostic 
--> about the use of
--> > --> > VLANs - particularly with respect to VLAN tagged 
--> encapsulation
--> > --> > and port-based VLANs, and where these things might 
--> apply.  The
--> > --> > reason for this is simply that one aim of protocol 
--> development -
--> > --> > especially at the architectural level - should be to avoid
--> placing
--> > --> > constraints on implementation beyond those 
--> explicitly required
--> > --> > to ensure interoperability.
--> > --> >
--> > --> > --
--> > --> > Eric
--> > --> >
--> > --> > --> -----Original Message-----
--> > --> > --> From: rbridge-bounces at postel.org
--> > --> > --> [mailto:rbridge-bounces at postel.org] On Behalf 
--> Of Silvano Gai
--> > --> > --> Sent: Monday, October 30, 2006 12:29 PM
--> > --> > --> To: rbridge at postel.org
--> > --> > --> Subject: [rbridge] VLANs
--> > --> > -->
--> > --> > -->
--> > --> > --> The second biggest issue I have with the four documents
--> > --> > --> (first one being
--> > --> > --> broadcast/multicast storm) is the definition of VLANs.
--> > --> > -->
--> > --> > --> I don't think the term VLAN is used consistently in
--> > --> the documents.
--> > --> > -->
--> > --> > --> 1) Sometimes VLAN refers to the VLANs present on the
--> > --> > --> untagged frames,
--> > --> > --> which must be propagated by ISIS, VLAN pruning must be
--> > --> > --> performed and so
--> > --> > --> on. They all share the same core instance of ISIS.
--> > --> > -->
--> > --> > --> 2) Sometimes VLANs refers to the fact that a CRED can be
--> > --> > --> encapsulated
--> > --> > --> into a VLAN (present as a 1Q tag in the outer 
--> header) and
--> > --> > --> therefore ISIS
--> > --> > --> will run per VLAN, i.e. there will be a core instance of
--> > --> > --> ISIS per each
--> > --> > --> VLAN. This seems to be the case in some part of the
--> > --> architectural
--> > --> > --> document.
--> > --> > -->
--> > --> > --> I propose to name the former IVLAN (inner VLAN) and the
--> latter
--> > --> OVLAN
--> > --> > --> (Outer VLAN), with reference to the position of 
--> the 1Q tag
--> > --> > --> in the frame.
--> > --> > -->
--> > --> > --> This is also very relevant for the discussion 
--> that we need
--> > --> > --> to complete
--> > --> > --> on the FTAG: it is my understanding that some 
--> folks think
--> > --> > --> that the FTAG
--> > --> > --> is not needed, since there may be an OVLAN.
--> > --> > -->
--> > --> > --> Comments?
--> > --> > -->
--> > --> > --> -- Silvano
--> > --> > -->
--> > --> > --> _______________________________________________
--> > --> > --> rbridge mailing list
--> > --> > --> rbridge at postel.org
--> > --> > --> http://mailman.postel.org/mailman/listinfo/rbridge
--> > --> > -->
--> > -->
-->