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.

-- 
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
>
>