From pppext-bounces@ietf.org Mon May 16 09:33:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXfiY-0001Ia-Hb; Mon, 16 May 2005 09:33:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXfiW-0001IV-T3 for pppext@megatron.ietf.org; Mon, 16 May 2005 09:33:09 -0400 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 JAA11283 for ; Mon, 16 May 2005 09:33:04 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXfz1-0003zr-GC for pppext@ietf.org; Mon, 16 May 2005 09:50:13 -0400 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j4GDX30R011325 for ; Mon, 16 May 2005 07:33:03 -0600 (MDT) 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 j4GDX2Op004463 for ; Mon, 16 May 2005 09:33:03 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id j4GDX2PG021995 for ; Mon, 16 May 2005 09:33:02 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j4GDX2Uc021992; Mon, 16 May 2005 09:33:02 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17032.41230.705099.235432@gargle.gargle.HOWL> Date: Mon, 16 May 2005 09:33:02 -0400 From: James Carlson To: pppext@ietf.org X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Subject: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 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 I have a few questions and comments on this draft: - In the scenario identified as "Fig. 3" (PPPoA to PPPoE conversion), why wouldn't the device labeled "DSLAM" in that picture just alter the LCP negotiation messages in flight, so that if the PPPoA side attempts anything over 1492, the MRU is just negotiated downwards as necessary? - Why is the "recommended" Echo-Request probing mechanism -- the only thing other than LLDP that can deal with L2 MTU issues -- disabled by default? Isn't that just asking for trouble? (I can see why an implementation might want to have an option to disable this feature, but why would that necessarily be the default?) - Why is the action on failure of Echo-Request just to assume a different peer MRU? I'd expect that a better way to deal with this would be to renegotiate LCP, and make sure that the MRU is lowered in both directions. (It may well be the case that only one end notices the problem.) - What does the interoperability picture look like? Are there deployed implementations that attempt to negotiate an MRU of 1500, and is this commonly ignored on PPPoE links? (I suspect that the answers here are "yes" and "yes" -- meaning that changing the behavior of MRU negotiation on PPPoE, which previously had a hard cap at 1492, will likely break existing implementations, unless some mitigating feature is included by default.) -- James Carlson, KISS Network 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 Wed May 18 22:40:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYax8-0007Mf-Bg; Wed, 18 May 2005 22:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYax6-0007Lk-1A for pppext@megatron.ietf.org; Wed, 18 May 2005 22:40:00 -0400 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 WAA19942 for ; Wed, 18 May 2005 22:39:57 -0400 (EDT) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYbEA-0001zQ-A5 for pppext@ietf.org; Wed, 18 May 2005 22:57:38 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id DAA4410EAB91; Wed, 18 May 2005 19:39:41 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03697-04; Wed, 18 May 2005 19:39:41 -0700 (PDT) Received: from PARBETM2XP (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id B8EF010EAB8E; Wed, 18 May 2005 19:39:39 -0700 (PDT) From: "Peter Arberg" To: "'James Carlson'" , Subject: RE: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 Date: Wed, 18 May 2005 22:39:35 -0400 Organization: Redback Networks MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVaHDEkOnrXLoFrS5y/9tED0y1+bgB/jhHQ In-Reply-To: <17032.41230.705099.235432@gargle.gargle.HOWL> Message-Id: <20050519023939.B8EF010EAB8E@prattle.redback.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: parberg@redback.com List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org James, Thanks for your interest in the internet-draft, I have tried to answer your questions inline in the email. > I have a few questions and comments on this draft: > > - In the scenario identified as "Fig. 3" (PPPoA to PPPoE > conversion), why wouldn't the device labeled "DSLAM" in that > picture just alter the LCP negotiation messages in flight, so that > if the PPPoA side attempts anything over 1492, the MRU is just > negotiated downwards as necessary? The intention discussed in DSL Forum at the moment is that the DSLAM only initiate the PPPoE session, and not alter the actual PPP or LCP packets. I guess that it would be doable for the DSLAM to alter the LCP packets in flight, but if the main concern here is that some existing PPPoA client will not accept a smaller MRU than 1500 bytes, then the fact that the DSLAM will downsize the MRU, will leave a PPP session with 2 end-points having a wrong view of the other end-points MRU, and as such this will either result in no connection, or the DSLAM having to perform PPP packet fragmentation, as I see it ? > - Why is the "recommended" Echo-Request probing mechanism -- the > only thing other than LLDP that can deal with L2 MTU issues -- > disabled by default? Isn't that just asking for trouble? (I can > see why an implementation might want to have an option to disable > this feature, but why would that necessarily be the default?) The reason for disabling this functionality by default, is because the PPPoE client and server must work in a backward compatible setup by default, and as such it is anticipated that an active configuration of both the RG client and the BRAS PPPoE server is needed for them to suggest and accept a MRU greater than 1492. When such an active configuration is needed to make PPPoE MRU higher than 1492, it is expected that Service Providers know their network well enough to only turn on this functionality when the intermediate systems support Ethernet MTU higher than 1500 bytes. By disabling this functionality, we are saying that PPP session setup time is more important than a per session setup security check, BUT at the same time we agree that a troubleshooting functionality is needed in case end-to-end connectivity can not be established. > - Why is the action on failure of Echo-Request just to assume a > different peer MRU? I'd expect that a better way to deal with > this would be to renegotiate LCP, and make sure that the MRU is > lowered in both directions. (It may well be the case that only > one end notices the problem.) That is a good suggestion, so do you suggest that it still test the link with 1492 byte packets before initiate a MRU renegotiation ? Our concern was the danger of PPP client implementations might have trouble with renegotiation of one or more layers, but you are right in the scenario where only end notice the problem, then our suggestion will not correct this, so initiating a new LCP negotiation for MRU 1492 will be the right thing. > - What does the interoperability picture look like? Are there > deployed implementations that attempt to negotiate an MRU of 1500, > and is this commonly ignored on PPPoE links? (I suspect that the > answers here are "yes" and "yes" -- meaning that changing the > behavior of MRU negotiation on PPPoE, which previously had a hard > cap at 1492, will likely break existing implementations, unless > some mitigating feature is included by default.) I expect that there already are systems out there that will try and initiate a 1500 byte MRU, but I do not know of any production code doing so. By testing some existing RG PPPoE clients and some BRAS PPPoE Servers, it has shown different behavior from NAK greater MRU to silently ignoring it, but so far with the limited test we have done, we have not seen any catastrophic behavior. cheers, Peter -------------------------------------- Peter Arberg Redback Networks office: 1 (408)750 5423 email: parberg@redback.com Web: http://www.redback.com/ -------------------------------------- > > -- > James Carlson, KISS Network > > 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 > _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Sat May 21 17:53:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZbuv-0002EP-BE; Sat, 21 May 2005 17:53:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZbut-0002EG-Bi for pppext@megatron.ietf.org; Sat, 21 May 2005 17:53:55 -0400 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 RAA01082 for ; Sat, 21 May 2005 17:53:52 -0400 (EDT) Received: from [209.234.107.227] (helo=hardcoder.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZcCW-0001Vx-4i for pppext@ietf.org; Sat, 21 May 2005 18:12:09 -0400 Received: from [209.234.107.234] ([209.234.107.234]) by hardcoder.com (8.13.3/8.13.3) with ESMTP id j4LLrlXh008118; Sat, 21 May 2005 14:53:48 -0700 Date: Sat, 21 May 2005 14:53:37 -0700 From: Frank Cusack To: parberg@redback.com Subject: RE: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 Message-ID: <1CD7F4388A1997FF878444CB@manatee.local> In-Reply-To: <20050519023939.B8EF010EAB8E@prattle.redback.com> References: <20050519023939.B8EF010EAB8E@prattle.redback.com> X-Mailer: Mulberry/4.0.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 required=1.7 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on athena X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org, 'James Carlson' 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 Just chiming in ... On May 18, 2005 10:39:35 PM -0400 Peter Arberg wrote: >> - In the scenario identified as "Fig. 3" (PPPoA to PPPoE >> conversion), why wouldn't the device labeled "DSLAM" in that >> picture just alter the LCP negotiation messages in flight, so that >> if the PPPoA side attempts anything over 1492, the MRU is just >> negotiated downwards as necessary? > > > The intention discussed in DSL Forum at the moment is that the DSLAM > only initiate the PPPoE session, and not alter the actual PPP or LCP > packets. > > I guess that it would be doable for the DSLAM to alter the LCP packets > in flight, but if the main concern here is that some existing PPPoA > client will not accept a smaller MRU than 1500 bytes, then the fact > that the DSLAM will downsize the MRU, will leave a PPP session with > 2 end-points having a wrong view of the other end-points MRU, and as such > this will either result in no connection, or the DSLAM having to perform > PPP packet fragmentation, as I see it ? And how would the DSLAM be able to fragment? (It couldn't, AFAIK, in a pass- through scenario.) If the two peers had an incorrect idea of the other's actual MRU, this doesn't matter because the incorrect MRU would be *smaller* than the actual MRU and so all transmitted packets would be acceptable. Is it broken for PPPoA clients to not accept small MRUs? /fc _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext