Subject: [P2PSIP] Usage or multicast for discover of bootstrap nodes

From: Cullen Jennings <[email-masked]>
Date: Thu, 15 Oct 2009 19:07:13 -0600

I'm not aware of anyone that is using this. It's currently under- 
specified in the draft and I'm wondering if we should just remove it  
from the base draft. It could easily be added to a different extension  
draft. I'll take it out of the next version so people can see what  
this would look like but if this turns out not to be what people want,  
I'll add it back in if folks that want ti can send me the text to help  
finish it.

Thanks, Cullen

---

From: jc <[email-masked]>
Date: Thu, 15 Oct 2009 22:11:43 -0400

Cullen,
I've implemented multicast bootstrap and have it well defined. It's  
not a necessity and can be removed for base simplicity. As you said it  
can be added as an extension draft. In fact I could write the  
extension draft for multicast bootstrap.

Julian

On Oct 15, 2009, at 9:07 PM, Cullen Jennings wrote:

> from the base draft. It could easily be added to a different  
> extension draft. I'll take it out of the next version so people can  
> see what this would look like but if this turns out not to be what  
> people want, I'll add it back in if folks that want ti can send me  
> the text to help finish it.
>
> Thanks, Cullen
>
>
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

---

From: Michael Chen <[email-masked]>
Date: Thu, 15 Oct 2009 20:42:51 -0700

Julian,

We implemented UDP broadcast bootstrap as a simple way to form a ring in 
a private network with no enrollment server (self-signed cert, of 
course). This is specified in section 5.5.5 and 10.4 of the draft.

However, there is a small detail here. We assume the broadcast is always 
on the Reload port number, i.e. 255.255.255.255:6084 (thus no enrollment 
server is needed). I believe this should be recommended by the draft. 
Adding this as an extension would seem too trivial.

Cullen,

This method (along with LAN multicast) is VERY USEFUL. A private network 
can have a single long running node connected to the overlay on the 
public Internet.  When other peers boot up, they only need to use 
broadcast or multicast to join the overlay via that lone "seed" node in 
their private network.

Thanks

--Michael

jc wrote:
>> I'm not aware of anyone that is using this. It's currently 
>> under-specified in the draft and I'm wondering if we should just 
>> remove it from the base draft. It could easily be added to a 
>> different extension draft. I'll take it out of the next version so 
>> people can see what this would look like but if this turns out not to 
>> be what people want, I'll add it back in if folks that want ti can 
>> send me the text to help finish it.
>>
>> Thanks, Cullen
>>
>>

---

From: jc <[email-masked]>
Date: Fri, 16 Oct 2009 00:14:04 -0400

On Oct 15, 2009, at 11:42 PM, Michael Chen wrote:

> Julian,
>
> We implemented UDP broadcast bootstrap as a simple way to form a  
> ring in a private network with no enrollment server (self-signed  
> cert, of course). This is specified in section 5.5.5 and 10.4 of the  
> draft.
>
> However, there is a small detail here. We assume the broadcast is  
> always on the Reload port number, i.e. 255.255.255.255:6084 (thus no  
> enrollment server is needed). I believe this should be recommended  
> by the draft. Adding this as an extension would seem too trivial.

I somewhat agree however this isn't fully defined as Cullen and I have  
pointed out. Also it seems your experiencing the same effect where you  
now use internal IP's with Bootstrap because LAN Multicast which as I  
mentioned in a previous email is forbidden by the draft. So either it  
needs to be fully removed or fully defined and Cullen has removed it  
for now. I don't believe the draft should define this because it's  
actually non-trivial. When do you join the multicast group? How long  
are you a member? Do you send unicast and receive unicast? What do you  
do if you receive a stray message of N type? What is the broadcast  
interval? Do you join a multicast group on all active network  
interfaces? Do you use loopback?

I believe this should be an extension draft because it is non-crucial  
to the base protocol. If this were to be part of the base protocol  
draft then as I mentioned in the previous emails there would need to  
be changes made regarding Clients and Peers as well as the references  
to External and Routable IP addressing.

>
> Cullen,
>
> This method (along with LAN multicast) is VERY USEFUL. A private  
> network can have a single long running node connected to the overlay  
> on the public Internet.  When other peers boot up, they only need to  
> use broadcast or multicast to join the overlay via that lone "seed"  
> node in their private network.
>
> Thanks
>
> --Michael
>
> jc wrote:
>> Cullen,
>> not a necessity and can be removed for base simplicity. As you said  
>> it can be added as an extension draft. In fact I could write the  
>>> specified in the draft and I'm wondering if we should just remove  
>>> it from the base draft. It could easily be added to a different  
>>> extension draft. I'll take it out of the next version so people  
>>> can see what this would look like but if this turns out not to be  
>>> what people want, I'll add it back in if folks that want ti can

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 16 Oct 2009 08:44:20 -0600

