Re: [P2PSIP] RFC6940: Detecting Partitioning

[Evgeny <[e-mail]>]

On Mon, Oct 15, 2018 at 10:13 AM, Bless, Roland (TM) 
<[e-mail]> wrote:
> Yes, the last hop forwarding the answer will be B, but the originating
> node from the other end (i.e., the one answering the ping request) is 
> a
> different node than P's current successor.

"the one answering the ping request"? But this will be my node 
answering the ping request.
Ok, I'm lost. Let's consider the PingReq path:

my_node -> boot_node -> ... -> node_X -> my_node

The corresponding PingAns will be:

my_node -> node_X -> ... -> boot_node -> my_node

So the idea is to check if node_X is the successor of my_node, right?
In this case I don't understand how to get that node from the answer: 
forwarding nodes
are not required to maintain Via lists, or they can just hide the path 
by OpaqueID.
Should I maintain some state on my node to do these checks?

> That may be best understood by looking at Figure 1 on page 139 and/or
> section 10.5.
> The Joining Node sends an AttachReq to its own ID+1 (this process
> is probably denoted as "Attaching"). The Admitting Peer (AP) and
> responsible peer are the same in this case, it will be the successor
> of the newly joining node. Does this make sense?

Yes, this makes sense, and this is trivial, but it's hard to understand 
from that phrase.
Whatever, thanks for the clarification.