Re: [RRG] On the Transitionability of LISP

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

Hi Mark,

Here is what I think will be the deal for people adopting
Ivip-mapped address space, not counting some problems which are
common to LISP, eFIT-APT and Ivip, regarding Path MTU Discovery,
fragmentation and packet overheads:

  Your hosts will be reachable from all hosts, with full
  portability, multihoming and TE (Ivip enables TE simply
  by the user mapping individual IP addresses or small
  subnets to one ETR or the other).

  Paths will be optimal or very close to optimal from
  hosts in networks with ITRs and there should be no
  reduction in bandwidth limits.

  Path lengths from hosts in non-upgraded networks will be
  generally close to optimal depending on where the closest
  anycast ITR is.  Bandwidth limits will depend on the
  load on that particular ITR.

So for Ivip to involve no loss of connectivity, there needs to be a
substantial ITR system which each able to handle whatever load is
placed upon it.  Generally, ISPs will be motivated to run their own
ITRs, since they have paying customers and part of their service
will be to ensure packets leaving their network don't depend on
external ITRs.

Exactly how the administration or economics of anycast ITRs will
work out, I am not sure.  If there are lots of them, then there will
be little incentive for provider and AS-end-user networks to install
their own ITRs.  If there are too few, then there could be capacity
limits or excessive path lengths which would discourage adoption of
Ivip-mapped address space.

The business plan for all these proposals is hard to determine at
such an early stage.

At least Ivip has a robust, simple, technical solution to the
transition period where some or many networks don't have their own
ITRs.  As long as there are some ITRs in the core, Ivip doesn't
require all networks to have their own ITRs.

Ivip doesn't involve trade-offs such as some packets having benefits
and others not, and about when to pull the plug on hosts in
non-upgraded networks.  With the anycast ITR approach, all packets
are handled by ITRs in the same way.

LISP could ensure all packets were handled by an ITR, if the border
router of some network is the sole BGP advertiser of the prefix and
functions as an ITR.  This would involve sub-optimal path lengths
when the ETR was far from this ITR, potential capacity limits and
continued dependence on that network and its border router.  This is
a single point of failure, so the result is not proper multihoming
for packets arriving from networks without ITRs.

If the border router which advertised the prefixes doesn't function
as an ITR, then adopters of LISP-mapped address space have all this
messy stuff to think about:  packets from some hosts have the new
benefits and packets from hosts in non-upgraded networks have none
of the benefits and just go to the one network, which is not
necessarily where the destination host with the LISP-mapped address is.


You wrote:

> One scenario is that LISP-enabled sites actually get proper
> multihoming (so long as both ends are enabled), 

This is multihoming with loss of reachability from a large
proportion of sending hosts, at least in the early stages of adoption.

> but non-LISP sites
> increasingly find that their long-prefix routes are filtered by ISPs
> that buy into LISP.  

I don't understand this.  Why would a network with ITRs and ETRs
want to stop sending packets to networks which don't?

The problem we are discussing is how sending hosts in non-upgraded
networks get their packets to the destination, which can only be
done via an ITR and an ETR.

> It's not that non-LISP sites are unreachable;
> it's just that they're only reachable via the aggregated path, and
> their multihoming doesn't work the way they wish.

I don't understand this - LISP doesn't involve making it impossible
to send packets to networks without ITRs or ETRs.  Unless you are
discussing networks which have invested in ITRs and ETRs trying to
freeze out networks which haven't in order to encourage them to
install LISP ITRs and ETRs.


> A possible early stage of such a transition plan might involve LISP
> sites continuing to advertise their existing long prefixes for their
> multi-homed customers, but marking them with a transitive attribute
> that says "you may drop this route if you do LISP".  Thus LISP-enabled
> networks have smaller routing tables than non-LISP networks.  

This is extra trouble for the LISP-enabled networks for a not
particularly valuable benefit: a reduction in routing table size,
when their routers - like all other routers - are able to handle
however big the global routing table is anyway.


> After
> enough LISP sites exist, they can also start filtering routes with
> long prefixes that are not marked in this way.

I think that what this really means is something like: "When the
LISP-enabled networks decide that the their end-users with
LISP-mapped addresses don't mind not being reachable from hosts in
non-upgraded networks, the network will stop accepting packets from
those non-upgraded networks.


> Anyway, it's premature to fixate on the details of this at this stage;
> the point is that there are transition paths that don't involve making
> prefixes unreachable but rather make then suboptimally reachable.

The LISP transition path results in messy outcomes both for hosts
sending packets and for hosts receiving them on LISP-mapped
addresses.  The "anycast ITRs in the core" provides a much cleaner
outcome, but it involves extra investment.

Initially, to get Ivip off the ground, there wouldn't need to be
thousands of "anycast ITRs in the core" because the traffic volumes
wouldn't be so high.  However, they do need to be pretty widely
spread to avoid overly long paths.  There would need to be a few in
Australia to start with, and an a few in any country which was not
part of the big mesh of connectivity of North America, Europe,
Japan, Korea etc.

  http://www.chrisharrison.net/projects/InternetMap/

 - Robin



--
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