Subject: [RAM] RADIR Problem Statement: timeframe, portability, mobility, FIB etc.

From: Robin Whittle <[email-masked]>
Date: Thu, 09 Aug 2007 12:56:35 +1000

I am replying to Thomas Narten and Brian Carpenter, regarding

http://www.cs.duke.edu/~narten/ietf/draft-narten-radir-problem-statement-00.txt

and their messages from the "Renumbering impossibility: TSL/SSL
certs, DNS delegation etc." thread:

   TN (Re: Renumbering impossibility: TSL/SSL certs, ...)
   http://www1.ietf.org/mail-archive/web/ram/current/msg01785.html

   BC (First cut at routing & addressing problem statement)
   http://www1.ietf.org/mail-archive/web/ram/current/msg01786.html

These were responses, in part, to my suggested rewrite of section 6
of the draft Problem Statement:

   http://www1.ietf.org/mail-archive/web/ram/current/msg01773.html

"End-user" in this message refers to those end-users with networks
which need multihoming, TE and/or portability of their network's
address range between ISPs.

Hi Thomas,

You wrote, in part:

>> In that thread I argue that the RADIR Problem Statement should
>> not be written as if there was even a slight possibility that new
>> technologies could make today's networks reliably renumbered by
>> some automated means.
>
> Why is it important to do this? If it is feasible to do this, we
> shold. If it is not, we won't. Trying to rule it out as a
> possibility from the problem statement point of view makes no
> sense (IMO).

I am sure that there is no prospect whatsoever of end-user's genuine
needs for multihoming - or for ease of using another ISP - being met
by some other mechanism than portability of their own address space.

I don't think that you or anyone else has an argument as to why
end-users would be happy with any conceivable mechanism other
than portability.

So by re-framing the Problem Statement to ignore this idea, I don't
think you would be ruling out a possibility.

It would be marvellous if mathematicians found more than 4 billion
combinations of 32 bits . . . but since we all agree there is no
possibility of this occurring, there is no point in an IPv4 addressing
problem statement being written as if it was a possibility.

> The purpose of the problem statement is to define the problem, and
> not rule out _any_ solution, so long as it addresses the problem.

I am certain that there is no solution to Multihoming or ISP choice
other than portability.

Are there any network operators on the list who disagree with this?

> (And no, I'm not about to argue that getting automatic/painless
> renumbering is about to happen. But let any proposed solution in
> that direction be evaluated  on its merits please!).

I am evaluating "automatic/painless renumbering" it on its merits -
its merits amount to zero.

So let's not pretend that perhaps, by some new technique no-one has
stumbled upon in all these years, there might be a technical
approach which would make network operators happy to have their
entire network suddenly renumbered the moment one multihoming link
goes down, or that could provably make some automated renumbering
system work flawlessly on a huge variety of networks in existence
today, for which there is no clear enough definition to even start
designing such an automated system.

> It's much more productive to focus on solution aproaches that folk
> think might be viable, than spending cycles trying to rule out
> approaches that aren't being pushed very heavily...

There is no reason to think that "automatic/painless renumbering" of
today's networks might be viable.

Because such a thing would be really highly desirable (from the
point of view of having end-user networks use PA space so we don't
need to have unconstrained growth in the global BGP routing table or
alternatively have to create out an architecture which supports
genuine portability), some folks tend to think it "might be viable",
despite everyone else being adamant that it is impossible, and will
forever remain so.

The reason it is not being pushed very heavily is because the only
people who want it are not the end-users, but those who want to keep
end-users using PA space for the convenience of not having to design
and run the Internet in a way which genuinely supports end-user needs.

If this is a blue-sky, no deadline, Problem Statement then I think
you can include "automatic/painless renumbering" as a design goal.
With no deadline, you can easily make part of the solution a new set
of standards to which all future networks and their devices and
software must comply.  Whether anyone living now will ever see such
an architecture become widely adopted is highly debatable.

What is the timeframe of the solution this Problem Statement
describes the properties of?

