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

From: Thomas Narten <[email-masked]>
Date: Thu, 26 Jul 2007 19:20:37 -0500

The Routing & Addressing directorate has been working on a strawman
problem statement since Prague. I just submitted our first cut as an
Internet Draft and it's available at:

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

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?

 - Are there other pressures on the routing system that we have not
   listed or described completely?

 - 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.)

 - Are there other views of what folk perceive the core routing and
   addressing problem to be?

Thomas

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

---

From: "Ricardo V. Oliveira" <[email-masked]>
Date: Fri, 27 Jul 2007 10:32:19 -0400

Hi Thomas,

Some minor comments on the draft:
Sec 4.7:
"For a large ISP, the internal IPv4 table can be between 50,000 and  
150,000 routes."
What do you mean by internal IPv4 table? In large IS, the number of  
routable prefixes in a router can easily reach 250k.

   The degree of interconnectedness between ASes has increased in recent
    years.  That is, the Internet as whole is becoming "flatter" with an
    increasing number of possible paths interconnecting sites [ref?]
http://www.cs.ucla.edu/~rveloso/papers/fp163_oliveira.pdf has some  
numbers for this in section 4.3.

Thanks,

--Ricardo

---

From: "Ved Kafle" <[email-masked]>
Date: Sat, 28 Jul 2007 00:19:14 +0900

Are the rrg presentation slides going to be available online?

---

From: Peter Sherbin <[email-masked]>
Date: Fri, 27 Jul 2007 10:50:46 -0700 (PDT)

Enjoined reading the statement. Re the "flatter" Internet in 5.1. since around 2000
seemingly there is a trend in changing upstream transit contracts to peering
arrangements. By Q1 2007 in the observed example over 80% of traffic is routed via
peers.

Statement 1. Would it be beneficial to define the targeted number of individual
prefixes in DFZ, specify the update rate and then architecture towards those
numbers? E.g. assume 1 AS per each 10,000 sq km of Earth's surface and 9 routes per
AS. It gives about 450K as the maximum number of DFZ entries providing an idea of
the router required processing power.

Statement 4. Make it more rigid "Allows end sites to switch providers without
configuration changes to internal end site devices".

Statement 5. seems redundant

Thanks,

Peter

>    addressing problem to be?

____________________________________________________________________________________
Get the free Yahoo! toolbar and rest assured with the added security of spyware protection.
http://new.toolbar.yahoo.com/toolbar/features/norton/index.php

---

From: Jason Schiller <[email-masked]>
Date: Fri, 27 Jul 2007 15:09:06 -0400 (EDT)

> routable prefixes in a router can easily reach 250k.

You can classify the routes in a large ISP as "Internet routes" these
prefixes also show up in the Internet table, and internal routes, these
are ones that are not advertised outside of the AS.

Currently the Internet table (DFZ) is rougly 230K.  ISPs carry an
additional 50K-150K internal prefixes that don't appear in the Internet
table (DFZ).  This does not include VPN routes.

In IS, the total number of routable prefixes (Internet + internal) in a
router can easily reach 380K.

I hope that answers your question.

Can you please look back at section 4.7 and see if the text is sufficent
or if more detail needs to be provided to make this clear.

__Jason    

==========================================================================
Jason Schiller                                               (703)886.6648
Senior Internet Network Engineer                         fax:(703)886.0512
Public IP Global Network Engineering                       [email-masked]
UUNET / Verizon                         [email-masked]

The good news about having an email address that is twice as long is that
it increases traffic on the Internet.

On Fri, 27 Jul 2007, Ricardo V. Oliveira wrote:

> Date: Fri, 27 Jul 2007 10:32:19 -0400
> From: Ricardo V. Oliveira <[email-masked]>
> To: [email-masked]
> Subject: Re: [RAM] First cut at routing & addressing problem  statement
> 
> Hi Thomas,
>

---

From: Robin Whittle <[email-masked]>
Date: Sat, 28 Jul 2007 23:42:03 +1000

Hi Thomas,

I think the Problem Statement is well written.  The only typo I
found is that the final sentence in the definition of RIB should
be deleted.

I suggest this be added to Section 6:

  6. Ensures continued reachability from hosts in non-upgraded
     networks to those hosts which directly use the new
     architecture - such as by having an addresses which uses a
     tunnel-based mapping system to enable portability,
     multihoming and traffic engineering without further burdening
    the BGP routing system.

I have one big suggestion and a few smaller ones.

The Statement mentions the looming shortage of IPv4 address
space, but doesn't consider it to be part of the Problem to be
solved.  I think this is the biggest technical problem facing the
Net itself - not counting regulatory problems, botnets, spam and
general security problems with the computers and how they are used.

The Statement recognises that a future solution to the Problem
as currently defined could have great benefits for Mobile IP.

I think it would be good to also recognise that a future solution
to the Problem as currently defined (Section 6) might be able to
help with the IPv4 address shortage, by enabling a much finer
allocation system to end-users, giving them as few addresses as
they actually need, rather than with the current minimum
assignment size of 256 IPv4 addresses.

Another approach would be to define the IPv4 address shortage as
part of the current Problem.  I think this is the best idea, for
two reasons:

