[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] On the Transitionability of LISP
Robin:
> 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.
It is unclear how one could make the sending host select a mapped IP
source address for a packet if and only if the recipient correspondent
host, too, sits in a LISP-enabled network. Two reasons:
(1) The sending host does not know whether or not the correspondent
host's network is LISP-enabled.
(2) IP source address selection would not behave as needed even if the
sending host was aware of the correspondent host's network's LISP status
-- given that the sending host is supposed to be unmodified.
It may be possible to fix this by having the ITR of the sending host act
as a classic NAT box. The cost is a loss of end-to-end semantics. Many
customers don't like this, providing another deployment disincentive.
> 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.
Right, here the problem is selection of the right IP destination address
by the host in the legacy network. The above-mentioned issues (1) and
(2) apply here as well -- replacing "source" by "destination" in (2).
In order to avoid breaking communications between LISP and non-LISP
networks, one option would be to order IP addresses in DNS replies such
that non-mapped addresses are first and mapped addresses are second.
However, the negative consequence of this would be that non-mapped
addresses would likely be selected even in the case were LISP was
deployed on both ends of a connection.
> 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.
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.
- Christian
--
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