In a recent message

  TN (Re: Renumbering impossibility . . .)
  http://www1.ietf.org/mail-archive/web/ram/current/msg01803.html

you wrote:

> I don't believe putting in a concrete timetable is possible.  My
> sense from having participated in many discussions with many
> different people is that there just is no concensus on this point.

My understanding of what the RRG and this RAM list is working on is
how to create an addition to the current architecture which will:

  1 - Solve or significantly help with:

      a - Unconstrained growth in the number of advertised routes
          while supporting growing number of end-user networks
          which have multihoming, TE and portability (often referred
          to as "automatic/painless renumbering").

      b - Enable better use of IPv4 space to accommodate more
          end-user networks, more actively used IP addresses etc.
          (This is the most urgent crisis, but it seems most folks
          just accept that nothing can be done.  I think LISP/
          eFIT-APT/Ivip could all make significant improvements.)

  2 - Be incrementally deployable.  This rules out any proposal
      which requires changes to hosts - including switching to
      IPv6.

  3 - Not restrict the adoption of mobility, future architectures
      etc.

I think RADIR needs to define the timeframe.

Are you trying to define a new architecture for the future to which
all users will ultimately migrate?  That is a fine goal, and
involves less constraints - because you don't need to be backwards
compatible.  Instead you need to define a much better end-point and
devise the technical and business aspects of how and why people will
progressively adopt the new architecture.

Or are you looking for a solution which could start to be deployed
in 2010 and be widely adopted - with major, lasting, benefits -
around 2104?

I am working on the latter.

> TO make predictions, one has to make assumptions about future
> growth and trends that we have little confidence in, and that
> different people have very different views on.

Sure, but does the 9 person RADIR Directorate:

  http://www3.tools.ietf.org/group/radir/

have a consensus?  You can't be constrained by trying to agree with
everyone else.

If you can't agree among yourselves on whether your Problem
Statement should be for near-term (3 to 8 years, benefits for IPv4
and IPv6, no host changes) or for some future architecture (15 to 30
years), then maybe you should make a separate Problem Statement for
each timeframe.

> I'm not sure it makes sense to ask whether a "patch" or an
> "architecture change" is the way to go. IMO, the right answer is
> that we go with a solution that solves the problem in a meaningful
> way, and that we believe can actually be deployed.

Assuming you mean "deployed in 3 to 8 years time" I think this rules
out changes to IPv4 hosts and to considering "automatic/painless
renumbering" as a possibility.

> Whether or not that involves an "architecture change" or not is
> sort of an academic point.

I think improvements to BGP does not constitute "architecture change".

I think that having a significant amount of the address space only
reachable via a LISP/eFIT-APT/Ivip ITR-ETR mapping system is a
significant architectural change, but it is not switching all users
over to a completely new architecture.  It is like building another
few storeys on a building.  The old building is still there, but
people who use the building generally need to use the new addition
as well.  That addition is not going to go away in the future, so it
needs to be planned in a way that doesn't preclude whatever
important additions will be needed in the future.

> Let's see proposed solutions please, evaluate them on their
> merits, and then chose the approach that makes the most sense.

I have a proposed solution with the Ivip I-D:

  http://www.firstpr.com.au/ip/ivip/
  http://tools.ietf.org/html/draft-whittle-ivip-arch-00

You responded to some of my message, but not beyond the middle of my
point 2 in my proposed rewrite of your Section 6.  That was 11 days
ago - 29 July:

  http://www1.ietf.org/mail-archive/web/ram/current/msg01773.html

I would be interested to know what you and other RADIR people
thought of my proposed points 2 to 10.  (There is no point 3.)

>> As far as I know, this notion of IPv6 end-users supposedly being
>> happy with PA space and automated renumbering has been going on
>> for ten years or so.
>
> Um, AFAIK, people have NOT been making this argument.

I think you are arguing that it is possible that at some time in the
future (the so-far unspecified timeframe of the Problem Statement)
that IPv6 end-users will be happy with automated renumbering.