1 - The reason for the shortage is the poor utilisation
    of IPv4 address space - which is a direct result of the
    limitations of the BGP system in not being able to
    globally route millions or hundreds of millions of
    prefixes.  Currently, it can only handle a limited number
    of divisions, each of 256 IPv4 addresses or more - and
    ideally these chunks should be advertised in a manner
    which aids route aggregation.

2 - I think the "IP-level" solutions - LISP, eFIT-APT and Ivip -
    to the other parts of the routing and addressing Problem as
    currently defined will also enable a substantial solution of
    the IPv4 address shortage by enabling space to be more finely
    divided between many more end-users.

We are running out of space with 3.7 billion addresses available,
but less than 10% of those addresses are used, as far as I can
tell.  (I could only find just over 100 million with ping, which I
know has its limits.)

The Statement's current wording could be interpreted as indicating
that IPv4 address space is being efficiently used:

  In IPv4 there has been a heavy emphasis on conserving
  address space and obtaining efficient utilization.

but this is just relative to IPv6, not to the ideal of approaching
100% utilisation.

Even allowing for a wide margin of underestimating actual
utilisation with ping, my survey:

  http://www.firstpr.com.au/ip/host-density-per-prefix/

shows that some prefixes have quite high rates of utilisation,
such as more than 30% while most have much lower levels.

30% is pretty low, I think - but if this could be achieved in
general for the whole 3.7 billion IPv4 addresses, this would
provide for probably 4 to 10 times the number of active IP
addresses than there are today.  This doesn't mean IPv4 can go
forever, but it would be a great improvement on continuing to use
the clunky tool of BGP to distributed finite address space to a
growing number of end-users.

There are two broad areas of solution to the Problem as currently
defined, not counting general improvements in routers themselves.

The first area is improvements to the BGP routing system, in terms
of the details of the protocol, how BGP is implemented in routers,
how the routers are configured and run etc.

The second area is an IP-address based system which has nothing
directly to do with BGP, other than either not advertising
prefixes which otherwise would be advertised.

In this second area, four current proposals exist which aim to
work with both IPv4 and IPv6 by altering the behavior of routers -
and so which not require any changes to hosts, host operating
systems or applications.  (However, they all involve tunneling, so
I think there is going to have to be some effect on hosts,
hopefully won't require user configuration changes, in the form of
a marginally reduced MTU.)

  LISP-NERD
  LISP-CONS
  eFIT-APT
  Ivip      (my proposal)

I think the proponents of the first three proposals have the
primary goal of providing multihoming, portability and TE for
end-user networks.

In addition to these goals, my understanding of these proposals
has always been that they can lead to much better utilisation of
IPv4 address space than is possible with the current BGP
arrangements.  The fact that the proponents don't state this and
may not even support or believe this doesn't alter my view that
this increase in utilisation efficiency may be the most important
and immediate benefit these proposals can offer - perhaps more
important than saving existing DFZ routers from early obsolescence
in the rising tide of the global routing table.

BGP slices and dices IPv4 space with 256 address granularity, with
clunky temporal resolution (minutes?) and with unacceptably high
cost burdens on all BPG users, for every new advertised prefix and
every change to how and where the prefix is advertised or not.
The main problem is that the cost of each extra slice falls on
every DFZ router, and that beyond a few hundred thousand slices,
the system becomes expensive and has stability problems and slower
convergence times.

All these new proposals enable the division of IPv4 address space
into prefixes of any length, including to /32 single IP addresses.
 (Ivip is more flexible, because it isn't stuck on prefix
boundaries - it can group one or any number of contiguous IP
addresses together in terms of them all being mapped to the one
ETR address.)

The temporal resolution of these systems varies widely, but even
if they were all really slow, the fact that any of these systems
can be used to make single IP addresses, or 2 or 4 or 8 ... 64
addresses etc. be portable to any ISP in the world which has an
ETR, and to be used for multihoming, is a tremendous step forward
compared to BGP.

I think that any of these schemes, once successfully introduced,
would enable end users - including some who would otherwise get an
ASN and PI space and many who wouldn't - to run their networks
with just as many IP addresses as they need.  I think that in many
cases, end-users would be happy with significantly less than 256
addresses.

So with any of these proposed systems, many more end-users would
be able to have their own portable, multihomable networks in a
given range of IPv4 address than would be possible with BPG now.

Exactly which space gets sliced up finely like this is an
important administrative and business question, which I think will
find natural and generally agreeable solutions when one of these
proposed systems is widely implemented.

I suggest something like this be added to Section 6:

  7. Provide for more efficient utilisation of IPv4 address space,
     such as by enabling end-users to connect their networks with
     portability, multihoming and traffic engineering capabilities
     without burdening the BGP system and in a way which uses only
     the number of IP addresses each network actually needs.

Regarding Mobile IP, I think it is good that the Statement
recognises that the solution for the main routing and addressing
problem could provide tremendous benefits for Mobile IP.

