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

Mingui Zhang <> Tue, 16 February 2016 07:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D4F3A1A88A6 for <>; Mon, 15 Feb 2016 23:22:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.607
X-Spam-Status: No, score=-3.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CqzofwDcgxBa for <>; Mon, 15 Feb 2016 23:22:53 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EE2EF1A87AD for <>; Mon, 15 Feb 2016 23:22:52 -0800 (PST)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id CEM06189; Tue, 16 Feb 2016 07:22:32 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 16 Feb 2016 07:22:08 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 16 Feb 2016 07:22:08 +0000
Received: from ([fe80::a54a:89d2:c471:ff]) by ([]) with mapi id 14.03.0235.001; Tue, 16 Feb 2016 15:22:05 +0800
From: Mingui Zhang <>
To: Donald Eastlake <>, "" <>
Thread-Topic: [trill] RBridge Channel versus ESADI for MAC address flush
Thread-Index: AQHRZO23KsQQ04JFskq1XN7/Dk/PI58siCmLgABUecA=
Date: Tue, 16 Feb 2016 07:22:04 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.56C2CE45.0099, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 712b0f2f0266ffb60e5314836fd44c94
Archived-At: <>
Subject: Re: [trill] RBridge Channel versus ESADI for MAC address flush
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 Feb 2016 07:22:56 -0000

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 [] On Behalf Of Donald Eastlake
> Sent: Monday, February 15, 2016 12:26 PM
> To:
> 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.

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 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.

> 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
> > ________________________________________
> > From: Donald Eastlake []
> > Sent: Friday, February 12, 2016 0:59
> > To:
> > 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
> _______________________________________________
> trill mailing list