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

[Donald Eastlake <[e-mail]>]

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,
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   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> ________________________________________
> From: Donald Eastlake [[e-mail]]
> Sent: Friday, February 12, 2016 0:59
> To: [e-mail]
> 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   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail]