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

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
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram