Re: [trill] RBridge Channel versus ESADI for MAC address flush

Donald Eastlake <d3e3e3@gmail.com> Thu, 18 February 2016 04:04 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A721B3415 for <trill@ietfa.amsl.com>; Wed, 17 Feb 2016 20:04:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.15
X-Spam-Level:
X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, J_CHICKENPOX_55=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8r7_rHnLtFW for <trill@ietfa.amsl.com>; Wed, 17 Feb 2016 20:04:54 -0800 (PST)
Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9831C1B341E for <trill@ietf.org>; Wed, 17 Feb 2016 20:04:47 -0800 (PST)
Received: by mail-ob0-x235.google.com with SMTP id gc3so47670399obb.3 for <trill@ietf.org>; Wed, 17 Feb 2016 20:04:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=hEqblzhbXtHNwCHkIxF5gP2BmeMsoSYLm9a5KRKnv74=; b=UvqpCObiXRYOhz33/L4a+P1enq8CH4+B6bF2XBdf0BoZ92EvxOtq1NEdSfZpasY+6k HdLIv/woogoxaicIX8en+PZ07WwihQxTtO4++ZCmaKDE2diC0w4OePcV23U5OLSJiw+M bhw84eOEi1lwrgLvdqY8EiTzPnq3sj/XZ3E9r6jm8EMCyDHM1alTrarVJTulhpRBzj7I tZOVWKxW0FU5IhOVZ+kvf0IR9MnZ6SDBzFWmI8jJSD1nOHSPhftmt3pMhQOyz0/1lQxF zsUUGs1gDAKunwBYYNjerrGRGvyxW1n6adjBVGMKPFUOODvGJJ9RINxAxv8ptWL8sEmm Rorg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=hEqblzhbXtHNwCHkIxF5gP2BmeMsoSYLm9a5KRKnv74=; b=GDt8fgb8ngkLEvSqInIryhLxiL7Kexj2bwGjMP6I3bX8XYT6p75VOOlY1VZu0+1ySO 0khc5bdEF1mipj45DRZac00SlBANeTaXYtgzzCvMgKIaFKBjbgu1c4gQvPUjFMGnQwS4 AmzbAOhY4ZLd7JpZawlgn5zjO0IpaMbpjotl4cc+QnoVZAOrJ/9vWzICfB/z/echef7o hy99l8V7duhWhd6WdaLSmzNciW00yNxeSjTiY346DG79t0O0+NyqKz3d8JTbpz/MFa4u 6CQOnIzpccmHX3WxU3tmKMDuWWbDe4R+7oS8msG2p0wKeZ28ZCNMMwi7nWXgiM7C6HwZ C29A==
X-Gm-Message-State: AG10YOTyV/bXvSLyWXkDuxGKIYbbhG1IXs8zqDCZZUnj2H21xIEuMdNTgy4ZOkYM5+cm0Sz/AFhHhK+pQ+l/WQ==
X-Received: by 10.182.103.167 with SMTP id fx7mr4358579obb.36.1455768287067; Wed, 17 Feb 2016 20:04:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.76.157.161 with HTTP; Wed, 17 Feb 2016 20:04:32 -0800 (PST)
In-Reply-To: <4552F0907735844E9204A62BBDD325E787C563A4@NKGEML515-MBX.china.huawei.com>
References: <CAF4+nEFxdn-EA27y6y+ist9vFpbWh6h9JAkRLFSjyW5kf8QJpQ@mail.gmail.com> <DD5FC8DE455C3348B94340C0AB551733502932AD@nkgeml513-mbx.china.huawei.com> <CAF4+nEEToy_PMPXVcw07dhchAMNns4V+Y9eCrmcveGndesm7JQ@mail.gmail.com> <4552F0907735844E9204A62BBDD325E787C563A4@NKGEML515-MBX.china.huawei.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Wed, 17 Feb 2016 23:04:32 -0500
Message-ID: <CAF4+nEEmMdWSti-7nDQh2an7TePAOHgWDKK2L4xsZUj-Dt6mZQ@mail.gmail.com>
To: Mingui Zhang <zhangmingui@huawei.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/trill/Q9DLC8bJQsgtbSeXa1HKgaXL1CY>
Cc: "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] RBridge Channel versus ESADI for MAC address flush
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 18 Feb 2016 04:04:56 -0000

