Tom,
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.
Yes and no. The goal certainly is that there may be some (or even
most) applications that use the HIP identifiers directly. However,
for the peer protocols and maybe also some applications it may make
more sense to use other kinds of identifiers. That's why we made the
distinction between Peer IDs and HIP identities in Section 3.1.
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.
That is certainly part of our goal.
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.
Right. I agree.
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.
That issue Gonzalo and I have discussed extensively. On my part I
still don't quite understand the requirement (as is probably visible
from the previous exchange of message between you Tom and me).
However, for example, one possibility here would be that the routing
tables could contain PeerIDs (distinct from HIP identifiers) while
the forwarding tables would contain HIP identifiers. However, of
course, whether that would work in a scalable manner depends on many
details that haven't really been figure out yet. For example, in
such an approach it might be necessary to define a new HIP parameter
(or reuse the existing HOST_ID parameter) to carry the PeerID when
routing HIP packets through the overlay.
HIP BONE seems to be suggesting that the peer protocol can fill
this gap ...
Exactly.
... 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.
There are certainly many things that need to be worked out in order
to make HIP BONE practical. The present draft was more meant to
provide an overall map of some territory rather than providing detail
instructions on how to get to the goal. But, from the HIP BONE point
of view, it would not make sense to make the peer protocol and a
resolution or routing service separate. Ideally, HIP BONE would
support both P2PSIP based peer protocols and other, unrelated overlay
or identity routing protocols, perhaps something similar to Berkeley
DONA.
<snip>
Question (for P2PSIP): ...
I think your questions are very good, but since I am not really a
member of the P2PSIP community, I don't feel myself able to answer to
those.
--Pekka
_______________________________________________
P2PSIP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/p2psip
