Subject: [rbridge] IVLANs vs OVLANs

From: kreeger at cisco.com (Larry Kreeger (kreeger))
Date: Thu, 16 Nov 2006 18:16:20 -0800

I just read through this thread so far and I understand where Silvano is
coming from, but I don't quite get what Eric is saying.

Maybe it would help if someone could answer the following.

When an RBridge sends a frame to another RBridge (other one containing
IS-IS or a data frame), can it be encapsulated with an outer VLAN tag,
or should we say that it cannot?

If the answer is that the frames cannot be encapsulated with an OVLAN,
then things become clearer.  In the topology Silvano originally showed
(repeated below), 

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

If we assume that SW1's port connected to RB1 has the "native"
port-based VLAN for untagged frames set to VLAN 1, then the RBridge
topologies would look like.

 +-----+        +-----+       +-----+
 | RB2 |--------| RB1 |       | RB3 |
 +-----+        +-----+       +-----+

If the answer is that RBridges can encapsulate frames with an OVLAN,
then each OVLAN on each of an RBridge's physical port should be
considered a separate logical port on the RBridge.  Separate IS-IS
hellos should be sent by an RBridge on each of the logical ports.  This
makes the topology look exactly like Silvano's second picture (repeated
below), 

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

Which would make the RBridge topology look like:

 +-----+        +-----+       +-----+
 | RB2 |--------| RB1 |-------| RB3 |
 +-----+        +-----+       +-----+

 - Larry

Gray, Eric wrote on Thursday, November 16, 2006 7:39 AM:

> Silvano,			(note: Russ - please read this!!)
> 
> 	For the first part of your question, Radia and I had almost this
> exact same discussion during the BoF I mentioned.  The only
> legitimate way to get from one (logical) VLAN to another is via a
> routing function.   
> 
> 	Unless you include the "routing function" as part of the TRILL
> specification requirements - which does not, in any way, makes sense
> - then the model that applies is the one that has VLANs logically
> separated.  
> 
> 	That is strictly a VLAN separation issue.  The second part of
your
> question is trickier, hence it is good that you ask it and even
> better that you insisted on being understood.  :-)  
> 
> 	From an RBridge perspective, I believe it is sufficient that all
of
> the RBridges MUST support a common (probably the default - NULL) VLAN
> to ensure that all of them MUST peer with each other - at least for
> support of that (common) VLAN.  Hence, it should not be the case that
> any (proper) subset of RBridges would not peer exclusively with any
> other (proper) subset of RBridges in the same CRED.     
> 
> 	Also, from an IS-IS perspective (help me out here Russ), I am
> reasonably sure that adjacent/connected IS-IS instances MUST discover
> each other during peer discovery - even if they do not subsequently
> peer with each other (or having peered with each other, exchange any
> routing information).  I believe this would be the case, even if
> there was potentially some strange virtual L3 overlay topology
> involving separate L3 VPN instancing in the IS-IS routing deployment.
> 
> 	If that is the case, then - from a peer discovery perspective -
all
> RBridges will still be in the same CRED.  This is the perspective
> that matters, because it is the peer discovery process that allows
> the members of a CRED to "discover" potential _hidden_ loops in
> underlying    
> L2 topology.
> 
> 	See also my reply to your question about VLAN interactions with
> routing...