[rrg] Rebuttal to Critique of “Enhanced Efficiency of Mapping Distribution Protocols in Map-and-Encap Schemes”

["Sriram, Kotikalapudi" <[e-mail]>]

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

Draft of the proposal:
http://tools.ietf.org/html/draft-irtf-rrg-recommendation-04#section-13 
More detailed document:
http://www.antd.nist.gov/~ksriram/NGRA_map_mgmt.pdf 
(substantially revised version to be posted within the next week)

Critique (posted by Lixia Zhang on Feb 13, 2010):
http://www.ietf.org/mail-archive/web/rrg/current/msg06025.html  

Another critique posted by Robin earlier today
(it appears that he missed seeing Lixia’s critique cited above):
http://www.ietf.org/mail-archive/web/rrg/current/msg06087.html 

Note: This rebuttal was prepared primarily in response to the critique
posted by Lixia, and prior to the posting of Robin’s critique today on the list,
but I feel that it still covers several aspects addressed in Robin’s critique as well.
Therefore, I am posting this rebuttal for now partly in the interest
of meeting the rebuttal deadline (I guess it already passed), but also partly to
offer my responses to some of Robin’s comments.
I will follow up with further response to Robin’s other comments
in additional  email messages later within the next week or so. 
----------------------------  

Rebuttal (from Sriram and his co-authors; 494 words):

There are two main points in the critique that would be 
addressed here: (1) 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, and (2) Approach 2 is lacking
an added feature of conveying just the mask-length of the more 
specifics that exist as part of current map-response.

Regarding comment (1) above, there are multiple possibilities regarding
how situations can arise  resulting in allocations having holes in them. 
An example of one of these possibilities is as follows. Org-A has historically 
received multiple /20s, /22s, /24s over the course of time which are adjacent 
to each other. At the present time, these prefixes would all aggregate to 
a /16 but for the fact that just a few of the underlying /24s have been 
allocated elsewhere historically to other organizations by an RIR or ISPs. 
An example of a second possibility is that Org-A has an allocation
of a /16 prefix. It has suballocated a /22 to one of its subsidiaries,
and subsequently sold the subsidiary to another Org-B. For ease of 
keeping the /22 subnet up and running without service disruption, the
/22 subprefix is allowed to be transferred in the acquisition process.
Now the /22 subprefix originates from a different AS 
and is serviced by a different ETR (as compared to the parent \16 prefix).
We are in the process of performing an analysis of RIR allocation
data and are aware of other studies (notably at UCLA) which are 
also performing similar analysis to quantify the frequency of occurrence 
of the holes. We feel that the problem that has been addressed 
is a realistic one, and the proposed scheme would help reduce the 
overheads associated with the mapping distribution system.

Regarding comment (2) above, the suggested modification to
Approach 2 would be definitely beneficial. In fact, we feel that
it would be fairly straight forward to dynamically use Approach 1 
or Approach 2 (with the suggested modification), depending on 
whether there are only a few (e.g., <=5) or many (e.g., >5) more specifics,
respectively. The suggested modification of notifying the mask-length of 
the more specifics in map-response is indeed very helpful because
then the ITR would not have to resend a map-query for EID addresses
that match the EID address in the previous query up to at least 
mask-length bit positions. There can be a two-bit field in map-response 
that would indicate: (a) With value 00 for notifying that there are 
no more-specifics; (b) With value 01 for notifying that there are 
more-specifics and their exact information follows in additional 
map-responses, and (c) With value 10 for notifying that there are 
more-specifics and the mask-length of the next more-specific is 
indicated in the current map-response. An additional field will be 
included which will be used to specify the mask-length of the 
next more-specific in the case of the “10” indication (case (c) above).