The -06 version of this draft resolves all of the concerns raised by the Gen-ART review of the -05 version - the -06 version is ready for publication as an Informational RFC. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Wednesday, July 17, 2013 7:54 PM > To: ldunbar at huawei.com; Donald Eastlake; Radia at alum.mit.edu; igor at yahoo- > inc.com; General Area Review Team > Cc: trill at ietf.org; ietf at ietf.org; Black, David; Ted Lemon > Subject: Gen-ART review of draft-ietf-trill-directory-framework-05 > > 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 > ----------------------------------------------------