Subject: [nvo3] New Version Notification for draft-saum-nvo3-pmtud-over-vxlan-03.txt

From: "Saumya Dikshit (sadikshi)" <[email-masked]>
Date: Fri, 17 Jun 2016 17:41:16 +0000

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
Revision:	03
Title:		PMTUD Over Vxlan
Document date:	2016-06-17
Group:		Individual Submission
Pages:		27
URL:            
https://www.ietf.org/internet-drafts/draft-saum-nvo3-pmtud-over-vxlan-03.tx
t
Status:         
https://datatracker.ietf.org/doc/draft-saum-nvo3-pmtud-over-vxlan/
Htmlized:       
https://tools.ietf.org/html/draft-saum-nvo3-pmtud-over-vxlan-03
Diff:           
https://www.ietf.org/rfcdiff?url2=draft-saum-nvo3-pmtud-over-vxlan-03

Abstract:
   Path MTU Discovery between hosts/VM/servers/end-points connected over
   a Data-Center/Service-Provider Overlay Network, is still an
   unattended problem.  It needs a converged solution to ensure optimal
   usage of network and computational resources for all hooked end-point
   devices.

Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Jun 2016 11:46:22 -0700

> 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