Re: [RRG] On the Transitionability of LISP

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

I am responding to Noel and Christian.

Noel Chiappa wrote:

> > From: Christian Vogt <christian.vogt@nomadiclab.com>
> 
> > I do agree that, to remain reachable, upgraded edge networks would have
> > to use their old locator space in addition to the new ID space. 
> 
> The whole issue of what routes need to be carried where is a complex one;
> alas, no time/energy to explore it in depth now. It depends a lot on the
> exact operational details, so changing them changes the picture.
> 
> However, I don't think the picture is this dire (at least in this area - a
> bigger issue, IIRC, is getting to legacy networks from inside areas of the
> network that have converted).

As far as I know, there is no problem getting a packet out from a
network with LISP, eFIT-APT or Ivip ITRs and or ETRs to a host in
any other network where that host's address is not part of the LISP,
eFIT-APT or Ivip mapping system.  The outgoing packet is not touched
by any ITR or ETR function in any router it passes through.

The problem is getting packets sent by hosts in networks without an
ITR to an ITR so it can be tunneled to whatever ETR is required.

There as been recent discussion about complex, messy, transitional
arrangements for LISP.  I wrote about my best guess of eFIT-APT
transition in the section "Incremental deployability" of:

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


Christian Vogt wrote:

> My personal summary of this discussion so far is the following:
>
> Early adopters of LISP would need to use non-mapped ("legacy")
> prefixes in addition to mapped prefixes.  The continued existence
> of non-mapped prefixes, in turn, would defeat much of the purpose
> of the mapping.

My understanding is that there is only one prefix involved.  Let's
say 20.0.0.0/20 was LISP-NERD/CONS-mapped.

With the basic conception of LISP, ITRs are only within each
"network" (of a provider or some AS-end-user with ordinary PI BPG
reachable address space).  That is, the ITR functions are found in
internal routers and/or in border routers.  With basic LISP,
20.0.0.0/20 is not advertised in BGP, so if a packet is sent to
20.0.0.5 from a host in a non-upgraded network the packet is dropped
in that network - it never gets out the border router.

There are two more promising options, as far as I know, for LISP
(other than adopting "anycast ITRs in the core" - and there's no
reason I know of why this couldn't be adopted):

1 - 20.0.0.0/20 is still advertised in BGP, by a single border
    router of some network L.  This router is an ITR.

2 - 20.0.0.0/20 is still advertised in BGP, by a single border
    router of some network L.  This router is a not an ITR.

In the former case, all packets sent from any network in the world
to any address in 20.0.0.0/20 will either find their way to an ITR
in their originating network, or will be sent out of the border
router (from a non-LISP-upgraded network) and arrive at the ITR,
where they will be tunneled to wherever they should go.  The
problems with this are mainly the possibility of longer path
lengths.  If the sender is in Düsseldorf, the ITR is in Japan and
the ETR is in  Cologne, then the path length is terribly
sub-optimal.  There are also single-point of failure problems due to
all hosts in non-upgraded networks relying on this one ITR for their
connectivity to the LISP-mapped hosts using the 20.0.0.0/20 addresses.

However, in principle, it should work.  As with Ivip, it only really
helps with reducing the BGP routing table size if there are, as a
result of LISP-mapping, more end-users using this space than was
possible with ordinary BGP.

If each prefix which is LISP-mapped and remains advertised like this
only supports as many users as it does today, then I think little
will be achieved, except for a reduction in BGP changes and whatever
benefits of finer control of multihoming, and TE LISP brings
compared to BGP.

Ivip is intended to be used in a different way from this "BYO
prefix" model.  There are supposed to be fairly large subnets (short
prefixes) assigned to Ivip, with lots more separate end-users making
use of this prefix than would be possible with current BGP techniques.

In the second case, the packets from non-upgraded networks arrive at
some network L, but the router there is not an ITR so it can't get
the packets to a destination host if that host is no longer part of
network L.  Therefore there is this mixed up state of some packets
being portable and multihomable to any ETR in any network and some
just arriving at network L.

So I don't respond to the rest of the message because I think it is
based on some notion I don't understand involving two prefixes at once.

  - 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