Re: [core] πŸ”” WGLC for Resource Directory

Peter van der Stok <stokcons@bbhmail.nl> Thu, 30 May 2019 07:29 UTC

Return-Path: <stokcons@bbhmail.nl>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F95412004F for <core@ietfa.amsl.com>; Thu, 30 May 2019 00:29:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.nl
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 7UlTPapSDtIa for <core@ietfa.amsl.com>; Thu, 30 May 2019 00:29:40 -0700 (PDT)
Received: from smtprelay.hostedemail.com (smtprelay0155.hostedemail.com [216.40.44.155]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EC1512006F for <core@ietf.org>; Thu, 30 May 2019 00:29:39 -0700 (PDT)
Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay01.hostedemail.com (Postfix) with ESMTP id C6B50100E86C5; Thu, 30 May 2019 07:29:38 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=5IYs0rZxj8/Awk4NOA nXLrqGRsYyESD6aAB4f062B9I=; b=AR0nKyJEIsQlnLdwgINoLBHmRERqRkGcru piOeajm3IjTpKOpm98Faf0dQLk9OJdWouuarvxvXpme8yfzMMIv90P67ASFnEPFo LkAHri6gKL4UyL4fKsyi65y4hUngSW/gKZTd0Y60k8RT0woiZ1Jd/mC/yyTlUU55 F7p5gRZlQ=
X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C
X-Spam-Summary: 10, 1, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::, RULES_HIT:41:46:72:150:152:355:379:582:800:960:962:967:973:983:988:989:1152:1189:1208:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1535:1543:1575:1588:1589:1592:1594:1711:1730:1776:1792:2194:2198:2199:2200:2527:2528:2553:2557:2559:2562:2692:2693:3138:3139:3140:3141:3142:3354:3586:3622:3769:3865:3866:3867:3868:3870:3871:3872:3873:3874:4118:4250:4321:4362:5007:6117:6119:6261:6298:6657:6659:6678:6691:7875:7903:8603:9108:9177:10004:10400:10848:11232:11657:11658:11914:11984:12043:12114:12555:12740:12895:12986:13071:13139:13161:13229:13255:13439:14093:14096:14180:14181:14721:21060:21080:21324:21433:21451:21625:21740:21810:30003:30028:30041:30054:30062:30090, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:24, LUA_SUMMARY:none
X-HE-Tag: way45_370cc6d881d23
X-Filterd-Recvd-Size: 7811
Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf07.hostedemail.com (Postfix) with ESMTPA; Thu, 30 May 2019 07:29:38 +0000 (UTC)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_4d4c7d7b21ea987deff445fc2961626e"
Date: Thu, 30 May 2019 09:29:37 +0200
From: Peter van der Stok <stokcons@bbhmail.nl>
To: Ted Lemon <mellon@fugue.com>
Cc: consultancy@vanderstok.org, core@ietf.org, Stuart Cheshire <cheshire@apple.com>
Organization: vanderstok consultancy
Reply-To: consultancy@vanderstok.org
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <E4E34317-03D5-448E-BB12-06EFC1FDC353@fugue.com>
References: <AM5PR0701MB230754CF5CD643B6B7DC1A7697420@AM5PR0701MB2307.eurprd07.prod.outlook.com> <EBFF17D7-86DF-4C3E-B69E-EF69206A6D17@fugue.com> <02585a832a91742de93f6d311259ae61@bbhmail.nl> <CF34C053-A417-4914-BB28-B4E47E97A625@fugue.com> <498bff27c1804f08365f0e11e6d24050@bbhmail.nl> <32B6BB77-91AA-4F85-B5EA-6AC8C6407F7F@fugue.com> <a97554a90cfd49ce21fb59e43ff0ed63@bbhmail.nl> <33B4FD70-E650-47E4-A603-BD4928E4C47F@fugue.com> <f7fe549e40f879c6f46a0a7d8242241a@bbhmail.nl> <137192BD-7638-4D2E-A6E5-E1618499366F@fugue.com> <0d20366a188573397f9e98e4f8adc8e2@bbhmail.nl> <34EE8F1D-62E6-4C8C-B967-834BAF1FFFAF@fugue.com> <cfb17f0ee8d4dd0e0984b58658e78cfb@bbhmail.nl> <E4E34317-03D5-448E-BB12-06EFC1FDC353@fugue.com>
Message-ID: <4afdae3b6feeddb3af3b276188f97b30@bbhmail.nl>
X-Sender: stokcons@bbhmail.nl
User-Agent: Roundcube Webmail/1.2.7
X-Originating-IP: [86.203.99.87]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/JAAVvcR6y5STMUB6_MOuKJDDsn8>
Subject: Re: [core] πŸ”” WGLC for Resource Directory
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 May 2019 07:29:43 -0000

Hi Ted,

thanks for the dissection of use cases. The ones I understand:

1a) no infrastructure with nodes that see each other.
1b) followed by nodes that see each other connected to an infrastructure
with border router (possibly intermittently)
2) nodes that see each other connected to an infrastructure with border
router (possibly intermittently)

Where 1b and 2 are actually identical; and 1b does not necessarily
follow 1a.

The intermittent connection to the border router is not important
because from the first connection to the 6LBR, the 6LR remember the
border router options.

When different border routers fly over, it wil be difficult to to
instruct them all what the RD address is. (not clear what to recommend
here, I prefer to leave that out)

When nodes do not see each other, the presence of an RD is irrelevant.

The case that a node migrates from one infrastructure to the next is
beyond my competence. That was a use case for home networks with DNS
support?

I will add some phrases to the building control section to make the
connection to (absence of) the infrastructure clearer.

Any other suggestions?

Peter
Ted Lemon schreef op 2019-05-29 19:04:

> On May 29, 2019, at 8:23 AM, Peter van der Stok <stokcons@bbhmail.nl> wrote: 
> 
> Nodes want to use the RD before the 6LBR is connected.

Hm, okay.   That's the piece I was missing.   So there is some
infrastructure, just no external connection?   Or there is no
infrastructure, just nodes that find each other?   I _think_ these are
two separate use cases.   The use case I thought you were talking about
is where there are nodes that don't see each other, but do see the
border router as it flies over/drives by/whatever.   I suppose another
use case is where the leaf node is mobile, and the network
infrastructure that it sees changes over time: sometimes nothing,
sometimes ranger station 1, sometimes ranger station 2, etc. 

IOW it would be good to enumerate these use cases in more detail, and
then ask the question, how can I best configure this network, for each
such use case.