[homenet] Discussion on draft-ietf-homenet-simple-naming-03

RayH <v6ops@globis.net> Fri, 26 July 2019 12:42 UTC

Return-Path: <v6ops@globis.net>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D14120236; Fri, 26 Jul 2019 05:42:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.478
X-Spam-Level:
X-Spam-Status: No, score=0.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, MISSING_MIMEOLE=1.899, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSXCxs1dpmuP; Fri, 26 Jul 2019 05:42:30 -0700 (PDT)
Received: from globis01.globis.net (92-111-140-212.static.v4.ziggozakelijk.nl [92.111.140.212]) by ietfa.amsl.com (Postfix) with ESMTP id 3122312021D; Fri, 26 Jul 2019 05:42:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 0271F401B6; Fri, 26 Jul 2019 14:42:26 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at globis01.globis.net
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jE2n6wtIZ-HJ; Fri, 26 Jul 2019 14:42:23 +0200 (CEST)
Received: from [192.168.2.25] (athedsl-288528.home.otenet.gr [85.73.174.174]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id BD41F40193; Fri, 26 Jul 2019 14:42:21 +0200 (CEST)
Date: Fri, 26 Jul 2019 15:42:13 +0300
Message-ID: <1df50d95-bee8-4561-8124-0518236187bc@email.android.com>
X-Android-Message-ID: <1df50d95-bee8-4561-8124-0518236187bc@email.android.com>
From: RayH <v6ops@globis.net>
To: draft-ietf-homenet-simple-naming@ietf.org
Cc: homenet@ietf.org
Importance: Normal
X-Priority: 3
X-MSMail-Priority: Normal
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/vJlStFM-q5k5gqwnbfvS4A_3O8M>
Subject: [homenet] Discussion on draft-ietf-homenet-simple-naming-03
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jul 2019 12:42:31 -0000

Hi, I've re-read this draft and have some questions and comments.

The draft seems to assume a typical primary secondary DNS set up configured using HNCP.

I checked but couldn't see explicit details of the election process for determining which node would become master for the base zone e.g. home.arpa.

I did see the round robin query specification to gather the maximum amount of information, and how dnssd clients find and update the master.

Is the master for the base zone elected in the same way as the zones per link?

I also have some questions about transitory status and synchronisation.

The assumption seems to be that state can be preserved in a distributed system where nodes leave and join the network.

My concern is not about recovering a network partitioned for hours or days, because there's not much we can do about that, but more avoiding short term race conditions of seconds or minutes.

Example 1: HNCP uses trickle. During boot up, and power cycling, many nodes may arrive and depart at unpredictable times. The state of each node also takes time to propagate across the homenet on a hop by hop basis.

How does a node know HNCP has reached network-wide convergence before starting serving as the master?

Wait for local trickle timers to reach a certain threshold? Wait for a fixed period? We don't care?

Otherwise it's likely we'll end up temporarily at least with two active masters and/or hot secondaries.

Example 2: new high priority node arrives in the network out of the shrink wrap or after a hard reset and thus has a blank zone.

Does the blank zone become authorative: wiping all existing state?

[standard DNS replication assumes copying from master to slave, not stitching together information from alternative sources]

"Nodes without recent state information should reduce their announced priority so they aren't chosen as master over nodes with existing state information"?

"On learning new servers for the base domain via HNCP, a node SHOULD query that server to try to glean additional state information. Non-conflicting information MAY be added to local state"?

Or do we punt and give the hint that "state retention in Homenet is imperfect, and all nodes SHOULD regularly resolve and re-publish, update, or delete their own rr's as necessary"?

Regards,
RayH