[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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