I understand that current Mobile IP systems are not a burden on
the BGP routing system or on the addressing system.  However, I
think that the potential benefits of Mobile IP, including for IPv4
(which as far as I know is not really attempted much at present)
are so important that the mobility support of potential solutions
should be an important factor if is necessary to decide between
two otherwise roughly equivalent proposals.

Ivip is intended to go a step further than the others by providing
very fine temporally resolution to mapping - a few seconds,
ideally - with the user setting up their own systems to control
mapping to achieve multihoming service restoration, mobility etc.
without these being built into Ivip itself.

I think it would be good to state some approximate, but reasonably
concrete figures for BGP router numbers in the Statement.

Is it possible to get reliable figures for the number of BGP
routers, and how many of them are multihomed border routers or
transit routers?  I asked about this on the RAM list a few months
ago, and got no solid figures.

Recently I found this:

  http://iplane.cs.washington.edu/data.html
  Lists of alias clusters:

     Each line in this file contains a space-separated list of
     interfaces that correspond to a single router.

     58,834 lines  (62,699 on 2007-07-12 for reasons unknown.)

Can anyone confirm that this is a good estimate of the number of
BGP routers?  Perhaps there is a way of analysing this data,
probably with other data from the iPlane site, to determine which
are single-homed and which are in the DFZ.

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

---

From: Robin Whittle <[email-masked]>
Date: Sun, 29 Jul 2007 21:24:44 +1000

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.

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.

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 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.

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 the term "site" tends to imply a physical installation,
largish network, etc.  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.

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.

IPv6 has been designed to support painless renumbering, including
smoothly switching over from one address range to another without
loss of connectivity.  I am not sure how well this is regarded by
the operators of big networks - and I imagine it has rarely, if
ever, been put to the test in a real, busy, substantial commercial
end-user network.

These IPv6 provisions can't cope automatically and reliably with
every little detail programmed into routers, switches, etc. such
as ACLs, VPN configuration, source address spoofing filters etc.
Nor can these IPv6 provisions work fast enough and without human
intervention to support multihoming - because existing
communications sessions do not persist into the new addresses,
unless perhaps both ends of the session are using SHIM6.

It is completely impossible for any new routing and addressing
architecture to enable reliable, cost-free renumbering of IPv4
networks.

So to respect the genuine needs of end-users, I think this should
be rewritten simply to provide "portability" of their address
space between providers.

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.

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

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.

I think people should move to IPv6 (or maybe some new and better
system in the long term future) if and when the benefits they
receive exceed their costs.  At the same time, we should be doing
our best to preserve and improve the usability of IPv4.

I think there is a danger of seeing the Problem being just the
biggest obvious problem: the RIB-BGP load caused by an increasing
number of multihoming end-users who are big enough to get an ASN
and PI space today.

We certainly need to solve this problem in a way which doesn't add
to the number of BGP advertised prefixes.  However, I think it is
important to frame the goals for a new architecture in a way which
encompasses the longer-term challenges posed by ubiquitous
Internet adoption, with millions - or hundreds of millions - of
end-users wanting and needing portability (or at least painless
choice of providers), multihoming, and TE for incoming traffic
over multihomed links.

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

Furthermore, if the ITR tunneling (EID-RLOC mapping) can be
controlled by the end-user fast enough  (not just codified in the
form of instructions to ITRs regarding multihoming service
restoration), then the new system will support Mobility too.

Although lack of Mobility is not regarded as a crucial problem,
this is a little like thinking lack of cell-phones wasn't a
problem in 1977.  The value of genuine mobility, with sessions
continuing as the mobile node switches between separate provider
networks, will be immense.  This is probably the biggest single
thing which could be done to boost the usefulness of Internet
communications - even more than significant increases in speed or
decreases in cost.

I think this real-time control of mapping - such as with 2 to 4
seconds latency globally - can be achieved, but the proponents of
LISP and eFIT-APT do not base their systems on any such high-speed
mapping information distribution system.

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.

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.

Another, more crucial, intention of the current address management
system is driven by the desire for route aggregation.  The idea is
that by giving providers and end-users largish slabs of space,
each provider or end-user will be able to satisfy their needs for
a long time with this space, which will either be a single BGP
advertisement or at least be advertised in a few smaller pieces in
roughly the same geographic and topological area.

This goal of route-aggregation would not be so well served in the
current BGP-dependent architecture if the providers and end-users
were only given small pieces of space, on a more frequent basis,
with those smaller pieces making up non-contiguous blocks of
addresses, each requiring a separate advertisement in BGP.

BGP imposes some clunky restrictions on the use of address space.
 The granularity (in IPv4) is 256 addresses at a time, and all
users are urged to minimise the number of prefixes they advertise.

The likely new architectural approaches all enable the address
space to be used much more flexibly.  The granularity of control
can be prefixes of any length, including single IP addresses.  The
number of separately mapped prefixes in the new system places no
burden on BGP, and only burdens the new system - which will be
designed to scale to millions or perhaps a billion such separately
mapped prefixes.

So to the extent that address space is split between end-users
with the new architecture, that new address space can be assigned
in much finer and more flexible ways than has been possible with
BGP.  This is exactly what is needed for the space to be highly
utilised so that more users and or more nodes can be accommodated.
 This is not just for end-users - providers can use space which is
