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

Donald Eastlake <> Wed, 20 March 2013 22:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 330EB21F8BBC for <>; Wed, 20 Mar 2013 15:00:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ofTYPL7yalBU for <>; Wed, 20 Mar 2013 15:00:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c01::236]) by (Postfix) with ESMTP id 8B97321F8AE8 for <>; Wed, 20 Mar 2013 15:00:10 -0700 (PDT)
Received: by with SMTP id va7so2173674obc.41 for <>; Wed, 20 Mar 2013 15:00:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=PusiahwQSpxLXK/GO7uGaAFuWPXPBOMmu8SdmiI+ka4=; b=CdKOanmbTI/f7yCUraR4vhxbeAgrqN2FGFVa/9Iq8F03ixrBKACiGZ1X3ShJ8cdWm0 e2uDm3rB4pL2oU4PdrEqZ5xe8AyujV69jGR4yj6rJk7y696SJdCmrynHJ8tamWvtXJa+ VXGO+mE+edcJpanZyz7A073xgiD/autY613/pPB+X7QerF2NoJcUjJrRxoZE6leu2WKw p+TR9i0/2iqC2QaoTJQ438ipWOtqOsDUe4rc/cx7DwqEnlzMBxSDOsVZ2Z6JBPO/ecz7 xKVU9sI7hR8awn3c5pomhi0WdZ/BUT8bfTreWcb/MoPk268GRh+y+wkJi1xouhJYjvrD Mhbw==
X-Received: by with SMTP id a2mr5215075oef.97.1363816809990; Wed, 20 Mar 2013 15:00:09 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 20 Mar 2013 14:59:49 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Donald Eastlake <>
Date: Wed, 20 Mar 2013 17:59:49 -0400
Message-ID: <>
To: Thomas Narten <>
Content-Type: text/plain; charset=ISO-8859-1
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: Wed, 20 Mar 2013 22:00:11 -0000

Hi Thomas,

On Wed, Mar 20, 2013 at 5:19 PM, Thomas Narten <> wrote:
> Radia,
>> No!  There isn't any mention in the document of "operating in VL
>> mode", whatever it is you might mean by that.
> Operating in "VL mode" (to me) means you don't know anything about FGL
> and operate as described in RFC 6325 et al. I.e., the base mode of
> operation for TRILL. I think it's useful to define a term like "VL
> mode" to describe that behavior to distinguish it from RBs that have
> somehow enabled and are using FGL.

The use of "mode" and "enable" all imply to be a big toggle-switch.
There is no such big toggle-switch.

It many cases, it might be a bit obscure to tell if a TRILL switch is
FGL-safe or VL if there are no FGL-edges/FGL-packets to tickle it into
FGL behavior. But an FGL-safe TRILL switch always behaves as an
FGL-safe TRILL switch. In particular, it always announces itself in
its LSP as FGL-safe and it always conforms to Section 4.5 of the draft
as far as distribution tree construction goes. So, even in the absence
of any FGL-edge TRILL switches and any FGL packets, an FGL-safe TRILL
switch behaves in a way that is still distinguishable from the
behavior of a VL TRILL switch.

>> If R1 is FGL-safe, and if R1's neighbor R2 does not claim to be FGL-safe,
>> then R1 does not forward FGL frames to R2.  R1 does not do anything
>> different if some non-neighbor of R1, say R3, is not FGL-safe.
> The above says to me that you now have a TRILL campus where R1 does
> process FGL frames and R2 does not. But doesn't that contradict the
> model:
>> 1) VL-only (today's deployment), then
>> 2) A mixture of VL and FGL-safe, until
>> 3) EVERYone upgraded to FGL-safe, then
>> 4) FGL-links [FGL-edges] can be introduced.

While this is the smoothest and most complete migration scenario,
there certainly might be TRILL switches that cannot be upgraded to be
FGL-safe or FGL-edges might appear before step 3 is complete due to
misconfiguration or whatever. In either case, you still must safely
handle FGL packets.

> Or maybe we are having a violent agreement? if we are at step 2)
> above, then isn't the entire campus operating in "VL mode"? I.e., at
> step 2, no one is sending/receiving/processing FGL frames. (Right?)

Almost. See above for the ways (admittedly a bit obscure) that
FGL-safe TRILL switches would be behaving differently from VL TRILL
switches even when there are no FGL-edges/packets.

> It's not until step 3/4 that you see *any* FGL frames being used. And
> for that, you can't have *any* RBs still operating only in VL mode -
> they *all* have to support FGL.

No. Co-existence of FGL-safe and VL TRILL switches in one campus is
the whole point of mandating the behavior in Section 5.1. So you will
be safe and can handle FGL packets within a contiguous island of
FGL-safe TRILL switches regardless of the presence of VL TRILL

Furthermore, if the nature of your FGL-safe TRILL switches that are
directly adjacent to a VL TRILL switch is such that you can use step
(A) in Section 5.1, you can even communicate VL packets between end
stations attached to VL TRILL switches and end stations attached FGL
TRILL switches in your campus. (But this will not be possible if your
FGL-safe TRILL switches that are immediately adjacent to VL switches
cannot support step (A) and have to use step (B).)

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA

> What is it that I'm not understanding?
> Thomas