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 protected]> wrote:
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:
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,
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:
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
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
