jiangxingfeng 36340 wrote:
Cullen Jennings wrote:
How does a node decide it should be a bootstrap peer. The
current
document more or less say configuration.
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
So points I see in various comments are that:
- bootstrap peer selection is going to be use-case dependent
- the proper reaction to inability to locate a bootstrap peer is
use-case dependent
- how can you figure out if you're a good bootstrap peer?
options for obtaining bootstrap peers include:
- configuration file
- cached previous neighbors
- mDNS etc
I think bootstrap server should be included.
Currently reload doesn't have a notion of a bootstrap server (separate
from a bootstrap peer). I'm not really sure what the purpose of having
a non-peer bootstrap server would be, actually. OTOH, I don't think
the existing protocol would need to be changed at all to support
it---the JP doesn't need to know it's not a bootstrap peer it's
contacting and the routing wouldn't be any different from the JP or AP's
perspectives.
So I think if one did have a bootstrap server speaking reload, I think
it would just appear in the list of bootstrap peers and be treated the same.
Bruce
I think the real question here is what needs to be in the base
draft and
what is appropriate for extensions or simply
implementation/deployment
specific. I would like to propose:
- the configuration file can contain a list, can indicate whether
local
search (mDNS, etc) can be used, and can indicate whether no
bootstrap
peers being contacted is a failure (there's a minor
bootstrapping(!)
problem here for starting a new overlay, but that's not too bad)
- the draft will specify the format of the list and the mDNS
parameters.- caching previous peers will be left as an option for
implementers,
presumably falling back to the other mechanisms. (I don't see a
reason
to want to prohibit this, but am open to suggestions.)
- determining whether you make a good bootstrap peer and
whether/how to
update the configuration list will be out of scope for the base draft.
In RELOAD, bootstrap peer should have public address which is very important for overlay to function properly. So if it is not within base draft, I think we need other draft to address this issue, maybe with BCP.
Bruce
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
