Re: [lisp] Judging Consensus on the UDP Checksum Issue

Marshall Eubanks <tme@americafree.tv> Fri, 14 August 2009 01:20 UTC

Return-Path: <tme@americafree.tv>
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75CDA3A6A6C; Thu, 13 Aug 2009 18:20:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.582
X-Spam-Level:
X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxoYfYGyLqQR; Thu, 13 Aug 2009 18:20:24 -0700 (PDT)
Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 7067A3A683A; Thu, 13 Aug 2009 18:20:24 -0700 (PDT)
Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 49C5E47A0F11; Thu, 13 Aug 2009 21:20:27 -0400 (EDT)
Message-Id: <D6C226C3-8BF9-4C68-BBCB-9F9BB5430061@americafree.tv>
From: Marshall Eubanks <tme@americafree.tv>
To: Brian Haberman <brian@innovationslab.net>
In-Reply-To: <4A847D96.1070606@innovationslab.net>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 13 Aug 2009 21:20:25 -0400
References: <20090811161852.7157A6BE591@mercury.lcs.mit.edu> <928251FD-05DA-4588-96C1-2135A33AF96C@sandstorm.net> <32AADADD-6A45-4565-91D5-F095AE713215@cisco.com> <CEFD62DC-4877-49C3-9294-87DEFAE326E0@nokia.com> <86D687BA-A9C9-4539-89FF-1FBD5E834C6A@cisco.com> <E5FEC413-6EA4-4A2D-A6A5-C97384D65AE8@nokia.com> <tslhbwbbo2q.fsf@mit.edu> <4A847D96.1070606@innovationslab.net>
X-Mailer: Apple Mail (2.936)
Cc: "ipv6@ietf.org" <ipv6@ietf.org>, "lisp@ietf.org" <lisp@ietf.org>, Margaret Wasserman <mrw@sandstorm.net>, Noel Chiappa <jnc@mercury.lcs.mit.edu>
Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Aug 2009 01:20:25 -0000

On Aug 13, 2009, at 4:54 PM, Brian Haberman wrote:

> Sam Hartman wrote:
>>>>>>> "Lars" == Lars Eggert <lars.eggert@nokia.com> writes:
>>    Lars> Hi, yes, because RFC2460 says "MUST use always" and the
>>    Lars> intent here is to loosen that restriction for LISP and AMT.
>>    Lars> (And I'm sure Noel will again call this "red-tape legalese",
>>    Lars> but the fact is that this change revises the standing IETF
>>    Lars> consensus, and there's a process for that.)
>> Something that apparently isn't obvious to some WG participants who
>> have contacted me off-list is that it is quite possible to change an
>> IETF consensus.  When Margaret, Lars and I talk about doing things
>> like updating RFC 2460, we're not talking about what we think should
>> be a obstruction once we've done the work to decide what the right
>> technical direction is.
>> We've all been on the IESG and are used to these sorts of updates  
>> as a
>> routine matter of IETF business.
>> In the simplest case, you're talking about writing a potentially  
>> short
>> draft that updates the spec in question.  You then find the
>> appropriate AD or working group to sponsor the draft and go through
>> the normal process.
>> Yes, you do actually have to build consensus.  For some updates,
>> that's easy, for others it is very difficult.  That's how we all
>> convince each other that we actually have thought things through and
>> come to the right decision.
>
> Finally a point that is appropriate to the 6man mailing list...  
> There are two proposals on the table to do just that (modify the  
> handling of UDP as defined in 2460).  The discussion should be on  
> the tradeoffs of those two proposals.
>
> http://tools.ietf.org/html/draft-eubanks-chimento-6man-00 proposes  
> allowing UDP to have a zero checksum in certain conditions (i.e.,  
> outer checksum is zero as long as there is an encapsulated UDP  
> checksum that is valid).
>

We envision draft-eubanks-chimento-6man-00, should it
go through, as explicitly updating RFC2460 and the next version will  
reflect this.

Regards
Marshall

> http://tools.ietf.org/html/draft-fairhurst-6man-tsvwg-udptt-01  
> proposes a "checksum per flow" approach that is applicable for UDP  
> tunneled inside of UDP.
>
> The chairs of 6MAN would like to here feedback on these drafts as  
> they apply to the problem spaces raised (AMT, v4/v6 translators, and  
> LISP).
>
> Regards,
> Brian
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>