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

From: Robin Whittle <[email-masked]>
Date: Wed, 28 May 2008 11:54:23 +1000

This will no-doubt displease some folks, but here is a set of points
which I think we need to agree upon soon in order to make sufficient
progress to achieve a useful recommendation in March 2009.

Without such agreement, or something similar, I think we would waste
time arguing about:

   a - A solution which involves significant host changes - and
       therefore which could never be implemented in a reasonable
       time-frame.

   b - Router based translation schemes which can't be practical for
       IPv4.  http://psg.com/lists/rrg/2008/msg01314.html

   c - The prospects for near-term (next 5 years or so) widespread
       adoption of IPv6 - because we haven't formed a clear
       consensus that we need to solve the IPv4 routing scaling
       problem directly, but think it could or should be solved by
       mass migration from IPv4 to IPv6.

Here is the rough list of points, all of which have been discussed
in greater detail in recent days:

1 - The scope of the RRG's work should focus on IP addresses and
    network based solutions - involving new router functions
    and/or new network elements.  The solution should not involve
    any changes to host stacks or applications, except perhaps
    to optimise performance which is degraded by the main solution.

    Discussion of longer-term architectural solutions involving
    changing or underpinning existing host-level protocols -
    necessarily involving changes to host stacks and/or
    applications - should be directed to another forum.

2 - The solution must work for IPv4 and IPv6 and show promise
    for being adopted by the majority of end-user networks
    in the 3 years following deployment, such as in the 2012 to
    2015 time-frame.  While this adoption will be supported and
    encouraged by administrative and perhaps business arrangements,
    the primary reason for adoption will be the immediate benefits
    to the ISPs and end-user networks.

(We don't have a good definition of "end-user networks", but I
suggest it should include all sizes - existing and new - including
single-host networks: from the largest universities and corporations
down to individuals on DSL lines and with cell-phones.)

3 - The solution must provide portable address space for
    end-user networks without impacting the scaling of the
    current BGP routing system.  (The map-encap schemes do this.)

4 - As already agreed, the solution needs to support multihoming
    and traffic engineering in a scalable fashion.

  - Robin           http://www.firstpr.com.au/ip/ivip/

--
to unsubscribe send a message to [email-masked] 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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 May 2008 10:11:39 +1200

Robin,

>        therefore which could never be implemented in a reasonable

We'd certainly waste time by arguing about it as an abstract principle.
But there is evidence that new TCP/IP stacks can be rolled out in the
major operating systems on a timescale of a few years, so I would be
prepared to consider a solution that includes incremental roll-out
to hosts. I think we agree that we're unlikely to invent a solution
that solely depends on that, however. In any case I suggest it's
already off the research table, since shim6 is already in the IETF
process, so not worth discussing here.

>        IPv4.  http://psg.com/lists/rrg/2008/msg01314.html

I think it's pretty clearly established that, due to the shortage
of IPv4 prefixes, either map-and-encap or pure NAT is *required*
for IPv4, iff we believe that the remaining scaling of IPv4 usage
will actually exceed BGP4 scaling capability.

However, I would observe (even as a well-known NAT hater) that we
have *already* broken the IPv4 transparency model by widespread use
of NAT. So one can legitimately ask: does it really matter if we
break IPv4 transparency even more by deploying much more NAT?

