While there is room to discuss a lot of the other aspects, I at least
consider the ability to migrate to a host based solution, which would
easily support multi-interface hosts and site topology changes while
preserving identity, to be a benefit.
Yours,
Joel
Dino Farinacci wrote:
I'm not seeing any compelling benefit here Pekka. Just that HIP is
different and the stuff it does have that LISP currently doesn't is too
heavy-weight. This is just my opinion and a judgement.
Dino
On Jan 7, 2009, at 3:55 AM, Pekka Nikander wrote:
Eric wrote:
By combining a true locator-identifier split (i.e., HIP) with a
map-and-encaps (e.g., LISP) one gets the combined benefits of both
approaches. Those benefits are
Dino replied:
But you add another layer of addressing that is probably more than
the user wants. It could get this bad:
HIT -> EID -> private-RLOC -> public-RLOC when behind a NAT
or
HIT -> private-EID -> public-EID -> RLOC when behind a NAT
I don't think those mappings are right.
If there is a NAT between the xTR/HIP-proxy and the "new" internet,
the mapping would be:
EID -> (HIT) -> private-RLOC -> public-RLOC
where the HIT would be invisible everywhere but inside the HIP proxies
and within the signalling protocol between the HIP proxies.
If there is a NAT between the legacy host and the xTR/HIP-proxy, the
mapping would be:
private-EID -> public-EID -> (HIT) -> RLOC
where again the HIT would be invisible, as explained above.
2-levels of mapping is plenty, adding 2 more probably is a
non-starter. Remember folks, we have to incrementally deploy this
with minimal cost, see Yakov's post early today, he makes good points.
I don't see how replacing the xTR internal functionality with the
HIP-proxy functionality would add much cost. It would change the
protocol between the xTRs, yes. HIP as a protocol is probably more
complex than the present xTR-xTR protocol, but it is well tested, been
in operational use at Boeing for a few years, as has three open source
implementations.
There is an extra mapping, i.e. replacing the EID->RLOC mapping with a
EID->(HIT)->RLOC mapping. But that mapping is internal to the proxies
and the signalling protocol, and not visible outside. In the simplest
case the HITs would be ephemeral and opportunistic, requiring no
configuration or storage anywhere. (The benefit from them is in terms
of security and mobility, especially in more complex scenarios than
the simplest case.)
--Pekka
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
