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

Radia Perlman <> Fri, 01 February 2013 10:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D754F21F8826 for <>; Fri, 1 Feb 2013 02:45:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.949
X-Spam-Level: *
X-Spam-Status: No, score=1.949 tagged_above=-999 required=5 tests=[AWL=-3.947, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001, SARE_SUB_ENC_GB2312=1.345]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pNlIFC8Knm0n for <>; Fri, 1 Feb 2013 02:45:38 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c03::233]) by (Postfix) with ESMTP id 09E8921F881E for <>; Fri, 1 Feb 2013 02:45:31 -0800 (PST)
Received: by with SMTP id fo13so2702934lab.38 for <>; Fri, 01 Feb 2013 02:45:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jTv2qT3OF7sycH+5NpPATjSTmk0ZLSHdVPwuy2ZSRYo=; b=jIVcVAxvVOEP5JMu/+bblBt0fvevRX/Ovv2PkTN5oZZeTqS22yPdeOA7UrKtb7mO2N 6JPeXS3JMJW/TVHz2FJNDLeIoj3gp/GLLu+noBwqdJNwBSkl9yE229fFUY2VnVdGywgO lPTSw4ehWOjvBb7Q850aGtAnwVwuwg82nxga7BM4rTSydw01/263qtB0YEqQV/dDGVry Y3LrcIqPiTymTxPLb6nWd1yjRPJsn3eCqD3NfO8OwkeaFYwGTcbIcQxDXZZFPA5Q2IEy LGXy4RhhaJlSB528XSqjZqyMTe/MDn3GNCfD5J24J9QBPOz/63wSs4KOucPbmtLFDYUF NDWw==
MIME-Version: 1.0
X-Received: by with SMTP id lx2mr10735956lab.52.1359715530865; Fri, 01 Feb 2013 02:45:30 -0800 (PST)
Received: by with HTTP; Fri, 1 Feb 2013 02:45:30 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Fri, 1 Feb 2013 02:45:30 -0800
Message-ID: <>
From: Radia Perlman <>
To: Haoweiguo <>
Content-Type: multipart/alternative; boundary=f46d0434bfea367c2804d4a77181
Cc: Anoop Ghanwani <>, Ayan Banerjee <>, Sam Aldrin <>, Donald Eastlake <>, "" <>, "Tissa Senevirathne \(tsenevir\)" <>, Jon Hudson <>
Subject: Re: [trill] =?gb2312?b?tPC4tDogIEV4cGxhaW5pbmcgdGhyZWUgb3B0aW9ucyBm?= =?gb2312?b?b3IgdXBncmFkaW5nIHRvIEZHTCAoZmluZS1ncmFpbmVkLWxhYmVs?= =?gb2312?b?aW5nKQ==?=
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: Fri, 01 Feb 2013 10:45:40 -0000

I think you were just misinterpreting what I wrote.  It is OK to let things
through that could be pruned.  It is *not* OK to falsely delete things.
The example I gave of interpreting the first FGL label as a VL label is
something that the RBridge MUST NOT do.

So we're not disagreeing.


On Fri, Feb 1, 2013 at 1:11 AM, Haoweiguo <> wrote:

