Subject: Re: [rbridge] Is Inner VLAN Tag Required?

From: Andre Fredette <[email-masked]>
Date: Thu, 09 Sep 2010 22:28:04 -0400

Allowing TRILL data frames without an inner VLAN tag could be made to 
work like it does on regular Ethernet switches by configuring a default 
VLAN ID for untagged frames. That said, I think it is simpler if the 
inner VLAN tag is required, and in the case that Radia mentions where 
the edge nodes don't need frames to be tagged, the ingress RBridge would 
insert the default VLAN ID.

In any case, I asked the question because it is not crystal clear to me 
from the document. Section 4.1.2 states:

"If the RBridge is an appointed
forwarder for that VLAN and the delivery of the frame requires
transmission to one or more other links, this ingress RBridge forms a
TRILL data frame with the associated VLAN ID and priority placed in
the Inner.VLAN information."

Which will result in the Inner.VLAN information always being in the 
frame if followed to the letter, but could be made more definitive, and 
the wording in the other sections I mentioned could be made more clear 
as well.

So, in either case, I think an editorial change would be good to make it 
clear which way is intended.

Thanks,
Andre

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On 
Behalf Of Dinesh Dutt
Sent: Thursday, September 09, 2010 9:26 PM
To: [email-masked]
Subject: Re: [rbridge] Is Inner VLAN Tag Required?

Donald is right, the inner VLAN is mandatory,

Dinesh
On 09/09/2010 04:36 PM, Radia Perlman wrote:
 > 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
 >
 >
 >
 > On Thu, Sep 9, 2010 at 3:19 PM, Donald Eastlake<[email-masked]> wrote:
 >
 >> Hi Andre,
 >>
 >> On Thu, Sep 9, 2010 at 4:48 PM, Andre Fredette
 >> <[email-masked]> wrote:
 >>
 >>> 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.
 >>
 >>
 >>> Thanks,
 >>> 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.
 >>
 >> _______________________________________________
 >> rbridge mailing list
 >> [email-masked]
 >> http://mailman.postel.org/mailman/listinfo/rbridge
 >>
 >>
 > _______________________________________________
 > rbridge mailing list
 > [email-masked]
 > http://mailman.postel.org/mailman/listinfo/rbridge
 >
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 10 Sep 2010 00:12:28 -0400

Hi Andre,

> insert the default VLAN ID.

Sure. You need to distinguish native frames and TRILL Data frames. An
ingress RBridge is one performing the function of receiving a native
frame and encapsulating it. The RBridge port receiving that frame
always assigns it to a VLAN, just like an 802.1Q-2005 port does. The
port does this for a TRILL Data frame it receives as well but the
Inner.VLAN is what actually controls further processing of the
encapsulated frame.

> clear which way is intended.

OK. A few editorial clarification points have been brought up on the
list, including this one. I think these clarifications can be made as
part of the AUTH48 process for the base protocol standard.

Thanks,
Donald

>  > 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
>  >
>  >
>  >
>  > On Thu, Sep 9, 2010 at 3:19 PM, Donald Eastlake<[email-masked]> wrote:
>  >
>  >> Hi Andre,
>  >>
>  >> On Thu, Sep 9, 2010 at 4:48 PM, Andre Fredette
>  >> <[email-masked]> wrote:
>  >>
>  >>> 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
>  >> or something else, with no provision for Outer.VLAN tagging.
>  >>
>  >>
>  >>> Thanks,
>  >>> 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.
>  >>
>  >> _______________________________________________
>  >> rbridge mailing list
>  >> [email-masked]
>  >> http://mailman.postel.org/mailman/listinfo/rbridge
>  >>
>  >>
>  > _______________________________________________
>  > rbridge mailing list
>  > [email-masked]
>  > http://mailman.postel.org/mailman/listinfo/rbridge
>  >

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 10 Sep 2010 18:25:04 -0700

> clear which way is intended.

The .problem is that there is no default for an untagged frame,
there is a default for an untagged frame received on a specific port.

The only way for two RBridges to .exchange inner L2 frames
lacking VTAGs .would .be .for them to .somehow share the same
default VLAN for all ports, and to know that they did.

The intermediate RBridges should not be inspecting the inner
packet, so any specialized collaboration between ingress and
egress RBridges should work. But I cannot see any justification
for standardizing such an optimization.

--
Caitlin Bestler
[email-masked]
http://www.asomi.com/CaitlinBestlerResume.html