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
