Subject: [rbridge] VLANs

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 1 Nov 2006 08:23:24 -0800

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
> --> > -->
> -->