Subject: [rbridge] Summary of IVLANs vs OVLANs

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Tue, 21 Nov 2006 13:18:42 -0500

Silvano,

	With the qualification that "under a single management" means
that - if VLAN tagging is required for fractional LAN traversal - 
then VLAN tags will be assigned consistently, then I understand your
position.  That is not to say that I agree with it.

	A question for clarification: assuming a real world deployment
(in an enterprise environment) where VLANs are used both to protect
and segregate traffic, how does Radia's proposal prevent potential
"leakage" from one (end-station) VLAN to another?

	When I first read Radia's proposal, I thought (for one minute)
that she was arguing for this as a "logical model" - where practical
implementations might actually be more clever/efficient.  It might
have been reasonable to assume that the intervention of a router is
going to bound the RBridge domain (as it does a broadcast domain).

	However this does not prevent the discovery of an RBridge - as
an IS-IS (L2-specific) peer, even if the same physical RBridge is a
part of multiple VLANs.  Consequently, that logical model necessitates 
creation of separate IS-IS instances on a per-VLAN basis in RBridges
that span multiple VLANs, further resulting in over-lapping RBridge
"CREDs" and potentially forcing each (physical) RBridge to be able to
participate in each CRED.  Note that this effectively forces RBridge
implementations to support per-VLAN trees explicitly (as opposed to
implicitly as originally suggested in previous discussions involving
IRTs and VLAN optimization).

	As a second question for clarification: are we prepared to both
mandate RBridges MUST support IS-IS instancing per-VLAN and that they
MUST also be capable of participation in multiple CREDs including the
formation of per-VLAN p2mp trees?

	Also, even though there is a "hard limit" of 4k VLANs in both
the end-station and RBridge domains, that does not mean I want to be
REQUIRED to configure up to 4k VLANs in my core switches.

--
Eric