What I'm getting at is that it doesn't follow that we need the same
solution for IPv4 as for IPv6. We could consider "doing it right"
for IPv6 and struggling on with NAT for IPv4. (I can't believe I
just wrote that ;-( )

>        mass migration from IPv4 to IPv6.

I haven't used the word 'migration' for years in that context. The model
is very clearly one of long-term *coexistence* of v4 and v6. So
v6 deployment is definitely not an excuse for ignoring v4 scaling.

>     to optimise performance which is degraded by the main solution.

I mainly agree with that. Some host based approaches (shim6 and sctp)
are already in standards development. However, I think we should
have ILNP on the radar screen.

>     to the ISPs and end-user networks.

See above comment re different solutions for the two cases.
>     current BGP routing system.  (The map-encap schemes do this.)

I don't agree. The desire for "portable" prefixes is an artefact of
IPv4 experience. Let me reformulate.

     The solution must allow the option of provider-independent
     address space and the option of multiple provider-dependent
     address spaces for end-user networks...

I don't think we should constrain the future in a way that IP does
not do today.

>     and traffic engineering in a scalable fashion.

Yes.

    Brian

---

From: "Fleischman, Eric" <[email-masked]>
Date: Wed, 28 May 2008 15:38:22 -0700

From: Brian E Carpenter [mailto:[email-masked]] 

>But there is evidence that new TCP/IP stacks can be rolled 
>out in the major operating systems on a timescale of a few 
>years, so I would be prepared to consider a solution that 
>includes incremental roll-out to hosts. I think we agree 
>that we're unlikely to invent a solution that solely depends 
>on that, however. In any case I suggest it's already off 
>the research table, since shim6 is already in the IETF 

Brian,

I'd like to point out that an large number of embedded system devices
are increasingly using IP networks for their communications. While I
don't disagree with your observation concerning  traditional computers
(except regarding critical legacy systems, which can somehow manage to
hang around for decades), I do want to push-back against any notion that
we can afford to ignore embedded systems when we consider future routing
issues. Admittedly I am perhaps too close to this issue to have a
correct perspective, but this closeness does provide me with some
awareness of the (many) differences between networked computers and
networked embedded systems. 

--Eric

---

From: Randall Atkinson <[email-masked]>
Date: Wed, 28 May 2008 16:26:52 -0700

Earlier, Robin wrote:
% Here is the rough list of points, all of which have been
% discussed in greater detail in recent days:

"Discussed...in recent days" is very substantially different
from "Rough consensus is evident".

I would submit the discussion so far has mainly highlighted
a LACK of rough consensus on a wide range of issues.

(Obviously only the co-chairs are empowered to formally
measure consensus.)

Cheers,

Ran

---

From: Robin Whittle <[email-masked]>
Date: Thu, 29 May 2008 12:38:37 +1000

I am replying to Brian and Ran, but also mention Lixia's request to
end discussion of whether we only need to develop an IPv6 solution.

> process, so not worth discussing here.

I understand that over a period of years, there is scope for new
features in the major operating systems and that these can often be
integrated into running systems via the regular update mechanism.

However I feel certain that this falls far short of the complete,
rapid, painless, upgrade capability which would be required for the
great majority of end-user networks to be able to adopt a solution
which required host changes.

This is particularly the case with the various "embedded" devices,
and the old servers, old routers, which are surely a part of most
end-user networks.  There is more to networks than modern desktop
PCs, servers and routers.

There are printers, various special purpose devices including
hardware to do firewall functions, managed switches, NAS boxes, WiFi
devices, VoIP boxes, UPSes.  These are generally not amenable to OS
upgrades and there is no way of automating their reconfiguration if
their address needs to change.  While not all of these might need to
be accessible via the Internet, they may well be on addresses which
depend upon the public address range the network uses.

I think any solution which does not provide portable space for
anyone who wants/needs it will not be adopted widely enough to solve
the routing scaling problem.

It doesn't matter if we think portability is not a need - if a
significant number of end-users feel they want or need it, they will
fail to adopt solutions which do not provide it.

I guess we can't succeed in solving the routing scaling problem if
more than about 10% or so of end-users (including the largest
corporations and universities) do not find our solution attractive.

The proportion of end-user networks (from the largest corporations
to home-office users) who can't or don't want to fully upgrade their
OSes in all their devices and/or who need/want portability is vastly
more than 10%.

> will actually exceed BGP4 scaling capability.

Does this mean you agree with my argument that router-based
translation (such as Six/One Router) cannot be a solution in IPv4
because it could only work with duplicate address ranges?

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

The last part of your statement is preceded by an IF, as if we don;t
know whether we have consensus on it:

> iff we believe that the remaining scaling of IPv4 usage

I believe this statement is true, since I think there is no chance
in the foreseeable future of mass migration to IPv6, and because I
am sure that there will be more and more end-user networks in IPv4,
as address space is utilized more intensively - with more and more
DFZ routes.  I think this is worth stating as something we might
achieve consensus on.

   We expect the continued use of IPv4 will result in further growth
   in the DFZ routing table and/or insufficient provision of
   multihoming, TE and portability (or ease of choosing another
   ISP) to end-user networks which require it.  So we must provide a
   direct solution to the IPv4 routing scalability problem.

However, Lixia asked to put a stop to the thread "We can't bet the
Internet on the imminent adoption of IPv6".  I wrote that thread
because of my impression that Tony, Ran and Iljitsch thought we
didn't necessarily need an IPv4 solution:

   http://psg.com/lists/rrg/2008/msg01326.html
   http://psg.com/lists/rrg/2008/msg01329.html
   http://psg.com/lists/rrg/2008/msg01344.html

Perhaps if the co-chairs declared we have consensus that we need an
IPv4 solution, that would do the trick.

> break IPv4 transparency even more by deploying much more NAT?

I think more use of NAT and perhaps double NAT is inevitable.

Whatever we think about the lost end-to-end transparency, I think
virtually all end-user networks would choose to stay with IPv4 NAT
rather than try to survive on IPv6 addresses with some ugly and/or
non-existent approaches to getting their hosts and applications
interworking with the IPv4 Internet.

> for IPv6 and struggling on with NAT for IPv4. (I can't believe I

I agree entirely.

I thought that the lack of urgency for IPv6 meant we could learn
something, as we inevitably will, from widespread map-encap
deployment in IPv4 before deciding what to do with IPv6.  However,
as you suggest, we could use the extra time to be more ambitious
with IPv6 - to design something much better than IPv4's (I assume)
pure map-encap solution.

Since the installed base of IPv6 would still probably be very low,
the more ambitious solution could include host changes - to the OS
and applications - without major problems.  Even in 2015, I think
IPv6 deployment will only be for specialised purposes, and will
remain a tiny fraction of a percent of IPv4 deployment.

It may be an elaborate enough alteration to warrant bumping the
version number up, while making it not too painfully different from
IPv6.

> v6 deployment is definitely not an excuse for ignoring v4 scaling.

I agree.

> have ILNP on the radar screen.

Ran's Identifier Locator Network Protocol for IPv6 only:

   http://tools.ietf.org/html/draft-rja-ilnp-intro-00

I understand you favour no host changes for the IPv4 solution but
would contemplate them for the IPv6 solution.

SCTP is for both IPv4 and IPv6.  Does anyone have an idea of how
widely it is being used?  I guess it is still early days with
applications, since it will be a while before sufficient OSes
support it.

> See above comment re different solutions for the two cases.

So perhaps you would favour the RRG adopting two parallel strands of
discussion:

  1 - For the more immediate, no host changes, IPv4 solution.

  2 - A more ambitious, longer-term, IPv6-only solution.

I think this would be a good approach, and that we should
concentrate on the IPv4 solution, whilst doing some useful
preliminary work on a reasonably compatible (with the IPv4 solution)
longer term solution for IPv6.

That sounds like a better idea than what I proposed above: excluding
longer-term discussion from the RRG.

Does IPv4 scalable routing solution deployment in 2012 to 2105 sound
about right?

> I don't think we should constrain the future in a way that IP does

I think we should constrain any solution for the foreseeable future
(the IPv4 solution) to require provision of portable space to all
end-user networks which want it, because:

1 - Many or most networks want/need it - and we must get the great
    majority of new end-user networks, and probably the majority
    of existing networks, to to adopt our solution in a few years in
    order to solve the IPv4 routing scaling problem.

2 - No-one has any proposal other than portability which works for
    most of today's networks, in which raw public IP addresses are
    found in config files all over the network, and which are
    also programmed into some embedded devices which will never
    be amenable to any automated update system.  (The security
    and robustness requirements of any centralised IP address
    alteration system are really daunting - my guess is it will
    never be achieved to the satisfaction of most end-user
    networks.)

Since there is not so much urgency finalising and deploying the IPv6
solution, and since a more elaborate solution for IPv6 could
contemplate host changes, and to have the new mechanisms built into
the OS, applications and embedded devices in the future, I would not
entirely oppose some automated renumbering as an alternative to
portability for IPv6.

However, if the IPv6 solution is going to involve map-encap, then
that provides perfectly portable space anyway, without the concerns
of the past.  So it may just be easier to accept portability as the
easiest way of reducing the pain of renumbering - by removing the
need for renumbering entirely.

The simplest and most robust approaches (in my opinion - map-encap)
to multihoming and mobility involve fast portability.  Slow
portability - a scalable form of PI space so there is no renumbering
when changing ISPs - comes naturally with the map-encap approaches
to multihoming and mobility.

>>     and traffic engineering in a scalable fashion.

OK.

> from "Rough consensus is evident".

I didn't mean "rough consensus is evident".  I wrote I thought it
would be good if we did agree on these things.

> a LACK of rough consensus on a wide range of issues.

Indeed - but I am happy to agree with Brian on some things!

> (Obviously only the co-chairs are empowered to formally

Yes.  I wasn't trying to say we had consensus on anything, except a
few days ago in which I wrote that I thought we all agreed that
since the RRG and the IETF etc. has only limited ability to persuade
end-users to do anything, that our solution needs to have immediate
benefits if it is to be widely enough adopted to solve the routing
scaling problem.

  - Robin

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 29 May 2008 05:29:56 -0700

>> v6 deployment is definitely not an excuse for ignoring v4 scaling.

True words - and if we take care of IPv4 routing scaling the
right way IPv6 routing scaling should take care of itself.

Fred
[email-masked]

---

From: Scott Brim <[email-masked]>
Date: Thu, 29 May 2008 17:31:24 -0400

>      address spaces for end-user networks...

It doesn't even need to do that.  It should allow multihoming and easy 
migration from one point in the topology to another.  How it does that 
is an open question.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 May 2008 14:24:48 +1200

> migration from one point in the topology to another.  How it does that

Please add to that: must allow stable network management (including
asset databases, monitoring and diagnostic systems, etc.). While I
dislike the phrase "portable address space", I think that argues
strongly for stable (i.e. PI) space as an operational matter, but in
an IPv6 world, that does *not* mean it's the only address space in
use. It's running code to use different IPv6 prefixes for on-site
and off-site traffic. I'm just concerned that we don't allow the
shortage of IPv4 prefixes to constrain our thinking about IPv6.

    Brian

---

From: Robin Whittle <[email-masked]>
Date: Sat, 31 May 2008 12:38:25 +1000

Hi Scott,

You wrote:

Robin >>> 3 - The solution must provide portable address space for
Robin >>>     end-user networks without impacting the scaling of the
Robin >>>     current BGP routing system.  (The map-encap schemes do
this.)
Brian >> I don't agree. The desire for "portable" prefixes is an
Brian >> artefact of IPv4 experience. Let me reformulate.
Brian >>
Brian >>    The solution must allow the option of
Brian >>    provider-independent address space and the option of
Brian >>    multiple provider-dependent address spaces for end-user
Brian >>    networks...
>
> It doesn't even need to do that.  It should allow multihoming and
> easy migration from one point in the topology to another.  How it
> does that is an open question.

I think that neither you or Brian have addressed my arguments:

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

The question of how to enable end-user networks to easily choose
another provider has been around for two decades or so, AFAIK.

In that time, the only solution which has been developed which meets
the needs of end-user networks is portable address space - PI space.

Despite the elaborate and impressive nature of the automatic host
address functions in IPv6, this falls a long way short of the
requirements to reliably, securely, change IP addresses in
configuration files of various daemons, ACLs etc, in various
embedded systems, and in DNS zone files.  (I am not sure that every
end-user network would want to use this automatic host numbering
system.  Perhaps some or many networks need better security and more
explicit control.)

In the long-term, I agree, this remains an open question.

My argument is in the context of the RRG's timetable of coming up
with a reliable, promising, architectural recommendation in March 2009.

19 months after RAWS and 10 (9?) months before deadline, I argue
that we need to settle on portable address space as the solution for
end-user networks' need to change to another provider without
unreasonable cost, disruption and risks.  By doing this we can avoid
spending any more time on any solution which doesn't provide
portability.  I believe the solution should provide portability for
the largest end-user networks such as universities and corporations,
to the smallest, including home-office users and single-host
potentially mobile devices.

Do you think we can come up with any solution for this old problem
other than portability, in the next 9 months?  If so, what would
such a solution look like?

Alternatively, do you think it is reasonable to hold our breath on
this important question as if it could be solved in any way other
than portability?

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 which are the cause of the long-held
objections to portability.

  - Robin

---

From: [email-masked] (Noel Chiappa)
Date: Sat, 31 May 2008 11:12:52 -0400 (EDT)

> From: Robin Whittle <[email-masked]>

    > another provider
    > ...

Within the current IPv4/6 architecture, crippled as they both are with only
one namespace, yes.

    > we need to settle on portable address space as the solution for
    > end-user networks' need to change to another provider
    > ...
    > 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'.

On its own, PI address space is about as useful a 'solution' as a
peanut-butter-and-jam sandwich is without the bread - i.e. a total
^%&^%*@&#%@$ useless mess.

	Noel

---

From: Robin Whittle <[email-masked]>
Date: Sun, 01 Jun 2008 13:15:08 +1000

Hi Noel,

> - the former being something that some people somehow seem to think is a

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