Subject: [trill] more questions on "draft-ietf-trill-fine-labeling-01"

From: Linda Dunbar <[email-masked]>
Date: Tue, 10 Jul 2012 23:01:52 +0000

Donald, et al,

-        Section 3 (page 7) 3rd paragraph:

"Ethernet links between FGL TRILL switches still have only C-VLAN tagging on them"

When you talk about Ethernet Links between FGL TRILL switches, the VID is the outer Ethernet header above the TRILL header. Is it always "C-VLAN"? Why have this restriction?

-         Section 5.1: Can FGL RBridge also do VL RBridge function? For example, when the C-VLAN of the incoming frame is the VL specifiable data label, the FGL RBridge just simply performs the VL RBridge function. Is it possible?

-         Same goes with Section 5.3: when X is VL specifiable only, why can't the FGL RBridge simply decapsulates the frame as regular VL RBridge?

Thanks, Linda

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 10 Jul 2012 19:59:24 -0400

Hi Linda,

On Tue, Jul 10, 2012 at 7:01 PM, Linda Dunbar <[email-masked]> wrote:
> “Ethernet links between FGL TRILL switches still have only C-VLAN tagging on
> them”
>
> When you talk about Ethernet Links between FGL TRILL switches, the VID is
> the outer Ethernet header above the TRILL header. Is it always "C-VLAN"? Why
> have this restriction?

Perhaps the wording can be improved. The point is that an RBridge
never send a frame on an Ethernet link with an outer FGL. FGL can only
appear inside. Since RBridges are currently specified as customer
devices, if an RBridge sends a frame on an Ethernet link and the
RBridge port is configured to send tagged frames, the frame will have
an outer C-VLAN tag. However, as it says here and there, use of S-VLAN
tags is an obvious extension.

> -         Section 5.1: Can FGL RBridge also do VL RBridge function? For
> example, when the C-VLAN of the incoming frame is the VL specifiable data
> label, the FGL RBridge just simply performs the VL RBridge function. Is it
> possible?

Yes, I believe the draft requires an FGL RBridge to be able to do VL.
Section 5.1 says that a port may be configured to do FGL ingress
process implying that by default it does VL ingress processing that
Section 5.1 says in unchanged.

> -         Same goes with Section 5.3: when X is VL specifiable only, why
> can’t the FGL RBridge simply decapsulates the frame as regular VL RBridge?

I believe it can and must. The wording in Section 5.3 is less clear
than 5.1 and should probably state this more explicitly.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]