Hi, I didn't catch it, sorry. Do you mean that the node_id is learned at JP via the TLS (certificate) authentication with bootstrap peer ? So when TLS happens, Jp gets the node_id of bootstrap peer via the certificate used in TLS ? That means that for debugging purpose you have to use TLS ? We hoped during implementation that we could use simple TCP connections first, instead of TLS.
If so, don't you think that the exchange of the Node_id should better be placed on RELOAD-Layer, not on the Link Layer ? Cheers, Frédéric On Sat, Oct 23, 2010 at 8:06 PM, jc <[email protected]> wrote: > > On Oct 23, 2010, at 12:46 PM, Frederic-Philippe Metz > <[email protected]> wrote: > >> Hi jc, thanks a lot for the support. Ok, I understand. So the second >> paragraph in section 10.5 is also not correct ? >> >> The init setup procedure, assume you have chord-reload, is where I >> have problems to understand. >> >> Assume the config-server is contacted and the bootstrap IP is in >> place. What happens then ? I guess the JP a) has to establish a TLS >> connection to the bootstrap peer. Then b) it has to send an attach to >> the bootstrap peer for the purpose of sending further RELOAD messages >> (i.e. ping to find the AP). But from where does it know the Node-Id >> (for sending the attach request) of the bootstrap peer (in case of >> central enrollment when the node-id is generated by the enrollment >> server) ? > > The Node-Id is obtained from the message signature. > >> >> Second question is for clarification: >> The draft states a difference between the Connection Table and the >> Routing table. So I see the Connection Table (in the Forwarding and >> LinkLayer) as a map of key node-id with value of a IP:Port pair. Would >> that go along with the draft ? And the Routing table (in the Topology >> plugin) as an Overlay specific "decision table" to which _node-id_ at >> the end the message has to be routed. This node-id in the Routing >> table has always a key entry in the connection table. Would that also >> go along with the draft ? > > This sounds like a implementer detail. > >> >> Cheers, >> Frédéric >> >> >> On Sat, Oct 23, 2010 at 9:43 AM, jc <[email protected]> wrote: >>> It should be AP. You are correct however JP could have discovered the >>> node-id of AP through many means. >>> >>> On Oct 23, 2010, at 3:31 AM, Frederic-Philippe Metz >>> <[email protected]> wrote: >>> >>>> Hi all, >>>> >>>> I've got a question resp. page 123: >>>> >>>> The first attach in the call flow diagram states JP as the >>>> destination. I think it should be AP ? JP has got the node-id of AP >>>> from a previous ping, right ? If that assumption is not right, the >>>> attach to node-id JP will fail, because 5.5.1 states that the attach >>>> to a node-id which isn't reached will fail. >>>> >>>> Cheers, >>>> Frédéric >>>> _______________________________________________ >>>> 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
