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

Yizhou Li <liyizhou@huawei.com> Wed, 30 January 2013 04:25 UTC

Return-Path: <liyizhou@huawei.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 D324021F8967 for <trill@ietfa.amsl.com>; Tue, 29 Jan 2013 20:25:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 6E-GG0t6SSAw for <trill@ietfa.amsl.com>; Tue, 29 Jan 2013 20:25:47 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF8521F856D for <trill@ietf.org>; Tue, 29 Jan 2013 20:25:45 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANZ44372; Wed, 30 Jan 2013 04:25:44 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 30 Jan 2013 04:25:07 +0000
Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 30 Jan 2013 04:25:43 +0000
Received: from l63746 (10.138.122.43) by smtpscn.huawei.com (10.82.67.152) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 30 Jan 2013 12:25:35 +0800
From: Yizhou Li <liyizhou@huawei.com>
To: "'Anoop Ghanwani'" <anoop@alumni.duke.edu>, "'Donald Eastlake'" <d3e3e3@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>
In-Reply-To: <CA+-tSzz0=oh6iB1e-ESyeOx2sCvBFXeVpzuNbKmUVhRNLScDgQ@mail.gmail.com>
Date: Wed, 30 Jan 2013 12:25:35 +0800
Message-ID: <049401cdfea1$d9ab3bc0$8d01b340$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac3+fTnvU4O4WzT2SZO/1Z2uBQcFswAIdlxg
Content-Language: zh-cn
X-Originating-IP: [10.138.122.43]
X-CFilter-Loop: Reflected
Cc: 'Radia Perlman' <radiaperlman@gmail.com>, 'Ayan Banerjee' <ayabaner@gmail.com>, 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 04:25:47 -0000

With option 2, once RB starts to injecting FGL frame, isolated pure VL RB
will no longer able to exchange VL-tagged frame with FGL-safe RB and vice
versa. Such scenario may be caused by mis-configuration, flaky link, newly
connected cable, etc. Option 3 gives better handlings for such corner cases.
However comparing the complexity, I would still vote for option 2. The most
possible smooth migration path would be gradually replacing VL RB with FGL
safe RB. 
I think the administrator should roughly know the overall equipments
distribution and be responsible to decide when is the right time to actually
enable the injecting of FGL frame. 

Yizhou


-----Original Message-----
From: trill-bounces@ietf.org [mailto:trill-bounces@ietf.org] On Behalf Of
Anoop Ghanwani
Sent: Wednesday, January 30, 2013 8:03 AM
To: Donald Eastlake
Cc: Radia Perlman; Ayan Banerjee; trill@ietf.org
Subject: Re: [trill] Explaining three options for upgrading to FGL
(fine-grained-labeling)

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

Anoop
_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill