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

Luigi Iannone <ggx@gigix.net> Thu, 07 February 2019 08:42 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 F204F1310FA for <lisp@ietfa.amsl.com>; Thu, 7 Feb 2019 00:42:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.042
X-Spam-Level:
X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 Uco9nUrBrDgt for <lisp@ietfa.amsl.com>; Thu, 7 Feb 2019 00:42:31 -0800 (PST)
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 CC8AA131104 for <lisp@ietf.org>; Thu, 7 Feb 2019 00:42:25 -0800 (PST)
Received: by mail-wm1-x32f.google.com with SMTP id a62so5167081wmh.4 for <lisp@ietf.org>; Thu, 07 Feb 2019 00:42:25 -0800 (PST)
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=38geerq+/4AW3I5y4M8TbbWP3/yxsrhiZrbCcsxHS7s=; b=NRi6C+MTVV5FnSYbTWWqnBaT63zsFooAb0Ar1uFL2v95xwrNcbXxI6bQuGJiljcJFX JbqDcflV7nb98m2j9CHDkI2h8c1qXQuhjKusHKtQfH4YYhRtzV2V+ttWPtCqMdDkjuNj rfZlsKDUJjHPyzgVJeNbLYumcSi2vOX5jjUgHXneJt/8aCP+FqgXhI63sN+qJhQGNyyz veP42MtybGsZa6xd0XmZmB9L610vcWftuynk1Y9qVMLKhLQddg4wOdXZ2nN1UoTU5IZa HJdOyy970pLjO81Ekbl2ZZ1UGQHdAVw2k+Elu6DjC2MyZmMQHUFThOej6R6vTgYbiErY RKFg==
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=38geerq+/4AW3I5y4M8TbbWP3/yxsrhiZrbCcsxHS7s=; b=oXtgC8juLOpHFOm/4n7A/hwHxkAFwQYDYAdDPCSrlv4LGlqv0oBfJ+lXn/EvUSOYqC mHZx97c2tVLx0TVy0l/IHPgYkTKwtoxf7O38dgIgZVB59+Z/Xee8AJctavLIypx+eLeC 1nr6qcA3GkLw1TTqna4s1mOgHs2Y23/CPf8ZHUdxjvvdVgyuq/G1io1b+p21qF/DUKLg 76cswZaNbmJKSf6hm5OrwizcIB8lhbebMuWeVVnZaZ/Kt1pmQwdK/a4UaCk2yfVcLSJx KXULr//06Fcv8f5yNtVVf+aE65KpTA33tQk+b7ghFwP6JUMIo1zqH0ugZhzd2t+ZqgEO XCxw==
X-Gm-Message-State: AHQUAuZiZGE5OJrpEB5SlOPamnnnqynUwX56EqCmPJXpgdeSeYJCb7PL pRw/JGAgHU4SphHyMpPnpmGT6g==
X-Google-Smtp-Source: AHgI3IbkyxUzBP1+MZfBZ5D1TOGHvdsyIUq6afV1iyzXbQrcEUpa77SzACUkmoeHaDyIxJc54Q+A7A==
X-Received: by 2002:a1c:5a42:: with SMTP id o63mr6256259wmb.88.1549528944130; Thu, 07 Feb 2019 00:42:24 -0800 (PST)
Received: from ?IPv6:2001:660:330f:a4:4082:459c:cea5:81dc? ([2001:660:330f:a4:4082:459c:cea5:81dc]) by smtp.gmail.com with ESMTPSA id m4sm5265117wrq.6.2019.02.07.00.42.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Feb 2019 00:42:22 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Luigi Iannone <ggx@gigix.net>
In-Reply-To: <DA613B3B-C318-42C4-AC80-E32E1D96FA67@kuehlewind.net>
Date: Thu, 7 Feb 2019 09:42:25 +0100
Cc: Dino Farinacci <farinacci@gmail.com>, The IESG <iesg@ietf.org>, lisp-chairs@ietf.org, "lisp@ietf.org list" <lisp@ietf.org>, draft-ietf-lisp-rfc6830bis@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <7BD549B6-CA14-4C84-936C-466208F1D530@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> <CDF10486-2CD1-43C2-BF1B-BA8CA8C29444@gmail.com> <2DC6D38E-C46B-4D38-B093-B88720BCD550@kuehlewind.net> <0BE5C929-D2FA-4786-9F5E-0A93E7700880@gmail.com> <11FBAC13-2859-4778-84CA-B546EB669727@kuehlewind.net> <EB03EA1D-6C18-4039-A228-224774D991B5@gmail.com> <2FEB555F-16A5-4875-93ED-D14BFEEF503A@gigix.net> <A3211D06-60D4-45C6-9B99-3F9CA6421CCA@kuehlewind.net> <1B6E2085-FFD8-4CAA-B9BB-5CBFC5AA9745@gigix.net> <DA613B3B-C318-42C4-AC80-E32E1D96FA67@kuehlewind.net>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/R4zRTQeNaRsxjjf01ZVWYwUh26s>
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: Thu, 07 Feb 2019 08:42:34 -0000

Thanks Mirja.

Ciao

L.


