Re: [trill] Explaining three options for upgrading to FGL (fine-grained-labeling)

Anoop Ghanwani <> Wed, 30 January 2013 00:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E957A21F886A for <>; Tue, 29 Jan 2013 16:03:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AIuHcfdOFcpB for <>; Tue, 29 Jan 2013 16:03:19 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c02::229]) by (Postfix) with ESMTP id 8053321F8863 for <>; Tue, 29 Jan 2013 16:03:19 -0800 (PST)
Received: by with SMTP id j5so1480331iaf.14 for <>; Tue, 29 Jan 2013 16:03:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=iLHRQkIf9b3yMKcMak8AbiphZle9mdEQC1G5bzNUxI0=; b=Fr7U4xmvJC/BkhuDypRe1UVOx32r0Wa8GX6YqZBHFJCOX652vgmi1PM/aBCYMCc3sG d7FGvaRnt9SPC5SaMj/tcpAU3jnp14KRBEvwmU141UgBLE6JGN4ee7tbx1W6FFgLrKOp CtmFVotDlX+kr+WXhL1lDsHzIlBSudvmA2nT+sxmvRfYW/lyi9Y0LPbQrsP8xR+umiC+ /1EAHtnNvW1aR333gLz1WGom7JJ30Po5n+ciUjily6vc/xoQ5E1BMvO1Jds6hvpDVwt8 2CHxkOJVZZarOym8RzyduRZSTuZMuhiA4w9bhqOF62CS6ujBIpLBBewZwNkuEFfhdAbK tRKQ==
MIME-Version: 1.0
X-Received: by with SMTP id k1mr2259264igb.102.1359504198784; Tue, 29 Jan 2013 16:03:18 -0800 (PST)
Received: by with HTTP; Tue, 29 Jan 2013 16:03:18 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 29 Jan 2013 16:03:18 -0800
X-Google-Sender-Auth: JMUdA-6E9TNUzHyCmjndXMwBy3Q
Message-ID: <>
From: Anoop Ghanwani <>
To: Donald Eastlake <>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Radia Perlman <>, Ayan Banerjee <>, "" <>
Subject: Re: [trill] Explaining three options for upgrading to FGL (fine-grained-labeling)
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, 30 Jan 2013 00:03:20 -0000

On Tue, Jan 29, 2013 at 12:49 PM, Donald Eastlake <> wrote:

> The general assumption is that you are migrating from VL to FGL. First
> you migrate to FGL-safe. Then you unleash the FGL traffic, by
> configuring FGL ports, which isolates any remaining (FGL-unsafe) VL
> switches while still being able to handle VL traffic between VL ports
> on FGL-safe switches.

Based on what is written so far, it looks like as long as there is even
one VL RBridge in it's database, an RBridge would not be able to start
sourcing FGL traffic.  It may start doing so only when all RBridges in
its database are FGL-safe.  If we ever get into a condition where
an RBridge has started advertising FGL information, at that point,
does any other RBridge in the campus simply isolate any VL RBridge
(with the assumption that there was some kind of race condition?

The case I'm concerned about is we have 2 FGL RBridges, RB1 and RB2.
RB1 is connected to a campus of n RBs that are still VL only.  The VL link
Breaks, and RB1 starts advertising FGL information to RB2, but then
the link to the VL campus comes back up.  Does this mean RB1 and RB2
remain isolated from the campus (and operate as they own mini-campus)
until all the other RBridges are converted over to FGL-safe?