Subject: [GROW] WG Adoption call for: draft-mlevy-ixp-jumboframes

From: Christopher Morrow <[email-masked]>
Date: Thu, 17 Nov 2011 03:11:17 -0500

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)

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 17 Nov 2011 12:43:03 +0000

> work that GROW should pursue?

yep, definitely would like to see some formal guidelines in this area.

Nick

---

From: Seiichi Kawamura <[email-masked]>
Date: Fri, 18 Nov 2011 16:04:02 +0900

I think this is an interesting document.
Although I have never had the experience of
using jumbo frames on my router connecting to the IX,
I am certainly interested in this discussion and
IF I was to be involved in such a case, having
a document that I can refer to will make things a lot easier.
So I think yes, it's worth a discussion in GROW.

For that matter, I would like to see the socialite draft
discusseed in GROW too, but I guess Warren's taking that to IDR?

Seiichi

(2011/11/17 17:11), Christopher Morrow wrote:
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 18 Nov 2011 08:30:38 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Christopher Morrow
> Sent: Thursday, November 17, 2011 12:11 AM
> To: [email-masked]; [email-masked] [email-masked]; 
> Martin J. Levy
> Subject: [GROW] WG Adoption call for: draft-mlevy-ixp-jumboframes
> 

Yes.

---

From: Gaurab Raj Upadhaya <[email-masked]>
Date: Tue, 22 Nov 2011 06:10:00 +0000

On 11/17/11 8:11 AM, Christopher Morrow wrote:
> can we get a poll on the adoption for this document in GROW, is
> this work that GROW should pursue?
> 

support.

wonder why it too so many years, I had to go dig this

http://63.196.71.246/~phil/jumbo.html.

- -gaurab

- -- 

http://www.gaurab.org.np/

---

From: Arien Vijn <[email-masked]>
Date: Wed, 23 Nov 2011 10:45:42 +0100

> work that GROW should pursue?

Yes, the GROW workgroup should take this up.

-- Arien

---

From: "George, Wes" <[email-masked]>
Date: Mon, 28 Nov 2011 11:58:50 -0500

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christopher Morrow
> Sent: Thursday, November 17, 2011 3:11 AM
> To: [email-masked]; [email-masked] [email-masked]; Martin J.
> Levy

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.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 28 Nov 2011 20:50:37 +0100

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: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Christopher Morrow
>> Sent: Thursday, November 17, 2011 3:11 AM To:
>> [email-masked]; [email-masked] [email-masked]; Martin J.
>> Levy Subject: [GROW] WG Adoption call for:
>> draft-mlevy-ixp-jumboframes
>>
>> -chris (co-chair) _______________________________________________
>> GROW mailing list [email-masked]
> 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
> [email-masked] https://www.ietf.org/mailman/listinfo/grow
>
>

---

From: "Martin J. Levy" <[email-masked]>
Date: Mon, 28 Nov 2011 11:57:53 -0800

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:
> 
> 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.
> 
>

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 28 Nov 2011 15:24:19 -0500

> 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

---

From: Roland Dobbins <[email-masked]>
Date: Tue, 29 Nov 2011 12:34:42 +0700

> 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?

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.'.

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 29 Nov 2011 10:07:26 -0500

> 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…

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

---

From: Roland Dobbins <[email-masked]>
Date: Wed, 30 Nov 2011 10:35:47 +0700

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!