Last Call Review of draft-ietf-trill-address-flush-05

Request Review of draft-ietf-trill-address-flush
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2018-02-05
Requested 2018-01-22
Authors Hao Weiguo, Donald Eastlake, Li Yizhou, Mohammed Umair
Draft last updated 2018-03-26
Completed reviews Rtgdir Early review of -00 by Henning Rogge (diff)
Opsdir Last Call review of -05 by Shwetha Bhandari (diff)
Genart Last Call review of -05 by Robert Sparks (diff)
Secdir Last Call review of -05 by Dan Harkins (diff)
Assignment Reviewer Shwetha Bhandari 
State Completed
Review review-ietf-trill-address-flush-05-opsdir-lc-bhandari-2018-03-26
Reviewed rev. 05 (document currently at 06)
Review result Has Nits
Review completed: 2018-03-26


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. 

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.