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

Radia Perlman <> Wed, 20 March 2013 20:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E83321F8265 for <>; Wed, 20 Mar 2013 13:08:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ivB90oZ00g7B for <>; Wed, 20 Mar 2013 13:08:57 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::235]) by (Postfix) with ESMTP id 35FE921F8546 for <>; Wed, 20 Mar 2013 13:08:51 -0700 (PDT)
Received: by with SMTP id fr10so3769232lab.12 for <>; Wed, 20 Mar 2013 13:08:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8Ucna0oFxzWY5clzf6201QH13Y0yJjOxzlOHV+TicSo=; b=v/syy824FBevjk900a9O7TCUIHM+ugDtGYWZveXVbgHdw9Xf2fBWJAUzOdJxU5kI7O mKfZzYkD94lNXtRglPUCBScCDaCKukYXHdzHyQMpJaams/a6pXtmxBfz/UGcXVTr1x4Z k+METrS+1Yn4UWLtnz34E65fD6hyacjDDc42vLpVQ6uhNBbI3qpinCmSBXTGOxpzuqqi Y/LPkHGMvd+y532fbJoz6rznnqa9bbXx15EA06bx36n06/elNG68joW1Ux9YbkzL5KeG Ef1VuVjuLK4IHuABmmCHoVXtTeXjQI/gRghdtuJuGQkcM9deLc99VbzidalWyYmjFvjW 02ig==
MIME-Version: 1.0
X-Received: by with SMTP id s4mr894753lba.106.1363810130084; Wed, 20 Mar 2013 13:08:50 -0700 (PDT)
Received: by with HTTP; Wed, 20 Mar 2013 13:08:49 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Wed, 20 Mar 2013 13:08:49 -0700
Message-ID: <>
From: Radia Perlman <>
To: Thomas Narten <>
Content-Type: multipart/alternative; boundary=e0cb4efe293c58528704d860ca1a
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 20:08:58 -0000

I never get too excited about what words are used, but the terminology
"FGL-safe" is intended to mean "doesn't do anything bad with FGL traffic"
as opposed to being able to understand FGL labels.
So, indeed, "FGL-capable" would, I believe, evoke a different image from
"FGL-safe", since the reader would assume from the word "FGL-capable", that
it would actually be able to parse FGL labels.  And indeed, it doesn't
matter to R1 whether distant RBridge R2 is FGL-capable...the only time R1
needs to do something different is if R2 is not FGL-safe.

Whether R2 is indeed "FGL-capable" is really only a local matter...whether
it can sink or source FGL traffic, so obviously if it isn't FGL-capable, it
won't actually claim to be connected to an FGL link.

I thought the writeup that I'd done explaining the four steps, that you

> 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 can be introduced.

was clearer than what is in the current draft, but I didn't argue since I
believe the current draft does have that technical behavior.  Most drafts
could be written more clearly, but we really are way overdue for issuing
this, and I wouldn't want to delay it because of editorial issues with the


On Wed, Mar 20, 2013 at 11:59 AM, Thomas Narten <> wrote:

> I spent some time rereading the current fine labels draft
> (draft-ietf-trill-fine-labeling-05.txt) and the January email thread
> on "safe mode" (Re: [trill] Explaining three options for upgrading to
> FGL (fine-grained-labeling)).
> But I'm still not sure I understand...
> What exactly is "FGL-safe mode"? I see the definition in the document,
> but it doesn't explain at a high level what this mode is intended to
> do. I.e., what the principles are. I.e., what does it mean for a TRILL
> campus (as opposed to an individual RB)?
> Is "safe" mode just another word for "FGL capable", i.e., the
> implementation is capable of fully supporting FGL?
> Or is there a broader definition for "capable"? (Some other messages
> seem to suggest this) If so, what is the difference?
> Finally, what is the migration path from VL to FGL in a real
> network?
> Back in January, Radia said
> (
> > So...again...the migration phases in option 2 are
> > 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 can be introduced.
> From the above, I conclude that there is no FGL traffic and no actual
> usage of FGL capabilities until step 4.  That makes sense to me, but
> this is not explained clearly in the current draft. Indeed, it's
> pretty easy to conclude from the draft that an RB operates in both FGL
> and VL mode at the same time from the way the behavior is described
> (often talking about an RB having some links doing FGL and some doing
> VL).
> PS, to me "FGL safe" doesn't seem like the right term. Wouldn't "FGL
> capable" be more accurate, and then distinguish between an
> implementation fully supporting FGL (i.e., is "capable") vs. that
> capability being enabled operationally? That would seem to more
> clearly reflect what (I think) is the intended behavior.
> Thomas
> _______________________________________________
> trill mailing list