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

Radia Perlman <radiaperlman@gmail.com> Fri, 01 February 2013 10:45 UTC

Return-Path: <radiaperlman@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 D754F21F8826 for <trill@ietfa.amsl.com>; Fri, 1 Feb 2013 02:45:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNlIFC8Knm0n for <trill@ietfa.amsl.com>; Fri, 1 Feb 2013 02:45:38 -0800 (PST)
Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 09E8921F881E for <trill@ietf.org>; Fri, 1 Feb 2013 02:45:31 -0800 (PST)
Received: by mail-la0-f51.google.com with SMTP id fo13so2702934lab.38 for <trill@ietf.org>; Fri, 01 Feb 2013 02:45:31 -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=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 10.152.123.34 with SMTP id lx2mr10735956lab.52.1359715530865; Fri, 01 Feb 2013 02:45:30 -0800 (PST)
Received: by 10.112.64.17 with HTTP; Fri, 1 Feb 2013 02:45:30 -0800 (PST)
In-Reply-To: <DD5FC8DE455C3348B94340C0AB5517334F65191F@nkgeml501-mbs.china.huawei.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> <CA+-tSzz0=oh6iB1e-ESyeOx2sCvBFXeVpzuNbKmUVhRNLScDgQ@mail.gmail.com> <CAF4+nEFLrJL=CgX9e6on-cgz89ugmu93P6u5kmODhUia3H7RLg@mail.gmail.com> <1F5A81AE-4B3C-45FD-B431-9BA0011EB085@gmail.com> <DC8898F8-75C0-4535-BA61-C54279901332@gmail.com> <43DF00BE-B5F6-48B9-B313-8D179354C7B7@gmail.com> <A9B8F2D5-C3D7-4688-A76D-ED19EC47E59F@gmail.com> <FBEA3E19AA24F847BA3AE74E2FE19356288F6978@xmb-rcd-x08.cisco.com> <CAFOuuo4jZMdvUU_2EzBj1MLp6k0e+AmW1+k1ai4Q_m4rA0ObMw@mail.gmail.com> <DD5FC8DE455C3348B94340C0AB5517334F65191F@nkgeml501-mbs.china.huawei.com>
Date: Fri, 1 Feb 2013 02:45:30 -0800
Message-ID: <CAFOuuo6=7OtsDW0UjRkhHpEaCaDs2n55Z7Au2Y_bY7nvDzkM5w@mail.gmail.com>
From: Radia Perlman <radiaperlman@gmail.com>
To: Haoweiguo <haoweiguo@huawei.com>
Content-Type: multipart/alternative; boundary=f46d0434bfea367c2804d4a77181
Cc: Anoop Ghanwani <anoop@alumni.duke.edu>, Ayan Banerjee <ayabaner@gmail.com>, Sam Aldrin <aldrin.ietf@gmail.com>, Donald Eastlake <d3e3e3@gmail.com>, "trill@ietf.org" <trill@ietf.org>, "Tissa Senevirathne \(tsenevir\)" <tsenevir@cisco.com>, Jon Hudson <jon.hudson@gmail.com>
Subject: Re: [trill] =?gb2312?b?tPC4tDogIEV4cGxhaW5pbmcgdGhyZWUgb3B0aW9ucyBm?= =?gb2312?b?b3IgdXBncmFkaW5nIHRvIEZHTCAoZmluZS1ncmFpbmVkLWxhYmVs?= =?gb2312?b?aW5nKQ==?=
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: 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.

Radia

On Fri, Feb 1, 2013 at 1:11 AM, Haoweiguo <haoweiguo@huawei.com> 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 [radiaperlman@gmail.com]
> *发送时间:* 2013年2月1日 4:24
>
> *到:* Tissa Senevirathne (tsenevir)
> *Cc:* Anoop Ghanwani; Ayan Banerjee; Sam Aldrin; trill@ietf.org; 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
>
>
>