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
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
