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

Anoop Ghanwani <> Tue, 29 January 2013 14:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B07DE21F86BC for <>; Tue, 29 Jan 2013 06:42:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eclsaE+rps19 for <>; Tue, 29 Jan 2013 06:42:46 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c02::229]) by (Postfix) with ESMTP id 0C21721F866F for <>; Tue, 29 Jan 2013 06:42:45 -0800 (PST)
Received: by with SMTP id j5so661937iaf.28 for <>; Tue, 29 Jan 2013 06:42:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=702hqBayd/Ys2WK/HzeRqmGGfMGv7zaQ9sget92IBwU=; b=YOWxFZ8wxUzbXigzkVSxopEc8Gqk44eJRAF9EoCXq+CojQBn0c3aISBfVJan1rMefm 3iPu32av47nY5zaFN1X/vrto+DUjP7Wo5t+XHEpj0cfECOw7kHbGm9XmgEun8rzL5beP GLQ/f8UkK5hyOc7X3fM7quYYOskHpTAb688mAPsxTJHhBcQAFJWUgBZPmbtejTAOCaTv Q1/X/1l3fmO/IESp9Q5kWJH7refx+Yvey5DKRCQaAZ10YVylyAC6tmFWN/ag60/HjwHl REg0h/8VRQb4Y6gumjCuGk0XHZe8065imoFlMFGujReDX3KXO8FLLluJeHVOnAUIvMXE +zOA==
MIME-Version: 1.0
X-Received: by with SMTP id hr10mr896505igc.21.1359470564407; Tue, 29 Jan 2013 06:42:44 -0800 (PST)
Received: by with HTTP; Tue, 29 Jan 2013 06:42:44 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Tue, 29 Jan 2013 06:42:44 -0800
X-Google-Sender-Auth: jEFRTrJ5cdud41XfphAP73OUdcE
Message-ID: <>
From: Anoop Ghanwani <>
To: Radia Perlman <>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [trill] Explaining three options for upgrading to FGL (fine-grained-labeling)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Jan 2013 14:42:46 -0000

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.


On Fri, Jan 25, 2013 at 11:00 AM, Radia Perlman <> 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) 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's fine to mix FGL-safe RBridges
> with VL'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