Telechat Review of draft-ietf-trill-directory-framework-06
review-ietf-trill-directory-framework-06-genart-telechat-black-2013-08-09-00

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
> ----------------------------------------------------