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

From: Brian Dickson <[email-masked]>
Date: Fri, 04 Jan 2008 05:08:16 -0500

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 [email-masked] 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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 05 Jan 2008 17:47:00 +1300

> RLOC onto the EID, and the EID host doesn't know any different.

My attention may have been off, but I don't quite recall how your
proposal remaps to the original addresses at or near the recipient,
which is required for the EID host not to know any different
(because of all the reasons that NAT breaks upper layers).

We travelled this road in multi6/shim6 and that's how we ended up with
shim6 being essentially signalled double ended NAT. I don't see how
you can untransmogrify without signalling.

    Brian C

---

From: Brian Dickson <[email-masked]>
Date: Sat, 05 Jan 2008 03:22:12 -0500

Brian E Carpenter wrote:
>> 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.
>
The essential part is, an ETR may (and likely will) hold many RLOC blocks,
where each block might typically be a (PA) assignment from a larger 
(single) PA block.

EID blocks are effectively PI, either by being actual PI blocks 
(preferably), or ULA/ULA-G/ULA-C blocks.

Each EID block gets mapped to a set of RLOC blocks, but each RLOC block 
only has one EID block mapped to it.

That uniqueness allows for the reverse mapping to be deterministic. The 
exact mechanism for forward/reverse lookups
will depend greatly on the specifics of the RLOC->EID mapping database 
stuff itself. :-)

This operates, as does the EID->RLOC mapping, is essentially static, and 
does not require signalling.
> you can untransmogrify without signalling.
It basically uses the addressing scheme to do this.
I.e. it is part of the architecture, designed-in deliberately.

I'm not sure whether/how that uniqueness can be guaranteed or enforced.
It boils down to, "This is how you do things to make it work, and if you 
don't, it won't work."

The main criteria for the mapping database should be, that the essential 
elements be delegated to the "customer", and the "customer" would need 
to do what is needed, or delegate the authority for doing that to some 
third party (e.g. outsourcing entity).

This is mainly so that the design/implementation/operation of lots of 
these scales, both globally and from the perspective of the service 
providers (PA block owners).

The obvious choice would be to somehow link the mapping to the inherent 
delegation that happens with ip6.arpa delegation for the RLOC block(s), 
and to the delegation for the EID block.

Perhaps something as simple as a PTR RR at the zone cut of the RLOC 
block, and some kind of RR listing the ip6.arpa zones (of the RLOCs) 
under the EID block zone?

(This bit needs fleshing out, but the details of the mapping function 
are orthogonal to the transmogrification bits.)

Brian D

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 07 Jan 2008 09:49:43 +1300

> only has one EID block mapped to it.

Doesn't that mean there will be far more RLOC prefixes than EID
prefixes?

     Brian

---

From: Brian Dickson <[email-masked]>
Date: Sun, 06 Jan 2008 16:52:52 -0500

Brian E Carpenter wrote:
>
>
>> Each EID block gets mapped to a set of RLOC blocks, but each RLOC 
>> block only has one EID block mapped to it.
>
It depends on your measure of "far more". :-)
But yes, it will be more.

Notably, the following should all be applicable:
- not every site needs an EID block, only multi-homed sites
- each RLOC block is assigned out of a PA block, and in the DFZ only 
should appear as the covering aggregate from the LIR
- the distribution of number-of-homes versus 
number-of-sites-with-that-number-of-homes, would likely be highly tilted 
towards the values 1, 2 and 3.
- EID blocks *may* number less than non-RLOC PA assignments, depending 
on the uptake of multihoming generally.

So, even in the extreme cases of some sites having lots of homes, I 
would expect the *average* RLOC:EID ratio is likely to be about 2 and 
change.

In short, I don't see it as being a big concern.

The main question will be, what are they typical block sizes for 
multihomed sites compared to non-multihomed sites?

That will impact the allocation assumptions being made by LIRs, if it 
differs significantly from the general case (non-multihomed).

However, I don't think there is any association between a sites desire 
to be multihomed, and the size of prefix it needs. The experience with 
PI assignments in IPv4 certainly suggests that small prefix multihomed 
is a very popular niche need.

Brian

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 6 Jan 2008 21:07:06 -0800

Brain have you seen http://www.ietf.org/internet-drafts/draft-lewis-lisp-interworking-00.txt?

A lot of your ideas are written down in this draft.

Dino

------

On Jan 4, 2008, at 2:08 AM, Brian Dickson wrote:

> Hosts are known via their PA addresses (e.g. PA addresses occur in  
> DNS AAAA records).
>
> Hosts can be updated over some period of time, to have the EID  
> prefix added to them (with same II as PA block, NB!)
> RLOCs (PA addresses) are no longer needed on hosts. They can be  
> removed at site's leisure.
>
> (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 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.
> DNS entry for non-EID host is an natural address, not an EID, and  
> can be thought of as self-RLOC.
> 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  
> 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).
>
> 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