Subject: [rbridge] Summary of IVLANs vs OVLANs

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Tue, 21 Nov 2006 11:11:17 -0500

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