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

Luigi Iannone <ggx@gigix.net> Tue, 18 September 2018 13:46 UTC

Return-Path: <ggx@gigix.net>
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 2B3B3130E4A for <lisp@ietfa.amsl.com>; Tue, 18 Sep 2018 06:46:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.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 x49Ci7SyjAvt for <lisp@ietfa.amsl.com>; Tue, 18 Sep 2018 06:46:41 -0700 (PDT)
Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (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 1BD01130E10 for <lisp@ietf.org>; Tue, 18 Sep 2018 06:46:41 -0700 (PDT)
Received: by mail-wr1-x444.google.com with SMTP id 20-v6so2158865wrb.12 for <lisp@ietf.org>; Tue, 18 Sep 2018 06:46:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UO4i15++Hq5OOOkV3At/XmNMTOb0M/CIvGHu9+Bz0ns=; b=KSkSOwww7U7RB1mdlNwlReIewVZFwblFJT/imFHE5oNwWB/FrUASqatIVbbdvE7TbV 5WBjX0cM9vB1A+qJIpRTaAoBP/FiAGCSUUPiH7rsZ/pJV+0gHBxeFyFhgqVwXbU5IwZy YnaruBIT6wQxJSxynK/cVKbQXf5vzYyZrwvd2eWaxn6arqiaXYO/dN7qdEf6HDhmHtkt exMCNXknNk5XmPlycCrm3MywwFeJZc6fiJ+feyA8fA3WR74rJkP4T+WyD0F5gOy503hl RUyNRUYHs9O7uivYd1Xaxrv1vcIZ5cR4jjqkhhes8rSKuvmhhSiWBl0PAdl8D9VXPmbX T9og==
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=UO4i15++Hq5OOOkV3At/XmNMTOb0M/CIvGHu9+Bz0ns=; b=QGsMLSgxz2WRbu84tegytaXnd204NARSeqyqmfdbAEgzdFkUCxJ7xCKivXoApsojPc ib+B0iWBQhc9Vn42w0KkoAo9j3M25cp8Szk6FKcv+K23CQ56uFBVxuAUHiMm3qh1ZMfn eej0fgSQ22kfl3vCBxsCEp8Es+CrLRNWgBCtEEQG/2t35/e5l+5unX2xZrS/Qn/987m2 AJwFMQMDQfCZlfFnuEiFrZzqjwuyuIy86n8LofCBvjuP2TpW+kRdtYdVcifavEdAihHx vRtkzqSGfg2rODoURAF8mo5w9QbvhccyzVgstDB+25q+Tmwbqj9Kn5poWrfq9n6/io+c iiZA==
X-Gm-Message-State: APzg51DfDFZHGGMsvx5g4Hrmm0N5zb/LD4Kc6p0vNIIUl2vVTlhN9LzN kxTJE3WdC4e0gdCiLc6At8GJmA==
X-Google-Smtp-Source: ANB0VdampPfXsXIYcBurwCrAHMLqBpROaAVOx3/S+1ESSP1sI9KnFpjHhbsgfAkcLWX33WSSMgncDw==
X-Received: by 2002:adf:fb0e:: with SMTP id c14-v6mr23911500wrr.117.1537278399394; Tue, 18 Sep 2018 06:46:39 -0700 (PDT)
Received: from ?IPv6:2001:660:330f:a4:25f4:45e1:39b9:1fee? ([2001:660:330f:a4:25f4:45e1:39b9:1fee]) by smtp.gmail.com with ESMTPSA id 124-v6sm3892638wmk.20.2018.09.18.06.46.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Sep 2018 06:46:38 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Luigi Iannone <ggx@gigix.net>
In-Reply-To: <AC0C4ACA-0E15-441E-B05A-64F034CBF2F1@kuehlewind.net>
Date: Tue, 18 Sep 2018 15:46:43 +0200
Cc: Dino Farinacci <farinacci@gmail.com>, 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: <1A5C783B-05EE-4A58-8905-C5F95B2729D6@gigix.net>
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/lFncN57hnsEhRcwzN-sS0lG3oE4>
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 13:46:44 -0000


> On 18 Sep 2018, at 12:32, 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.

Mirja,

So why not keeping the text as it is (actually with some of the improvement you suggested), but for all the rest we refer to 6040.
See below.

For the encapsulation we keep what you 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 copy the 2-bit 'ECN' field from the stripped inner header to the 
     new outer header.“


For the decapsulation we simply keep the following:

"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. 
     Further information on how to preserve CE information can be found in RFC6040.”


L.