How to solve the problem that multiple SRP Servers are in different LANs

[fuxiaoming-lumi]

We have two Thread Border Router BR-A & BR-B and they are in the same thread network.
Test Environment:

1. Two Thread Border Router BR-A & BR-B and they are in the same thread network.
2. BR-A & BR-B connect to same WiFi Router 01.
3. Add Thread SED(support auto srp client) and find it only register mdns service to one SRP server.
4. This mdns service will be discoverable with this phone.

                   phone 
                     |
                     |
BR-A <------> WiFi Router 01 <------> BR-B <------> Thread SED

5. Add new WiFi Router 02 and let BR-B switch to connect to WiFi Router 02(different ssid and password).

                   phone 
                     |
                     |
BR-A <------> WiFi Router 01         WiFi Router 02 <------> BR-B <------> Thread SED
  |                                                            |
  |------------------------------------------------------------|
                             Thread Link

6. This mdns service will not be discoverable with this phone. Although BR-A and BR-B are in the same network and they can communicate with each other, SRP Client seems to have no way to identify this situation. In this case, if there are two srp servers, should the srp client register mdns service with both srp servers? Or this use case is not within the scope of thread spec and needs to be solved in the application.

(From BR)
> netdata show
Prefixes:
fd11:32:0:0::/64 paros med bc00
Routes:
fd5b:32de:ad5b:beef::/64 s med cc00
Services:
44970 01 1a04b000000e10 s bc00
44970 5d fd70cfa623ca9ad0dd5c09a77ffc8b47d11f s bc00
44970 5d fd70cfa623ca9ad05994a480b9febcbbd11f s cc00
Done

[wgtdkp]

Or this use case is not within the scope of thread spec and needs to be solved in the application.

I believe existing Thread spec doesn't support multiple BRs on different AILs (Adjacent Infrastructure Link). @jwhui

Are there real-world use cases that this can be useful?

[fuxiaoming-lumi]

Yes. Let me share the use case.

1. The user purchased two Hubs (Speakers)(BR). At the beginning, the user connects the two Hubs to WiFi Router 01 and let's say they are in the living room.
2. One day, the user wants to be able to perform voice control on the bedroom, so one of the Hub is moved to the bedroom. But there is another WiFi Router 02(different ssid and passcode) in the bedroom and use vendor app to switch wifi network via BLE or NFC.
3. The user's mobile phone is connected to Wifi Router 01 and want to implement local control, the control will fail (assuming that the controlled device is a Matter device, mdns discovery needs to be performed before control). It should be controllable technically, because the thread network is reachable, right?

[jwhui]

Currently, Thread devices only register with a single SRP server. If the SRP server is not attached to the same infrastructure link, the mobile phone will not be able to use mDNS.

The right long term solution here is to have the infrastructure network (i.e. home network) provide the SRP server and advertising proxy functionality. However, we are not quite there yet.

[fuxiaoming-lumi]

Thanks. According to A SHARED MESH: THE PROMISE OF THREAD, we are also thinking about how to guide users to configure the right home Thread network and Interoperability between different vendor Border Router. So the best practise is to direct users to connect multiple border routers to the same wifi router. And prompt the user, if connected to different infrastructure link, there may be Interoperability issues.

[jwhui]

Note that this issue is not specific to Thread. Matter devices connected to Wi-Fi will have a similar issue since mDNS is constrained to link-local scope. In other words, a home network should operate as a single broadcast domain until performing DNS-SD over multiple links is more established.

[fuxiaoming-lumi]

Yes. I agree that this is not the issue to Thread.
For the use case I described, I am wondering whether it is possible to implement an information synchronization mechanism (like mdns reflector or mdns gateway) in the thread network. Not sure if this is the right solution, maybe complicating things.

[fuxiaoming-lumi]

@jwhui SRP replication could help this use case ?

[abtink]

Not necessaily. In SRP replication partners discover each other using mDNS/DNS-SD over infrastructure link.

[fuxiaoming-lumi]

We aspire to create a shared thread network within users' homes. To accomplish this vision, our app utilizes APIs provided by iOS and Android. However, in reality, ensuring the correct configuration of users' infrastructure devices in their homes has proven to be challenging.
IOS - Share Thread Credentials
Android - Share Thread Credentials