Re: [trill] Explaining three options for upgrading to FGL (fine-grained-labeling)
Donald Eastlake <d3e3e3@gmail.com> Wed, 30 January 2013 00:14 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 8E67921F870A for <trill@ietfa.amsl.com>; Tue, 29 Jan 2013 16:14:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.078
X-Spam-Level:
X-Spam-Status: No, score=-103.078 tagged_above=-999 required=5 tests=[AWL=0.521, 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 x7xtlPZNb902 for <trill@ietfa.amsl.com>; Tue, 29 Jan 2013 16:14:49 -0800 (PST)
Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9835021F86F5 for <trill@ietf.org>; Tue, 29 Jan 2013 16:14:49 -0800 (PST)
Received: by mail-ob0-f182.google.com with SMTP id va7so1079996obc.13 for <trill@ietf.org>; Tue, 29 Jan 2013 16:14:49 -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=7FuHnn+yVDAXMMZyxlsJ/qhsBntRoSYgVy9CmeitYlI=; b=IP0eOXa6mEpyP1VlbIFTvN5GaiSmZfSWOAYWc9X9tSYyJg9sL5sLHQi/knKUq/+S9x zd9whZh2ltcHmfaPwDW/gt00tytbkXu2mmIsJKx9TGngNM4vh1nH+RAE6GeHSVpVgFr3 htkrwHbjAGO8FMo52k0+46K8qnsNk7CFyblqg4fpBsrflfqFAT7xGPyCL0L4WY4PO0D9 SCcsGO/awtJ0xFGJ7wX7TZbKsdPfqO6iyCOl7I873HOahoMoMl3+K4axLMa85CkLb9i1 /+Kld3YDnktOv93C0TTzRkvHviWDMNwJGVag/tATae3iPjgvBt3eOY9PflrjzQRCiWr8 iHRA==
X-Received: by 10.60.30.38 with SMTP id p6mr2320722oeh.2.1359504889203; Tue, 29 Jan 2013 16:14:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.76.98.168 with HTTP; Tue, 29 Jan 2013 16:14:28 -0800 (PST)
In-Reply-To: <CAHD03N8HMnMY9p2dm60qCnTfNXL-rawf0hkY0a=cKF_B+jknXA@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> <CAHD03N8HMnMY9p2dm60qCnTfNXL-rawf0hkY0a=cKF_B+jknXA@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Tue, 29 Jan 2013 19:14:28 -0500
Message-ID: <CAF4+nEEL-FjzKxbxg93t6QTTJy_5uVtok1_RAS1=pR_0B_p1kQ@mail.gmail.com>
To: Ayan Banerjee <ayabaner@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: Anoop Ghanwani <anoop@alumni.duke.edu>, Radia Perlman <radiaperlman@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:14:50 -0000
Ayan, Yes, it would probably be good to have a brief informational section describing the intended VL to FGL migration scenario. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Tue, Jan 29, 2013 at 4:15 PM, Ayan Banerjee <ayabaner@gmail.com> wrote: > Donald, > > Yes, realize that would be way to do it - not sure if these options are > being captured in a document, if so it would be great if this also added > there. > > Thanks, > Ayan > > > > On Tue, Jan 29, 2013 at 12:49 PM, Donald Eastlake <d3e3e3@gmail.com> wrote: >> >> Hi Ayan, >> >> On Tue, Jan 29, 2013 at 2:45 PM, Ayan Banerjee <ayabaner@gmail.com> wrote: >> > I agree with Anoop here. >> > >> > I think that we are describing a network that is FGL-safe and ready and >> > then >> > switch to FGL-mode. However, we need some statements to account for a >> > VL-node coming-in/leaving-the network due to a flaky link. >> >> 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. >> >> After you have unleashed FGL traffic, it would certainly be possible >> that a VL switch could be attached to the network or come and go due >> to a flakey link, but this would have almost no effect. With FGL >> traffic being handled, VL switches are isolated. >> >> Thanks, >> Donald >> ============================= >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA >> d3e3e3@gmail.com >> >> > Thanks, >> > Ayan >> > >> > >> > >> > On Tue, Jan 29, 2013 at 6:42 AM, Anoop Ghanwani <anoop@alumni.duke.edu> >> > wrote: >> >> >> >> At noted, option 1 looks dangerous so that should be ruled out. >> >> >> >> Option 2 seems reasonable. It might be useful to clarify a couple of >> >> things: >> >> - Can the FGL-safe campus have both VLAN & FGL frames going around? >> >> - Do all RBridges need to agree on when the campus is FGL-safe? I >> >> would >> >> hope not. But the problem I'm thinking about is where RB1 thinks >> >> the campus is >> >> FGL-safe and starts announcing attachment to FGL links, but RB2 >> >> hadn't >> >> yet >> >> concluded that process and it see RB3 which happens to be VL. >> >> >> >> Option 3 seems to introduce more complexity to solve this problem than >> >> is necessary. >> >> >> >> Anoop >> >> >> >> On Fri, Jan 25, 2013 at 11:00 AM, Radia Perlman >> >> <radiaperlman@gmail.com> >> >> wrote: >> >> > 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 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 >> > > >
- [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