Hello Fred, Sorry for the delay...
> 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. I don't know the exact motivations for this proposal, and therefore won't comment on this aspect. I "just" read the current I-D, section 13, and here are some comments. ** 3.13 Intro: it is said: "Although IPv4 specifies a smaller minimum link MTU of 68 bytes [RFC0791], AERO interfaces also observe a 1280 byte minimum for IPv4 even if some fragmentation is needed." I fully agree! We observed on our side that Linux/Windows hosts react badly to ICMP PTB announcing PMTUs below 576 (this is not the exact value). So this idea of imposing a minimum MTU that is larger is fine, and aligning it with IPv6 can make sense. ** 3.13 Intro: it is said: "Original source hosts have therefore become conditioned to expect that IP packets up to 1500 bytes in length will either be delivered to the final destination or a suitable PTB message returned." Really? Isn't "conditioned to expect" a bit too strong? This is true for standard links but with the multiplication of "virtual links" (e.g., tunnels) I wouldn't make such a claim. ** 3.13.2 vs. 3.13.3 criteria I understand that behind: "When the original source, ingress and egress are all within the same well-managed administrative domain" there is in fact the idea of having a guaranty that there is no ICMP blackhole, and therefore PMTUD is effective. Is it really what you mean? In that case why don't you say that clearly? And could a "well managed admin. domain" decide to filter or not generate ICMP(v6) PTB for some legitimate reason (or assumed so)? In summary, we need a definition of what is meant by "well-managed" (I think it's not the case in previous sections). ** 3.13.2: notions of L3 versus L2 PTB message not defined. I understand that L3 PTB refers to ICMP(v6) PTB sent to the source, while L2 PTB refers to ICMP(v6) PTB exchanged within the tunnel, seen as a link. Is it what you mean? I'd suggest to say that explicitly in the I-D. ** 3.13.3, first bullet: "... i.e., unless lost due to congestion or routing errors." Don't try to provide an exhaustive list of reasons why a packet won't arrive, it's impossible. ** 3.13.3, 2nd bullet: By "minimum number of non-overlapping fragments", I guess you mean two. Say that. Also, I don't really understand why you recommend the egress to be capable of reassembling at least 2KB. Why 2KB rather than, say, 1500+100? It looks like a magic number. ** 3.13.3, 4th bullet, 1) This I-D is about tunneling, so why should it RECOMMEND that end-host use PLPMTUD? It's out of scope. A lower case "recommended" would be preferable. ** 3.13.3, last two paragraphs: Once again, the following paragraph seem to assume that ICMP(v6) PTB is operational. Say that, especially as it can be the case even if ingress/egress are not in the same "well-managed admin domain". Same comment for the last paragraph. Cheers, Vincent
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
