Re: [6lo] Call for feedback to draft-wachter-6lo-can-00

"Carles Gomez Montenegro" <carlesgo@entel.upc.edu> Sun, 20 October 2019 15:54 UTC

Return-Path: <carlesgo@entel.upc.edu>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B821200F4 for <6lo@ietfa.amsl.com>; Sun, 20 Oct 2019 08:54:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 7vYtV-E047yz for <6lo@ietfa.amsl.com>; Sun, 20 Oct 2019 08:54:57 -0700 (PDT)
Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1DCA120090 for <6lo@ietf.org>; Sun, 20 Oct 2019 08:54:56 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id x9KFssUG001394; Sun, 20 Oct 2019 17:54:54 +0200
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 42D6B1D53C1; Sun, 20 Oct 2019 17:54:53 +0200 (CEST)
Received: from 193.153.132.124 by webmail.entel.upc.edu with HTTP; Sun, 20 Oct 2019 17:54:54 +0200
Message-ID: <4f4f9df4c114ee7d41309ccd93c53591.squirrel@webmail.entel.upc.edu>
In-Reply-To: <dba6a13a-dcdc-f133-b59f-76b1e21fa18b@wachter.cloud>
References: <7de413c1-726e-8595-fe21-0a6f3fe97dcd@wachter.cloud> <d76a963526245134d3f2d2d4f8941f5e.squirrel@webmail.entel.upc.edu> <70401c68-c343-b55a-5ca0-e0f58e3e43fa@wachter.cloud> <86202eb00717994a75a75877943be4b0.squirrel@webmail.entel.upc.edu> <dba6a13a-dcdc-f133-b59f-76b1e21fa18b@wachter.cloud>
Date: Sun, 20 Oct 2019 17:54:54 +0200
From: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
To: Alexander Wachter <alexander@wachter.cloud>
Cc: 6lo@ietf.org
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.100.3 at dash
X-Virus-Status: Clean
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Sun, 20 Oct 2019 17:54:54 +0200 (CEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/1jfZtN-2G0WU7a8bMxwkqaXL9BU>
Subject: Re: [6lo] Call for feedback to draft-wachter-6lo-can-00
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Oct 2019 15:55:00 -0000

Dear Alexander,

> Dear Carles,
>
>
> On 20.10.19 15:37, Carles Gomez Montenegro wrote:
>> Dear Alexander,
>>
>> Thanks for your responses.
>>
>> To some extent, I see similarities between the environment you are
>> considering (CAN) and MS/TP. Few years ago, the 6Lo WG produced RFC
>> 8163,
>> which specifies IPv6 over MS/TP.
>
> The main difference I see between CAN and MS/TP is the packet/frame
> size. MS/TP satisfies the minimal requirements of 1500 octets minimal
> MTU where CAN only has 8 octets of payload per frame. 6LoCAN therefore
> defines a fragmentation an reassembly.

Your draft proposes using a subset of ISO-TP for fragmentation and
reassembly.

Clarifying question: is ISO-TP part of the CAN protocol (stack)?

>> I understand that using header compression reduces the amount of IPv6
>> packets that will require fragmentation. Also, it provides a more
>> efficient use of the bus. Interesting!
>
> IPHC helps to reduce the number of frames needed to send an IPv6 packet.
> Nevertheless, sending an IPv6 packet in a single frame is only possible
> for CAN-FD (up to 64 bytes payload). Classical CAN always needs
> fragmentation and reassembly.

I see. Anyway, there is the need to comply with the 1280-byte IPv6 MTU
requirement, but it is already satisfied in your draft.

> In my opinion, 6LoCAN is the right WG because it defines a
> "6lo-adaption-layer". It specifies a fragmentation and reassembly as
> other 6lo technologies do.

I actually mentioned MS/TP and the (6Lo-produced) RFC 8163 to emphasize
the potential similarities with CAN (and 6LoCAN), since the 6Lo WG has
also dealt with technologies with somewhat different characteristics (e.g.
wireless, mesh topologies, energy-constrained devices, etc.).

Kind regards,

Carles


> Kind regards,
>
> Alexander