sliced and diced in this way as well, though not for running ITRs
or ETRs.

Ivip is the only proposal which has as one of its explicit goals a
great improvement in how many IPv4 addresses can actually be used.

However, I believe that LISP-NERD, LISP-CONS and probably eFIT-APT
will be just as suitable as Ivip for this fine-grained address
assignment.

Ivip is currently the only proposal which aims for mapping changes
to be transmitted rapidly (a few seconds ideally) to all ITRs.

While I haven't devised precisely how to do this, no-one can say
yet that it can't be done.  We can get packets across the world in
a fraction of second - so maybe all we need is a multicast system
to distribute mapping changes, with some authentication
arrangements and provision for coping gracefully with lost packets.

I hope there will be other people working on Ivip or on their own
proposals with similar high-speed mapping distribution.

Even if the best efforts to devise a system such as this fail in
the next year or two, it cannot be assumed that such a system will
not be practical and attractive in the future.  So while Ivip is a
lone, young, proposal at present, I think that the Problem
Statement should not be limited by the assumption that high-speed,
essentially real-time, user control of ITRs (or however the new
architecture works) will never be feasible.

Here is a chart of the current proposals which are intended to
provide benefits directly to both IPv4 and IPv6, without requiring
changes to hosts.  (So this leaves out SHIM6, Six/One and IPvLX.)

"BGP improvements" encompasses the proposals which are intended to
make the BGP routing system work better, such as being able to
handle more prefixes, increase stability, reduce unnecessary
control plane traffic, lower costs, ease router management
difficulties, improve security etc.  I assume that these
improvements will not drastically increase the BGP system's
ability to handle more prefixes or to propagate advertisement
changes more rapidly.

             Proposal >>  BGP impro-  LISP    eFIT-APT  Ivip
                          vements
New goal:

Better utilization of     NA          Yes*    Yes*      Yes
IPv4 space, via finer
allocations to more
end-users who have
portability, MH and TE
without burdening BGP.

Support major improve-    NA          No      No        Yes
ments to Mobile IPv4
and IPv6 - with optimal
or usually close to
optimal path lengths
and reachability from
non-upgraded hosts and
networks.

  NA   Not applicable - meaning the proposal does not prevent
       this goal, but does not directly support it either.

  No   The proposal does not allow this goal to be achieved.

  Yes  The proposal allows this goal to be achieved.

  Yes* I think the proposal allows the goal to be achieved, but
       this is not necessarily the view or the intention of
       the proponents of this proposal.

This rewrite also attempts to consider other problems the routing
system faces apart from the number of advertised prefixes and
their rate of change - including the cost and processing
difficulties of the FIB.

Having to process 48 bits of IPv6 address for the new PI end-user
assignments of ARIN and AfriNIC seems really inefficient.

Consider the vast number of streams of little VoIP packets - such
as 30 to 50 packets a second with 20 to 30 bytes of voice data,
plus RTP header (12 bytes) and UDP header (8 bytes).  This is 40
to 50 bytes.  Users want this to be a low-cost service, and they
will expect it to be pretty much for free.

Yet with IPv6, the small amount of data per packet gets a
lumbering 40 byte IPv6 header in front of it, and every multihomed
and transit router the packet traverses has to labour its way
through 48 bits of destination address just to figure out which
interface to forward it to.

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.

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.

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

       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.)

       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.

       A.  Portability of the address space when choosing
           another provider.

       B.  Multihoming with two or more providers, with
           robust session continuity.

       C.  Incoming Traffic Engineering where there are two
           or more links to providers.   This TE should be
           technically capable of being controlled by the
           end-user and/or the provider.

   4.  Provides meaningful benefits to the parties who bear the
       costs of deploying and maintaining the existing and new
       elements of the routing system.

   5.  Requires no change to host operating systems or application
       software.  Configuration changes to hosts in upgraded or
       non-upgraded networks should be minimised and would only be
       required to improve, or perhaps maintain current levels of
       efficiency.  No changes to any hosts will be required to
       maintain current levels of reachability and reliability of
       communications.

          (I am thinking of MTU settings, tunneling and
           fragmentation.  Hosts in both upgraded and non-upgraded
           networks might have less efficient communications with
           hosts in upgraded networks, due to fragmentation, but
           they shouldn't suffer significantly less reliable
           communications.  This may not quite be possible with
           packet loss rates having more impact with
           fragmentation.)

   6.  Requires no changes to networks which do not adopt the
       new architecture in order to maintain current levels of
       reachability and reliability of communications.  Any
       changes of configuration, such as to routers, will be
       necessary only to improve efficiency.

          (It may be best for all networks, upgraded or not, to
           have their DHCP servers send out lower MTU settings,
           to avoid packets being fragmented due to the
           tunneling overhead.)

   7.  Ensures sites which adopt the new approach remain fully
       reachable from sites which do not.

          (May be redundant since point 2 may make this clear.)

   8.  Supports the greater utilization of IPv4 address space
       by enabling greater flexibility in address assignment
       than is currently possible - which will enable a
       greater number of end-users to be assigned address space
       in smaller increments which more closely match their
       immediate needs.

   9.  Supports administrative and commercial frameworks which
       are intended to improve flexibility, choice and
       competition - including the ability of large numbers
       of smaller sites and individual end-users to gain
       address space, with or without the benefits of
       portability, multihoming and TE.

  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.