Hi Brian,

You wrote:

>> We would welcome comments on the document. In particular:
>>
>>  - Do folk agree with the problem statement as written, or are we
>>    missing something fairly fundamental?
>
> Yes. I think it's correct to keep it down to the bare bones.

But why make it some arbitrary length?  The proposed changes are so
extensive and will affect all Internet users forever.  This is a
very difficult set of problems to solve.  Surely it would take a few
few pages text to properly describe the constraints which exist on
solutions, and goals we have for the next decade or two?

I know it is convenient to have a short problem statement, but what
if it leaves out important questions?  What if the omission of
certain criteria enables the selection of a solution which won't
work, or which is far worse than a solution which would only have
matched a more rigorous and longer statement, or which prevents us
from achieving some other important goal we easily could have left
ourselves open to?

The current statement doesn't have a timeframe.  Do you think it
should be aimed at IPv4 over the next five to ten years (which rules
out host changes) or is it aimed at developing a new architecture
which everyone will migrate to after IPv4 has become unworkable?

>>  - Are there other pressures on the routing system that we have
>>    not listed or described completely?
>
> Not that I noticed.

What about FIBs?  They are burning up R&D dollars, manufacturing
costs and electricity all over the world.  All Internet users pay
for this.

Surely there is a difference between an architecture which handles
packets with short prefixes rather than long ones.  It seems
monstrous to expect a router to chew through 48 bits on 50 low-key
little VoIP packets a second, with perhaps 15 or 20 routers en-route
performing these gymnastics.  (PI IPv6 space as /48s for end-users
is now part of ARIN, AfriNIC and RIPE policy.)

Likewise, there is a huge difference in cost and performance for
routers and therefore to some extent the working of the entire
Internet, between solutions which do the job with no tunneling (I
think there are no such solutions, other than a drastic BGP
improvement, which seems impossible) or simple tunneling (Ivip)
rather than with tunneling with nonces and other complex operations
and lots of CPU time (LISP and eFIT-APT).

The Internet is too complex for us to make it work better with a
Problem Statement which is as short as the current version.  I
suggested a bunch of additional things for Section 6, at the end of:

  http://www1.ietf.org/mail-archive/web/ram/current/msg01773.html

You critiqued these up to the middle of my new point 2:

  http://www1.ietf.org/mail-archive/web/ram/current/msg01775.html

and I responded to your critique:

  http://www1.ietf.org/mail-archive/web/ram/current/msg01779.html

but I haven't seen your response to this.

I corrected your misunderstanding that I meant more IPv4 end-users
and more IPv4 IP addresses being actually used would involve more
advertised prefixes.  The way to do it is with LISP/eFIT-APT/Ivip
etc. more finely dividing existing prefixes to serve more end users
and have hosts on more IP addresses than is possible with BGP's
slow, costly, coarse (256 addresses at a time) method of divvying up
the space.

I discussed how the more bits which need to be analysed in the FIB
the more time and power is required.  Surely we can't ignore FIB
difficulties when selecting a new architecture.

I was most perplexed when you wrote that you didn't think there was
consensus that the core of the problem involved what I tried to
describe:

  D.  The complexity and size of the RIB and the
      complexity and volume of inter-router communications.

Along with FIB difficulties and instability in the whole BGP system,
these are the major problems - all driven primarily by the growth in
the number of prefixes.  I thought there was consensus on this.

You didn't disagree with with my points 1F and 2, but said they were

> really getting more into desirable properties of a solution,
> rather than the problem.

and I responded that this is in keeping with section 6, which
defines the problem in terms of the properties of the desired solution.

You didn't specifically mention my suggested points 4 to 10.

>>  - We intentionally did not include improving mobility as a core
>>    "problem", as explained in the document. (That doesn't mean we
>>    don't recognize that some of the solutions under discussion
>>    may also be applicable to mobility scenarios. Rather, we tend
>>    to see improved mobility as a possible benefit of certain
>>    classes of solutions.)
>
> I think this is correct. In many ways mobility is an overlay
> on a routing system assumed to be stable and scaleable.

