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

Erik Nordmark <nordmark@sonic.net> Thu, 21 May 2015 15:54 UTC

Return-Path: <nordmark@sonic.net>
X-Original-To: rtg-dt-encap-considerations@ietfa.amsl.com
Delivered-To: rtg-dt-encap-considerations@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94D31B29D9 for <rtg-dt-encap-considerations@ietfa.amsl.com>; Thu, 21 May 2015 08:54:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.711
X-Spam-Level:
X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fsNSvOwQ2Ed for <rtg-dt-encap-considerations@ietfa.amsl.com>; Thu, 21 May 2015 08:54:23 -0700 (PDT)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB80E1A87B3 for <Rtg-dt-encap-considerations@ietf.org>; Thu, 21 May 2015 08:54:23 -0700 (PDT)
Received: from [172.22.227.238] ([162.210.130.3]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t4LFsLLv008657 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 May 2015 08:54:21 -0700
Message-ID: <555DFFAD.6000401@sonic.net>
Date: Thu, 21 May 2015 08:54:21 -0700
From: Erik Nordmark <nordmark@sonic.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Tom Herbert <tom@herbertland.com>
References: <5554E2C1.3000306@sonic.net> <CALx6S34kcZd9xg=eQ=Dq85uB4RBHFad9-_UWrJ5yuGvG=9zjQw@mail.gmail.com> <555CB339.4080407@sonic.net> <CALx6S372LZNO-TnuS-NZxkaDWRf5qD6-ms84_ZdR33DEL1ZZgQ@mail.gmail.com>
In-Reply-To: <CALx6S372LZNO-TnuS-NZxkaDWRf5qD6-ms84_ZdR33DEL1ZZgQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Sonic-CAuth: UmFuZG9tSVYTrmDvBd0HVQWM8pYWkE7g4TIb6l8VpERBLnNEZdoGfBOIuNwpiqyRqFRLlS5vXaCeK1rN5TCX1EKn2jNoM+1U
X-Sonic-ID: C;allXpdH/5BG2B/jYVPtzAg== M;VLtqpdH/5BG2B/jYVPtzAg==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-dt-encap-considerations/ARRIWHeIJya9ajkZnhso8h9V2lQ>
Cc: "rtg-dt-encap-considerations@ietf.org" <Rtg-dt-encap-considerations@ietf.org>
Subject: Re: [Rtg-dt-encap-considerations] draft-rtg-dt-encap-02 for review
X-BeenThere: rtg-dt-encap-considerations@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Design Team on Encapsulation Considerations discussion list <rtg-dt-encap-considerations.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dt-encap-considerations>, <mailto:rtg-dt-encap-considerations-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-dt-encap-considerations/>
List-Post: <mailto:rtg-dt-encap-considerations@ietf.org>
List-Help: <mailto:rtg-dt-encap-considerations-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dt-encap-considerations>, <mailto:rtg-dt-encap-considerations-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 May 2015 15:54:25 -0000

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 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.
Yes, those are the devices I'm concerned about.
> 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).
>
I think it would be unfortunate if the IETF standardized an 
encapsulation protocol which requires UDP checksums of the complete 
packet over IPv6 but not over IPv4. That would at best slow down the 
transition to IPv6 as a viable underlay.

We have bad experience with no UDP checksum for actual UDP payload (I 
recall UDP over NFS at Sun and bit errors).
Hence requiring UDP checksums makes a lot of sense.
However, when the payload is protected by a checksum and is 
encapsulated, then the only issue is some misdelivery or mishandling 
(wrong QoS) due to undetected corruption in the UDP header.

So to me it doesn't make sense to require an outer checksum which covers 
the encaps plus whole payload when there is another checksum for the 
payload.

    Erik