Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15

Dino Farinacci <farinacci@gmail.com> Thu, 30 August 2018 16:09 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74993130EB1; Thu, 30 Aug 2018 09:09:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 9W64_xMXk0Fr; Thu, 30 Aug 2018 09:09:57 -0700 (PDT)
Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70CF9130DD0; Thu, 30 Aug 2018 09:09:57 -0700 (PDT)
Received: by mail-pg1-x543.google.com with SMTP id m4-v6so4084086pgv.12; Thu, 30 Aug 2018 09:09:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=POWn/VEkzu6d6r/JHGMnMIJJF5cHGczz8z/1nR/DByM=; b=FM2HA7VVyblqtbOoIKa310fqdBRIbhfgfyIDryuMo8KUgCNe5sAZApxfSYt48aZu6d hTR8H7pb4+5oYNfkjSjVbpDDrS8ydvNYo6wK215gY6w1tQgxM6gHB0y9mPx7L/Jv87RW AxFBzZZK/lpiQLKd+0nCdTHagHunuMq2QngQPpJpiAerxBv1N/Wotqr8P+e2dzz176SV qarBLqfICWDaC8nfrzG0GjPjPpKeTwbAUDS4xYVRvcUXktl+KAWE1RJNNCJOIj9emodZ ZF9EOYIAUyy/3BuMeuHzF44ieUlu4Vuv/IganyF9/NH8LV+DT96/A1moTfFevZKcXVKX 6OXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=POWn/VEkzu6d6r/JHGMnMIJJF5cHGczz8z/1nR/DByM=; b=jHB8GEMpEe3NCujK4iQguwy1DxqSdw3NNXeIbQV8obUVjkfDlRoMJi/ORLaCtYGnKC 0OaqC7G7CV/LRLle4oNEpmpoM7kKsXXMZ1D7o+mVQUdvNDDl+ygbXEvaxXXiM5/p0WDO af7qKOFqFwOCFiFd0SNvKDDSLzUbiaU7DwyVr+kGJ1Ll4bXVjbtaH+VLoBzOstG6WhdH CihjQULkdR+gy2Mt3f7W2mFUSvMPzj3yzmsVSyvGRLm11875A5BzyZvFcCeoT/bU2Lou jQeHr+XKkiPNH3c6Ao1Njbxi47lujdr/BxODFYg8UExE5fFU68HGxQuHeBciwY7Lbfqb /tqA==
X-Gm-Message-State: APzg51CBMHdOQ/lNeuShBk0kOPtSEZdlLXuSu/IcArrF+GAyVo6abgRS Ghzai94QsUqJFTCnCOeeWVo=
X-Google-Smtp-Source: ANB0VdZpQ8SGK9k1wku2lGx0yUjK9ynBQpa5H4oF1DYb4zWP0vPdWl7a5UM2PH5TdvjmONZUnrebpw==
X-Received: by 2002:a63:f244:: with SMTP id d4-v6mr10200969pgk.2.1535645396963; Thu, 30 Aug 2018 09:09:56 -0700 (PDT)
Received: from [10.31.79.28] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id v6-v6sm18064511pfa.28.2018.08.30.09.09.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Aug 2018 09:09:56 -0700 (PDT)
From: Dino Farinacci <farinacci@gmail.com>
X-Google-Original-From: Dino Farinacci <farinacci@GMAIL.COM>
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
In-Reply-To: <FD414B30-ED12-4BEC-94FB-737FB1AAECA1@trammell.ch>
Date: Thu, 30 Aug 2018 09:09:54 -0700
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, tsv-art@ietf.org, IETF Discussion Mailing List <ietf@ietf.org>, "lisp@ietf.org list" <lisp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <60047CB6-2F13-4BE7-BCF0-4108479B569C@GMAIL.COM>
References: <153538054829.30074.15428909912816972228@ietfa.amsl.com> <ED34F830-1FEF-42BB-BB6E-805D724AB339@gmail.com> <79FA52C8-94AC-43CE-B052-9F921A65E0D5@trammell.ch> <23680BD5-0DD3-4404-888D-D1C78A0A437D@gmail.com> <130902C2-9CEE-4931-8957-D32446723B89@trammell.ch> <CF5E3C7B-E492-4EE9-A2E6-A2D823C6610F@gmail.com> <1514B576-87FD-475F-B6C5-BBA1C2CA94ED@trammell.ch> <CE7ECD23-E8A2-4D48-B752-0D246C02F27E@gmail.com> <FBA13CF2-8E44-46DA-AB5D-9082B5288F05@trammell.ch> <5E2CBC85-87FF-48DC-950B-403E6E8E14BF@gmail.com> <C4425CD6-B44D-479A-819A-BEFCC83E9E33@gmail.com> <B466126A-DBE8-4088-AC93-F7D49C534ABE@trammell.ch> <E76EB141-5D80-4131-AB42-4DB326348B00@gmail.com> <FD414B30-ED12-4BEC-94FB-737FB1AAECA1@trammell.ch>
To: "Brian Trammell (IETF)" <ietf@trammell.ch>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/_NMMJZ_yZucRaslaMjyyu1BLY0Y>
Subject: Re: [lisp] [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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, 30 Aug 2018 16:10:00 -0000

Thanks for the great discussion Brian. I think we’re all in sync now?

Dino

> On Aug 30, 2018, at 8:46 AM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
> 
> 
> 
>> On 30 Aug 2018, at 16:55, Dino Farinacci <farinacci@gmail.com> wrote:
>> 
>>> On Aug 30, 2018, at 2:57 AM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
>>> 
>>> hi Dino,
>>> 
>>> Almost. How about:
>>> 
>>> 
>>> OLD:
>>> 
>>> When the UDP and LISP headers require integrity protection, the
>>> methods of using UDP checksums in [RFC8085] can be considered.
>>> 
>>> NEW:
>>> 
>>> Implementors are encouraged to consider UDP checksum usage guidelines in section 3.4 of [RFC8085]. Specifically, when the UDP, LISP, and outer IPv6 headers require protection against corruption, the use of non-zero UDP checksums is RECOMMENDED.
>> 
>> Well if we recommend it and when describing the UDP header in the packet format section we don’t that woudl be a contracdiction.
> 
> I think my point here is that the packet format section probably shouldn't do that. :) Yes, I understand the disconnect between the reality of the situation and the
> 
>> And note the IPv6 outer header cannot be protected with a UDP checksum. The link-layer CRC will do that.
> 
> Eh, this makes assumptions about the underlying link layer's corruption characteristics that may not hold. But yeah, for most packets in most realistic situations this is the case, and I guess we've learned to live with the underlying phy error rate * 1e-10 in any case.
> 
>> NEWNEW:
>> 
>> Implementors are encouraged to consider UDP checksum usage guidelines in section 3.4 of [RFC8085] when
>> it is desirable to protect UDP and LISP headers against corruption.
>> 
>> What do you think?
> 
> This seems like a fine compromise to me.
> 
> Thanks, cheers,
> 
> Brian
> 
>> 
>> Dino
>> 
>> _______________________________________________
>> Tsv-art mailing list
>> Tsv-art@ietf.org
>> https://www.ietf.org/mailman/listinfo/tsv-art
>