Subject: [rbridge] VLANs

From: sgai at nuovasystems.com (Silvano Gai)
Date: Tue, 31 Oct 2006 21:55:16 -0800

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