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.