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

Thomas Narten <> Wed, 20 March 2013 20:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B7B391F0D0F for <>; Wed, 20 Mar 2013 13:33:03 -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 cCuVOo25hBXO for <>; Wed, 20 Mar 2013 13:33:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F3E261F0C36 for <>; Wed, 20 Mar 2013 13:33:02 -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 16:32:54 -0400
Received: from ( by ( with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 20 Mar 2013 16:32:52 -0400
Received: from ( []) by (Postfix) with ESMTP id 82D676E803F for <>; Wed, 20 Mar 2013 16:32:49 -0400 (EDT)
Received: from ( []) by (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2KKWp0I29294812 for <>; Wed, 20 Mar 2013 16:32:51 -0400
Received: from (loopback []) by (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r2KKWSWk001252 for <>; Wed, 20 Mar 2013 14:32:29 -0600
Received: from ([]) by (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r2KKWRCV001081; Wed, 20 Mar 2013 14:32:27 -0600
Received: from (localhost.localdomain []) by (8.14.5/8.12.5) with ESMTP id r2KKWOMj030163; Wed, 20 Mar 2013 16:32:24 -0400
Message-Id: <>
From: Thomas Narten <>
To: Radia Perlman <>
In-reply-to: <>
References: <> <>
Comments: In-reply-to Radia Perlman <> message dated "Wed, 20 Mar 2013 13:08:49 -0700."
Date: Wed, 20 Mar 2013 16:32:24 -0400
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 13032020-9360-0000-0000-0000116942F4
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:33:03 -0000

Hi Radia.

> 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"

I understand that, but what is the value in writing a standard with
that sort of description? The FGL document should be about what you
have to do to be compliant and how to get interoperabilty. "Not doing
anything bad" doesn't seem like the right way to say that...

> as opposed to being able to understand FGL labels.

Could someone then please layout what capabilities an "FGL safe" RB
has that a "fully compliant" RB does not? What is the difference?
Better yet, point me to text in the document that explains that.

> 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.

Actually, all they need to know is whether there is *one* RB that
*doesn't* understand FGL. If one such RB exists, everyone just
operates in VL mode. (Right?)

If that is what the intended behavior is, why can't the document just
come out and clearly say that? 

> 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 find this sort of definition somewhat maddening.

What we need to clearly describe is when an RB is capable of
supporting FGL (fully) and when can FGL be enabled on a TRILL campus
(and then on which RBs).  And will this be clearly understood by an
operator trying to actually use and deploy the functionality?

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

> > 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
> draft.

Great. But it's really frustrating when folk start saying "I agree the
document isn't so good, but we need to publish it anyway" with the
implication being "no thanks for taking the time to review and trying
to make the document better".