IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 03 December 2020 13:55 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 7598A3A0B5D; Thu, 3 Dec 2020 05:55:55 -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 SxnmYw4UudnK; Thu, 3 Dec 2020 05:55:53 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1522C3A0B5C; Thu, 3 Dec 2020 05:55:52 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id F3C32389D4; Thu, 3 Dec 2020 08:57:43 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sHX_yPVR26O8; Thu, 3 Dec 2020 08:57:43 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7751D389CE; Thu, 3 Dec 2020 08:57:43 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3973E1FB; Thu, 3 Dec 2020 08:55:51 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Qin Wu <bill.wu@huawei.com>, "iotops@ietf.org" <iotops@ietf.org>, Ted Lemon <mellon@fugue.com>, 6MAN <6man@ietf.org>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABAADBDE6E0@dggeml511-mbs.china.huawei.com>
References: <B8F9A780D330094D99AF023C5877DABAADBDE6E0@dggeml511-mbs.china.huawei.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 03 Dec 2020 08:55:51 -0500
Message-ID: <24496.1607003751@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotops/HwOerual39hjsqygqZzQIQ_GX1g>
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: Thu, 03 Dec 2020 13:55:56 -0000

Qin Wu <bill.wu@huawei.com> wrote:
    >>> In answer to your question: State of the Art
    >>>
    >>> Currently there is one known way to accomplish what we are describing
    >>> here [[Michael, does ANIMA have a second way?]].
    >>>
    >>> The ANIMA ACP sets up an overlay network with /128 routing via
    >>> RPL(RFC6550) storing mode.

    > I am wondering how ACP+RPL is different from HNCP+Babel? Are they equivalent?

They are not equivalent.
They do different things.
They could be used at the same time.
Both can benefit from BRSKI for enrollment of new devices, but both could do
enrollment via another method.

There are similiarities in how some things work.

For instance, both use multicast, and both use IPv6.
Both contain mechanisms to do prefix assignment at different layers.
[ACP/RPL assigns /128s to nodes.  An ANIMA ASA can use the ACP to do prefix
delegation.  The HNCP is used for prefix delegation directly]
(They also both use network byte order... so)

The ACP is an overlay network of point-to-point tunnels that tries hard to be
resilient, and does not *optimize* for shortest path.

HNCP is a consensus protocol which is used to for many things, including
prefix assignment, and the uses Babel to announce them.   It is not an
overlay.  It does find the shortest path.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email