[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
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
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
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
(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
to unsubscribe send a message to firstname.lastname@example.org 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