> On Jul 1, 2015, at 6:16 PM, Black, David <[email protected]> wrote: > > Joe, > >> -overall: in a tunneling system, the packetization layer is the tunnel >> encapsulator, which means that layer should be doing MTU discovery > >> It should be supporting the minimum required transit MTU for IPv4 or >> IPv6 (respectively), and where that's not directly possible it must >> support fragmentation and reassembly on its own. > > Well, the "running code" doesn't do either of those, sorry :-(. > > The underlying situation is that VXLAN, was never standardized by the > IETF - RFC 7348 on VXLAN is an Independent Submission RFC that has > this to say on path MTU: > > VTEPs MUST NOT fragment VXLAN packets. Intermediate routers may > fragment encapsulated VXLAN packets due to the larger frame size. > The destination VTEP MAY silently discard such VXLAN fragments. To > ensure end-to-end traffic delivery without fragmentation, it is > RECOMMENDED that the MTUs (Maximum Transmission Units) across the > physical network infrastructure be set to a value that accommodates > the larger frame size due to the encapsulation. Other techniques > like Path MTU discovery (see [RFC1191] and [RFC1981]) MAY be used to > address this requirement as well.
That could easily be inconsistent with existing requirements, e.g., if running IPv6 over (eventually) IPv6. > If the underlay (physical network) MTU is constant between encap and > decap nodes (the VTEPs), then the packet drop occurs at the ingress VTEP. Right - that would be one source of such an inconsistency. While I appreciate this isn’t what running code does, it’s not appropriate to propose an approach that cannot support existing standards. Joe > > Otherwise, the absence of a requirement to set DF in the outer IPv4 > header can result in black-holing for IPv4 in the underlay when an > intermediate router fragments and the egress VTEP drops the fragments. > > Thanks, > --David > >> -----Original Message----- >> From: nvo3 [mailto:[email protected]] On Behalf Of Joe Touch >> Sent: Wednesday, July 01, 2015 2:45 PM >> To: Saumya Dikshit (sadikshi); [email protected] >> Cc: [email protected] >> Subject: Re: [nvo3] New draft: PMTUD Over Vxlan >> >> >> >> On 7/1/2015 11:38 AM, Saumya Dikshit (sadikshi) wrote: >>> Hi Joe, >>> >>> Vxlan is a Layer-2 tunnel and carries layer-2 frame(complete packet >>> including l2 header) as payload. >> >> If that is correct, then it has no business interacting with ICMP. >> >> It should be supporting the minimum required transit MTU for IPv4 or >> IPv6 (respectively), and where that's not directly possible it must >> support fragmentation and reassembly on its own. >> >> >> ... >>> Secondly, Vxlan Gateway can potentially act as a Layer-2 gateway and >>> Layer-3 gateway for client devices >>> connected over same or different subnet respectively. For Layer-2 gateway >>> case, MTU derivation may not >>> make sense, as the destination is one L3-hop away. >> >> IP hops are measured by the number of routers, not link. I.e., >> traversing one hop is one router, not one link. See RFC1812. >> >> Although I appreciate you're trying to optimize, ICMP PTBs are for "I >> can't carry this message at all", not "I wish it were smaller". If you >> try to interpret the PTBs incorrectly, you'll only create black holes. >> >> Further, the use of PMTUD is deprecated in favor of PLMTUD (RFC4821), >> precisely so the path properties to not rely on ICMPs - which are often >> blocked anyway. >> >> Again, these comments are NOT intended as issues to be "fixed" with >> document edits. >> >> Joe >> >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
