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

Brian Haberman <brian@innovationslab.net> Thu, 13 August 2009 22:13 UTC

Return-Path: <brian@innovationslab.net>
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 D05C028C178; Thu, 13 Aug 2009 15:13:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 rDRBCNDPMzAK; Thu, 13 Aug 2009 15:13:22 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by core3.amsl.com (Postfix) with ESMTP id 0F8463A67B8; Thu, 13 Aug 2009 15:13:22 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 3B1AA8820F; Thu, 13 Aug 2009 13:54:55 -0700 (PDT)
Received: from Clemson-2.local (c-69-255-98-109.hsd1.md.comcast.net [69.255.98.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id CA0D5130002; Thu, 13 Aug 2009 13:54:52 -0700 (PDT)
Message-ID: <4A847D96.1070606@innovationslab.net>
Date: Thu, 13 Aug 2009 16:54:46 -0400
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: Sam Hartman <hartmans-ietf@mit.edu>
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>
In-Reply-To: <tslhbwbbo2q.fsf@mit.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 14 Aug 2009 09:00:10 -0700
Cc: "ipv6@ietf.org" <ipv6@ietf.org>, Noel Chiappa <jnc@mercury.lcs.mit.edu>, Margaret Wasserman <mrw@sandstorm.net>, "lisp@ietf.org" <lisp@ietf.org>
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: Thu, 13 Aug 2009 22:13:22 -0000

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).

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