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