Re: [trill] Explaining three options for upgrading to FGL (fine-grained-labeling)
Ayan Banerjee <ayabaner@gmail.com> Tue, 29 January 2013 19:45 UTC
Return-Path: <ayabaner@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 D9F7721F875C for <trill@ietfa.amsl.com>; Tue, 29 Jan 2013 11:45:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 U3dPLvPcES8F for <trill@ietfa.amsl.com>; Tue, 29 Jan 2013 11:45:03 -0800 (PST)
Received: from mail-vb0-f52.google.com (mail-vb0-f52.google.com [209.85.212.52]) by ietfa.amsl.com (Postfix) with ESMTP id A494121F8722 for <trill@ietf.org>; Tue, 29 Jan 2013 11:45:03 -0800 (PST)
Received: by mail-vb0-f52.google.com with SMTP id fa15so513341vbb.25 for <trill@ietf.org>; Tue, 29 Jan 2013 11:45:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=QdQAE3gJPM+MPL4V55Pgnfz4hZ5N5i1+Tk0NPvtF5MA=; b=oRVX8pTO2AvmrPAgtf/0MIN1VHzwKsmGd0HS7QhoGJVDs2RvWDEcUI1hLbiIzHCp0r ahxFK5JdKDdaDPtFaug/kFeyFG/AdaMm71r04VTXCblzT0/y4p5WbCPIECbaWGINwy57 UW6jKWiEtJB4pOCJvsmnxhKswu93VjuqQi105KBIh71DyFvdF1Jb3Lnbwb9b06aopEHT poeJ5OhWIJlVYO8n6rhidBmJNhhWSOSuQHeBbFX1ytjj4jvmLuaP9ECKPqM26d8Jtze0 uDCcv83D6fOKDC2eyuW+rPC/8fyO+A7tM/R2yyRcTE8zGrsBigRH+ikr9nANEtVUG/d5 MTNQ==
MIME-Version: 1.0
X-Received: by 10.52.66.14 with SMTP id b14mr2170734vdt.0.1359488703070; Tue, 29 Jan 2013 11:45:03 -0800 (PST)
Received: by 10.220.144.78 with HTTP; Tue, 29 Jan 2013 11:45:02 -0800 (PST)
In-Reply-To: <CA+-tSzx0E3J4i5Dvfbj4egruCeGi7z1se1Jn5RXtx3RedQLPdg@mail.gmail.com>
References: <CAFOuuo67iBR2JkDtwPFCkrKHs3Fp4U_L1jkmNz5sfht6y05YMw@mail.gmail.com> <CA+-tSzx0E3J4i5Dvfbj4egruCeGi7z1se1Jn5RXtx3RedQLPdg@mail.gmail.com>
Date: Tue, 29 Jan 2013 11:45:02 -0800
Message-ID: <CAHD03N89RNX4=XxRZpD+Y2PCktYf-FtVjyYJ5oFS3dui3SsXaA@mail.gmail.com>
From: Ayan Banerjee <ayabaner@gmail.com>
To: Anoop Ghanwani <anoop@alumni.duke.edu>
Content-Type: multipart/alternative; boundary="20cf3071c8aa3903ab04d472a115"
Cc: 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: Tue, 29 Jan 2013 19:45:05 -0000
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. 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] 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