> -----Original Message----- > From: Bruce Lowekamp [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 08, 2008 2:16 PM > To: Gonzalo Camarillo > Cc: Pekka Nikander; P2PSIP Mailing List > Subject: Re: [P2PSIP] New draft: HIP BONE >
> > Going with the HIP-BONE, approach, as I understand the "HIP is IP and > the peer protocol is OSPF" idea... I think this analogy has some weaknesses, as you have pointed out, in the "peer protocol is OSPF" part. My reading of HIP BONE is that the overall goal is to allow the peer protocol and other applications to deal with HIP identifiers instead of IP addresses. That is a worthy goal IMO which might free RELOAD and other applications from having to do ICE and handle recursive routing issues or host mobility and multihoming. However, the problem with this approach is that HIP needs a naming service or routing service to resolve identifiers to either locators or route lists. This does not exist yet in HIP. There have been proposals to use DHTs to provide this service, but they do not presently accommodate the possibility of multiple DHTs, which is pretty much a requirement to handle, from my perspective. HIP BONE seems to be suggesting that the peer protocol can fill this gap but there appear to be some issues that need to be worked out, or maybe HIP BONE needs its own resolution/routing service separate from the application overlay. Let's presume, for the sake of discussion, that HIP BONE could be made to work (perhaps not exactly how it is written in the draft, but somehow), and that it provided an abstraction to the peer protocol layer and other applications that every node was reachable within a single Internet; i.e., that each node had a single, globally scoped, unchanging IP address, that there was a routing service that made each IP address reachable from any other, and that there were no NATs. Let's also presume that HIP BONE was co-deployed with the peer protocol deployment; that HIP was guaranteed to be available wherever the peer protocol was deployed. Question (for P2PSIP): Is that a useful goal, for HIP to try to provide the above abstraction, and to try to work out the rest of the details to realize that service? Or would there be other considerations that still make this an unattractive abstraction to P2PSIP? For instance, are there reasons that nodes would want to know more details about the underlying IP addresses associated with peer nodes, and wouldn't want those details hidden? Question: How would RELOAD or other proposals change if that were the case? Would the benefits greatly outweigh any drawbacks to this abstraction? Tom _______________________________________________ P2PSIP mailing list [email protected] https://www1.ietf.org/mailman/listinfo/p2psip
