Hi Donald, All of your responses are fine with me. Thanks, --David > -----Original Message----- > From: Donald Eastlake [mailto:d3e3e3@xxxxxxxxx] > Sent: Friday, July 19, 2013 7:56 AM > To: Black, David > Cc: ldunbar@xxxxxxxxxx; Radia@xxxxxxxxxxxx; igor@xxxxxxxxxxxxx; General Area > Review Team; trill@xxxxxxxx; ietf@xxxxxxxx; Ted Lemon > Subject: Re: Gen-ART review of draft-ietf-trill-directory-framework-05 > > Hi David, > > Thanks for the review. See responses below. > > On Wed, Jul 17, 2013 at 7:54 PM, Black, David <david.black@xxxxxxx> wrote: > > 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. > > Thanks. > > > 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: > > OK. > > > - 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. > > We'll try to clean that up. > > > 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 . > > I suggest combining point 1 with the material just before the table > and re-numbering points 2-4 to be 1-3. > > > 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". > > OK on the first two points. On "virtual node", that is only used in > the definition of "station" which is different from the definition of > "end station". However, looking through the document, there was only > one instance of "station" without "end" before it and that instance > was talking about end stations. So I propose to remove the definition > of "station" and to insert "end" before the one occurrence of > "station" in the body of the document not already preceded by "end". > > > Section 3.2 - Add the number of entries to be learned to scenario #1 > > in order to parallel the scenario # 2 discussion. > > OK. > > > Section 4 - remove "(distributed model)" from first paragraph, > > as it's not explained. > > OK. > > > 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". > > OK. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@xxxxxxxxx > > > 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@xxxxxxx Mobile: +1 (978) 394-7754 > > ----------------------------------------------------