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

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Sun, 21 Feb 2010 23:02:58 -0500

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

---

From: Robin Whittle <[email-masked]>
Date: Mon, 22 Feb 2010 19:24:32 +1100

Short version:  I think most of the end-user networks which will be
                using the new scalable "edge" space provided by CES
                architectures will only need one or a handful of IPv4
                addresses.  I think their usage of this space will
                be pretty scattered between ETRs all over the place.

Hi Sriram,

Thanks for your message concerning my critique.  Here are some
thoughts on address allocation for CES "edge" space.

I don't think current patterns of use of BGP advertised prefixes will
help much in predicting how space will be used in a CES system.  The
current usage of PI space depends on how RIRs allocate the space and
how the current PI end-user networks actually use it.

In solving the routing scaling problem, most of the users of
multihomable, portable, space will be different and generally smaller
organisations than those who currently have PI prefixes.  They will
be far more numerous and my guess is that the probably won't be
obtaining space directly from RIRs.

To get any accurate idea of future usage patterns for the new
scalable "edge" space, firstly, one would have to determine how space
was allocated to end-user networks with such a system - then one
would need to imagine how a wide variety of end-user networks (EUNs)
might use them.

With Ivip, I anticipate that most EUNs will obtain space from a
company which "owns" or runs a Mapped Address Block (MAB) - a large
(short prefix) prefix of space which is advertised in the DFZ as a
single prefix.  Hundreds or thousands of EUNs would lease space from
within a single MAB.  They would presumably get contiguous chunks of
space, but perhaps they want more and then lease a second chunk.

I am sure that the great majority of EUNs will be happy with less
than 256 IPv4 addresses.  The number of /24s in the DFZ greatly
outnumbers any other shorter prefix:

  http://bgp.potaroo.net/bgprpts/rva-index.html
  http://bgp.potaroo.net/as2.0/bgp-active.html

     /8	    21   0.01%
     /9	    10 	 0.00%
    /10	    25 	 0.01%
    /11	    65 	 0.02%
    /12	   187 	 0.06%
    /13	   391 	 0.12%
    /14	   662 	 0.21%
    /15	  1236 	 0.39%
    /16	 10946 	 3.48%
    /17	  5165 	 1.64%
    /18	  8723 	 2.77%
    /19	 18101 	 5.75%
    /20	 21995 	 6.99%
    /21	 22172 	 7.05%
    /22	 28569 	 9.08%
    /23	 28696   9.12%
    /24 164513  52.28%

Just over half of advertised prefixes are /24, though the percentage
has dropped a few points in the last decade.  /24 is the smallest
chunk of PI space which can be used, due to convention on filtering
out longer prefixes.

These /24s are presumably almost all PI prefixes of EUNs.  Since the
actual needs of EUNs will vary considerably, it is reasonable to
assume from this distribution that the great majority of them need
less than 256 IPv4 addresses at any one site.  If even 20% of them
needed more, we would see a bigger spill over into the numbers of
/23s than we do.

With Ivip, each micronet (separately mappable chunk of SPI "edge"
space) will be an arbitrary number of IPv4 addresses, or IPv6 /64s.
So usage of space won't be constrained by binary boundaries, and
lengths of 2, 4, 8, 16 etc.

Generally, I think the pattern will be that there will be a
contiguous chunk of space for one EUN, followed by another contiguous
chunk for another EUN.  These EUNs could have their "head office"
(usually their single site) anywhere in the world with respect to the
EUN whose space is adjacent in any MAB.

Many EUNs will have one site and so presumably one or two micronets
(EID prefixes in LISP), some will have two sites and so just a
handful of micronets, some will have three sites etc. and a few will
have a hundred sites.  So how they split their space up will vary
considerably.

Many sites probably only need a single IPv4 address, or four or so.
If they had separate IPv4 addresses for mailserver, nameserver,
webserver, VoIP box and VPN access, they would be fine with 8
addresses or less.  Each one of these could be on a separate
micronet, or they could all be on one.  When multihomed some
micronets (such as a single IPv4 address per micronet) may be on one
ETR and the rest may be on the other.  However, some networks will be
able to run all these services on a single IPv4 address, or on two or
three IPv4 addresses.

My impression of what will transpire is that there would be too few
patterns of usage in which your more complex mapping system might be
helpful to make the extra complexity worthwhile - but I don't have
any data about the future!

  - Robin

---

From: Tony Li <[email-masked]>
Date: Mon, 22 Feb 2010 14:27:31 -0800

Hi Sriram,

On 2/21/10 8:02 PM, "Sriram, Kotikalapudi" <[email-masked]>
wrote:

> Rebuttal to Critique of
> ³Enhanced Efficiency of Mapping Distribution Protocols in
> Map-and-Encap Schemes²

I've incorporated your rebuttal...

> http://www.ietf.org/mail-archive/web/rrg/current/msg06025.html

... And Lixia's critique.

Tony