> -----Original Message-----
> From: Silvano Gai [mailto:sgai at nuovasystems.com] 
> Sent: Tuesday, November 21, 2006 12:51 PM
> To: Gray, Eric; Radia Perlman
> Cc: Russ White; rbridge at postel.org
> Subject: RE: Summary of IVLANs vs OVLANs
> 
> 
> Eric,
> 
> I see only two possible uses for the OVLAN:
> 
> 1) The one that Radia proposes, that I think is appropriate for an
> Enterprise environment, where the TRILL network is under a single
> management;
> 
> 2) The one proposed in metro Ethernet in which the OVLAN (there called
> S-VLAN) identifies a particular customer and the IVLAN contains the
> customer VLAN. I know Ali Sajassi is in favor of this model.
> 
> I don't see any advantage of deriving the OVLAN from an "N:1 mapping
> from the inner VLAN tag": 
> - It does not increase scalability, since the overall number of VLANs
> will remain 4K;
> - It adds complexity and the need for a protocol to keep the 
> mapping in
> synch among different Rbridges;
> - It does not increase segregation, since segregation and pruning is
> anyhow performed on the IVLAN;
> - It requires unnecessary inner header lookup.
> 
> For these reasons my consensus is with Radia proposal.
> 
> -- Silvano
> 
> ----------------------------------------------------------------
> 
> 
> > -----Original Message-----
> > From: Gray, Eric [mailto:Eric.Gray at marconi.com]
> > Sent: Tuesday, November 21, 2006 8:11 AM
> > To: Radia Perlman
> > Cc: Silvano Gai; Russ White; rbridge at postel.org
> > Subject: RE: Summary of IVLANs vs OVLANs
> > 
> > Radia,
> > 
> > 	I think that this may be a summary of your perspective on the
> > use of VLANs, but I do not believe that this perspective has been
> > discussed generally.  Nor do I believe that it has been agreed to
> > by any sort of "rough consensus" subset within the working group.
> > 
> > 	However, I may be wrong, so I would like to suggest that we
> > (as a working group) discuss the "summary" you have provided.  If
> > I am wrong, then I suggest the members of that "subset" may need
> > to re-think their position.
> > 
> > 	I am reasonably sure that many people would like to use VLAN
> > tags in the RBridge domain as a means to form reasonable aggregates
> > of the VLANs among end-stations.  In this sense, the outer VLAN tag
> > is derived simply as an N:1 mapping from the inner VLAN tag - and,
> > as a result of this is, there will be a dependence on the inner tag
> > in how forwarding occurs between RBridges.
> > 
> > 	This approach helps scalability in two ways: one, it allows
> > for reduced VLAN configuration among RBridges to support a larger
> > quantity of end-station VLANs; two, it allows some subset of the
> > RBridge topology to avoid deriving and storing forwarding entries
> > for traffic they should not need to forward.
> > 
> > 	Arguably the latter scalability concern is eliminated by the
> > use of per-ingress p2mp forwarding trees.  However, it has been
> > suggested that we might not do that - hence it is important to bear
> > this in mind.  One potential use of VLANs between RBridges is to
> > allow for sub-setting of spanning trees (assuming we decide to use
> > spanning trees between RBridges) using the existing techniques we
> > already have defined in 802.1D (2004) - i.e. - MSTP.
> > 
> > 	It is even possible that some people may be thinking of using
> > VLAN tags in other ways.  If so, I would like to hear their ideas.
> > For one thing, it is clear that we MUST decide on some set of uses
> > that are compatible, and it is clear that the use outlined in your
> > summary is fundamentally incompatible with the use I (and, I assume,
> > other people) have assumed.  It is also incompatible with standard
> > usage as defined in 802.1Q, and new proposals currently in process
> > in the IEEE.
> > 
> > 	As a more-or-less philosophical clarification, it does not
> > make sense to configure VLANs in RBridges to accommodate the VLAN
> > tags used by the intervening fractional-LANs (what we have been
> > calling "LAN segments") between two RBridges.  VLAN tags SHOULD be
> > used to accommodate connectivity among RBridges across the under-
> > lying fractional LANs (just as they are to accommodate connectivity
> > among end-stations) - and not the other way around.
> > 
> > 	From the perspective of existing 802.1D bridges, RBridges are
> > end-stations.  You decide which end-stations require connectivity,
> > you assign them to the same VLAN, and then you configure the VLAN
> > information in the VLAN bridges.
> > 
> > 	Also, the idea of potentially "switching" from one VLAN tag
> > to another across and RBridge to accommodate a presumed under-lying
> > VLAN tagging arrangement seems broken.  We would need to consider a
> > lot of potential corner-cases - particularly during deployment and
> > re-configuration - to determine if this will even work.  For one
> > thing, there are interesting problems that arise as a result of not
> > consistently using the same VLAN tags within a single administrative
> > domain.
> > 
> > 	I assume we have not yet decided to tackle the "multi-domain"
> > problem in TRILL, given that it is supposed to be a LAN-oriented,
> > plug-and-play capable, enterprise solution...
> > 
> > --
> > Eric
> > 
> > > -----Original Message-----
> > > From: Radia Perlman [mailto:Radia.Perlman at sun.com]
> > > Sent: Monday, November 20, 2006 8:36 PM
> > > To: Gray, Eric
> > > Cc: 'Silvano Gai'; Russ White; rbridge at postel.org
> > > Subject: Summary of IVLANs vs OVLANs
> > >
> > > I don't think there is an issue here, but let me hopefully
> > > clarify the
> > > purpose of a VLAN tag on the inner frame
> > > vs a VLAN tag which might appear on the outer header.
> > >
> > > **********
> > > First: Purpose of "inner" VLAN tag
> > > ___________________________
> > >
> > >
> > > The purpose of the inner tag is to provide separation for endnode
> > > communities. In other words, VLAN A
> > > endnodes can only talk to VLAN A endnodes. The VLAN tag is either
> > > inserted by the original endnode,
> > > or the first bridge or RBridge that receives the frame. What
> > > tag to put
> > > in, whether to strip it, is configured
> > > into RBridges exactly as it would be with bridges.
> > >
> > > The inner VLAN tag is irrelevant for how the frame is
> > > forwarded between
> > > the RBridges.
> > >
> > > RBridges are willing to forward all frames, regardless of the
> > > inner VLAN
> > > tag. They forward towards the
> > > egress RBridge, totally ignoring the inner VLAN tag on
> > > unicast packets.
> > > On multicast, however, they
> > > will look at the VLAN tag on the inner frame to decide if they
> should
> > > filter on some outgoing ports
> > > for the selected multicast tree, because there are no
> > > downstream links
> > > for that VLAN tag.
> > >
> > > *******************
> > > Now for the outer VLAN tag
> > >
> > > Basically, the outer header is only a hop-by-hop header, and is of
> no
> > > significance other than
> > > to be able to communicate between RBridge neighbors. If it's
> > > necessary
> > > (because of configuration of
> > > bridges between two RBridges) to stick VLAN tags into the
> > > outer header,
> > > that's what the RBridges do.
> > >
> > > So: figuring out your RBridge neighbors:
> > >
> > > RBridges figure out who their RBridge neighbors are, through
> > > the IS-IS
> > > Hello protocol. VLANs make this
> > > a bit awkward, but still straightforward. Which VLAN tags 
> exist on a
> > > link is configured into the RBridges, just
> > > like it would be configured into a bridge.
> > >
> > > So...RBridge RB1 has been configured to know that on port a,
> > > packets are
> > > allowed to have, say,
> > > VLAN tags A, C, and none.
> > >
> > > So...RB1 has to figure out what RBridge neighbors it has. It
> > > does this
> > > by sending IS-IS Hellos three times
> > > on that port, tagged respectively with A, C, and none.
> > >
> > > It might form different adjacencies depending on which 
> VLAN tag the
> > > IS-IS Hello was sent with.
> > > Let's say that with VLAN tag A, it forms an adjacency with
> > > RB2, and with
> > > VLAN tag C and no VLAN tag,
> > > it forms an adjacency with RB3.
> > >
> > > Therefore, in the core instance of IS-IS, RB1 announces that
> > > it has two
> > > RBridge neighbors (maybe others on
> > > other ports as well); RB2 and RB3. It doesn't matter to any other
> > > RBridges what VLAN tags RB1 needs
> > > to stick into the outer header in order to communicate on the
> > > adjacency.
> > >
> > > Whenever RB1 sends anything (forwarded data packets, IS-IS Hellos)
> to
> > > adjacency RB2, it sticks VLAN A
> > > tag into the outer header.
> > >
> > > Whenever RB1 sends anything to adjacency RB3, it has a choice. It
> can
> > > put a VLAN C tag into the outer header,
> > > or no VLAN tag. It doesn't matter which it chooses.  I'd
> > > choose no VLAN
> > > tag, just to save a few bytes.
> > > But there might be a case where any of a set of VLAN tags would
> work,
> > > and no VLAN tag wouldn't work,
> > > in which case, again, it doesn't matter which one it chooses.
> > >
> > > ************************
> > > So, now let's look at the example being discussed in this thread:
> > >
> > >                  +-----+  1,2  +-----------+
> > >                  | RB1 |-------| Rtg Fnctn |
> > >                  +-----+       +-----------+
> > >                     |
> > >                     | 1,2
> > >                     |
> > >   +-----+   1    +-----+    2     +-----+
> > >   | RB2 |--------| SW1 |----------| RB3 |
> > >   +-----+        +-----+          +-----+
> > >      |                               |
> > >      | IVLAN=3                       | IVLAN=3
> > >   +-----+                         +-----+
> > >   |  H1 |                         |  H2 |
> > >   +-----+                         +-----+
> > >
> > >
> > > In this example, RB2 will wind up with an adjency to RB1, and have
> to
> > > stick VLAN 1 into the outer
> > > header in order to talk to RB1. RB2 will not form an
> > > adjacency with RB3.
> > >
> > > RB2, on the other other, will form two adjacencies on that
> > > port; one to
> > > RB2 (using VLAN 1), and
> > > one to RB3 (using VLAN 2).
> > >
> > > The IS-IS topology will looks like:
> > >
> > > H1----RB2---RB1----RB3---H2
> > >
> > > So the path from H1 to H2 will go through RB2, then RB1, then RB3.
> > >
> > > Hope this clarifies.
> > >
> > > Radia
> > >
> > >
> > >
> > >
> > >
>