Subject: [rbridge] IVLANs vs OVLANs

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Thu, 16 Nov 2006 22:08:10 -0500

Silvano,

	Forget the "Null VLAN" concept for the moment, and look at
the rest of what you're saying.

	What part of the quote you provide (below) from what 802.1Q
says, leads you to conclude what you say in the next paragraph -
i.e. - that an 802.1Q compliant "switch" only handles tagged frames?

	The way I read the quote, 802.1Q is making a complicated (but
- in my opinion - very wise) observation.  The observation - broken
into its explicit components is:

1)	a device MAY use other means to associate frames with a VLAN,
2)	these other means are considered extensions to 802.1Q and are
	(therefore) not addressed by 802.1Q.

An implicit observation that can be derived from this is:

3)	any such extensions may be implemented in a device and - as
	long as that device is otherwise compliant with 802.1Q - these
	extensions are allowed by 802.1Q.

The derivation for this third observation is as described in the
next few (un-indented) paragraphs.

First, the quote you provide - in no way - states (or clearly implies) 
that any device that supports any sort of extension to 802.1Q is not 
compliant with 802.1Q.

Second, the way that protocol specifications work is that anything 
not explicitly (or otherwise obviously) prohibited, is allowed.

This is the only reasonable way to deal with the possibility of any
sort of protocol that is intended (or allowed) to be extended.  By
merely stating that these are potential extensions to the protocol,
without explicitly stating that such extensions are not allowed, a 
protocol specification is making it clear that such extensions are
allowed by the protocol.

At best, you could argue that the 802.1Q "compliant function" is
logically separated from the "mapping function" but to argue that
this separation makes an implementation that is done that way "non
compliant" is to make a completely specious argument.

	Now, let's get back to the "NULL VLAN" case.  

	Whatever we call it, there is one case in which a frame is 
received by a bridge - without any VLAN tagging - and is mapped to
a specific logical VLAN (using any reasonable criteria).  In being
forwarded, such a frame MAY be tagged using 802.1Q.  This happens.

	For some people, it is convenient to view this as logically
equivalent to having received a frame from a "default VLAN", on a
logical interface defined by whatever criteria the implementation
may use to determine the frame belongs in a specific VLAN.

	There is also the case in which a 802.1Q tagged frame is
intended to be forwarded on a physical interface, without the tag.

	It is actually the combination of these two cases that tends 
to define what sorts of criteria it makes practical sense to use 
in defining an "802.1Q extension-based" VLAN.  Because people are
required to think about this combined case, it is important to have 
some term you use to talk about the "untagged" case.  Some people 
have referred to that case as the "NULL VLAN" case.

	If you have a term you feel is better, then maybe we can use 
your term sometimes.

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