Re: [rrg] draft-narten-radir-problem-statement-05.txt

[Robin Whittle <[e-mail]>]

Hi Thomas,

In a recent message:

   Scalable routing & architectural enhancements
   http://www.ietf.org/mail-archive/web/rrg/current/msg06099.html

I described my understanding of the routing scaling problem and some
other problems which I think would ideally be solved as part of the
"once in several decades" architectural enhancements to IPv4 and IPv6
which will be required to solve their routing scaling problems:

   IPv4 address shortage and need for higher rates of utilization.

   Mobility (both IPv4 and IPv6).

   Security of hosts against attacks (probably can't be solved with
   any network enhancement).

   Combating DoS and other network-based attacks.

   Path MTU discovery and packet length limitations


Here are some thoughts on the RADIR Problem Statement.


  - Robin




The history of the RADIR Problem Statement ID is:

  00  2007-07-26
  01  2007-10-09  Various changes, mainly to terms and summary.
  02  2008-10-17  No changes.
  03  2009-03-09  Minor changes, I think.
  04  2009-12-15  No changes.
  05  2010-02-17  Minor changes, I think.

I commented on version 00 on 2007-08-09:

  http://www.ietf.org/mail-archive/web/ram/current/msg01809.html


Also of potential interest is the RRG Goals ID, which has been in
version 01 since 2007-07-08, after relatively few discussions:

  http://tools.ietf.org/html/draft-irtf-rrg-design-goals-01

I commented on it on 2007-07-14:

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

but there have been no updates and little or no discussion of this
ID.  Tony confirmed recently that these goals did not represent
consensus and were subject to further revisions:

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


There is a page the RADIR folks might be interested in - my attempt
to describe the constraints we face due to the need for widespread
voluntary adoption:

  http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/

I think this may be relevant to your section 3.3 Alignment of Incentives.


Section 3.3 states "there are millions of potential end sites which
would benefit from being able to multihome".  Brian Carpenter and I
recently, independently, nominated 10 million as a rough upper limit
on the number of non-mobile network which want or need portability,
multihoming and/or TE (though perhaps Brian didn't mention
"portability".  My reasoning was roughly that with human population
of 10 billion, there will probably be only one organisation per 1000
people (mainly small companies, but also schools and other
organisations) which have sufficient need of portability or
multihoming to get "edge" space in a CES system and to get the two or
more physical links from two or more ISP's services as needed for
multihoming.


I think the Problem Statement's references to "4.3. End Site
Renumbering" and to certain extent to "4.4. Acquisitions and Mergers"
 could be improved by reference to address space "portability".  The
word "portability" does not appear in the Statement, and while I
think it makes some people's teeth itch, I think it should be mentioned.

The problems mentioned in these sections arguably only exist because
only PI space is "portable" and that when splitting even this
portable space into two separately advertised PI prefixes is
possible, this contributes to the routing scaling problem.

Core-Edge Separation architectures provide a new subset of the global
unicast address space which is portable in a scalable manner, and
which can be split up much more finely than the /24 limit which
applies to conventional PI prefixes.

So I think it would be reasonable to describe a key part of the
routing scaling problem as being due to the lack of portability for
any scalable form of address space in the current system.

  - Robin