Subject: [RRG] Comparison table - LISP/APT/Ivip/TRRP

From: Robin Whittle <[email-masked]>
Date: Fri, 24 Aug 2007 18:54:14 +1000

Hi Brian,

I don't have time at present to respond to all the discussions on
this list or on the RAM list which I understand should now move here.

Below is an updated table, including what I currently understand
about TRRP - which may be wrong.

I have not added a Traffic Engineering column, because the various
systems have different approaches to this.  For instance Ivip (and
maybe TRRP) has no explicit TE functions, but could be used for some
TE purposes by splitting traffic up per IP address so one or more IP
addresses is mapped to one ETR with other IP addresses mapped to
other ETRs.

I have added a column for "No delay ITRs".  As per your message:

http://www1.ietf.org/mail-archive/web/ram/current/msg01818.html

I think that any system where packets have to wait while a query
traverses some global system will not be acceptable.  This makes
LISP-CONS global CDR network approach:

   ITR -> CAR -> CDR*n ->
                           CAR (authoritative)
   ITR <- CAR <- CDR*n <-

and TRRP's global DNS approach look really unattractive.

In LISP-NERD every ITR has a copy of the database.  In eFIT-APT, the
ITR can get a response from a local Default Mapper very quickly.
Ivip has some ITRs with a full database and others which cache - the
caching ITRs get responses very quickly from local Query Servers.

You wrote:

> IMHO address "portability" is a bogus criterion, since a
> solution that doesn't require portability shouldn't be measured
> against it.

I have retained Portability because as far as I can see, a
significant number of end-users with substantial networks want and
need to keep the address range of their networks when they change ISP.

  http://www1.ietf.org/mail-archive/web/ram/current/msg01783.html

I think it is mainly - or only - people who are trying to run the
Internet who maintain some hope that end-users will one day not care
about having their entire network renumbered.  I can't imagine why
anyone running a substantial end-user network today would consider
this a possibility.

Perhaps in the distant future when a totally new system beyond IPv4
or IPv6 arrives, maybe they won't care about their entire network
being renumbered - for multihoming service restoration and/or for
mobility and/or for choosing another ISP.

For now, for end-users with substantial IPv4 and IPv6 networks -
those who currently want to, or will want to, get PI space - need
portability.  So I am adamant this is not a bogus criteria for
selecting an architectural upgrade which existing networks are
supposed to be compatible with - in the 0 to 15 year timeframe.

I have added a column for the locus of control of multihoming
service restoration.

  B = Built into protocol = monolithic system.
  E = External MH monitoring system required - the proposed
      architectural addition is a modular component.

  H = Host-level control.
  I = ITRs work independently.
  R = Router level control (Six/One, the CE router).

             SHIM6  Six/  Mobile  LISP-   LISP-   eFIT-  Ivip   TRRP
                    One   IPv6    NERD    CONS    APT

No delay     na     na    na      Y               Y      Y
ITRs

Address
portability                       Y       Y       Y      Y      Y

Multihoming   Y     Y             Y       Y       Y      Y      Y

MH Service
Restoration   BH    BHR           BI      BI      BI     E      E

Provides (1)
Mobility                  Y                              Y*

IPv4 too                          Y       Y       Y      Y      Y

No host                           Y       Y       Y      Y*     Y
changes

(1) Actually provides mobility, rather than being in some way
    compatible with it.

 *  Mobile IPv4 or IPv6 hosts making use of Ivip will need new host
    software.

There are many other things which could be compared, but they don't
fit in a table.

My comparison:

  http://www.firstpr.com.au/ip/ivip/comp/

remains somewhat relevant, but doesn't cover TRRP or the
developments on the RAM and RRG lists since then.  For instance, my
interpretation of:

  http://psg.com/lists/rrg/2007/msg00260.html
  http://psg.com/lists/rrg/2007/msg00264.html

is that a long-term arrangement for LISP-NERD being compatible with
non-upgraded networks is similar or identical to the "anycast ITRs"
approach of Ivip.

All these proposals - LISP, eFIT-APT, Ivip and TRRP - are, in my
view, ugly kludges.  They all have similar problems with tunneling
overhead, fragmentation, breaking traceroute and Path MTU Discovery.
 All but Ivip, in my view, have a problem with the ETRs finding it
extremely onerous to ensure that local source addresses are not
spoofed in the packets they decapsulate:

http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-arch-00.html#anchor67

