Re: [trill] Edge Directory Assistance Framework draft-ietf-trill-directory-framework-04.txt

[Donald Eastlake <[e-mail]>]

Replying as a co-author,

On Wed, Apr 24, 2013 at 6:03 PM, Linda Dunbar <[e-mail]> wrote:
> Jon,
>
> Thank you very much for shepherding this draft.
>
> Reply to your comments are inserted below:
>
> From: Jon Hudson [mailto:[e-mail]]
> Sent: Wednesday, April 24, 2013 2:43 AM
> To: Linda Dunbar; Donald Eastlake; Radia Perlman; [e-mail]
> Cc: [e-mail]
> Subject: Edge Directory Assistance Framework
> draft-ietf-trill-directory-framework-04.txt
>
> Greetings Authors!
>
> I am the Document Shepard for you draft.
>
> Initial review of your draft brings up three initial small issues and one
> small suggestion
>
> (1) Acronyms that are not common IETF acronyms need to be spelled out
> on first use in the Abstract and Introduction. (TRILL is spelled out
> on second use in the abstract but there are others not spelled out at
> all.)
>
> [Linda] Can you point out the exact acronyms? Terminology Section should
> have the definitions for all of acronyms used in the document.  But we might
> missed some.

OK.

> (2) The list of acknowledgements should include Sam Aldrin and Yizhou
> Li who did reviews.
>
> [Linda] Absolutely. We can re-spin the draft to include the people who
> provided valuable comments.

OK.

> (3) A light editing pass should be done by someone who is a native
>
> English speaker to add articles and the like so it reads more smoothly.Some
> statements are a wee bit awkward. Just in the paragraph below "...where VMs
> migrates" needs to be either where a VM migrates or where VMs migrate.
>
> [Linda] I will leave it to Donald for a final check.

OK.

> (4) Just a suggestion: the last paragraph in section 3.1 ( lovely ascii
> pictures by the way)
>
>     - In an environment where VMs migrates, there is 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.
>
> It may be worth noting that the issues with reliance on the gratuitous ARP
> is exacerbated by the fact that individual implementations in the field
> vary, and even between product lines in the same vendor you will different
> timers as to how long it takes for a switch to act on a gratuitous arp. The
> inconsistency this creates is so troublesome I have worked in some shops
> that flat never relied on gratuitous ARPs for anything.
>
> Now since this amounts to implementation issues, and not any issues with
> 802.1bg, it may not be worth mentioning. However it is the first thing I
> think of when I think of the value learning by directory would bring me in a
> datacenter.
>
> [Linda] So you are agreeing with the statement in our draft? i.e. You can’t
> depend on Gratuitous ARP to flush stalled entries. You can’t depend on
> 802.1bg either because not every server support this feature.

I'm not sure that is worth changing in the draft.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> Just a suggestion, 4 is not a blocking issue.
>
>
>
> Other than the items above, the draft is looking quite good.
>
>
>
> Cheers,
>
> Jon
>
>
>
>
>
>
> _______________________________________________
> trill mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trill
>