It depends . . .  if LISP or eFIT-APT are added to the Internet and
are regarded as part of the routing system, then they will get in
the way of the new techniques for supporting mobility which I
discuss in:

http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-arch-00.html#anchor81

If Ivip is regarded as part of the routing system (I am not sure
that it should be), then it does mobility as an integral part of the
routing system.

If you have a critique of these techniques, then please write about
it to the list.

I don't think it is right to support such a short Problem Statement
without adequately considering a bunch of constructive stuff which
argues that more things need to be considered when defining the
properties of a solution, which is the purpose of Section 6.

For instance, do you support this addition?

  10.  Either directly supports or at least does not preclude
       the use of the new architecture to be used for supporting
       Mobile IP in terms of greater flexibility, more optimal
       path lengths and communications with non-upgraded
       correspondent hosts.

 - Robin

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Aug 2007 14:35:10 +0200

Robin,

Briefly,

On 2007-08-09 04:56, Robin Whittle wrote:
...
> by some other mechanism than portability of their own address space.

"Portability" is a word I associate with cell-phone numbers. If you're
referring exclusively to IPv4, and to the class of mechanism described
in RFC 4116, then yes. But your argument does not apply a priori
to a scenario where address space and prefixes are plentiful. That is
why IPv6 was designed from the start on the assumption that sites
would have multiple simultaneous prefixes and hosts would have multiple
simultaneous addresses.
...
> problem statement being written as if it was a possibility.

Yes, but that isn't the problem statement being written.

...
> its merits amount to zero.

That's just polemic.

> goes down,

I'm not aware that anyone has ever suggested such a thing.

> or that could provably make some automated renumbering

There was certainly some thought about that in the early days of
IPv6 design, but it's clearly impossible, which is why RFC 4192
was written.

...
> and run the Internet in a way which genuinely supports end-user needs.

This also verges on the polemic. To be clear, we've spent >10 years
with the certain knowledge that the only way to avoid a BGP4 meltdown
is to aggregate prefixes, and the only way to aggregate prefixes is to
us PA space whenever possible (and I mean that strictly, i.e. not
merely whenever convenient or preferred).

Multi6 took that as a basic assumption and Shim6 (and I suppose Six/One)
takes that as a basic assumption. This wasn't an assumption adopted for
convenience; it was an assumption adopted to avoid meltdown. People thought
that would be even less convenient.

That's also why it would be pretty short sighted to hand out more than a
few tens of thousands PI prefixes, of course, unless we have a viable
solution in the LISP/iVIP/eFIT class ready to deploy. If this current
effort leads to such a solution, net convenience will increase. But the
problem statement cannot assume that such a solution can be found.

...
>> Yes. I think it's correct to keep it down to the bare bones.

I still think that. Short problem statements get read. Long
ones don't.

...
> but I haven't seen your response to this.

You won't. I will be mostly silent for the next month while
moving jobs and land masses.

     Brian

---

From: Robin Whittle <[email-masked]>
Date: Fri, 10 Aug 2007 12:42:26 +1000

Hi Brian,

Thanks for your response.

("End-user" in the following means end-users who need multihoming,
traffic engineering and what I try to describe, briefly, as
"portability" of the address range their network uses.)

> would have multiple simultaneous prefixes and hosts would have multiple

I don't think the end-user's need for "portable" address space is
related to the scarcity or otherwise of address space.

The end-user wants and needs to run their network without sudden
changes imposed by outside circumstances, such as the failure of a
multihoming link, or the business or technical failure of an ISP.
They also want and arguably need to be able to choose another ISP
for reasons of cost, performance etc. without having to do anything
disruptive or expensive to their network.

