Sriram and I had a few exchanges to clarify the picture with his  
design; he also further clarified with Dino the earlier comments on  
this scheme.  Below is an updated critique, mostly by Sriram.

Lixia
------------------
Critique of “Enhanced Efficiency of Mapping Distribution Protocols in  
Map-and-Encap Schemes”

This scheme (see http://www.antd.nist.gov/~ksriram/NGRA_map_mgmt.pdf  
for details) represents one approach to mapping overhead reduction,  
and it is a general idea that is applicable to any proposal that  
includes prefix or EID aggregation. A somewhat similar idea is also  
used in Level-3 aggregation in the FIB aggregation proposal (“An  
Evaluation Study of Router FIB Aggregatability,” GROW WG, IETF76).   
There can be cases where  deaggregation of EID prefixes occur in such  
a way that bulk of an EID prefix P would be attached to one locator  
(say, ETR1) while a few subprefixes under P would be attached to other  
locators elsewhere (say, ETR2, ETR3, etc.). Ideally such cases should  
not happen, however in reality it can happen as RIR's address  
allocations are imperfect.  In addition, as new IP address allocations  
become harder to get, an IPv4 prefix owner might split previously  
unused subprefixes of that prefix and allocate them to remote sites  
(homed to other ETRs).  Assuming these situations could arise in  
practice, the nature of solution would be that the response from  
mapping server for the coarser site would include information about  
the more specifics.  The solution as presented seems correct.

The proposal mentions that in Approach 1, the ID-Locator Mapping (ILM)  
system provides the complete mapping information for an aggregate EID  
prefix to a querying ITR including all the maps for the relevant  
exception subprefixes. The sheer number of such more-specifics can be  
worrisome, for example, in LISP.  What if a company’s mobile-node EIDs  
came out of their corporate EID-prefix?  Approach 2 is far better but  
still there may be too many entries for a regional ILM to store. In  
Approach 2, ILM communicates that there are more specifics but does  
not communicate their mask-length. A suggested improvement would be  
that rather than saying that there are more specifics, indicate what  
their mask-lengths are. There can be multiple mask lengths.  This  
number should be pretty small for For IPv4 but can be large for IPv6.

Later in the proposal, a different problem is addressed involving a  
hierarchy of ETRs and how aggregation of EID prefixes from lower level  
ETRs can be performed at a higher level ETR. The various scenarios  
here are well illustrated and described. This seems like a good idea,  
and a solution like LISP can support this as specified.
As any optimization scheme would inevitably add some complexity; the  
proposed scheme for enhancing mapping efficiency comes with some of  
its own overhead.  The gain depends on the details of specific EID  
blocks, i.e., how frequently the situations arise such as an ETR  
having a bigger EID block with a few holes.