Re: [Rtg-dt-encap-considerations] draft-rtg-dt-encap-02 for review

Tom Herbert <> Wed, 20 May 2015 22:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B0D311AC3A7 for <>; Wed, 20 May 2015 15:28:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KKi14JZkXlkN for <>; Wed, 20 May 2015 15:28:08 -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 759771ABD3A for <>; Wed, 20 May 2015 15:28:08 -0700 (PDT)
Received: by iepj10 with SMTP id j10so50403697iep.3 for <>; Wed, 20 May 2015 15:28:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZyKWLd9PSvLSlgRZntVjA+cKgcvXLNpZIDFpr/MHc34=; b=TVWXfJ1w+y/x2lscU9wdoRVk9KQft+1mhsL1huyBVZj1O411kUGcWqZKMIFFhofYER MmWV7S1IpfpQfh4Y2y4nkEFctvfQsCRy8VjjcWvPk/hWhkw67DzM8O5KDN5Ybe/CGtYh 9/6xgQZ38EjIKxQC9pSEAZC/7lBe7Ef2opa2ilhY840g///w8SZdBxowK7ukGHoJIcrO /dwB6wGFIsk70+hjclPcgSrj9CCqncEm7kp1ONsLMl3ZYfBE+Uz5u09EBhKXSIy58AlG NnsyP7ZaRH+6rH2tgX8oDc+ARX0+ucpms0eEruN4dRsBlWMvBPBpxKasTdy9tD77nomF BC8A==
X-Gm-Message-State: ALoCoQnbQ5t9qv74j5eTEYmDd6+lC4WYozQAbAnlAc+CEiF7H3ypCXK6nJQZFafZwjoZYr6fChln
MIME-Version: 1.0
X-Received: by with SMTP id fg4mr130610icb.52.1432160887961; Wed, 20 May 2015 15:28:07 -0700 (PDT)
Received: by with HTTP; Wed, 20 May 2015 15:28:07 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Wed, 20 May 2015 15:28:07 -0700
Message-ID: <>
From: Tom Herbert <>
To: Erik Nordmark <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>
Subject: Re: [Rtg-dt-encap-considerations] draft-rtg-dt-encap-02 for review
X-Mailman-Version: 2.1.15
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: Wed, 20 May 2015 22:28:09 -0000

>> Would change "Avoid full packet checksums in encapsulation if
>> possible" to "Avoid full packet checksums in cases where necessary
>> devices cannot support them"
> I don't know what others think, but that seems to be confusing. It seems to
> imply that some devices are sub-standard and can be fixed, when in fact it
> is impossible to do a full packet checksum, where the checksum is placed in
> the header, in a low-latency cut-through device.
Note this only applies to devices terminating encapsulation, not to
other middleboxes or switches in the underlay path. Also, w.r.t. UDP
encapsulation we already have several protocols that provide the
answer: UDP checksums on TX are optional for IPv4 and optional for
IPv6 only under the requirements of RFC6935 and RFC6936. This allows
for hardware that does not support UDP checksum to be deployed, but
hopefully with awareness by an administrator as to the tradeoffs of
disabling checksums. There are no provisions to ignore checksums on
receive, so if a device does not support UDP checksums sees a non-zero
checksum it should drop the packet (IMO VXLAN allowing RX checksums to
be ignored is not correct).