Re: [RAM] First cut at routing & addressing problem statement

Robin Whittle <rw@firstpr.com.au> writes:

> Here is a rewrite of the Problem Statement, focusing on
> "end-users" rather than "sites" and extending the goals in a
> number of ways which I think are achievable and highly desirable.

We intended the term "site" to be a fairly general term, one that
includes pretty much any topologically distinct thing that connects to
the internet. This includes home users. It is also NOT restricted to
just larger enterprises or ASes. We'll add a clarifying definition to
the document.

> I think the current version of the Statement is compatible with
> these two statements being true - but I think they are not true:

> 1 - That a new architecture could make renumbering robust
>     and sufficiently painless and free of costs and risks
>     that all end-users would, or should, be happy to get
>     new addresses whenever they choose a new provider.

If we could do this, then I think we have solved a core
problem. Whether or not the above is actually achievable is an open
question (and I recognize that many are skeptical).

But an important goal of the problem statement is to define the
problem and not rule in (or out) any particular solution approach up
front. If a proposed solution actually does addresses the problem (and
is deployable in practice), we should be happy. :-)

> 2 - That a new architecture cannot, or should not, enable
>     a much finer method of allocating IPv4 address space, to
>     accommodate more end-users with multihoming, portability
>     etc. - and that this cannot or should not be used to
>     enable a much greater number of end-users of all types,
>     (including those who don't need portability/MH/TE) to
>     use IPv4.

I'm not sure I'd go as far as the above. I think you may be making
some assumptions above that are not immediately obvious to me. But I
do agree that giving out smaller and smaller address blocks to
sites/users and expecting them to be routed in the DFZ makes the
problem worse rather than better.

> I am also keen to see the new architecture either directly support
> Mobile IP, or at least be compatible with future extensions which
> do so.  I mean an expansive view of Mobile IPv4 and IPv6, with
> correspondent hosts not requiring new software, and with close to
> optimal path lengths.

I think the document is clear on this point:

   The problem statement in this document has purposefully been scoped
   to focus on the growth of the routing update function of the DFZ.
   Other problems that may seem related, but do not directly impact the
   route scaling problem are not considered to be "in scope" at this
   time.  For example, Mobile IP [[RFC2002], RFC3775] and NEMO
   [[RFC3963]] place no pressures on the routing system.  They are
   layered on top of existing IP, using tunneling to forward packets via
   a care-of addresses.  Hence, "improving" these technologies (e.g., by
   having them leverage a solution to the multihoming problem), while a
   laudable goal, is not considered a part of this problem statement.

> For instance, the new architecture's ITR system could be used to
> create generally optimal paths to ETRs which are close to the
> mobile node.  This would enable correspondent hosts without any
> special mobile IP software to communicate efficiently with mobile
> nodes, including small devices (cell-phones and laptops) as well
> as nodes which connect mobile networks - for instance in passenger
> jets and trains.

I think you are now going into solution space, something the problem
statement document is trying very hard to avoid. Again, quoting from
the document:

   This document attempts to define the "problem", with the aim of
   describing the essential aspects so that the community has a way of
   evaluating whether proposed solutions actually address or impact the
   underlying problem or "pain points" in a significant manner.

Our view is that improved mobility is a "nice to have", rather than
critical requirement.

> I think the term "site" tends to imply a physical installation,
> largish network, etc.

Not our intention, per above.

> These are the only types of end-users who have the resources to gain
> ASNs, PI space etc. today.  However I think the new approach to
> routing and addressing can and should provide multihoming,
> portability and TE (for those with multihomed links) for a much
> larger number of end-users, including those who lack the resources
> to get an ASN, PI space etc.  In principle, I think the goals should
> be extended to apply to single hosts which are physically mobile,
> such as cell-phones, laptops etc.  I think the term "site" does not
> adequately capture that sort of end-user or the device, node,
> network etc. whose address space must support multihoming,
> portability and ideally mobility.

Again, you are now into desiring a better mobility approach.

> I am wary of the current state of point 4:

>    4.  Allows end sites to switch providers while minimizing
>        configuration changes to internal end site devices.

> End-users today need "portable" address space, because there is
> currently no mechanism for reliably and painlessly renumbering
> every aspect of their network.

> The current wording of point 4 only makes sense if a new routing
> and addressing architecture might be able to automate address
> settings so that end-users with all sizes of networks - including
> really large ones - could reliably, quickly and with little cost
> adopt a new address range when they change to another provider.

> I think this is an unrealistic hope and will remain so within the
> foreseeable future - most likely forever.

The point of the problem statement is to layout the requirements. It
is in the solution space that we can have discussions about what is
and is not realistic.

> IPv6 has been designed to support painless renumbering, including
> smoothly switching over from one address range to another without
> loss of connectivity.

This is going too far, and is one of the myths of IPv6 (sigh).

Renumbering is easier in IPv6 than in IPv4. But it is not
"painless". There have been endless discussions/threads about this.

> I am a little wary that the current version of the Problem
> Statement's goals could be used to justify a new architecture
> which pressures end-users to adopt IPv6, and/or to make any other
> such major change their host operating system and application
> software.

If IPv6 solved the route scaling problem, I don't think we'd have much
trouble convincing people to adopt IPv6. But since it doesn't, we
do not find ourselves in that situation.

> I think some people see IPv4 as a dead-end and so can only foresee
> long-term solutions which involve everyone moving to IPv6.

Not sure what this has to do with the problem statement.

> While I recognise there are fundamental problems with IPv4 (NAT
> and limited address space are the most obvious) I think it would
> be dangerous in the five to ten year timeframe in which this
> Problem Statement is relevant to think that the way forward may be
> to discourage people from using IPv4.  I think that any such
> attempt by the IETF etc. is bound to fail.

Can you point to specific text that leads you to feel that the problem
statement is discouraging continued use of IPv4?

> It seems that these things can all be achieved with an ITR - ETR
> scheme as proposed in LISP, eFIT-APT and Ivip.

The problem statement document takes no position on any particular
solution space.

> There are two goals not mentioned in the current Problem Statement
> which I think are achievable and essential for coping with
> long-term growth and ubiquitous adoption:  More efficient
> utilization of IPv4 space and Mobility, including Mobile IPv4.

Please justify each of these two positions. The document talks to the
second point. I don't immediately see how a more efficient utilization
of the IPv4 space helps. Indeed, it probably hurts. From the document:

   4.8.  IPv4 Address Exhaustion

   The IANA and RIR free pool of IPv4 addresses will be exhausted within
   a few years.  As the free pool shrinks, the size of the remaining
   unused blocks will also shrink and unused blocks previously held in
   reserve for expansion of existing allocations or otherwise not used
   due to their smaller size will be allocated for use.  Consequently,
   as the community looks to use use every piece of available address
   space (no matter how small) there will be an increasing pressure to
   advertise additional prefixes in the DFZ.

It is pretty much an axiom that achieving higher utilization in the
use of address space leads to increased fragmentation, and hence, more
routes.

> The currently low percentage of advertised IPv4 addresses which
> are actually used is a result primarily of the address management
> policies of assigning large chunks of space to all applicants.
> This long-standing practice is based on the intention that
> end-user won't need to ask for more space for a few years.

Um, it is RIR policy that an end site can obtain IPv4 space, even if
it it never will be advertised on the public Internet. Thus, you
cannot conclude that because only some fraction of the current
address space is routed on the public internet, the remaining space is
"unused".

Also, RIR policies use an 80% utilization metric. You cannot obtain
more space until you have shown that you are actually using 80% of the
space you already have.

Many (myself included) would argue that we have already got a rather
high utilization out of IPv4. While we might be able to squeeze a few
more drops of blood out of the IPv4 turnip, how much time does that
actually buy us in the overall scheme of things? I suspect not much.

> I think it would be highly desirable to have some policy which
> limits the IPv6 classification tasks of DFZ routers to something
> like /32 or /35 at the most.  Then, the routers can be optimised
> for handling the bulk of their traffic within these limits (which
> are still really demanding).  This is not a goal below, but maybe
> the new architecture needs to include administrative and other
> arrangements which put reasonable limits on the FIB functionality
> of routers, since they are so costly, use so much power, and are
> going to be handling so many VoIP packets.

One small observation: There is no place to define such a policy that
would actually be implemented by (or enforcable on) the DFZ
routers. Remember, the DFZ routers are operated by ISPs, and what
routes they carry, etc. is completely unregulated. Nobody can tell
them what they will and will not route.

> Here is a rewrite:

>    There is a need for a new architecture for routing and
>    addressing that:

>    1.  Reduces the growth rate of the DFZ routing load, where the
>        routing load is dependent on:

>        A.  The number of individual prefixes in the DFZ.

>        B.  The update rate associated with those prefixes.

>        C.  The length of those prefixes.

We have not considered  the prefix length to be a significant
problem. Can you you please expand on this point, and why it is
significant enough to include?

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

The difficulty here is that this gets into router architecture,
something way out of scope for the IETF "on the wire" focus. And the
discussions that followed the RAWs report (to me anyway) make it clear
that there is not really concensus that this component of "routing" is
where the core problem really is. Or that is not a symptom of the core
problem as outlined in the document.

>        E.  The complexity, cost and power consumption of the FIB
>            functions which handle ordinary routing tasks and any
>            requirements of a new architecture, such as
>            encapsulation, decapsulation, authentication and
>            support for Path MTU Discovery when packets are
>            tunneled.

>               (Actually, I think the new architecture needs a
>                whole new system by which hosts can do a much
>                better job of PMTUD than is currently possible.
>                The new tunneling architectures will make PMTUD
>                much harder, while the problems with MTU and
>                fragmentation are going to be made worse.  So there
>                is a lot more which probably should be added to the
>                goals about this.)

I would argue that the above is covered by by section 3.1 and 3.2

>        F.  The costs and difficulties of administering routers
>            and the routing system as a whole so routers operate
>            efficiently and do not place unreasonable burdens on
>            other routers.

>    2.  Allows the following benefits for end-users, with the
>        needs of larger organisational end-users being most
>        important, but in principle extending to individual
>        end-users's networks and single devices.  These benefits
>        should support communications initiated by hosts in
>        networks which have not adopted the new architecture -
>        perhaps not with the same efficiency as to non-upgraded
>        networks, or with as high an efficiency as between two
>        hosts in upgraded networks.  Hosts in non-upgraded
>        networks should suffer no loss of reliability in their
>        communications with hosts in networks using the new
>        architecture.

I think all of this is really getting more into desirable properties
of a solution, rather than the problem.

Thomas

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram