NFD

In 5309,2, the logic after obtaining a list of HUBs is:

1. Canonize a FaceUri. If canonization fails, go to step 5.
2. Send a face creation command. If face creation fails, go to step 5.
3. Register prefixes toward the HUB.
4. Declare success and abort these steps.
5. If the list contains another HUB, try the next HUB. Otherwise, declare failure.

First problem with this logic is: UDP face creation always succeeds, even if the HUB is down or unreachable.
Prefix registration toward a UDP face would not fail either.
Thus, Procedure must test the HUB works: send an Interest that the HUB would respond with either Data or Nack, then read face counters to check RX counter is non-zero.

Second problem: if none of the HUBs returns from one stage works, the program should try the next stage.
For example, after failing NDN-FCH, the next stage would be GuessFromIdentityName.

Junxiao Shi wrote:

In 5309,2, the logic after obtaining a list of HUBs is:

1. Canonize a FaceUri. If canonization fails, go to step 5.
2. Send a face creation command. If face creation fails, go to step 5.
3. Register prefixes toward the HUB.
4. Declare success and abort these steps.
5. If the list contains another HUB, try the next HUB. Otherwise, declare failure.

First problem with this logic is: UDP face creation always succeeds, even if the HUB is down or unreachable.
Prefix registration toward a UDP face would not fail either.
Thus, Procedure must test the HUB works: send an Interest that the HUB would respond with either Data or Nack, then read face counters to check RX counter is non-zero.

Agreed.

Second problem: if none of the HUBs returns from one stage works, the program should try the next stage.
For example, after failing NDN-FCH, the next stage would be GuessFromIdentityName.

Once a stage fails, it tries next stage. GuessFromIdentifyName has been added as the 4th stage since the previous commit.

Junxiao Shi wrote:

First problem with this logic is: UDP face creation always succeeds, even if the HUB is down or unreachable.

True. However, this is already the case today: the FCH stage always succeeds (unless the backend service itself is unreachable I guess), so the subsequent stages are never used. It's not a new problem introduced by this change. Therefore I'm not convinced that solving it belongs to this issue.

Thus, Procedure must test the HUB works: send an Interest that the HUB would respond with either Data or Nack, then read face counters to check RX counter is non-zero.

This sounds quite complicated and fragile. One potential alternative is to create faces towards all discovered hubs, and let the forwarding plane deal with nexthop selection as it should. This might even prove more reliable in some cases.

One potential alternative is to create faces towards all discovered hubs, and let the forwarding plane deal with nexthop selection as it should.

This would break prefix propagation, because /localhop/nfd/rib/register would point to multiple remote routers and the readvertise module would only receive one response. Hence, this solution would be blocked by #3142 #3143.

Junxiao Shi wrote:

One potential alternative is to create faces towards all discovered hubs, and let the forwarding plane deal with nexthop selection as it should.

This would break prefix propagation, because /localhop/nfd/rib/register would point to multiple remote routers and the readvertise module would only receive one response. Hence, this solution would be blocked by #3142 #3143.

I agree with Davide's proposal, because detecting whether a face works should not be part of this procedure, since forwarding plane or "link" layer is a better place to handle it.
@Junxiao, why prefix propagation cannot work with multiple remote routers?

why prefix propagation cannot work with multiple remote routers?

You have multiple /localhop/nfd registrations. When you send a /localhop/nfd/rib/register command to propagate a prefix, you can receive no more than one response. Without receiving all responses, you can't determine whether prefix propagation has succeeded.

You have multiple /localhop/nfd registrations. When you send a /localhop/nfd/rib/register command to propagate a prefix, you can receive no more than one response. Without receiving all responses, you can't determine whether prefix propagation has succeeded.

A local producer registers a prefix on a local NFD. The local NFD propagate this prefix to multiple connected gateways. These two steps are separate.

A local producer registers a prefix on a local NFD.

This step is unaffected.

The local NFD propagate this prefix to multiple connected gateways.

This step would not work if there are multiple /localhop/nfd registrations.

These two steps are separate.

Yes.

The local NFD propagate this prefix to multiple connected gateways.

This step would not work if there are multiple /localhop/nfd registrations.

What's the problem of handling this case, e.g., do registration for each gateway respectively?

What's the problem of handling this case, e.g., do registration for each gateway respectively?

See #3142 issue description.