Subject: [rbridge] IVLANs vs OVLANs

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 16 Nov 2006 08:01:16 -0800

Eric,

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

Eric you really need to start to think in term of OVLAN and IVLAN and in
term of access ports and trunk port. The fact that products may use the
same port to be a trunk and an access at the same time is OK, so as it
is OK that the IVLANs and OVLANs are both implemented used using the 1Q
tagging scheme.

Without a clear terminology we will not be able to agree on anything.

What you are saying is not true for OVLANs. A frame, when it has an
OVLAN, i.e. it is on a trunk port, i.e. it has a TRILL shim, i.e. it has
an outer header, CANNOT have the outer MAC address of a router.
Therefore saying that "The only legitimate way to get from one (logical)
VLAN to another is via a
routing function" is incorrect in the case of OVLANs.

It may be the common case for IVLANs, but there are exceptions in today
networks, starting from NAT.

-- Silvano

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