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

Jon Hudson <jon.hudson@gmail.com> Wed, 30 January 2013 20:41 UTC

Return-Path: <jon.hudson@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 B377221F88C7 for <trill@ietfa.amsl.com>; Wed, 30 Jan 2013 12:41:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Level:
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
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 HX4QQnvSconL for <trill@ietfa.amsl.com>; Wed, 30 Jan 2013 12:40:59 -0800 (PST)
Received: from mail-gh0-f179.google.com (mail-gh0-f179.google.com [209.85.160.179]) by ietfa.amsl.com (Postfix) with ESMTP id 454B221F88B6 for <trill@ietf.org>; Wed, 30 Jan 2013 12:40:59 -0800 (PST)
Received: by mail-gh0-f179.google.com with SMTP id r14so355888ghr.24 for <trill@ietf.org>; Wed, 30 Jan 2013 12:40:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=dAd1u+UhClckytY4DjnSl/yN3ZXdHUmmwyJtGtSvNoA=; b=NmMX0wlrfZb8yi9gR/KvKPs8NxxWU25y0Mwxa5pC3Kcio1XBPzWcNc0XVhSQLjFwIx U3dkRSvtYOmvIXUo+SiWJz7IUqYGq2RMqXg2V74Ei3ZFdRln9LeHxZk4KQ73o/2HUk7Q RZAe/vMp5A0Jhye6mRsFnyQf93duHonY0KIdw7mAndh3uBUwGl9Yu1aRxIItltJXJrZs 3JDBkkfrWFX7ReftkjvsIAHBmtcw7dBb5/P5Xe2Vg6brS5nJWD+/9Hz7BLh1/s4xmEn3 2fnyAcBTZ4fj40OFgJ4QES9D4fmJzrkTtnru9GFVNmKlt8gLDrz70GcPj/3P+vU+/Tgp W1Eg==
X-Received: by 10.236.131.9 with SMTP id l9mr7304279yhi.93.1359578458610; Wed, 30 Jan 2013 12:40:58 -0800 (PST)
Received: from [10.163.181.190] (mobile-166-147-115-015.mycingular.net. [166.147.115.15]) by mx.google.com with ESMTPS id s3sm4108359yhm.10.2013.01.30.12.40.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jan 2013 12:40:57 -0800 (PST)
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> <CAF4+nEFLrJL=CgX9e6on-cgz89ugmu93P6u5kmODhUia3H7RLg@mail.gmail.com> <1F5A81AE-4B3C-45FD-B431-9BA0011EB085@gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <1F5A81AE-4B3C-45FD-B431-9BA0011EB085@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <DC8898F8-75C0-4535-BA61-C54279901332@gmail.com>
X-Mailer: iPhone Mail (10B143)
From: Jon Hudson <jon.hudson@gmail.com>
Date: Thu, 31 Jan 2013 04:40:43 +0800
To: Sam Aldrin <aldrin.ietf@gmail.com>
Cc: Donald Eastlake <d3e3e3@gmail.com>, Anoop Ghanwani <anoop@alumni.duke.edu>, 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 20:41:00 -0000

Can you clarify on what you mean by deploy?

I ask because I have many customers waiting for this functionality. Everyone of the ~1000 installs we have, that also have multitenancy environments plan to deploy this as soon as possible. 

But with no one have I gone through and done a Visio of how their Rbridges are wired up today and how FGL rbridges would be integrated gracefully into the environment.

On Jan 31, 2013, at 3:55 AM, Sam Aldrin <aldrin.ietf@gmail.com> wrote:

> [still catching up on email, so the delay]
> 
> When everyone says, upgrade RBridges, what is the upgrade model they have in mind?
> How can one do software upgrade when hardware/silicon cannot support?
> Secondly, any actual users, not vendors, commented on how they plan to deploy FGL?
> 
> -sam
> 
> On Jan 29, 2013, at 4:37 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
> 
>> 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
>> _______________________________________________
>> trill mailing list
>> trill@ietf.org
>> https://www.ietf.org/mailman/listinfo/trill
> 
> _______________________________________________
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill