Re: [RRG] On the Transitionability of LISP

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

Hi Christian,

You wrote:

>> 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. [...]
> 
> There is an issue in this case as well:  If the host in the LISP-enabled
> network uses a mapped IP source address for the outgoing packet, the
> correspondent host in the legacy network won't be able to respond.

I think this is the same problem viewed from a different place.

If a host H1 in a non-upgraded network ISP-A can't send a packet to
a host H2 in ISP-B because H2 is using a LISP-mapped address, and
ISP-A has no ITR, then there is a problem: H1 cannot initiate or
maintain communications with H2.

What you are discussing, I think, is that H2 can send packets to H1,
but won't get a reply.

Clearly it would be unacceptable to introduce a new architecture
which was so disruptive.

The only solution is to either add things to LISP so it maintains
full reachability, or to get some other architecture which naturally
maintains it - such as Ivip.

I snipped a bunch of what you wrote, because it was complex attempts
at workarounds for a problem which I think should never be allowed
in the first place.


>> 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.
> 
> Robin, one main purpose of multi-homing is to avoid a dependency on a
> single provider.  The provider with the ITR in your example is a single
> point of failure, which is exactly what multi-homing tries to avoid.

I agree these are lousy approaches.

I was not discussing Ivip - I was discussing my understanding of two
ways LISP could be adapted to achieve reachability from non-upgraded
networks, while still being different from the way I think is best:
Ivip's "anycast ITRs in the core".


> Morerover, if I understand you correctly, in your example you would
> advertise a provider-independent edge network prefix in BGP.  So there
> also wouldn't be an advantage in terms of reduced routing table load.
> 
> Please clarify if I did not understand you correctly.

I have tried to explain this a number of times, but here goes again.

This is mentioned in the I-D:

  http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-arch-00.html

     Ivip's capacity to reduce the growth on the BGP routing table
     and to enable the efficient use of IPv4 space by giving
     end-users precisely the number of addresses they need - not
     256, 512, 1024 etc. addresses - rests on the RIRs developing an
     address management policy for Ivip-mapped address space which
     generally ensures that large blocks of addresses are assigned
     to the Ivip system, with each block being used to serve the
     needs of many end-users. It should not be difficult to develop
     implement such policies.

If either LISP/eFIT-APT or Ivip worked in the way I think you
suggest (one end-user per BGP advertised prefix which is dedicated
to the ITR-ETR mapping system), which I call "BYO address space",
then nothing much would be achieved in terms of reducing the number
of advertised prefixes.  There would be benefits for the end-user,
and there would be no updates in BGP for this prefix.

"BYO address space" means that for any end-user who uses mapped
addresses, they bring their own PI space to the mapping system and
by not let anyone else use it.

LISP, eFIT-APT and Ivip could be used this way - but it is not the
way I intend Ivip to be used.  Alternatively they could be used like
this:

Maybe I will call this the "Two or many more peas in a pod" approach:

The prefixes which are advertised and controlled by the LISP/Ivip
etc. mapping system are big enough to serve the needs of multiple
end-users.  These prefixes might not be usable by more than one
end-user now, with current BGP-based approaches to address
management.  With any of these ITR-ETR tunnelling and mapping
schemes (LISP/eFIT-APT or Ivip), the space can be divided down as
finely as desired, including into individual IP addresses.

If every end-user who needs portability and multihoming always
required a minimum of 256 IPv4 addresses, and had genuine needs
which always existed in multiples of 256 addresses, then there would
be little to be gained from using LISP, eFIT-APT and Ivip to slice
and dice the address space.

However, I am sure that some - probably many - end-users ("end-user"
in this message means those who need multihoming, portability, TE
etc.) don't need as much as 256 addresses.  Therefore all these
schemes - LISP, eFIT-APT and Ivip - enable more end-users to use a
/24 or a /23 than is possible today with BGP's clunky 256 address
resolution.  (This /24 limit is not fixed in the protocol - but by a
general practice of filtering advertisements to be for prefixes no
longer than 24.)

Ivip could probably slice and dice finer, because I intend it have
arbitrary ranges of address space given the same mapping, not binary
boundary prefixes like LISP and eFIT-APT.

Apart from that detail, LISP, eFIT-APT and Ivip could all be used
just as well to get more use out of a given amount of IPv4 address
space.

This greater usage of IPv4 space is not an explicit goal of LISP or
eFIT-APT, but it is of Ivip.


So the fact that Ivip has one prefix in the global routing table for
20.0.0.0/20 is not such a problem, as long as it is supporting two
or more end-users who otherwise would need to get PI space and
advertise it in BGP.   Clearly, the bigger the subnet (shorter the
prefix), of each Ivip-Mapped Address Block (IMAB), the more
end-users can be in it and the more savings there will be for the
global routing table.

If two separate end-users brought contiguous IMAB blocks (PI space
they had been assigned by an RIR) to Ivip:

  20.0.0.0/20
  20.0.16.0/20

and if they agreed for the mapping of their space to be mapped by
the one Root Update Authorisation System (RUAS), then database dumps
and update streams for the two could be handled as one.  Then all
the ITRs could advertise the two as a single IMAB:

  20.0.0.0/19

and this would reduce the number of advertised prefixes by one.

Ideally, Ivip or whatever would be launched with an RIR or some
large, stable, multi-party organisation (one that is not going to go
out of business) running a RUAS and having a whole slab of fresh
address space, such as a /8, to use for tens or hundreds of
thousands of multihoming and/or portability requiring end-users.

However, by the time this system is running, all that space will
probably be gone.  I recently floated the idea of saving a few /8s
for Ivip etc. on the RIPE Address Policy mailing list and it was not
hugely popular . . .

Ivip should enable such improved use of IP address space including
for mobility, that I reckon there could be profitable businesses
running their own independent Ivip systems, with ITR/TTRs all over
the Net, renting out IP addresses for mobility and multihoming.
Alternatively, there could be a global Ivip system with multiple
RUASes, each controlling various amounts of address space, either
that they have been assigned themselves by an RIR or which someone
else has allowed them to use.

All this is going to require RIR approval anyway, but there should
be no problems because it enables multihoming, more end-users etc.
without burdening BGP (except for there being one prefix per IMAB,
which is relatively stably advertised by ITRs all over the Net).

  - 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