I think it is a good use of IPv6's vast address space to have
arrangements by which each host can have multiple IP addresses at
the same time.  Then SHIM6 or Six/One can use these to provide
multihoming.  SHIM6 does it without involving routers, but I think
it involves longer packets, with the extension header.  At least
this length is not added en-route and there are no problems with
Path MTU Discovery.  Six/One does it by involving routers, and I
think, without any extra headers - thanks to creative use of IPv6's
huge number of address bits.  However, I am not sure that Six/One's
rewriting destination addresses won't cause trouble for PMTUD.

Although there are better facilities in IPv6 for automated control
of router and host addresses, this doesn't solve the problem of
mobility - which ideally involves the host having one (or a stable
set of) address (or the mobile network one stable set of addresses)
no matter which provider network they connect to in a dynamic fashion.

For the major goal of multihoming, as far as I know, the only way
IPv6's "multiple addresses at once" approach can be used is SHIM6.

A decade after the guts of IPv6 was defined, SHIM6 is still not
finished.  This makes me think it is a difficult protocol to devise,
given its goals and constraints.

Even if SHIM6 was here today and universally implemented in all IPv6
stacks, it would not provide multihoming the way most end-user
networks want it.

My understanding of the needs of end-user network multihoming
requirements is that there must be a centralised, robust control
system.  Having to simultaneously control the multihoming behaviour
of hundreds or thousands of different hosts is not practical.

So the ten year long attempt at making IPv6 provide multihoming the
way most end-user networks want and need has not worked and will not
work.

If it had, or if anyone expected it to work sometime soon, then
there probably wouldn't have been the pressure to have IPv6 PI space
for end-users.  Likewise, if SHIM6 was expected to provide
multihoming which was acceptable to most end-users, I doubt whether
ARIN, AfriNIC and RIPE would have reversed long-standing policies
and decided to provide PI /48s to end-users.

The terms "portability" or "portable address space" are the
shortest, most accurate, terms for what I think end-users
(multihoming etc. end-users) need.

It is a delicate enough business getting all the software working on
one host, integrated with the external environment of nameservers
and all the other hosts which communicate with it.  It is also a
delicate business getting a whole network running, with all sorts of
different hosts, including some which don't have ongoing updates to
their operating systems and those which run applications which are
not completely up-to-date with recent RFCs.

There is no way an end-user with such a network can be sure their
network is going to keep running reliably if every host and router
needs to switch over to another address range.  IPv6 is intended to
facilitate this, but even when SHIM6 is finished and widely
implemented (2012?) it won't fulfil network multihoming needs
because this is a host-based, approach.

This seems to lead to portability as the only mechanism by which
end-users can get what they need for multihoming.  Portability is
also the only practical way of allowing painless switching to
another ISP.

Portability, if it can be done fast enough, is clearly the best
approach to mobility too - from the end-user's point of view.

> Yes, but that isn't the problem statement being written.

My point was that no-one mentions more than 4 billion IPv4 addresses
because everyone agrees it is not a possibility.

Thomas Narten and perhaps you seem to think that it is possible for
multihoming and free choice of ISP to be achieved without what I
call "portability".  I believe this is not a possibility.

My guess is that you hold on to the idea of it being possible
because if it were possible, you would be able to retain the
traditional and current Internet architecture without causing
unsustainable growth in the global BGP routing table.

I think you need to show why it is a possibility.  It doesn't matter
how convenient it would be for the rest of the Internet if it were
possible.  What counts is whether it is what end-users want and need
in order to run their networks reliably and without excessive costs
or other complications.

I think you need to show why end-users could find your
yet-to-be-developed solutions - which involve changing the addresses
of their networks - robust, fully applicable to their actual
networks and of sufficiently low cost that they would be about as
happy with this as with what they currently want: "portability" -
meaning their networks keep the same address space.

>> its merits amount to zero.

Yes, but at least it was brief!

What are its merits?

"Automatic/painless renumbering" (user networks adopting new
addresses) would have enormous merits for the Internet's routing
system because no further change is needed to the current routing
architecture.

But that doesn't matter unless you can show why this would be as
good as true portability for the people who need to run their
networks 24 hours a day without disruption or further complications.

What is the time-frame within which the techniques you hope for will
be developed and fully deployed?

