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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A77C612B0D8; Tue, 20 Sep 2016 10:36:49 -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 kTmOWzQ5fKIJ; Tue, 20 Sep 2016 10:36:47 -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 CCDAD12B03F; Tue, 20 Sep 2016 10:36:47 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id u8KHZgWX022658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 20 Sep 2016 10:35:42 -0700 (PDT)
To: Tom Herbert <>
References: <> <> <>
From: Joe Touch <>
Message-ID: <>
Date: Tue, 20 Sep 2016 10:35:41 -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: u8KHZgWX022658
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:36:50 -0000

On 9/20/2016 10:29 AM, Tom Herbert wrote:
> On Tue, Sep 20, 2016 at 10:07 AM, Joe Touch <> wrote:
>> Hi, Tom,
>> On 9/20/2016 9:13 AM, Tom Herbert wrote:
>>> ...
>>> For new encapsulation protocols please consider the effects of IP
>>> header alignment in the presence of Ethernet encapsulation. Defining
>>> Ethernet encapsulation with the two byte padding like in ETHERIP may
>>> help a lot to make implementation of Ethernet encapsulation feasible
>>> on CPU HW.
>> IMO, alignment needs to be handled within each encapsulation layer
>> independently. I don't think it's useful to expect new encapsulation
>> layers to have to make sure every layer of an encapsulated packet is
>> aligned - just the first one ought to be sufficient. The rest is the
>> responsibility of whomever added the other layers already in place.
>> So yes, it's useful to make sure the encapsulated packet starts on a
>> boundary that is 4-byte aligned, but the rest *needs to be* someone
>> else's problem.
> It's the Ethernet payload that we need to be four byte aligned not the
> Ethernet header. Just aligning Ethernet header to four bytes is not
> useful; that means the Ethernet payload, e.g. an IP packet, won't have
> four byte alignment and hence the misery of trying to process the
> packet. For the cost of two bytes ETHERIP gets things right in this
> regard!
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. Aligning the IP header de-aligns the
Ethernet one. Again, if you're encapsulating ethernet, then that is what
you should align to.