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

Donald Eastlake <d3e3e3@gmail.com> Tue, 29 January 2013 16:38 UTC

Return-Path: <d3e3e3@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 B57A821F88A6 for <trill@ietfa.amsl.com>; Tue, 29 Jan 2013 08:38:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.951
X-Spam-Level:
X-Spam-Status: No, score=-99.951 tagged_above=-999 required=5 tests=[AWL=-3.647, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
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 tmk3c9mHkA-3 for <trill@ietfa.amsl.com>; Tue, 29 Jan 2013 08:38:39 -0800 (PST)
Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) by ietfa.amsl.com (Postfix) with ESMTP id CC43421F88A9 for <trill@ietf.org>; Tue, 29 Jan 2013 08:38:38 -0800 (PST)
Received: by mail-ob0-f178.google.com with SMTP id wd20so609646obb.23 for <trill@ietf.org>; Tue, 29 Jan 2013 08:38:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=nxVGEVx/FGQomFlCBsx9gS5TyXxPrKb176smSnVdOi0=; b=MsYeG9CHqggJwog7LlVEK2CGVudks8S5XKOVucIQ9en7PgJayR55Q+/6MYNtHcs9C9 ilSGdGrHVrhYteGEwDGKE4Tth5r09tDb6RZsn7ORwiMcjxXdRyC3a5HqYB4esaenJAcE VGH4lcNqczMM0BkLyFxpwFcxdSOOHR2/wDJhwlg7K54bP664u1/l5gHimCwfqzJ4xZ7c dtjXrIl7d+V3PIsr1bgP9HU1ATzf4J8MepUtlDxVOAdMKgw8LB3S9+HTYnfbXnRkJbO5 PQLXEbhmhGn+JsErDK6S7CGxwWjy7Cq3YKtgo0KXW8+NsUTnApIpBO4TAo6rytmG1WXT Aamw==
X-Received: by 10.182.40.3 with SMTP id t3mr1183032obk.56.1359477518350; Tue, 29 Jan 2013 08:38:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.76.98.168 with HTTP; Tue, 29 Jan 2013 08:38:17 -0800 (PST)
In-Reply-To: <DD5FC8DE455C3348B94340C0AB5517334F6514AD@nkgeml501-mbs.china.huawei.com>
References: <CAFOuuo67iBR2JkDtwPFCkrKHs3Fp4U_L1jkmNz5sfht6y05YMw@mail.gmail.com> <DD5FC8DE455C3348B94340C0AB5517334F651415@nkgeml501-mbs.china.huawei.com> <CAFOuuo597npOuDLT1di-0V+Q1Fh7nYvKD3jHG3bbZPB81hc=Tw@mail.gmail.com> <DD5FC8DE455C3348B94340C0AB5517334F6514AD@nkgeml501-mbs.china.huawei.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Tue, 29 Jan 2013 11:38:17 -0500
Message-ID: <CAF4+nEHR9SadJoAFXGqD-s_=K-js4Z3E7ONsLWxBSHjPMN+hzQ@mail.gmail.com>
To: Haoweiguo <haoweiguo@huawei.com>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable
Cc: Radia Perlman <radiaperlman@gmail.com>, "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] =?gb2312?b?tPC4tDogtPC4tDogRXhwbGFpbmluZyB0aHJlZSBvcHRp?= =?gb2312?b?b25zIGZvciB1cGdyYWRpbmcgdG8gRkdMIChmaW5lLWdyYWluZWQt?= =?gb2312?b?bGFiZWxpbmcp?=
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 16:38:39 -0000

Hi Weiguo,

On Tue, Jan 29, 2013 at 8:23 AM, Haoweiguo <haoweiguo@huawei.com>
wrote:
> Hi Radia,
>
> For unicast, I think TRILL switch don't care about inner VLAN or FGL
> and they forward the unicast data frame just by egress nickname. So
> I think VL switch can support unicast FGL data frame forwarding and
> have no problem.

