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

Ayan Banerjee <ayabaner@gmail.com> Wed, 30 January 2013 00:22 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 8061B21F8626 for <trill@ietfa.amsl.com>; Tue, 29 Jan 2013 16:22:52 -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 PST-TuHsXZ2i for <trill@ietfa.amsl.com>; Tue, 29 Jan 2013 16:22:50 -0800 (PST)
Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id 72AF721F8718 for <trill@ietf.org>; Tue, 29 Jan 2013 16:22:50 -0800 (PST)
Received: by mail-vc0-f171.google.com with SMTP id p1so689992vcq.30 for <trill@ietf.org>; Tue, 29 Jan 2013 16:22:43 -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=RM4X0ZU/FnBWTgXHd/YECTq06oQxGwIbsC1JJ5sFhr0=; b=PyJgGJyIzy8eTPz5t+NvNIx6s3LTs6qEo6+rFO4D2QyfhY3AziljGedNiXZTBvJ+iU cpNfEKsK+DOvFIAjitx1KnJosabGy107wQULZknCy1NOB9LZI5hfRs5N2wB3lRfnCS0U cDf9cpXiWduleEWQUG5MWoRiMcN9XmSspKyn4+wPumDhkIjuEy/eAOeppB5HECDjr7cX V/IHq7E+q5DkY+T9lnFuiDQmbV7xZ8Wr5H5PB4TvowDl119sI00K9G1s55Usoh7t8BoB LNEK1ppeqLJ4zIlLOas2+CWXaA498ec4GnfmUPACcodRIrcSVTR+MFWMvG8Zjlvtmn2M XSUQ==
MIME-Version: 1.0
X-Received: by 10.52.66.14 with SMTP id b14mr2897234vdt.0.1359505362874; Tue, 29 Jan 2013 16:22:42 -0800 (PST)
Received: by 10.220.144.78 with HTTP; Tue, 29 Jan 2013 16:22:42 -0800 (PST)
In-Reply-To: <CAF4+nEEL-FjzKxbxg93t6QTTJy_5uVtok1_RAS1=pR_0B_p1kQ@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> <CAF4+nEEL-FjzKxbxg93t6QTTJy_5uVtok1_RAS1=pR_0B_p1kQ@mail.gmail.com>
Date: Tue, 29 Jan 2013 16:22:42 -0800
Message-ID: <CAHD03N8T5rY4nFT46QX8EQ_KjarbugFNjFcjazk1ZiV4F4AymA@mail.gmail.com>
From: Ayan Banerjee <ayabaner@gmail.com>
To: Donald Eastlake <d3e3e3@gmail.com>
Content-Type: multipart/alternative; boundary=20cf3071c8aa396fdb04d47682b1
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:22:52 -0000

Thanks much Donald. I think that I would vote for approach 2.
Ayan



On Tue, Jan 29, 2013 at 4:14 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:

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