Re: [homenet] Ted's stub network document: draft-lemon-stub-networks{, -ps}

Ted Lemon <mellon@fugue.com> Sat, 27 February 2021 20:19 UTC

Return-Path: <mellon@fugue.com>
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 8AB1F3A138D for <homenet@ietfa.amsl.com>; Sat, 27 Feb 2021 12:19:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 9pCa5psyGhie for <homenet@ietfa.amsl.com>; Sat, 27 Feb 2021 12:19:15 -0800 (PST)
Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087003A138F for <homenet@ietf.org>; Sat, 27 Feb 2021 12:19:14 -0800 (PST)
Received: by mail-qv1-xf31.google.com with SMTP id x13so323297qvj.7 for <homenet@ietf.org>; Sat, 27 Feb 2021 12:19:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/GaA2Y/Az3ixohFHntYwMZuTe06yn+ZDCbK6D71xTNE=; b=jG0tRyr1aez9NSEY/5zX0N85uCMPnqemF+7kTXzvonzaxao9R2SFlYNM5PKMPRPhvh ELM18j+GuHpTIC74AZdxqO2715tyexSTJtoOqCPcZdvoJLl3fumyTt2ZfQ0JWKVBmevN xrgAVIiDKq4Ue0mhFZBgwjpRG2IIeHk3jVUGK0+B908BlBFxS50Yibe3HZiEsJZyllhf 2VNdIXi3UmxMm105kU+okfUavRb29GrNcwKKUN4ZQ9P4WTWChh8shnWFiOfdaN5tadN2 OVYQPNVEUpELaQ5irgI45Ifx63500itR11KbUWPBgMsyoP7w2jyCmX5LVaju3X229cfS Q2WQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/GaA2Y/Az3ixohFHntYwMZuTe06yn+ZDCbK6D71xTNE=; b=ZMNScxvwON+pADPYA8GQaLBgYKSJ2/7iS6uaEeBUmUMTXe9y3PSe2isMci6rWrvhwf J4bofuwuePrRSoCqyT9d/9RKc+Jq4Y96/1eWa+7BZ+ajuC6FmVXm7qGNN0v+0j9AAN7K QO9YvG8dB8gWidDrCbL8hBcO49hYLsdPv17fPPjwxF/6L1hseymh6x/p1FtlBvLtXM2o tuE6E18vCBlCpR5HwFZYeZ1S9EwlrCxulA4tWNWNEPGD6l6qOGnlrbMRBPnYJX3nKJkJ 8QsIehUWXGAFfasFZ+J7VmltSQ/gR/9vFzdq1KPZvzSmWDqkkXiXj+wzgX1tcPSyeI0V lh8w==
X-Gm-Message-State: AOAM5325n1AMecsUXK9JdzNhHVfzDQeZbR7Neu4bUsb2ya4ZCFU7uXRy jLmJyRKqCCEdi9bpQG1jcKmF2g==
X-Google-Smtp-Source: ABdhPJwTemrnsgo8Qlc+F4KyKNWDDkHJx3YFE+xAg7Ok3zrjlDyn/NtTzeh/NwX5Go+phMGt9MMbNQ==
X-Received: by 2002:a0c:a404:: with SMTP id w4mr8682857qvw.22.1614457154006; Sat, 27 Feb 2021 12:19:14 -0800 (PST)
Received: from smtpclient.apple (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id q15sm9102850qkm.126.2021.02.27.12.19.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Feb 2021 12:19:13 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.33\))
From: Ted Lemon <mellon@fugue.com>
In-Reply-To: <389E2CE9-A3A7-48D1-82D3-0ADA11981765@fugue.com>
Date: Sat, 27 Feb 2021 15:19:12 -0500
Cc: 6man@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <81FFDCE1-A297-47E1-B82A-F498E4F1F5A8@fugue.com>
References: <13781.1614356677@localhost> <389E2CE9-A3A7-48D1-82D3-0ADA11981765@fugue.com>
To: iotops@ietf.org, Homenet Working Group <homenet@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3654.80.0.2.33)
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/rx-97CBbdtNW_8t79MjJ8tZgMps>
Subject: Re: [homenet] Ted's stub network document: draft-lemon-stub-networks{, -ps}
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: Sat, 27 Feb 2021 20:19:18 -0000

Since I’m updating the document...

> On Feb 26, 2021, at 12:01 PM, Ted Lemon <mellon@fugue.com> wrote:
>> On Feb 26, 2021, at 11:24 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
>> 2) There is advice about monitoring the RAs from the infrastructure router
>>  (which is probably the home CPE router), and soliciting them regularly.
>>  In effect, the Stub Router can't depend that the CPE router will remain
>>  alive for it's lifetime.
>>  That is, the RA lifetimes tell the client how long it may use the
>>  resource, but not how to determine if the router is alive.  Of course,
>>  power can disappear at any time.
>>  Ted: it seems that maybe neigh-cache entries already have all the timers
>>  and rechecks needed, and maybe the Stub Router can just watch for
>>  the NCE going Stale?
> 
> That would work, but depends on the stub router implementation being able to get a notification that this has happened, which means it’s running in the kernel. I don’t think that’s a likely scenario. Also, NCEs have lifetimes, so they will also outlive on-link routers.

I’ve added this, but please suggest better wording:

	    As an alternative to the vicarious router discovery process described here, the stub router could monitor the presence
	    of the router advertising the on-link prefix in the neighbor cache. If the neighbor cache entry becomes stale, this
	    could be an indication that the prefix is also stale. If the neighbor cache entry goes stale, the router would need to
	    try to refresh it, and if that fails, then the stub router must begin advertising its own on-link prefix on the stub
	    network.


>> 4) I'd like to add a state machine diagram to 3.1.1/3.1.2.
> 
> I think that’s a good idea, although I am not really a fan of state machine *diagrams* — I’d maybe rather just describe the state machine. Diagrams are easy to misread. There are actually several state machines, and each I think is fairly simple, so writing out a list of states, events and state transitions may be practicable.

This is noted, and on the to-do list, but not today. :)