Subject: [rbridge] IVLANs vs OVLANs

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Thu, 16 Nov 2006 16:55:45 -0500

Silvano,

	You need to read my other mail.

	Once you realize that there are logical models that apply, and
start using them, it should become clear to you why there is not a
really useful reason to make the distinction you're making between
the VLANs that may exist for RBridges and the VANs that may exist 
around the RBridges.  They are logically distinct, not philosophically
distinct...

--
Eric

-----Original Message-----
From: Silvano Gai [mailto:sgai at nuovasystems.com] 
Sent: Thursday, November 16, 2006 11:01 AM
To: Gray, Eric; Russ White
Cc: rbridge at postel.org
Subject: RE: [rbridge] IVLANs vs OVLANs

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

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 20 Nov 2006 17:36:26 -0800

I don't think there is an issue here, but let me hopefully clarify the 
purpose of a VLAN tag on the inner frame
vs a VLAN tag which might appear on the outer header.

**********
First: Purpose of "inner" VLAN tag
___________________________

The purpose of the inner tag is to provide separation for endnode 
communities. In other words, VLAN A
endnodes can only talk to VLAN A endnodes. The VLAN tag is either 
inserted by the original endnode,
or the first bridge or RBridge that receives the frame. What tag to put 
in, whether to strip it, is configured
into RBridges exactly as it would be with bridges.

The inner VLAN tag is irrelevant for how the frame is forwarded between 
the RBridges.

RBridges are willing to forward all frames, regardless of the inner VLAN 
tag. They forward towards the
egress RBridge, totally ignoring the inner VLAN tag on unicast packets. 
On multicast, however, they
will look at the VLAN tag on the inner frame to decide if they should 
filter on some outgoing ports
for the selected multicast tree, because there are no downstream links 
for that VLAN tag.

*******************
Now for the outer VLAN tag

Basically, the outer header is only a hop-by-hop header, and is of no 
significance other than
to be able to communicate between RBridge neighbors. If it's necessary 
(because of configuration of
bridges between two RBridges) to stick VLAN tags into the outer header, 
that's what the RBridges do.

So: figuring out your RBridge neighbors:

RBridges figure out who their RBridge neighbors are, through the IS-IS 
Hello protocol. VLANs make this
a bit awkward, but still straightforward. Which VLAN tags exist on a 
link is configured into the RBridges, just
like it would be configured into a bridge.

So...RBridge RB1 has been configured to know that on port a, packets are 
allowed to have, say,
VLAN tags A, C, and none.

So...RB1 has to figure out what RBridge neighbors it has. It does this 
by sending IS-IS Hellos three times
on that port, tagged respectively with A, C, and none.

It might form different adjacencies depending on which VLAN tag the 
IS-IS Hello was sent with.
Let's say that with VLAN tag A, it forms an adjacency with RB2, and with 
VLAN tag C and no VLAN tag,
it forms an adjacency with RB3.

Therefore, in the core instance of IS-IS, RB1 announces that it has two 
RBridge neighbors (maybe others on
other ports as well); RB2 and RB3. It doesn't matter to any other 
RBridges what VLAN tags RB1 needs
to stick into the outer header in order to communicate on the adjacency.

Whenever RB1 sends anything (forwarded data packets, IS-IS Hellos) to 
adjacency RB2, it sticks VLAN A
tag into the outer header.

Whenever RB1 sends anything to adjacency RB3, it has a choice. It can 
put a VLAN C tag into the outer header,
or no VLAN tag. It doesn't matter which it chooses.  I'd choose no VLAN 
tag, just to save a few bytes.
But there might be a case where any of a set of VLAN tags would work, 
and no VLAN tag wouldn't work,
in which case, again, it doesn't matter which one it chooses.

************************
So, now let's look at the example being discussed in this thread:

                 +-----+  1,2  +-----------+
                 | RB1 |-------| Rtg Fnctn |
                 +-----+       +-----------+
                    |
                    | 1,2
                    |
  +-----+   1    +-----+    2     +-----+
  | RB2 |--------| SW1 |----------| RB3 |
  +-----+        +-----+          +-----+
     |                               |
     | IVLAN=3                       | IVLAN=3
  +-----+                         +-----+
  |  H1 |                         |  H2 |
  +-----+                         +-----+

In this example, RB2 will wind up with an adjency to RB1, and have to 
stick VLAN 1 into the outer
header in order to talk to RB1. RB2 will not form an adjacency with RB3.

RB2, on the other other, will form two adjacencies on that port; one to 
RB2 (using VLAN 1), and
one to RB3 (using VLAN 2).

The IS-IS topology will looks like:

H1----RB2---RB1----RB3---H2

So the path from H1 to H2 will go through RB2, then RB1, then RB3.

Hope this clarifies.

Radia