Re: [lisp] Magnus Westerlund's No Objection on draft-ietf-lisp-gpe-17: (with COMMENT)

"Joel M. Halpern" <jmh@joelhalpern.com> Thu, 09 July 2020 17:57 UTC

Return-Path: <jmh@joelhalpern.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 C4C953A0D9B; Thu, 9 Jul 2020 10:57:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 gniIcgNC5cfO; Thu, 9 Jul 2020 10:57:15 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 2B0EA3A0D96; Thu, 9 Jul 2020 10:57:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4B2kQf6MCVz6G8q4; Thu, 9 Jul 2020 10:57:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1594317434; bh=OvAepFnkZGydcyDwDt/uZaR9LOhHI0K36LENahS8LBA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=gJG+3ysY0cUcejKS6IcweC2ellAsZJdXfrWYa5XS1KdHCTYcLepA3wpxg5kLmWqIu jRggZLfKVQuQDKqkT4eh9GPbOKoFgvnoL4gEEQptzBujYwqDk3G7/UlbHm/wJwt7h3 qrce3FowaLGbZxCf98fjYcaMZhsw6BuU5OoPCzRk=
X-Quarantine-ID: <lfe9jeVGEeaS>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4B2kQd5lg7z6G9GH; Thu, 9 Jul 2020 10:57:13 -0700 (PDT)
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, "fmaino@cisco.com" <fmaino@cisco.com>, "iesg@ietf.org" <iesg@ietf.org>
Cc: "draft-ietf-lisp-gpe@ietf.org" <draft-ietf-lisp-gpe@ietf.org>, "lisp@ietf.org" <lisp@ietf.org>, "lisp-chairs@ietf.org" <lisp-chairs@ietf.org>, "ggx@gigix.net" <ggx@gigix.net>
References: <159429861569.12326.4735174452265776723@ietfa.amsl.com> <1464C8A8-747A-45CB-8F62-9E96373C0D67@cisco.com> <54ee2cbb0c528b6c5aa36f88a8cf78d2d7d0ff09.camel@ericsson.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <f6a3ce17-1033-01c3-2995-089845df1524@joelhalpern.com>
Date: Thu, 9 Jul 2020 13:57:12 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <54ee2cbb0c528b6c5aa36f88a8cf78d2d7d0ff09.camel@ericsson.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/thOg4hTeJgB9k-s5NvIfQLWvX64>
Subject: Re: [lisp] Magnus Westerlund's No Objection on draft-ietf-lisp-gpe-17: (with COMMENT)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
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, 09 Jul 2020 17:57:18 -0000

Magnus, while it is possible we will still get hold ups on the LISP 
documents, I would really prefer to avoid creating a normative 
dependency on something that at best is 6 months away.  Particularly 
since the TSVWG has not cared enough to maintain the document.

Yours,
Joel

On 7/9/2020 1:50 PM, Magnus Westerlund wrote:
> Hi,
> 
> No, RFC 3819 is not a good replacement for the draft. I would note that only a
> minor part of RFC 3819 is updated by draft-ietf-tsvwg-ecn-encap-guidelines.
> 
> So I contacted the TSVWG chairs to try to get an update on when the document
> could be ready. The WG has not abandonded it. Actually I found an updated
> version from March that simply failed to make it into the public archive at that
> point.
> 
> I will also note that the document has gone through one WG last call and appear
> to be in descent shape. The only issue is that the main author been busy with
> L4S that is a hot topic in TSVWG.
> 
> We have requested an estimate for an update from Bob Briscoe so that we can get
> this document going forward.
> 
> So it might be possible to get this document approved before the end of the
> year.
> 
> As an alternativ there might be possible that you can reformulate the sentence
> so that the high level requirement that the reader is expected to derive is
> expressed in your document, and then you can get to a state where the reference
> would only be informative?
> 
> Cheers
> 
> Magnus
> 
> 
> 
> On Thu, 2020-07-09 at 16:51 +0000, Fabio Maino (fmaino) wrote:
>> Hi Magnus, thanks for your comments.
>>
>> Wrt I-D.ietf-tsvwg-ecn-encap-guidelines it turns out that the draft is
>> expired, so making it normative might not be an option.
>>
>> Since it is meant to replace RFC3819, should we refer to RFC3819 instead?
>>
>> Thanks,
>> Fabio
>>
>>    
>>
>> On 7/9/20, 5:43 AM, "Magnus Westerlund via Datatracker" <noreply@ietf.org>
>> wrote:
>>
>>      Magnus Westerlund has entered the following ballot position for
>>      draft-ietf-lisp-gpe-17: No Objection
>>
>>      When responding, please keep the subject line intact and reply to all
>>      email addresses included in the To and CC lines. (Feel free to cut this
>>      introductory paragraph, however.)
>>
>>
>>      Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>      for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>>      The document, along with other ballot positions, can be found here:
>>      https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/
>>
>>
>>
>>      ----------------------------------------------------------------------
>>      COMMENT:
>>      ----------------------------------------------------------------------
>>
>>      Section 4.2:
>>
>>      To me it looks like this is normative reference:
>>
>>      Such new encapsulated payloads, when registered with LISP-
>>         GPE, MUST be accompanied by a set of guidelines derived from
>>         [I-D.ietf-tsvwg-ecn-encap-guidelines] and [RFC6040].
>>
>>      Section 4.3.1:
>>
>>      Thanks for writing relevant guidance on how to mitigate the risks with
>> zero
>>      checksum. Especially the one on traffic separation from other traffic so
>> that
>>      it can be caught on the boundaries of the network to prevent the risk to
>> other
>>      networks from corrupted traffic.
>>
>>
>>
>>