It is true that the case for unicast is better than the case for
multi-destination. But a VL TRILL switch might (a) drop an FGL frame
as malformed because it does not have 0x8100 after the inner MAC
addresses or (b) do incorrect flow classification for ECMP, resulting
in persistent re-ordering, because it is trying to look deeper into
the frame past the data label and gets confused by an FGL. If it does
either (a) or (b) it is not FGL-safe (although (b) is not as bad as
(a)) and you have to route FGL frames around such VL switches.

> For multicast, VL switch can't perform distribution tree pruning by
> FGL and VL switch has following possible behaviors:
>
> 1,VL switch drops FGL multicast data frame because VL switch cares
> about inner ethtype. The VL switch only support inner ethtype of
> 0x8100.

If it does this, it is not FGL-safe and you have to route FGL traffic
around VL switches.

> 2,VL switch don't implement VLAN pruning and forward multicast data
> frame by broadcast distribution tree. The forwarding key of the
> broadcast distribution tree is nickname of DST root. The VL switch
> don't care about inner VLAN or FGL also Multicast FGL data frame can
> be forwarded by this kind of VL switch.

As far as I know, all TRILL products with silicon fast path support do
implement pruning.

> 3,VL switch implements VLAN pruning and forward multicast data frame
> by VLAN pruning tree. The forwarding key of the pruning tree is root
> nickname+inner VLAN.  If the switch cares about accurate inner
> ethtype(0x8100), FGL data frame will be dropped. If the switch
> allows random or multiple ethtype, then FGL data frame can be
> forwarded higher 12 bit of FGL.

If the VL switch drops frames without the 0x8100, they it is not
FGL-safe and you have to steer FGL traffic around VL switches. If the
VL switch pruning is based on believing that the top 12 bits of the
FGL are a VLAN ID, it will prune incorrect and will not be FGL-safe,
so you have to route FGL traffic around such a VL switch.

And then there is a fourth behavior:

4, VL switch ignores the Ethertype and uses the top 12 bits of the FGL
as a VLAN ID. As a result, it egresses multi-destination frames out
wrong ports in the wrong VLAN and violates security considerations.
This may be the worst of the possible behaviors. Since you cannot tell
if a VL TRILL switch might do this, you cannot trust VL switches to
properly handle FGL traffic.

However, as far as I know, existing silicon based VL TRILL switches
can be upgraded with software changes to be FGL-safe.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

> thanks
>
> weiguo
>
> ________________________________
>
> 发件人: Radia Perlman [radiaperlman@gmail.com]
> 发送时间: 2013年1月29日 18:59
> 到: Haoweiguo
> Cc: trill@ietf.org
> 主题: Re: 答复: [trill] Explaining three options for upgrading to FGL
> (fine-grained-labeling)
>
> Hi Weiguo,
>
>  If we knew that it was already safe to transit FGL frames through VL nodes,
> that would be great.  We could basically just start sending FGL frames, not
> worry about ostrasizing VL RBridges, not worry about calculating two
> forwarding databases.
>
>  But,  I was assuming that there were implementations of VL that might do
> bad things if they saw an FGL packet.  For instance, for unicast, they might
> drop the packet, or they might decapsulate it onto a link that should not
> receive packets for that FGL.  For multicast, they might falsely filter the
> packet.  If that assumption is true, then the safe thing is to avoid VL
> RBridges for FGL packets, which means calculating paths that do not include
> VL RBridges.
> .
> Thanks,
>
> Radia
>
>
>
> On Mon, Jan 28, 2013 at 10:59 PM, Haoweiguo <haoweiguo@huawei.com> wrote:
>>
>> Hi Radia,
>>
>> In option3:
>>
>> why FGL switches 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? If two FGL switches can only transmit data through VL
>> switch, the method will disconnect data channel between FGL switches. I
>> think VL switch is safe as transit node to tranmit unicast FGL data packet.
>>
>> thanks
>>
>> weiguo
>>
>> ________________________________
>>
>> 发件人: Radia Perlman [radiaperlman@gmail.com]
>> 发送时间: 2013年1月26日 3:00
>> 到: trill@ietf.org
>> 主题: [trill] Explaining three options for upgrading to FGL
>> (fine-grained-labeling)
>>
>> 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.