[RRG] map-and-map (vs map-and-encaps) - further thoughts

[Brian Dickson <briand@ca.afilias.info>]

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

--
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