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

Donald Eastlake <d3e3e3@gmail.com> Wed, 30 January 2013 00:37 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E7321F8684 for <trill@ietfa.amsl.com>; Tue, 29 Jan 2013 16:37:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.143
X-Spam-Level:
X-Spam-Status: No, score=-103.143 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMvCZqVoYNxZ for <trill@ietfa.amsl.com>; Tue, 29 Jan 2013 16:37:23 -0800 (PST)
Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7D32721F83EF for <trill@ietf.org>; Tue, 29 Jan 2013 16:37:23 -0800 (PST)
Received: by mail-oa0-f42.google.com with SMTP id i18so833718oag.1 for <trill@ietf.org>; Tue, 29 Jan 2013 16:37:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=h94FNRQay3F+veKoqD2of8XyeQKkGOY2G2DSJMdzyR4=; b=DcG1syGWRoxfNDJ+S5NtkDZVh3bx11sDzYdiot6dD9Kgdpn6hxhbpLdLMVWXv+HlFg u5FnZBu0zko1YW/BM0nSNjz+FIEG4MCNl65Q90HT4HnqmMwg0S7DU4j1RNn9yTAZ2MC3 ewXzDcqI9fHEg7OwZQymLurX1lBR/DJ+V6+Eij+19fVq19jfalMwj8d7ItFiMn0YKA8a pTG6AdFvDkZdrDn0CbxtzQ6yPkHsxr5jA3/pZns6rwqlZjZLj+Rt2EMvLapcsoQQGibl kD+ZWvvghQKOfM3UI4CpdTDAGsUuEv8yoT6yxSDdsvyP/5MpGjuG3kPbLsYQ14T4S+MG J0Tw==
X-Received: by 10.182.123.49 with SMTP id lx17mr2289499obb.63.1359506243073; Tue, 29 Jan 2013 16:37:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.76.98.168 with HTTP; Tue, 29 Jan 2013 16:37:02 -0800 (PST)
In-Reply-To: <CA+-tSzz0=oh6iB1e-ESyeOx2sCvBFXeVpzuNbKmUVhRNLScDgQ@mail.gmail.com>
References: <CAFOuuo67iBR2JkDtwPFCkrKHs3Fp4U_L1jkmNz5sfht6y05YMw@mail.gmail.com> <CA+-tSzx0E3J4i5Dvfbj4egruCeGi7z1se1Jn5RXtx3RedQLPdg@mail.gmail.com> <CAHD03N89RNX4=XxRZpD+Y2PCktYf-FtVjyYJ5oFS3dui3SsXaA@mail.gmail.com> <CAF4+nEG7YKGzGmObAMaOxackivjJsALymqHX=6PKBd5qU-Z+zQ@mail.gmail.com> <CA+-tSzz0=oh6iB1e-ESyeOx2sCvBFXeVpzuNbKmUVhRNLScDgQ@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Tue, 29 Jan 2013 19:37:02 -0500
Message-ID: <CAF4+nEFLrJL=CgX9e6on-cgz89ugmu93P6u5kmODhUia3H7RLg@mail.gmail.com>
To: Anoop Ghanwani <anoop@alumni.duke.edu>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Radia Perlman <radiaperlman@gmail.com>, Ayan Banerjee <ayabaner@gmail.com>, "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] Explaining three options for upgrading to FGL (fine-grained-labeling)
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, 30 Jan 2013 00:37:24 -0000

Hi Anoop,

On Tue, Jan 29, 2013 at 7:03 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:
> On Tue, Jan 29, 2013 at 12:49 PM, Donald Eastlake <d3e3e3@gmail.com> 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

Well, it can start sourcing FGL traffic but their are consequences as
you note below.

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

Yes. (This could just be due to some misconfiguration.)

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

Yes. But I don't think this as much of a problem given that I believe
existing TRILL switches can be software upgraded to be FGL-safe. I
view the configuration of FGL ports on RB1/RB2 and the consequent
routing of actual FGL traffic to be an active network management
decision, not something that might just happen because there appear to
be no more VL TRILL switches in the topology.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

> Anoop