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