Re: [lisp] Mirja Kühlewind's Discuss on draft-ietf-lisp-rfc6830bis-16: (with DISCUSS and COMMENT)

Dino Farinacci <farinacci@gmail.com> Tue, 18 September 2018 16:56 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 392F9130E0A; Tue, 18 Sep 2018 09:56:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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] 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 Z7CT4GSaNQpb; Tue, 18 Sep 2018 09:56:29 -0700 (PDT)
Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 9F8BA127333; Tue, 18 Sep 2018 09:56:29 -0700 (PDT)
Received: by mail-pf1-x42e.google.com with SMTP id h79-v6so1299860pfk.8; Tue, 18 Sep 2018 09:56:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MSftNArNbdrJRIiPLIwQDTdD7GWEqd2ZJVZHRjxxsbM=; b=O10qMwGaZ4JdRm/Dwno1xr4sqw7V0n0/Zpiu4xKxyzJpqOCyXTE4ruq0bAf3XU7dLd Fs0nF8iLecvMONrtbqaseuCR9CPdQPu0+nwLhboJJuZntVp16MCm3u3zJmBYtahwg7SN RjETJM3p7Yra8wdoJK2PDRWEAfNFVobPjsrAaNJCKwUJA46fiI+a1xFvmigF+zTmyk/S +PCaNTkyvWYZkbxdGg420ElwS0RSPFwSouikGWXXFSoajuCe66jSjOqpTeC4Vwhbpu06 ZGo54qWxFHlJLTaDztKyD6YPnpc8RXv8mYFQZidcqmT/PkHOXbjwtHwmoFviN3NuPdo+ IBSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MSftNArNbdrJRIiPLIwQDTdD7GWEqd2ZJVZHRjxxsbM=; b=ln7A2hbMJb2i5zBbS3z3OHvhqxN4FG9G80HlpZ1gARAizM7MeU1gaip9bA3Znwea3d w2RGZe8lC72XCXO+FGHYocOvlpL8j1jxivjdNaOYm/O7NOlBqDst8aN8DiBtrkFEn67s kR+/2iLDCLVVUxsDFTQniLd1M34OlcdiTOU0PYjUTxHDTtnvuqtFtD3X/MPfirw1Y1h8 VfbguvaRbV+RmnSb3oB406GBMQdkNhs9hDOScKa4NqVhSRmyD/K2kcvQRKLjPHT9u+cu JoJWWdBL1p1WTkp1MwAcClCE7LZWIY37jdSr4ZP24Y4awesQtPX4qBzDIUEV2ujLmjmz AH/A==
X-Gm-Message-State: APzg51CMmicV+OQFpkEidai0YDiyT11fAC8tQNOEfZ6Ux2RgV8t4l7Ob 6Zl77CC4ogl+rDLQQlM3YGiF78En
X-Google-Smtp-Source: ANB0VdYFxGLNcGb8fFVZv7he22U2ns0QTCsmYMe2ep4UAN98FhXWoR7cxsGyCypp9Yc2fnBoHsYVkQ==
X-Received: by 2002:a62:fc5:: with SMTP id 66-v6mr31555579pfp.237.1537289789188; Tue, 18 Sep 2018 09:56:29 -0700 (PDT)
Received: from [10.10.32.182] ([65.154.156.52]) by smtp.gmail.com with ESMTPSA id e73-v6sm35873418pfb.153.2018.09.18.09.56.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Sep 2018 09:56:28 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <AC0C4ACA-0E15-441E-B05A-64F034CBF2F1@kuehlewind.net>
Date: Tue, 18 Sep 2018 09:56:27 -0700
Cc: Luigi Iannone <ggx@gigix.net>, lisp-chairs@ietf.org, "lisp@ietf.org list" <lisp@ietf.org>, draft-ietf-lisp-rfc6830bis@ietf.org, The IESG <iesg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CDF10486-2CD1-43C2-BF1B-BA8CA8C29444@gmail.com>
References: <153667905625.16761.12157659372502604927.idtracker@ietfa.amsl.com> <7DEBCA24-9D55-4325-85AA-48AB3FAAB91D@gmail.com> <0201F06C-DA9E-445A-A995-54BA805B595C@kuehlewind.net> <DDA9C261-44DD-4389-9463-3A84E4C176BB@gmail.com> <5EC21C57-D217-48A9-AFD0-24710299CF7F@kuehlewind.net> <5A3C4B1F-EA31-4698-96F4-915A77400A56@gmail.com> <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net> <5F9D8F39-871D-4A96-9C0A-7BACD2ABB1F7@gmail.com> <AC0C4ACA-0E15-441E-B05A-64F034CBF2F1@kuehlewind.net>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/s6EJwbU0gAMRZXVWggEspVpH2w4>
Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?lisp-rfc6830bis-16=3A_=28with_DISCUSS_and_COMMENT=29?=
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: Tue, 18 Sep 2018 16:56:33 -0000

As I already said, this text is too detailed and repeats what is in other RFCs. And since implementations do what they already do, adding more details that are not implemented, IMO, is not good form.

Dino

