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

honjun.zhai <honjun.zhai@tom.com> Mon, 15 February 2016 08:40 UTC

Return-Path: <honjun.zhai@tom.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 33C871B2F7D for <trill@ietfa.amsl.com>; Mon, 15 Feb 2016 00:40:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.243
X-Spam-Level: ***
X-Spam-Status: No, score=3.243 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RCVD_IN_PSBL=2.7, 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 fqT81k6LRbUa for <trill@ietfa.amsl.com>; Mon, 15 Feb 2016 00:39:55 -0800 (PST)
Received: from smtp.tom.com (smtpfreer209.163vip.net [61.135.158.116]) by ietfa.amsl.com (Postfix) with SMTP id D8C3F1B2F5E for <trill@ietf.org>; Mon, 15 Feb 2016 00:39:45 -0800 (PST)
Received: from smtp.tom.com (unknown [172.24.173.69]) by bjzjm-tm-app4.localdomain (SMTP) with ESMTP id C9DF0189FD8 for <trill@ietf.org>; Mon, 15 Feb 2016 16:39:39 +0800 (CST)
Authentication-Results: bjzjm-antispam2 smtp.user=honjun.zhai@tom.com; auth=pass (LOGIN)
Received: from [172.24.173.117] ([172.24.173.117:48345] helo=bjzjm-tm-web5) by bjzjm-antispam2 (envelope-from <honjun.zhai@tom.com>) (ecelerity 3.5.4.38585 r(Platform:3.5.4.0)) with ESMTPA id 9A/42-15677-BCE81C65; Mon, 15 Feb 2016 16:39:39 +0800
Date: Mon, 15 Feb 2016 16:40:52 +0800 (CST)
From: =?UTF-8?B?aG9uanVuLnpoYWk=?= <honjun.zhai@tom.com>
To: =?UTF-8?B?RG9uYWxkIEVhc3RsYWtl?= <d3e3e3@gmail.com>
Message-ID: <215386047.731018.1455525652191.JavaMail.tomwebmail@bjzjm-tm-web5>
In-Reply-To: <CAF4+nEEToy_PMPXVcw07dhchAMNns4V+Y9eCrmcveGndesm7JQ@mail.gmail.com>
References: <CAF4+nEFxdn-EA27y6y+ist9vFpbWh6h9JAkRLFSjyW5kf8QJpQ@mail.gmail.com> <DD5FC8DE455C3348B94340C0AB551733502932AD@nkgeml513-mbx.china.huawei.com> <CAF4+nEEToy_PMPXVcw07dhchAMNns4V+Y9eCrmcveGndesm7JQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_731016_1665674535.1455525652189"
X-Mailer: TOMWEBMAIL 2.0
X-Originating-IP: 221.226.154.107
Archived-At: <http://mailarchive.ietf.org/arch/msg/trill/76en6Vs8Rzu5XokzReTUPW7X49U>
Cc: trill@ietf.org
Subject: Re: [trill] =?utf-8?q?RBridge_Channel_versus_ESADI_for_MAC_address_fl?= =?utf-8?q?ush?=
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: Mon, 15 Feb 2016 08:40:01 -0000

<p>Hi Donald,</p>
<p></p>
<p>&gt; So, it is not particularly useful to provide a way to clear data plane learning for</p>
<p>&gt; ESADI participants that probably don't have any data plane learning anyway.</p>
<p></p>
<p>Agree.&nbsp; I also think the MAC addresses advertised by ESADI participants should </p>
<p>be flushed by ESADI messages rather than the RBridge Channel messages.<br /><br />&gt; I do not necessarily support all the details in the current draft. I'm sure it can be </p>
<p>&gt; improved. But I do that that using RBridge Channel messages is the way to go.</p>
<p></p>
<p>Agree.<br /><br /></p>
<p>Thanks,<br /></p>
<p>Hongjun Zhai</p>
<p>------------------------------------------------------------------------------</p>
<p>Jiangning&nbsp;District, Nanjing City, People's Republic of China</p>
<p>Mobile: +086-025-5287-7345</p>
<p>Email: <a href="mailto:Honjun.zhai@gmail.com">honjun.zhai@tom.com</a></p>
<p>------------------------------------------------------------------------------</p>
<p><br /></p>
<hr />
<p><br /><br />于 2016-02-15 12:25:38,Donald Eastlake&lt;d3e3e3@gmail.com&gt;写道:</p>
<blockquote style="PADDING-LEFT: 1ex; BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex"><pre>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&amp;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,
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,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com
&gt; ________________________________________
&gt; From: Donald Eastlake [d3e3e3@gmail.com]
&gt; Sent: Friday, February 12, 2016 0:59
&gt; To: trill@ietf.org
&gt; Subject: [trill] RBridge Channel versus ESADI for MAC address flush
&gt;
&gt; At the last TRILL WG meeting in Yokohama, towards the end of the
&gt; second session, there was a discussion of the best mechanism to
&gt; implement a remote RBridge MAC address flush mechanism.
&gt; draft-hao-trill-address-flush proposes to use RBridge Channel messages
&gt; [RFC7178] but some people suggest the use of ESADI messages [RFC7357].
&gt; There was no resolution of this at the meeting so the Chair indicated
&gt; that it should be taken to the mailing list. This message is to start
&gt; the discussion. I'll post separately with my personal opinion.
&gt;
&gt; Thanks,
&gt; Donald
&gt; =============================
&gt;  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
&gt;  155 Beaver Street, Milford, MA 01757 USA
&gt;  d3e3e3@gmail.com
_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill
</pre></blockquote>