Re: [Rtg-dt-encap-considerations] [nvo3] Alignment and Ethernet encapsulation

Joe Touch <touch@isi.edu> Tue, 20 September 2016 19:05 UTC

Return-Path: <touch@isi.edu>
X-Original-To: rtg-dt-encap-considerations@ietfa.amsl.com
Delivered-To: rtg-dt-encap-considerations@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE9812B475; Tue, 20 Sep 2016 12:05:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.216
X-Spam-Level:
X-Spam-Status: No, score=-9.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.316] 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 yh-s0pE4Dtbu; Tue, 20 Sep 2016 12:05:21 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 115A512B130; Tue, 20 Sep 2016 12:05:21 -0700 (PDT)
Received: from [128.9.184.133] ([128.9.184.133]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u8KJ4pEh024232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 20 Sep 2016 12:04:52 -0700 (PDT)
To: Tom Herbert <tom@herbertland.com>
References: <CALx6S375-k7hEbC5YMsehWuCTczd=NzwCF8PdYew=vT_Ep+2-g@mail.gmail.com> <fcdcc884-2bf3-381d-8084-8bb845fb5ba8@isi.edu> <CALx6S36_YhTv7ddm9Op48OaQmz1MQ_2d31bjV7Cki1acNumBDw@mail.gmail.com> <f16a836c-ed34-9a6e-c184-8593e4217fe2@isi.edu> <CALx6S35ZAVhQZR4Z2XW-pCUG9FOTY5LAhM4t3oKEU8hNH-3rWA@mail.gmail.com> <2e947b85-84ce-e1bd-d134-6441d9a38067@isi.edu> <CALx6S35_4wUo-cq5Tm50+a3rOeQc-FkvU6_CLK=0aJ==Zdw-mA@mail.gmail.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <15ba5d4e-da2a-75ec-8889-b011a29cc2e7@isi.edu>
Date: Tue, 20 Sep 2016 12:04:50 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CALx6S35_4wUo-cq5Tm50+a3rOeQc-FkvU6_CLK=0aJ==Zdw-mA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dt-encap-considerations/-P5J2T3eyuKejKhFAeuGvFnGOaQ>
Cc: Sowmini Varadhan <sowmini.varadhan@oracle.com>, "nvo3@ietf.org" <nvo3@ietf.org>, "rtg-dt-encap-considerations@ietf.org" <rtg-dt-encap-considerations@ietf.org>
Subject: Re: [Rtg-dt-encap-considerations] [nvo3] Alignment and Ethernet encapsulation
X-BeenThere: rtg-dt-encap-considerations@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Routing Area Design Team on Encapsulation Considerations discussion list <rtg-dt-encap-considerations.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dt-encap-considerations>, <mailto:rtg-dt-encap-considerations-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dt-encap-considerations/>
List-Post: <mailto:rtg-dt-encap-considerations@ietf.org>
List-Help: <mailto:rtg-dt-encap-considerations-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dt-encap-considerations>, <mailto:rtg-dt-encap-considerations-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Sep 2016 19:05:22 -0000


On 9/20/2016 11:38 AM, Tom Herbert wrote:
> On Tue, Sep 20, 2016 at 10:55 AM, Joe Touch <touch@isi.edu> wrote:
>>
>> On 9/20/2016 10:47 AM, Tom Herbert wrote:
>>> On Tue, Sep 20, 2016 at 10:35 AM, Joe Touch <touch@isi.edu> wrote:
>>>> ...
>>>> If you've been handed Ethernet to encapsulate, then that is the header
>>>> whose alignment you should be optimizing.
>>>>
>>>> As you point out, you can't align both IP and Ethernet to 4-byte
>>>> boundaries at the same time.
>>> You can if you insert a two byte pad before the encapsulated Ethernet
>>> header like ETHERIP (RFC3378 does).
>> You CAN do a lot of things, but you shouldn't.
>>
>> If you're handed ethernet to encapsulate, then THAT is the header whose
>> access should be aligned.
>>
>> You have no business ASSUMING that you need to optimize for IP header
>> access. All you're doing is messing up the ethernet access.
>>
> Sorry, but I disagree with that statement. Keeping IP headers aligned
> for stack processing is a HUGE concern in real implementation.
It is, and something that handles Ethernet messages should already know
what to do here.

So if it already expects to shift the packet over as it copies it in,
then you've just defeated that. The same is true for non-IP inside
Ethernet, which might have its own padding to re-align its contents.

I.e., if it's ethernet, treat it as ethernet. That's what an L2 tunnel
should do.

Joe