IETF Logo Mail Archive

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

"Larry Kreeger (kreeger)" <kreeger@cisco.com> Wed, 20 May 2015 22:34 UTC

Return-Path: <kreeger@cisco.com>
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 F3C7E1AC3A0 for <rtg-dt-encap-considerations@ietfa.amsl.com>; Wed, 20 May 2015 15:34:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 DKN6wQ-yCoB0 for <rtg-dt-encap-considerations@ietfa.amsl.com>; Wed, 20 May 2015 15:34:58 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 230CE1ABD3B for <Rtg-dt-encap-considerations@ietf.org>; Wed, 20 May 2015 15:34:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2012; q=dns/txt; s=iport; t=1432161298; x=1433370898; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RKAIesyWmUV6S8uYMUgT7Eg/vUE+k1MKuF+kI2NzmI0=; b=ULhFr6bTY7y1cSB/jcGiixKuTizsochoVi5j3DIt74+tjRkvoGIvo0RX hIEGXI5vRw2urp5Niao7J1HsRq0sDTPL6IC5g+HJGzY0t3FeQG7fsOc4P uE8xtHcj9et9x7aGHX59oYr1z3HL2zRf/12NAqjhEe9mFa/Lv8/Ir/294 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D9AwDJC11V/5NdJa1cgxBUXgbDWAmBUAqFdwKBOjgUAQEBAQEBAYEKhCMBAQMBAQEBNzQLEAIBCDYQJwslAgQBDQWIJAgNzxsBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIs6hQUHhC0FknCLAJcUI4IFgXNvgUaBAQEBAQ
X-IronPort-AV: E=Sophos;i="5.13,466,1427760000"; d="scan'208";a="579033"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-2.cisco.com with ESMTP; 20 May 2015 22:34:57 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t4KMYvf7010638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 May 2015 22:34:57 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.6]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Wed, 20 May 2015 17:34:57 -0500
From: "Larry Kreeger (kreeger)" <kreeger@cisco.com>
To: Tom Herbert <tom@herbertland.com>, Erik Nordmark <nordmark@sonic.net>
Thread-Topic: [Rtg-dt-encap-considerations] draft-rtg-dt-encap-02 for review
Thread-Index: AQHQjm/4os07u12chEOyOvSlkY94M52EMU2AgAE2IYCAAGgAgP//jJ0A
Date: Wed, 20 May 2015 22:34:56 +0000
Message-ID: <D182595A.148D28%kreeger@cisco.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>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.9.150325
x-originating-ip: [10.155.166.41]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <D04EA95D3D98584E94EB1B406CE08EC3@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-dt-encap-considerations/_TcGH6STGPkxIDANPCvJgUZT0a0>
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: Wed, 20 May 2015 22:35:00 -0000

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.

 - Larry

On 5/20/15 3:28 PM, "Tom Herbert" <tom@herbertland.com> 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. 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
>Rtg-dt-encap-considerations@ietf.org
>https://www.ietf.org/mailman/listinfo/rtg-dt-encap-considerations

v2.23.0 | Report a Bug | By Email