Hi Mingui,

On Tue, Feb 16, 2016 at 2:22 AM, Mingui Zhang <zhangmingui@huawei.com> wrote:
> Hi Donald,
>
> Thanks for the explanation of the subtle reason why an RBridge Channel is needed for MAC flush. Please find my comments in-line.
>
>> -----Original Message-----
>> From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Donald Eastlake
>> Sent: Monday, February 15, 2016 12:26 PM
>> To: trill@ietf.org
>> Subject: Re: [trill] RBridge Channel versus ESADI for MAC address flush
>>
>> These are my thoughts on this question:
>>
>> The goal of the MAC address flush facility is to be able to clear MAC addresses
>> that have been learned from the data plane.
>>
>> For example, if an edge RBridge RB1 knows that an end station with MAC
>> address ES1 in VLAN V1 is no longer attached to any of its ports, it would want
>> to clear any learning in the TRILL campus that associates
>> ES1&V1 with RB1.
>>
>> Another case would be if RB2 has a port to a link with a bunch of end stations in
>> V1 but RB2 losses appointed forwarder for V1 on that port.
>> RB2 would then want to clear all learning at other RBridges in the campus
>> associating any of the MAC addresses out that port with RB2.
>> (This is actually only useful if RB2 is still appointed forwarder for
>> V1 out some other port. If RB2 were no longer appointed forwarder for
>> V1 for any port, then RB2 would use the core IS-IS instance to withdraw the
>> Interested VLANs sub-TLV by which RB2 declared interest in V1. All the other
>> RBridges in the campus can see this withdrawal and would know to clear any
>> V1 MAC address learning for RB2, as specified in RFC 6325 Section 4.8.3, next
>> to last paragraph on page
>> 70.)
>>
>> ESADI uses a mechanism patterned after the IS-IS reliable link state flooding
>> mechanism. The ESADI idea is that, if RB3 is using ESADI for V1, RB3 advertises
>> all the locally attached MAC addresses RB3 has learned about (through the
>> receipt of native frames or whatever) in V1 through ESADI. All other RBridges in
>> the campus that are participating in ESADI will reliably learn that those MAC
>> addresses are associated with RB3 if those other RBridges are participating in
>> ESADI for V1.
>> RB3 can easily and reliably withdraw one, several, or all of these MAC
>> addresses by sending updated link state information through the ESADI
>> instance using the already existing ESADI mechanisms.
>>
>> The current proposal is to use an RBridge Channel message to clear out MAC
>> addresses learned from the data plane.
>>
>> RBridge Channel messages and ESADI messages have a number of similarities.
>> Both use packets structured as TRILL Data packets with an Inner.MacDA of
>> All-Egress-RBridges (this MAC address was formerly called All-ESADI-RBridges).
>> The use of this MAC address as the Inner.MacDA assures that the packets will
>> not be forwarded to an end station. The difference is that after the inner MAC
>> addresses, an ESADI packet has the L2-IS-IS Ethertype and the rest of the
>> frame is structured as an IS-IS PDU, while an RBridge Channel packet has the
>> RBridge-Channel Ethertype and the rest of the frame is structured as specified
>> in RFC 7178 to provide a general extensible format for typed messages
>> between RBridges. (There is also a way to send RBridge Channel messages,
>> called “native RBridge Channel messages”, to end stations but that is not
>> what would be used here.)
>>
>> To me, it does not make sense to try to figure out how to somehow encode a
>> message to clear data plane learning into ESADI. In fact, RBridges that are not
>> participating in ESADI will discard ESADI messages. But if an RBridge is
>> participating in ESADI for VLAN V1 for example, then very likely it will disable
>> data plane learning for V1,
>
> Here, I am thinking about the granularity of "disabling data-plane learning". Should it be per Data Label (VLAN or Fine-Grained Label) or per Data Label plus the originating RBridge? I am afraid this RBridge cannot simple disable data-plane learning for the whole V1. It's probably that some RBridge in V1 are participating ESADI while others are not participating. For those not participating, the RBridge cannot disable the data-plane learning.

