Re: [P2PSIP] New draft: HIP BONE

Pekka Nikander <pekka.nikander@nomadiclab.com> Fri, 11 January 2008 07:45 UTC

Return-path: <p2psip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDEZx-0000qd-FE; Fri, 11 Jan 2008 02:45:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDEZv-0000qC-SF for p2psip@ietf.org; Fri, 11 Jan 2008 02:45:23 -0500
Received: from n2.nomadiclab.com ([2001:14b8:400:101::2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JDEZv-00084z-BL for p2psip@ietf.org; Fri, 11 Jan 2008 02:45:23 -0500
Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id C10BD1EF105; Fri, 11 Jan 2008 09:45:21 +0200 (EET)
Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5AE2E1EF104; Fri, 11 Jan 2008 09:45:20 +0200 (EET)
In-Reply-To: <0bf801c853db$fe101830$6601a8c0@china.huawei.com>
References: <476BA8D9.4010203@ericsson.com> <20d2bdfb0712210823m2218c4a6mcace60af3d82db57@mail.gmail.com> <476E2B7C.9070601@ericsson.com> <20d2bdfb0801081416t41b9b84atb3a147659771036@mail.gmail.com> <77F357662F8BFA4CA7074B0410171B6D04049B22@XCH-NW-5V1.nw.nos.boeing.com> <7C5B8529-85C9-4977-8C57-34E9041ED1EC@nomadiclab.com> <77F357662F8BFA4CA7074B0410171B6D04049B33@XCH-NW-5V1.nw.nos.boeing.com> <0bf801c853db$fe101830$6601a8c0@china.huawei.com>
Mime-Version: 1.0 (Apple Message framework v753)
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <B5C4134C-1856-4150-BC88-1D43A45C66F3@nomadiclab.com>
Content-Transfer-Encoding: 7bit
From: Pekka Nikander <pekka.nikander@nomadiclab.com>
Subject: Re: [P2PSIP] New draft: HIP BONE
Date: Fri, 11 Jan 2008 09:45:18 +0200
To: Spencer Dawkins <spencer@mcsr-labs.org>
X-Mailer: Apple Mail (2.753)
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: -1.4 (-)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: P2PSIP Mailing List <p2psip@ietf.org>
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
Errors-To: p2psip-bounces@ietf.org

In the case of HIP BONE, the peer (or routing) protocol is both a  
user of HIP and an enable of HIP.  But so are the routing protocols  
for IP, and in certain sense DNS for IP, too.

Such a circular dependency in itself is not bad, as long as it is  
designed (i.e. not accidental) and we have a clear understanding how  
to manage the bootstrap problem.

In this case, the bootstrap may take place, for example, in the form  
of direct HIP connections (no overlay routing).  That is, if that  
approach is taken, when a node joins to an overlay, it looks up the  
HIT and IP address of some host within the overlay (e.g. using DNS,  
local service discovery, or manual configuration), creates an HIP  
association, and runs the peer protocol join over the HIP association.

--Pekka


On 11 Jan 2008, at 00:56, Spencer Dawkins wrote:

> [Spencer] Yes, exactly. I'm not sure that we DON'T have circular  
> dependencies yet. I'm still trying to understand whether the peer  
> protocol is a user of HIP or an enabler of HIP.
>
> Thanks,
>
> Spencer
>
> From: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
>>
>> The difficulty I have (also with the OSPF analogy) is that it seems
>> necessary to avoid circular dependencies.  OSPF and IS-IS build IP
>> forwarding tables but, in so doing, they do not use those IP  
>> forwarding
>> tables, because that would be a circular dependency.  If you say that
>> peer protocol and resolution and routing service are combined,  
>> then it
>> seems to me that you are saying in HIP BONE that the peer protocol is
>> both a user of HIP (in some contexts) and an enabler of HIP (such as
>> overlay-routing the HIP messages).
>>
>> If HIP provides connection managment, and the peer protocol provides
>> data storage and retrieval, and peer protocol uses HIP for its
>> connections, and HIP uses the peer protocol for data storage,  
>> there seem
>> to be some circular dependencies.  Or does HIP only apply to the  
>> media
>> stream connections?
>>
>> I'm led to assume that, in the model you're describing, the peer
>> protocol has to operate in the absence of HIP (and must implement  
>> ICE);
>> i.e., data storage and retrieval is necessary to bootstrap HIP, and
>> therefore the connections used to implement data storage and  
>> retrieval
>> do not run over HIP.  Is that correct, or am I missing something?
>
>

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip