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

Joe Touch <> Tue, 20 September 2016 17:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 69FAA12B14C; Tue, 20 Sep 2016 10:56:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.216
X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4flME2NPr3BJ; Tue, 20 Sep 2016 10:56:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 350A012B138; Tue, 20 Sep 2016 10:56:18 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id u8KHu118026408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 20 Sep 2016 10:56:02 -0700 (PDT)
To: Tom Herbert <>
References: <> <> <> <> <>
From: Joe Touch <>
Message-ID: <>
Date: Tue, 20 Sep 2016 10:55:59 -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: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: u8KHu118026408
X-ISI-4-69-MailScanner: Found to be clean
Archived-At: <>
Cc: Sowmini Varadhan <>, "" <>, "" <>
Subject: Re: [Rtg-dt-encap-considerations] [nvo3] Alignment and Ethernet encapsulation
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Routing Area Design Team on Encapsulation Considerations discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Sep 2016 17:56:19 -0000

On 9/20/2016 10:47 AM, Tom Herbert wrote:
> On Tue, Sep 20, 2016 at 10:35 AM, Joe Touch <> 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.

Frankly, anything that already parses Ethernet then IP ought to be able
to efficiently handle the difference in the two alignments - and you
might be messing THAT up.

RFC3378 defines a header used for ETHERIP; that header may or may not be
relevant to other ethernet-in-X encapsulations. The field needed to be
there for versioning and was expanded from 8 to 16 bits, which certainly
helps align the *ethernet* header that comes after it compared to the
earlier use of an 8-bit field. There's no mention of aligning for the
purposes of accessing the IP header, which again, I disagree with.