Subject: [rbridge] IVLANs vs OVLANs

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 16 Nov 2006 17:22:38 -0800

Eric,

The concept of "Null VLAN" does not exists in IEEE 802.1Q.

IEEE 802.1Q states:
"An untagged frame or a priority-tagged frame does not carry any
identification of the VLAN to which it belongs. Such frames are
classified as belonging to a particular VLAN based on parameters
associated with
the receiving Port, or, through proprietary extensions to this standard,
based on the data content of the frame (e.g., MAC Address, layer 3
protocol ID, etc.)."

Therefore all the frames inside an IEEE 802.1Q compliant-switch are
tagged with an VLAN independently from the fact that they came in
VLAN-Tagged, Priority-Tagged or untagged.

On entering an Rbridge a frame:
1) if it does not have a TRILL shim header, it is always tagged with an
IVLAN.
2) if it does have a TRILL shim header it always has both an OVLAN and
an IVLAN.

Do you agree?

-- Silvano

> -----Original Message-----
> From: Gray, Eric [mailto:Eric.Gray at marconi.com]
> Sent: Thursday, November 16, 2006 7:39 AM
> To: Silvano Gai; Russ White
> Cc: rbridge at postel.org
> Subject: RE: [rbridge] IVLANs vs OVLANs
> 
> 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...
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:sgai at nuovasystems.com]
> --> Sent: Thursday, November 16, 2006 12:57 AM
> --> To: Gray, Eric
> --> Cc: rbridge at postel.org
> --> Subject: RE: [rbridge] IVLANs vs OVLANs
> -->
> -->
> --> 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
> --> > -->
> -->