Re: [trill] Explaining three options for upgrading to FGL (fine-grained-labeling)
hu.fangwei@zte.com.cn Wed, 30 January 2013 06:27 UTC
Return-Path: <hu.fangwei@zte.com.cn>
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 64F9F21F84B6; Tue, 29 Jan 2013 22:27:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.395
X-Spam-Level:
X-Spam-Status: No, score=-98.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 waOlhZjP+urm; Tue, 29 Jan 2013 22:27:28 -0800 (PST)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id E1CCE21F84A1; Tue, 29 Jan 2013 22:27:27 -0800 (PST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 78F691245691; Wed, 30 Jan 2013 14:28:19 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r0U6R3Ag048006; Wed, 30 Jan 2013 14:27:03 +0800 (GMT-8) (envelope-from hu.fangwei@zte.com.cn)
In-Reply-To: <CAFOuuo67iBR2JkDtwPFCkrKHs3Fp4U_L1jkmNz5sfht6y05YMw@mail.gmail.com>
To: Radia Perlman <radiaperlman@gmail.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004
Message-ID: <OF7D4AED17.C9650586-ON48257B03.0022E885-48257B03.00237369@zte.com.cn>
From: hu.fangwei@zte.com.cn
Date: Wed, 30 Jan 2013 14:27:01 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-01-30 14:26:59, Serialize complete at 2013-01-30 14:26:59
Content-Type: multipart/alternative; boundary="=_alternative 0023736548257B03_="
X-MAIL: mse02.zte.com.cn r0U6R3Ag048006
Cc: trill-bounces@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 06:27:29 -0000
Support option 2 It provides a smooth migration process by a simple software upgrade from VL node to FGL-Safe node. Radia Perlman <radiaperlman@gmail.com> 发件人: trill-bounces@ietf.org 2013-01-26 03:00 收件人 trill@ietf.org 抄送 主题 [trill] Explaining three options for upgrading to FGL (fine-grained-labeling) I'm going to summarize three options for phasing-in FGL, and explain the tradeoffs, to help people have informed opinions about the implications of the three approaches. There are infinite variations, of course, but as I said, I'll describe three main ones. Option 1: Original draft, no changes. There are two types of RBridges. The first type is "VL" which only understands VLAN tags, and have unknown and possibly dangerous behavior when they receive an FGL-labeled packet. (e.g., decapsulate a packet onto a link where it is not allowed, or mistakenly prune a multicast so it does not reach everywhere it should). The second type is "FGL". FGL guys need to do two things: 1) understand FGL tags and do the right thing with them, and 2) ostrasize VL guys...meaning that an FGL guy refuses to form an adjacency with a VL guy. This option is very simple for implementers of FGL, but the implication is that you have to upgrade your entire campus to FGL at once. There is no coexistence. Option 2: Two types of RBridges, but the 2nd type is different from option 1. VL guys of course are the same as in option 1...they cannot be trusted with FGL frames. The second type I will call "FGL-safe". An FGL-safe RBridge must advertise in its LSP that it is FGL-safe, and it must not "do anything bad" with FGL frames, meaning that it is allowed to ignore pruning of FGL (or even VL frames) entirely...it just can't falsely drop FGL frames. And it must not decapsulate an FGL frame onto a link for which that FGL frame doesn't belong. In this option, all RBridges must be upgraded to FGL-safe, but it need not happen instantaneously...it's fine to mix FGL-safe RBridges with VL RBridges...it's just not safe to inject FGL frames yet. Once all the RBridges have been upgraded to be FGL-safe, then edge RBridges can start announcing they are connected to an FGL link, and can start injecting FGL packets. It is considered a misconfiguration if you start injecting FGL frames before all the RBridges are upgraded to FGL-safe, so an additional chore for an FGL-safe RBridge R1 is to examine LSPs, and if any RBridge claims to be attached to an FGL link, then R1 must ostrasize any VL neighbors. (don't start ostrasizing VL guys until it is necessary because of actually starting to use FGL frames, in other words). This option is more work for the upgraded RBridges than option 1, and there still isn't good coexistence with VL guys long-term (as option 3 will), but it does allow upgrading RBridges one by one in a working campus without causing disruption. Option 3: Two types of RBridges. VL, of course, is the same as in options 1 and 2. This option makes FGL guys do more work, but allows maximal long term coexistence of VL and FGL guys. In this option, FGL guys calculate unicast paths to FGL edge guys that avoid any VL guys, and calculate at least one FGL-friendly multicast tree that also avoids any VL guys. So let's say R1 is an FGL guy. R1 discards all LSPs from VL guys (ones that don't advertise FGL capability in their LSP), when calculating paths to other FGL RBridges. Then R1 calculates paths to the VL guys using all LSPs. Likewise, when calculating an FGL-friendly tree, R1 calculates a tree through only FGL guys. This option is more work for the upgraded RBridges (because they have to calculate Dijkstra in two different ways, one for reaching VL guys, and one for reaching FGL guys). However, it does allow having long-term coexistence with VL guys. For instance, you could forever keep some VL edge RBridges that communicate just fine through an FGL core. They can stay there forever, and still be able to communicate through the core to all the links attaching to their VLAN. _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill
- [trill] Explaining three options for upgrading to… Radia Perlman
- [trill] 答复: Explaining three options for upgradin… Haoweiguo
- Re: [trill] 答复: Explaining three options for upgr… Radia Perlman
- [trill] 答复: 答复: Explaining three options for upgr… Haoweiguo
- Re: [trill] Explaining three options for upgradin… Anoop Ghanwani
- Re: [trill] Explaining three options for upgradin… Donald Eastlake
- Re: [trill] 答复: 答复: Explaining three options for … Donald Eastlake
- Re: [trill] Explaining three options for upgradin… Ayan Banerjee
- Re: [trill] Explaining three options for upgradin… Donald Eastlake
- Re: [trill] Explaining three options for upgradin… Ayan Banerjee
- Re: [trill] Explaining three options for upgradin… Anoop Ghanwani
- Re: [trill] Explaining three options for upgradin… Donald Eastlake
- Re: [trill] Explaining three options for upgradin… Ayan Banerjee
- Re: [trill] Explaining three options for upgradin… Donald Eastlake
- [trill] 答复: 答复: 答复: Explaining three options for … Haoweiguo
- Re: [trill] Explaining three options for upgradin… Yizhou Li
- Re: [trill] Explaining three options for upgradin… Tal Mizrahi
- Re: [trill] Explaining three options for upgradin… hu.fangwei
- Re: [trill] Explaining three options for upgradin… zhai.hongjun
- Re: [trill] Explaining three options for upgradin… Sam Aldrin
- Re: [trill] Explaining three options for upgradin… Linda Dunbar
- Re: [trill] Explaining three options for upgradin… Jon Hudson
- Re: [trill] Explaining three options for upgradin… Sam Aldrin
- Re: [trill] Explaining three options for upgradin… Jon Hudson
- Re: [trill] Explaining three options for upgradin… Sam Aldrin
- Re: [trill] Explaining three options for upgradin… Tissa Senevirathne (tsenevir)
- Re: [trill] Explaining three options for upgradin… Radia Perlman
- Re: [trill] Explaining three options for upgradin… Olen Stokes
- Re: [trill] Explaining three options for upgradin… Radia Perlman
- [trill] 答复: Explaining three options for upgradin… Haoweiguo
- Re: [trill] 答复: Explaining three options for upgr… Radia Perlman
- [trill] 答复: 答复: Explaining three options for upgr… Haoweiguo
- Re: [trill] Explaining three options for upgradin… Jon Hudson