[nvo3] 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: nvo3@ietfa.amsl.com
Delivered-To: nvo3@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/nvo3/YNMW7x2e2SjJclcidlolVAwUv0c>
Subject: [nvo3] RtgDir review: draft-ietf-nvo3-geneve-14
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-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.
- [nvo3] RtgDir review: draft-ietf-nvo3-geneve-14 Tal Mizrahi
- Re: [nvo3] RtgDir review: draft-ietf-nvo3-geneve-… Ganga, Ilango S