Re: [dnssd] Adoption call for draft-sctl-advertising-proxy

> It generally only happens when the thread omr prefix changes. So in production network it should be rare. But the thread network can fluctuate a bit on startup as the mesh settles, and this can result in changes to > the omr prefix. So although this shouldn’t happen much, the time when is is most likely is right after a power outage or right when the devices are first installed.

Agree that OMR prefix can change for Thread devices of one partition
when two partitions converge.

Are you implying that the SRP server IP address in the SRP Unicast
Dataset is using the OMR address of the SRP server?

In such a case, an OMR prefix change would lead to SRP server IP
change in Unicast Dataset, which further lead to SRP clients having to
switch SRP server IP.
However if the SRP servers are using ML-EIDs in Unicast Dataset, the
SRP server IP won't change when partitions merge, which will lead to
less SRP server switches on SRP clients.

Nevertheless, if a SRP client migrates from one partition to another
and each partition has a different SRP server, the SRP client will
have to reregister, which will cause name conflicts (assuming no SRP
replication).

So, it's foreseeable that partitioning may cause many SRP name
conflicts when SRP replication is not adopted. That being said, can we
argue that SRP replication is less useful when TREL can significantly
reduce the chance of partitioning?

--
Simon Lin

Simon Lin | Software Engineer, Nest Shanghai | simonlin@google.com |
+86 13656630312

On Mon, Aug 16, 2021 at 11:17 PM <mellon@fugue.com> wrote:
>
> It generally only happens when the thread omr prefix changes. So in production network it should be rare. But the thread network can fluctuate a bit on startup as the mesh settles, and this can result in changes to the omr prefix. So although this shouldn’t happen much, the time when is is most likely is right after a power outage or right when the devices are first installed.
>
> --
> mellon@fugue.com
>
> On August 16, 2021 at 03:40:32, Simon Lin (simonlin@google.com) wrote:
>>
>> On the other hand we see conflicts all the time with SRP because of the two-SRP-server mDNS conflict detection algorithm, so it's pretty clear that SRP + mDNS conflict detection is a recipe for creating conflicts.
>>
>>
>> Could you explain why there are so many conflicts because of
>> two-SRP-server mDNS conflict detection algorithm?
>>
>> Are the SRP servers using SRP Anycast TLV or Unicast TLV?
>>
>> I would expect name conflicts to happen more often if SRP servers are
>> using Anycast TLVs because a SRP client can change SRP server for each
>> registration or renewing.
>>
>> When SRP servers are using Unicast TLV, a SRP client should stick to
>> the same SRP server for registration and renewing, even after the SRP
>> client is rebooted.
>> A SRP client may change SRP server when there are multiple request
>> failures, but I would expect it to be less often.
>> So, I would not expect many name conflicts for SRP servers using Unicast TLVs.
>>
>> On Sat, Aug 14, 2021 at 6:40 AM Ted Lemon <mellon@fugue.com> wrote:
>>
>>
>>
>> On August 13, 2021 at 6:24:51 PM, Jonathan Hui (jonhui@google.com) wrote:
>>
>>
>> Another thing to be aware of is that because of the way mDNS works, if you are using mDNS for discovery, a name conflict when names aren't being defended will sit around in the cache for a few minutes. If names are defended, this doesn't happen; one alternative is to just defend names and count on SRP to deal with conflicts, but the downside of this is that now there is a delay before the new information appears.
>>
>> This delay could potentially be minimized by retrying to register as soon as the SRP replication update has been acknowledged by all SRP replication peers—right now my code (when name defense is enabled) just waits two minutes before re-attempting, which is a lot longer than should be necessary.
>>
>>
>> Sounds like a good idea to explore. My initial concern is that waiting for positive confirmation from all peers can lead to other failure modes resulting from poor implementation or connectivity. At the same time, those same assumptions are what would lead us back to needing other mitigations.
>>
>> The problem with anything that's ad-hoc and not integrated into the infrastructure is that there's no model that guarantees success. It's always going to be best effort. The goal has to be to make "best" as good as possible, but have a backup strategy for when it's not quite good enough.
>>
>>
>> _______________________________________________
>> dnssd mailing list
>> dnssd@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnssd