Re: OK, shim6, if we must [Re: [RAM] Ivip (was ViP ...)]

[Robin Whittle <rw at firstpr.com.au>]

Brian Carpenter wrote, in part:

> No. If shim6 was shipping code in the popular operating systems, we could
> start the clock on that evaluation. Since it isn't, it's way too soon
> to say anything.

I think it is fair enough to say that if an AS-end-user or an
ISP has a prefix of IP addresses with a bunch of hosts on these
addresses (especially hosts belonging to another organisation)
and they want to multihome that prefix, then they would much
prefer to do the whole thing with a router and some robust,
global, system such as LISP, Ivip or whatever - rather than have
to configure a bunch of disparate host devices, operating
systems etc. to all respond to some centralised control system
so each SHIM6 system behaved as required.

There is the practical problem of either the ISP or the owner of
all the hosts (and there may be thousands of separate owners,
many of them not very technically adept) making sure they are
all configured correctly.  For instance after re-installing an
operating system, plugging in a new machine etc.  Testing the
SHIM6 system is properly controlled from the single point could
be tricky too.  This is all labour-intensive, full of
administrative hassles across organisational boundaries and
subject to technical error.

Then what if the central control point has to change?  All the
hundreds or thousands of hosts need to be reconfigured.

Customers who own the hosts don't want an ISP administrator
poking around their system, for security reasons.  So the ISP
has to give them explicit instructions on exactly how to
configure their machine - but there could be many operating
systems, different versions of the operating systems, many
different "appliance" devices and so many different ways an IPv6
host might need to be configured, from the users' point of view.
 This is roughly analogous to the ISP having to provide
bullet-proof instructions for people with limited technical
skills on how to configure several versions of Windows and Mac
operating systems to dial into their network.

>> Noel wrote:
>>
>> RW> A architectural-level discussion of why people are unhappy
>> RW> with SHIM6, and how that relates to those inescapable
>> RW> technical drivers, might not be out of place here...
>>
>> I agree.
> 
> First of all, please identify those people. The ones who were
> identified in last year's round of meetings with IAB members have been
> heard from, and their main issue - lack of ISP control over multihoming
> policy - has certainly been heard. As far as I understand the history
> of these discussions, we're here to look for another solution that
> has that property, which would certainly move the control point for
> locator selection out from the host towards the border router
> or beyond.

I agree that we are looking for such a solution.  The only ones
which seem to be available for IPv4, which make no demands such
as changing operating systems are LISP or some similar or
derivative system such as Ivip, which involves tunneling packets
and popping them out with their raw IP addresses in a local
environment where they are routed to their destination host.
The hosts at both ends of the communication are blissfully
unaware of how the packets have been handled in transit.  Each
host with an LISP/Ivip-mapped IP addresses only has that IP
address.

Since it seems that some form of LISP/Ivip/whatever is practical
and since no-one has a better solution to the problem of the BGP
routing table threatening to swamp the DFZ routers in the
uncomfortably near future, I think it is reasonable to believe
that something like LISP/Ivip will be built around the end of
the decade.  However I think we would need to make faster
progress than in the last 6 months to achieve this.

The quotes below are from me.

>> I think a global system for LISP, Ivip or similar will be built.
>>  I think this system will provide good portability
> 
> I'm not sure exactly what you mean by portability.

A primary goal of Ivip - and I assume LISP - is to allow someone
who has an IP address, or a prefix of addresses, to use those
addresses for their host(s) which are either located at "any
ISP", or which are housed in their office, factory etc. and link
to the Net via a link through "any ISP".  "Any ISP" is an ISP
which has an ETR and local routing support for whichever
LISP/Ivip-mapped addresses the customer is using at the time.

The ITRs are a global system which tunnel the packets to
whichever IP address the owner of these hosts chooses - because
the owner of these hosts has some arrangement with the LISP/Ivip
system by which they control that part of the database which
controls how the ITRs tunnel incoming packets whose destination
address is one of their IP addresses.

I think different people in this discussion have different
models of administration of IP addresses, different goals etc.
for how LISP or whatever would be used.  A primary goal I have
is to enable a LISP/Ivip system to provide effectively portable
IP addresses or prefixes to millions or in principle a billion
or two end-users.

