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

[Robin Whittle <[e-mail]>]

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