Subject: [rbridge] Is Inner VLAN Tag Required?

From: Andre Fredette <[email-masked]>
Date: Thu, 9 Sep 2010 13:48:51 -0700

Is the Inner VLAN tag required in all TRILL data frames?

Section 4.1.2 seems to suggest that the Inner VLAN tag is required, but doesn't come right out and say it, and a couple of other sections (2.5 and 4.1)  say that there may be two tags, but never say there must be in inner tag and may be an outer tag.

Thanks,
Andre

________________________________
DISCLAIMER:
This e-mail and any attachments to it may contain confidential and proprietary material and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed.
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 9 Sep 2010 18:19:39 -0400

Hi Andre,

> Is the Inner VLAN tag required in all TRILL data frames?

Yes, if the Inner.VLAN tag were not present in a TRILL Data frame,
there would be no way of telling what VLAN the encapsulated frame was
in.

> Section 4.1.2 seems to suggest that the Inner VLAN tag is required, but
> doesn’t come right out and say it, and a couple of other sections (2.5 and
> 4.1)  say that there may be two tags, but never say there must be in inner
> tag and may be an outer tag.

Well, toward the end of Section 4.1.3, it says

   Whether an Outer.VLAN tag actually appears on the wire when a TRILL
   frame is sent depends on the configuration of the RBridge port
   through which it is sent in the same way as the appearance of a VLAN
   tag on a frame sent by an [802.1Q-2005] bridge depends on the
   configuration of the bridge port...

The encapsulated frame is always in Ethernet format and VLAN tagged.
The outer transport header, even if it is for Ethernet, might not have
an Outer.VLAN tag. If there is an Outer.VLAN tag present, its purpose
is just to get the TRILL Data frame through to the next RBridge.

