Re: [rrg] Scalable routing problem & architectural enhancements

[[e-mail]]

In einer eMail vom 23.02.2010 07:13:31 Westeuropäische Normalzeit schreibt  
[e-mail]:

Here are the aspects I perceive to the IPv4 routing scaling  problem -
most of which also apply to IPv6.

1 - The growth in  the number of prefixes advertised in the DFZ:

http://bgp.potaroo.net

Currently about 300k  with a doubling time of about 5 years.
This figure  drives several problems:

a - Increasing expense  for each DFZ router due to the
correspondingly high number of prefixes in the FIBs.

b - Potentially greater difficulties updating the FIB, such
as computational cost and/or time the FIB can't be  used
for classifying packets while  updates are applied.

c - extra load on the RIBs  due to the number of prefixes - with
DFZ  routers with more neighbours being more heavily
affected in terms of the CPU and RAM requirements for
maintaining a two-way conversation with each  neighbour
about each  prefix.

d - Exacerbating problems with overall  stability of the DFZ
control  plane.  For instance, a single outage will affect
more prefixes, causing more BGP processing, RIB and  FIB
updating, more BGP changed  announcements etc.  Since
routers  take time to do this, and due to other problems
with the BGP control plane (such as unwanted updates
occurring due to combinations of topology and MRAI  timer
settings) the ability of the  entire system to adapt to
changes and  "converge" is lessened.  "Converge" means
firstly all routers finding best paths which acceptably
forward traffic packets and secondly finding best  paths
which are stable without requiring  any further changes.

2 - Growth in rate of updates to how these  prefixes are announced.
The number of prefixes  represents one dimension of the load on
the BGP  control plane.  Each change adds further load, so the
number of changes in general adds to the routing scaling
problem.  Some changes only require adjustments to best  paths
of a few DFZ routers.  Other changes could,  in principle,
require changes to best path, or at  least changes to the
AS details each DFZ router  announces for the best path (even
if the best path  remains the same) affecting many, most or
all DFZ  routers.

3 - It is widely agreed that the DFZ can and must scale  to handle
the prefixes advertised by ISPs - and that  the scalability
problem is due to unsustainable growth  in the number of EUNs
which advertise their own  prefixes - and in the rates of
change in the way these  prefixes are added.  These prefixes
are "PI"  prefixes.  (I use this term to include an alternative
arrangement with the same impact - an EUN with a PA prefix  from
one ISP causing it to be advertising in the DFZ  by another
ISP.)

4 - Consequently, there  are high barriers to EUNs obtaining PI
space and  advertising it in the DFZ.  These are not high
enough to acceptably constrain the growth in the number of
advertised PI prefixes, but they are already unacceptably
high compared to the need for millions (up to 10  million)
EUNs to gain benefits which are currently  only available via
advertising PI space.

Advertising PI space in the DFZ is the only current method  by
which an EUN can currently obtain the PMHTE  benefits:

Portability - keeping its  space when choosing another ISP.

Multihoming - two or more ISPs with session survivability
when  switching between them to cope with
ISP or link  failure.

Inbound TE -  When two  or more ISPs are used, the ability
to steer incoming traffic -  potentially of
different sorts - between these ISP links  for
the  purposes of load balancing, optimising
costs, latency reliability or other
considerations.

These high barriers reduce the number of EUNs which can  gain
these PMHTE benefits.  These barriers also  increase the costs
of those which are able to use PI  space.

5 - This leads to a more difficult to measure aspect of  the
problem: a large number of EUNs which want or need  PMHTE
benefits and are currently unable to obtain it,  due to the cost
and administrative barriers to  obtaining and advertising PI
space.

6 -  A further aspect of point 5 is that due to the convention of
not propagating prefixes longer then /24 in the IPv4 DFZ -
an EUN needs at least a /24 prefix before it can obtain  PMHTE
benefits.  EUNs probably need multiple /24s  to be able to do
inbound TE.

While the total amount of space used in advertised /24s is
only a fraction of a percent of advertised space, if it  were
somehow possible for millions of EUNs to have  their own PI
prefixes, the /24 limit would cause many  of them to use more
space than they actually  need.  The much higher numbers of
the smallest  prefix - /24s - than any other length indicates
that  the majority of EUNs need 256 IPv4 addresses or less.
(msg06092).



