We don't need more options for what we CAN do, we need decisions on
what we WILL do. If we're not considering making HIP mandatory, then
let's stop talking about it and start focusing on those things that
*will* be mandatory.
That said, I think this HIP discussion is the best thing to happen in
P2PSIP for years. It seems like the most practical and powerful
solution, the best layering of functionality, and the most feasible
design that I've yet to hear. Moving the hard P2P code into a
reusable HIP layer makes a lot of sense, not only for P2PSIP, but for
the internet as a whole. It seems like a wagon that we should
voluntarily and enthusiastically hitch ourselves to, rather than try
to reproduce or compete with it, or toss it in the overflowing bucket
of optional extensions.
It seems sensible to have a base HIP layer that either comes pre-
installed with the OS or redistributed by the application (similar to
WinPCap). (I could even see making a sort of "HIP-lite" self-
contained library that can be linked straight into the application for
when installing a Then P2PSIP can be one of many HIP-using
applications that are vastly simplified by being insulated from the
gnarly realities of NAT and firewall penetration, mobility, etc.
This makes a lot more sense than continually reproducing this really
hard functionality in every application.
-david
On Jan 11, 2008, at 7:33 AM, Cullen Jennings wrote:
I was assuming most folks were talking about (3) given that much of
HIP is still being designed and it will be awhile to get things
build and deployed. I know lots of parts of HIP have been done but
when we are talking about mobility, nat traversal, no DNS, and easy
end user installations, there is still work. Anyway, I am in the 3
category.
Cullen <with my individual hat on>
On Jan 10, 2008, at 2:14 PM, Henning Schulzrinne wrote:
One of the issues I don't understand about this discussion is
whether all instances of P2PSIP would be expected to be running HIP
or just some. There seem to be at least three options:
(1) Mandatory to implement and run
The only non-recursive-dependency model seems to be that peer nodes
would store the HIT-IP bindings in their routing tables. (This
largely negates any mobility advantages, but that's a separate
discussion.)
(2) Mandatory to implement, but there can be instances of an
overlay (or maybe even part of an overlay) that don't use HIP
This would require providing ICE functionality at both the HIP
level and directly to the P2P protocol.
(3) Optional to implement and run
This only works if you can have mixed HIP-non-HIP nodes. Also
requires implementations of ICE in both layers and the ability to
mix-and-match HIP and non-HIP nodes within an overlay, unless each
overlay has a "HIP flag".
I admit that I'm rather worried about the complexity of this whole
edifice. I think it would be helpful if the proponents of a HIP-
based approach stated clearly which of these they have in mind.
Henning
_______________________________________________
P2PSIP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/p2psip
