[trill] FGL "safe" mode in fine labels

Thomas Narten <narten@us.ibm.com> Wed, 20 March 2013 18:59 UTC

Return-Path: <narten@us.ibm.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9340321F8FC0 for <trill@ietfa.amsl.com>; Wed, 20 Mar 2013 11:59:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id jDDo-znFFBtT for <trill@ietfa.amsl.com>; Wed, 20 Mar 2013 11:59:45 -0700 (PDT)
Received: from e34.co.us.ibm.com (e34.co.us.ibm.com []) by ietfa.amsl.com (Postfix) with ESMTP id 0C5B521F8FA1 for <trill@ietf.org>; Wed, 20 Mar 2013 11:59:45 -0700 (PDT)
Received: from /spool/local by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <trill@ietf.org> from <narten@us.ibm.com>; Wed, 20 Mar 2013 12:59:43 -0600
Received: from d03dlp01.boulder.ibm.com ( by e34.co.us.ibm.com ( with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 20 Mar 2013 12:59:30 -0600
Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com []) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id D0A841FF004B for <trill@ietf.org>; Wed, 20 Mar 2013 12:54:33 -0600 (MDT)
Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com []) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2KIxQxK027120 for <trill@ietf.org>; Wed, 20 Mar 2013 12:59:26 -0600
Received: from d03av03.boulder.ibm.com (loopback []) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r2KIxNAM000791 for <trill@ietf.org>; Wed, 20 Mar 2013 12:59:23 -0600
Received: from cichlid.raleigh.ibm.com ([]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r2KIxKn9000625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <trill@ietf.org>; Wed, 20 Mar 2013 12:59:22 -0600
Received: from cichlid.raleigh.ibm.com (localhost.localdomain []) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id r2KIxJ32017742 for <trill@ietf.org>; Wed, 20 Mar 2013 14:59:19 -0400
Message-Id: <201303201859.r2KIxJ32017742@cichlid.raleigh.ibm.com>
From: Thomas Narten <narten@us.ibm.com>
To: trill@ietf.org
Date: Wed, 20 Mar 2013 14:59:18 -0400
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 13032018-2876-0000-0000-00000688A374
Subject: [trill] FGL "safe" mode in fine labels
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trill>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2013 18:59:45 -0000

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

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

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.