Subject: Re: [trill] [Gen-art] Gen-ART review of draft-ietf-trill-directory-framework-06

From: Jari Arkko <[email-masked]>
Date: Mon, 12 Aug 2013 20:11:51 +0300

David: Thank you. I have placed a no-objection ballot for this draft.

Jari

On Jul 29, 2013, at 2:20 PM, "Black, David" <[email-masked]> 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: [email-masked]; Donald Eastlake; [email-masked]; igor@yahoo-
>> inc.com; General Area Review Team
>> Cc: [email-masked]; [email-masked]; 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
>> [email-masked]        Mobile: +1 (978) 394-7754
>> ----------------------------------------------------
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art