Last Call Review of draft-ietf-trill-address-flush-05
review-ietf-trill-address-flush-05-opsdir-lc-bhandari-2018-03-26-00

Reviewer: Shwetha Bhandari
Review Result: Ready with nits

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

Summary:
This draft specifies a message by which a TRILL switch can explicitly request
other TRILL switches to flush certain MAC reachability learned through TRILL
Data packets. This is done by defining a new message to flush mac addresses in
the RBridge protocol [rfc6325]. Operational considerations: - The draft list
couple of possible operational scenarios when the message to flush learnt mac
address can be triggered: o LDP Address Withdraw Message based
rfc4762#section-6.2 can be mapped into Rbridge protocol with the new message
defined in this draft o When RBridges receive topology change information
(e.g., TC in STP, TCN in MSTP) - Nice to have –  defining a data model to
trigger address flush that can then be programmatically (e.g. over
netconf/restconf) called in any scenario. - For securing these message RBridge
Channel Header Extension are recommended. - Monitoring or reporting
considerations when address flush messages are processed: I did not find any
section/text that recommends logging/triggering of events on successful or
failure to process address flush message. Considering the message defined here
flushes blocks of learnt mac addresses trouble shooting connectivity issues as
a result of the address flush without some form of reporting will be difficult.

Thanks,
Shwetha