[armd] Gen-art] review: draft-ietf-armd-problem-statement-03

["Joel M. Halpern" <[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> .

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-armd-problem-statement-03
     Problem Statement for ARMD
Reviewer: Joel M. Halpern
Review Date: 9-Aug-2012
IETF LC End Date: 23-Aug-2012
IESG Telechat date: N/A

Summary: This document is almost ready for publication as an 
Informational RFC

Major issues:
     The use of the term "switch" seems confusing.  I had first assumed 
that it meant an ethernet switch (which might have  abit of L3 smarts, 
or might not.  I was trying not to be picky.)  But then, in section 6.3 
it refers to "core switches ... are the data center gateways to external 
networks" which means that those are routers.

Moderate Issue:
    The document seems to be interestingly selective in what modern 
technologies it chooses to mention.  Mostly it seems to be describing 
problems with data center networks using technology more than 5 years 
old.  Since that is the widely deployed practice, that is defensible. 
But then the document chooses to mention new work such as OpenFlow, 
without mentioning the work IEEE has done on broadcast ad multicast 
containment for data centers.  It seems to me that we need to be 
consistent, either describing only the widely deployed technology, or 
including a fair mention of already defined and productized solutions 
that are not yet widely deployed.

     On a related note, the document assumes that multicast NDs are 
delivered to all nodes, while in practice I believe existing techniques 
to filter such multicast messages closer to the source are widely 
deployed.  (Section 5.)

Minor issues:
     I presume that section 6.4.2 which describes needing to enable all 
VLANs on all aggregation ports is a description of current practice, 
since it is not a requirement of current technologies, either via VLAN 
management or orchestration?

     Section 6.4.4 seems very odd.  The title is "overlays".  Are there 
widely deployed overlays?  If so, it would be good to name the 
technologies being referred to here.  If this is intended to refer to 
the overlay proposal in IETF and IEEE, I think that the characterization 
is somewhat misleading, and probably is best simply removed.

     Is the fifth paragraph of section 71. on ARP processing and 
buffering in the absence of ARP cache entries accurate?  I may well be 
out of date, but it used to be the case that most routers dropped the 
packets, and some would buffer 1 packet deep at most.  This description 
indicates a rather more elaborate behavior.

     Given that this document says it is a general document about 
scaling issues for data centers, I am surprised that the security 
considerations section does not touch on the increased complexity of 
segregating subscriber traffic (customer A can not talk to customer B) 
when there are very large numbers of customers, and the itneraction of 
this with L2 scope.

Nits/editorial comments: