From pppext-bounces@ietf.org Thu Feb 16 10:38:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9lDY-0004yQ-2a; Thu, 16 Feb 2006 10:38:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9lDX-0004y3-Kv; Thu, 16 Feb 2006 10:38:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04236; Thu, 16 Feb 2006 10:37:03 -0500 (EST) Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9lRm-0001qN-9S; Thu, 16 Feb 2006 10:53:35 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k1GFcfvP021813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 Feb 2006 15:38:41 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1F9lDN-0003AG-9f; Thu, 16 Feb 2006 10:38:41 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 16 Feb 2006 10:38:41 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: pppext@ietf.org Subject: [Pppext] Last Call: 'Accommodating an MTU/MRU greater than 1492 in PPPoE' to Informational RFC X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org The IESG has received a request from the Point-to-Point Protocol Extensions WG to consider the following document: - 'Accommodating an MTU/MRU greater than 1492 in PPPoE ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-03-02. The file can be obtained via http://www.ietf.org/internet-drafts/draft-arberg-pppoe-mtu-gt1492-02.txt _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Feb 17 16:27:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAD8I-0000i4-Ol; Fri, 17 Feb 2006 16:27:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FACWh-0005az-S7; Fri, 17 Feb 2006 15:48:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03409; Fri, 17 Feb 2006 15:46:39 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FACl9-00084T-9A; Fri, 17 Feb 2006 16:03:24 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k1HKmAHa007880; Fri, 17 Feb 2006 22:48:10 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k1HKmABU007877; Fri, 17 Feb 2006 22:48:10 +0200 Date: Fri, 17 Feb 2006 22:48:10 +0200 (EET) From: Pekka Savola To: iesg@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88/1291/Thu Feb 16 22:15:09 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_20 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 X-Mailman-Approved-At: Fri, 17 Feb 2006 16:27:17 -0500 Cc: pppext@ietf.org, ietf@ietf.org Subject: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than 1492 in PPPoE' to Informational RFC 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 On Thu, 16 Feb 2006, The IESG wrote: > The IESG has received a request from the Point-to-Point Protocol > Extensions WG to consider the following document: > > - 'Accommodating an MTU/MRU greater than 1492 in PPPoE ' > as an Informational RFC I think this is addressing one of operationally important aspects, but I'm not so sure about a couple of particular design decisions made, and would like to see them justified (or points to earlier discussions) or changed. major discussion points ----------------------- 1) This doc seems to define a PPPoE option 'PPP-Max-Payload'. It talks of using PPP MRU option. There is no PPP MTU option that I could see. My question here is, should there be a PPP MTU option instead of a PPPoE option? This would be a more generic solution to this part of the problem, and would also apply in non-PPPoE scenarios for signalling MTU. Am I missing something ? 2) MRU test procedure using MRU-sized Echo-Requests is disabled by default and to be used for debug purposes only. I'm questioning whether this is wise. The protocol would be much more robust against errors if it always used, once, during the PPP set-up, one roundtrip of MRU-sized packets. This is not a bandwidth issue, because we're talking about fast DSL networks or Gigabit Ethernet. This ensure that the higher MTU is actually supported and actually works as well (e.g., someone hadn't turned off jumbo frames). So I'd argue it might make sense to put sending/receiving MRU-sized packets (e.g., some padding) right into the negotiation phase. substantial comments -------------------- ==> first off, a major clarification request: RFC1661 does not mention 'MTU' anywhere, <-------------- PPPoA -------------> <- PPPoE session -> +-----+ +-----+ +--+ +---+ | | | | |PC|--------------|CPE|------------|DSLAM|------------| BRAS| +--+ +---+ | | | | +-----+ +-----+ Fig. 3: Broadband network designs with PPPoA to PPPoE conversion. ==> surely the part between PC and CPE should be something else? It's difficult to believe someone would be considering developing a new PPPoA mechanism which would require deploying ATM on the PCs :-) This requires some tweaking to the figure and text. Since next generation broadband networks are built around Ethernet systems supporting baby-giants and jumbo frames with payload sizes larger than the normal Ethernet MTU of 1500 octets, a BRAS acting as a PPPoE server MUST support PPPoE MRU negotiations larger than 1492 bytes in order to limit the amount of fragmented packets in network designs shown in section 1. 5.1 MRU Negotiations ==> this is a very confusing section. It seems you're saying almost the same things about 3 times: at PPPoE pseudo-code, after that in a very confusing explanation of the pseudo-code, and then at the summary of the behaviour. As these use slightly different terms, this left me uncertain of what the actual behaviour is. This section needs a rewrite to remove duplication of specification and to make it clearer. mostly editorial ---------------- ==> This has over half a dozen ID-nits, many of them blocking: http://tools.ietf.org/wg/pppext/draft-arberg-pppoe-mtu-gt1492/draft-arberg-pppoe-mtu-gt1492-02.nits.txt ==> no refs in the abtract In the network design shown in figure 1, fragmentation is typically not a problem since the subscriber session is PPPoE end-to-end from the PC to the BRAS, so a PPP negotiated MRU of 1492 bytes is fully acceptable as it makes the largest PPPoE frame adhere to the standard Ethernet MTU of 1500 bytes. ==> well, there is ample evidence that fragmentation is a problem here as well (due to broken firewalls dropping ICMP errors that BRAS'es send), but the text is protocol-wise correct. Maybe reword to describe the problem, to something like: In the network design shown in figure 1, fragmentation is typically unavoidable since the subscriber session is PPPoE end-to-end from the PC to the BRAS, and the standard Ethernet MTU of 1500 sets the limit of the frames to 1492 octets. As this causes issues with e.g., Path MTU Discovery, it would be desirable to be able to raise the maximum PPP payload size to at least 1500 octets. ..... In the network design shown in figure 2, fragmentation becomes a major problem since the subscriber session is a combination of IPoE and PPPoE. The IPoE typically negotiates a MTU of 1500 bytes. ==> the last sentence is misleading: IP over Ethernet does not 'negotiate' anything. You use the default 1500, or you manually configure both ends. Slight reword needed. If (PPP-Max-Payload-Tag) Not Present Then PPP_MRU_Max = 1492 Else PPP_MRU_Max = min (PPP-Max-Payload-Tag, Interface MTU-8) ==> for clarity, I'd move 'Else ...' indentation left by two spaces. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Feb 17 16:38:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FADJ4-0004au-8k; Fri, 17 Feb 2006 16:38:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FADJ2-0004Zy-Jh; Fri, 17 Feb 2006 16:38:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15488; Fri, 17 Feb 2006 16:36:35 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FADXV-0003xk-Az; Fri, 17 Feb 2006 16:53:23 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k1HLcKdK017104; Fri, 17 Feb 2006 13:38:20 -0800 (PST) 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 k1HLcJH0027765; Fri, 17 Feb 2006 16:38:19 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k1HLcJfn004387; Fri, 17 Feb 2006 16:38:19 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k1HLcJLb004384; Fri, 17 Feb 2006 16:38:19 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17398.16971.577636.543375@gargle.gargle.HOWL> Date: Fri, 17 Feb 2006 16:38:19 -0500 From: James Carlson To: Pekka Savola Subject: Re: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than 1492 in PPPoE' to Informational RFC In-Reply-To: Pekka Savola's message of 17 February 2006 22:48:10 References: X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org, iesg@ietf.org, ietf@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 Pekka Savola writes: > This doc seems to define a PPPoE option 'PPP-Max-Payload'. It talks > of using PPP MRU option. There is no PPP MTU option that I could see. > > My question here is, should there be a PPP MTU option instead of a > PPPoE option? This would be a more generic solution to this part of I don't follow. PPP is symmetric -- there are two MRUs negotiated, one for each direction. Your peer's MRU is your maximum (and default) MTU. How could we need another option for this? Or how could one help? What's really going on here is negotiation about the existence of a usable path. Unfortunately, the underlying protocol itself (other than LLDP) doesn't provide a way to do this. This new mechanism thus doesn't solve the actual problem, but does at least allow consenting peers to identify each other. (In other words, I view it as just a boolean.) > MRU test procedure using MRU-sized Echo-Requests is disabled by > default and to be used for debug purposes only. I'm questioning > whether this is wise. The protocol would be much more robust against I don't think it is. But we did discuss that during the document review. > ==> first off, a major clarification request: RFC1661 does not > mention 'MTU' anywhere, It doesn't need to, I think. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Feb 17 16:59:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FADdv-00076R-00; Fri, 17 Feb 2006 16:59:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FADdt-00075Q-7W; Fri, 17 Feb 2006 16:59:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17496; Fri, 17 Feb 2006 16:58:08 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FADsN-00054t-Jh; Fri, 17 Feb 2006 17:14:57 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k1HLxhHa009810; Fri, 17 Feb 2006 23:59:43 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k1HLxhWV009807; Fri, 17 Feb 2006 23:59:43 +0200 Date: Fri, 17 Feb 2006 23:59:43 +0200 (EET) From: Pekka Savola To: James Carlson Subject: Re: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than 1492 in PPPoE' to Informational RFC In-Reply-To: <17398.16971.577636.543375@gargle.gargle.HOWL> Message-ID: References: <17398.16971.577636.543375@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88/1291/Thu Feb 16 22:15:09 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: pppext@ietf.org, iesg@ietf.org, ietf@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 On Fri, 17 Feb 2006, James Carlson wrote: > Pekka Savola writes: >> This doc seems to define a PPPoE option 'PPP-Max-Payload'. It talks >> of using PPP MRU option. There is no PPP MTU option that I could see. >> >> My question here is, should there be a PPP MTU option instead of a >> PPPoE option? This would be a more generic solution to this part of > > I don't follow. PPP is symmetric -- there are two MRUs negotiated, > one for each direction. Your peer's MRU is your maximum (and default) > MTU. Your peer's MRU is not directly your MTU, because the MTU could be lower as well (e.g., capped by the interface MTU). But yes -- this was mentioned in the pseudo-code. > How could we need another option for this? Or how could one help? > > What's really going on here is negotiation about the existence of a > usable path. Unfortunately, the underlying protocol itself (other > than LLDP) doesn't provide a way to do this. This new mechanism thus > doesn't solve the actual problem, but does at least allow consenting > peers to identify each other. (In other words, I view it as just a > boolean.) I guess the problem I was having here is that I didn't understand why a PPPoE MTU options would be useful (still don't). After all, if both PPP endpoins would signal MRU = 2000 (for example), then PPPoE could just use that with no need for an extra option? Looking back at the archives, it appears others have had related concerns, so I guess this is beating a dead horse.. >> MRU test procedure using MRU-sized Echo-Requests is disabled by >> default and to be used for debug purposes only. I'm questioning >> whether this is wise. The protocol would be much more robust against > > I don't think it is. But we did discuss that during the document > review. I reviewed the mailing list archives for the last 6 months, and at least during that period I didn't see this discussed. But let me qualify that. "The protocol would be more robust against ..." instead of "much more". That is at least an objective statement: as the document specifies that all PPPoE servers MUST support this mechanism, sooner or later someone is going to misconfigure too high MTU usage when jumboframes aren't enabled, or someone is going to disable jumboframes somewhere on the path. Currently there is no jumboframe spec that I'm aware of, and there is no way to recover or notice these situations that I can think of. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Sat Feb 18 11:32:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAUzv-0002D5-8P; Sat, 18 Feb 2006 11:31:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAUzt-0002Bg-4G; Sat, 18 Feb 2006 11:31:49 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAUYF-0002Vo-64; Sat, 18 Feb 2006 11:03:15 -0500 Received: from ausc60ps301.us.dell.com ([143.166.148.206]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FAT5v-0000Ke-UT; Sat, 18 Feb 2006 09:29:57 -0500 Received: from ausx3bps302.aus.amer.dell.com ([10.3.153.40]) by ausc60ps301.us.dell.com with ESMTP; 18 Feb 2006 08:29:55 -0600 X-IronPort-AV: i="4.02,126,1139205600"; d="scan'208"; a="46223495:sNHT39870292" X-SBRSIP: 132.151.6.71 X-SBRS: 0.3 X-HAT: Sender Group , Policy $ACCEPTED applied. X-MAIL-FROM: ietf-bounces@ietf.org X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAQAAA+k= X-IronPort-AV: i="4.02,124,1139205600"; d="scan'208"; a="1097597861:sNHT25408852" Date: Fri, 17 Feb 2006 22:48:10 +0200 (EET) From: Pekka Savola To: iesg@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88/1291/Thu Feb 16 22:15:09 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_20 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 17 Feb 2006 20:56:28.0796 (UTC) FILETIME=[9F8CDBC0:01C63404] X-Spam-Score: -1.9 (-) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: pppext@ietf.org, ietf@ietf.org Subject: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than 1492 in PPPoE' to Informational RFC X-BeenThere: pppext@ietf.org List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pppext-bounces@ietf.org On Thu, 16 Feb 2006, The IESG wrote: > The IESG has received a request from the Point-to-Point Protocol > Extensions WG to consider the following document: > > - 'Accommodating an MTU/MRU greater than 1492 in PPPoE ' > as an Informational RFC I think this is addressing one of operationally important aspects, but I'm not so sure about a couple of particular design decisions made, and would like to see them justified (or points to earlier discussions) or changed. major discussion points ----------------------- 1) This doc seems to define a PPPoE option 'PPP-Max-Payload'. It talks of using PPP MRU option. There is no PPP MTU option that I could see. My question here is, should there be a PPP MTU option instead of a PPPoE option? This would be a more generic solution to this part of the problem, and would also apply in non-PPPoE scenarios for signalling MTU. Am I missing something ? 2) MRU test procedure using MRU-sized Echo-Requests is disabled by default and to be used for debug purposes only. I'm questioning whether this is wise. The protocol would be much more robust against errors if it always used, once, during the PPP set-up, one roundtrip of MRU-sized packets. This is not a bandwidth issue, because we're talking about fast DSL networks or Gigabit Ethernet. This ensure that the higher MTU is actually supported and actually works as well (e.g., someone hadn't turned off jumbo frames). So I'd argue it might make sense to put sending/receiving MRU-sized packets (e.g., some padding) right into the negotiation phase. substantial comments -------------------- ==> first off, a major clarification request: RFC1661 does not mention 'MTU' anywhere, <-------------- PPPoA -------------> <- PPPoE session -> +-----+ +-----+ +--+ +---+ | | | | |PC|--------------|CPE|------------|DSLAM|------------| BRAS| +--+ +---+ | | | | +-----+ +-----+ Fig. 3: Broadband network designs with PPPoA to PPPoE conversion. ==> surely the part between PC and CPE should be something else? It's difficult to believe someone would be considering developing a new PPPoA mechanism which would require deploying ATM on the PCs :-) This requires some tweaking to the figure and text. Since next generation broadband networks are built around Ethernet systems supporting baby-giants and jumbo frames with payload sizes larger than the normal Ethernet MTU of 1500 octets, a BRAS acting as a PPPoE server MUST support PPPoE MRU negotiations larger than 1492 bytes in order to limit the amount of fragmented packets in network designs shown in section 1. 5.1 MRU Negotiations ==> this is a very confusing section. It seems you're saying almost the same things about 3 times: at PPPoE pseudo-code, after that in a very confusing explanation of the pseudo-code, and then at the summary of the behaviour. As these use slightly different terms, this left me uncertain of what the actual behaviour is. This section needs a rewrite to remove duplication of specification and to make it clearer. mostly editorial ---------------- ==> This has over half a dozen ID-nits, many of them blocking: http://tools.ietf.org/wg/pppext/draft-arberg-pppoe-mtu-gt1492/draft-arberg-pppoe-mtu-gt1492-02.nits.txt ==> no refs in the abtract In the network design shown in figure 1, fragmentation is typically not a problem since the subscriber session is PPPoE end-to-end from the PC to the BRAS, so a PPP negotiated MRU of 1492 bytes is fully acceptable as it makes the largest PPPoE frame adhere to the standard Ethernet MTU of 1500 bytes. ==> well, there is ample evidence that fragmentation is a problem here as well (due to broken firewalls dropping ICMP errors that BRAS'es send), but the text is protocol-wise correct. Maybe reword to describe the problem, to something like: In the network design shown in figure 1, fragmentation is typically unavoidable since the subscriber session is PPPoE end-to-end from the PC to the BRAS, and the standard Ethernet MTU of 1500 sets the limit of the frames to 1492 octets. As this causes issues with e.g., Path MTU Discovery, it would be desirable to be able to raise the maximum PPP payload size to at least 1500 octets. .... In the network design shown in figure 2, fragmentation becomes a major problem since the subscriber session is a combination of IPoE and PPPoE. The IPoE typically negotiates a MTU of 1500 bytes. ==> the last sentence is misleading: IP over Ethernet does not 'negotiate' anything. You use the default 1500, or you manually configure both ends. Slight reword needed. If (PPP-Max-Payload-Tag) Not Present Then PPP_MRU_Max = 1492 Else PPP_MRU_Max = min (PPP-Max-Payload-Tag, Interface MTU-8) ==> for clarity, I'd move 'Else ...' indentation left by two spaces. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Sat Feb 18 12:01:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAVSX-0002Lm-NF; Sat, 18 Feb 2006 12:01:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAUzw-0002AL-9L; Sat, 18 Feb 2006 11:31:52 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAUYF-0002Vo-Ii; Sat, 18 Feb 2006 11:03:15 -0500 Received: from ausc60ps301.us.dell.com ([143.166.148.206]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FAT5t-0000Ke-OL; Sat, 18 Feb 2006 09:29:55 -0500 Received: from ausx3bpc105.aus.amer.dell.com ([10.30.101.55]) by ausc60ps301.us.dell.com with ESMTP; 18 Feb 2006 08:29:53 -0600 X-IronPort-AV: i="4.02,126,1139205600"; d="scan'208"; a="46223455:sNHT37646368" X-SBRSIP: 132.151.6.71 X-SBRS: 0.3 X-HAT: Sender Group , Policy $ACCEPTED applied. X-MAIL-FROM: ietf-bounces@ietf.org X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAQAAA+k= X-IronPort-AV: i="4.02,124,1139205600"; d="scan'208"; a="1097623954:sNHT19343690" Date: Fri, 17 Feb 2006 23:59:43 +0200 (EET) From: Pekka Savola To: James Carlson In-Reply-To: <17398.16971.577636.543375@gargle.gargle.HOWL> Message-ID: References: <17398.16971.577636.543375@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88/1291/Thu Feb 16 22:15:09 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: Re: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than 1492 in PPPoE' to Informational RFC X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 17 Feb 2006 22:03:17.0070 (UTC) FILETIME=[F4AAEEE0:01C6340D] X-Spam-Score: -1.9 (-) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: pppext@ietf.org, iesg@ietf.org, ietf@ietf.org X-BeenThere: pppext@ietf.org List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pppext-bounces@ietf.org On Fri, 17 Feb 2006, James Carlson wrote: > Pekka Savola writes: >> This doc seems to define a PPPoE option 'PPP-Max-Payload'. It talks >> of using PPP MRU option. There is no PPP MTU option that I could see. >> >> My question here is, should there be a PPP MTU option instead of a >> PPPoE option? This would be a more generic solution to this part of > > I don't follow. PPP is symmetric -- there are two MRUs negotiated, > one for each direction. Your peer's MRU is your maximum (and default) > MTU. Your peer's MRU is not directly your MTU, because the MTU could be lower as well (e.g., capped by the interface MTU). But yes -- this was mentioned in the pseudo-code. > How could we need another option for this? Or how could one help? > > What's really going on here is negotiation about the existence of a > usable path. Unfortunately, the underlying protocol itself (other > than LLDP) doesn't provide a way to do this. This new mechanism thus > doesn't solve the actual problem, but does at least allow consenting > peers to identify each other. (In other words, I view it as just a > boolean.) I guess the problem I was having here is that I didn't understand why a PPPoE MTU options would be useful (still don't). After all, if both PPP endpoins would signal MRU = 2000 (for example), then PPPoE could just use that with no need for an extra option? Looking back at the archives, it appears others have had related concerns, so I guess this is beating a dead horse.. >> MRU test procedure using MRU-sized Echo-Requests is disabled by >> default and to be used for debug purposes only. I'm questioning >> whether this is wise. The protocol would be much more robust against > > I don't think it is. But we did discuss that during the document > review. I reviewed the mailing list archives for the last 6 months, and at least during that period I didn't see this discussed. But let me qualify that. "The protocol would be more robust against .." instead of "much more". That is at least an objective statement: as the document specifies that all PPPoE servers MUST support this mechanism, sooner or later someone is going to misconfigure too high MTU usage when jumboframes aren't enabled, or someone is going to disable jumboframes somewhere on the path. Currently there is no jumboframe spec that I'm aware of, and there is no way to recover or notice these situations that I can think of. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Sun Feb 19 03:57:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAkO0-00077W-Cl; Sun, 19 Feb 2006 03:57:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAkNy-00077L-8p; Sun, 19 Feb 2006 03:57:42 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAkNv-0002Be-LD; Sun, 19 Feb 2006 03:57:42 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 07A9EBD4C5F; Sun, 19 Feb 2006 00:57:35 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09870-04; Sun, 19 Feb 2006 00:57:34 -0800 (PST) Received: from PARBETM2XP (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id CCA1DBD4C61; Sun, 19 Feb 2006 00:57:29 -0800 (PST) From: "Peter Arberg" To: "'Pekka Savola'" , "'James Carlson'" Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than1492 in PPPoE' to Informational RFC Date: Sun, 19 Feb 2006 19:56:30 +1100 Organization: Redback Networks MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcY0DgOGHsDM3u5ZSKegQ7ssh0pcNQAkhsQw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20060219085729.CCA1DBD4C61@prattle.redback.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: pppext@ietf.org, iesg@ietf.org, ietf@ietf.org 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: , Errors-To: pppext-bounces@ietf.org Hi Pekka, thanks for your comments, I have added some comments inline. =20 > -----Original Message----- > From: pppext-bounces@ietf.org=20 > [mailto:pppext-bounces@ietf.org] On Behalf Of Pekka Savola > Sent: 17. februar 2006 23:00 > To: James Carlson > Cc: pppext@ietf.org; iesg@ietf.org; ietf@ietf.org > Subject: Re: [Pppext] Re: Last Call: 'Accommodating an=20 > MTU/MRU greater than1492 in PPPoE' to Informational RFC >=20 > On Fri, 17 Feb 2006, James Carlson wrote: > > Pekka Savola writes: > >> This doc seems to define a PPPoE option 'PPP-Max-Payload'.=20 > It talks > >> of using PPP MRU option. There is no PPP MTU option that=20 > I could see. > >> > >> My question here is, should there be a PPP MTU option instead of a > >> PPPoE option? This would be a more generic solution to=20 > this part of > > > > I don't follow. PPP is symmetric -- there are two MRUs negotiated, > > one for each direction. Your peer's MRU is your maximum=20 > >(and default) MTU. >=20 > Your peer's MRU is not directly your MTU, because the MTU could be=20 > lower as well (e.g., capped by the interface MTU). But yes -- this=20 > was mentioned in the pseudo-code. right, this is shown in the pseudo-code. > > How could we need another option for this? Or how could one help? > > > > What's really going on here is negotiation about the existence of a > > usable path. Unfortunately, the underlying protocol itself (other > > than LLDP) doesn't provide a way to do this. This new=20 > > mechanism thus > > doesn't solve the actual problem, but does at least allow consenting > > peers to identify each other. (In other words, I view it as just a > > boolean.) >=20 > I guess the problem I was having here is that I didn't understand why=20 > a PPPoE MTU options would be useful (still don't). After=20 > all, if both PPP endpoins would signal MRU =3D 2000 (for example), = then=20 > PPPoE could just use that with no need for an extra option? Looking = back=20 > at the archives, it appears others have had related concerns, so I=20 > guess this is beating a dead horse.. When we published the first version of the draft, it was actually to do just so, simply let the PPPoE endpoints negotiate a higher MRU than the=20 RFC2516 limitation of 1492. But during different vendor testing, it unfortunately became clear that some older PPPoE clients would request 1500 in a MRU negotiation, but = not be able to handle it... s=EDnce PPPoE servers =3D BRAS have been taking = care of this issue earlier and not allowed more than 1492 even if the client asked for 1500, it has not been a problem so far. But now we needed a way to differentiate the "new" clients who can = handle 1500 when they ask for it and the "old" clients who can't. The PPPoE = TAG is the proposal for this, to give better interoperability for higher MRU negotiation. This has been discussed on the list back in May-05. > >> MRU test procedure using MRU-sized Echo-Requests is disabled by > >> default and to be used for debug purposes only. I'm questioning > >> whether this is wise. The protocol would be much more=20 > >> robust against > > > > I don't think it is. But we did discuss that during the document > > review. >=20 > I reviewed the mailing list archives for the last 6 months, and at=20 > least during that period I didn't see this discussed. >=20 > But let me qualify that. "The protocol would be more robust against=20 > ..." instead of "much more". That is at least an objective=20 > statement:=20 > as the document specifies that all PPPoE servers MUST support this=20 > mechanism, sooner or later someone is going to misconfigure too high=20 > MTU usage when jumboframes aren't enabled, or someone is going to=20 > disable jumboframes somewhere on the path. Currently there is no=20 > jumboframe spec that I'm aware of, and there is no way to recover or=20 > notice these situations that I can think of. I agree it would be "more robust" following your suggestion, but this was also discussed back in May-05, and it is a consious choice we made and say Service Providers knows their network, and as such by disabling=20 this functionality by default, we are saying that PPP session setup time is more important than a per session setup security check, BUT=20 at the same time we agree that a troubleshooting functionality is needed = in case end-to-end connectivity can not be established. Also we did include based on James suggestion the following warning = because=20 there is no jumbospec.=20 --- The procedure described in this document do not strictly conform=20 to IEEE standards for Ethernet packet size, but rely on a widely=20 deployed behavior of supporting jumbo frames on Ethernet segments. --- cheers, Peter >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 > _______________________________________________ > Pppext mailing list > Pppext@ietf.org > https://www1.ietf.org/mailman/listinfo/pppext >=20 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Sun Feb 19 05:05:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAlRu-0004pU-Lc; Sun, 19 Feb 2006 05:05:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAlRt-0004pO-5r for pppext@ietf.org; Sun, 19 Feb 2006 05:05:49 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAlRp-0008V1-Ft for pppext@ietf.org; Sun, 19 Feb 2006 05:05:49 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 4DB43BD4C60; Sun, 19 Feb 2006 02:05:41 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06707-01; Sun, 19 Feb 2006 02:05:40 -0800 (PST) Received: from PARBETM2XP (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 0DE91BD4C62; Sun, 19 Feb 2006 02:05:38 -0800 (PST) From: "Peter Arberg" To: "'Pekka Savola'" , "'James Carlson'" Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than 1492 in PPPoE' to Informational RFC Date: Sun, 19 Feb 2006 21:05:25 +1100 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 Thread-Index: AcY0CRWyU1PmaSfaTKCXFU/kJQCJ9AAnFXTA In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20060219100538.0DE91BD4C62@prattle.redback.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: pppext@ietf.org 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: , Errors-To: pppext-bounces@ietf.org Hi Pekka, some more comments inline. > -----Original Message----- > From: pppext-bounces@ietf.org > [mailto:pppext-bounces@ietf.org] On Behalf Of Pekka Savola > Sent: 17. februar 2006 21:48 > To: iesg@ietf.org > Cc: pppext@ietf.org; ietf@ietf.org > Subject: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU > greater than 1492 in PPPoE' to Informational RFC > > On Thu, 16 Feb 2006, The IESG wrote: > > The IESG has received a request from the Point-to-Point Protocol > > Extensions WG to consider the following document: > > > > - 'Accommodating an MTU/MRU greater than 1492 in PPPoE ' > > as an Informational RFC > > I think this is addressing one of operationally important > aspects, but > I'm not so sure about a couple of particular design decisions made, > and would like to see them justified (or points to earlier > discussions) or changed. > > major discussion points > ----------------------- > > 1) > > This doc seems to define a PPPoE option 'PPP-Max-Payload'. It talks > of using PPP MRU option. There is no PPP MTU option that I could see. > > My question here is, should there be a PPP MTU option instead of a > PPPoE option? This would be a more generic solution to this part of > the problem, and would also apply in non-PPPoE scenarios for > signalling MTU. Am I missing something ? > > 2) > > MRU test procedure using MRU-sized Echo-Requests is disabled by > default and to be used for debug purposes only. I'm questioning > whether this is wise. The protocol would be much more robust against > errors if it always used, once, during the PPP set-up, one roundtrip > of MRU-sized packets. This is not a bandwidth issue, because we're > talking about fast DSL networks or Gigabit Ethernet. This > ensure that > the higher MTU is actually supported and actually works as > well (e.g., > someone hadn't turned off jumbo frames). > > So I'd argue it might make sense to put sending/receiving MRU-sized > packets (e.g., some padding) right into the negotiation phase. > 1) and 2) is responded to in earlier email. > substantial comments > -------------------- > > ==> first off, a major clarification request: RFC1661 does not > mention 'MTU' anywhere, > Correct, my comment is the same as James. Instead of every say MRU and maximum MTU I simply say MTU/MRU, I do not think this can cause to much confusion, especially when the pseudo code do show that the interface MTU has to be considered. > > > <-------------- PPPoA -------------> <- PPPoE session -> > > +-----+ +-----+ > +--+ +---+ | | | | > |PC|--------------|CPE|------------|DSLAM|------------| BRAS| > +--+ +---+ | | | | > +-----+ +-----+ > > Fig. 3: Broadband network designs with PPPoA to PPPoE conversion. > > ==> surely the part between PC and CPE should be > something else? > It's difficult to believe someone would be considering developing > a new PPPoA mechanism which would require deploying ATM on the PCs :-) > This requires some tweaking to the figure and text. I'm not talking about what people will consider moving forward, I'm talking about what is deployed today, and you will still find a large number of ATM interface cards in PC's today. This drawing is simply to show what have been deployed earlier, and what the solution will have to be able to be backward compatible with. > Since next generation broadband networks are built around Ethernet > systems supporting baby-giants and jumbo frames with payload sizes > larger than the normal Ethernet MTU of 1500 octets, a BRAS acting > as a PPPoE server MUST support PPPoE MRU negotiations larger than > 1492 bytes in order to limit the amount of fragmented packets in > network designs shown in section 1. > > 5.1 MRU Negotiations > > ==> this is a very confusing section. It seems you're saying almost > the same things about 3 times: at PPPoE pseudo-code, after that in a > very confusing explanation of the pseudo-code, and then at > the summary of the behaviour. As these use slightly different terms, > this left me > uncertain of what the actual behaviour is. This section needs a > rewrite to remove duplication of specification and to make it clearer. I will be happy to see a suggetsion, I have rewritten this before based on comments from the list, I'm not sure I can come up with a better explanation than exist here. I do not think it is the same information given 3 times, I do agree that the pseudo code is explained (or tried explained) in english, but the summary also describe what should happen if no PPP MRU negotiation happens, and as such clarifies the fact that RFC1661 is the most important factor in setting MTU/MRU even if a "PPP-Max-Payload" TAG is received. > mostly editorial > ---------------- > > ==> This has over half a dozen ID-nits, many of them blocking: > http://tools.ietf.org/wg/pppext/draft-arberg-pppoe-mtu-gt1492/ > draft-arberg-pppoe-mtu-gt1492-02.nits.txt > > ==> no refs in the abtract > > In the network design shown in figure 1, fragmentation > is typically > not a problem since the subscriber session is PPPoE > end-to-end from > the PC to the BRAS, so a PPP negotiated MRU of 1492 bytes is > fully acceptable as it makes the largest PPPoE frame adhere to > the standard Ethernet MTU of 1500 bytes. > > ==> well, there is ample evidence that fragmentation is a > problem here as well (due to broken firewalls dropping ICMP errors > that BRAS'es send), but the text is protocol-wise correct. Maybe reword > to describe the problem, to something like: > > In the network design shown in figure 1, fragmentation > is typically > unavoidable since the subscriber session is PPPoE end-to-end from > the PC to the BRAS, and the standard Ethernet MTU of 1500 sets > the limit of the frames to 1492 octets. As this causes issues > with e.g., Path MTU Discovery, it would be desirable to > be able to > raise the maximum PPP payload size to at least 1500 octets. > I don't think rewording the text will make the point any different, but I do agree a fragmentation problem often can exist in this type of setup as well, and it will also benefit from increasing the PPPoE MTU/MRU. > In the network design shown in figure 2, fragmentation becomes a > major problem since the subscriber session is a combination of > IPoE and PPPoE. The IPoE typically negotiates a MTU of > 1500 bytes. > > ==> the last sentence is misleading: IP over Ethernet does not > 'negotiate' anything. You use the default 1500, or you manually > configure both ends. Slight reword needed. Yes agree, negotiates is a wrong word to use, it should simply have said "The IPoE typically use a MTU of 1500 bytes." I have no problem issuing a v.3 of the draft with the above editorial changes, and also editorial changes to remove the found "nits", and will do so based on James advise now or when the last-call is done. thanks, Peter > If (PPP-Max-Payload-Tag) Not Present > Then PPP_MRU_Max = 1492 > Else PPP_MRU_Max = min (PPP-Max-Payload-Tag, Interface MTU-8) > > ==> for clarity, I'd move 'Else ...' indentation left by two spaces. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > _______________________________________________ > 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 Mon Feb 20 02:08:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB5A8-0006wE-L6; Mon, 20 Feb 2006 02:08:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB5A7-0006w6-6q for pppext@ietf.org; Mon, 20 Feb 2006 02:08:47 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB5A5-0004XC-Pk for pppext@ietf.org; Mon, 20 Feb 2006 02:08:47 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 19 Feb 2006 23:08:45 -0800 X-IronPort-AV: i="4.02,129,1139212800"; d="scan'208"; a="256460771:sNHT30706144" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k1K78Wuj017566; Sun, 19 Feb 2006 23:08:42 -0800 (PST) Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 19 Feb 2006 23:08:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than1492 in PPPoE' to Informational RFC Date: Sun, 19 Feb 2006 23:08:39 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than1492 in PPPoE' to Informational RFC Thread-Index: AcY0CRWyU1PmaSfaTKCXFU/kJQCJ9AAnFXTAAFFwifA= From: "Veera Tubati \(vtubati\)" To: X-OriginalArrivalTime: 20 Feb 2006 07:08:41.0187 (UTC) FILETIME=[7A966B30:01C635EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: pppext@ietf.org, Pekka Savola , 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: , Errors-To: pppext-bounces@ietf.org I wonder if draft should state its position about IPCP start while=20 MRU test is enabled. I would think IPCP start should be delayed (if this verification option is enabled) till verification is finished and BRAS decides on MTU to be used. Else, if there is a TCP session coming in soon after IPCP is up and if verification process reduces the MTU later down to 1492 that TCP session would be using a wrong MTU and would have connectivity problems. Veera _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Feb 20 13:38:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBFv6-0001sQ-AB; Mon, 20 Feb 2006 13:38:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBFv4-0001sI-Ve for pppext@ietf.org; Mon, 20 Feb 2006 13:37:59 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBFv3-0000dv-5y for pppext@ietf.org; Mon, 20 Feb 2006 13:37:58 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k1KIbtdK013546 for ; Mon, 20 Feb 2006 10:37:56 -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 k1KIbsWc023524 for ; Mon, 20 Feb 2006 13:37:54 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k1KIbsvu007305; Mon, 20 Feb 2006 13:37:54 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k1KIbsPC007302; Mon, 20 Feb 2006 13:37:54 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17402.3202.84944.205839@gargle.gargle.HOWL> Date: Mon, 20 Feb 2006 13:37:54 -0500 From: James Carlson To: "Veera Tubati (vtubati)" Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than1492 in PPPoE' to Informational RFC In-Reply-To: Veera Tubati (vtubati)'s message of 19 February 2006 23:08:39 References: X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: pppext@ietf.org, Pekka Savola 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: , Errors-To: pppext-bounces@ietf.org Veera Tubati (vtubati) writes: > I wonder if draft should state its position about IPCP start while > MRU test is enabled. > > I would think IPCP start should be delayed (if this verification option > is enabled) till verification is finished and BRAS decides on MTU to be > used. Else, if there is a TCP session coming in soon after IPCP is up > and if verification process reduces the MTU later down to 1492 that TCP > session would be using a wrong MTU and would have connectivity problems. I don't see how that'd be helpful. If the MTU negotiated at LCP time later turns out to be a problem, you're going to need to restart LCP anyway, and that will tear down IPCP. So how does waiting help? At best it avoids a small bounce (IP goes up briefly, then down and back up again) in an unusual error case. And it's something that could be handled in a decent implementation by keeping track of the MAC address of the peer and remember the MTU limit. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Feb 20 13:44:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBG0z-00028O-Ki; Mon, 20 Feb 2006 13:44:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBG0x-000282-TY; Mon, 20 Feb 2006 13:44:03 -0500 Received: from nwkea-mail-4.sun.com ([192.18.42.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBG0x-0000kW-HL; Mon, 20 Feb 2006 13:44:03 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k1KIi23W029122; Mon, 20 Feb 2006 10:44:02 -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 k1KIi2Wa024366; Mon, 20 Feb 2006 13:44:02 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k1KIi150007322; Mon, 20 Feb 2006 13:44:01 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k1KIi1ms007319; Mon, 20 Feb 2006 13:44:01 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17402.3569.880626.330804@gargle.gargle.HOWL> Date: Mon, 20 Feb 2006 13:44:01 -0500 From: James Carlson To: parberg@redback.com Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than1492 in PPPoE' to Informational RFC In-Reply-To: Peter Arberg's message of 19 February 2006 19:56:30 References: <20060219085729.CCA1DBD4C61@prattle.redback.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: pppext@ietf.org, ietf@ietf.org, 'Pekka Savola' , iesg@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: , Errors-To: pppext-bounces@ietf.org Peter Arberg writes: > I agree it would be "more robust" following your suggestion, but this > was also discussed back in May-05, and it is a consious choice we made > and say Service Providers knows their network, and as such by disabling > this functionality by default, 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. I don't think it's a wise choice at all. For those who perform the check, the check can be done in parallel with everything else the link does (such as IPCP negotiation), so there's no reason to suppose that it will somehow affect session set-up time. Plus, in the case where the test succeeds, it's very quick -- no timeout required because the large size packet will get through and be echoed back. And more importantly, if there is a problem with the path, then the failure mode will be quite obscure, painful, and difficult for mere users to diagnose. So, I don't think it's a good choice to offer at all, but since this document seems to be reflecting some existing deployment practices or implementations rather than design, I suppose I'm not overly concerned if the advice has flaws. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Feb 20 13:49:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBG6V-0002QG-15; Mon, 20 Feb 2006 13:49:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBG6T-0002PR-4Y; Mon, 20 Feb 2006 13:49:45 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBG6R-0000qm-Qv; Mon, 20 Feb 2006 13:49:45 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k1KIngSD000103; Mon, 20 Feb 2006 11:49:42 -0700 (MST) 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 k1KIngWa025674; Mon, 20 Feb 2006 13:49:42 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k1KIngax007343; Mon, 20 Feb 2006 13:49:42 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k1KIng69007340; Mon, 20 Feb 2006 13:49:42 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17402.3910.418667.24901@gargle.gargle.HOWL> Date: Mon, 20 Feb 2006 13:49:42 -0500 From: James Carlson To: Pekka Savola Subject: Re: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than 1492 in PPPoE' to Informational RFC In-Reply-To: Pekka Savola's message of 17 February 2006 23:59:43 References: <17398.16971.577636.543375@gargle.gargle.HOWL> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: pppext@ietf.org, iesg@ietf.org, ietf@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: , Errors-To: pppext-bounces@ietf.org Pekka Savola writes: > I guess the problem I was having here is that I didn't understand why > a PPPoE MTU options would be useful (still don't). After all, if both > PPP endpoins would signal MRU = 2000 (for example), then PPPoE could > just use that with no need for an extra option? Looking back at the > archives, it appears others have had related concerns, so I guess this > is beating a dead horse.. I think it is. What's really needed is some end-to-end mechanism within 802 itself for making sure that the MTU on the path is correct. That mechanism doesn't really exist. There are several problems here. First of all, there are several PPPoE implementations that will assume a fixed limit of 1492 (based on requirements of the 802 the standards), no matter what PPP attempts to negotiate. So merely having the LCP MRU option show something larger won't help -- the peer already "knows" that the path can't possibly be that wide. Now, it'd be reasonable to have LCP negotiate an MRU > 1492, and then use LCP Echo-Request (in parallel with IPCP start-up) to verify that the path really supports packets that large. If it doesn't, then restart LCP and negotiate a fixed 1492. That wouldn't require any protocol changes at all. I think something like that is what you're suggesting. It seems reasonable to me, except that I think the draft authors wanted explicit signaling between the peers to enable the new mode of operation. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Feb 20 14:29:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBGiz-0004mp-63; Mon, 20 Feb 2006 14:29:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBGix-0004mG-M0 for pppext@ietf.org; Mon, 20 Feb 2006 14:29:31 -0500 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBGiw-00026D-9X for pppext@ietf.org; Mon, 20 Feb 2006 14:29:31 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-5.sun.com (8.12.10/8.12.9) with ESMTP id k1KJTSxZ026490 for ; Mon, 20 Feb 2006 11:29:29 -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 k1KJTSWa003515 for ; Mon, 20 Feb 2006 14:29:28 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k1KJTSov007461; Mon, 20 Feb 2006 14:29:28 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k1KJTSq3007458; Mon, 20 Feb 2006 14:29:28 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17402.6296.478250.454172@gargle.gargle.HOWL> Date: Mon, 20 Feb 2006 14:29:28 -0500 From: James Carlson To: parberg@redback.com Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than 1492 in PPPoE' to Informational RFC In-Reply-To: Peter Arberg's message of 19 February 2006 21:05:25 References: <20060219100538.0DE91BD4C62@prattle.redback.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: pppext@ietf.org, 'Pekka Savola' 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: , Errors-To: pppext-bounces@ietf.org Peter Arberg writes: > I have no problem issuing a v.3 of the draft with the above editorial > changes, and also editorial changes to remove the found "nits", and > will do so based on James advise now or when the last-call is done. I'd suggest waiting until the commentary has settled and then issuing a new version. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Feb 20 14:41:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBGty-000701-E0; Mon, 20 Feb 2006 14:40:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBGtx-0006zp-2M for pppext@ietf.org; Mon, 20 Feb 2006 14:40:53 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBGtv-0002tn-NZ for pppext@ietf.org; Mon, 20 Feb 2006 14:40:53 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 20 Feb 2006 11:40:51 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1KJePgw017552; Mon, 20 Feb 2006 11:40:49 -0800 (PST) Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Feb 2006 11:40:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than1492 in PPPoE' to Informational RFC Date: Mon, 20 Feb 2006 11:40:46 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than1492 in PPPoE' to Informational RFC Thread-Index: AcY2TM813beMOfaGT4Ww9lLYyPiteQABcp6A From: "Veera Tubati \(vtubati\)" To: "James Carlson" X-OriginalArrivalTime: 20 Feb 2006 19:40:47.0488 (UTC) FILETIME=[8BF58000:01C63655] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: pppext@ietf.org, Pekka Savola 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: , Errors-To: pppext-bounces@ietf.org > -----Original Message----- > From: James Carlson [mailto:james.d.carlson@sun.com] > Sent: Monday, February 20, 2006 10:38 AM > To: Veera Tubati (vtubati) > Cc: parberg@redback.com; pppext@ietf.org; Pekka Savola > Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater > than1492 in PPPoE' to Informational RFC >=20 > Veera Tubati (vtubati) writes: > > I wonder if draft should state its position about IPCP start while > > MRU test is enabled. > > > > I would think IPCP start should be delayed (if this verification option > > is enabled) till verification is finished and BRAS decides on MTU to be > > used. Else, if there is a TCP session coming in soon after IPCP is up > > and if verification process reduces the MTU later down to 1492 that TCP > > session would be using a wrong MTU and would have connectivity problems. >=20 > I don't see how that'd be helpful. >=20 > If the MTU negotiated at LCP time later turns out to be a problem, > you're going to need to restart LCP anyway, and that will tear down > IPCP. So how does waiting help? At best it avoids a small bounce (IP > goes up briefly, then down and back up again) in an unusual error > case. 1. Draft doesn't imply that LCP would restart in this case. It just states that (section 5.2) sending side wouldn't send packets bigger than 1492. 2. Even if IPCP is restarted it is not going help the cases of PPPoE session starting from a CPE or DSLAM (fig 2 and 3 respectively from the draft) while TCP would be from the end PC. Bouncing IPCP wouldn't really have any bearing on TCP connection which still thinks it can use higher MTU.=20 But agreed that TCP from PC has to come up in a narrow time window (before test could detect a problem with negotiated MRU and adjust the MTU) to hit this problem case. Veera >=20 > And it's something that could be handled in a decent implementation by > keeping track of the MAC address of the peer and remember the MTU > limit. >=20 > -- > James Carlson, KISS Network > Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Feb 20 14:47:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBH0m-0007O4-Rf; Mon, 20 Feb 2006 14:47:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBH0m-0007Nz-5H for pppext@ietf.org; Mon, 20 Feb 2006 14:47:56 -0500 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBH0k-00034n-Nz for pppext@ietf.org; Mon, 20 Feb 2006 14:47:56 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-5.sun.com (8.12.10/8.12.9) with ESMTP id k1KJlrxZ004383 for ; Mon, 20 Feb 2006 11:47:53 -0800 (PST) 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 k1KJlrH2026789 for ; Mon, 20 Feb 2006 14:47:53 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k1KJlqA8007577; Mon, 20 Feb 2006 14:47:52 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k1KJlqAu007574; Mon, 20 Feb 2006 14:47:52 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17402.7400.870286.502781@gargle.gargle.HOWL> Date: Mon, 20 Feb 2006 14:47:52 -0500 From: James Carlson To: "Veera Tubati (vtubati)" Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than1492 in PPPoE' to Informational RFC In-Reply-To: Veera Tubati (vtubati)'s message of 20 February 2006 11:40:46 References: X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: pppext@ietf.org, Pekka Savola 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: , Errors-To: pppext-bounces@ietf.org Veera Tubati (vtubati) writes: > > If the MTU negotiated at LCP time later turns out to be a problem, > > you're going to need to restart LCP anyway, and that will tear down > > IPCP. So how does waiting help? At best it avoids a small bounce (IP > > goes up briefly, then down and back up again) in an unusual error > > case. > > 1. Draft doesn't imply that LCP would restart in this case. It just > states that (section 5.2) sending side wouldn't send packets bigger than > 1492. Either solution would be reasonable, I suppose. > 2. Even if IPCP is restarted it is not going help the cases of PPPoE > session starting from a CPE or DSLAM (fig 2 and 3 respectively from the > draft) while TCP would be from the end PC. Bouncing IPCP wouldn't really > have any bearing on TCP connection which still thinks it can use higher > MTU. I don't see how that's really PPP's problem. If the TCP/IP implementation you're using can't manage to deal with an IP link going down and coming back up with a different MTU, then that's a flaw in the TCP/IP implementation, not PPP. Isn't it always possible for the link to flap or for routes to change such that you use different interfaces at different times? I don't see how this issue is any different. It's a quality of implementation issue, not a protocol issue. > But agreed that TCP from PC has to come up in a narrow time window > (before test could detect a problem with negotiated MRU and adjust the > MTU) to hit this problem case. ... and be on a system with a flawed TCP implementation as well. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Feb 20 15:07:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBHJt-0008VK-SJ; Mon, 20 Feb 2006 15:07:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBHJs-0008V4-9U; Mon, 20 Feb 2006 15:07:40 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBHJr-0003UZ-VK; Mon, 20 Feb 2006 15:07:40 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 20 Feb 2006 12:07:40 -0800 X-IronPort-AV: i="4.02,131,1139212800"; d="scan'208"; a="407757720:sNHT37088264" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1KK7Sgk002109; Mon, 20 Feb 2006 12:07:36 -0800 (PST) Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Feb 2006 12:07:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than1492 in PPPoE' to Informational RFC Date: Mon, 20 Feb 2006 12:07:34 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than1492 in PPPoE' to Informational RFC Thread-Index: AcY2Tp7n1Fxb0Y4OTKuKbxxuyDHkewACFP7Q From: "Veera Tubati \(vtubati\)" To: "James Carlson" , "Pekka Savola" X-OriginalArrivalTime: 20 Feb 2006 20:07:35.0349 (UTC) FILETIME=[4A519E50:01C63659] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: pppext@ietf.org, iesg@ietf.org, ietf@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: , Errors-To: pppext-bounces@ietf.org > -----Original Message----- > From: James Carlson [mailto:james.d.carlson@sun.com] > Sent: Monday, February 20, 2006 10:50 AM > To: Pekka Savola > Cc: pppext@ietf.org; iesg@ietf.org; ietf@ietf.org > Subject: Re: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater > than1492 in PPPoE' to Informational RFC >=20 > Pekka Savola writes: > > I guess the problem I was having here is that I didn't understand why > > a PPPoE MTU options would be useful (still don't). After all, if both > > PPP endpoins would signal MRU =3D 2000 (for example), then PPPoE = could > > just use that with no need for an extra option? Looking back at the > > archives, it appears others have had related concerns, so I guess this > > is beating a dead horse.. >=20 > I think it is. What's really needed is some end-to-end mechanism > within 802 itself for making sure that the MTU on the path is > correct. That mechanism doesn't really exist. >=20 > There are several problems here. First of all, there are several > PPPoE implementations that will assume a fixed limit of 1492 (based on > requirements of the 802 the standards), no matter what PPP attempts to > negotiate. So merely having the LCP MRU option show something larger > won't help -- the peer already "knows" that the path can't possibly be > that wide. >=20 > Now, it'd be reasonable to have LCP negotiate an MRU > 1492, and then > use LCP Echo-Request (in parallel with IPCP start-up) to verify that > the path really supports packets that large. If it doesn't, then > restart LCP and negotiate a fixed 1492. That wouldn't require any > protocol changes at all. That can be done but then that means for PPPoE sessions to go beyond 1492 BRAS always have to incur this cost of verification; as BRAS may not be able to turn off that verification selectively either as it wouldn't be certain which clients really are asking for 1500 MRU (due to underlying network really supporting it) or which are asking 1500 MRU due to their config/implementation being broken. Seems fixing these broken clients would be a much overhead for Service provider. Veera=20 >=20 > I think something like that is what you're suggesting. It seems > reasonable to me, except that I think the draft authors wanted > explicit signaling between the peers to enable the new mode of > operation. >=20 > -- > James Carlson, KISS Network > Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 >=20 > _______________________________________________ > 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 Mon Feb 20 15:18:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBHUM-0000aC-Pc; Mon, 20 Feb 2006 15:18:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBHUK-0000Zs-PT; Mon, 20 Feb 2006 15:18:28 -0500 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBHUK-00048u-CE; Mon, 20 Feb 2006 15:18:28 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-5.sun.com (8.12.10/8.12.9) with ESMTP id k1KKIRxZ017852; Mon, 20 Feb 2006 12:18:27 -0800 (PST) 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 k1KKIRH2002994; Mon, 20 Feb 2006 15:18:27 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k1KKIQVp007728; Mon, 20 Feb 2006 15:18:26 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k1KKIQNG007725; Mon, 20 Feb 2006 15:18:26 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17402.9234.849947.301232@gargle.gargle.HOWL> Date: Mon, 20 Feb 2006 15:18:26 -0500 From: James Carlson To: "Veera Tubati (vtubati)" Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than1492 in PPPoE' to Informational RFC In-Reply-To: Veera Tubati (vtubati)'s message of 20 February 2006 12:07:34 References: X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: pppext@ietf.org, ietf@ietf.org, Pekka Savola , iesg@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: , Errors-To: pppext-bounces@ietf.org Veera Tubati (vtubati) writes: > That can be done but then that means for PPPoE sessions to go beyond > 1492 BRAS always have to incur this cost of verification; "Cost?" We're talking about a single MTU-sized packet transmitted and one received on an Ethernet link. Why is that a cost worth optimizing -- especially at the risk of losing correctness? > as BRAS may > not be able to turn off that verification selectively either as it > wouldn't be certain which clients really are asking for 1500 MRU (due to > underlying network really supporting it) or which are asking 1500 MRU > due to their config/implementation being broken. Seems fixing these > broken clients would be a much overhead for Service provider. Right, I think that may well be one of the concerns: existing old implementations that use an incorrect MTU would end up causing the peer to probe and time out. I think it'd still be possible to do something reasonable here without the extra flag, but it's probably not worth the effort. However, that doesn't mean that turning off the check for new implementations with this new feature is a good idea. I think it's a hazard and I see no benefit. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Feb 20 15:25:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBHap-0000nv-7O; Mon, 20 Feb 2006 15:25:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBHan-0000np-Rg for pppext@ietf.org; Mon, 20 Feb 2006 15:25:09 -0500 Received: from hibernia.jakma.org ([212.17.55.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBHam-0004ed-9b for pppext@ietf.org; Mon, 20 Feb 2006 15:25:09 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX19p8npQvimM2ZN1de3o8o082GoeDXRUlso@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k1KKOo49009059; Mon, 20 Feb 2006 20:25:02 GMT Date: Mon, 20 Feb 2006 20:26:13 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: James Carlson Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than1492 in PPPoE' to Informational RFC In-Reply-To: <17402.7400.870286.502781@gargle.gargle.HOWL> Message-ID: References: <17402.7400.870286.502781@gargle.gargle.HOWL> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: pppext@ietf.org, "Veera Tubati \(vtubati\)" , Pekka Savola 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: , Errors-To: pppext-bounces@ietf.org On Mon, 20 Feb 2006, James Carlson wrote: > Isn't it always possible for the link to flap or for routes to > change such that you use different interfaces at different times? And could happen somewhere in the 'middle' of the internet too, even if the PC<->ISP path stays perfectly stable. > I don't see how this issue is any different. Indeed. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Time to take stock. Go home with some office supplies. _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Feb 20 15:31:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBHgd-0000yu-SN; Mon, 20 Feb 2006 15:31:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBHgc-0000yp-Vt for pppext@ietf.org; Mon, 20 Feb 2006 15:31:10 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBHgc-0004pZ-MC for pppext@ietf.org; Mon, 20 Feb 2006 15:31:10 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 20 Feb 2006 12:31:10 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1KKUWh6013805; Mon, 20 Feb 2006 12:31:08 -0800 (PST) Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Feb 2006 12:30:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than1492 in PPPoE' to Informational RFC Date: Mon, 20 Feb 2006 12:30:31 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than1492 in PPPoE' to Informational RFC Thread-Index: AcY2VpSwFDmiOdZNRXyrMzIl+3JKiQAAyUaw From: "Veera Tubati \(vtubati\)" To: "James Carlson" X-OriginalArrivalTime: 20 Feb 2006 20:30:32.0833 (UTC) FILETIME=[7F5CFF10:01C6365C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: pppext@ietf.org, Pekka Savola 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: , Errors-To: pppext-bounces@ietf.org > -----Original Message----- > From: James Carlson [mailto:james.d.carlson@sun.com] > Sent: Monday, February 20, 2006 11:48 AM > To: Veera Tubati (vtubati) > Cc: parberg@redback.com; pppext@ietf.org; Pekka Savola > Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater > than1492 in PPPoE' to Informational RFC >=20 > Veera Tubati (vtubati) writes: > > > If the MTU negotiated at LCP time later turns out to be a problem, > > > you're going to need to restart LCP anyway, and that will tear down > > > IPCP. So how does waiting help? At best it avoids a small bounce (IP > > > goes up briefly, then down and back up again) in an unusual error > > > case. > > > > 1. Draft doesn't imply that LCP would restart in this case. It just > > states that (section 5.2) sending side wouldn't send packets bigger than > > 1492. >=20 > Either solution would be reasonable, I suppose. >=20 > > 2. Even if IPCP is restarted it is not going help the cases of PPPoE > > session starting from a CPE or DSLAM (fig 2 and 3 respectively from the > > draft) while TCP would be from the end PC. Bouncing IPCP wouldn't really > > have any bearing on TCP connection which still thinks it can use higher > > MTU. >=20 > I don't see how that's really PPP's problem. If the TCP/IP > implementation you're using can't manage to deal with an IP link going > down and coming back up with a different MTU, then that's a flaw in > the TCP/IP implementation, not PPP. >=20 > Isn't it always possible for the link to flap or for routes to change > such that you use different interfaces at different times? I don't > see how this issue is any different. That is correct but it seems ICMP error messages are filtered out (for other reasons) on these networks and sending TCP end point is never going to know that the packets it sent out with DF bit ON are not reaching the peer.=20 Reduced MTU of 1492 from PPPoE peer probably is more likely to cause pain compared to possibility of MTU changes with route flaps likely to become a bottle neck I guess... I don't mean it is a problem with PPP but since this draft is defining a mechanism for auto detection of problem with negotiated MRU already, I was wondering if it has to be little more robust in the guidelines. Veera >=20 > It's a quality of implementation issue, not a protocol issue. >=20 > > But agreed that TCP from PC has to come up in a narrow time window > > (before test could detect a problem with negotiated MRU and adjust the > > MTU) to hit this problem case. >=20 > ... and be on a system with a flawed TCP implementation as well. >=20 > -- > James Carlson, KISS Network > Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Feb 20 15:53:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBI2Z-0001Sd-Jm; Mon, 20 Feb 2006 15:53:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBI2X-0001SG-GV; Mon, 20 Feb 2006 15:53:49 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBI2W-00054D-2e; Mon, 20 Feb 2006 15:53:49 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k1KKrk4u008424; Mon, 20 Feb 2006 12:53:47 -0800 (PST) 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 k1KKrkH2009270; Mon, 20 Feb 2006 15:53:46 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k1KKrk1K007858; Mon, 20 Feb 2006 15:53:46 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k1KKrkx6007855; Mon, 20 Feb 2006 15:53:46 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17402.11354.343581.745342@gargle.gargle.HOWL> Date: Mon, 20 Feb 2006 15:53:46 -0500 From: James Carlson To: "Veera Tubati (vtubati)" Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than1492 in PPPoE' to Informational RFC In-Reply-To: Veera Tubati (vtubati)'s message of 20 February 2006 12:47:13 References: X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: pppext@ietf.org, ietf@ietf.org, Pekka Savola , iesg@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: , Errors-To: pppext-bounces@ietf.org Veera Tubati (vtubati) writes: > > We're talking about a single MTU-sized packet transmitted and one > > received on an Ethernet link. > > Correct, but it could be in the order of 20k or more sessions trying to > come up at once after the outage of a BRAS box. For the broken clients > asking for 1500, it is more overhead to timeout and retry something > else. Whatever can be avoided reasonably is a bonus. So ... we're worried about a BRAS that is unable to handle the load of one extra packet for those 20K clients but that will perform "acceptably" when those same 20K clients are all actively using their links? I don't quite understand, but it sounds to me like a design issue for the BRAS and not a protocol issue. If it wants, that machine could sequence the link bring-up so that it spreads out the load, or it could just use a more capable hardware platform. > May be there would be cases where ISP is sure that their underlying > network and clients support 1500 MRU indeed... I agree that consenting peers may do as they like, but it's not an optimization that makes sense to me. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Feb 20 16:09:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBIHp-00042P-Uk; Mon, 20 Feb 2006 16:09:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBIHo-00041o-1A; Mon, 20 Feb 2006 16:09:36 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBIHn-0005kK-OD; Mon, 20 Feb 2006 16:09:36 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 20 Feb 2006 13:09:35 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1KL97gq003296; Mon, 20 Feb 2006 13:09:32 -0800 (PST) Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Feb 2006 13:09:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than1492 in PPPoE' to Informational RFC Date: Mon, 20 Feb 2006 13:09:27 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than1492 in PPPoE' to Informational RFC Thread-Index: AcY2X8GqYH6CQMj6QC6FvvURMMsHvwAAQ3cQ From: "Veera Tubati \(vtubati\)" To: "James Carlson" X-OriginalArrivalTime: 20 Feb 2006 21:09:28.0005 (UTC) FILETIME=[EF3BF750:01C63661] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: pppext@ietf.org, ietf@ietf.org, Pekka Savola , iesg@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: , Errors-To: pppext-bounces@ietf.org > -----Original Message----- > From: James Carlson [mailto:james.d.carlson@sun.com] > Sent: Monday, February 20, 2006 12:54 PM > To: Veera Tubati (vtubati) > Cc: Pekka Savola; pppext@ietf.org; iesg@ietf.org; ietf@ietf.org > Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater > than1492 in PPPoE' to Informational RFC >=20 > Veera Tubati (vtubati) writes: > > > We're talking about a single MTU-sized packet transmitted and one > > > received on an Ethernet link. > > > > Correct, but it could be in the order of 20k or more sessions trying to > > come up at once after the outage of a BRAS box. For the broken clients > > asking for 1500, it is more overhead to timeout and retry something > > else. Whatever can be avoided reasonably is a bonus. >=20 > So ... we're worried about a BRAS that is unable to handle the load of > one extra packet for those 20K clients but that will perform > "acceptably" when those same 20K clients are all actively using their > links? >=20 > I don't quite understand, but it sounds to me like a design issue for > the BRAS and not a protocol issue. If it wants, that machine could > sequence the link bring-up so that it spreads out the load, or it > could just use a more capable hardware platform. It is clear that is not an issue with the protocol, but seems there are practical reasons which pushed for the birth of this draft. Veera >=20 > > May be there would be cases where ISP is sure that their underlying > > network and clients support 1500 MRU indeed... >=20 > I agree that consenting peers may do as they like, but it's not an > optimization that makes sense to me. >=20 > -- > James Carlson, KISS Network > Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Feb 20 16:16:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBIOG-00052o-Ov; Mon, 20 Feb 2006 16:16:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBIOF-00052O-B4; Mon, 20 Feb 2006 16:16:15 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBIOF-0006Ee-2E; Mon, 20 Feb 2006 16:16:15 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k1KLGESD011965; Mon, 20 Feb 2006 14:16:14 -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 k1KLGDH2013602; Mon, 20 Feb 2006 16:16:14 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k1KLGD86007939; Mon, 20 Feb 2006 16:16:13 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k1KLGDPB007936; Mon, 20 Feb 2006 16:16:13 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17402.12701.791460.492132@gargle.gargle.HOWL> Date: Mon, 20 Feb 2006 16:16:13 -0500 From: James Carlson To: "Veera Tubati (vtubati)" Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than1492 in PPPoE' to Informational RFC In-Reply-To: Veera Tubati (vtubati)'s message of 20 February 2006 13:09:27 References: X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: pppext@ietf.org, ietf@ietf.org, Pekka Savola , iesg@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: , Errors-To: pppext-bounces@ietf.org Veera Tubati (vtubati) writes: > > I don't quite understand, but it sounds to me like a design issue for > > the BRAS and not a protocol issue. If it wants, that machine could > > sequence the link bring-up so that it spreads out the load, or it > > could just use a more capable hardware platform. > > It is clear that is not an issue with the protocol, but seems there are > practical reasons which pushed for the birth of this draft. That seems unrelated to the potential performance issue I thought we were discussing. In any event, the draft authors wanted explicit signaling because of the behavior of the existing PPPoE implementations. There's little way to be _sure_ you're talking to a new one without checking. (I think a boolean would be sufficient for that, but I see no problem with having an integer value instead.) -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Feb 20 16:16:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBIOw-00058d-7p; Mon, 20 Feb 2006 16:16:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBIOu-00058O-LM; Mon, 20 Feb 2006 16:16:56 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBICw-0005MJ-KA; Mon, 20 Feb 2006 16:04:34 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FBHzD-0001Vr-5A; Mon, 20 Feb 2006 15:50:23 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 20 Feb 2006 12:47:21 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1KKkZhG020340; Mon, 20 Feb 2006 12:47:18 -0800 (PST) Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Feb 2006 12:47:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than1492 in PPPoE' to Informational RFC Date: Mon, 20 Feb 2006 12:47:13 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than1492 in PPPoE' to Informational RFC Thread-Index: AcY2WtQjdZthnSLdQH2wSPZ2dbRhlQAAhxBA From: "Veera Tubati \(vtubati\)" To: "James Carlson" X-OriginalArrivalTime: 20 Feb 2006 20:47:14.0641 (UTC) FILETIME=[D47CC410:01C6365E] X-Spam-Score: -2.6 (--) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: pppext@ietf.org, ietf@ietf.org, Pekka Savola , iesg@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: , Errors-To: pppext-bounces@ietf.org > -----Original Message----- > From: James Carlson [mailto:james.d.carlson@sun.com] > Sent: Monday, February 20, 2006 12:18 PM > To: Veera Tubati (vtubati) > Cc: Pekka Savola; pppext@ietf.org; iesg@ietf.org; ietf@ietf.org > Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater > than1492 in PPPoE' to Informational RFC >=20 > Veera Tubati (vtubati) writes: > > That can be done but then that means for PPPoE sessions to go beyond > > 1492 BRAS always have to incur this cost of verification; >=20 > "Cost?" >=20 > We're talking about a single MTU-sized packet transmitted and one > received on an Ethernet link. Correct, but it could be in the order of 20k or more sessions trying to come up at once after the outage of a BRAS box. For the broken clients asking for 1500, it is more overhead to timeout and retry something else. Whatever can be avoided reasonably is a bonus. >=20 > Why is that a cost worth optimizing -- especially at the risk of > losing correctness? >=20 > > as BRAS may > > not be able to turn off that verification selectively either as it > > wouldn't be certain which clients really are asking for 1500 MRU (due to > > underlying network really supporting it) or which are asking 1500 MRU > > due to their config/implementation being broken. Seems fixing these > > broken clients would be a much overhead for Service provider. >=20 > Right, I think that may well be one of the concerns: existing old > implementations that use an incorrect MTU would end up causing the > peer to probe and time out. >=20 > I think it'd still be possible to do something reasonable here without > the extra flag, but it's probably not worth the effort. >=20 > However, that doesn't mean that turning off the check for new > implementations with this new feature is a good idea. I think it's a > hazard and I see no benefit. May be there would be cases where ISP is sure that their underlying network and clients support 1500 MRU indeed... Veera >=20 > -- > James Carlson, KISS Network > Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Tue Feb 21 07:18:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBWTZ-0002A8-AC; Tue, 21 Feb 2006 07:18:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBWTY-00029x-02; Tue, 21 Feb 2006 07:18:40 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBWTW-0008TF-Id; Tue, 21 Feb 2006 07:18:39 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 17B73EAED39; Tue, 21 Feb 2006 04:18:30 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11941-05; Tue, 21 Feb 2006 04:18:29 -0800 (PST) Received: from PARBETM2XP (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 0701AEAED38; Tue, 21 Feb 2006 04:18:17 -0800 (PST) From: "Peter Arberg" To: "'James Carlson'" , "'Veera Tubati (vtubati)'" Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than1492in PPPoE' to Informational RFC Date: Tue, 21 Feb 2006 23:17:55 +1100 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 Thread-Index: AcY2YyP77t+PjRaMQl6Q16ZyW/O8SAAepxrA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <17402.12701.791460.492132@gargle.gargle.HOWL> Message-Id: <20060221121817.0701AEAED38@prattle.redback.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: pppext@ietf.org, iesg@ietf.org, ietf@ietf.org, 'Pekka Savola' 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: , Errors-To: pppext-bounces@ietf.org I agree a boolean flag could as well have been used, but the initial suggestion was for a value to set a hint for the max value the client would be asking for, I also see no problem in this value. I do think based on recent discussions that a little more precise pseudo code is needed, to make the pseudo code in line with the tag description, that it's value is only a maximum hint if it's greater than 1492, if for some strange reasons a client send a tag value less than 1492 (don't ask me why it would ;) then the BRAS should ignore the value and allow the MRU negotiation of upto 1492. Also for the echo test, the recommendation ended up like it is, because the carrier feedback was they know their network, and as such do not expect major problems if/when they would enable the new capability. It is the intend of the text that this is an adhoc test which can be performed by an administrator upon connectivity problems. It will without a doubt make the solution more robust if the echo test was performed upon setup, and we could change the recommendation to not specific say this capability SHOULD be disabled, so changing it from --- This capability SHOULD be disabled by default, and SHOULD only be available for debug, test purpose. --- to something like this: --- This capability MAY be disabled by default, but SHOULD be available for debug, test purpose. --- if you think that will make it a little better. cheers, Peter > -----Original Message----- > From: James Carlson [mailto:james.d.carlson@sun.com] > Sent: 21. februar 2006 08:16 > To: Veera Tubati (vtubati) > Cc: pppext@ietf.org; ietf@ietf.org; Pekka Savola; iesg@ietf.org > Subject: RE: [Pppext] Re: Last Call: 'Accommodating an > MTU/MRU greater than1492in PPPoE' to Informational RFC > > Veera Tubati (vtubati) writes: > > > I don't quite understand, but it sounds to me like a > design issue for > > > the BRAS and not a protocol issue. If it wants, that > machine could > > > sequence the link bring-up so that it spreads out the load, or it > > > could just use a more capable hardware platform. > > > > It is clear that is not an issue with the protocol, but > seems there are > > practical reasons which pushed for the birth of this draft. > > That seems unrelated to the potential performance issue I thought we > were discussing. > > In any event, the draft authors wanted explicit signaling because of > the behavior of the existing PPPoE implementations. There's little > way to be _sure_ you're talking to a new one without checking. (I > think a boolean would be sufficient for that, but I see no problem > with having an integer value instead.) > > -- > James Carlson, KISS Network > > Sun Microsystems / 1 Network Drive 71.232W Vox +1 > 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N 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 Tue Feb 21 21:01:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBjJy-0001dx-9n; Tue, 21 Feb 2006 21:01:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBjJx-0001dX-4Q for pppext@ietf.org; Tue, 21 Feb 2006 21:01:37 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBjJw-0007Jt-Oi for pppext@ietf.org; Tue, 21 Feb 2006 21:01:37 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV200IW6FL71B@usaga01-in.huawei.com> for pppext@ietf.org; Tue, 21 Feb 2006 17:46:19 -0800 (PST) Received: from huawei.com ([172.17.1.218]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV200632FL676@usaga01-in.huawei.com> for pppext@ietf.org; Tue, 21 Feb 2006 17:46:19 -0800 (PST) Received: from [172.24.1.6] (Forwarded-For: [10.71.149.96]) by szxmc02-in.huawei.com (mshttpd); Wed, 22 Feb 2006 09:49:31 +0800 Date: Wed, 22 Feb 2006 09:49:31 +0800 From: Wang Hui 10128 To: pppext@ietf.org Message-id: <792bfc78c236.78c236792bfc@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Pppext] About "Prefix elision" in RFC 2686(MC-ML-PPP) 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: , Errors-To: pppext-bounces@ietf.org Hi All: In RFC 2686 "The Multi-Class Extension to Multi-Link PPP", it describes: ------------------------------------------------------------------------ > 5. Prefix elision: Compressing common header bytes > > For some applications, all packets of a certain class will have a > common protocol identifier (or even more than one common prefix > byte). In this case, the following optimization is possible: the > class number can be associated with a prefix of bytes that are > removed from each packet before transmission and that are implicitly > prepended to the reassembled packet after reception. > > Prefix elision is not a replacement for header compression or data > compression: it allows implementations to compress away prefixes that > often are not reachable by header or data compression methods. ------------------------------------------------------------------------- For normal ip packets, "protocol id"+"ip header"+"data", maybe we can remove only one byte or two bytes (protocol id); It's not very useful. And, when we remove the configed prefix from these packets, if the packets not include the same "prefix", should we discard the packet? Do anybody know some other applications about this "Prefix elision" ? Are there any devices implement the MC "Prefix elision" ? Thanks very much! Regards WangHui _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Feb 23 01:26:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC9vr-0002kp-LH; Thu, 23 Feb 2006 01:26:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC9vp-0002k8-6W; Thu, 23 Feb 2006 01:26:29 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC9vn-0001ao-NH; Thu, 23 Feb 2006 01:26:29 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k1N6QMHa029552; Thu, 23 Feb 2006 08:26:22 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k1N6QLEv029549; Thu, 23 Feb 2006 08:26:22 +0200 Date: Thu, 23 Feb 2006 08:26:21 +0200 (EET) From: Pekka Savola To: Peter Arberg Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greater than1492in PPPoE' to Informational RFC In-Reply-To: <20060221121817.0701AEAED38@prattle.redback.com> Message-ID: References: <20060221121817.0701AEAED38@prattle.redback.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88/1298/Wed Feb 22 22:50:12 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: pppext@ietf.org, "'Veera Tubati \(vtubati\)'" , ietf@ietf.org, 'James Carlson' , iesg@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: , Errors-To: pppext-bounces@ietf.org On Tue, 21 Feb 2006, Peter Arberg wrote: > It will without a doubt make the solution more robust if the echo test > was performed upon setup, and we could change the recommendation to not > specific say this capability SHOULD be disabled, so changing it from > --- > This capability SHOULD be disabled by default, and SHOULD only be > available for debug, test purpose. > --- > > to something like this: > > --- > This capability MAY be disabled by default, but SHOULD be > available for debug, test purpose. > --- > if you think that will make it a little better. Couldn't we say even more than that, simply like: This capability SHOULD be used by default. or: This capability SHOULD be used by default to verify that the negotiated MTU/MRU actually works. That would allow anyone to disable it (or not implement it) and still be compliant with the spec. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Feb 23 10:41:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCIaj-0001zt-L8; Thu, 23 Feb 2006 10:41:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCIaj-0001zd-4C; Thu, 23 Feb 2006 10:41:17 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCIai-0002co-Qn; Thu, 23 Feb 2006 10:41:17 -0500 Received: from unknown (HELO pi-smtp.jnpr.net) ([10.10.2.36]) by borg.juniper.net with ESMTP; 23 Feb 2006 07:41:16 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,141,1139212800"; d="scan'208"; a="532020408:sNHT35545848" Received: from antipi.jnpr.net ([10.10.2.34]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 23 Feb 2006 10:41:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greaterthan1492in PPPoE' to Informational RFC Date: Thu, 23 Feb 2006 10:41:14 -0500 Message-ID: <6B8F46B46D292A438250E42591ABB59D02246A90@antipi.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greaterthan1492in PPPoE' to Informational RFC Thread-Index: AcY4Tfh+cNkKkibVT5OwWLFqcBGlnQAP/tuQ From: "Jerome Moisand" To: "Pekka Savola" X-OriginalArrivalTime: 23 Feb 2006 15:41:14.0901 (UTC) FILETIME=[94780450:01C6388F] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: pppext@ietf.org, ietf@ietf.org, iesg@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: , Errors-To: pppext-bounces@ietf.org I think we have to be mindful of the primary use case here, and be actually driven by it. The primary use case is a DSL scenario, where the aggregation network behind the DSLAM is Ethernet down to an IP edge router (call it BRAS or BNG, as you want) which processes PPPoE. All broadband carriers I know of have very clear plans to use Ethernet aggregation gear and Ethernet interfaces on both DSLAM and BRAS which are enabled for jumbo-frames. All corresponding equipment vendors I know do support such feature. So this isn't a fairly arbitrary topology like could be found in an enterprise environment or a campus environment. It is a very controlled environment with strict deployment rules. Based on that, enabling such verification by default (with the additional roundtrip implied) is just a completely unnecessary burden, and when you have to deal with 20K or 40K PPPoE sessions, including major peaks when a GE link is restored after failure, this is rather impactful. This is the rationale for disabling the mechanism by default, while allowing to enable it whenever one really needs it (e.g. debugging purposes; or some new use case nobody thought about so far). This is admittedly a pragmatic, use-case driven, recommendation. Tx Jerome -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi]=20 Sent: Thursday, February 23, 2006 1:26 AM To: Peter Arberg Cc: pppext@ietf.org; 'Veera Tubati (vtubati)'; ietf@ietf.org; 'James Carlson'; iesg@ietf.org Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greaterthan1492in PPPoE' to Informational RFC On Tue, 21 Feb 2006, Peter Arberg wrote: > It will without a doubt make the solution more robust if the echo test > was performed upon setup, and we could change the recommendation to not > specific say this capability SHOULD be disabled, so changing it from > --- > This capability SHOULD be disabled by default, and SHOULD only be > available for debug, test purpose. > --- > > to something like this: > > --- > This capability MAY be disabled by default, but SHOULD be > available for debug, test purpose. > --- > if you think that will make it a little better. Couldn't we say even more than that, simply like: This capability SHOULD be used by default. or: This capability SHOULD be used by default to verify that the negotiated MTU/MRU actually works. That would allow anyone to disable it (or not implement it) and still=20 be compliant with the spec. --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ 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 Thu Feb 23 11:00:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCItC-0006bW-3u; Thu, 23 Feb 2006 11:00:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCItA-0006as-Sk; Thu, 23 Feb 2006 11:00:20 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCIt7-000329-E9; Thu, 23 Feb 2006 11:00:20 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k1NG0FdK004087; Thu, 23 Feb 2006 08:00:15 -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 k1NG0EWa013830; Thu, 23 Feb 2006 11:00:14 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k1NG0Bnb018318; Thu, 23 Feb 2006 11:00:11 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k1NG0Bkn018315; Thu, 23 Feb 2006 11:00:11 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17405.56330.968771.125533@gargle.gargle.HOWL> Date: Thu, 23 Feb 2006 11:00:10 -0500 From: James Carlson To: Jerome Moisand Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRU greaterthan1492in PPPoE' to Informational RFC In-Reply-To: Jerome Moisand's message of 23 February 2006 10:41:14 References: <6B8F46B46D292A438250E42591ABB59D02246A90@antipi.jnpr.net> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: pppext@ietf.org, iesg@ietf.org, Pekka Savola , ietf@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: , Errors-To: pppext-bounces@ietf.org Jerome Moisand writes: > All broadband carriers I know of have very clear plans to use Ethernet > aggregation gear and Ethernet interfaces on both DSLAM and BRAS which > are enabled for jumbo-frames. All corresponding equipment vendors I know > do support such feature. If there's just one customer-owned non-jumbo bridge in the way (e.g., an 802.11 AP), then your whole day is shot. > So this isn't a fairly arbitrary topology like could be found in an > enterprise environment or a campus environment. It is a very controlled > environment with strict deployment rules. That's the part that seems really inappropriate for any sort of document published via the IETF. History tells us that we have very little ability to predict the future -- and essentially none at all when it comes to the distant future. Designing a protocol that works only in one particular deployment scenario but falls on its face elsewhere seems tragically short- sighted to me. (Perhaps it's ultimately a good thing overall, if it just causes customers to abandon vendors using solutions that fail. But getting there is tough and unnecessarily hazardous.) > Based on that, enabling such verification by default (with the > additional roundtrip implied) is just a completely unnecessary burden, > and when you have to deal with 20K or 40K PPPoE sessions, including > major peaks when a GE link is restored after failure, this is rather > impactful. That's still an implementation issue, not a protocol issue. If you can't handle the load (a decent design should, as this is by far the least of the duties it might face), then spread it out. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N 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 23 11:44:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCJa6-00038H-J9; Thu, 23 Feb 2006 11:44:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCJa5-00036B-0T; Thu, 23 Feb 2006 11:44:41 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCJa4-0004mh-My; Thu, 23 Feb 2006 11:44:40 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 23 Feb 2006 08:44:40 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,141,1139212800"; d="scan'208"; a="532035078:sNHT34472704" Received: from antipi.jnpr.net ([10.10.2.34]) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Feb 2006 11:44:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRUgreaterthan1492in PPPoE' to Informational RFC Date: Thu, 23 Feb 2006 11:44:38 -0500 Message-ID: <6B8F46B46D292A438250E42591ABB59D02246A92@antipi.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pppext] Re: Last Call: 'Accommodating an MTU/MRUgreaterthan1492in PPPoE' to Informational RFC Thread-Index: AcY4kkme8Z7ySElNS6KoI2HLYr7EygAAivhA From: "Jerome Moisand" To: "James Carlson" X-OriginalArrivalTime: 23 Feb 2006 16:44:38.0976 (UTC) FILETIME=[6FDFCC00:01C63898] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: pppext@ietf.org, ietf@ietf.org, iesg@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: , Errors-To: pppext-bounces@ietf.org James, I don't know of any real-life use case where an AP is in the way, but the protocol extension *IS* general-purpose, the MTU/MRU testing mechanism option is there, and can be used. Tuning the default behavior to the main use cases doesn't preclude to enable the other behavior in other (yet unforeseen) environments.=20 Adding an unnecessary round-trip (hence adding latency & burden) is definitely a protocol issue, not an implementation issue. I really have troubles to understand why a default setting should not be tuned with the main use cases as known at the time of writing. Where I do have sympathy for improving the text is NOT to change the default setting, but to be more clear that the MTU/MRU test might find other applications then simple troubleshooting.=20 Because you are quite correct in pointing out that the unforeseen needs to be somewhat accommodated. In other words, the 2nd part of the following sentence is indeed limitative. << This capability SHOULD be disabled by default, and SHOULD only be available for debug, test purpose. >> Maybe should we change it to: << This capability SHOULD be disabled by default, but SHOULD be available for debug & test purpose, or for topologies where a dynamically adaptive behavior is required.>> Is this better? If you have a better wording, please speak up. I do agree this sentence needs to be improved. Tx Jerome -----Original Message----- From: James Carlson [mailto:james.d.carlson@sun.com]=20 Sent: Thursday, February 23, 2006 11:00 AM To: Jerome Moisand Cc: Pekka Savola; pppext@ietf.org; ietf@ietf.org; iesg@ietf.org Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRUgreaterthan1492in PPPoE' to Informational RFC Jerome Moisand writes: > All broadband carriers I know of have very clear plans to use Ethernet > aggregation gear and Ethernet interfaces on both DSLAM and BRAS which > are enabled for jumbo-frames. All corresponding equipment vendors I know > do support such feature. If there's just one customer-owned non-jumbo bridge in the way (e.g., an 802.11 AP), then your whole day is shot. > So this isn't a fairly arbitrary topology like could be found in an > enterprise environment or a campus environment. It is a very controlled > environment with strict deployment rules. That's the part that seems really inappropriate for any sort of document published via the IETF. History tells us that we have very little ability to predict the future -- and essentially none at all when it comes to the distant future. Designing a protocol that works only in one particular deployment scenario but falls on its face elsewhere seems tragically short- sighted to me. (Perhaps it's ultimately a good thing overall, if it just causes customers to abandon vendors using solutions that fail. But getting there is tough and unnecessarily hazardous.) > Based on that, enabling such verification by default (with the > additional roundtrip implied) is just a completely unnecessary burden, > and when you have to deal with 20K or 40K PPPoE sessions, including > major peaks when a GE link is restored after failure, this is rather > impactful. That's still an implementation issue, not a protocol issue. If you can't handle the load (a decent design should, as this is by far the least of the duties it might face), then spread it out. --=20 James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N 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 23 12:46:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCKYE-00035v-1y; Thu, 23 Feb 2006 12:46:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCKYD-00035k-7P for pppext@ietf.org; Thu, 23 Feb 2006 12:46:49 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCKYC-0006qU-RR for pppext@ietf.org; Thu, 23 Feb 2006 12:46:49 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k1NHklSD015435 for ; Thu, 23 Feb 2006 10:46:48 -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 k1NHklH0006381 for ; Thu, 23 Feb 2006 12:46:47 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k1NHkl51018823; Thu, 23 Feb 2006 12:46:47 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k1NHklDv018820; Thu, 23 Feb 2006 12:46:47 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17405.62727.348970.541373@gargle.gargle.HOWL> Date: Thu, 23 Feb 2006 12:46:47 -0500 From: James Carlson To: Jerome Moisand Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRUgreaterthan1492in PPPoE' to Informational RFC In-Reply-To: Jerome Moisand's message of 23 February 2006 11:44:38 References: <6B8F46B46D292A438250E42591ABB59D02246A92@antipi.jnpr.net> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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: , Errors-To: pppext-bounces@ietf.org [Dropping ietf and iesg from the list, as we probably should have done quite some time ago.] Jerome Moisand writes: > I don't know of any real-life use case where an AP is in the way, That's precisely my point. We don't know. And we can't know. I'm explicitly arguing that any protocol that relies this strongly on deployment considerations in order to be "correct" is just plain broken. If someone wants to make a knowing violation of an RFC's recommendations because his particular deployment scenario allows or encourages it, that's fine. I see no problem at all with that. It's not as if there are "RFC police" who will stop him. But I do *NOT* believe that such local "optimizations" are what should be described or encouraged in the RFC itself. > but > the protocol extension *IS* general-purpose, the MTU/MRU testing > mechanism option is there, and can be used. Tuning the default behavior > to the main use cases doesn't preclude to enable the other behavior in > other (yet unforeseen) environments. I think this is backwards. The default should be to be robust. For those who don't care about robustness for some reason, then the safety features can be disabled. > Adding an unnecessary round-trip (hence adding latency & burden) is > definitely a protocol issue, not an implementation issue. I still don't see it. This is a test that can be assumed to succeed and can be performed in parallel with starting up IPCP and other services. It should have essentially *zero* cost in any reasonable implementation. I don't think that assuming either poor implementation or bad overall design should be a requirement. > I really have troubles to understand why a default setting should not be > tuned with the main use cases as known at the time of writing. Because RFCs are meant to capture good practice, not just some quirk of the deployment issues we see today. > << This capability SHOULD be disabled by default, but SHOULD be > available for debug & test purpose, or for topologies where a > dynamically adaptive behavior is required.>> > > Is this better? If you have a better wording, please speak up. I do > agree this sentence needs to be improved. No. This would be better: This capability SHOULD be enabled by default, because the failure mode is difficult for users to diagnose correctly and otherwise impossible to protect against. It MAY be configurable and MAY be disabled on networks where there is some prior knowledge indicating that the test is not necessary. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N 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 23 14:09:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCLq7-0005BJ-8S; Thu, 23 Feb 2006 14:09:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCLph-0004ke-Hc for pppext@ietf.org; Thu, 23 Feb 2006 14:08:57 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCLbp-00006d-1W for pppext@ietf.org; Thu, 23 Feb 2006 13:54:37 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 23 Feb 2006 10:54:27 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,141,1139212800"; d="scan'208"; a="529700232:sNHT35445040" Received: from antipi.jnpr.net ([10.10.2.34]) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Feb 2006 13:54:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRUgreaterthan1492in PPPoE' to Informational RFC Date: Thu, 23 Feb 2006 13:54:25 -0500 Message-ID: <6B8F46B46D292A438250E42591ABB59D02246A9B@antipi.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pppext] Re: Last Call: 'Accommodating an MTU/MRUgreaterthan1492in PPPoE' to Informational RFC Thread-Index: AcY4oTP4BCnt3iHrTnmEvfJSx2yHqwAAwWrg From: "Jerome Moisand" To: X-OriginalArrivalTime: 23 Feb 2006 18:54:25.0945 (UTC) FILETIME=[9144F890:01C638AA] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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: , Errors-To: pppext-bounces@ietf.org Ok, then we have diverging philosophies on default settings... In any case, irrespective of the default setting, the protocol isn't broken since the setting can be changed. Anybody else having views on this topic, notably folks actually involved in corresponding implementations & deployments? -----Original Message----- From: James Carlson [mailto:james.d.carlson@sun.com]=20 Sent: Thursday, February 23, 2006 12:47 PM To: Jerome Moisand Cc: pppext@ietf.org Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRUgreaterthan1492in PPPoE' to Informational RFC [Dropping ietf and iesg from the list, as we probably should have done quite some time ago.] Jerome Moisand writes: > I don't know of any real-life use case where an AP is in the way, That's precisely my point. We don't know. And we can't know. I'm explicitly arguing that any protocol that relies this strongly on deployment considerations in order to be "correct" is just plain broken. If someone wants to make a knowing violation of an RFC's recommendations because his particular deployment scenario allows or encourages it, that's fine. I see no problem at all with that. It's not as if there are "RFC police" who will stop him. But I do *NOT* believe that such local "optimizations" are what should be described or encouraged in the RFC itself. > but > the protocol extension *IS* general-purpose, the MTU/MRU testing > mechanism option is there, and can be used. Tuning the default behavior > to the main use cases doesn't preclude to enable the other behavior in > other (yet unforeseen) environments.=20 I think this is backwards. The default should be to be robust. For those who don't care about robustness for some reason, then the safety features can be disabled. > Adding an unnecessary round-trip (hence adding latency & burden) is > definitely a protocol issue, not an implementation issue. I still don't see it. This is a test that can be assumed to succeed and can be performed in parallel with starting up IPCP and other services. It should have essentially *zero* cost in any reasonable implementation. I don't think that assuming either poor implementation or bad overall design should be a requirement. > I really have troubles to understand why a default setting should not be > tuned with the main use cases as known at the time of writing. Because RFCs are meant to capture good practice, not just some quirk of the deployment issues we see today. > << This capability SHOULD be disabled by default, but SHOULD be > available for debug & test purpose, or for topologies where a > dynamically adaptive behavior is required.>> >=20 > Is this better? If you have a better wording, please speak up. I do > agree this sentence needs to be improved. No. This would be better: This capability SHOULD be enabled by default, because the failure mode is difficult for users to diagnose correctly and otherwise impossible to protect against. It MAY be configurable and MAY be disabled on networks where there is some prior knowledge indicating that the test is not necessary. --=20 James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Feb 24 01:49:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCWlJ-0001Vf-33; Fri, 24 Feb 2006 01:49:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCWlH-0001VR-F3; Fri, 24 Feb 2006 01:49:07 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCWlD-0007Za-VJ; Fri, 24 Feb 2006 01:49:07 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k1O6n0Ha001870; Fri, 24 Feb 2006 08:49:00 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k1O6mxX3001867; Fri, 24 Feb 2006 08:48:59 +0200 Date: Fri, 24 Feb 2006 08:48:59 +0200 (EET) From: Pekka Savola To: Jerome Moisand Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRUgreaterthan1492in PPPoE' to Informational RFC In-Reply-To: <6B8F46B46D292A438250E42591ABB59D02246A92@antipi.jnpr.net> Message-ID: References: <6B8F46B46D292A438250E42591ABB59D02246A92@antipi.jnpr.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88/1300/Thu Feb 23 17:55:11 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: pppext@ietf.org, ietf@ietf.org, James Carlson , iesg@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: , Errors-To: pppext-bounces@ietf.org On Thu, 23 Feb 2006, Jerome Moisand wrote: > Adding an unnecessary round-trip (hence adding latency & burden) is > definitely a protocol issue, not an implementation issue. > > I really have troubles to understand why a default setting should not be > tuned with the main use cases as known at the time of writing. AFAIK, we're breaking IEEE Ethernet specifications by using jumbo frames (or, at the very least, using an unspecified features). To me, that should imply it might be wise to err to the side of caution. Note: it might be possible to do away with an extra roundtrip if that's issue, by adding some padding to the PPP/PPPoE messages themselves, instead of using separate PPP echo req/response. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Tue Feb 28 10:27:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE6ku-0001vU-5x; Tue, 28 Feb 2006 10:27:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE6kt-0001tD-08 for pppext@ietf.org; Tue, 28 Feb 2006 10:27:15 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE6kr-0007F1-IE for pppext@ietf.org; Tue, 28 Feb 2006 10:27:14 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 93DE013254A6; Tue, 28 Feb 2006 07:27:05 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22589-01; Tue, 28 Feb 2006 07:27:05 -0800 (PST) Received: from PARBETM2XP (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 7F6BF13254AB; Tue, 28 Feb 2006 07:27:01 -0800 (PST) From: "Peter Arberg" To: "'James Carlson'" , "'Jerome Moisand'" Subject: RE: [Pppext] Re: Last Call: 'Accommodating an MTU/MRUgreaterthan1492inPPPoE' to Informational RFC Date: Tue, 28 Feb 2006 16:27:11 +0100 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: AcY4oYR4rcuzPf70TdOVQIP6HlEOkAD2Qb8g In-Reply-To: <17405.62727.348970.541373@gargle.gargle.HOWL> Message-Id: <20060228152701.7F6BF13254AB@prattle.redback.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: pppext@ietf.org 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: , Errors-To: pppext-bounces@ietf.org Hi, the authors of the draft are fine with changing the last paragraph of section 5.2 from: --- This capability SHOULD be disabled by default, and SHOULD only be available for debug, test purpose. --- into a new text, and we propose this text as a compromise between the different suggestions voiced on the list. --- This capability SHOULD be enabled by default. It SHOULD be configurable and MAY be disabled on networks where there is some prior knowledge indicating that the test is not necessary. --- This will be included in the version-3 text as soon as we finish the last-call comments. thanks for all the good comments, Peter > -----Original Message----- > From: James Carlson [mailto:james.d.carlson@sun.com] > Sent: 23. februar 2006 18:47 > To: Jerome Moisand > Cc: pppext@ietf.org > Subject: RE: [Pppext] Re: Last Call: 'Accommodating an > MTU/MRUgreaterthan1492inPPPoE' to Informational RFC > > [Dropping ietf and iesg from the list, as we probably should have done > quite some time ago.] > > Jerome Moisand writes: > > I don't know of any real-life use case where an AP is in the way, > > That's precisely my point. We don't know. And we can't know. I'm > explicitly arguing that any protocol that relies this strongly on > deployment considerations in order to be "correct" is just plain > broken. > > If someone wants to make a knowing violation of an RFC's > recommendations because his particular deployment scenario allows or > encourages it, that's fine. I see no problem at all with that. It's > not as if there are "RFC police" who will stop him. But I do *NOT* > believe that such local "optimizations" are what should be described > or encouraged in the RFC itself. > > > but > > the protocol extension *IS* general-purpose, the MTU/MRU testing > > mechanism option is there, and can be used. Tuning the > default behavior > > to the main use cases doesn't preclude to enable the other > behavior in > > other (yet unforeseen) environments. > > I think this is backwards. The default should be to be robust. For > those who don't care about robustness for some reason, then the safety > features can be disabled. > > > Adding an unnecessary round-trip (hence adding latency & burden) is > > definitely a protocol issue, not an implementation issue. > > I still don't see it. This is a test that can be assumed to succeed > and can be performed in parallel with starting up IPCP and other > services. It should have essentially *zero* cost in any reasonable > implementation. > > I don't think that assuming either poor implementation or bad overall > design should be a requirement. > > > I really have troubles to understand why a default setting > should not be > > tuned with the main use cases as known at the time of writing. > > Because RFCs are meant to capture good practice, not just some quirk > of the deployment issues we see today. > > > << This capability SHOULD be disabled by default, but SHOULD be > > available for debug & test purpose, or for topologies where a > > dynamically adaptive behavior is required.>> > > > > Is this better? If you have a better wording, please speak up. I do > > agree this sentence needs to be improved. > > No. This would be better: > > This capability SHOULD be enabled by default, because the failure > mode is difficult for users to diagnose correctly and otherwise > impossible to protect against. It MAY be configurable and MAY be > disabled on networks where there is some prior knowledge indicating > that the test is not necessary. > > -- > James Carlson, KISS Network > > Sun Microsystems / 1 Network Drive 71.232W Vox +1 > 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N 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