(I need to respond to Bill Herrin's message about this.)

Assuming we on this list are right in our general consensus that
something must be done in the next few years to stop the growth in
the number of advertised prefixes, while still allowing for general
Internet growth and in particular the growth in the number of
multihomed end-user networks, then (along with modest improvements
to BGP) maybe one of these kludges is a lesser evil than any other
alternative.  But someone would need to do a cost-benefit analysis
of simply building bigger routers compared to introducing one of
these ITR-ETR architectural schemes.

I am not convinced everyone shares this consensus.  Those who don't
are probably not active on this list.  I recently corresponded with
a knowledgeable and communicative fellow on another list who figured
that the current growth in multihomed sites is just the middle of an
S curve (it is difficult in ASCII art):

                                         .....................
                          ...............
                  ........
              ....
            ..
        ....
........

and that it will flatten out before too long, with current and
near-future router capabilities coping with the remaining rate of
growth without any dramatic architectural changes as we are
contemplating.

I don't believe we are near the end of the growth phase of an
S-curve, and I am excited about the ability of Ivip (and potentially
the others) to use IPv4 address space more efficiently.  I am also
excited about Ivip's ability (assuming the database replication can
be done fast enough) to support a dramatically improved form of
mobility for IPv4 and IPv6.

I am unsure about when the rising costs of routers, if that is the
outcome of doing nothing, will be such a problem as to convince a
sufficiently large majority of  people (ISPs mainly, I guess) that
something dramatic needs to be done.

  - Robin

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: "William Herrin" <[email-masked]>
Date: Fri, 24 Aug 2007 19:19:37 -0400

On 8/24/07, Robin Whittle <[email-masked]> wrote:
> They all have similar problems with tunneling

Hi Robin,

What about something like this: http://bill.herrin.us/network/trrp-via.html

> spoofed in the packets they decapsulate:

I may have a deadly problem for you here: If the inner source address
is the outer source address then the fragmentation needed message will
return to the originating host instead of the ITR. Even if the
originating host accepts the size limit offered in fragmentation
needed message and retransmits with the shortened MSS, the packet
won't get there. Why? Because the ITR will add its own header to the
front of the packet, boosting the size back above the path MTU.

The only thing I see that can save outer source = inner source would
be to set the ITR's MTU to the IPv4 minimum MTU, eliminating the
possibility of downstream fragmentation needed messages. 576 bytes?
536 bytes? I forget.

> (I need to respond to Bill Herrin's message about this.)

:)

> traverses some global system will not be acceptable.

I disagree. I assume we expect local-scope routing to behave the same
way it does now, with raw IP packets and an interior protocol
spreading the routes. If so then the systems we're talking about are
directed towards global-scope routes.

When you're trying to get to a remote host like www.google.com, you've
almost always already done a DNS or comparable lookup to get from the
name to an IP address. With TRRP you potentially do three lookups
instead: once for name to IP, once for forward IP to route and once
for return IP to route. That makes the first communication longer,
yes, but its still in the same ballpark and all three lookups benefit
from caching so that later packets between the same endpoints aren't
delayed at all.

But really, this is something we don't need to argue about. Lets put
it to the test and see what happens. If I can get half a dozen or so
volunteers, this is what I'd propose we try:

1. I'll add enough code to the proof of concept ITR to make it
field-usable. Should take me a few weeks; after all I do have a day
job too. :)
2. We'll take a /23 from the swamp that I have parked right now and
each volunteer will announce the whole /23 via BGP. That'll make it
"anycast."
3. The /23 will be broken up into subnets and two will be assigned to
each volunteer.
4. One of each volunteer's subnets will be staticly GRE tunneled to a
fixed destination. This is the "control" group and is intended to
simulate a tunnelling solution where the routing information is
pre-propagated to the ITRs.
5. The other one of each volunteer's subnets will be dropped into the
TRRP ITR and dynamically tunnelled via a DNS lookup as specified in
http://bill.herrin.us/network/trrp.html . That's our experimental
group.
6. Then we'll bang on it and see what the user-observed difference in
performance really is.

Thoughts?

> I recently corresponded with
> S curve

Yikes! If anything, the growth rate of multihoming is heavily
suppressed by indirect registry requirements that you deploy 500 or so
computers before you can multihome. (PI needed to multihome, /22 with
efficient utilization needed to get PI.)

This cuts out the large and growing number of folks who have two
broadband providers in their basement or a broadband and backup dial
provider.

> something dramatic needs to be done.

I suspect Usenet and NNTP would make for a useful case study to
predict how BGP growth is likely to progress and its impact on cost
and stability. Its basically the same structure: take any message
introduced at any node and copy it to all the other nodes each of
which must reasonably index it and make it available to readers.

Regards,
Bill Herrin

-- 
William D. Herrin                  [email-masked]  [email-masked]
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004