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

Dino Farinacci <farinacci@gmail.com> Mon, 17 September 2018 17:48 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 74B36124BE5; Mon, 17 Sep 2018 10:48:15 -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 TOAR0CFjTa7K; Mon, 17 Sep 2018 10:48:13 -0700 (PDT)
Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 92D931200D7; Mon, 17 Sep 2018 10:48:13 -0700 (PDT)
Received: by mail-pf1-x429.google.com with SMTP id x17-v6so7912705pfh.5; Mon, 17 Sep 2018 10:48:13 -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=Pz7sMS2g+Z+37m7O9NNgo8Q3UJobycRBCSxZRKX7kZw=; b=a8zZw96JpbIsWsP6xd3X56N1upM4CuIa6+SzecNTaHoYX0RmXkYgoMyx4N4OmskCv3 zUKQIBkBfj5B9uoy2+i7igyjVzrffqIVDDgrmUUuW47omsINptmWtiTA6eUQoFUhMsQo 4wg3LKCTkyA7arLuGG4faqI/B0XbuF9WKjUvUCr5WW58nJcCm9AhxlmOBjrDHFmz3w2u jCfbFjneNagVyiB34rJP6RyAnVmISviWxjgEUpD7WzlW05yuuk7Qk07bYxRpU85fcO5S Oipp1pY86LjfV6jYR1zZMWS3Z4Ql5EWlT+KFwQEWcsVu6ShATAkEviEXjm6+crdnKJaF UvGQ==
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=Pz7sMS2g+Z+37m7O9NNgo8Q3UJobycRBCSxZRKX7kZw=; b=UqCiG/SeX5RG0AQTVm3UAT7bXzD7v6ajQtE3ewo8UyFP4ft8kLo1V4xV5GQ0yWZjnF dE7I6b2WF63/45AzqOHeEXmIzmX4WzfSQ4hQCMTtMGYeYY/loONi1vLH9joDYCGl744f 42f+rub+jrNQkclebwcTsU1mvJDa/FtOmt2X4B8en7U9v2oVJj2CluettxJHSSah1F7k nF5kTwaOLB6FTV6CNZXK2ohN8ElTSBmoD8k/3bv/McQ7SORFWqga5yX+AaRVsuSJdX4B IB8GRMpKRgTlJJ5Oc3K9TmMuWEjm2QTcgv/aAkBcrsPL74j4J+6vFPZ6NJlx+OrAcUrN Kskg==
X-Gm-Message-State: APzg51CicW8po8OrD0JEdfMUpicSfTo0AzLo5aCsuhW0wKogDbt47i+e 93uKmU94tBrccvFWzyQ10urUA5Vp
X-Google-Smtp-Source: ANB0VdbQ84EItjJy8bgMxVhzOS/vDv2PGV9IwS9fMM9Tt8jcRPZR+VL8AAVogHoD/hFKCtr8SdIsow==
X-Received: by 2002:a63:c114:: with SMTP id w20-v6mr23544215pgf.234.1537206493043; Mon, 17 Sep 2018 10:48:13 -0700 (PDT)
Received: from [10.10.10.70] ([4.28.87.67]) by smtp.gmail.com with ESMTPSA id i26-v6sm18841413pfo.107.2018.09.17.10.48.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Sep 2018 10:48:12 -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: <2CAF25CC-01EE-49D4-B970-F8EFB24940A8@kuehlewind.net>
Date: Mon, 17 Sep 2018 10:48:11 -0700
Cc: lisp-chairs@ietf.org, draft-ietf-lisp-rfc6830bis@ietf.org, The IESG <iesg@ietf.org>, Luigi Iannone <ggx@gigix.net>, "lisp@ietf.org list" <lisp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5F9D8F39-871D-4A96-9C0A-7BACD2ABB1F7@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>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/n2rlHgseS2cBuREsnZAkhhZLHWo>
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: Mon, 17 Sep 2018 17:48:16 -0000

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

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


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

> 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