If the discussion is about IPv4, then you can't rely on host changes
- because there is too much old stuff out there which can't and
won't be upgraded.  With IPv6, because it is so little used at
present, you can probably require host changes, but I think you need
to show how and why everyone would make these changes in the
timeframe you are proposing.

All such host changes need to support full backwards compatibility
with non-upgraded hosts for as long as any non-upgraded hosts remain
in use, perhaps until some far-off date where you nominate that
those hosts will no longer be able to communicate fully.

> I'm not aware that anyone has ever suggested such a thing.

SHIM6, when it is finished, should enable multihoming without this
sudden change of addresses, because each host will already have a
set of addresses from the PA space of each of the two or more ISPs
through which the end-user network is multihomed.  But this is IPv6
only, requires new host software in every host in the multihomed
network and in all correspondent hosts.  It doesn't exist yet and it
is not a router-centric approach, which I understand is what most
end-user networks want and need, rather than having to fuss over
every host.

Apart from this host-based, IPv6-specific, future possibility, as
long as you want end-user networks not to have "portable" address
space, then I think you are implying that when one link goes down,
the network must switch to using the address space which is
available on another link.

LISP/eFIT-APT/Ivip are intended to provide address space which is
genuinely portable between any ISP with an ETR.  Ivip is intended to
do this so fast that it will support mobility, with generally
optimal path lengths from all correspondent hosts, without upgrades
to those correspondent hosts, and for both IPv4 and IPv6.

All these schemes have significant problems to do with tunneling
overhead, breaking Path MTU Discovery etc.  But unlike SHIM6 they
give the end-user what they want and need.  (I think Six/One can do
multihoming with passive, not specifically controlled, hosts running
 suitable software - with the control being exercised at the
network's CE router.  So this may well provide the network-centric
control of multihoming which end-user's need.  Six/One's techniques
can't be applied to IPv4.)

With the possible exception of using Six/One for IPv6 only
multihoming, I don't think you can give the end-user what they want
and need as long as you can't give them "portable" address space.

> IPv6 design, but it's clearly impossible, which is why RFC 4192

Sections 3 and 4 consider some fundamental problems in implementing
this, such as with dedicated devices (VoIP phones) which are not
amenable to being upgraded to adopt the new addresses.  There are
also problems with securely automating DDNS and reverse mapping.

Six/One would need to be implemented in all a network's devices,
including phones and light switches, for it to be successful.

> merely whenever convenient or preferred).

But this "certain knowledge" is no longer true.

LISP/eFIT-APT/Ivip all provide portable address - applicable for
most of the purposes PI space is currently used for - without
directly involving or burdening the BGP routing system.  (LISP etc.
mapped space can't be used for running ITRs, ETRs or any server
which is part of the LISP/eFIT-APT/Ivip infrastructure.)

They are all a kludge, with various degrees of ugliness and various
amounts of new benefits, particularly in terms of the speed by which
end users can control the behaviour of the global network of ITRs.

If you and others had been successful in meeting the needs of
end-users (who need multihoming, TE and "portability" = ease of
switching to another ISP) by the use of PA space, then there
wouldn't be unsustainable growth in the global BGP routing table.

You haven't been successful.

The task was - and remains - impossible.

End-users with current network technology can only run their
networks reliably with stable addresses - and you can't provide that
with PI space. (Except that in the future SHIM6 or Six/One will be
able to provide multihoming for IPv6 within limits such as those
described above.)

That is why we now have a crisis in routing and addressing for which
the only potentially practical solution seems to be a kludge like
LISP, eFIT-APT or Ivip.

If RADIR wants to position its Problem Statement into the indefinite
future, to provide a new architecture to which everyone will happily
migrate within some time-frame - say 2020 or 2025 - with new host
and router requirements which support robust, easy, renumbering of
networks, then that would be great.   That would be worth working
for, rather than all this tunneling stuff and being stuck forever in
the constraints of IPv4.  In the meantime, I think there needs to be
another Problem Statement and potential solutions to get us through
to 2020 or 2025.

