Here are some further interesting side-benefits that come from doing
transmogrification (onto, and then 1:1, mappings), rather than
encapsulation (tunneling):
It is possible for non-EID hosts (without an ITR) to speak to an EID
host, by addressing it via any of its RLOC addresses. The ETR maps
the RLOC onto the EID, and the EID host doesn't know any different.
This raises all kinds of beneficial scenarios:
(1) migration paths from non-EID to EID:
Start with PA-only site, with hosts numbered out of the assigned PA
prefix.
Hosts are known via their PA addresses (e.g. PA addresses occur in
DNS AAAA records).
Site gets PI block for doing EID.
Hosts can be updated over some period of time, to have the EID
prefix added to them (with same II as PA block, NB!)
Once all hosts (that need it, at least) have EID, enable EID->RLOC
mapping.
Add EID addresses to DNS.
Configure ETR to map any RLOCs onto EIDs.
RLOCs (PA addresses) are no longer needed on hosts. They can be
removed at site's leisure.
(2) Access to EID hosts from non-ITR hosts is possible:
ITRs will know about EID->RLOC.
(Caveat: Hosts behind ITRs may need to have DNS responses modified,
so that only EID AAAA's get through, ditch any RLOC AAAA's from RR
sets with both RLOC and EID AAAA values.)
Hosts behind ITRs can access hosts via EIDs.
Hosts not behind ITRs, can access hosts via RLOCs. If EID is
attempted, it won't be reachable, and next AAAA should be tried,
which should be an RLOC.
ETRs map RLOCs to EIDs, so EID host only ever needs to be configured
with EID addresses.
(3) Hosts behind ITRs can access non-EID hosts (hosts no EID, no ETR)
DNS entry for non-EID host is an natural address, not an EID, and
can be thought of as self-RLOC.
ITR doesn't find a match, and doesn't modify the destination. The
self-RLOC is routable, and reachable.
The source addresses of EID hosts get modified by the ITR, to become
RLOCs.
The return path works the same, with the ITR behaving like an ETR
now, mapping RLOC to EID on the destination, but leaving self-RLOC
source addresses untouched.
(4) Hosts can be their own ITR/ETR. This might not be overly useful,
but can provide interesting solutions in the extreme case of /128 PA
addresses from multiple providers (SOHO multihoming).
(5) EID blocks aren't limited in size to /64 or bigger; they can
conceptually be any size at all. However, due to limitations on the
ability to use EID blocks as site prefixes, distinct EIDs should not
be allocated from the same /64. On the site side, any EID block
smaller than a /64, would likely look like a /64 with large chunks
of contiguous addresses unused (i.e., all unused except for a /N
where N > 64).
The bottom line is, in this model, LISP is still very valuable, even
when not universally deployed.
Optimizations for hosts knowing about LISP, and possibly having a
shim ITR layer rather than relying on network-centric ITRs, is a
possible growth path for extending the model further into the non-
multihomed sites/hosts.
Thoughts?
Brian Dickson