Subject: [rbridge] Summary of IVLANs vs OVLANs

From: sgai at nuovasystems.com (Silvano Gai)
Date: Tue, 21 Nov 2006 09:50:56 -0800

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