[RTG-DIR] RtgDir review: draft-ietf-nvo3-geneve-14

Tal Mizrahi <tal.mizrahi.phd@gmail.com> Thu, 28 November 2019 13:59 UTC

Return-Path: <tal.mizrahi.phd@gmail.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13DF120874; Thu, 28 Nov 2019 05:59:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=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 4-wxrDMAlGZ6; Thu, 28 Nov 2019 05:59:11 -0800 (PST)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 5EED41200C4; Thu, 28 Nov 2019 05:59:11 -0800 (PST)
Received: by mail-wm1-x332.google.com with SMTP id f129so11778446wmf.2; Thu, 28 Nov 2019 05:59:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=fSpImIf8mbngOvkC0OtUrzqJMuC90yCXS/zRbACcH9w=; b=QYG9ZmyO7bVswnFqDzogeW31UiSh2/ZkbZ+/ZQpXDhI3A1Uf+95lRGiHJ/Fk0Bjoaf hRD4p1eVdz0wXoKXcD/m5xhOu8Kj4Xw8BkvTGn14j7N7P58IoWUvNX3niZvmrb49eCPT WTzEnDA6SWIwyehywt2Kle/pJxzO9Q8ENrFjeOU9QnGP3rt9PHw8u0dFmtPQ1UeC1uJD UZUCV8RkpTGoveNVdrBT5FRhXYx/Aevx7Mo5qQRY6Zo1M/nhOv2qYaWHPDMeCeRIqWDI EFoF9PNLhaxz/ytB0eFb/RGXx8M7lBG0YvD0ddWDRXrEWutduWiz65Z8OwhuMHw65gk1 QsmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=fSpImIf8mbngOvkC0OtUrzqJMuC90yCXS/zRbACcH9w=; b=gik7wZ3DjveDY1gyN5407jS2nAcKXOWpW43IvrOnIjSJaTyElr38LXllipPFKmJo31 EAF2ndz8RQZP5JZGmM1vXPTjosv8OOgOHK0nICkdvmP31eXZ+yPX8OlN37vomC9k2Eey PzCSHz/3YbkpMDYgHUQvBXp4NtYD41WG/KyxffVUKNZ13NdASBFxp5fapaWcEmYyt9Ss ytKaqptEUjJjTt5C37c5rRgyO2jTDYJU05qGT+roo+1NaH4Ngjl69xv2GWaSHuTXJXSG de8jvcIKLtjYLJjDm3NW9RFUSMyyox8ROklzhTtpguL42UQKHDkH9VHiRDgMdioyXR7q 62zQ==
X-Gm-Message-State: APjAAAWK1quS+vj3P81UBzYtk5uGoH7vBrFxhpXD1YCUdb2IIdpUQNnX RQmhphDqq5PKrynEUhfvDWNHkIsS39RMUsajQblbutBLmT0=
X-Google-Smtp-Source: APXvYqzN8dPHNGBHhPZ+dWAhW2YhoFxm5/+ovZt4RgfNXnTKZFp/8qXyaUJQcDyqC8wcgCSbUQzAfEeOcUwCGaJ3hgU=
X-Received: by 2002:a1c:39c4:: with SMTP id g187mr10315681wma.78.1574949549423; Thu, 28 Nov 2019 05:59:09 -0800 (PST)
MIME-Version: 1.0
From: Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Date: Thu, 28 Nov 2019 15:58:58 +0200
Message-ID: <CABUE3Xn2V1L+M7Kd7TOC8Uhz+UXFUjBHMLnVxx00p8eZCm5Uvw@mail.gmail.com>
To: rtg-ads@ietf.org
Cc: rtg-dir@ietf.org, draft-ietf-nvo3-geneve@ietf.org, NVO3 <nvo3@ietf.org>, nvo3-chairs@ietf.org, IETF <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006ec0de0598688462"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/sDZgm23mCO_p5SaadjrI8_3fdoo>
Subject: [RTG-DIR] RtgDir review: draft-ietf-nvo3-geneve-14
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Nov 2019 13:59:14 -0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and sometimes
on special request. The purpose of the review is to provide assistance to
the Routing ADs. For more information about the Routing Directorate, please
see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF Last
Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-nvo3-geneve-14
Reviewer: Tal Mizrahi
Review Date: 28-Nov-2019
Intended Status: Standards Track


Summary:
========
I have some minor concerns about this document that I think should be
resolved before publication.


Comments:
=========

The draft is clear and well-written.
Specific comments are provided below.

Section 2.2:
"The presence of a Geneve variable length header SHOULD NOT prevent the
tunnel endpoints and transit devices from using such offload capabilities."
- this is purely an implementation consideration, and uppercase requirement
language is not appropriate.

Section 3.4:
  "Transit devices MUST maintain consistent forwarding behavior
   irrespective of the value of 'Opt Len', including ECMP link
   selection.  These devices SHOULD be able to forward packets
   containing options without resorting to a slow path."
The first sentence makes sense, but the second sentence is
implementation-specific. Given the first sentence, I would recommend to
remove the second sentence.

Section 3.5:
OLD:
for standardized and experimental options
NEW:
for allocated and for experimental options
Explanation:
the word "standardized" is misleading, because the document is requesting
an "IETF Review" allocation policy.

Section 3.5.1:
I could not find a specification of what a receiving endpoint should do if
the total length of the Geneve header + options exceeds its processing
depth. Drop? Notify the peer tunnel endpoint?

Section 4.2:
"Geneve MUST be used with congestion controlled traffic or within a network
that is traffic managed to avoid congestion (TMCE)" - the MUST does not
seem appropriate. It is up to the operator whether congestion control is
required or not.

Section 4.6:
This section should be rephrased. This section currently defines how
hardware offloading in NICs should be implemented, including MUST
requirements. A network protocol should not define requirements for
specific implementation approaches. Instead, the section should describe
what is expected from ANY intermediate node in the network (switch, router,
or hardware component along the path) to do or not do (for example not to
change the order of Geneve options).

Section 5:
- I suggest to remove this section, or to significantly revise it. As
opposed to its title, it does not discuss interoperability, but migration
from other tunnel protocols to Geneve.
- The following sentences are inaccurate: "Geneve does not introduce any
interoperability issues as it appears to most devices as UDP packets.", and
"Geneve is a superset of the functionality of the most common protocols
used for network virtualization (VXLAN,NVGRE)"
- It appears that removing this section would not remove significant
information.

Section 7:
OLD:
are to be reserved for standardized options for allocation by IETF Review
NEW:
are to be assigned by the IETF Review policy
Explanation:
This sentence is confusing, since "Standards Action" and "IETF Review" are
two different IANA policies.

Section 1:
Currently section 1.1 starts a whole page after section 1 starts. I suggest
to separate the Requirement Language and the Terminology from the
Introduction (two different sections).

References:
IEEE.802.1Q_2014 is not the latest version of 802.1Q.

Cheers,
Tal Mizrahi.