IETF Logo Mail Archive

Re: Padding and draft-pfister-6man-sadr-ra - Call for opinions on TLV format and type D host definition

Pierre Pfister <pierre.pfister@darou.fr> Wed, 06 May 2015 11:17 UTC

Return-Path: <SRS0=HUEw=FR=darou.fr=pierre.pfister@bounces.m4x.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB471B2AC4 for <ipv6@ietfa.amsl.com>; Wed, 6 May 2015 04:17:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.902
X-Spam-Level:
X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, 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 iDHo0yBKkQEQ for <ipv6@ietfa.amsl.com>; Wed, 6 May 2015 04:17:33 -0700 (PDT)
Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5425E1B2AC3 for <ipv6@ietf.org>; Wed, 6 May 2015 04:17:33 -0700 (PDT)
Received: from [10.148.10.49] (unknown [173.38.220.43]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 2B4BD1409B021; Wed, 6 May 2015 13:17:31 +0200 (CEST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: Padding and draft-pfister-6man-sadr-ra - Call for opinions on TLV format and type D host definition
From: Pierre Pfister <pierre.pfister@darou.fr>
In-Reply-To: <3B2ED11B-3885-400D-9B5A-7C5B851B65D1@danrl.de>
Date: Wed, 06 May 2015 13:17:30 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A821610E-D9B2-45DB-91CE-0FB85F226AB6@darou.fr>
References: <FC3DDE3B-0F66-4F8D-98FD-7E957C6A75D9@darou.fr> <55479FA1.9090101@gmail.com> <CAJE_bqceUWRwQqbtKe4kNM-gJ_0XQBKHFZ6a7f7jDCam1pLjFw@mail.gmail.com> <5549C78B.8050404@gmail.com> <9EB56366-8BD9-49E0-BE67-B4E876928918@danrl.de> <7B44DA9E-65B6-437F-BA21-CFED54512103@darou.fr> <3B2ED11B-3885-400D-9B5A-7C5B851B65D1@danrl.de>
To: Dan Lüdtke <mail@danrl.de>
X-Mailer: Apple Mail (2.1878.6)
X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Wed May 6 13:17:31 2015 +0200 (CEST))
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/j_JHpz3KMhUybxv-MhtcErs-f9w>
Cc: Alexandru Petrescu <alexandru.petrescu@gmail.com>, IPv6 IPv6 List <ipv6@ietf.org>, 神明達哉 <jinmei@wide.ad.jp>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 May 2015 11:17:34 -0000

Dan,

> 
> Having either 64 or 128 long prefixes would be a compromise. Everything else seems to complex for too little gain from my point of view. But let me think about that a bit.
> 
>> On 6 May 2015, at 11:33, Pierre Pfister <pierre.pfister@darou.fr> wrote:
>> 
>> On the other side, not aligning may require a memcpy. Which is not going to kill your cpu neither.
> 
> I care more about the bus than the CPU here. But lets discuss that on a different level. What are good reasons for compression in the first place? On links were compression matters, isn’t there already compression below the network layer?

I’d say the main motivation is to be conservative in terms of packet size use.
We are adding things to RAs at a quite regular pace. And at some point we will reach the MTU, which is a hard boundary for RAs.
We could rely on jumbo packets, or expect the MTU is going to increase in the coming decade, or that we will simply not reach it anytime soon, but I think we should try to be careful when adding options to RAs. Try not to consume too much packet space.

- Pierre

v2.23.0 | Report a Bug | By Email