Re: [Iotops] Automatically connecting to stub networks...

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Mon, 07 December 2020 20:49 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: iotops@ietfa.amsl.com
Delivered-To: iotops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A702A3A09CC; Mon, 7 Dec 2020 12:49:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.118
X-Spam-Level:
X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.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 8EbdHMgLKiXz; Mon, 7 Dec 2020 12:49:44 -0800 (PST)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536EB3A09C9; Mon, 7 Dec 2020 12:49:44 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 0B7Knf9F026501; Mon, 7 Dec 2020 15:49:42 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1607374182; bh=064JBbd/nu5udA+YnM/d6lgBEnhTy12885fOOQwU+i4=; h=From:To:CC:Subject:Date:From; b=MFeIcYqmfAK5PqtoT/4iJ1SUh5rQugIyg1Igx6/luyA7kE8VAvxALddQpKHfI35Ku pf9IW8m6nXDxgJc9VkxljedPlpeJlZ4Bt1qRr/ZGSXr6q/1gWvofPjDPny3AD6DxkH W0dJZCyRRdArf3lLkx1d1dAFA4LUmo0nLxC1q2j0x3SXyu8woiATipGPpd8+F9VIt8 +VsBXtAwuw/alb9+AFhWgQdZwjS8Txfw9agNIpBkOHzH+RQ0FpW1jen6wrmJq6DHct 9sQwbewUx50oDqxt/x/R9KGGLHfZeCvtzwP3ntq9L7gewHj+YeLFiNIQIxb1S4HjwG hHnELlJp45y4Q==
Received: from XCH16-07-12.nos.boeing.com (xch16-07-12.nos.boeing.com [144.115.66.114]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 0B7KnTBu026366 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 7 Dec 2020 15:49:29 -0500
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-12.nos.boeing.com (144.115.66.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Mon, 7 Dec 2020 12:49:28 -0800
Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Mon, 7 Dec 2020 12:49:28 -0800
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Ted Lemon <mellon@fugue.com>
CC: "STARK, BARBARA H" <bs7652@att.com>, Michael Richardson <mcr+ietf@sandelman.ca>, Ole Trøan <otroan@employees.org>, 6MAN <6man@ietf.org>, "iotops@ietf.org" <iotops@ietf.org>
Thread-Topic: [Iotops] Automatically connecting to stub networks...
Thread-Index: AdbM2RVU6TN99+sHT4u+0UMKR97w+w==
Date: Mon, 07 Dec 2020 20:49:28 +0000
Message-ID: <6816090d7f43480490396c569cf6e24b@boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: CB2FFDBCB7B9F30E661487E7E866D049CD66CF346600EACCEA89C5C965D474D22000:8
Content-Type: multipart/alternative; boundary="_000_6816090d7f43480490396c569cf6e24bboeingcom_"
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotops/1dP-JOt_l1-bKnJMAaY-sYa6gNk>
Subject: Re: [Iotops] Automatically connecting to stub networks...
X-BeenThere: iotops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IOT Operations <iotops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iotops>, <mailto:iotops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iotops/>
List-Post: <mailto:iotops@ietf.org>
List-Help: <mailto:iotops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iotops>, <mailto:iotops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2020 20:49:47 -0000


From: Ted Lemon [mailto:mellon@fugue.com]
Sent: Monday, December 07, 2020 12:28 PM
To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
Cc: STARK, BARBARA H <bs7652@att.com>; Michael Richardson <mcr+ietf@sandelman.ca>; Ole Trøan <otroan@employees.org>; 6MAN <6man@ietf.org>; iotops@ietf.org
Subject: Re: [Iotops] Automatically connecting to stub networks...

Ted, it surprises me that I don’t seem to be reaching you on this, so maybe we are
talking about different things? My model for a mobile node is a mobile router with
a downstream-attached network where one might find an attached “Internet of
Things” – a simplest example would be a small router with a “northbound” wireless
interface and a “southbound” Ethernet interface attached to a switch to which a
small number of hosts are connected. The mobile router needs to get a “Mobile
Network Prefix (MNP)” from the network via its “northbound” interface, so it sends
an RS with a piggybacked DHCPv6 Solicit on board. The Access Router in the
network gets the RS, extracts the DHCPv6-PD Solicit and sends it to the DHCPv6
Server, gets back the DHCPv6-PD Reply, then crafts an RA with the DHCPv6 Reply
on board and sends it back to the mobile router. The mobile router then turns around
and advertises the delegated prefix over the “southbound” interface, and the attached
IoT devices are happy. Is this not the kind of scenario you are interested in when you
talk about stub networks?

Fred


On Dec 7, 2020, at 3:21 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>> wrote:
Ted, there is a need to reduce the number of messages especially on low end
wireless links like those used for aviation. So, if a terse DHCPv6 PD exchange
can be piggybacked on-board the RS/RA exchange that already needs to be
there in any case then there is a tangible savings on messages over the air.
This is good for more than just aviation, too, and applicable for mobile use
cases such as intelligent transportation systems and urban air mobility; maybe
even for pedestrians too.

I still can’t think of a case where this applies to stub networks. E.g., if you decide to support stub networks on an airplane, you’re going to need a prefix to allocate stub network prefixes from. That’s one transaction over the satellite link to get that prefix, plus some maintenance. If your satellite link is so slow that this is a problem, it’s not going to be usable, so we don’t need to address that use case.

If you are thinking that the airplane’s public WiFi network is itself a stub network, I think that would be out of scope for stub networks—the whole point of stub networks is to be able to automatically connect without an operator’s intervention, which doesn’t match your use case. Additionally, I would consider a home network connection to also be out of scope for stub networks, and that’s somewhat analogous to the airplane use case.

If you mean the airplane’s automation network, the same objection applies.

So I really don’t see where there’s overlap here.