Re: [GROW] WG Adoption call for: draft-mlevy-ixp-jumboframes
On Tue, Nov 29, 2011 at 12:34 AM, Roland Dobbins roland.dobb...@gmail.com wrote: On Nov 29, 2011, at 2:50 AM, Robert Raszuk wrote: I think we really need to have a way to determine PMTU in the cases of switch in the middle having a mismatched value. Shouldn't the root cause of PMTU-D breakage - i.e., overfiltering of the requisite ICMP message types - be mentioned and appropriate ICMP filtering recommendations be made in order to ensure PMTU-D functionality across IXP fabrics making use of jumbo frames? it's not always the filtering of packet-too-big messages though, sometimes it's filtering of the packet because the source isn't valid (1918 router interfaces, to take a simple example) Also, there's a typo - 'ICMP filtering on the customers router could impeed this testing.' should read 'ICMP filtering on the customers router could impede this testing.'. customer's router ___ 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
Re: [GROW] WG Adoption call for: draft-mlevy-ixp-jumboframes
On Nov 29, 2011, at 10:07 PM, Christopher Morrow wrote: it's not always the filtering of packet-too-big messages though, sometimes it's filtering of the packet because the source isn't valid (1918 router interfaces, to take a simple example) Yes - so, should this document contain a precis of how to minimize the risk of PMTU-D breakage with regards to the IXP fabric and the SP fabric interconnect devices? customer's router Good catch! ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WG Adoption call for: draft-mlevy-ixp-jumboframes
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
Re: [GROW] WG Adoption call for: draft-mlevy-ixp-jumboframes
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
Re: [GROW] WG Adoption call for: draft-mlevy-ixp-jumboframes
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
Re: [GROW] WG Adoption call for: draft-mlevy-ixp-jumboframes
On Mon, Nov 28, 2011 at 2:57 PM, Martin J. Levy mar...@he.net wrote: 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. you could upload anytime... it'd be nice to say: I uploaded -0X, I included resolutions (I think) to the questions posed by bob, sue, sally, jimmy, but didn't not reach conclusion for Steve and Sam. or something like that :) -chris ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WG Adoption call for: draft-mlevy-ixp-jumboframes
On Nov 17, 2011, at 9:11 AM, Christopher Morrow wrote: 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? Yes, the GROW workgroup should take this up. -- Arien ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WG Adoption call for: draft-mlevy-ixp-jumboframes
-Original Message- From: grow-boun...@ietf.org [mailto:grow-boun...@ietf.org] On Behalf Of Christopher Morrow Sent: Thursday, November 17, 2011 12: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? Yes. 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 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
