[rrg] Handling multiple layers of indirection

[Pekka Nikander]

Summary:  One can initially deploy multiple layers of indirection  
initially by "architecturally cheating"  or "hiding" some of the  
indirection layers so that they are not visible to the resolution  
system nor in data plane packets.

>>> What HIP gives you is an identifier that may be used for many  
>>> things.
>>
>> Assuming I deem the DNS trustworthy, it seems much more natural to  
>> treat the DNS as the source of an HI, and then for the locator to  
>> be looked up as a function of the HI. I'm not saying your model  
>> doesn't work, but surely the HI is fundamental and has universal  
>> validity, and the locator (any of the locators) is transient and  
>> has non-universal scope? So starting with a locator lookup seems  
>> funny.
>
> I prefer Brain's opinion since there is no need for each host owns a  
> FQDN name. Once you tell me your host ID, I can resolve your locator  
> from a seperate ID/locator mapping system and then communicate with  
> you.

 From an architectural orthodoxy point of view, i.e. from the layering  
point of view, what you and Brian describe may well be the "right"  
way.  Indeed, what you describe is more-or-less what happens with HIP  
as standardised today.  You get the HIT and a set of initial locators  
from the DNS.  The initial locators are typically those of rendezvous  
servers, which in turn know the current locator(s) of a mobile host.   
For details, see RFC5204 and RFC5205.

However, if you consider the various early deployment scenarios, the  
situation is different.  The question is no longer what is "right",  
from the architectural point of view, but what is the best deployment  
strategy.  From that point of view, a good strategy may be to  
initially get only the locators from the DNS, as that requires no  
changes to the DNS.  The HIT (or the HITs) can then be learned form  
the peer, along the opportunistic HIP model.  See Section 4.1.6 of RFC  
5201.  But I can also imagine other deployment models.

IMHO, if we want to consider the deployability a HIP-based solution,  
or any solution, what Noel wrote before Christmas is well worth  
reading again:

http://www.ietf.org/mail-archive/web/rrg/current/msg04037.html

(Remember, that is the message to which I reacted, causing the current  
thread of messages about HIP, where I have mainly tried to explain  
that HIP-proxy could have a quite different deployment model than the  
plain HIP has.)

In general, the question is very much about deployment cost.  With  
proxy HIP, by initially "hiding" the HITs and using the opportunistic  
HIP model and ephemeral or even imaginary HITs, we can "fold" the HIP  
model into what is essentially the map-and-encaps model.

[[Generalising more, once again: one can deploy architecturally host- 
based solutions initially as network-based ones, and vice versa.   
Conversely, one can design architecturally host-bast solutions that  
are *hard* to deploy as network-based ones, and one can design  
architecturally network-based solutions that are *hard* to utilise in  
single hosts.  And vice versa.  Hence, paying attention to the  
details, both in selecting the architectural approach and thinking  
about the deployment flexibility, should pay off to the community in  
the large.

I've been trying to say that now for over two years, and nobody still  
seems to pay any attention.  Am I completely bogged and off the road  
in my thinking?]]

--Pekka