Subject: [rbridge] IVLANs vs OVLANs

From: sgai at nuovasystems.com (Silvano Gai)
Date: Fri, 17 Nov 2006 07:22:05 -0800

Eric,

> -----Original Message-----
> From: Gray, Eric [mailto:Eric.Gray at marconi.com]
> Sent: Thursday, November 16, 2006 7:08 PM
> To: Silvano Gai; Russ White
> Cc: rbridge at postel.org
> Subject: RE: [rbridge] IVLANs vs OVLANs
> 
> Silvano,
> 
> 	Forget the "Null VLAN" concept for the moment, and look at
> the rest of what you're saying.
> 

... Snip ...

> 	Finally, to get onto the question you ask, I don't agree that
> any frame handled by an RBridge MUST be tagged - at all.  

I never said that. I understand that on the links there are three kinds
of frames:
1) Untagged
2) Priority Tagged
3) VLAN tagged

What I pointed out from the standard text is that the port of the switch
always normalizes the frame to be tagged in the moment it enters the
switch. You are right that IEEE 802.1Q allows for extensions, but the
final result is that a frame inside a switch as a VID (VLAN ID)
associated to it.

Now let's consider an RBridge:

1) if the frame is received on an access port, i.e. comes from a host,
i.e. does not have a TRILL shim, it has an IVLAN tag associated. In the
base protocol spec there is an explanation on how to handle that frame,
including VLAN pruning. I have no issues

2) if the frame is received on a trunk port, i.e. it comes from another
RBridge, i.e. it has a TRILL shim, it has both an IVLAN and an OVLAN tag
associated. This is the case that I don't understand how it works. 

We need to explain what to do with the OVLAN information: we can ignore
it or use it.

If we ignore the OVLAN it means that two hosts are considered to be on
the same VLAN if they are both on the same IVLAN, independently of the
OVLAN. This is my understanding of Radia proposal.

If we use it, it means that two stations are considered to be on the
same VLAN only if they are both on the same IVLAN and OVLAN. This is my
understanding of what Metro Ethernet folks want to do.

Which solution are you advocating?

-- Silvano

Assuming
> you are addressing the case where a deployment only uses 802.1Q
> devices, and all traffic is necessarily tagged, then every frame
> that is not TRILL encapsulated MUST have a VLAN tag.  That is a
> trivial observation that necessarily follows from the definition
> of the deployment scenario.
> 
> 	I also don't agree that frames forwarded within a CRED will
> necessarily have any VLAN tag in the tunnel encapsulation.  Again,
> if the assumption is that there is a deployment scenario in which
> this is required, then (naturally) it will be the case that this
> turns out to be true.
> 
> 	However, I do agree that there could be advantages to using
> a VLAN tagged frame format in the tunnel encapsulation when there
> was a VLAN tagged frame format in native frames being forwarded
> across a CRED.  For example, this might be used to eliminate the
> need for RBridges to peek beyond the tunnel encapsulation.
> 
> 	The potential for advantage is limited, if the mapping is not
> essentially a 1:1 VLAN tag mapping, because it seems likely that any
> N:1 mapping (where N is more than a few) will result in delivering
> some number of frames to egress devices that will then drop them.
> This approach fails to meet any sort of "efficient forwarding"
> criterion I would like to define.  This would be true, even if it is
> a hard requirement for RBridges to always filter based on VLANs -
> including within the CRED.
> 
> 	Note that this is potentially far more true if the RBridges
> are not supporting per-ingress IRTs.
> 
> 	The potential for advantage is limited, at the other end, if
> N is close to (or equal to) 1, because there is no scalability gain
> if every VLAN in the network is represented by VLAN tags in tunnel
> encapsulation within the CRED.
> 
> 	However, the issue is that this "mapping" is strictly that,
> and this greatly complicates your original question - without, in
> fact, making the answer different in any other way.  If there is a
> mapping of VLAN tags in native frames to VLAN tags in the tunneled
> (TRILL) frames, it is made at the ingress RBridge, used by transit
> RBridges for IRT VLAN-pruning (if practical), and simply stripped
> off at the egress.  This does not change the fact that these frames
> must then leave the CRED and be delivered to an L2 end-station (at
> least, as far as RBridges are concerned).  If anything is expected
> to make a re-forwarding decision, it would be the receiving end
> station, not the egress RBridge.
> 
> --
> Eric
> 
> -----Original Message-----
> From: Silvano Gai [mailto:sgai at nuovasystems.com]
> Sent: Thursday, November 16, 2006 8:23 PM
> To: Gray, Eric; Russ White
> Cc: rbridge at postel.org
> Subject: RE: [rbridge] IVLANs vs OVLANs
> 
> 
> 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
> > --> > -->
> > -->