If you have a point-to-point Ethernet link between two RBridges, there
is generally no purpose in VLAN tagging any TRILL frames going between
those RBridges, unless there are intervening bridges or other VLAN
sensitive devices that require it. And, of course, if it is some other
type of point-to-point inter-RBridge link the outer transport header
might be PPP (http://tools.ietf.org/html/draft-ietf-pppext-trill-protocol-01),
or something else, with no provision for Outer.VLAN tagging.

> Andre

Thanks,
Donald

PS: For IETF purposes, you should use an email account that doesn't
put a confidentiality note at the end of your messages.

---

From: Radia Perlman <[email-masked]>
Date: Thu, 9 Sep 2010 16:36:39 -0700

I'm not sure the inner VLAN is "required".  I thought it was a bridge
configuration thing as to whether to explicitly put in a VLAN tag.
So, if in a regular bridged net, it is legal for S to send an Ethernet
packet to D, and it would not need to have a VLAN tag, then it
wouldn't be required in TRILL either.

If there is a use of TRILL that doesn't require endnode VLAN tags,
then I don't see why TRILL should require it.

It's only if it is desired for endnodes to be partitioned into VLANs
that it is necessary to have the inner VLAN tag.

Likewise, if there is a link between R1 and R2 that doesn't require a
VLAN tag in order for the packet to get from R1 to R2, I wouldn't
think there would need to be an outer VLAN tag.

Or at least that's how I understand it.

Radia

---

From: Dinesh Dutt <[email-masked]>
Date: Thu, 09 Sep 2010 18:26:29 -0700

Donald is right, the inner VLAN is mandatory,

Dinesh
On 09/09/2010 04:36 PM, Radia Perlman wrote:
> On Thu, Sep 9, 2010 at 3:19 PM, Donald Eastlake<[email-masked]>  wrote:
>    
>> Hi Andre,
>>

---

From: Anil Rijhsinghani <[email-masked]>
Date: Fri, 10 Sep 2010 08:51:19 -0400

Dinesh,

If we require that a packet be cvlan-tagged within a Trill- 
encapsulated frame, I can't think of anything that would break, but I  
can think of scenarios when it's not useful, such as when you have  
default vlan or pvid, or native packets that can be vlan-classified  
from packet fields like e-type, address, etc. A nice side effect in  
these cases is you avoid bumping up packet size further.

Just curious, what could break if the inner vlan was not there? If the  
outer vlan were required - which it isn't - I could understand that  
better since it's a TRILL protocol-related vlan tag, in a sense  
similar to b-vlan in .1ah (in the latter, outer vlan is required but  
inner isn't.)

Regards,
Anil

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 12 Sep 2010 09:58:52 -0400

Hi Anil,

> these cases is you avoid bumping up packet size further.

If I recall correctly, a number of these issues were discussed in the
WG. In particular, the idea of dropping the Inner.VLAN if the VLAN was
1. But the WG decided that it wouldn't be worth the savings and it
left some questions about priority unanswered.

I'm not sure that PVID has much to do with it. If a transit RBridge
received a multi-destination TRILL Data frame without an Inner.VLAN or
if an egress RBridge received such a TRILL data frame, and assuming
they were willing to handle it, they would have to assign it a VLAN to
be able to prune the distribution tree in the transit case or to
decide where it is safe to deliver the decapsulated native frame in
the egress case. I'm not sure that using the PVID (Port default VLAN
ID) of the port on which the TRILL data frame was received would help.
That could make the encapsulated frame appear to be in different VLANs
depending on what path it took and to be in different VLANs at
different points along its path or the like.

On the other hand, if you could determine the VLAN of the encapsulated
frame from MAC addresses or Ethertype or the like and you knew that
all the RBridges in the campus could do that, maybe you could
configure something outside the existing TRILL standard to omit the
Inner.VLAN. And it would be nice to save those bytes. But you still
have the question of priority. TRILL is designed so as not to be
dependent on the presence of the Outer.VLAN so I don't think you can
depend on that for priority. The sending RBridge port might be
configured to strip Outer.VLAN tags as might any intervening bridge or
bridges. Or the link might be PPP or something else where there isn't
any Outer.VLAN at all.

You could have an extension to the TRILL standard for low end RBridges
where you didn't care about VLAN or priority and which wasn't VLAN
aware but I wonder how much demand there would be for that...

> similar to b-vlan in .1ah (in the latter, outer vlan is required but

The entire set of TRILL outer header: Outer.MacDA, Outer.MacSA,
optional Outer.VLAN, and Ethertype, are really just a transport and
interpretation artifact for a TRILL data frame. Their purpose is to
get the following TRILL Header and encapsulated Ethernet frame from an
RBridge safely to the next hop RBridge in such a way that the
receiving RBridge knows to process it as a TRILL data frame. The
Outer.* fields can change every RBridge hop, which seems different
from a b-vlan to me. Of course the Ethertype stays the same as long as
you are on Ethernet links but, for example, on a PPP link you
negotiate a TRILL data PPP type and the TRILL Ethertype field isn't
even present.

Thanks,
Donald

---

From: Dinesh Dutt <[email-masked]>
Date: Mon, 13 Sep 2010 15:34:44 -0700

Sorry, I was out of the office last week.

On 09/10/2010 05:51 AM, Anil Rijhsinghani wrote:
> Dinesh,
>
> If we require that a packet be cvlan-tagged within a 
> Trill-encapsulated frame, I can't think of anything that would break, 
> but I can think of scenarios when it's not useful, such as when you 
> have default vlan or pvid, or native packets that can be 
> vlan-classified from packet fields like e-type, address, etc. A nice 
> side effect in these cases is you avoid bumping up packet size further.
A nice side-effect of mandating the inner VLAN is that we don't have to 
deal with VLAN being present or not present. It's always there. We don't 
have to deal with priority being present or not present. Simplifies a 
lot of processing that seems unnecessary.

> similar to b-vlan in .1ah (in the latter, outer vlan is required but 
Configuration gets more error-prone, for example. If we assume PVID 
concept, it is easy to hop VLANs and such. In TRILL, the problem is 
exacerbated because except for multi-destination frames, intermediate 
devices don't look at the VLAN and so maintaining the correctness of 
configuration gets trickier than regular 802.1D bridges. By mandating 
that the VLAN be always present, configuring VLANs becomes an edge-only 
function, considerably simplifying configuration. Unlike 802.1D bridges, 
a user can configure a VLAN only at the Rbridges where the VLAN is 
required and not everywhere else. With a default VLAN, we have to ensure 
the correct configuration of default VLAN in every box.

In short, we get a lot of benefits,

Dinesh