[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Convergence - design-goals-01: IPv4 utilization, portability



Short version:

I think the Design Goals could be improved in terms of terminology
eg. "control plane" and to include the following goals:

  Portability       Since many end-users want this and since ITR-ETR
                    schemes do provide it, it should be one of the
                    goals.

  IPv4 utilization  I see this as being inextricably entwined with
                    successful resolution of the IPv4 routing
                    scalability problem.  Therefore, it should be
                    a core goal, rather than simply a goal which
                    is inferred, depending on how the solution to
                    the scaling problem is understood.

  Mobility          Since efficient, low path stretch mobility
                    would be a huge benefit to many end-users in
                    the future (a bit like trying to imagine
                    cell-phone demand in 1975), and since at least
                    one ITR-ETR scheme (Ivip) is intended to provide
                    this, mobility support should be an

                    "additional", or "good if we can get it too"
                    goal.

David Meyer wrote:

> At the RRG meeting on Monday we talked a bit about
> this ("convergence"). IIRC, Tony mentioned the
> design-goals document (draft-irtf-rrg-design-goals-01.txt)
> as a source of evaluation criteria. My concern is that
> there is not enough detail in the draft to form the basis
> of a decision process (which ever one we use, which is
> another question).
> 
> So my question is: Do folks feel that this document
> contains sufficient detail (at least to a first
> approximation) to make an informed decision, and if not,
> how do we plan to do to obtain that detail? 

I think it would be good to discuss the current draft and devise a
more comprehensive version of it.

On 14 July I wrote a critique:

  http://psg.com/lists/rrg/2007/msg00199.html

but there was no follow-up messages, and I don't recall any other
critiques.

I think there are improvements to be made in terminology.  I also
think that since ITR-ETR / map&encap schemes provide portability of
addresses (apologies to Brian and others who wince at this phrase)
that this should be a goal as well.

Portability with sufficient speed of updates - as Ivip is intended
to achieve - would enable a new and previously unanticipated support
mechanism for mobility.  So if there are two proposals with roughly
the same benefits in other terms, but one is clearly better for
supporting mobility, I think the Design Goals document should
provide a basis for choosing the one with the mobility benefits.

Another criteria or goal I think the Design Goals should contain is
the better utilisation of IPv4 address space.  My July critique
doesn't mention this.  There is a range of opinions on how much more
can be achieved - and I guess some people don't care much, since
they see IPv4 as a dead end anyway.  Geoff Huston estimates
utilization of 5 to 20% of currently advertised space.  Even 20%
leaves room for a factor of 2 or 3 improvement, at a time when we
are supposedly running out of IPv4 space.

Essentially every Internet user relies on IPv4 - and will continue
to do so for years to come.  All ITR-ETR schemes enable finer
divisions of address space than BGP, and therefore enable the
provision of multihomable address space in increments suitable for a
large number of end-user networks who don't need hundreds or
thousands of addresses.  By the time the ITR-ETR scheme is
implemented, there will be a huge demand for better utilization of
IPv4 address space.

There was recent discussion of this in the "IPv4 shortage, new
features and IPv6 inevitability" thread.

To most technically inclined Internet folks, the IPv4 address
shortage is the biggest problem facing the Net - not so many know
about the routing scalability problem.  Getting the ITR-ETR scheme
developed and implemented ASAP is challenging.  I think we could get
more widespread support for the new scheme if it has as one of its
explicit goals the better utilization of IPv4 space, both for more
hosts and for more multihoming (and portable) end-user networks.


The routing scalability problem is a slow-burning problem which is
sure to burn much faster when the IPv4 address crunch happens,
because without an ITR-ETR scheme, there will be increased slicing
and dicing with BGP, greatly increasing the growth in the number of
advertised prefixes, as people start hacking their larger
allocations into smaller pieces - just like rural land being
subdivided for suburban house lots.

So I see solution to the IPv4 routing scaling problem being tied
inextricably to the ability of a new scheme to accommodate large
numbers (millions) of mulithomable, portable (and perhaps
mobile-capable) end-user networks without each one having their own
BGP advertised prefix.

I think there was a message from one of the LISP team which
supported my view that LISP could be used to increase the
utilization of IPv4 space - but I don't recall which message it was.

 - 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