Subject: [rbridge] IVLANs vs OVLANs

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 15 Nov 2006 21:56:31 -0800

Eric,

I am just trying to understand if there is consensus in a) or b).

The impression I got talking with Radia is that she was in favor of a).

Your reply is my b) model to which you have added a router. Since b) is
two separate layer 2 networks, you can put a router between the two, as
you did.

Please also note that I can redraw the same network in a different way:

                +-----+
                | RB1 |
                +-----+
                 |  |
               1 |  | 2
                 |  |
 +-----+   1    +-----+    2     +-----+
 | RB2 |--------| SW1 |----------| RB3 |
 +-----+        +-----+          +-----+

Where I replaced the Etherchannel with two links, one in OVLAN=1 and one
in OVLAN=2. 

Now is RB2 capable of talking to RB3 through RB1?

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:Eric.Gray at marconi.com]
> Sent: Wednesday, November 15, 2006 12:13 PM
> To: Silvano Gai
> Cc: rbridge at postel.org
> Subject: RE: [rbridge] IVLANs vs OVLANs
> 
> 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
> -->