Re: [RRG] Consensus? 4 points so we can make progress

[Robin Whittle <rw@firstpr.com.au>]

Hi Noel,

You wrote:

>     > we need to settle on portable address space as the solution for
>     > end-user networks' need to change to another provider
>     > ...
>     > Portability is a clear solution end-users are familiar with and
>     > actually want - and the map-encap systems provide this portability
>     > without the scaling problems 
> 
> As long as you make it clear that the solution is *NOT* "portable address
> space", but rather "portable address space *along with* a map-encap system"
> - the former being something that some people somehow seem to think is a
> 'solution'.

OK.  I meant portable address space which is provided as part of the
RRG's solution to the routing scaling problem.  I am not advocating
portable address space which worsens the routing scaling problem -
as does the only kind of portable space today: directly BGP
advertised PI prefixes.

Here is a more detailed attempt:

  Within the RRG time-frame - recommendation in 2008-03 and
  large-scale deployment starting around 2012 - portable address
  space is the only approach we can consider for providing
  end-user networks with the freedom to choose a new provider
  without unreasonable costs, disruption and risks.

  The RRG solution needs to provide "scalable portable address
  space" for end-user networks of all sizes.

  This means that the new form of address space places little or
  no burden on the existing BGP system and is handled by the new
  architecture in a manner which scales well to whatever projected
  number of  end-user networks we anticipate in the long-term.

The map-encap schemes provide this for both IPv4 and IPv6.  Perhaps
there will be some non map-encap proposal which will also do this -
but such a proposal would need to be developed pretty quickly in
order for it to be the basis for our architectural recommendation 9
months from now.


I think it would be helpful if we reached some rough consensus on:

1 - When we expect large-scale deployment to start.

2 - How long after that we expect a sizable majority of new
    end-user networks to adopt the new method of managing their
    address space, and likewise some kind of notion of how many
    existing BGP-PI based end-user networks will adopt it (to lessen
    the load on the BGP system, as well as to not increase it).

3 - Long term goals adoption goals by various measures,
    including numbers of end-user network numbers, such as:

     a - Absolute numbers of EID prefixes (micronets)
         the new architecture needs to handle.

     b - Amount of IPv4 EID/micronet address space - as a fraction
         of allocated (assigned?) and yet to be allocated space.

     c - Proportion of existing large end-user networks:
         universities, government departments, corporations
         etc.

     d - Proportion of moderate sizes end-user networks:
         mid-size companies, schools, businesses and other
         organisations with more than a few people etc.

     e - Proportion of home, small office and home office
         end-user networks.

     f - Proportion of probably "single-host" end-user
         networks including mobile devices (laptops,
         cell-phones, PDAs etc.) and perhaps mobile or
         fixed embedded devices (credit card readers,
         sensors, security devices etc.).

I am not suggesting that most home or SOHO end-users will want or
need portability, multihoming etc.  However, because I think that
TTR-style mobility:

   http://www.firstpr.com.au/ip/ivip/#mobile

is a promising and likely profitable approach to global (and between
multiple operator's radio networks) mobility for cell-phones,
laptops etc. I think that there could be a need for a map-encap
system which is the basis for this form of mobility to scale to
billions of EID prefixes / micronets.

We can't be precise about any of this, but I think rough consensus
on some or all of the above would enable us to be clearer about how
ambitious our solution should be - in terms of the complexity and
cost of the technology and how fast we are expecting it to be adopted.

For instance, one person might think we need to start deployment in
2011 and have 70% of small to medium sized end-user network address
space managed by the new system by 2014, with the solution not being
needed or suitable for corporations or universities, or for mobile
devices.  This is rather different from someone else who thinks it
will be acceptable (or we can't possibly do better than) adoption in
the 2014 to 2020 period, with the solution being attractive for most
universities, corporations etc. and also attractive and scalable to
billions of mobile devices.  (The latter is my view, ideally with an
earlier time-frame.)

My view of urgency is probably similar to Tony Li's:  that there is
no sudden crunch time.

I think the routing scalability problem is something we need to
resolve for IPv4 at least in the next five years or so, in order
that most end-user networks will find it attractive to use the new
system by about 2015 or so.  I think that gives us time to "Do It
Right" - where "It" is something like the optimal approach to
map-encap, including that architecture being extendible to support
TTR-style mobility.

I described my vision of the scope of "It" in the last 3 paragraphs of:

   http://psg.com/lists/rrg/2008/msg01374.html

However rather than excluding the discussion of longer-term
architectural enhancements from the RRG, perhaps it would be best to
continue those discussions so we have a clearer vision of where the
RRG-recommended architectural enhancement will fit into the
long-term development of the Internet.

  - Robin


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg