David: Thank you. I have placed a no-objection ballot for this draft.
Jari
On Jul 29, 2013, at 2:20 PM, "Black, David" <david.black@xxxxxxx> wrote:
> 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@xxxxxxxxxx; Donald Eastlake; Radia@xxxxxxxxxxxx; igor@yahoo-
>> inc.com; General Area Review Team
>> Cc: trill@xxxxxxxx; ietf@xxxxxxxx; 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@xxxxxxx Mobile: +1 (978) 394-7754
>> ----------------------------------------------------
>
> _______________________________________________
> Gen-art mailing list
> Gen-art@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/gen-art