I also wrote about the RRG Design Goals at:

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

but that doesn't include all the stuff I am proposing now.

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 31 Jul 2007 14:35:00 -0400

Peter,

Thanks for your comments.  With regard to statement 1, we discussed  
whether targeted numbers might be worth including but decided in the  
end not to do so for several reasons.  For one thing, it's an  
invitation for contentious argument about exactly what the numbers  
should be -- which would seem to be a rathole.  For another, the  
supportable values are certainly a moving target, based on the state  
of the art at any given time.

With regard to statement 4, I personally think it's OK as written.   
Surely a proposal which can allow switching with no configuration  
changes also optimally fulfills "minimizing configuration changes".   
Seems like flat-out forbidding any slightest configuration change  
would be going too far, though I think it's clear that forced site  
config changes are undesirable.

With regard to statement 5, with what other statements do you think  
it's redundant?  Note that statement 5 focuses on the alignment of  
cost and benefit.

Regards,

--John

---

From: Thomas Narten <[email-masked]>
Date: Tue, 31 Jul 2007 16:24:11 -0400

> 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.

>     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. :-)

>     (including those who don't need portability/MH/TE) to

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.

> correspondent hosts not requiring new software, and with close to

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.

> as nodes which connect mobile networks - for instance in passenger

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.

> 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.

> 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.

> 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.

> such major change their host operating system and application

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.

> long-term solutions which involve everyone moving to IPv6.

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

> 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?

> scheme as proposed in LISP, eFIT-APT and Ivip.

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

> 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.

> 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.

> 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.

>        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?

>            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.

>                is a lot more which probably should be added to the

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

>        communications with hosts in networks using the new

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

Thomas

---

From: JFC Morfin <[email-masked]>
Date: Wed, 01 Aug 2007 02:52:41 +0200

>just larger enterprises or ASes. We'll add a clarifying definition to

Dear Thomas,
I am sorry but "5. Provides meaningful benefits to the parties who 
bear the costs of deploying and maintaining the technology." is an 
error. What we want is to provide meaningful benefits to the users. 
The users are those who have the money but no incentive today. Their 
satisfaction is the benefit for the parties who beat the costs, 
because they will pay. Not the IETF.

The incentives for them the users are:

- to get presentation layer warranties. Each network application 
tries to build its own virtual presentation layer features. IDNs and 
200 languages. ccTLD with 193 countries. RFC4646 and 7,500 languages. 
Addressing does not, while there is an unlimited need.

- as a result SNHN (small networks/home networks) have not been 
considered and their addressing area has not been protected and 
supported by the addressing format which is for them no better than a NAT.

- privacy, security, national policies require that the "sites" can 
decide of their routing.

Addressing is to point fixed, mobile, virtual targets on "the 
semantic distributed networks of the decentralized logical network of 
the centralized ISP/Corp/SNHN bandwidth networks" in order to flow a 
traffic of fractal natue. To match the resulting diversity and 
routing constraints (path, access, and content) presentation layer 
equivalence is of the essence (whatever you name it: presentations, 
externets, groups/classes, views, closed user groups, etc.) I looked 
for "presentation layer" in the list's archive. I did not find it a 
single occurence.

Such a layer could be implemented in part through the addressing 
structure. Multi-level addressing also can help it. May be there are 
other possibilities. This should also be investigated through a 
"smart NIMROD"? It could be involved in getting some control on 
routing? Whatever the solution retained, it should provide the best 
addressing and operational environment to "plug-and-play" 
standardized sub-addresses.
jfc

---

From: JFC Morfin <[email-masked]>
Date: Wed, 01 Aug 2007 03:03:34 +0200

Dear Robin,
in your rewite the point 3 is missing. Is that a typo or a real miss.
thank you.
jfc

---

From: JFC Morfin <[email-masked]>
Date: Wed, 01 Aug 2007 02:52:41 +0200

Dear Thomas,

---

From: JFC Morfin <[email-masked]>
Date: Wed, 01 Aug 2007 03:03:34 +0200

Dear Robin,

---

From: Peter Sherbin <[email-masked]>
Date: Tue, 31 Jul 2007 18:09:55 -0700 (PDT)

> should be -- which would seem to be a rathole.

There were at least two reasons for suggesting a quantitative benchmark. 1. The
Earth has a finite surface or more precisely a limited band of interest which
includes the surface plus 20-40km above and 10-20km underneath. Thus it will sustain
only a finite number of routers.

2. The draft says that there are 229,789 routes, that "there will be an increasing
pressure to advertise additional prefixes in the DFZ" and that "the amount of work
needed to maintain paths for a given set of prefixes appears to be increasing". Such
conclusions lead to questions like what is the optimal number of prefixes in DFZ?
what is the relationship between the number of prefixes and the number of paths?
What is the optimal number of entries in RIB/FIB for a particular processor speed?
Having numbers here provide a reference point for the discussion.

There is also a few other questions such as what is the general theory/model of the
Internet? what is the countable unit of the Internet: a node, an interface, an end
point, a bit, all of the above? what are the quantitative relationship between the
Internet units? does the exercise of producing the Internet model belong to IETF?

> would be going too far

The strict requirement here protects the site. Ideally there should be no effort at
all for the site to change providers. Please keep in mind that the wire-line
Internet is only an individual case of the more general mobile Internet with end
points moving freely between (relatively) static access points. Which access point
belong to what provider should remain transparent to an end point.

> it's redundant?

This one is redundant in a sense that it does not specify the quantity of benefits
and that it seems to be a default assumption in any engineering effort whether IETF
or else.

Thanks,

Peter

       
____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. 
http://mobile.yahoo.com/go?refer=1GNXIC

---

From: Robin Whittle <[email-masked]>
Date: Wed, 01 Aug 2007 13:54:29 +1000

Hi JFC Morphin,

The missing point 3 is just a typo.  The other points you mention
seem to involve long-term new architectural goals involving host
changes.

I have approached the RADIR Problem Statement assuming it concerns
a problem which requires a solution which is incrementally
deployable and automatically enables existing hosts, without
changes, to remain connected, but achieves important benefits such
as multihoming, portability, TE etc. for many more end-users
without adding to the growth in the global routing table.

In fact, there is no timeframe or requirement for unchanged hosts,
or incremental deployability, in the current Problem Statement.
Below, I discuss it as if this was the goal.  Perhaps there needs
to be two problem statements.  One is to get us out of a fix in
the next five to ten years, without requiring host changes.  The
other is to create a new set of protocols or whatever to achieve
some of the more ambitious goals you discuss.  As far as I know,
your goals can't be done without changes to host operating systems
and probably applications too.

The rest of this message responds to Thomas Narten's reply to my
message 1773.

Thanks Thomas for your response.  Some of my message discussed
what I think can and can't be expected from potential solutions.
I wasn't suggesting that that material be included in the Problem
Statement.  I think it is important not to write the Problem
Statement as if something is possible when it is not.

I mentioned the capabilities and limitations of various solutions
to explain why I think it is important to include criteria which
identify solutions which might preclude the realisation of an
important goal which is not part of solving the current Problem.

Thanks for clarifying "site".  I agree with much of what you
wrote. Here are some points where where I disagree, don't
understand etc.

> is deployable in practice), we should be happy. :-)

