-----Original Message-----
From: Donald Eastlake [mailto:d3e3e3(_at_)gmail(_dot_)com]
Sent: Friday, July 19, 2013 7:56 AM
To: Black, David
Cc: ldunbar(_at_)huawei(_dot_)com; Radia(_at_)alum(_dot_)mit(_dot_)edu;
igor(_at_)yahoo-inc(_dot_)com; General Area
Review Team; trill(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; Ted Lemon
Subject: Re: Gen-ART review of draft-ietf-trill-directory-framework-05
Hi David,
Thanks for the review. See responses below.
On Wed, Jul 17, 2013 at 7:54 PM, Black, David
<david(_dot_)black(_at_)emc(_dot_)com> 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 +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3(_at_)gmail(_dot_)com
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(_dot_)black(_at_)emc(_dot_)com Mobile: +1 (978) 394-7754
----------------------------------------------------