Re: 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: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C88F3A138E for <ipv6@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 WoaNSut2J_Ql for <ipv6@ietfa.amsl.com>; Sat, 27 Feb 2021 12:19:15 -0800 (PST)
Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (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 0A15B3A1393 for <6man@ietf.org>; Sat, 27 Feb 2021 12:19:14 -0800 (PST)
Received: by mail-qv1-xf2c.google.com with SMTP id t1so5244795qvj.8 for <6man@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=l6o6IiO4NVtvCs0/FswBW9Ci61FVAnAnLUT4jS37EVZqDbBPro5eUUfSUtuAnDOABL qM8Ck73HmIj12w1fb/CCUYozTrPqdYTzP0LNtTgI2O5WhIQzYKC2/KNr+IcJW7xCjmck PO+BBOjCBpJYpUrYuJoWtCxwo3bt+kdB0xNL2FNU9hyuYX8an2rcn0N2DbDUMZWrxFXy cGj6pzYQSGlujl7swZ8xgRMm1U4N6AF3pwEuHQLwp8Z9v54ZGJu4+OifVmXdub8vpmvt pdybGp/pMfQUs++mp2ih7BwmqqyXiXUX8KeSDnxGVHO9TYPnBtLsAswmm2e15+6dhR/6 sh5w==
X-Gm-Message-State: AOAM530DXANDA4yvB8qJH0OP8fNK3TRUOK0OhUtgVlVkZbPFg8KRNKBw sZwcxubuJhwqwcOEWwubKA0UTLtIsif46A==
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\))
Subject: Re: Ted's stub network document: draft-lemon-stub-networks{,-ps}
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/ipv6/aPUDGTD_XxJ-DUBg5PyCXW6U4QU>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Feb 2021 20:19:17 -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. :)