> On Sep 18, 2018, at 3:32 AM, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:
> 
> Hi Dino,
> 
> please see below.
> 
>> Am 17.09.2018 um 19:48 schrieb Dino Farinacci <farinacci@gmail.com>om>:
>> 
>>> PROPOSED
>>> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
>>>    of the IPv6 'Traffic Class' field) [RFC3168] requires special treatment in
>>>    order to preserve the use of ECN on the path.
>>>    ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
>>>    header to the outer header, inline with the ’Normal Mode’ in section 4.1 
>>>    of [RFC6040].  Re-encapsulation SHOULD follow the decapsulation as described 
>>>    below and then 2-bit 'ECN' field from the stripped inner header to the 
>>>    new outer header.“
>> 
>> I did not include this text because the last sentence is not formed well. Please restate. A verb is missing.
> 
> copy
> 
>> 
>>> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
>>>    of the IPv6 'Traffic Class' field) requires special treatment on 
>>>    decapsulation in
>>>    order to avoid discarding indications of congestion, 
>>>    inline with section 4.2 of [RFC6040]. If
>>>    the 'ECN‘ field of the outer header contains a congestion indication 	
>>>    codepoint (the
>>>    value is '11', the Congestion Experienced (CE) codepoint) and the inner 
>>>    header indicates ECN support (either ECT(0) or ECT(1) codepoint is set), 
>>>    then ETR decapsulation MUST also set CE field in the inner header that is 
>>>    used
>>>    to forward the packet beyond the ETR. If the inner packet is marked as non-
>>>    ECT but the outer header has the CE mark set, the packet MUST be dropped 
>>>    instead. Any discrepancy between the inner and outer header for non-ECT, 
>>>    ECT(0) and ECT(1) MUST NOT be copied from the outer header. These 
>>>    requirements preserve
>>>    CE indications when a packet that is ECN-capable traverses a LISP tunnel
>>>    and becomes marked with a CE indication due to congestion between
>>>    the tunnel endpoints or transforms an CE into loss if that packet is not 
>>>    ECN-capable conserving the congestion indication towards a non-ECN enables 
>>>    endpoint.”
>> 
>> I didn’t include this text because (1) it under states what to do with IPv4, (2) it has too much detail that is already in RFC6040, and (3) it undoes text that other reviewers have offered.
> 
> I didn’t change the mentioning of IPv6 here. Yes please at IPv4.
> 
> You can remove all this text and only point to rfc6040. That would actually my preferred solution. I don’t think it „undoes“ text; it just adds what was missing in compliance with RFC6040. Anyway it doesn’t matter point being that it should specify the same things as RFC6040 does not matter what other have ofter because RFC6040 is the IETF-consensus doc how describing how to handle this.
> 
>> 
>> 
>>> Please also remove the duplicated text after these bullet lists in the draft!
>> 
>> You have to tell me what text. I am too confused at this point on what you want.
> 
> This is the text in the en-/ and decapsulation lists:
> 
> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
>      of the IPv6 'Traffic Class' field) requires special treatment in
>      order to avoid discarding indications of congestion [RFC3168].
>      ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
>      header to the outer header.  Re-encapsulation MUST copy the 2-bit
>      'ECN' field from the stripped outer header to the new outer
>      header."
> 
> "The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
>      of the IPv6 'Traffic Class' field) requires special treatment in
>      order to avoid discarding indications of congestion [RFC6040].  If
>      the 'ECN' field contains a congestion indication codepoint (the
>      value is '11', the Congestion Experienced (CE) codepoint), then
>      ETR decapsulation MUST copy the 2-bit 'ECN' field from the
>      stripped outer header to the surviving inner header that is used
>      to forward the packet beyond the ETR.  These requirements preserve
>      CE indications when a packet that uses ECN traverses a LISP tunnel
>      and becomes marked with a CE indication due to congestion between
>      the tunnel endpoints."
> 
> And this text comes up right after the list in the same section:
> 
> "The Explicit Congestion Notification ('ECN') field occupies bits 6
>   and 7 of both the IPv4 'Type of Service' field and the IPv6 'Traffic
>   Class' field [RFC6040].  The 'ECN' field requires special treatment
>   in order to avoid discarding indications of congestion [RFC6040].  An
>   ITR/PITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
>   header to the outer header.  Re-encapsulation MUST copy the 2-bit
>   'ECN' field from the stripped outer header to the new outer header.
>   If the 'ECN' field contains a congestion indication codepoint (the
>   value is '11', the Congestion Experienced (CE) codepoint), then ETR/
>   PETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped
>   outer header to the surviving inner header that is used to forward
>   the packet beyond the ETR.  These requirements preserve CE
>   indications when a packet that uses ECN traverses a LISP tunnel and
>   becomes marked with a CE indication due to congestion between the
>   tunnel endpoints."
> 
> The last text bit does not add any information; it just states all normative requirement twice, even using basically exactly the some words. This can lead to discrepancies and it really not necessary. I’d recommend to just remove the last text block here (and fix the IPv6/IPv4 issue in the other blocks).
> 
> Mirja
> 
> 
>> 
>>> Further I believe my discuss points 2) and 4) are not fully resolved yet. Also I would like to at least see more explanation about the approach for extensibility that was taken in this doc (point 6).
>> 
>> You are going to have to repeat what they are because too many emails have flown by since your initial post. And for extensibility, we discuss it in RFC8060 and don’t think anything more should be said here otherwise, we will duplicate unnecessary text.
>> 
>> Another new diff file enclosed.
>> 
>> Dino
>> 
>> 
>> 
>> 
>> 
>> 
>