Hi Vincent, I would like to invite you to review Section 3.1.3 of the AERO spec:
https://datatracker.ietf.org/doc/draft-templin-aerolink/ which is titled: "AERO Interface MTU and Fragmentation" and presents an alternate viewpoint. In particular, it allows for leveraging operational assurance of sufficient MTU (RC4459, Section 3.3) and path MTU discovery from within the tunnel (RFC4459, Section 3.2) in environments where it is assured that those techniques will not result in black holes. In other cases, the tunnel ingress makes sure that packets of minimum sizes get through even if a little fragmentation and reassembly are needed, and allows larger packet into the tunnel unfragmented at risk that they may be dropped silently. It is therefore up to the original source to ensure that PLPMTUD is used when it sends large packets. Thanks in advance for your review and comments, Fred [email protected] > -----Original Message----- > From: Int-area [mailto:[email protected]] On Behalf Of Vincent Roca > Sent: Friday, June 10, 2016 12:45 AM > To: Joe Touch <[email protected]> > Cc: [email protected]; [email protected] > Subject: Re: [Int-area] Comments for draft-ietf-intarea-tunnels-02 > > Hello Joe, > > > Thanks for your detailed comments. All are queued up for the next revision. > > You're welcome. > > A few answers below. I removed all items we agreed. > > > >> First of all, I need to say that I found the > >> draft-ietf-intarea-tunnels-02 I-D extremely useful > >> and wish I found it before. > >> > >> We exchanged a few private emails with Joe last week and I promised to > >> send detailed > >> comments on the list. Here they are... Sorry if this is a bit long. > > ... > >> I also clarified the case of encapsulation header size that is deducted. > > It's worth noting throughout that MTU is defined as the size of the payload. > > Yes but there are two notions of payloads depending on the point of view. > Figure 10 can be useful: > inner packet payload => iD > tunnel link packet's payload => iH+iD > > >> ** Path MTU definition: I think it's worth clarifying that we focus on > >> the tunnel PMTU in this I-D. > >> I also explain that the encapsulation header size has already been > >> subtracted from the > >> Tunnel PMTU. > >> > >> OLD: > >> o Path MTU (PMTU): the largest message that can transit a path. > >> Typically, this is the minimum of the link MTUs of the links of > >> the path. > >> > >> NEW: > >> o Path MTU: the largest message that can transit a path. > >> Typically, this is the minimum of the link MTUs of the links of > >> the path. > >> > >> o Tunnel Path MTU (TunnelPMTU): the largest Tunnel Transit Packet > >> (or fragment) > >> that can transit inside the tunnel's path. The encapsulation > >> header size is already > >> subtracted from TunnelPMTU and this TunnelPMTU is not visible > >> from outside the > >> tunnel, unlike the Tunnel MTU. > > > > This definition is what the tunnel MTU is intended to convey. > > I don't understand. If we re-use example of 4.1, Tunnel MTU=1460 - TOptSz > while tunnel path MTU=1240 - TOptSz. The first one is visible to source, > the second one is not, and the difference is due to reassembly at egress. > > > > I think we do need another term for the path MTU between the egress and > > ingress but NOT inside the tunnel. I prefer to just call that the PMTU > > between the ingress and egress, though. > > Okay, this is the regular IP vision of PMTU. If we need it, we can define it. > > > >> ** In tunnel MTU definition: > >> Say explicitly that the encapsulation header size has already been > >> subtracted from > >> the Tunnel MTU, since encapsulation headers are considered as > >> "headers from lower > >> protocols" and therefore excluded. > >> > >> OLD: > >> o Tunnel MTU (TMTU): the largest message that can transit a tunnel. > >> Typically, this is limited by the egress reassembly MTU. > >> > >> NEW: > >> o Tunnel MTU (TunnelMTU): the largest message that can transit a > >> tunnel. > >> The encapsulation header size is already subtracted from TunnelMTU. > >> Typically, the TunnelMTU is limited by the EgressRMTU. > > This should be clarified as the MTU that can transit *inside* a tunnel. > > yes, it's simple and consistent with the tunnel=link viewpoint. > > > >> ** Still section 4.1: we cannot say that 1500 is the minimum > >> EgressRMTU as > >> we need to remove the encapsulation header size before as detailed above. > >> I also tried to explain why... Not easy! Do you have a better explanation? > > > > It's because IPv6 uses the term MTU in terms of the link payload, not as > > the network payload. > > You're right, RFC2460 uses "link MTU". I never paid attention to this. > > > Throughout this doc, we similarly refer to the tunnel as a link, so link > > MTU is the correct notion. > > Yes. > > Regards, > > Vincent > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