This portability between ISP's ETRs - between any ETR in any
edge network - is a prerequisite for multihoming.  LISP or Ivip
enables multihoming by having the customer site have two links
to two ISPs where the ETRs of both ISPs are ready to accept
encapsulated packets and to decapsulate them, and where the
local routing system is ready to forward the packets to the link
to the customer site.  (The ISP's network also needs to accept
outgoing packets and enable those which match BGP advertised
prefixes out to the Net, probably via an ITR so outgoing packets
to LISP/Ivip-mapped addresses don't depend on public-access ITRs
outside the ISP's edge network.)

Then by one means or another, the LISP/Ivip ITRs all over the
world tunnel the packets to one or the other ETR - whatever is
needed to keep the customer site connected when one link or one
ISP goes down.


>> and hopefully
>> TE for ordinary hosts - IPv4 or IPv6 - 
> 
> Hosts aren't interested in TE. That is an enterprise
> network operator, or ISP interest.

It is probably not much of a concern for an end-user with a
single IP address, but the end users of LISP/Ivip would include
a non AS-end-user with one or more LISP/Ivip-mapped addresses
and two or more links to ISPs.  That end-user may find there is
wildly varying incoming traffic for the various LISP/Ivip-mapped
addresses.  Say they want to keep both links from saturating,
they might start off with half of their mapped addresses getting
their packets through the ETR of ISP-A and the other half from
the ETR of ISP-B.  Then when one of their LISP/Ivip mapped
addresses has a very high rate of incoming traffic, they can
keep that on one ETR (say ISP-A's) and change the database to
map the others which used that ETR to use the other ETR of
ISP-B.  This leaves only the busy IP address's traffic on the
link from ISP-A.

With fine-grained, to individual IP address, control like this,
I think there is considerable scope for TE - at least in terms
of incoming load balancing across multiple links, ISPs, ETRs
etc. - simply by switching the database to cause the ITRs to
tunnel packets to a different ETR.  This is without any of the
TE specific constructs of "Weight" or "Priority" in:

  http://tools.ietf.org/html/rfc4271#section-9.1.2

I think these are very powerful constructs, but that they would
impose a huge burden on ITRs and cause the database to be more
complex.

I suspect that some or many people tend to think of LISP
generally dealing with whole prefixes.  I have always thought of
LISP and now Ivip dealing both with prefixes and with individual
IP addresses.


I believe we would have no crisis in routing or addressing - and
still have heaps of IPv4 space free - if the global routing
system could (and was always able to) easily point any IP
address to any edge network.  If the global routing system could
change this reliably and nearly instantly, without any great
cost, that would make full Mobile-IP easy to achieve.  Then, IP
address space could always have been assigned in smaller chunks
and used very efficiently.

We definitely can't do this with the global routing system.  The
propagation of changes is too slow, to unreliable and too
costly.  The RIBs can't handle 3.75 billion separate routes (for
each IP address in the unicast space to 223.255.255.255) and the
FIBs aren't up to this either.

My aim with Ivip is to keep the BPG system approximately where
it is now, to have tens of thousands of ETRs (dumb, cheap and
not needing any coordination) in most ISPs and to have a
globally coordinated, robust, database and ITR system which can
map individual IP addresses - ultimately one or two billion of
them - so packets sent to these addresses are tunneled to any
ETR in the world.

There is a burden on the database, the communications system
(push and pull) and on the ITRs for every change in the mapping.
 So I don't suggest an end-user should be able to flip their
mapping every few minutes without incurring some kind of fee to
help pay for the burden they place on the system.  However, all
such changes are a lot less expensive, faster and vastly more
fine-grained (single IP addresses rather then 256) than is
possible with changing the advertisement of a BGP-prefix.

I see a successful LISP or Ivip system as absolutely necessary
to contain the growth in the global BGP routing table - and that
 it would grow to cover a large proportion of the address space,
using it extremely efficiently, and so enabling a much greater
utilisation of IPv4 address space than is currently the case.

Once this happens, LISP/Ivip-mapped addresses will be much more
portable and generally useful than IPv6 addresses, assuming the
current ban on PI IPv6 space for AS-end-users remains.  As long
as that restriction remains, and as long as there is no
LISP/Ivip system, I believe not many ordinary end-users will
take up IPv6.  (I think China will adopt it because the
government wants each citizen on an individual IP address, where
they can be made responsible for the communications - the
surveillance system is deeply frustrated by NAT.  Also, I expect
IPv6 to be adopted by 3G mobile operators, to support Mobile
Multimedia Subsystem.)

However, if something like LISP/Ivip was created for IPv6, then
lots of end-users, including those who have no ASN and don't
want to fuss with BGP etc. might start adopting IPv6.

I haven't thought much about Ivip for IPv6, but I think it would
be nuts to have ITR' FIB having to look at all 128 bits of
address to determine the IP address the packet needs to be
tunneled to.  Even looking at the most significant 64 bits is a
major cost, but that may be the best granularity to use: map
whole /64 prefixes.


>> without additions to the
>> protocol stack or changes to operating systems. 
> 
> You should know that one of the reasons we took a host based
> approach in developing shim6 was because we saw no sign of
> a proposal to solve the problem in the routing system. So, now
> we have a near-ready host based solution. Why can't we just
> let it become ready and see if it works? Why let shim6 be a
> distraction here?

I believe that SHIM6 won't work for people who want and/or need
portability and multihoming control without having to fuss with
the operating system configuration of all the affected hosts.

So I don't think that we should expect SHIM6 alone to solve the
problem of encouraging widespread adoption of IPv6 without PI
space for AS-end-users.  The only solution I can imagine working
is something like LISP or Ivip.  Widespread adoption of IPv6
with people doing portability and multihoming with their own PI
space being advertised in BGP will quickly bring the IPv6 BGP
system to the same router-swamping state we are facing with IPv4.


  - Robin


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