Re: [trill] FGL "safe" mode in fine labels

Thomas Narten <> Thu, 21 March 2013 01:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E33111E8119 for <>; Wed, 20 Mar 2013 18:03:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WHybxNJoxEcg for <>; Wed, 20 Mar 2013 18:03:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 447D311E810D for <>; Wed, 20 Mar 2013 18:03:28 -0700 (PDT)
Received: from /spool/local by with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <> from <>; Wed, 20 Mar 2013 21:03:27 -0400
Received: from ( by ( with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 20 Mar 2013 21:03:26 -0400
Received: from ( []) by (Postfix) with ESMTP id 0E6EC6E801D for <>; Wed, 20 Mar 2013 21:03:24 -0400 (EDT)
Received: from ( []) by (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2L13Qqw301522 for <>; Wed, 20 Mar 2013 21:03:26 -0400
Received: from (loopback []) by (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r2L13O15026180 for <>; Wed, 20 Mar 2013 22:03:25 -0300
Received: from ([]) by (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r2L13MRY026086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Mar 2013 22:03:23 -0300
Received: from (localhost.localdomain []) by (8.14.5/8.12.5) with ESMTP id r2L13KOi032305; Wed, 20 Mar 2013 21:03:20 -0400
Message-Id: <>
From: Thomas Narten <>
To: Donald Eastlake <>
In-reply-to: <>
References: <> <> <> <> <> <>
Comments: In-reply-to Donald Eastlake <> message dated "Wed, 20 Mar 2013 17:59:49 -0400."
Date: Wed, 20 Mar 2013 21:03:20 -0400
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 13032101-9360-0000-0000-00001169EB4C
Subject: Re: [trill] FGL "safe" mode in fine labels
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Mar 2013 01:03:29 -0000

So, it seems to me that there are several different deployment
combinations involving VL and FGL.

1) Mixture of VL only and FGL-safe RBs, but no FGL-edges. To me, this
case is pretty uninteresting, in the sense that since all the RB-edges
understand only VL, there is zero reason to use FGL anywhere. Thus, in
this case, I would expect FGL-safe RBs to advertise that they are
FGL-safe, but all RBs would operate in VL-only mode.

Does this make sense?

2) A second possibly uninteresting case consists of a mixture of VL
only and FGL-safe RBs, all edges are FGL-edges. In this case, you do
have VL-only transit RBs (they are not connected to edges). This case
is sort of weird in that the VL-only transit RBs are useless and
aren't used. So I'd just rule this case out of scope.

Well, except an operator needs to be aware of this restriction, so
they aren't surprised.

Does this make sense?

3) The interesting cases are where you have a mixture of VL-only and
FGL-safe RBs AND a mixture of VL-edges and FGL-edges. This is the
tricky case.

This leads to two different problems.

3a) First, if you are using both VL-Edges and FGL-edges, what is the
interoperabilty model intended to be? If RB1 is VL-only and supports
VLAN 1, but RB3 is an FGL-edge and also accepts traffic on VLAN 1,
what is supposed to happen? Is traffic supposed to be relayed between
those two VLANs? Why or why not?

My impression from the document is that the above case is handled by
saying "ships in the night", you don't get communication in that
case. Is that correct?  Either way, I think the document should
explain this more directly -- its critical to understanding the
transition approach when deploying FGL.

3b) Whatever the answer for 3a), there is a separate problem that you
may have FGL-safe RBs and VL-only RBs, and you can't forward FGL
traffic via a VL-only RB. That means that the SPF calculation that
creates the TRILL routing table conceptually runs two different
instances: one covering only FGL-safe RBs, another covering all
RBs. FGL frames are only sent using the routing table built from the
FGL-safe RBs, VL frames are sent via the other table. The edge RBs
Ethernet Frames ingress into the TRILL network decide which
encapsulation (VL or FGL) gets used.

The current document supports model 3b), though doesn't explain it
directly. One ends up deriving this behavior from the details in the

Do I have this right?