Document: draft-ietf-trill-directory-framework-05 Reviewer: David L. Black Review Date: July 17, 2013 IETF LC End Date: July 18, 2013 Summary: This draft is on the right track but has open issues, described in the review. This draft describes a framework for using directory servers to provide address mappings (address -> destination RBridge) to TRILL Rbridges as an alternative to data plane learning and use of the TRILL ESADI protocol. The draft's generally well written and clear. I found a couple of minor issues. Major issues: None. Minor issues: [1] The last bullet in Section 3.1 says: - In an environment where VMs migrate, there is a higher chance of cached information becoming invalid, causing traffic to be black-holed by the ingress RBridge, that is, persistently sent to the wrong egress RBridge. If VMs do not flood gratuitous ARP/ND or VDP [802.1Qbg] messages upon arriving at new locations, the ingress nodes might not have MAC entries for the MAC of the newly arrived VMs, causing unknown address flooding. This is incorrect in multiple ways and should just be removed: - Persistent black-holing is rare in practice because all common VM migration implementations issue the gratuitous messages. - VMs don't send the gratuitous messages, hypervisors do. - VDP is not flooded. The receiver's always a bridge. - At least one common VM migration implementation actually uses a gratuitous RARP, not ARP. - Flooding is done by the bridges and Rbridges, not the VMs. [2] There are some unfortunate notation problems in Section 5.1 that carry into the following sections, based on the logical data structure: [{IP, MAC/VLAN, {list of attached RBridge nicknames}, {list of interested RBridges}] - The first open curly brace ('{') is unmatched. - Subsequent text uses [IP or MAC/VLAN], IP/MAC/VLAN and MAC&VLAN, none of which appear in that structure. Nits/editorial comments: Section 1 - item 1 in the numbered list does not explain why it makes a directory approach attractive. This should be added, as it is present for the other three items . Section 2 - Say that IS-IS is a routing protocol. The definition of Station should say that the node or virtual node is on a network. Also, please define or explain "virtual node". Section 3.2 - Add the number of entries to be learned to scenario #1 in order to parallel the scenario # 2 discussion. Section 4 - remove "(distributed model)" from first paragraph, as it's not explained. Section 5.3, top of p.13: therefore, there needs to be some mechanism by which RBridges that have pulled information that has not expired can be informed when that information changes or the like. "or the like" is vague. I suggest "or becomes invalid for other reasons". idnits 2.12.17 didn't find any nits that need attention. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA  01748 +1 (508) 293-7953             FAX: +1 (508) 293-7786 david.black at emc.com        Mobile: +1 (978) 394-7754 ----------------------------------------------------