Subject: [RRG] Map-encap can & will reduce the cost of multihoming

From: Robin Whittle <[email-masked]>
Date: Fri, 27 Jun 2008 01:16:16 +1000

Hi Yakov,

In "Re: [RRG] Long term clean-slate only for the RRG?" you wrote
some critical things about LISP.

I am defending the map-encap schemes - LISP, APT, my own Ivip and
probably Bill Herrin's TRRP - against the negative judgements you
seem to have made about LISP and perhaps about map-encap schemes in
general.

You wrote, quoting Dino:

(Some text omitted.)
>> The routing table size problem is not the only problem. 
> 
> Good. So, at least we seems to agree that we do not need LISP
> to deal with the routing table size.

That is not what Dino meant, I am sure.

Since the map-encap schemes can be used to serve a large number of
end-user networks (generally those requiring smaller amounts of
space) from a single BGP advertised prefix, they certainly can
reduce the DFZ routing table size for any given number of multihomed
end-user networks.  This remains true for many more end-user
networks using the map-encap approach compared to the limited number
who have so far been able to gain conventional BGP-managed PI space.

I believe a map-encap scheme *should* be used to achieve this, since
the bloat in the DFZ global routing table is a major cost burden on
the entire Internet, shouldered initially via the providers who run
the DFZ routers.

There is a need to reduce this bloat, and so far, the map-encap
schemes are the only potentially practical proposals for IPv4.
Likewise for IPv6, except that Six/One Router (a router-based
translation scheme) may be practical for IPv6.

>> There are many  
>> enterprise sites that want to do low-cost multihoming, they want to be  
>> good citizens to the Internet and don't want to inject more specifics,  
>> and they want to control their ingress traffic flows.
> 
> LISP is *not* going to reduce the cost of multi-homing. To the
> contrary, LISP is going to make the cost of multihoming higher than
> it is today. This is because deploying and operating additional
> infrastructure/mechanisms to support LISP has its own (non-zero)
> cost.

LISP and Ivip have clearly defined methods of supporting multihoming
without requiring any ITRs in the networks of the sending hosts.
For Ivip, this is OITRDs (Open ITRs in the DFZ).  For LISP it is
Proxy Tunnel Routers (PTRs).  APT and I think TRRP have their own
approaches to support of packets from non-upgraded networks.
However, I think APT has some problems, unless there is a single APT
"island".  More information on this and other distinctions between
the map-encap schemes is at:

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

Very large numbers of end-user networks - including large ones but
also many who only need small amounts of space (one IPv4 address,
two, four or whatever) - can be served by the one map-encap
infrastructure.  OITRDs and PTRs need to be placed around the world,
in order that packet paths are generally short no matter where the
sending host (in an unmodified network) is and where the ETR is of
the end-user network.

BGP, in practice, is only able to slice IPv4 space as fine as 256
address subnets.  (I know this administrative, but it is unlikely to
be changed in the foreseeable future.)  Map-encap schemes can slice
down to 1 IPv4 address.  This means the cost of multihoming can be
much less, since there is no need for the end-user network to obtain
space from an RIR, since they only need small amounts of space in
general, since they don't need to field a BGP router, or use BGP
resources of their ISPs' routers and since they don't need BGP
expertise.

> Moreover, LISP would would place this cost not only on the enterprises
> that want to do multihoming, but on other parties as well (which
> would result in mis-alignment of cost relative to benefits).

If you read about LISP PTRs and Ivip's OITRDs:

  http://www.firstpr.com.au/ip/ivip/
  http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf

you will see that hosts in non-upgraded networks have their packets
caught in the DFZ by the nearest PTR or OITRD, and tunnelled to the
correct ETR.  This involves no cost or involvement at all in the
sending host's network.  The end-user networks therefore find all
incoming packets subject to the map-encap systems multihoming,
portability and TE arrangements: packets sent from networks with and
without ITRs.

There is no LISP home page, but there is a list of the LISP Internet
Drafts at:

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

PTRs are described in:

  http://tools.ietf.org/html/draft-lewis-lisp-interworking-00

 - 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