From mailman-bounces@ietf.org Sat Jan 1 06:08:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09652 for ; Sat, 1 Jan 2005 06:08:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CkhIv-0007Fm-7Z for pppext-web-archive@ietf.org; Sat, 01 Jan 2005 06:20:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CkgHC-0000LA-Tx for pppext-web-archive@ietf.org; Sat, 01 Jan 2005 05:14:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: pppext-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sat, 01 Jan 2005 05:04:02 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for pppext-web-archive@ietf.org: List Password // URL ---- -------- pppext@ietf.org kiowes https://www1.ietf.org/mailman/options/pppext/pppext-web-archive%40ietf.org From pppext-bounces@ietf.org Fri Jan 28 16:39:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20563 for ; Fri, 28 Jan 2005 16:39:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cue7o-00025V-09 for pppext-web-archive@ietf.org; Fri, 28 Jan 2005 16:57:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CudTv-0000br-KM; Fri, 28 Jan 2005 16:16:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CudBX-0000Hx-LN; Fri, 28 Jan 2005 15:57:43 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12622; Fri, 28 Jan 2005 15:57:41 -0500 (EST) Message-Id: <200501282057.PAA12622@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 28 Jan 2005 15:57:41 -0500 Cc: pppext@ietf.org Subject: [Pppext] I-D ACTION:draft-ietf-pppext-pppoe-mtu-1500-00.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Accommodating an MTU of 1500 in PPPoE Author(s) : J. Fitzgibbon Filename : draft-ietf-pppext-pppoe-mtu-1500-00.txt Pages : 0 Date : 2005-1-28 Point-to-Point Protocol Over Ethernet, (PPPoE), as described in RFC 2516, mandates a maximum negotiated MRU of 1492. This memo proposes relaxing that restriction to allow a maximum negotiated MRU of 1500. This can be achieved by treating the PPPoE Header and Protocol ID as part of the Ethernet Header, taking advantage of the fact that most network devices have buffers for the Ethernet Header and Payload that are at least 1522 octets in size. To aid backward compatability, the proposal recommends testing the link with MRU-sized Echo-Request packets if an MRU greater than 1492 has been assumed or negotiated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-pppoe-mtu-1500-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-pppoe-mtu-1500-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-pppoe-mtu-1500-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-1-28152644.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-pppoe-mtu-1500-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-pppoe-mtu-1500-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-28152644.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext --NextPart-- From pppext-bounces@ietf.org Fri Jan 28 17:23:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26877 for ; Fri, 28 Jan 2005 17:23:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CueoI-00045W-Nr for pppext-web-archive@ietf.org; Fri, 28 Jan 2005 17:41:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CueLg-0006C0-4d; Fri, 28 Jan 2005 17:12:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CueFZ-0002X8-5y for pppext@megatron.ietf.org; Fri, 28 Jan 2005 17:05:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24927 for ; Fri, 28 Jan 2005 17:05:54 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CueWv-0003Rw-Uy for pppext@ietf.org; Fri, 28 Jan 2005 17:23:56 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0SM5qdt015897 for ; Fri, 28 Jan 2005 15:05:52 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j0SM5qQp028863 for ; Fri, 28 Jan 2005 17:05:52 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.2+Sun/8.13.2) with ESMTP id j0SM5qDM005852 for ; Fri, 28 Jan 2005 17:05:52 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.2+Sun/8.13.2/Submit) id j0SM5q3N005849; Fri, 28 Jan 2005 17:05:52 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16890.46912.369189.324499@gargle.gargle.HOWL> Date: Fri, 28 Jan 2005 17:05:52 -0500 From: James Carlson To: pppext@ietf.org Subject: Re: [Pppext] I-D ACTION:draft-ietf-pppext-pppoe-mtu-1500-00.txt In-Reply-To: Internet-Drafts@ietf.org's message of 28 January 2005 15:57:41 References: <200501282057.PAA12622@ietf.org> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit > Title : Accommodating an MTU of 1500 in PPPoE > Author(s) : J. Fitzgibbon So, now that this is (finally) out, I have some comments. > Abstract > > Point-to-Point Protocol Over Ethernet, (PPPoE), as described in RFC > 2516, mandates a maximum negotiated MRU of 1492. This memo proposes > relaxing that restriction to allow a maximum negotiated MRU of 1500. Many implementations (including the one on Solaris) assume that if the MRU is not negotiated on a PPPoE link (or is rejected), then the default MRU is 1492. Is that still true? Suppose one of these new implementations is negotiating with an old one. The new one suggests an MRU of 1500. The old peer looks at that and says, "well, I can't ever send a packet that big, but I'm glad he could accept it if I could, so I'll send Configure-Ack." The old peer doesn't include the MRU option in its Configure-Request (as none is really needed). What MTU does the new peer end up with? The answer can't be 1500, or interoperability is broken. > This can be achieved by treating the PPPoE Header and Protocol ID as > part of the Ethernet Header, taking advantage of the fact that most > network devices have buffers for the Ethernet Header and Payload that > are at least 1522 octets in size. To aid backward compatability, the This part seems like the wrong venue to me. In order to get the PPPoE Session Stage Ethertype recognized as being in the same class of types as the VLAN tag, I think that the IEEE specifications have to be updated. I don't think that extending Ethernet standards is something the IETF should undertake. > As PPPoE [1] is increasingly becoming the protocol of choice for > provisioning residential and small business Internet service, this is > having the undesirable effect of reducing the effective MTU for large > segments of Internet users from 1500 octets to 1492 octets. Protocol of choice or not, PPPoE has a number of serious problems, perhaps chief among them that it hasn't gone through any of the IETF review processes. (Ignoring the obvious design flaws, such as the one-way assignment of session IDs.) I'm not sure that we should try too hard to publish extensions to something that is effectively a dead end. If someone's interested, I suppose publishing it as yet another "Informational" RFC doesn't completely break the rules, but it does seem at least a bit misleading. > The reduced MTU can cause problems for any equipment or software that > is configured with a static MTU, in particular if the expected or > default value is 1500. In addition, widespread adoption of a lower > MTU reduces the overall efficiency of the Internet. I don't think "efficiency" of 1492 versus 1500 is noticable at all. The real issue is that Path MTU Discovery just doesn't work. It doesn't work because there are huge numbers of horribly broken packet filters (firewalls) and NATs out there, and there's just nothing anyone can do about the problem. And it's yet another good reason why PPPoE is probably not a good idea. > Devices that are not capable of handling the extra 8 octets in their > Ethernet Header SHOULD negotiate an MRU no larger than 1492. If no > MRU has been specified by the receiving side, the sending side MAY > assume that the receiving side is capable of handling the PPP default > MRU of 1500. To ensure compatability with older equipment, if the As above, I believe that breaks compatibility. The default has to be 1492. > sending side is assigning an MRU greater than 1492 to the receiving > side, (either by default, or through negotiation), it is RECOMMENDED > that the sending side send one or more MRU-sized Echo-Request packets > once the session is opened, to test that the receiving side and any > intermediate equipment can handle the MRU. If no Echo-Replies are I think that a procedure like that is a *requirement*, not just a recommendation. The problem is that there simply is no way for any PPPoE implementation to know whether the intermediate devices (which may include switches that add and remove VLAN tags) support an actual MTU of 1508. There's just no way to know that what's being negotiated is at all reasonable. > received, the sending side MAY choose to repeat the test with > Echo-Request packets of size 1492. If these packets receive replies, > the sending side MAY choose to treat the receiver as if it had > explicitly specified an MRU of 1492. I think that's ambiguous. It should probably restart LCP instead. -- James Carlson, IP Systems Group? Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Sat Jan 29 22:56:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10374 for ; Sat, 29 Jan 2005 22:56:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cv6U5-0002x4-Aq for pppext-web-archive@ietf.org; Sat, 29 Jan 2005 23:14:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cv68Z-00043t-Bb; Sat, 29 Jan 2005 22:52:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cv65L-0003ZK-Tl for pppext@megatron.ietf.org; Sat, 29 Jan 2005 22:49:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09911 for ; Sat, 29 Jan 2005 22:49:13 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cv6N1-0002nm-8k for pppext@ietf.org; Sat, 29 Jan 2005 23:07:31 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 29 Jan 2005 22:58:08 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from [10.82.224.158] (rtp-vpn1-158.cisco.com [10.82.224.158]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0U3mfW0020448; Sat, 29 Jan 2005 22:48:41 -0500 (EST) Message-ID: <41FC5916.9030501@cisco.com> Date: Sat, 29 Jan 2005 22:48:38 -0500 From: Bo Berry User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Carlson Subject: Re: [Pppext] I-D ACTION:draft-ietf-pppext-pppoe-mtu-1500-00.txt References: <200501282057.PAA12622@ietf.org> <16890.46912.369189.324499@gargle.gargle.HOWL> In-Reply-To: <16890.46912.369189.324499@gargle.gargle.HOWL> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: 7bit J. Fitzgibbon: Agree with the interoperability concerns brought forth by J. Carlson. This is a real problem. Also performance gain from 1492 to 1500 in the scheme of things is negligible. If you are really set on gaining 8-bytes, consider defining optional tags to negotiate the extended/longer MTU. This method would be backward compatible. Another suggestion is to publish as an Informational RFC. Good luck B. Berry James Carlson wrote: >> Title : Accommodating an MTU of 1500 in PPPoE >> Author(s) : J. Fitzgibbon >> >> > >So, now that this is (finally) out, I have some comments. > > > >>Abstract >> >> Point-to-Point Protocol Over Ethernet, (PPPoE), as described in RFC >> 2516, mandates a maximum negotiated MRU of 1492. This memo proposes >> relaxing that restriction to allow a maximum negotiated MRU of 1500. >> >> > >Many implementations (including the one on Solaris) assume that if the >MRU is not negotiated on a PPPoE link (or is rejected), then the >default MRU is 1492. Is that still true? > >Suppose one of these new implementations is negotiating with an old >one. The new one suggests an MRU of 1500. The old peer looks at that >and says, "well, I can't ever send a packet that big, but I'm glad he >could accept it if I could, so I'll send Configure-Ack." The old peer >doesn't include the MRU option in its Configure-Request (as none is >really needed). > >What MTU does the new peer end up with? The answer can't be 1500, or >interoperability is broken. > > > >> This can be achieved by treating the PPPoE Header and Protocol ID as >> part of the Ethernet Header, taking advantage of the fact that most >> network devices have buffers for the Ethernet Header and Payload that >> are at least 1522 octets in size. To aid backward compatability, the >> >> > >This part seems like the wrong venue to me. In order to get the PPPoE >Session Stage Ethertype recognized as being in the same class of types >as the VLAN tag, I think that the IEEE specifications have to be >updated. I don't think that extending Ethernet standards is something >the IETF should undertake. > > > >> As PPPoE [1] is increasingly becoming the protocol of choice for >> provisioning residential and small business Internet service, this is >> having the undesirable effect of reducing the effective MTU for large >> segments of Internet users from 1500 octets to 1492 octets. >> >> > >Protocol of choice or not, PPPoE has a number of serious problems, >perhaps chief among them that it hasn't gone through any of the IETF >review processes. (Ignoring the obvious design flaws, such as the >one-way assignment of session IDs.) > >I'm not sure that we should try too hard to publish extensions to >something that is effectively a dead end. If someone's interested, I >suppose publishing it as yet another "Informational" RFC doesn't >completely break the rules, but it does seem at least a bit >misleading. > > > >> The reduced MTU can cause problems for any equipment or software that >> is configured with a static MTU, in particular if the expected or >> default value is 1500. In addition, widespread adoption of a lower >> MTU reduces the overall efficiency of the Internet. >> >> > >I don't think "efficiency" of 1492 versus 1500 is noticable at all. >The real issue is that Path MTU Discovery just doesn't work. It >doesn't work because there are huge numbers of horribly broken packet >filters (firewalls) and NATs out there, and there's just nothing >anyone can do about the problem. > >And it's yet another good reason why PPPoE is probably not a good >idea. > > > >> Devices that are not capable of handling the extra 8 octets in their >> Ethernet Header SHOULD negotiate an MRU no larger than 1492. If no >> MRU has been specified by the receiving side, the sending side MAY >> assume that the receiving side is capable of handling the PPP default >> MRU of 1500. To ensure compatability with older equipment, if the >> >> > >As above, I believe that breaks compatibility. The default has to be >1492. > > > >> sending side is assigning an MRU greater than 1492 to the receiving >> side, (either by default, or through negotiation), it is RECOMMENDED >> that the sending side send one or more MRU-sized Echo-Request packets >> once the session is opened, to test that the receiving side and any >> intermediate equipment can handle the MRU. If no Echo-Replies are >> >> > >I think that a procedure like that is a *requirement*, not just a >recommendation. The problem is that there simply is no way for any >PPPoE implementation to know whether the intermediate devices (which >may include switches that add and remove VLAN tags) support an actual >MTU of 1508. There's just no way to know that what's being negotiated >is at all reasonable. > > > >> received, the sending side MAY choose to repeat the test with >> Echo-Request packets of size 1492. If these packets receive replies, >> the sending side MAY choose to treat the receiver as if it had >> explicitly specified an MRU of 1492. >> >> > >I think that's ambiguous. It should probably restart LCP instead. > > > _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Sun Jan 30 13:21:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21772 for ; Sun, 30 Jan 2005 13:21:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvJyq-0006fv-Ed for pppext-web-archive@ietf.org; Sun, 30 Jan 2005 13:39:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvJdQ-0001TP-Rq; Sun, 30 Jan 2005 13:17:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cv6ak-0008EV-F8 for pppext@megatron.ietf.org; Sat, 29 Jan 2005 23:21:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12577 for ; Sat, 29 Jan 2005 23:21:39 -0500 (EST) Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cv6sO-0003Wm-S3 for pppext@ietf.org; Sat, 29 Jan 2005 23:39:58 -0500 Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.1/8.13.1) id j0U4L9t8016465 for pppext@ietf.org env-from ; Sat, 29 Jan 2005 21:21:09 -0700 (MST) Date: Sat, 29 Jan 2005 21:21:09 -0700 (MST) From: Vernon Schryver Message-Id: <200501300421.j0U4L9t8016465@calcite.rhyolite.com> To: pppext@ietf.org Subject: Re: [Pppext] I-D ACTION:draft-ietf-pppext-pppoe-mtu-1500-00.txt References: <41FC5916.9030501@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-Mailman-Approved-At: Sun, 30 Jan 2005 13:17:19 -0500 X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa > From: Bo Berry > Agree with the interoperability concerns brought forth > by J. Carlson. This is a real problem. Also performance > gain from 1492 to 1500 in the scheme of things is negligible. except when the PPPoE link is not directly connected to the sending host and you get the problems of IP fragmentation or except when path MTU discovery is used and something doesn't generate or filters ICMP messages, and you get intermittent blackholes > If you are really set on gaining 8-bytes, consider defining > optional tags to negotiate the extended/longer MTU. This > method would be backward compatible. What is an "optional tag"? I kind of understand various PPP Configure-Request options, but they are not what I'd call tags. As James Carlson wrote, the IETF seems an unlikely forum for modifying IEEE standards. Is there no way to use the LCP MR option to negotiate an effective MTU of 1500 on media that differs from classic IEE 802.3 by having a data size of 1508 or larger? Why can't an advanced PPPoE box offer an MRU of 1508 or ask for an MTU of 1508 using a Configure-Nak? The PPPoE 8 byte overhead hassle is far from unique in the PPP world. MP (multilink) and CCP (compression) are two common examples. For that matter, why couldn't advanced PPPoE boxes use PPP MP fragmentation much as other PPP boxes handle the CCP and MP headers? > Another suggestion > is to publish as an Informational RFC. Whether the proposal RFC is Informational or on the standards track would not affect the interoperability problems. Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Jan 31 10:09:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09944 for ; Mon, 31 Jan 2005 10:09:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvdTK-0005gE-B3 for pppext-web-archive@ietf.org; Mon, 31 Jan 2005 10:28:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvd4O-00080t-Bv; Mon, 31 Jan 2005 10:02:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvczC-00071F-B2 for pppext@megatron.ietf.org; Mon, 31 Jan 2005 09:57:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08550 for ; Mon, 31 Jan 2005 09:57:04 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvdH9-0005O8-R3 for pppext@ietf.org; Mon, 31 Jan 2005 10:15:40 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 31 Jan 2005 10:06:14 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from [64.102.54.244] (dhcp-64-102-54-244.cisco.com [64.102.54.244]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0VEuVoA000124; Mon, 31 Jan 2005 09:56:32 -0500 (EST) Message-ID: <41FE471D.6010602@cisco.com> Date: Mon, 31 Jan 2005 09:56:29 -0500 From: Bo Berry User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vernon Schryver Subject: Re: [Pppext] I-D ACTION:draft-ietf-pppext-pppoe-mtu-1500-00.txt References: <41FC5916.9030501@cisco.com> <200501300421.j0U4L9t8016465@calcite.rhyolite.com> In-Reply-To: <200501300421.j0U4L9t8016465@calcite.rhyolite.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit Vernon According to the submitted abstract Point-to-Point Protocol Over Ethernet, (PPPoE), as described in RFC 2516, mandates a maximum negotiated MRU of 1492. This memo proposes relaxing that restriction to allow a maximum negotiated MRU of 1500. This can be achieved by treating the PPPoE Header and Protocol ID as part of the Ethernet Header, taking advantage of the fact that most network devices have buffers for the Ethernet Header and Payload that are at least 1522 octets in size. To aid backward compatability, the proposal recommends testing the link with MRU-sized Echo-Request packets if an MRU greater than 1492 has been assumed or negotiated. this is PPPoE related, not PPP. PPPoE, RFC2516, includes a provision for optional tags RFC 2516 Transmitting PPP Over Ethernet February 1999 The PPPoE payload contains zero or more TAGs. A TAG is a TLV (type- length-value) construct and is defined as follows: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TAG_TYPE | TAG_LENGTH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TAG_VALUE ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TAG_TYPE is a sixteen bit field in network byte order. Appendix A contains a list of all TAG_TYPEs and their TAG_VALUEs. TAG_LENGTH is a sixteen bit field. It is an unsigned number in network byte order, indicating the length in octets of the TAG_VALUE. If a discovery packet is received with a TAG of unknown TAG_TYPE, the TAG MUST be ignored unless otherwise specified in this document. This provides for backwards compatibility if/when new TAGs are added. If new mandatory TAGs are added, the version number will be incremented. Agree, IETF is not the place to redefine IEEE stds. -Bo Berry bberry@cisco.com Vernon Schryver wrote: >>From: Bo Berry >> >> > > > >>Agree with the interoperability concerns brought forth >>by J. Carlson. This is a real problem. Also performance >>gain from 1492 to 1500 in the scheme of things is negligible. >> >> > >except when the PPPoE link is not directly connected to the sending host >and you get the problems of IP fragmentation > >or except when path MTU discovery is used and something doesn't >generate or filters ICMP messages, and you get intermittent blackholes > > > > >>If you are really set on gaining 8-bytes, consider defining >>optional tags to negotiate the extended/longer MTU. This >>method would be backward compatible. >> >> > >What is an "optional tag"? I kind of understand various PPP >Configure-Request options, but they are not what I'd call tags. As >James Carlson wrote, the IETF seems an unlikely forum for modifying >IEEE standards. > >Is there no way to use the LCP MR option to negotiate an effective MTU >of 1500 on media that differs from classic IEE 802.3 by having a data >size of 1508 or larger? Why can't an advanced PPPoE box offer an MRU >of 1508 or ask for an MTU of 1508 using a Configure-Nak? > >The PPPoE 8 byte overhead hassle is far from unique in the PPP world. >MP (multilink) and CCP (compression) are two common examples. For >that matter, why couldn't advanced PPPoE boxes use PPP MP fragmentation >much as other PPP boxes handle the CCP and MP headers? > > > > >> Another suggestion >>is to publish as an Informational RFC. >> >> > >Whether the proposal RFC is Informational or on the standards track >would not affect the interoperability problems. > > >Vernon Schryver vjs@rhyolite.com > >_______________________________________________ >Pppext mailing list >Pppext@ietf.org >https://www1.ietf.org/mailman/listinfo/pppext > > > -- Warning: This document contains technical data whose export is restricted by the Arms Export Control Act (Title 22, U.S.C., Sec 2751, et seq.) or the Export Administration Act of 1979, as amended (Title 50, U.S.C., App. 2401 et seq.). Violations of these export laws are subject to severe criminal penalties. _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext