What should a join proxy due when it has access to multiple registrars?

[mcr]

Assume that a Join Proxy is receiving GRASP M_FLOOD messages on it's uplink (ACP) side.
What should it do when it receives announcements from multiple Registrars (distinct v6 locators).
Where does it connect to?
The choices are:

1. pick most recent announcement.
2. pick the one to which a reply was most recently received (or TCP connected successfully)
3. pick one at random
4. pick one in a round-robin fashion

If a packet is forwarded to a Registrar, and it does not reply within ?-seconds, does it then drop that registrar from the list (or put it at the back) if it has others?

[EskoDijk]

I would assume the constrained-join-proxy draft can cover this topic? (Not constrained-voucher)

[mcr]

I transferred the issue. it applies to HTTPS join proxies too.
I'm not sure there is a protocol / IETF requirement here, except that determinism is good for debugging.

[EskoDijk]

Another alternative that was discussed once, is that the Join Proxy doesn't pick or filter: it just "relays" all the discovered Registrars and their type information (as encoded in e.g. key/values) one to one to the Pledges, using its discovery responses to Pledges.

E.g. there could be a regular Registrar and a "variant" Registrar, and the Pledge can then discover both and select.

The Join Proxy uses different ports to expose these different services and the Pledge makes the choice by connecting to a particular port.

however, I think this can become a kind of heavy burden on the Join Proxy! Selecting one seems best as in most cases there will be only 1 Registar.

Now we need to think of selection criteria - something simple .

[EskoDijk]

Correction: there may be a single registrar device/host that offers multiple Registrar services. For example, a classic BRSKI server on port A and a BRSKI-PRM server on port B. How could a Join Proxy possibly select between these two services?

[mcr]

I agree that the JP can't/shoudn't really pick or filter, and that it should just relay.
You are right that it could be heavy to pass everything, and maybe yes, it should limit how many it passes through.
Ideally, different JP would pick different things, and so we'd get full coverage in the end, but I don't have a way to assure that.

[mcr]

Correction: there may be a single registrar device/host that offers multiple Registrar services. For example, a classic BRSKI server on port A and a BRSKI-PRM server on port B. How could a Join Proxy possibly select between these two services?

This is not any different than two registrars offering one service each, is it?

[EskoDijk]

This is not any different than two registrars offering one service each, is
it?

Indeed, same situation. I added the comment here because we were talking often about multiple Registrars offering a service, which has the mental model of different IP hosts. But the multiple Registrar services could be located on a single IP host also.

[EskoDijk]

As context: RFC 8995 discovery (Section 4) doesn't mention that a JP could potentially advertise multiple Registrar services; it just defines that the JP advertises a single "Join Proxy" service. It doesn't seem to specify how the JP then selects the Registrar. Maybe that's part of the GRASP protocol: that it would select the "nearest" Registrar by default?

[mcr]

Yeah, it seems like a quality of implementation issue. In particular, we ought to be able to fix/update/change the JP behaviour without changing the bits on the wire at either side.

[EskoDijk]

Since we're talking about the Constrained JP for this issue, we can make some simplifying assumptions. E.g. like this:

• JP selects at least one Registrar to advertise (more is OPTIONAL)
• JP implementation, or a protocol that governs JP behavior, defines the selection criteria
• in the draft we list some example good practice criteria such as "JP picks a recent GRASP advertisement within some time window from the nearest Registrar"

Why would we not fully define JP behavior in this draft? Because we also have other aspects that aren't fully defined in the current draft, such as when a device decides to become a JP and when the JP function is being switched off for that device.
For example a standard like Thread may define this; and it may also define that there is only one Registrar service that a JP needs to select and advertise to Pledges.

In particular, we ought to be able to fix/update/change the JP behaviour without changing the bits on the wire at either side.

Yes, that looks fully aligned with my proposal.