Hi Vincent, My sincere appreciation for the detailed review. You have contributed many points that will greatly improve the specification. Some responses to your questions below:
> -----Original Message----- > From: Vincent Roca [mailto:[email protected]] > Sent: Thursday, June 16, 2016 11:48 PM > To: Templin, Fred L <[email protected]> > Cc: Vincent Roca <[email protected]>; Joe Touch <[email protected]>; > [email protected]; [email protected] > Subject: Re: [Int-area] Comments for draft-ietf-intarea-tunnels-02 > > 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. OK. > ** 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. Most end systems connect to media like Ethernet and WiFi with a native 1500 MTU. Without MSS clamping somewhere in the network, that is the size (minus headers) that will be propagated to TCP correspondents in the MSS option. If there is a tunnel in the path, that tunnel would then either have to also somehow configure a 1500 or larger MTU, or return ICMP PTB messages if it configures a smaller MTU (e.g., 1480). That is why the text says "or a suitable PTB message returned". Can you suggest a wording change that might better address your point? > ** 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? Yes, I can say that - thanks. > 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). We could possibly give examples of well managed administrative domains, e.g., major corporate enterprise networks, aviation networks, operator networks, etc. Would adding some examples help? Or, if you think a definition is needed I would be happy to review any text suggestions you may have. > ** 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. Yes, I can make this clear in the text. Thanks. > ** 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. Good point; will fix. Thanks. > ** 3.13.3, 2nd bullet: > By "minimum number of non-overlapping fragments", I guess you mean two. Say > that. It would be a minimum of two for 1500 and smaller data packets, yes, but we may need to account for fragmentation of larger control messages. For example, if a control message in the future needs to carry something like an X.509 certificate it could become quite large (e.g., 3-4K or even larger). In that case, there could be more than two fragments. > 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. 2KB is 1500 plus ample room for additional encapsulation headers. 2KB is also a natural memory allocation boundary that should be friendly to memory management systems in end systems and network devices (i.e., it would match more naturally with operating system memory page sizes). > ** 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. Agree. I will fix this. > ** 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. Right, it sounds like some more examination of well-managed admin domains in the document would be helpful. I would be happy to review any text suggestions you may have. About expectation of operational ICMP PTB between actors that are in different administrative domains, what I mean to say is that if the two administrative domains can only reach each other via the public Internt then all bets are off and there can be no reliance on ICMP PTB and/or sufficiently large link MTUs in the path. Niether administrative domain has the ability to control what goes on in the outside Internet. Thanks - Fred [email protected] > Cheers, > > Vincent _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