> that would be even less convenient.

The idea of this global ITR network and tunneling overhead is pretty
 horrible, I think.  The thought of the the BGP system progressively
failing due to stability, RIB or FIB limits being breached by the
number and length of advertised prefixes is much worse.

I think I fully understand the motivation for this assumption.
Unfortunately, by staying within the constraints of this assumption,
it has not been possible to meet the needs of end-users with
substantial multihomed networks (or those who want freedom of choice
between ISPs).  Nothing has changed.  Apart from SHIM6 or Six/One
there is no reason to think anything will change in the future.  It
was a noble effort.  But it didn't work and I think it is best to
recognise that it won't work in the future either - not through lack
of effort, but because the task is impossible.

> solution in the LISP/iVIP/eFIT class ready to deploy. 

Thanks for moving Ivip up the pecking order!

> If this current

This makes me think that you see the RADIR Problem Statement as
applying to a longer time-frame.

I think there are two timeframes.  Something like:

Short timeframe:

  Start                   2010
  Wide adoption           2015

  Last until at least     2025

  Apply to IPv4 without requiring host changes?   Yes

  Apply similar principles to IPv6 maybe with
  host changes?                                   Yes

  Must solve:       Million or more MH end-user networks
                    without further significant growth
                    in number or churn of BGP advertised
                    prefixes.

  Should solve or   Portability so end-user networks can
  at least not      freely choose ISP without any impact
  prevent solution  on their network.
  to:
                    Mobility with generally optimal path
                    lengths and fast (a few seconds, ideally)
                    user control of mapping to whichever
                    router is best for the mobile-node.

                    Increased utilisation of IPv4 address
                    space.

                    Migration to IPv6 or whatever new
                    architecture is optimal in the future.

Long timeframe:

  Start                   2020
  Wide adoption           2025

  Last until at least     2035

  Apply to IPv4 without requiring host changes?   No - may not
                                                  support IPv4 at
                                                  all, except by
                                                  some tunneling and
                                                  software hack for
                                                  IPv4 applications.

  Apply similar principles to IPv6 maybe with
  host changes?                                   Everything is up
                                                  for grabs, so IPv6
                                                  might be extended
                                                  or replaced.

  Must solve:       Million or more MH end-user networks
                    without further significant growth
                    in number or churn of BGP advertised
                    prefixes.

  Ideally solve:    Portability so end-user networks can
                    freely choose ISP without any impact
                    on their network.

                    Mobility for billions of devices -
                    probably each with the functional
                    equivalent of an IPv6 /64 with generally
                    optimal path lengths and fast (a few seconds,
                    ideally) user control of mapping to whichever
                    router is best for the mobile-node.

                    Get rid of kludgey LISP/eFIT-APT/Ivip
                    tunnels and ITR stuff.

> I still think that. Short problem statements get read. Long

If additions to the Internet architecture are designed by people who
won't read more than a few pages, then I think the outcome is likely
to be a mess.

The current draft's Section 6, which is what really matters,
contains 90 words, not counting the final paragraph which is a
qualification about what the section doesn't fully consider.

The text I proposed in:

contains 515 words, not counting the stuff in brackets.  That is not
exactly long - about 1.6 pages

My suggested text is for a short timeframe.

I think it would be helpful if the RADIR statement specified the
timeframe.  I think it should be clear to the reader whether the
intended solution is meant to support existing IPv4 hosts and
networks, or whether it is meant to provide a new architecture in
the longer term future to which all those users would ultimately
migrate.

I am proceeding on the basis that some people will devote the time
to understanding the problem in all its facets - including how some
solutions might support further benefits (eg. mobility) while other
solutions make such benefits harder to achieve.

Perhaps the solution properties should also include that each new
architectural element should be, to the greatest extent possible, a
building block which can be used with other building blocks, rather
than a monolithic system which contains fixed ways of dealing with
particular problems.

> moving jobs and land masses.

OK - that is a huge move.  Good luck with it.

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