I think that it is distracting and of little or no use to frame a
statement as if some solution could exist for a problem when it
can be reliably proven that no such solution is possible.

Ignoring IPv6 for a moment, consider the large number of IPv4
end-user networks.  There is no way these can be renumbered
reliably, automatically, or manually, because there are many IP
addresses in obscure places, as the RRG "Design Goals" note, such as:

  In addition to being configured into hosts and routers, where
  automated renumbering tools can help, IP addresses are also
  often used for other purposes such as access control lists.
  They are also sometimes hard-coded into applications used in
  environments where failure of the DNS could be catastrophic
  (e.g. certain remote monitoring applications).  Although
  renumbering may be considered a mild inconvenience for some
  sites, and guidelines have been developed for renumbering a
  network without a flag day [RFC4192], for others, the necessary
  changes are sufficiently difficult so as to make renumbering
  effectively impossible.

These obscure locations of IP addresses cannot be known to any
newly introduced architecture, software tools etc. - so there is
no external solution which can enable these networks to reliably
renumber in some clean, automated, manner.  (Even if the IP
addresses were known to some system, how could such a system
reliably know they should be changed - and how could such a system
re-initialise various daemons, in the right order, at the right time?)

I regard the above as complete proof that any new architecture
will be incapable of providing reliable renumbering of most
substantial IPv4 networks in use today, or in the timeframe I
assume is of interest: the next ten years.  Can anyone think of a
counter argument?

In the long term, it might be possible to define some new
architecture to which all new routers, operating systems etc.
would fully comply, with systematic linkages for updating
configurations and reloading those config files etc.  Even then, I
doubt any network administrator would be confident about letting
some intricate automated web of processes suddenly try to steer
their network on another course, all at once.

If some new architecture is developed for reliable fully automated
renumbering, then it would be a decade or more before it could be
assumed that many networks would be fully compliant with that
scheme.  So an architecture which supports reliable automated
renumbering is a solution which might have some value around 2022
or so.

As you note, even with a decade or so of efforts, it is not close
to being achieved with IPv6.

Assuming the Problem Statement is referring to a solution which
will have reliable, practical, benefits in the 2010 to 2012
timeframe, I believe that reliable automated renumbering of
networks can be completely ruled out as a possibility.

In that case, I stand by my argument that it would be best to
frame the Problem Statement without the assumption or implication
that something which is provably impossible may in fact be
possible in the timeframe of interest.

> problem worse rather than better.

I should have added this to the above paragraph:

