Re: [Anima-bootstrap] joiner router stateful/stateless considerations

peter van der Stok <stokcons@xs4all.nl> Wed, 20 January 2016 08:29 UTC

Return-Path: <stokcons@xs4all.nl>
X-Original-To: anima-bootstrap@ietfa.amsl.com
Delivered-To: anima-bootstrap@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD69B1B3912 for <anima-bootstrap@ietfa.amsl.com>; Wed, 20 Jan 2016 00:29:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Level:
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 tTfK1c8T6OG4 for <anima-bootstrap@ietfa.amsl.com>; Wed, 20 Jan 2016 00:29:38 -0800 (PST)
Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D47D1A0171 for <anima-bootstrap@ietf.org>; Wed, 20 Jan 2016 00:29:38 -0800 (PST)
Received: from webmail.xs4all.nl ([194.109.20.217]) by smtp-cloud2.xs4all.net with ESMTP id 88Vc1s0094h15BW018VcLu; Wed, 20 Jan 2016 09:29:36 +0100
Received: from AMontpellier-654-1-17-221.w90-0.abo.wanadoo.fr ([90.0.32.221]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 20 Jan 2016 09:29:36 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 20 Jan 2016 09:29:36 +0100
From: peter van der Stok <stokcons@xs4all.nl>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <5232.1453219441@obiwan.sandelman.ca>
References: <3993.1453005398@obiwan.sandelman.ca> <792a80be15de2b353298752e7b8d160d@xs4all.nl> <5232.1453219441@obiwan.sandelman.ca>
Message-ID: <f9919477da0576077d643dbf2ffd72c4@xs4all.nl>
X-Sender: stokcons@xs4all.nl (M/jgVaxPQ+a8JFFKiqdaLF3pF1VVmVf/)
User-Agent: XS4ALL Webmail
Archived-At: <http://mailarchive.ietf.org/arch/msg/anima-bootstrap/in78jvPrLxIKrbX9Bh86cLBTxCw>
Cc: anima-bootstrap <anima-bootstrap@ietf.org>, consultancy@vanderstok.org
Subject: Re: [Anima-bootstrap] joiner router stateful/stateless considerations
X-BeenThere: anima-bootstrap@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: consultancy@vanderstok.org
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <anima-bootstrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima-bootstrap/>
List-Post: <mailto:anima-bootstrap@ietf.org>
List-Help: <mailto:anima-bootstrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jan 2016 08:29:41 -0000

>  I **SUGGEST** that the anima
> bootstrapping services
>     > both types of networks. That may mean that 2 solutions from the
> ones proposed
>     > in joinrouter document are chosen.
> 
> Which two solutions would you pick?

Below are the options for the managed constrained network, right? Thus 
one of the 2 solutions.

> 
> From the new node to joining router, we have three options:
>      A) CoAP/DTLS, B) HTTPS, C) HTTPS over HTTP proxy.
> 
> I prefer (A) as MTI, with (C) as MAY.

I tend to prefer (A) as I don't understand all consequences of (C)

> From the joining router to the registrar, I prefer method 6, CoAP/DTLS 
> with
> IPIP tunnel.  I think that this works the best in a constrained 
> network,
> where I do not expect to see an ACP.

Sounds reasonable, will try to think of alternatives.

> 
> At the edge of the contrained network, the 6LBR might have an ACP, and 
> would
> further route the join the traffic that way.  The IPIP header might be
> addressed to the 6LBR, and re-encapsulated by the 6LBR as well, but 
> that
> would involve some state (methods 1 or 2) on the 6LBR: That may be 
> acceptable.
> 
> I'm trying also to build a system that could also be initiated from the
> registrar to new node direction, as I've proposed in 6tisch.

I have no preferences on initiaion location for the moment.

> 

> I think that the point is that we don't know (in this document, at this
> stage) precisely if the new node and proxy communicate at layer 2 (e.g. 
> 802.1x)
> or layer 3 (PANA, CoAP/HTTP, etc.).  That's why it says "or"

OK, I got it, a specification "xor" and not an operation "or"

peter