Joel, I am seeing HIP proxy as having value both as a near-term connectivity capability for legacy hosts and as a longer term transition mechanism that encourages more and more end hosts to deploy a host-based solution. However, I see this as complementary to the network-based solution rather than a replacement for the network-based solution.
IMHO, the network based-solution provides the substrate on which the end-to-end solution builds. Fred [email protected] >-----Original Message----- >From: Joel M. Halpern [mailto:[email protected]] >Sent: Thursday, January 08, 2009 4:46 AM >To: RRG >Subject: Re: [rrg] Rejecting all but Strategy A > >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 _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
