Hi, Vincent, Thanks for your detailed comments. All are queued up for the next revision.
Comments below only where needed. Joe On 6/8/2016 7:44 AM, Vincent Roca wrote: > Hello everybody, > > > 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. > ** 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 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. > > > ** 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. ... > ** 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. Throughout this doc, we similarly refer to the tunnel as a link, so link MTU is the correct notion. ... > ** Section 5.2: I fully agree with: > "Detect when the egress MTU drops below the required minimum and shut > down the tunnel if that happens - configuring the tunnel down and > issuing a hard error may be the only way to detect this anomaly, and > it's sufficiently important that the tunnel SHOULD be disabled." > > However this not only an implementation aspect. This is also required > for security > reasons and therefore it should be discussed in the Security > Considerations section > as well. E.g., we observed opposite behaviors from an on-the-shelf IPsec > implementation and discussed consequences in our (now expired) > draft-roca-ipsecme-ptb-pts-attack-00. > > [WG: we already discussed this aspect in private emails with Joe last > week.] See below - I think Vincent and I are still working on this... > ** Section 5.4.4: it is said, for the "consistent with this doc" part, > that: > "Shuts the tunnel down if the tunnel path MTU isn't => 1280." > This contradicts the example of section 4.1 where TunnelPMTU == > 1280-40-TOptSz > is valid... > Do you mean "Shuts the tunnel down if the Tunnel MTU, seen from the > outside network, > isn't >= 1280"? Yes. That's consistent with tunnel = link and MTU = payload. > ** Section 6, Security considerations > As already discussed privately with Joe, I may have other items but > still need > to think it over. > > > ** Section A.1: the following sentence is ambiguous: > OLD: > "When the encapsulated packet exceeds the MTU of the tunnel, the > packet needs to be fragmented." > This is the Tunnel Path MTU, not MTU of the tunnel which can be > understood as > synonymous to the Tunnel MTU. It's the tunnel MTU, as clarified above. > ** Section A.1/ A.2: > Discussion in section 4.1 assumes an Outer Fragmentation scheme. The > notion of > Egress Reassembly also assumes an Outer Fragmentation. In fact it > seems to be > the model assumed throughout this I-D but this is not clearly stated > unless I missed > something. Am I right? You are correct. > It's clearly more universal as it does not make any assumption on the > inner packet > (can it be fragmented on path or not, as explained in A.2). > I think the I-D should identify from the beginning the assumption made > (Outer vs. > Inner fragmentation) as it will impact the discussion. Said > differently move Appendix A > in Section 3 for instance. Point taken, esp. with discussions on other lists (e.g., v6ops) and the notion of "recursive" tunneling (X in X, for any X). Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
