Re: [nvo3] New Version Notification for draft-saum-nvo3-pmtud-over-vxlan-03.txt
Joe Touch <touch@isi.edu> Fri, 17 June 2016 18:46 UTC
Return-Path: <touch@isi.edu>
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 ECE2112D9C7 for <nvo3@ietfa.amsl.com>; Fri, 17 Jun 2016 11:46:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.326
X-Spam-Level:
X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
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 vJom1ak3e-WD for <nvo3@ietfa.amsl.com>; Fri, 17 Jun 2016 11:46:44 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 A440A12D9C1 for <nvo3@ietf.org>; Fri, 17 Jun 2016 11:46:44 -0700 (PDT)
Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u5HIkMSd003049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 17 Jun 2016 11:46:26 -0700 (PDT)
To: "Saumya Dikshit (sadikshi)" <sadikshi@cisco.com>, "nvo3@ietf.org" <nvo3@ietf.org>
References: <20160617173711.9656.36621.idtracker@ietfa.amsl.com> <D38A33B2.67D78%sadikshi@cisco.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <5027ea95-6583-325f-33e8-71d7731d78fe@isi.edu>
Date: Fri, 17 Jun 2016 11:46:22 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <D38A33B2.67D78%sadikshi@cisco.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/cg1u9F3Ocx3zQPBVPfveBePahew>
Subject: Re: [nvo3] New Version Notification for draft-saum-nvo3-pmtud-over-vxlan-03.txt
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 17 Jun 2016 18:46:46 -0000
On 6/17/2016 10:41 AM, Saumya Dikshit (sadikshi) wrote: > A new version of I-D, draft-saum-nvo3-pmtud-over-vxlan-03.txt > has been successfully submitted by Saumya Dikshit and posted to the > IETF repository. > > Name: draft-saum-nvo3-pmtud-over-vxlan > I'm confused by a number of things in this doc: - PTB is an IPv6-ism, but the doc also refers in places to the DF bit. The relevant IP version should be indicated to clarify what protocol is affected. - the applicability claims relevance across protocols that don't use VXLAN, which makes no sense given the claimed focus of the doc. - the doc refers to places (ToR) and protocols (VXLAN gateway) as if they are synonymous. It needs to be more clear whether you intend place, protocol, or both - but "place OR protocol" makes no sense to me. - the issues raised here have nothing to do with VXLAN or NVO3, and IMO are endemic to all tunnels - which is why they are already addressed in intarea-tunnels. The need for this as a separate recommendation should be made much more clear, and the relationship of the recommendations here to those should be also made more clear. - the "error" described in the end of section 3.1.1 is actually a feature. When you ask the network for a path MTU, you're asking "what is the MTU of the path", not "what is the largest message that the path can handle without internal fragmentation". There's no way to determine the second, especially over a tunnel. A tunnel *is* a link - the whole point of a link is to isolate the upper layers from how the link needs to handle things. FYI, Fred and I have tripped over this issue many times before. We agree that "largest unfragmented packet over a link" might be an interesting question for a network layer to ask of a link layer, but ICMP doesn't do that - it reports only what gets over the network layer. - the doc ignores PLPMTUD, which is what is actually needed to overcome the limitations of ICMP and ICMP translation here. Joe
- Re: [nvo3] New Version Notification for draft-sau… Joe Touch
- [nvo3] New Version Notification for draft-saum-nv… Saumya Dikshit (sadikshi)