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

Luigi Iannone <ggx@gigix.net> Wed, 26 September 2018 15:28 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 BF453130EBA for <lisp@ietfa.amsl.com>; Wed, 26 Sep 2018 08:28:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 kol7xUX7xpz0 for <lisp@ietfa.amsl.com>; Wed, 26 Sep 2018 08:28:11 -0700 (PDT)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 55E0D130EAB for <lisp@ietf.org>; Wed, 26 Sep 2018 08:28:08 -0700 (PDT)
Received: by mail-wr1-x42a.google.com with SMTP id s14-v6so27457550wrw.6 for <lisp@ietf.org>; Wed, 26 Sep 2018 08:28:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0Tir1IqSKT+is+D7reVC+umW6U7F5LVuQikn/nSX3XE=; b=I/KZ2fo83jKJ5wY/rinh1l3eWH6abd9OKE9WpXUSjZChybWunuhP4o/ptgiTLtVu5E 7fJTQNPhd9yafZ0Mcj4zgQEjjwqYACs5QyO2AZPDpalqvEBfANT9JAypeBcNmAVyeB2+ L6flHpToSX/eHNJMFbzSLh1jRVP6nnlbuhC8ceGmDlQTyTUXNqO9/Bf1w/a9lG1X2+St cA+ca7Ca0HO7vsB5u4YEqyNiYuYaR3/cUVNdYwRBdPo+4SYDawaDFbqdOyGOGeiInWxn t6Fz/crQLFrnz/XM7sf2PcSNFb68vAe99wkMsxp1keJaNPs2g8ErsbMifQJE4GOoK1vL 7mSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0Tir1IqSKT+is+D7reVC+umW6U7F5LVuQikn/nSX3XE=; b=bzjNqr5TOUWVPWFPyzN6u4PWhAmqfZZEk6lSfjnrFSdG8ODti5Drh9F5JDTQ7IrvFp niXezKhQ2PErMlvUs7u5A2NpHhBxn9hLRxX9a7DA/ljJ0XIyXkzhDRsaYKGFk7OaTV1f /guSLyzOE9vsZob77jwABHqTvVsEKlk9utRcOQisHeznpauy/YbEQZgkYZHVP3OZS52u 3Y52++9faUxQEo8L6AJ1/Z/al+5JqY5hMXwV0IM/MsQ/iZZZRaiC0heFReczl6714RzV aRZdaz2OsC3t8niq6jMLIozqEtBSrJ9k0nhkFT3A4OI9Rs0+ie+sDKqJUKwCGXLx1hu8 I5IQ==
X-Gm-Message-State: ABuFfohOkxXukvxNOMM05IRup+HaZypMHw2ytyFPn0fMNm6z8Z/IQwVc F3+LhQ/07qxnOLU4Ph+9il6Uog==
X-Google-Smtp-Source: ACcGV63fESfRQq8TQX/ZWrZatPnUWYqihdsKt2WrDgfHWckYJwW8b33Kg4+jIaZoeEYC1Lb0NWG7Iw==
X-Received: by 2002:adf:9af5:: with SMTP id a108-v6mr5684169wrc.125.1537975682366; Wed, 26 Sep 2018 08:28:02 -0700 (PDT)
Received: from ?IPv6:2001:660:330f:a4:b0a0:f6a9:d60b:b029? ([2001:660:330f:a4:b0a0:f6a9:d60b:b029]) by smtp.gmail.com with ESMTPSA id a17-v6sm1171240wme.40.2018.09.26.08.28.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Sep 2018 08:28:00 -0700 (PDT)
From: Luigi Iannone <ggx@gigix.net>
Message-Id: <2FEB555F-16A5-4875-93ED-D14BFEEF503A@gigix.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EFBF6645-2486-4EF5-8324-9DB4C1EFD319"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Date: Wed, 26 Sep 2018 17:27:59 +0200
In-Reply-To: <EB03EA1D-6C18-4039-A228-224774D991B5@gmail.com>
Cc: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, lisp-chairs@ietf.org, "lisp@ietf.org list" <lisp@ietf.org>, draft-ietf-lisp-rfc6830bis@ietf.org, The IESG <iesg@ietf.org>
To: Dino Farinacci <farinacci@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> <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>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/u0sbcj7nBzDR6tq4hnXopdDjqn4>
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: Wed, 26 Sep 2018 15:28:14 -0000

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 <https://tools.ietf.org/html/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 <https://tools.ietf.org/html/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 <https://tools.ietf.org/html/rfc6040>] does not recommend this behavior.  It is RECOMMENDED
      that implementations change to support the behavior in [RFC6040 <https://tools.ietf.org/html/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 <https://tools.ietf.org/html/rfc6040>]. 
      Note that implementations exist that copy the 'ECN'
      field from the outer header to the inner header even though
      [RFC6040 <https://tools.ietf.org/html/rfc6040>] does not recommend such behavior.  It is RECOMMENDED
      that implementations change, so to support the specifications in [RFC6040 <https://tools.ietf.org/html/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
>>> 
>> 
>