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

otroan@employees.org Fri, 04 December 2020 08:19 UTC

Return-Path: <otroan@employees.org>
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 5C2653A15B2; Fri, 4 Dec 2020 00:19:22 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 KdYOGPBydOo2; Fri, 4 Dec 2020 00:19:17 -0800 (PST)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C17233A151C; Fri, 4 Dec 2020 00:19:17 -0800 (PST)
Received: from astfgl.hanazo.no (201.51-175-101.customer.lyse.net [51.175.101.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 4245B4E11B08; Fri, 4 Dec 2020 08:19:16 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 1532746DF105; Fri, 4 Dec 2020 09:19:14 +0100 (CET)
From: otroan@employees.org
Message-Id: <B9DC56CD-E2A7-469C-9E8F-596554DA1A80@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_C3382936-5006-4ECA-A9BD-6A577EA63BEA"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\))
Date: Fri, 04 Dec 2020 09:19:13 +0100
In-Reply-To: <20201204064930.GY44833@faui48f.informatik.uni-erlangen.de>
Cc: Ted Lemon <mellon@fugue.com>, 6MAN <6man@ietf.org>, iotops@ietf.org
To: Toerless Eckert <tte@cs.fau.de>
References: <695953.1606952552@dooku> <B989299A-ED3C-4205-A4E2-DA080F574B33@fugue.com> <20201203174901.GW44833@faui48f.informatik.uni-erlangen.de> <36EA3F9D-A79D-4BC0-B894-54B7D3054476@fugue.com> <20201204064930.GY44833@faui48f.informatik.uni-erlangen.de>
X-Mailer: Apple Mail (2.3654.20.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotops/h3Vu-Ap-5KptxaNn8r6LO9nQI8c>
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: Fri, 04 Dec 2020 08:19:23 -0000

Let's me see if I can dissect Ted's arguments against HNCMP in https://tools.ietf.org/html/draft-lemon-stub-networks-ps-00#section-1.3, and if restricting the problem to only allowing stub routers to be connected to a single router helps. (A topology with a single root router and a single level of branches).

1) HNCP only works if all routers in the AS runs it. It's a routing protocol so that's not surprising.
Solutions would have to either participate in routing and a prefix assignment protocol.
The degenerate case for routing is default route upstream and a static route for the assigned prefix downstream.
All traffic to sieblings would go via root router.

Ted also mentions that HNCP does not deal with the case where only a /64 has been delegated to the site.
In homenet we did a conscious choice of requiring a site to get enough addressing to get a /64 for each link.
I do know that the implementation in OpenWRT does support a single /64 (it subnets into /80s and does DHCP address assignment).
How to deal with a case of not enough addresses assigned is not a problem unique to HNCP though.

The degenerate case for addressing is:
a) Split up a /64 in pools of addresses for DHCP
b) If less than a /64 (e.g. already shared) then NAT

2) HNCP is too complex and does too much and is not implemented.
Not enough details to make any arguments for or against this one.
If one standard isn't deployed and implemented is a weak argument for inventing a new protocol and standardising that, that's neither specified, implemented nor deployed.


Question, what are the requirements here?

A) Stub network. Is it possible to restrict the topology to a single root/single level of leafes?
It prohibits multi-homing. What about the case where a node is attached to the stub with a hypervisor and VMs requiring addressing?
Is sending all traffic via the root acceptable? Instead of short-cutting between stub routers?

B) Is it possible to restrict the solution to the site having been delegated enough address space?
Or do you need to handle the cases where the site has:
a) not received enough /64s to number all links
b) have only been delegated a single /64
c) have only a shared /64
d) have only a single address


Cheers,
Ole