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

[Tom Herbert <[e-mail]>]

On Tue, Sep 20, 2016 at 10:35 AM, Joe Touch <[e-mail]> wrote:
>
>
> On 9/20/2016 10:29 AM, Tom Herbert wrote:
>> On Tue, Sep 20, 2016 at 10:07 AM, Joe Touch <[e-mail]> 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.

You can if you insert a two byte pad before the encapsulated Ethernet
header like ETHERIP (RFC3378 does).

Tom