Hello Robert, > I think we really need to have a way to determine PMTU in the cases of switch > in the middle having a mismatched value.
The experience shows that it's the IXPs customers that are misconfigured. A quick check on NETNOD showed a few that were not correctly setup. This test can be automated or checked manually. > 6. Testing customer MTU values > > An IXP operator can test the customer port MTU setting via a simple > ping [PING] packet. ... So I think this issue is documented. BTW: I assume I don't upload a 01 version till after all the discussion is done. Right? I have edits in based on this mailing list and other feedback. All good stuff and worth editing in. Martin On Nov 28, 2011, at 11:50 AM, Robert Raszuk wrote: > Support adoption. > > However I think while the draft is an interesting reading the crux of the > issue may/should be really in fixing the PMTU to the extend that if I peer to > N routers I should be able to tell exactly what the max path MTU is by > automation .. and not by guessing or calling the IX NOC or worse remote peers. > > Draft says: > > 10.1. PMTU (Path MTU) issues > > The IP protocol has two Path MTU Discovery (PMTU) mechanisms to > handle packets traveling along a path with varying MTU values for > various links in the path. > > The IPv4 Path MTU Discovery protocol, RFC 1191 [RFC1191], is > considered often NOT to work. See RFC 2923 [RFC2923] [SAUVER2003]. > In IPv6, Path MTU Discovery protocol, RFC 1981 [RFC1981], is > considered to work. > > However neither the IPv4 or IPv6 PMTU methods will work if the layer > 2 fabric has a mismatched value. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > I think we really need to have a way to determine PMTU in the cases of switch > in the middle having a mismatched value. > > Best regards, > R. > > >> Support adoption. I think that the appropriate way to discuss this >> without stepping on IEEE feet is exactly this sort of document, which >> simply recommends a tacit agreement among folks who are already >> likely violating IEEE "law" on the matter that they'll all violate it >> in the same way, and covers the operational considerations both of >> implementing/migrating and of deviating from the official 1500 >> limit. >> >> Thanks, >> >> Wes >> >>> -----Original Message----- From: grow-boun...@ietf.org >>> [mailto:grow-boun...@ietf.org] On Behalf Of Christopher Morrow >>> Sent: Thursday, November 17, 2011 3:11 AM To: >>> grow-cha...@tools.ietf.org; grow@ietf.org grow@ietf.org; Martin J. >>> Levy Subject: [GROW] WG Adoption call for: >>> draft-mlevy-ixp-jumboframes >>> >>> Given the discussion in the room today, and the current doc: >>> <http://tools.ietf.org/html/draft-mlevy-ixp-jumboframes-00> >>> >>> can we get a poll on the adoption for this document in GROW, is >>> this work that GROW should pursue? >>> >>> Call closes 12/01/2011 (Dec 01 2011 for our non-us-participants) >>> >>> -chris (co-chair) _______________________________________________ >>> GROW mailing list GROW@ietf.org >>> https://www.ietf.org/mailman/listinfo/grow >> >> This E-mail and any of its attachments may contain Time Warner Cable >> proprietary information, which is privileged, confidential, or >> subject to copyright belonging to Time Warner Cable. This E-mail is >> intended solely for the use of the individual or entity to which it >> is addressed. If you are not the intended recipient of this E-mail, >> you are hereby notified that any dissemination, distribution, >> copying, or action taken in relation to the contents of and >> attachments to this E-mail is strictly prohibited and may be >> unlawful. If you have received this E-mail in error, please notify >> the sender immediately and permanently delete the original and any >> copy of this E-mail and any printout. >> _______________________________________________ GROW mailing list >> GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow >> >> > _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
