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

Sam Aldrin <aldrin.ietf@gmail.com> Wed, 30 January 2013 23:25 UTC

Return-Path: <aldrin.ietf@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 6DC5221F87B3 for <trill@ietfa.amsl.com>; Wed, 30 Jan 2013 15:25:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.901
X-Spam-Level:
X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=-0.698, 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 eiG9yIhepbiE for <trill@ietfa.amsl.com>; Wed, 30 Jan 2013 15:25:36 -0800 (PST)
Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9193F21F8639 for <trill@ietf.org>; Wed, 30 Jan 2013 15:25:36 -0800 (PST)
Received: by mail-pa0-f41.google.com with SMTP id fa11so697629pad.28 for <trill@ietf.org>; Wed, 30 Jan 2013 15:25:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=fRuhvatqSMRVdjpANCbWXGxzh6XQz3p5hwastQgedLI=; b=wj3IjmEMZb7u0ihNLb1UmkzDHlBfyBSo2/rAL0j5NljrVrcyvY89ICLvFTPvHjkSM5 yx03sfC6Fpjdh1HYu6uQSv5XvhhqdLXLDDp8olyx/33ZdQGu1gaMqfY3hAwYmEoGCSZp I3aHWINI0KbDcqck1qbfuUZUtAAqoCVFh9RWBWfQ4TlpiFscQjU9DleEZugkYzaMNzS1 UjP3uRfUO/K1RzSTsAmvYPf1Lt7Otf0BDW8ROwQWCnOxttPIP4N/DRrKcnf/gJ2BvUXU 3jxVUjE181mZQTQUdOn3EFbMY4tAZnp5J4CO92kzt+D+N0nsOONbz9Wb1jv3ajeGh4ud WnDw==
X-Received: by 10.66.89.199 with SMTP id bq7mr15388101pab.26.1359588335766; Wed, 30 Jan 2013 15:25:35 -0800 (PST)
Received: from [192.168.255.224] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.74]) by mx.google.com with ESMTPS id mn4sm2913288pbc.12.2013.01.30.15.25.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jan 2013 15:25:35 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Sam Aldrin <aldrin.ietf@gmail.com>
In-Reply-To: <DC8898F8-75C0-4535-BA61-C54279901332@gmail.com>
Date: Wed, 30 Jan 2013 15:25:32 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <43DF00BE-B5F6-48B9-B313-8D179354C7B7@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> <CAF4+nEFLrJL=CgX9e6on-cgz89ugmu93P6u5kmODhUia3H7RLg@mail.gmail.com> <1F5A81AE-4B3C-45FD-B431-9BA0011EB085@gmail.com> <DC8898F8-75C0-4535-BA61-C54279901332@gmail.com>
To: Jon Hudson <jon.hudson@gmail.com>
X-Mailer: Apple Mail (2.1499)
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 23:25:37 -0000

Here is what I meant.

Deployment scenarios could be  upgrading to FGL RBridges via 1) new device insertion OR 2) replacing older devices with FGL supported RBridges OR 3) the so called upgrade to existing hardware to be FGL safe.
In each of those cases, the way to do it could differ for the reasons highlighted in various emails.
At the end of the day, by moving towards FGL based network, we cannot afford to disrupt existing TRILL network or force to forklift upgrade of non-FGL aware hardware.

Lastly, it would be good to hear from the actual user to understand the pain points in doing one way or the other.

-sam

On Jan 30, 2013, at 12:40 PM, Jon Hudson <jon.hudson@gmail.com> wrote:

> 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