Re: [P2PSIP] HIP: optional, mandatory?

[Cullen Jennings <[e-mail]>]

On Jan 10, 2008, at 8:23 PM, David Barrett wrote:

> We don't need more options for what we CAN do, we need decisions on  
> what we WILL do.

Yep - agree.  And what I want to do is standardize something that  
lets me build deployable interoperable solutions soon. Success for me  
involves deployments.

>   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.

The P2PSIP WG has made very few decisions since it was formed. IMHO,  
what we need to do real soon now is pick something as a starting  
point for a WG document then go and make the decision to change it to  
be what we want.  Until we do that, my belief is that the WG will  
make fairly marginal progress.

>
> 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,

this is way outside anything HIP was charted to do or is working on

> 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.

Most of the concrete proposals layer the p2p code such that the  
library that provided the p2p part could be used by other  
applications. This is a good design but not something you need HIP to  
accomplish.

>
> -david

Cullen <with my individual hat on>

>
> 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
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/p2psip
>> _______________________________________________
>> P2PSIP mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/p2psip
>>
>


_______________________________________________
P2PSIP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/p2psip