Henning, I think it can done in a modular way that will make it possible for it to be optional to implement and run. Then vendors and deployments can decide whether they want to use it or not.
I'm not entirely convinced that HIP is the right solution, but I'm interested enough in it that I think it will be cool to play with and see how well it works. That to me says it should be an optional component. If it's successful, obviously it will be more widely adopted. Bruce On Jan 10, 2008 5:14 PM, Henning Schulzrinne <[EMAIL PROTECTED]> 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