> On 6 Feb 2019, at 18:57, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:
> 
> Hi Luigi,
> 
> yes that sounds great!
> 
> Thanks!
> Mirja
> 
> 
>> Am 06.02.2019 um 17:10 schrieb Luigi Iannone <ggx@gigix.net>et>:
>> 
>> Hi Mirja,
>> 
>> 
>>> On 5 Feb 2019, at 16:39, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:
>>> 
>>> Hi Luigi,
>>> 
>>> I just realized that I never replied to this mail. The change below is okay, however, it did not make it into the current version of the draft and therefore I cannot clear my discuss.
>> 
>> Fair enough.
>> 
>> Let me sum up the changes we agree on:
>> 
>> 
>> Section 5.3 in the part marked as "When doing ITR/PITR encapsulation:”
>> 
>> OLD:
>>      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
>> ].
>>      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.
>> 
>> NEW and simplified:
>> 
>>      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 as specified in 
>> 
>>      [RFC6040]. 
>> 
>> 
>> Note the re-encapsultion test has been remove (see later on)
>> 
>> 
>> Section 5.3 in the part marked as "When doing ETR/PETR decapsulation:"
>> 
>> OLD: 
>>      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.  Implementations exist that copy the 'ECN'
>>      field from the outer header to the inner header even though
>>      [
>> RFC6040
>> ] does not recommend this behavior.  It is RECOMMENDED
>>      that implementations change to support the behavior in [
>> RFC6040].
>> 
>> 
>> NEW and simplified:
>> 
>>      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 as specified in 
>> 
>>      [RFC6040
>> ]. Note that implementations exist that copy the 'ECN'
>>      field from the outer header to the inner header even though
>>      [
>> RFC6040
>> ] does not recommend this behavior.  It is RECOMMENDED
>>      that implementations change to support the behavior in [
>> RFC6040].
>> 
>> 
>> In the same section drop completely the last paragraph because is a duplicate of the above.
>> Replaced by a note on the re-encapsulation:
>> 
>> NEW (Replacing last paragraph)
>> 
>>     Some xTRs and PxTRs performs re-encapsulation operations and need 
>>     to treat the 'Explicit Congestion Notification' (ECN) in a special way.
>> 	  Because the re-encapsulation operation is a  sequence of two operations, namely 
>>          a decapsulation followed by an encapsulation, the ECN bits MUST be treated as described 
>>          above for these two operations.
>> 
>> 
>> Does it sound OK to you?
>> 
>> Ciao
>> 
>> L.
>> 
>> 
>> 
>> 
>> 
>> 
>>> Please also note that the text on decapsulation is basically in the same section twice. I recommend to remove it once and adapt the other one accordingly.
>>> 
>>> Further, inline with RFC6040, you would also need to align the re-encapsulation part. Currently the text says:
>>> "Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the new outer header.“
>>> Usually re-encapsulation is performed by doing de-encapsulation and then encapsulation again. The difference here would be, that if e.g. the inner header is not-ETC but the tunnel changes the bits to ETC0 or ETC1 this error is not further propagated, indicating ECN support where there is not ECN support.
>>> 
>>> Thanks,
>>> Mirja
>>> 
>>> 
>>> 
>>>> Am 26.09.2018 um 17:27 schrieb Luigi Iannone <ggx@gigix.net>et>:
>>>> 
>>>> Hi Mirja,
>>>> 
>>>> trying to follow up on this issue.
>>>> 
>>>> The ECN text for encapsulation is currently:
>>>> 
>>>>     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.
>>>> 
>>>> Can we keep it as it is (updating the reference to 6040)?
>>>> 
>>>> The text for decapsulation is:
>>>> 
>>>> CURRENT:
>>>>     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.  Implementations exist that copy the 'ECN'
>>>>     field from the outer header to the inner header even though
>>>>     [
>>>> RFC6040
>>>> ] does not recommend this behavior.  It is RECOMMENDED
>>>>     that implementations change to support the behavior in [
>>>> RFC6040
>>>> ].
>>>> 
>>>> 
>>>> Which I suggest we shrink to:
>>>> 
>>>> NEW:
>>>> 
>>>>     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]. 
>>>>     Note that implementations exist that copy the 'ECN'
>>>>     field from the outer header to the inner header even though
>>>>     [
>>>> RFC6040
>>>> ] does not recommend such behavior.  It is RECOMMENDED
>>>>     that implementations change, so to support the specifications in [
>>>> RFC6040
>>>> ].
>>>> 
>>>> 
>>>> 
>>>> The text above clearly states that implementations should be conform to 6040. 
>>>> 
>>>> Is it what you were looking for?
>>>> 
>>>> Or am I missing something?
>>>> 
>>>> Ciao
>>>> 
>>>> L.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On 24 Sep 2018, at 19:34, Dino Farinacci <farinacci@gmail.com> wrote:
>>>>> 
>>>>> Well, the implementations are out and working. And we said in the latest updates to consider using RFC6040. So not sure we can do much more than that.
>>>>> 
>>>>> Dino
>>>>> 
>>>>>> On Sep 24, 2018, at 5:52 AM, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:
>>>>>> 
>>>>>> Because they don’t follow RFC6040 and therefore we do something different in some corner cases.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> Am 22.09.2018 um 06:52 schrieb Dino Farinacci <farinacci@gmail.com>om>:
>>>>>>> 
>>>>>>>> However, I totally disagree with your comment on providing details that are not implemented. If they are not implemented correctly, it might even be more important to spell them out in this document, so implementors have chance to update their (future) implementation to do the correct thing. Having deployed implementations that are non standard-conform always happens and in this case it is probably not specifically problematic as it doesn’t impact interoperability. However, it is important though that the spec is correct.
>>>>>>> 
>>>>>>> And why do you think they are implemented incorrectly? 
>>>>>>> 
>>>>>>> Dino
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>