Re: [RRG] On the Transitionability of LISP

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

Hi Brian,

You compared SHIM6 with LISP, and by implication with Ivip (with
your mention of anycast, in the context of Christian's discussion of
Ivip's "anycast ITRs in the core".

> I think this is more deployable than coordinating an anycast
> solution.

Within the restricted scope that SHIM6 operates, it may be easier to
deploy than a bunch of anycast ITRs for IPv4 and/or IPv6.  SHIM6
only involves IPv6 hosts, and it is assumed that it is feasible to
upgrade their operating systems with SHIM6 code, whenever that
becomes finalised.

However, LISP, eFIT-APT and Ivip all solve a much broader set of
problems than SHIM6 solves.  Here is a table:


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

Address
portability                       Y       Y       Y      Y

Multihoming   Y     Y             Y       Y       Y      Y

Mobility                  Y                              Y*

IPv4 too                          Y       Y       Y      Y

No host                           Y       Y       Y      Y*
changes

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

There are various administrative and business questions to be solved
regarding who is going to run a database system - and in the case of
Ivip, who is going to run anycast ITRs.  Considering the problems
this would solve, I think it would be easier to solve these business
problems than change all host software, change everyone over to IPv6
etc.

I think that it might be a profitable enterprise right now to create
an Ivip system, with TTRs and ITRs combined, all over the Net.  Then
rent out the space it maps, in single IP addresses or any larger
number - prefixes or arbitrary contiguous sets of addresses.  The
end-user either uses special software to tunnel to the nearest TTR,
which saves them trying to send packets in their current provider
network with source address = an Ivip-mapped address.

Alternatively, if they can get their packets out OK, they can have a
little software and be their own ETR.

(This assumes that the problems of MTU limits, fragmentation, PMTUD
etc. are solved - they are common problems for LISP and eFIT-APT
too. It also assumes a good method is devised of getting mapping
data out to all the ITRs in a few seconds.  I think this is feasible.)

This would be more profitable once supplies of fresh IPv4 space dry up.

The operators wouldn't need to wait for IETF standards - they could
make their own protocols, and also provide a multihoming monitoring
system with hooks into the database.

On one hand, I wonder - who is going to build these ITRs?  On the
other, I could imagine one or more companies doing it and making money.


Hi David,

You wrote:

> This would seem to be incorrect. There is no reason that
> early adopters need withdraw their "legacy" routes from
> the DFZ until it makes sense. So legacy sites reach the
> site via the legacy system, and the upgraded sites use
> the new mechanism. You could even have example.com
> (legacy) and example-new.com (or whatever). Or both,
> depending on what makes sense.

Then during transition, there is no removal of prefixes from the
global BGP routing table.  (There can still be benefits, because if
you use the system appropriately, I think you can serve more
end-users in a given space than with the old BGP-based techniques.)

During transition, you have a mixed bag of results.  You only get
portability, multihoming and TE for packets from upgraded networks -
unless the border router of the site acts as an ITR.

If it does act as an ITR, then you get sub-optimal paths if the ETR
for some EID in the space is somewhere distant.

For instance, if the sending host in a non-upgraded network is in
Sydney, the ITR is a border router in San Francisco, and the ETR is
in Melbourne, packets have to cross the Pacific twice to get from
Sydney to Melbourne.

Ivip proposes to solves this by having ITRs not too far from most
non-upgraded networks.  An ITR somewhere in Sydney would solve the
problem and give close to optimal path lengths.

If your border router is not an ITR, then you have portability,
multihoming and TE only for packets sent from hosts in LISP-upgraded
networks.

You can't remove the BGP advertisement until you don't care about
the small number of hosts in non-upgraded networks who won't be able
to reach any of the hosts in the address range.  So the transition
time would be very long indeed - until you could somehow convince
almost all networks to install their own ITR.

I think it would be easier to put anycast ITRs in the core than to
try to get people to use address space in a system which produced
half-baked results.

I have no clear understanding of what a LISP "proxy aggregator" is.
 Can you explain it, perhaps with a diagram and examples, rather
than a few terse words, which is all I remember about Vince's
mention of it some time ago on the RAM list?


Hi Christian,

You wrote, in part:

> There is a transition problem with any ID/locator split mechanism
> that requires mapping functions both locally at an edge network,
> and remotely at any correspondent edge network that the former
> edge network may exchange traffic with.  One such mechanism is
> LISP, where the local and remote mapping functions each take the
>  form of an ITR/ETR pair.
>
> The requirement for support on both sides implies that an
> "upgraded" edge network using mapped IDs will no longer be
> reachable from "legacy" edge networks that do not yet support the
> mapping.  This is a disincentive for edge networks to adopt the
> ID/locator split mechanism during an early transition stage.

This is the basic problem with LISP, unless one of the workarounds
is adopted, both involving continued BGP advertisement of the whole
block of addresses which is being subject to LISP mapping.

1 - Get packets from non-upgraded networks to the border router
    and then only be able to transport them in that network,
    which means that if the end-user's host or network is in
    another network, they have no connectivity from hosts in
    non-upgraded networks.  This is the ordinary border router
    option.  It means there is no portability, multihoming etc.
    for packets from non-upgraded networks - which I think makes
    it highly unattractive for anyone thinking of using LISP
    mapped addresses and taking their network to some other
    network than wherever this border router is located - which
    is the whole point of portability, multihoming and TE.

2 - The "border router is the ITR for the world for this block
    of LISP-mapped addresses" approach, which involves highly
    sub-optimal path lengths if the ETR is far from the
    border router.

3 - Adopt Ivip's "anycast ITRs in the core" idea . . .

> The only way I see to get around this disincentive is the approach
> of Ivip:  Decouple the remote mapping function from potential
> correspondent edge networks, move it further into transit space,
> and use anycast IDs to reach it.

Yes - the address block which is XXX-mapped, or rather all such
address blocks, are advertised by multiple BGP routers all over the
Net, operated probably by multiple ASes, at their border routers, or
as ITRs sitting as islands in the midst of transit routers and
border routers of other providers etc.

It doesn't matter technically who runs them.  Each such router has
its own IP address from which it tunnels the packets to the
appropriate ETRs.

> (The reason one needs anycast IDs is to let multiple alternative
> providers perform the same remote mapping for an edge network.

> Unicast IDs would bind the remote mapping to a single provider.

That is the option 2 above there is only one ITR advertising the
address block, which is run by one provider.

> This would create a dependency of the edge network on that
> provider, which is exactly what we want to avoid with
> multi-homing.)

Yes.  So there needs to be a generally highly reliable global
network of ITRs, some run inside networks, other as anycast BGP
routers catching packets from nearby non-upgraded networks.  Then
they all need to tunnel according to some centralised/distributed,
database and replication system.  All end-users trust the
connectivity of their system to all this machinery, and to the
business survival of whoever runs it.


> A side effect of anycast IDs is a change in the Internet business
> model. Edge networks today only need business relationships with
> providers they directly connect to.  A transition towards mapped
> anycast IDs would require an edge network to additionally
> subscribe to the remote-mapping service of multiple providers
> further inside transit space.

I think you mean that an edge network runs an ITR, and the ITR needs
to get database updates from multiple organisations each of whom
control the mapping for one of the many blocks of Ivip-mapped
address space.

I think this involves assumptions about who controls the various
sections of the entire mapping database.  In the Ivip I-D, I propose
a tree-structured set of Update Authorisation System, where one Root
Update Authorization System RUAS is authoritative for one Ivip
Mapped Address Block (IMAB).  There could me many such IMABs.  I
suppose that each IMAP must have been assigned by an RIR to some AS
- so that means the RUAS for that IMAB is run by, or authorised by,
that AS.

However, maybe each RIR runs multiple IMABs, all controlled by its
one RUAS.  Then it can deal out IP address space in arbitrary sizes,
down to single IP addresses.

This represents a significant extension of the RIR activities, but
maybe they do it by assigning the space to some reasonably stable
consortium, which itself is unlikely to fail in business.  Then,
end-users who get some of the space within each such IMAB are
dealing with some more substantial and stable thing than a mere ISP,
which could be taken over, go bankrupt etc.


> As many as possible remote-mapping subscriptions would be needed
> per edge network to limit the increase in packet propagation
> delays, which the new, triangular routes via a remote-mapping
> provider would entail.

Maybe you mean "there must be lots of ITRs so packets don't go
far before finding one"?

> Coordination would be required between remote-mapping providers.
> The providers would need to jointly administer a large,
> aggregatable block of anycast IDs, and consistently map slices of
> this to the locators of subscribing edge networks.

I don't understand these paragraphs.

If you could express it with terminology similar to that in the Ivip
I-D, or contrast what you are trying to describe with what I
describe in the I-D, that would help.   You may be describing
exactly what I am describing, but using different words.


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




--
to unsubscribe send a message to rrg-request@psg.com 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