... enable a much greater number of end-users of all types,
    (including those who don't need portability/MH/TE) to
    use IPv4 without adding to growth in the global routing table.
             ----------------------------------------------------

I think that something very clear to me is either not understood
or not agreed to by some people:

If you have a largish subnet assigned to the LISP/eFIT-APT/Ivip
system, say 20.0.0.0/14, with 262,144 IP addresses, then this will
require either no BGP advertised prefixes or for Ivip, one
advertised prefix.

The ITR-ETR-database tunneling and mapping system
(LISP/eFIT-APT/Ivip) is capable of dividing these 262,144
addresses between a large number of end-users.  In principle, each
IP address could go to a separate end-user, with portability,
multihoming and TE.

A more likely outcome is some mix of prefix sizes going to
end-users.  It is easy to imagine some mix of prefix sizes between
 /20 and /32 - with thousands of end-users getting what they need,
which may be only one or a few IP addresses, or may in some cases
be a few thousand.

This address space can be divided up much more finely than with
IPv4's current (and likely future) BGP arrangements which, in
practice, though not technically, restrict the advertised prefix
length to 24 or less.  Changing that limit wouldn't help, because
the real problem is the number of advertised prefixes.

Any of these schemes (LISP/eFIT-APT/Ivip) could take this /14 and
with either 0 or 1 extra prefixes in the global routing table,
serve the needs of hundreds or more likely thousands of end-users.

I think that the LISP and eFIT-APT proponents see their schemes as
being beneficial primarily by providing multihoming and TE to
single prefixes - so the overall benefit is mainly that a prefix
can be taken out of the BGP system and then still be used for MH,
TE etc. with LISP or eFIT-APT.

I have always seen the primary benefit of these schemes being that
a single block of address space can be used for many more
end-users than with BGP, because it becomes finely divisible
without concern about route aggregation or the effective 256
address granularity of BGP.

>    laudable goal, is not considered a part of this problem statement.

I agree with this, but I am suggesting that since some solutions
to the "multihoming, portability, TE vs. routing table growth"
problem (one so far - Ivip) would enable great benefits for Mobile
IP and that others would not be extendable to provide these
benefits, that the Problem Statement should support a decision
framework which gives preference to a solution which either
provides the Mobile IP benefits, or does not create barriers to
such benefits being added in the future.

In principle, it might be possible to add an Ivip-style
"real-time" database distribution system to LISP-NERD/CONS or to
eFIT-APT, but this would be a major change to those architectures,
and made more difficult by the more complex and lengthier nature
of the mapping data than is used with Ivip.

> Our view is that improved mobility is a "nice to have", rather than

I am discussing solutions to show that there are important
differences between the current solutions regarding mobility.
I am not suggesting that this discussion appear in section 6 of
the Problem Statement.

> statement is discouraging continued use of IPv4?

I see nothing in the Problem Statement which discourages continued
use of IPv4.  Nor did I want to imply that this was a motivation
of those who wrote it.

The current text does not mention the timeframe the new
architecture is to be developed and deployed in.  Nor does it
mention that in order to be acceptable, the new architecture must
not require changes to host operating systems, software (and
perhaps configuration).

In this whole debate, these requirements are widely assumed - or
perhaps this RADIR statement is for a longer timeframe, so it is
another debate.

If words to the effect of these were added:

   The new approach must be developed and deployed so that its
   benefits start to accrue by 2011, with full benefits being
   achieved by 2015.

   The new approach must not compromise the reliability of
   communications between hosts in networks which have not yet
   adopted the new approach and hosts in networks which have
   adopted it.

   In order that the new approach be reliably and incrementally
   deployable, it must not rely on changes to any hosts, including
   those in networks adopting the new approach, in order that
   those hosts maintain reliable connectivity with all other
   hosts.

     (This does not rule out an architecture which marginally
      degrades performance for all hosts, with some of that
      performance perhaps being restored via host configuration
      changes. For instance MTU settings.)

then I would not be concerned that the Statement could support
someone arguing that end-users should be required to adopt IPv6.

> The problem statement document takes no position on any particular

I agree that it shouldn't.

> use of address space leads to increased fragmentation, and hence, more

This is what I mentioned above - the LISP/eFIT/Ivip approaches all
enable a drastically more efficient utilisation of IPv4 address
space without adding prefixes to the BGP routing table.  (Ivip
adds one for each block of space which is assigned to it, but
supports many more than one end-users in that space.)

> address space is routed on the public internet, the remaining space is

Figure 5 "Current IPv4 Status" at:

  http://www.potaroo.net/tools/ipv4/

shows quite a lot of space, in orange, which has been assigned but
not advertised.

Figure 12 graphs the unadvertised space, which is growing more
slowly than the advertised space.  It is currently about 0.46  of
the advertised space.  So about 31% of assigned space is not
advertised.

I wonder why an end-site would want address space it was not going
to advertise, and why in an era of permanent shortage, RIRs would
allow space to be used in this way.  Couldn't those end-users be
expected to use private address space and let another end-user
have the publicly routable space, to advertise?

> actually buy us in the overall scheme of things? I suspect not much.

Perhaps this is where I misunderstand actual utilisation of IPv4
address space.

Does "80% utilisation" mean that 80% of the IP addresses actually
have a host, an ADSL modem/router etc. using them, at least some
of the time?

I wonder what fraction of the space actually has that rate of
utilisation.  Only a fraction of it would have, since much
assigned space would be either old (and often very large)
assignments or an assignment to an end-user or ISP which did prove
the 80% utilisation, but this new assignment generally won't be
that highly utilised yet.

In March this year there were about 1.695 billion IPv4 addresses
advertised.

I know some of this space is /8s with very low utilisation rates.
 I wonder how much of the advertised prefixes really come close to
the 80% utilisation rate.

It is my impression that a lot of this space is sparsely used.

There is no pressure about reclaiming sparsely used address space
this now - such as telling the assignee to keep a quarter of it,
move their hosts to that quarter, and use the rest for other
end-users - but I am sure there will be in two or three years time.

A recent JPNIC statement:

  http://www.apnic.net/news/2007/0626.html

may be foreshadowing this:

  To maintain the existing IPv4 based Internet, and to create
  smooth transition to IPv6, it is also important to recover and
  recycle unused IPv4 addresses.

> them what they will and will not route.

Maybe not a policy then, but sufficient ISPs deciding that they
don't want to be paying forever for overly complex routers because
a small amount of address space involves what they consider to be
unreasonably long prefixes.

> significant enough to include?

I am not concerned about IPv4 traffic often requiring up to 24
bits of the address to be analysed.

I accept that IPv6 will generally involve looking at 32 to 36
bits, but I think the recent development of /48 end-user
assignments by ARIN, AfriNIC and yesterday RIPE means that IPv6
routers have to do a huge amount of work in their FIB to classify
each of these packets which match a /48.

If the router uses a TCAM wide enough to handle these bits in a
single cycle, then I agree it doesn't really matter. TCAMs were 36
bits wide and are now available 72 bits wide.

However the latest high-end routers don't use TCAM in their FIBs -
they use ASIC CPUs and RAM lookups.  The more bits which need to
be analysed, the more processing time and RAM lookups are
required.  The shared Dynamic RAM is the bottleneck of Cisco's 188
CPU system.

The initial brochure for Cisco's CRS-1 mentioned that its MSC card
could handle 40Gbps, but only for IPv4.  I discuss this
Tree-bitmap based CRS-1 MSC at:

  http://www.firstpr.com.au/ip/sram-ip-forwarding/router-fib/

You can see the "IPv4" proviso on page 20 of:

http://www.dfn.de/content/fileadmin/3Beratung/Betriebstagungen/bt45/forum-winip-irgens.pdf

  Silicon Packet Processor
    40G of line rate Forwarding capability (IP4)

This is with one or two gigabytes of DRAM, and an ASIC with 188
independent 32 bit CPUs.

IPv6's longer prefixes are hard work, and I think that any new
architecture should only increase the workload of FIBs with very
strong justification.  There was a lot said about FIB burdens in
the RAWS report and presentations.

> problem as outlined in the document.

It is my understanding that the primary reason a new architecture
is required is that the growth in the global BGP routing table
must be constrained in order to ensure that unsustainable burdens
are not placed on individual DFZ routers, particularly in terms of
the amount of state they hold in their RIB, their processing load
and their communications load.

The internal RIB functions of routers are defined, in large part,
by the protocols they must handle, which is under the control of
the IETF.  It would be easy to invent a more detailed form of BGP
message, to enable routers to make better decisions, but either
no-one would implement it, due to the typically 4Gbyte restriction
on RAM, or they would do so and all compliant routers would cost
much more than current routers, with older routers needing to be
completely replaced.

I think "complexity and volume of inter-router communications" is
important, since this is the real problem along with the amount of
RIB state - and since the current text:

     A.  The number of individual prefixes in the DFZ

doesn't cover how long the messages are for each update of each
prefix, or the amount of data they contain which needs to be
stored in the RIB.

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

I think this needs to be part of the formal Problem Statement,
because otherwise an architecture could be chosen which involves
excessively complex processing to achieve important things like
authentication of ICMP messages and filtering encapsulated packets
to drop those with spoofed local source addresses.  I have written
about both these problems on this list recently.  Just the
encapsulation of some proposals involves extra headers, nonces,
etc.  I think there needs to be a good justification for all this
extra work and extra bits in packets.

> of a solution, rather than the problem.

I agree this concerns required or desirable properties of the
solution.  I think this is in keeping with the current form of
Section 6:

  The problem is that we need a solution which will have the
  following properties:

    1. .....
    2. etc.

My understanding is that most people in this field believe that a
new routing and addressing architecture needs to be developed in
the next two or three years and that it must be backwards
compatible by supporting connectivity to and from hosts in
non-upgraded networks.  I also think there is a consensus about
not requiring changes to hosts.

Ideally, that connectivity should be undiminished by the new
architecture, but I think that when any host sends packets to
another host whose address is mapped with LISP/eFIT-APT/Ivip, that
there are likely to be problems with MTU and fragmentation.

That is why I wanted to make it acceptable for a new architecture
to diminish efficiency somewhat - because I think all the
solutions (other than moderate improvements to BGP, which is not a
full solution) involve tunneling and so will have these MTU and
fragmentation problems.