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

Tom Herbert <> Wed, 20 May 2015 23:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D78A01AC3F2 for <>; Wed, 20 May 2015 16:14:48 -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 xqW8VbHZRnQf for <>; Wed, 20 May 2015 16:14: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 05DFC1AC3EE for <>; Wed, 20 May 2015 16:14:46 -0700 (PDT)
Received: by igcau1 with SMTP id au1so52026911igc.1 for <>; Wed, 20 May 2015 16:14:46 -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=xqy5s3xEBQjeFQ5H6Bq4ICOxDdWX8c+55skJE85GIXI=; b=glNbQuj+AGEGJO4d+cJJXDy4frHJ0+w3GGKwXlm6DcJrHnBK1bF2yKFvnB3iO3jjem en2oiwmATM6TmeNQvUXNm3c1tj07WuNlRdLKy2OcFRm1Ct0U5TaWMgls1TnL7x0X7qG7 nPVey7LB6Zv8KTk+dAHLWxheItBBwLJQUNr4Cy9SOi92fwur5xOtODvCvCVq/KOGV0ab ziaJ5Jc+0vFLPhMWsLnPZ87U48qQbt0ZVlnB9CAm7hkXs07EEFsh24z6IvB5hNZb8Z4R 3S0Sh/9URV+122IsK+lWdyv5/PzEjLKttWyFodvgS6qf6xdaMiy5LcyF3PGAgjY9FqZV 8gaA==
X-Gm-Message-State: ALoCoQkQ8Cxbv8sQY8tJzKfLjahIckMAuThHk0pV6HaCr+MIiQudwwowq7hJHXFnccpdqAcS4Fty
MIME-Version: 1.0
X-Received: by with SMTP id ru3mr20504167igb.16.1432163686393; Wed, 20 May 2015 16:14:46 -0700 (PDT)
Received: by with HTTP; Wed, 20 May 2015 16:14:46 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Wed, 20 May 2015 16:14:46 -0700
Message-ID: <>
From: Tom Herbert <>
To: "Larry Kreeger (kreeger)" <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>, Erik Nordmark <>
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 23:14:49 -0000

On Wed, May 20, 2015 at 3:34 PM, Larry Kreeger (kreeger)
<> wrote:
> Hi Tom,
> Why do you see it as a problem for a device that can't support UDP
> checksum checking to ignore the non-zero checksum rather than requiring
> the sender to explicitly set the checksum to zero.  The biggest problem I
> see with requiring dropping of non-zero checksum is when multicast is
> being used in the underlay because packets may be delivered to tunnel
> endpoints where some can check the checksum and some cannot.  It also
> means that every encapsulator must know the capability of the receiver.
Hi Larry,

Here are some points:

1) The requirements around UDP checksum are more than twenty years
old. The fact that UDP non-zero UDP checksums are validated is an
invariant in deployed networks. There is no easy way to distinguish
VXLAN from other UDP traffic in order to carve out exceptions.
2) We still see checksum errors in large networks so it is not true
that they have been obsoleted by Ethernet CRC.
3) If a transmitter sets a non-zero UDP checksum it does so with the
full expectation that the receiver will check it. So if the receiver
ignores the checksum:
  a) it misses errors that are hopefully caught somewhere else.
  b) may make debugging network issues more difficult since we lost
one level of verification.
  c) the transmitter wasted resources/power in computing the checksum.
  d) disregards the fact that the transmitter might have knowledge
that the path could be lossy and hence checksums are warranted.
4) In my network, I would much prefer that devices drop packets that
they can't verify, rather than allow packets through that are
potentially suspect. For instance, it is much easier to debug when a
device is consistently dropping packets because of misconfiguration
(i.e. sending non-zero checksums to a device that can't handle them)
rather than trying to tracked down some intermittent corruption of end
user data.


>  - Larry
> On 5/20/15 3:28 PM, "Tom Herbert" <> wrote:
>>>> 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
>>> 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).
>>Rtg-dt-encap-considerations mailing list