Well, the currently required facility is just per VLAN. See Section
5.4 RFC 6325.

I would think that in most real world situations, the network manager
would either have all the RBridges that had end stations in VLAN-x
either use ESADI or use data plane learning. However, if there was a
mixed scenario, then it seems like one way to handle this within the
TRILL protocol is for all the RBridges to have data plane learning
turned on for VLAN-x but to treat what is learned from the data plane
as having lower confidence that what is received from ESADI.

> It seems your final judgment still holds for the fine-grained "disabling data-plane learning" (i.e., per Data Label + originating RBridge). In other words, using already existing ESADI mechanism, the originating RBridge may well withdraw its MAC addresses by sending updated link state information through the ESADI instance. However, please consider the following case:

> Suppose both RB1, RB2 are communicating with a remote RBridge, say RBx, in V1. RB1 and RB2[[I think you mean RBx here]] are participating ESADI while RB2 is not. So, RBx has to retain data-plane learning for RB2. Now, RB1 wants to flush the MAC addresses attached to RB2. This case could be meaningful when RB1 speaks for other RBridges (e.g., RB1 acts as a reflector or central controller). For this case, an add-on flush function of ESADI is desirable.

See double parenthesis above. You mean that RBx should do data plane
learning for TRILL Data packet is egresses that were ingressed by RB2.
It seems odd to me that you way that RB1 wants to flush an address
that is/was locally attached to RB2. I'm not sure that RB1 should be
able to do that. RBridges, it seems to me, have better and more
immediate knowledge of locally attached end station MACs than they do
for remote MAcs. So I think RB1 should only flush things that other
RBridges have learned due to frames ingressed by RB1. RB2 is the
RBridge that knows best about end stations attached to RB2 so I think
RB2 should be the one originating flushes for stations that were
attached to RB2.

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

>> since ESADI can replace data plane learning. So, it is
>> not particularly useful to provide a way to clear data plane learning for ESADI
>> participants that probably don't have any data plane learning anyway.
>>
>> It seems more reasonable to implement an address learning flush message as
>> an RBridge Channel protocol. True, an RBridge might not implement the
>> RBridge Channel facility or might implement it but not implement such an
>> address flush message. But it might not implement ESADI either. Things still
>> work in such a case as data plane address learning will eventually time out. But
>> traffic may get black holed (sent to the wrong RBridge) temporarily, a problem
>> that can be fixed by the address flush facility.
>>
>> I do not necessarily support all the details in the current draft. I'm sure it can
>> be improved. But I do that that using RBridge Channel messages is the way to
>> go.
>
> Thanks,
> Mingui
>
>> Thanks,
>> Donald
>> =============================
>>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>  155 Beaver Street, Milford, MA 01757 USA  d3e3e3@gmail.com
>>
>> > ________________________________________
>> > From: Donald Eastlake [d3e3e3@gmail.com]
>> > Sent: Friday, February 12, 2016 0:59
>> > To: trill@ietf.org
>> > Subject: [trill] RBridge Channel versus ESADI for MAC address flush
>> >
>> > At the last TRILL WG meeting in Yokohama, towards the end of the
>> > second session, there was a discussion of the best mechanism to
>> > implement a remote RBridge MAC address flush mechanism.
>> > draft-hao-trill-address-flush proposes to use RBridge Channel messages
>> > [RFC7178] but some people suggest the use of ESADI messages [RFC7357].
>> > There was no resolution of this at the meeting so the Chair indicated
>> > that it should be taken to the mailing list. This message is to start
>> > the discussion. I'll post separately with my personal opinion.
>> >
>> > Thanks,
>> > Donald
>> > =============================
>> >  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>> >  155 Beaver Street, Milford, MA 01757 USA  d3e3e3@gmail.com