[P2PSIP] RFC6940: Detecting Partitioning

[Evgeny]

Hi there

I have hard time understanding the mechanism described in 10.7.4.4

P SHOULD then send a Ping for its own Node-ID routed through B.
If a response is received from peer S', which is not P's successor,
then the overlay is partitioned

How is it even possible? Given the Symmetric Recursive Routing, the
Ping answer will always come from node B.
I tried to grasp through the RFC about special routing rules of Ping
answers, but I didn't find anything special
except the statement in 6.1.2 (Other ID) [2] which I *fail* to

The node MUST implement support for
returning responses to a Ping or Attach request made by a Joining
Node Attaching to its responsible peer

"made by a Joining Node Attaching to its responsible peer"? What does
that mean exactly? Why is "Attaching"
with a capital letter?

[1] https://tools.ietf.org/html/rfc6940#section-10.7.4.4
[2] https://tools.ietf.org/html/rfc6940#section-6.1.2

[Michael Chen]

_______________________________________________
P2PSIP mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip

[Bless, Roland (TM)]

Hi Evgeny,

Post by Evgeny
I have hard time understanding the mechanism described in 10.7.4.4

P SHOULD then send a Ping for its own Node-ID routed through B.
If a response is received from peer S', which is not P's successor,
then the overlay is partitioned

How is it even possible? Given the Symmetric Recursive Routing, the Ping
answer will always come from node B.

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.

Post by Evgeny
I tried to grasp through the RFC about special routing rules of Ping
answers, but I didn't find anything special

The node MUST implement support for
returning responses to a Ping or Attach request made by a Joining
Node Attaching to its responsible peer

"made by a Joining Node At taching to its responsible peer"? What does
that mean exactly? Why is "Attaching"
with a capital letter?

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?

Regards,
Roland

[Evgeny]

On Mon, Oct 15, 2018 at 10:13 AM, Bless, Roland (TM)

Post by Bless, Roland (TM)
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?

Post by Bless, Roland (TM)
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.

[Roland Bless]

Hi Evgeny,

Post by Evgeny
On Mon, Oct 15, 2018 at 10:13 AM, Bless, Roland (TM)

Post by Bless, Roland (TM)
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.

No, your successor should answer the request, as one should ping
own ID+1. This seems to be inconsistent with the RFC:
"P SHOULD then send a Ping for its own Node-ID routed through B."
Own Node-ID would not work and the initial join procedure
in sec. 10.5 says
"JN SHOULD send an Attach request to the Admitting Peer (AP) for
Resource-ID n+1"

So Michael already filed an errata.

Post by Evgeny
my_node -> boot_node -> ... -> node_X -> my_node
my_node -> node_X -> ... -> boot_node -> my_node
So the idea is to check if node_X is the successor of my_node, right?
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?

The originator of the reply message can be found in the identity part of
the signature block.

Post by Evgeny

Post by Bless, Roland (TM)
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.

Regards,
Roland

[Evgeny]

Michael, Roland, thanks for your quick responses, now it makes things
clear ;)

[Michael Chen]

_______________________________________________
P2PSIP mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip

[Michael Chen]

-------- Original Message --------
Subject: Re: [P2PSIP] RFC6940: Detecting Partitioning
Date: Mon, October 15, 2018 12:56 am
On Mon, Oct 15, 2018 at 10:13 AM, Bless, Roland (TM)

Post by Bless, Roland (TM)
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.
my_node -> boot_node -> ... -> node_X -> my_node
my_node -> node_X -> ... -> boot_node -> my_node

No, but congratulation, you just discovered a new erratum. The partition
check 10.7.4.4 says, "repeat the discovery process used in the initial
join", which refers to the 2nd paragraph after 10.5.9:

"It SHOULD send a Ping directed at Resource-ID n+1 (directly after
its own Resource-ID)."

Section 10.7.4.4 incorrectly used the term "Node-ID". It should be:

"P SHOULD then send a Ping for its own Resource-ID n+1 routed
through B."

Destination Resource-ID n+1 ensures that it will only be answered by the
successor of the requester.

Thanks

--Michael