Subject: [rbridge] IVLANs vs OVLANs

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Wed, 15 Nov 2006 15:12:47 -0500

Silvano,

	First of all, I will take very large exception to the way
which you have over-loaded the term "CRED."  This term was coined
to eliminate confusion caused by the various different was people
were over-loading the term "Campus."

	At the "core" of your question, however, is the issue of
how VLANs interact in a bridged/RBridge environment.  It is not
different than would be the case in a "classical bridged LAN." 

	This issue is based on a misconception that existed very 
early on in the life of the TRILL working group (in the first
BoF, in fact).  The misconception is that VLAN connectivity may
be provided by RBridges and/or bridges.  

	This is fundamentally incorrect.

	Interconnection of VLANs is strictly a routing function.
In deployed equipment that does this today, there may be some
form of "smart VLAN bridging" that occurs in devices people are
used to referring to as "bridges" or "switches."  That does not
change the fact that forwarding from one VLAN to another is a
"routing function."

	Note that, in this context, when I say "forwarding from
one VLAN to another" - I mean "VLAN" in the sense of "virtual
LAN" as a logical concept.  This has nothing to do with the fact
that a VLAN ID might change in traversing a VLAN-aware bridge.

	Consequently, in the picture you have below, the VLANs
represented by the VLAN-tag in the tunnel encapsulation may 
not be connected together by RB1.

	To correctly restate your question, the original topology
would be as follows:

                +-----+  1,2  +-----------+
                | RB1 |-------| Rtg Fnctn |
                +-----+       +-----------+
                   |
                   | 1,2
                   |
 +-----+   1    +-----+    2     +-----+ 
 | RB2 |--------| SW1 |----------| RB3 |
 +-----+        +-----+          +-----+

The resulting logical topology MUST then be as follows:

 +-----+        +-----+       +-----------+
 | RB2 |--------| RB1 |-------| Rtg Fnctn |
 +-----+        +-----+       +-----+-----+
                                    |
                                 +--+--+          +-----+
                                 | RB1 |----------| RB3 |
                                 +-----+          +-----+

Since the "routing function" is orthogonal, and well understood,
it does not make sense for us to try to combine this concept with
RBridge behaviors and protocol interactions.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai
--> Sent: Tuesday, November 14, 2006 8:11 PM
--> To: rbridge at postel.org
--> Subject: [rbridge] IVLANs vs OVLANs
--> 
--> 
--> During the last WG meeting I had an action item to send an 
--> email on the
--> VLAN issue. Here it is.
--> 
--> In a previous email I introduced the concept of IVLAN and OVLAN.
--> 
--> IVLAN refers to the VLAN present on the untagged frames, 
--> which must be
--> propagated by ISIS, VLAN pruning must be performed and so 
--> on. All the
--> IVLANs share the same core instance of ISIS.
--> 
--> OVLAN refers to the fact that the traffic between two 
--> RBridges can be
--> encapsulated into a VLAN.
--> 
--> If we look to the format of a TRILL encapsulated frame the 
--> position of
--> these two fields is as follow:
--> 
--> +--------------------------------+
--> |               DA               |
--> +----------------+---------------+
--> |       DA       |     SA        |
--> +----------------+---------------+
--> |               SA               |
--> +--------------------------------+
--> |    ET = 1Q     |   OVLAN ...   |
--> +--------------------------------+
--> |    ET = TRILL  | RES  |  TTL   |
--> +--------------------------------+
--> | Egress Add.    | Ingress Add.  |
--> +--------------------------------+
--> |               DA               |
--> +----------------+---------------+
--> |       DA       |     SA        |
--> +----------------+---------------+
--> |               SA               |
--> +--------------------------------+
--> |    ET = 1Q     |   IVLAN ...   |
--> +--------------------------------+
--> |             Payload            |
--> 
--> Now let's consider the following topology:
--> 
-->                +-----+
-->                | RB1 |
-->                +-----+
-->                   |
-->                   | 1,2
-->                   |
--> +-----+   1    +-----+    2     +-----+
--> | RB2 |--------| SW1 |----------| RB3 |
--> +-----+        +-----+          +-----+
--> 
--> RB1, RB2, RB3 are Rbridges, SW1 is a classical Ethernet switch.
--> The link between RB2 and SW1 is in OVLAN 1, the link 
--> between SW1 and RB3
--> is in OVLAN 2 and the links between SW1 and RB1 is a trunk and it
--> carries both OVLAN 1 and 2.
--> 
--> Now my question is: "do we have one CRED or two?"
--> 
--> a) possible answer: "we have one CRED". RB2 is adjacent to 
--> RB1 but not
--> to RB3. The same applies to RB3 that is adjacent to RB1, 
--> but not RB2.
--> RB1 is adjacent to both RB2 and RB3. There is a single core 
--> instance of
--> ISIS. RB2 may reach RB3 through RB1.
--> 
--> The TRILL equivalent topology is:
--> 
--> +-----+        +-----+          +-----+
--> | RB2 |--------| RB1 |----------| RB3 |
--> +-----+        +-----+          +-----+
--> 
--> b) another possible answer: "we have two CREDs". One is 
--> composed by RB2
--> and RB1, the other by RB3 and RB1. RB2 may not reach RB3, 
--> since they are
--> in different CREDs.
--> 
--> The TRILL equivalent topologies are:
--> 
--> +-----+        +-----+
--> | RB2 |--------| RB1 |
--> +-----+        +-----+
--> 
--> +-----+          +-----+
--> | RB1 |----------| RB3 |
--> +-----+          +-----+
--> 
--> I like a) and I hope we are in agreement that the right 
--> answer is a),
--> but I haven't seen it explained in any of the documents.
--> 
--> -- Silvano
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://mailman.postel.org/mailman/listinfo/rbridge
-->