Robin, I appreciate your listing of all these aspects.Indeed, iIt is  not 
only the size of the FIB. It is also work, trouble, cause for making  
mistakes, time,etc.etc., i.e. all what you enlist. Enough reasons to get rid of  
the FIB, i.e. to provide a solution which reduces its size peu à peu until it  
disappears completely (which would happen if the new concept is completely  
deployed). Enough reasons to get rid of any prefix building based  solution!

There  appears to be broad agreement that the solution to these
problems cannot  involve any of:

1 - Souping up all DFZ routers with faster route  processors,
bigger FIB capacity etc.  (This will  continue, but the
current rates of growth in the DFZ  and the growing number
of EUNs which can't get PMHTE  benefits, together with the
increased costs for all  DFZ router operators of paying for
these more capable  routers constitutes the ongoing nature
of the routing  scaling problem.)
right.



2 - Replacing the DFZ with anything fundamentally  different.
Firstly, it is not clear what would work  better than BGP.
Secondly, if something different  would work better - there
seem to be insurmountable  barriers to adopting it.
wrong, if you mean a "fundamentally different solution"  (it is  not clear 
to me what the words "replacing the DFZ" means). Any  fundamentally 
different solution can only be deployed thanks to  BGP ! 
What if it only takes a tiny enhancement of BGP (whose vendor-specific  
enwrapping is already provided by BGP for some  decade ? 
 
 





3 - Erecting financial or administrative barriers to  EUNs obtaining
PI space and advertising it in the  DFZ.  This would be
administratively difficult,  would introduce competition
policy problems and would  merely contain one aspect of the
scaling problem (the  growth in the number of DFZ prefixes)
by worsening the  other aspects: the number of EUNs which can't
get  PMHTE benefits and the higher costs incurred by those who
are able to advertise PI space.
right



4 - Solutions to the "portability" problem along the  lines of
EUNs not having truly portable space (or in a  CEE architecture,
not having portable host  identifiers) and having some
supposedly "acceptable"  means of automatically renumbering
the hosts and  routers in their networks, when changing ISPs.
For  many networks, no such mechanism can come close to the
benefits of true portability, because the IP addresses of their
network and hosts may be stored in many other places  beyond
their control, such as ACLs.

For example, a university may subscribe to many journals  and
the journal sites give free access to hosts in the  university's
address prefix - using a simple  router-based ACL.  Changing
the address range of  the entire university network, to use a
new ISP, would  involve complex, expensive and error prone
administrative costs for the universities and all the journals
it subscribes to.


Therefore, a solution to the IPv4  routing scaling problem would
involve, some combination of the  following:

1 - Large numbers of EUNs being able to gain PMHTE -  Portability,
Multi-Homing and inbound TE - for their  networks in a manner
which placed little extra burden  on the DFZ control plane
in general, and on the RIBs  and FIBs of DFZ routers.
Above, I forgot to mention, let's get rid of any RIB. 
But you are right: Multihomig, which is just a particular aspect of   
multipath should be enabled
and, yes,portability. Imagine even the endusers being nodes and being  
nodes which permanently roam around! 
,



There is no consensus on numbers of  such EUNs with fixed
networks which will want or need  PMHTE benefits - but Brian
Carpenter and I have  independently suggested 10 million as a
long-term  upper bound.  (BC msg05801).  The RADIR Problem
Statement refers to "millions": "there are millions of
potential end sites which would benefit from being able to
multihome".

I suggest a solution which isn't limited at all.


2 - Current EUNs with PI space being able to adopt - and  actually
adopting - some scalable alternative to their  current PI
arrangements.  Likewise, EUNs which in  the future would
in the absence of a solution, would  advertise PI space in
the DFZ.

However, the  solution must not involve any of:

1 - Less efficient use of IPv4  address space.  (This rules
out CEE, since a  CEE-using EUN with N hosts requires at
least N  addresses from each ISP.)
right



2 - Changes to host stacks or applications - since  this would
rule out the possibility of the changes  being widely enough
adopted to solve the scaling  problem.  
right. imho the solution should not depend on host changes, but also  
shouldn't bother host changes either.

See:

List of constraints on a  successful scalable routing solution
which result from  the need for widespread voluntary adoption
http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/

3 -  Assuming that IPv4 usage will decline (as most end-users
migrate to IPv6 and no longer need IPv4 space) fast enough
to make the IPv4 scaling problem not worth  solving.

Future trends for the IPv4 routing scaling problem are the  subject of
debate.  Some argue that since IPv4 space is running out  rapidly that
migration to IPv6 must begin soon and that therefore the  routing
scaling problem in IPv4 will become either less significant  and/or
will not grow as fast as in the past.
The IAB RAWS report mentions that IPv6 will increase the scalability  
problem by factor 4.



I believe the growth will accelerate as there is more  slicing and
dicing of the available space to use it with more total hosts  -
driving up the number of prefixes in the DFZ, of both EUNs and  ISPs.
See the (msg05946) thread mentioned below for more on this.

In  several recent RRG messages (sorry, I don't have their numbers
handy)  people have expressed the view that IPv4 will be important for
a very long  time, or indefinitely.

I believe that attempting to solve the IPv4  routing scaling problem
by solving the IPv6 routing scaling problem and  moving the great
majority of end-users to IPv6 would be analogous to  solving the
Earth's global warming problem by solving any such problems on  Mars -
and assuming that most of humanity will move to Mars since Earth  is
so obviously over-crowded.


Since we can only develop and  suggest the adoption of technologies to
solve the routing scaling problem,  and since it seems we need wide
adoption (such as 90% percent or more) to  substantially solve the
problem - considering the two or more orders of  magnitude difference
between the current 300k prefixes and a likely 10  million figure - we
face some "constraints due to the need for widespread  voluntary
adoption".  Please see my page where I attempt to describe  these -
which has been improved after some RRG discussions:

_http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/_ 
(http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/) 

Here my comments end, because I do not believe in IPv6 (which  doesn't 
relate to some specific services and capabilities which are  currently developed 
only in IPv6).
Heiner 




IPv6 scaling problem and solution  constraints
---------------------------------------------

The IPv6  Internet currently has no scaling problem.  For a fuller
discussion,  please see the thread:

IPv4 & IPv6 routing scaling  problems
http://www.ietf.org/mail-archive/web/rrg/current/msg05946.html

The IPv6 Internet has no scaling problem:

http://bgp.potaroo.net/v6/as2.0/
http://bgp.potaroo.net/v6/as6447/

These indicate  about 2.6k prefixes with a doubling time
of about 20  months.  At these rates it would take 11.4
years  (2021) for this measure of the IPv6 scaling problem
to  reach the level of today's IPv4 scaling problem.  By
then, at the current growth rates, the IPv4 figure  would
be about 1.46 million.

The IPv6 scalable  routing problem - if and when it arises - is in
principle the same as  IPv4's.  However, there are some differing
constraints on the IPv6  solution - and potentially some different
techniques which are applicable  to IPv6 which won't work on IPv6.

The constraints on IPv4 solutions due  to shortage of global unicast
address space don't apply to IPv6.  So  CEE architectures could solve
the IPv6 problem.  CEE architectures are  wasteful of global unicast
address space, since each multihomed EUN with a  /X prefix of IP
address space for the Locators of its hosts needs to obtain  a /X PA
prefix from each of its upstream ISPs.  Also, some CEE  architectures
implement Locator / Identifier Separation by encoding both  the host's
Identifier and its Locator into the one IPv6 address.

The  Modified Header Forwarding techniques of Ivip - alternatives  to
encapsulation for tunneling packets from ITRs to ETRs - are  different
for IPv4 and IPv6:

http://tools.ietf.org/html/draft-whittle-ivip-etr-addr-forw
http://www.firstpr.com.au/ip/ivip/PLF-for-IPv6/

Also, with IPv6's much  lower base of hosts and routers - and with the
lesser urgency of widely  deploying a solution - there is probably a
lot more scope than in IPv4 for  upgrading routers (including DFZ
routers), host stacks and perhaps  applications.  Still, I believe
that requiring applications to be  altered in any way presents the
greatest of all barriers to adoption.   This is particularly the case
for the updates which would be required for  an IPv4 or IPv6
application to use the CEE naming model - Locator /  Identity
Separation.  This may be easy for some applications, but  would
require fundamental changes to protocols for others.

It is not  absolutely necessary that the IPv4 and IPv6 routing scaling
problems be  solved in the same way.  However, the task of making
applications run  on these systems at the same time - or at least that
the one code-base and  set of basic application protocols could work
on all these  systems:

IPv4
IPv4 with scalability  solution

IPv6
IPv6 with scalability  solution

is a further argument against CEE.  Only CES  architectures require no
changes to applications or stacks.  It would  be wildly unrealistic to
expect all IPv4 applications to be altered in any  way - for any
reason at all, including scalable routing.  Of the CEE  RRG proposals,
only GLI-Split requires no changes to IPv6 applications -  but I am
not yet convinced it will work.  (I am yet to get a response  from
Michael Menth and colleagues to my msg06056.)


Other  problems and goals
========================

I think it would be  irresponsible and impractical to develop and
attempt to deploy  architectural enhancements - each a once in several
decades opportunity for  improving the IPv4 and IPv6 Internets - for
the purpose of solving only a  subset of these problems:


IPv4:   Routing  scalability
Address  exhaustion
Mobility


IPv6:   Routing  scalability
Mobility

IPv4  address exhaustion and Mobility are discussed in sections below.

The  forthcoming enhancements must be an effective solution for all
three IPv4  problems and both IPv6 problems.

First I want to mention some other  potential problems which an
architectural enhancement might allow (or be  constrained by), since
the IPv4 and IPv6 Internets face pressing problems  beyond those
listed above.


Computer  Security
-----------------

There are general problems of computer  security, the ability of
attackers to directly gain control of hosts, or  trick their users
into giving them control - but these do not seem to be  amenable to
solution in the network itself.


DoS and other  attacks
---------------------

There is a general, very serious,  problem with the ability of
attackers to mount DoS and other attacks which  disrupt Internet
communications.

This is largely a function of the  ability of attackers to assemble
(or hire the services of) immense botnets  of hundreds or thousands or
millions of compromised hosts, each capable of  firing out packets to
the target.  This is largely a function of the  number of
Net-connected computers, the insecurity of their operating  systems
and applications, and the lack or care and expertise of their  owners.
The widespread adoption of faster DSL services - and  especially
fibre services with much faster upstream links than are possible  with
DSL, HFC cable or wireless links - will make this problem even  worse.

If it looks like there might be some method of reducing this  problem
as part of an architectural enhancement, I think this should  be
explored.  The ability of a CES architecture such as Ivip or LISP  to
in some way help with this problem has not really been explored  as
far as I know.  I am not sure there is a way of doing so - but  it
should be investigated as CES architectures are further  developed.


Path MTU Discovery and packet length  limits
-------------------------------------------

This is a whole  can of worms for IPv4 and IPv6.  Please refer to  the
thread:

Fred's IPv4 PMTUD research: RFC1191 support  frequently broken
http://www.ietf.org/mail-archive/web/rrg/current/msg05910.html

for more  information.

PMTUD problem apparently cause minor data loss today on  IPv4.  The
problems generally involves some tunnels and networks  either not
producing PTBs (Packet To Big messages) or dropping them  with
filters.  There may also be a problem with some hosts (stacks  and/or
applications?) not responding properly to PTBs.

These  problems lead to workarounds in which packet lengths are
artificially  limited - which means that it will be impossible to use
~9k byte jumboframe  paths across the DFZ as these become available.
In short, the current  situation seems to indefinitely lock us into
slightly sub-1500 byte  packets.

There are several worrying things about this.  Firstly,  the problems
result usually as a combination of circumstances - and can  be
difficult to recognise, debug and isolate to the level of  identifying
which ISP or other network did the wrong thing with their  tunnel
arrangements and/or over-zealous ICMP filtering.

Secondly,  each person who encounters these problems tends to adopt
quick-fixes which  mask the fundamental problems - thereby enabling
the problems to continue  and proliferate, while locking us more and
more into sub-1500 byte packet  lengths indefinitely.

Thirdly, neither CES nor CEE routing scaling  problems offer any
solution to these problems.

Finally, and most  troubling, CES architectures need to use
encapsulation between ITRs and  ETRs - unless one of Ivip's Modified
Header Forwarding techniques can be  deployed, by upgrading all DFZ
routers, before the Ivip CES architecture  itself is deployed.  (In
the long-term Ivip should be able to  transition from encapsulation to
MHF.)  So PMTUD problems may make it  significantly more difficult to
introduce a CES architecture.

I am  unsure how serious these problems will be - but ITRs will need
to be able  to send PTBs to sending hosts and have the sending hosts
respond with  suitably shortened packets.  If the ITR is outside some
network where  the sending host doesn't get these PTBs due to
over-zealous filtering of  incoming ICMPs by that network, then this
will cause real difficulties with  the CES architecture.  The CES
tunneling will frequently reduce packet  sizes below what most
networks are used to getting at present.

There  is only one proper answer to this situation - removing the
overzealous  filtering.  Placing the ITR in the network would fix this
problem -  but make it harder (not impossible, at least with Ivip's
IPTM arrangement)  to do PMTUD for the tunnel to the ETR, because then
the overzealous  filtering would drop PTBs coming from routers in any
part of the ITR to ETR  tunnel.

Tunnels in the DFZ or other networks which are part of the  ITR-->ETR
tunnel and which either don't produce valid PTBs, or only  produce
them on the second or subsequent occasion they drop a packet, make  it
more difficult for ITRs to successfully judge the Path MTU to  the
ETR.  This is not insurmountable - but it delays the ability of  the
ITR to correctly inform the sending host of the MTU it must  use.

My view is that these PMTUD problems arise from people doing  things
which are at odds with the Internet standards, and for which there  is
no reasonable means of coping defensively.  So I believe it would  be
easier and better to identify these bad practices and have  these
problems fixed, rather than crafting new protocols, such as RFC  4821,
to "route around" the problems.   Fred Templin has a  different view.

I think the PMTUD difficulties are probably worthy of a  concerted
research response along the lines of the current phase of  scalable
routing research, which was kicked off by the 2006 RAWS conference  in
Amsterdam.


IPv4 address exhaustion and efficient  utilization
-------------------------------------------------

This  is a far more pressing and well accepted problem than  scalable
routing.  It is pretty much common knowledge amongst all IT  people,
while scalable routing is not so widely known.  Also, I think,  even
some within the field regard it as a non-problem - well within  the
capability of normal (Moore's law etc.) router  technological
improvements.

I believe that a successful IPv4  scalable routing solution will, to
the maximum extent possible, "solve" the  address exhaustion problem
by allowing very high rates of utilization - the  percentage of
actively used IPv4 addresses out of each advertised  prefix.  Each
IPv4 address may be used for a single host, a NAT box at  the end of
DSL, fibre, HFC or wireless service, or a single mobile  host.

I believe the only class of solutions which can work for IPv4 are  CES
solutions and of the CES RRG proposals, only Ivip or LISP could  be
successful.  (APT could also work, I think, but it is no longer  being
developed.)

Both Ivip and LISP enable the slicing of "edge"  space (SPI for Ivip,
EID for LISP) down to separately mapped chunks as  small as a single
IPv4 address ("/32").  Ivip's micronets can be any  integer number of
IPv4 addresses, while LISP only works in power-of-two  prefixes.  But
both could, in principle and in practice, scalably  allow "edge" space
to be used very flexibly and with a close to 100%  utilization level.

This won't forever solve the IPv4 address shortage  problem.  But
considering the improvements which can be made to  utilization in this
manner, and the fact that only about 2.2 billion IPv4  addresses are
so far advertised, out of a total advertisable global unicast  range
of 3.7 billion:

"Advertised Address Space"  in:
http://bgp.potaroo.net/bgprpts/rva-index.html

I think the  successful adoption of a CES architecture such as Ivip or
LISP will give us  another 10 or more years of IPv4 usage without
really "running out" of  addresses *except* for the desire to give 5
billion or more mobile devices  their own global unicast scalable (SPI
or EID) "edge" address.  Most  of those billions of mobile IP devices
are going to have to work either  behind NAT for IPv4 and/or on IPv6.

Since I believe only Ivip or LISP  or the like could solve the IPv4
routing scaling problem, and since I  believe each would offer the
best possible means of maximising IPv4 address  utilization, I don't
think anything further needs to be done regarding this  problem.

Indeed, I think that the IPv4 address shortage will probably  drive
the adoption of Ivip or LISP for non-mobile networks wanting  PMHTE
benefits who don't need large amounts of space and/or which  don't
want to get PI space, advertise it in the DFZ  etc.


Mobility
--------

While no-one has data about the  future, I consider these trends:

Ubiquitous adoption of  digital mobile telephony in developed
and developing  nations.

Miniaturization of computers into hand-held  devices for many
purposes, including playing sound and video,  for telephony,
instant messaging (SMS texts and Internet IM  protocols),
web-browsing and other Internet applications,  micro-payment
systems, GPS capabilities, Bluetooth connections  to other
devices etc. etc.

Ubiquitous  adoption of Internet communications in developed
and  developing nations.

to be analogous to several freight trains  approaching the one
junction at full-throttle.

One doesn't need a  crystal ball ("data about the future") to be sure
that billions of  end-users will soon want Internet access on their
hand-held devices  (phones, pads, netbooks, laptops or whatever) AND
that they will want the  effective identity of their computer, and its
ongoing communication  sessions, to persist despite the device
automatically and frequently  connecting to the Internet by a wide
variety of physical link technologies  and through various access
networks.  Many of these connections will  be completely ad-hoc - such
as a 3G network via roaming arrangements in a  foreign country, or
using a WiFi service automatically, or with very little  user
interaction, simply by being in range of a free service in a  public
place.

I consider the upper limit for the number of these  devices to be
approximately 10 billion - one or (sometimes two or more) for  pretty
much every person on Earth, plus devices for selected pets,  cars,
point of sale terminals, vending machines, trucks in vehicle  tracking
systems etc.

Many of these devices will connect to IPv4  behind NAT, which
precludes the use of conventional mobile IP  techniques.  NAT will
hopefully not be used for IPv6.

LISP  proposes a form of mobility by which the MN (Mobile Node) acts
as its own  ETR.  But there are many problems with this, not least its
inability  to work behind NAT and the need for each MN to have an IPv4
address of EID  space and its own IPv4 address of RLOC space.  See the
end  of:

http://www.firstpr.com.au/ip/ivip/lisp-links/#critiques


As far as I  know, the only way of adequately solving the Mobility
problem - at least as  I understand it, for IPv4 and IPv6, with hosts
accessing many networks on  an ad-hoc basis, including behind one or
more layers of NAT - is the TTR  Mobility architecture:

http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf

This is an extension  to Ivip or perhaps to LISP.  Mapping changes are
not required for each  new host address.  Mapping changes would be
infrequent for most MNs,  since they are only needed (and even then,
not absolutely required) when  the MN moves more than 1000km or so.

TTR Mobility doesn't require any  new elaboration of the basic Ivip
architecture - though it would require  many more micronets - up to 10
billion or so, rather than the 10 million or  so required without
mobility.

Because of this, I don't see Mobility  as being an extra burden on the
enhancement - as long as the enhancement is  a CES architecture such
as Ivip or perhaps LISP.

CEE architectures  theoretically support mobility, but not for IPv4,
not with the MN behind  NAT - and at the cost of the MN having to do
much more routing and  addressing work than the relatively simple
extra responsibilities it has in  the TTR Mobility architecture.


Solutions
=========

I plan  to write a separate message about this, but the short version  is:

Many RRG "proposals" are not complete proposals for  scalable
routing and can ignored.

Three proposals are  are potential solutions, and are not CEE or CES
architectures:  "Aggregation with Increasing Scopes" (AIS -
Evolution), hIPv4 and  Name Overlay (NOL).  I believe these are not
practical  solutions.

There are four CEE proposals:

GLI-Split
ILNP
Name-Based Sockets
RANGI

These are only applicable to IPv6, and they all  require host stack
changes.  All but GLI-Split require upgraded  applications.  All of
them only provide substantial benefits to  adoptors and substantial
routing scaling benefits after essentially  all hosts (and therefore
all applications) adopt the new  system.  These are extraordinarily
high adoption barriers which  preclude them from being seriously
considered, since there are CES  architectures which could solve
the scaling problems and provide  mobility.  Even if there were no
such barriers, I would oppose  them because I believe their
Locator / Identifier Separation naming  model would decrease the
speed of session establishment and  unreasonably burden all hosts
with extra traffic and  responsibilities.  That said, I am not
yet convinced any of  these proposals would work as well as their
proponents intend.   See (msg05865).

This leaves four CES  architectures:

LISP (currently LISP-ALT, but perhaps in  the future
with another mapping  system)

Ivip (I will soon describe a Distributed Real  Time Mapping
System which will be  suitable for Ivip and LISP.)

TIDR

IRON-RANGER

TIDR doesn't solve the scaling problem, because the  traffic
handling and mapping distribution is done by DFZ  routers.

I think IRON-RANGER needs a lot of work before the  scaling
and security problems inherent in its continual process  of
EID prefix registration with VP routers can be  understood
and shown to be resolved.  I think it also lacks  technical
and business arrangements for supporting packets sent  from
non-upgraded networks.

That leaves LISP and  Ivip.  For reasons I won't repeat here,
I believe Ivip would be  a good solution to the problems
discussed here and that LISP in  anything like its current form
would be a poor solution.  FWIW,  if APT were still under
development, I would consider it better than  LISP, since
like Ivip, it uses local full-database query servers  to
avoid delaying or dropping initial packets.


Other  work
==========

Please see the RADIR Problem  Statement:

http://tools.ietf.org/html/draft-narten-radir-problem-statement-05

and  my comments on it, which I will post after this message.  This
message  also contains pointers to the RRG Goals  ID.















_______________________________________________
rrg  mailing  list
[e-mail]
http://www.irtf.org/mailman/listinfo/rrg