I did not realize you had both implemented the multicast stuff. I  
think another group also did. Given it has been in the draft for a  
long time, and people are implementing it, it was a mistake for me to  
take it out. Lets work to figure out what needs to be specified to  
make it all work and also figure out the MAYs and MUSTs.

On Oct 15, 2009, at 10:14 PM, jc wrote:

>> cert, of course). This is specified in section 5.5.5 and 10.4 of  
>> the draft.
>>
>> always on the Reload port number, i.e. 255.255.255.255:6084 (thus  
>> no enrollment server is needed). I believe this should be  
>> recommended by the draft. Adding this as an extension would seem  
>> too trivial.
>
> I somewhat agree however this isn't fully defined as Cullen and I  
> have pointed out. Also it seems your experiencing the same effect  
> where you now use internal IP's with Bootstrap because LAN Multicast  
> which as I mentioned in a previous email is forbidden by the draft.  
> So either it needs to be fully removed or fully defined and Cullen  
> has removed it for now. I don't believe the draft should define this  
> because it's actually non-trivial. When do you join the multicast  
> group? How long are you a member? Do you send unicast and receive  
> unicast? What do you do if you receive a stray message of N type?  
> What is the broadcast interval? Do you join a multicast group on all  
> active network interfaces? Do you use loopback?
>
> I believe this should be an extension draft because it is non- 
> crucial to the base protocol. If this were to be part of the base  
> protocol draft then as I mentioned in the previous emails there  
> would need to be changes made regarding Clients and Peers as well as  
> the references to External and Routable IP addressing.
>
>>
>> Cullen,
>>
>> network can have a single long running node connected to the  
>> overlay on the public Internet.  When other peers boot up, they  
>> only need to use broadcast or multicast to join the overlay via  
>> that lone "seed" node in their private network.
>>
>> Thanks
>>
>> --Michael
>>
>> jc wrote:
>>> Cullen,
>>> I've implemented multicast bootstrap and have it well defined.  
>>> It's not a necessity and can be removed for base simplicity. As  
>>> you said it can be added as an extension draft. In fact I could  
>>> write the extension draft for multicast bootstrap.
>>>
>>> Julian
>>>

---

From: jc <[email-masked]>
Date: Fri, 16 Oct 2009 12:16:32 -0400

The first thing that needs to be changed would be all of the points  
that refer to public ip addressing of bootstrap nodes as a MUST.  
Multicast introduces a new case where Nodes MAY bootstrap off of  
Clients which MAY have an internal IP address. A Node MUST be able to  
bootstrap off any other Node regardless of it's IP addressing and  
public routability.

Sent from my iPhone

On Oct 16, 2009, at 10:44 AM, Cullen Jennings <[email-masked]> wrote:

> long time, and people are implementing it, it was a mistake for me  
> to take it out. Lets work to figure out what needs to be specified  
> to make it all work and also figure out the MAYs and MUSTs.
>
>
>> where you now use internal IP's with Bootstrap because LAN  
>> Multicast which as I mentioned in a previous email is forbidden by  
>> the draft. So either it needs to be fully removed or fully defined  
>> and Cullen has removed it for now. I don't believe the draft should  
>> define this because it's actually non-trivial. When do you join the  
>> multicast group? How long are you a member? Do you send unicast and  
>> receive unicast? What do you do if you receive a stray message of N  
>> type? What is the broadcast interval? Do you join a multicast group  
>> on all active network interfaces? Do you use loopback?
>>
>> would need to be changes made regarding Clients and Peers as well  
>> as the references to External and Routable IP addressing.
>>
>>>
>>> Cullen,
>>>
>>>>> specified in the draft and I'm wondering if we should just  
>>>>> different extension draft. I'll take it out of the next version  
>>>>> so people can see what this would look like but if this turns  
>>>>> out not to be what people want, I'll add it back in if folks  
>>>>> that want ti can send me the text to help finish it.
>>>>>
>>>>> Thanks, Cullen
>>>>>
>>>>>

---

From: Michael Chen <[email-masked]>
Date: Wed, 21 Oct 2009 10:11:27 -0700

Cullen,

I believe bootstrap via UDP broadcast on 255.255.255.255:6084 should 
also be included and clarified as a "MAY."

--Michael

Cullen Jennings wrote:
>>>>> people can see what this would look like but if this turns out not 
>>>>> to be what people want, I'll add it back in if folks that want ti 
>>>>> can send me the text to help finish it.
>>>>>
>>>>> Thanks, Cullen
>>>>>
>>>>>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 22 Oct 2009 19:46:47 -0600

> also be included and clarified as a "MAY."

Sounds good - should be in next version ....

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 22 Oct 2009 19:53:24 -0600

> that refer to public ip addressing of bootstrap nodes as a MUST.

I think I got most of these but there may be a few places where text  
still needs to be updated.

> Clients which MAY have an internal IP address. A Node MUST be able  
> to bootstrap off any other Node regardless of it's IP addressing and  
> public routability.
>
> Sent from my iPhone
>