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

Erik Nordmark <> Thu, 04 April 2013 04:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8083F11E80A5 for <>; Wed, 3 Apr 2013 21:17:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Sg+HUMN8kNZv for <>; Wed, 3 Apr 2013 21:17:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3ACE711E80A2 for <>; Wed, 3 Apr 2013 21:17:58 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id r344HsSe000454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Apr 2013 21:17:55 -0700
Message-ID: <>
Date: Wed, 03 Apr 2013 21:17:56 -0700
From: Erik Nordmark <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Thomas Narten <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Radia Perlman <>,
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, 04 Apr 2013 04:18:00 -0000

On 3/20/13 2:19 PM, Thomas Narten wrote:

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

FWIW Your use of "FGL-link" is not consistent with the definition in the 
The document defines it as "A link where all of the attached TRILL 
switches are FGL."

I think what you refer to in #4 is what the document calls FGL-edge.

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

While the above 1-4 is a reasonable way to deploy FGL, the protocol 
mechanisms must be robust against there (perhaps accidentally) being VL 
RBridges when FGL-edges are in use; whether that is because not all was 
upgraded to FGL-safe, or after everything is FGL-safe someone (perhaps 
accidentally) connects one or more VL RBridges to the network.

That is why we have the rules about safety - not forwarding a FGL frame 
to a VL RBridge.