>  Hi Radia,
> I agree with your definition of "Safe FGL",but I have a problem about the
> following point:
> b) multicast pruning: it's OK not to do pruning at all, or to actually
> look at all 24 bits of the FGL and prune as a proper FGL guy would do.  But
> an example of what you canNOT do is look at the first 12 bits of FGL,
> pretend it's the same as VL, and delete the multicast packet because nobody
> downstream is listening to that 12 bit VL value
> [weiguo]:If a switch performs pruning by first 12 bits of FGL, can the
> switch called "Safe FGL" switch? If downstream have one VL switch with VLAN
> is equal to first 12 bits of FGL,then the switch will forward multicast
> data frame to downstream VL switch.
> thanks
> weiguo
>  ------------------------------
> *发件人:* Radia Perlman []
> *发送时间:* 2013年2月1日 4:24
> *到:* Tissa Senevirathne (tsenevir)
> *Cc:* Anoop Ghanwani; Ayan Banerjee; Sam Aldrin;; Donald
> Eastlake; Jon Hudson
> *主题:* Re: [trill] Explaining three options for upgrading to FGL
> (fine-grained-labeling)
>   Tissa said:
> >> how can you make sure all of the so called "Safe FGL" have consistent
> behavior
> "Safe FGL" need not all have the *same* behavior as each other...they
> just have to do "nothing bad" with an FGL frame.  It's worth summarizing
> (again) what it means to be "FGL-safe", which allows you to coexist safely
> with FGL frames.  To be FGL-safe you must do the following:
> a) unicast: you MUST NOT drop a packet because of seeing the unrecognized
> FGL tag.  You also MUST NOT get confused and do flow hashing improperly
> (choosing different paths for packets for the same flow).
> b) multicast pruning: it's OK not to do pruning at all, or to actually
> look at all 24 bits of the FGL and prune as a proper FGL guy would do.  But
> an example of what you canNOT do is look at the first 12 bits of FGL,
> pretend it's the same as VL, and delete the multicast packet because nobody
> downstream is listening to that 12 bit VL value
> c) egress of either unicast or multicast:  you MUST NOT egress an FGL
> frame onto a link that is not supposed to get that FGL value
> d) you have to advertise that you are FGL-safe...otherwise other RBs will
> assume you are VL ("FGL-unsafe")
> ---------
> Also, TIssa said:
> >>Do you agree if we say, FGL will always be core of the network, and VL
> will be at the edge of the network ?
> With option 2, a VL guy *cannot even be at the edge of a network with FGL
> links* unless it is upgraded to FGL-safe AND advertises that it is
> FGL-safe.  Option 2 says a VL guy is completely ostrasized once FGL-labeled
> links are introduced.  There is NO coexistence of VL guys and FGL-links.
> The only kinds of coexistence in option 2 are:
> a) VL and FGL-safe RBridge, but no actual FGL links yet.
> b) FGL-safe guys, even if some of them don't really understand FGL, but
> just don't do "anything bad" with it, and FGL frames.
> So...again...the migration phases in option 2 are
> 1) VL-only (today's deployment), then
> 2) A mixture of VL and FGL-safe, until
> 3) EVERYone upgraded to FGL-safe, then
> 4) FGL-links can be introduced.
> ----
> Also, Tissa said:
> >>what about some devices who are not "safe FGL" and so on, are we saying
> do not buy no safe FGL devices, if you do that you cannot get FGL interop ?
> *If* it's important to have VL guys as transit, and they cannot be
> upgraded to FGL-safe because upgrading requires a hardware change (it
> involves parsing data packets), then we are stuck with option 3.  In option
> 3, we can forever have VL guys at the edge speaking through an FGL-safe or
> full-FGL core.  In option 2, as I said, there is *no coexistence* of VL
> guys, *even at the edg*e, once FGL links are introduced.  In option 2, a
> VL guy, even at the edge, will be ostrasized completely once anyone
> advertises connectivity to an FGL link.
> I personally like option 2, because it's simple, but as Einstein said
> "make things as simple as possible, but no simpler".  We have to make sure
> that everyone understands the implications of option 2, and can live with
> them.  To summarize again (since there seems to be some confusion about
> what the implications of option 2 are),
> If we can upgrade all existing VL implementations to FGL-safe through
> software upgrade only, then option 2 provides smooth migration by changing
> ALL RBridges (edge as well as transit) to FGL-safe, and only after ALL of
> them are upgraded, then FGL-labeled links can be introduced.  If there are
> any remaining VL guys once FGL-labeled links are introduced, the VL guys
> are ostrasized, *even if they are just at the edge.*
> If we canNOT upgrade all existing VL to FGL-safe, AND if it's important to
> be able to mix VL guys into a network with FGL frames (say, having VL guys
> at the edge), then option 3 allows this.
> So hopefully everyone understands the implications of option 2 fully
> before voting.  As I said, I don't know about whether there are VL chips
> that would require a hardware upgrade to become FGL-safe.  Assuming there
> are none, then I'm quite happy with option 2.   And actually, it looks like
> people are converging on option 2 (though I hope it's based on fully
> understanding option 2).  Now is the time for people to speak up, that know
> of problems this would cause...for instance, needing to have non-upgradable
> VL guys at the edge for a long time.
> Radia