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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F05F12B3E5; Tue, 20 Sep 2016 10:08:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.216
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vu-ZLNWAD06C; Tue, 20 Sep 2016 10:08:00 -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 CD38C12B100; Tue, 20 Sep 2016 10:07:51 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id u8KH7SJa016563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 20 Sep 2016 10:07:31 -0700 (PDT)
To: Tom Herbert <>, "" <>, "" <>, Sowmini Varadhan <>
References: <>
From: Joe Touch <>
Message-ID: <>
Date: Tue, 20 Sep 2016 10:07:27 -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=windows-1252
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Archived-At: <>
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:08:03 -0000

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.