Re: [trill] Gen-ART review of draft-ietf-trill-directory-framework-05

[Donald Eastlake <[e-mail]>]

Hi David,

Thanks for the review. See responses below.

On Wed, Jul 17, 2013 at 7:54 PM, Black, David <[e-mail]> 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   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> 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
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------