From pppext-bounces@ietf.org Wed Feb 2 14:08:09 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 OAA15067 for ; Wed, 2 Feb 2005 14:08:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwQ9j-0001ns-76 for pppext-web-archive@ietf.org; Wed, 02 Feb 2005 14:27:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwPlz-0005Jr-Rq; Wed, 02 Feb 2005 14:02:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwPfs-0003il-Rt for pppext@megatron.ietf.org; Wed, 02 Feb 2005 13:56:28 -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 NAA13687 for ; Wed, 2 Feb 2005 13:56:21 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwPyH-0001Qz-QY for pppext@ietf.org; Wed, 02 Feb 2005 14:15:27 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 02 Feb 2005 14:05:56 -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-1.cisco.com (8.12.10/8.12.6) with ESMTP id j12ItljZ014189; Wed, 2 Feb 2005 13:55:51 -0500 (EST) Message-ID: <42012232.3020708@cisco.com> Date: Wed, 02 Feb 2005 13:55:46 -0500 From: Bo Berry User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: fitz@jfitz.com, pppext@ietf.org Subject: [Fwd: Re: [Pppext] I-D ACTION:draft-ietf-pppext-pppoe-mtu-1500-00.txt] 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: ea4ac80f790299f943f0a53be7e1a21a 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: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit John: Sorry if I have missed an email. What are your plans for the submitted draft given the expressed concerns on interoperability. compatability and its relationship to IEEE standards. Thanks -Bo Berry 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. _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Feb 3 14:47:34 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 OAA00441 for ; Thu, 3 Feb 2005 14:47:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwnFa-0001lX-6S for pppext-web-archive@ietf.org; Thu, 03 Feb 2005 15:06:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwmrJ-0005Hh-24; Thu, 03 Feb 2005 14:41:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwmIt-0005M9-8l for pppext@megatron.ietf.org; Thu, 03 Feb 2005 14:06:11 -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 OAA27008 for ; Thu, 3 Feb 2005 14:06:09 -0500 (EST) Received: from adsl-64-164-136-70.dsl.snfc21.pacbell.net ([64.164.136.70] helo=jfitz.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CwmbU-0000aY-TM for pppext@ietf.org; Thu, 03 Feb 2005 14:25:25 -0500 Received: (qmail 95213 invoked from network); 3 Feb 2005 19:06:01 -0000 Received: from localhost.jfitz.com (HELO adsl-69-233-182-146.dsl.pltn13.pacbell.net) (127.0.0.1) by localhost.jfitz.com with SMTP; 3 Feb 2005 19:05:59 -0000 Content-Type: text/plain; charset="iso-8859-1" From: John Fitzgibbon To: Bo Berry Subject: Re: [Pppext] I-D ACTION:draft-ietf-pppext-pppoe-mtu-1500-00.txt Date: Thu, 3 Feb 2005 11:05:59 -0800 User-Agent: KMail/1.4.3 References: <42012232.3020708@cisco.com> In-Reply-To: <42012232.3020708@cisco.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200502031105.59849.fitz@jfitz.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 03 Feb 2005 14:41:40 -0500 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: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 8bit > Sorry if I have missed an email. What are your > plans for the submitted draft given the expressed > concerns on interoperability. compatability > and its relationship to IEEE standards. Bo, No, you haven't missed any emails -- I just hadn't noticed that the draft was posted. Looking at the comments: 1) I like the idea of an optional tag -- that's better than negotiating an MRU that could break backwards compatability. 2) I also agree that it would be better to restart LCP if MRU-sized Echo-Requests go unanswered, (rather than trying to renegotiate). 3) I understand the concern that allowing for a PPPoE header in the frame is an IEEE issue, but, frankly, I don't want the hassle of taking this to IEEE. 4) It is entirely appropriate that anything suggested should be an informational RFC at best -- I confess I missed the fact that PPPoE is itself informational. I'll try to revise the proposal to reflect these observations and resubmit -- even if the result is informational and/or "non-IETF", I value the feedback. A question: is this a suitable forum for allocating a new tag? Some background on my rationale: This is a real problem for me, and it's not performance related -- I have residential DSL service and my provider, SBC, only offer PPPoE, (and they seem *very* reluctant to change). Since I write network test software, the lack of transparency resulting from an MTU of 1492 causes me some headaches. Given that I'm reasonably sure the hardware is capable of handling a 1500 byte MTU, the PPPoE limit seems overly restrictive. My thinking was that if I couldn't change SBC, I'd try to change PPPoE. Upon investigation, (google), it turned out that I was not alone -- many people have reported problems arising out of the widespread use of PPPoE by broadband providers. Presumably, there are many, many more who simply aren't aware that certain relatively obscure connectivity issues may be related to the PPPoE link to their service provider. Thanks to all for the feedback, John Fitzgibbon _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Feb 3 15:14:37 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 PAA03587 for ; Thu, 3 Feb 2005 15:14:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwnfl-0002c2-IH for pppext-web-archive@ietf.org; Thu, 03 Feb 2005 15:33:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwnFE-0005dO-MJ; Thu, 03 Feb 2005 15:06:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwnBI-00038i-R6 for pppext@megatron.ietf.org; Thu, 03 Feb 2005 15:02:29 -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 PAA01925 for ; Thu, 3 Feb 2005 15:02:22 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwnTu-0002GG-0m for pppext@ietf.org; Thu, 03 Feb 2005 15:21:39 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j13K2Kpv016345 for ; Thu, 3 Feb 2005 12:02:20 -0800 (PST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j13K2JOp003080 for ; Thu, 3 Feb 2005 15:02:19 -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 j13K2JTD026998; Thu, 3 Feb 2005 15:02:19 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.2+Sun/8.13.2/Submit) id j13K2Jh7026995; Thu, 3 Feb 2005 15:02:19 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16898.33611.747767.115482@gargle.gargle.HOWL> Date: Thu, 3 Feb 2005 15:02:19 -0500 From: James Carlson To: John Fitzgibbon Subject: Re: [Pppext] I-D ACTION:draft-ietf-pppext-pppoe-mtu-1500-00.txt In-Reply-To: John Fitzgibbon's message of 3 February 2005 11:05:59 References: <42012232.3020708@cisco.com> <200502031105.59849.fitz@jfitz.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit John Fitzgibbon writes: > 3) I understand the concern that allowing for a PPPoE header in the frame is > an IEEE issue, but, frankly, I don't want the hassle of taking this to IEEE. That doesn't quite sound right to me. I don't think the IETF should be in the business of approving extensions to IEEE protocols any more than the IEEE should extend things done in the IETF. I don't think that ETOOHARD is a good answer here. > A question: is this a suitable forum for allocating a new tag? Since the original PPPoE documents were (I believe!) written in the ADSL Forum and then submitted as individual submissions and published as RFCs without (substantial) IETF working group review, I'd guess that ADSL Forum (if it's still active) would probably be more interested, but that publishing as an RFC wouldn't be entirely wrong. (Ignoring for the moment my concerns about extending protocols that are already in conflict with the IETF's stated architectural direction, namely L2TP.) > Some background on my rationale: > > This is a real problem for me, and it's not performance related -- I have > residential DSL service and my provider, SBC, only offer PPPoE, (and they > seem *very* reluctant to change). Since I write network test software, the > lack of transparency resulting from an MTU of 1492 causes me some headaches. Right. A lot of people are in that same boat. Running plain old IP over Ethernet and using DHCP for both address assignment and accounting, rather than resorting to tunneling IP over PPP over PPPoE over Ethernet over ATM over DSL, might have been a better idea. > Given that I'm reasonably sure the hardware is capable of handling a 1500 > byte MTU, the PPPoE limit seems overly restrictive. My thinking was that if I > couldn't change SBC, I'd try to change PPPoE. Their equipment, as I understand it, terminates your DSL link and sends the ATM directly to your ISP. There it should hit an Ethernet- over-ATM bridge and end up in some kind of PPPoE concentrator. What's your plan for upgrading your ISP's equipment to handle the new oversize frames? > Upon investigation, (google), > it turned out that I was not alone -- many people have reported problems > arising out of the widespread use of PPPoE by broadband providers. Indeed. It's a widespread problem with PPPoE. There might be other options. > Presumably, there are many, many more who simply aren't aware that certain > relatively obscure connectivity issues may be related to the PPPoE link to > their service provider. What about Vern Schryver's suggestion that you use RFC 1990 MP with a single link instead? Doing so would not involve inventing any new protocols, and would involve changing fewer of the boxes in the picture. Just your system and the ISP's concentrator would need standard Multilink PPP support. It's possible that at least one of these already supports it. -- 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 Thu Feb 3 15:34: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 PAA05762 for ; Thu, 3 Feb 2005 15:34:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwnyd-0003CR-Ot for pppext-web-archive@ietf.org; Thu, 03 Feb 2005 15:53:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwnes-00036Q-Ne; Thu, 03 Feb 2005 15:32:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwnaE-0002v6-6M for pppext@megatron.ietf.org; Thu, 03 Feb 2005 15:28:10 -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 PAA05343 for ; Thu, 3 Feb 2005 15:28:08 -0500 (EST) Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwnsq-00031H-B5 for pppext@ietf.org; Thu, 03 Feb 2005 15:47:25 -0500 Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.1/8.13.1) id j13KRbgd017109 for pppext@ietf.org env-from ; Thu, 3 Feb 2005 13:27:37 -0700 (MST) Date: Thu, 3 Feb 2005 13:27:37 -0700 (MST) From: Vernon Schryver Message-Id: <200502032027.j13KRbgd017109@calcite.rhyolite.com> To: pppext@ietf.org Subject: Re: [Pppext] I-D ACTION:draft-ietf-pppext-pppoe-mtu-1500-00.txt References: <200502031105.59849.fitz@jfitz.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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: 7baded97d9887f7a0c7e8a33c2e3ea1b > From: John Fitzgibbon > This is a real problem for me, and it's not performance related -- I have > residential DSL service and my provider, SBC, only offer PPPoE, (and they > seem *very* reluctant to change). Since I write network test software, the > lack of transparency resulting from an MTU of 1492 causes me some headaches. > Given that I'm reasonably sure the hardware is capable of handling a 1500 > byte MTU, the PPPoE limit seems overly restrictive. My thinking was that if I > couldn't change SBC, I'd try to change PPPoE. Why won't SBC need to change software, firmware or software at their end to understand new PPPoE tags? Is there some evidence that SBC's end of your DSL link will pass frames with 1500 bytes of IP data over the DSL link to your equipment? For example, have you tried sending UDP or ICMP packets with the DF bit set toward your home system to see if and where IP fragmentation happens? What CPE do you have that will generate or accept new IEEE tags? Will it send or accept frames containing 1500 bytes of IP data? If not, do you have firmware or software source for it so that you can fix it? Why isn't this effort too little too late? PPPoE is an incredibly nasty, amazingly ill considered kludge, but by the time it came to the IETF, it seened to be set in concrete. In many markets there are DSL providers that allow or even require PPPoA instead of PPPoE. Their services tend to cost more than what you get from the ILEX, but I think you rarely get more value than what you pay for. My DSL link uses PPPoA and handles 1500 byte IP packets. Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Feb 3 18:09:40 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 SAA04213 for ; Thu, 3 Feb 2005 18:09:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwqPC-0003On-Ul for pppext-web-archive@ietf.org; Thu, 03 Feb 2005 18:29:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwpvR-0002B1-PK; Thu, 03 Feb 2005 17:58:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwpp8-0007LV-Co for pppext@megatron.ietf.org; Thu, 03 Feb 2005 17:51: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 RAA02286 for ; Thu, 3 Feb 2005 17:51:39 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwq7m-0002uV-3V for pppext@ietf.org; Thu, 03 Feb 2005 18:10:59 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 03 Feb 2005 17:51:11 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from [10.82.216.88] (rtp-vpn3-88.cisco.com [10.82.216.88]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j13Mp4jZ029017; Thu, 3 Feb 2005 17:51:07 -0500 (EST) Message-ID: <4202AAD8.2060900@cisco.com> Date: Thu, 03 Feb 2005 17:51:04 -0500 From: Bo Berry User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Fitzgibbon Subject: Re: [Pppext] I-D ACTION:draft-ietf-pppext-pppoe-mtu-1500-00.txt References: <42012232.3020708@cisco.com> <200502031105.59849.fitz@jfitz.com> In-Reply-To: <200502031105.59849.fitz@jfitz.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: 00e94c813bef7832af255170dca19e36 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: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit John: Few comments (to follow suit of Vernon and James) -Bo John Fitzgibbon wrote: >>Sorry if I have missed an email. What are your >>plans for the submitted draft given the expressed >>concerns on interoperability. compatability >>and its relationship to IEEE standards. >> >> > >Bo, >No, you haven't missed any emails -- I just hadn't noticed that the draft was >posted. > >Looking at the comments: >1) I like the idea of an optional tag -- that's better than negotiating an MRU >that could break backwards compatability. > > Good, Breaking things is not allowed >2) I also agree that it would be better to restart LCP if MRU-sized >Echo-Requests go unanswered, (rather than trying to renegotiate). >3) I understand the concern that allowing for a PPPoE header in the frame is >an IEEE issue, but, frankly, I don't want the hassle of taking this to IEEE. > 4) It is entirely appropriate that anything suggested should be an >informational RFC at best -- I confess I missed the fact that PPPoE is itself >informational. > >I'll try to revise the proposal to reflect these observations and resubmit -- >even if the result is informational and/or "non-IETF", I value the feedback. > >A question: is this a suitable forum for allocating a new tag? > > for PPPoE tags, yes >Some background on my rationale: > > > If SBC does not sign up to make the corresponding PPPoE changes, you are still stuck. Given that they are reluctant, you better be sure they will make the changes. Suggest you ask about cost and schedule. It may be wise to review the google based 'marketing assessment' with ISPs, such as SBC, to determine if this really has market value and justifies the effort. >This is a real problem for me, and it's not performance related -- I have >residential DSL service and my provider, SBC, only offer PPPoE, (and they >seem *very* reluctant to change). Since I write network test software, the >lack of transparency resulting from an MTU of 1492 causes me some headaches. >Given that I'm reasonably sure the hardware is capable of handling a 1500 >byte MTU, the PPPoE limit seems overly restrictive. My thinking was that if I >couldn't change SBC, I'd try to change PPPoE. Upon investigation, (google), >it turned out that I was not alone -- many people have reported problems >arising out of the widespread use of PPPoE by broadband providers. >Presumably, there are many, many more who simply aren't aware that certain >relatively obscure connectivity issues may be related to the PPPoE link to >their service provider. > >Thanks to all for the feedback, >John Fitzgibbon > > > _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext