From owner-ietf-ppp@merit.edu Wed Jan 1 20:47:06 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16322 for ; Wed, 1 Jan 2003 20:47:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 67DC591203; Wed, 1 Jan 2003 20:50:02 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 39C079120A; Wed, 1 Jan 2003 20:50:02 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 00E2291203 for ; Wed, 1 Jan 2003 20:50:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id DC14D5DE76; Wed, 1 Jan 2003 20:50:00 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from tx2.wvinternetservices.com (tx2.wvinternetservices.com [66.118.65.7]) by segue.merit.edu (Postfix) with ESMTP id 60CB05DE5B for ; Wed, 1 Jan 2003 20:50:00 -0500 (EST) Received: from a (63-144-68-230.citynet.net [63.144.68.230]) by tx2.wvinternetservices.com (8.12.6/8.12.6=Outbound) with SMTP id h021iHqw019511 for ; Wed, 1 Jan 2003 20:44:18 -0500 Message-ID: <000701c2b200$fae12b40$e644903f@a> From: "Bill Cunningham" To: Subject: pptp Date: Wed, 1 Jan 2003 20:47:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Anybody know off hand what the rfc number for PPTP is? The rfc editor is being stubborn at www.rfc-editor.org and refuses to show me the rfc, it thinks it doesn't exist. From owner-ietf-ppp@merit.edu Wed Jan 1 21:12:21 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16497 for ; Wed, 1 Jan 2003 21:12:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 703459120A; Wed, 1 Jan 2003 21:15:12 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CCF0291217; Wed, 1 Jan 2003 21:15:11 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BB8109120A for ; Wed, 1 Jan 2003 21:15:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6F35E5DE95; Wed, 1 Jan 2003 21:15:08 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by segue.merit.edu (Postfix) with ESMTP id 2C8495DE3B for ; Wed, 1 Jan 2003 21:15:06 -0500 (EST) Received: from packetdesign.com (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id SAA21951; Wed, 1 Jan 2003 18:09:10 -0800 (PST) Message-ID: <3E139F0A.5060100@packetdesign.com> Date: Wed, 01 Jan 2003 18:08:10 -0800 From: Archie Cobbs User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021106 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Cunningham Cc: ietf-ppp@merit.edu Subject: Re: pptp References: <000701c2b200$fae12b40$e644903f@a> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Bill Cunningham wrote: > Anybody know off hand what the rfc number for PPTP is? The rfc editor is > being stubborn at www.rfc-editor.org and refuses to show me the rfc, it > thinks it doesn't exist. RFC 2637: http://www.ietf.org/rfc/rfc2637.txt -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com From owner-ietf-ppp@merit.edu Fri Jan 3 14:48:34 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17593 for ; Fri, 3 Jan 2003 14:48:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5B7459124C; Fri, 3 Jan 2003 14:50:12 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2ABDD9124F; Fri, 3 Jan 2003 14:50:12 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DB84D9124C for ; Fri, 3 Jan 2003 14:50:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id C3B045DF45; Fri, 3 Jan 2003 14:50:08 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from watervalley.net (mail.watervalley.net [12.168.164.3]) by segue.merit.edu (Postfix) with SMTP id 1CC055DD90 for ; Fri, 3 Jan 2003 14:50:08 -0500 (EST) Received: from [204.39.227.85] (HELO greendragon.com) by watervalley.net (Stalker SMTP Server 1.8b8) with ESMTP id S.0041802526; Fri, 03 Jan 2003 12:53:57 -0600 Message-ID: <3E15DC4A.9AD6E00B@greendragon.com> Date: Fri, 03 Jan 2003 13:54:32 -0500 From: William Allen Simpson Organization: DayDreamer X-Mailer: Mozilla 4.79 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ppp@merit.edu Subject: Re: PPP L2TP legal status References: <20021227203749.A10935@google.com> <20021228065858.GB55880@pit.databus.com> <15887.47564.208282.104058@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit James Carlson wrote: > > Glen Zorn writes: > > L2TP is is sole subject of RFC 2661. Cisco holds no IPR WRT L2TP, nor does > > it license it to or from anybody. > > I would very much like to hear a clear statement from Cisco's lawyers > on this subject. The last such public communication that I know of > was this one: > > http://www.ietf.org/ietf/IPR/CISCO-L2TP > > This certainly leaves the situation a lot less clear than you seem to > be indicating, at least to me. > > For what it's worth, I personally know several folks who've been > contacted by lawyers involved in L2TP IPR litigation (including > myself), and who are thus quite adverse to implementing any part of > that standard for that reason. Talking to lawyers about IPR is not an > enjoyable part of the job. If Cisco is not pursuing these claims, > then I think that'd be wonderful news to make known more widely so > that the standard can become more widely used. > I believe that it is public knowledge (and not in violation of any NDA) that Cisco has been pursuing claims against Alcatel for over 3 years now. The case has passed factual discovery, is in expert depositions, and is expected to go to trial in the near future. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 From owner-ietf-ppp@merit.edu Fri Jan 3 15:51:49 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18864 for ; Fri, 3 Jan 2003 15:51:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AA0759124E; Fri, 3 Jan 2003 15:54:44 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D8FC91251; Fri, 3 Jan 2003 15:54:44 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2F9C59124E for ; Fri, 3 Jan 2003 15:54:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 226F45DDD1; Fri, 3 Jan 2003 15:54:42 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id C81AD5DDCC for ; Fri, 3 Jan 2003 15:54:41 -0500 (EST) Received: from juniper.net (wawa.juniper.net [172.17.20.55]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h03KsYS55310; Fri, 3 Jan 2003 12:54:34 -0800 (PST) (envelope-from dennis@juniper.net) Message-Id: <200301032054.h03KsYS55310@merlot.juniper.net> X-Mailer: exmh version 2.0.2 2/24/98 To: fcusack@fcusack.com (Frank Cusack) Cc: Barney Wolff , ietf-ppp@merit.edu Subject: Re: PPP In-reply-to: Your message of "28 Dec 1902 04:37:49 GMT." <20021227203749.A10935@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 Jan 2003 12:54:34 -0800 From: Dennis Ferguson Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Frank Cusack wrote: > On Fri, Dec 27, 2002 at 10:00:33PM -0500, Barney Wolff wrote: > > On Fri, Dec 27, 2002 at 06:45:10PM -0800, Frank Cusack wrote: > > > > > > PPTP is not proprietary. L2TP is, though. > > > > You seem to have a very odd definition of proprietary. Both protocols > > are published, but PPTP is strictly under Microsoft's control, while > > L2TP is a standards-track IETF effort. If sourceforge is your criterion, > > both protocols are there. > > Yes, I guess I'm using a different (incorrect) definition of proprietary. > What I really meant was, PPTP is freely implementable. L2TP is not. > > I can write and publish an implementation of PPTP, without being beholden > to Microsoft whereas I must license L2TP from Cisco. Of course, please > correct me if Cisco has granted no-cost license terms to anyone for L2TP. I don't think the latter paragraphs describe the situation. Cisco has a patent which mentions neither PPTP nor L2TP, but which patents an application for which either PPTP or L2TP might be used. As such the patent, if it applies at all, applies equally to PPTP and L2TP when either is used for the application described in the patent's claims. PPTP is no less encumbered by this patent than L2TP. What this amounts to is that if your use of PPTP doesn't infringe on this patent then using L2TP for the same thing won't either, while if your use of L2TP does infringe on this patent then changing the protocol to PPTP won't save you. The patent provides no particular reason to prefer one protocol over the other since, for applications which infringe the patent, the patent will apply equally to both PPTP and L2TP. If I had to guess (I'm far from a lawyer) I suspect the patent claims apply not at all when the implementation does what RFC 3193 defines to be "Voluntary Tunneling", with the (LAC,PAC) residing on the client machine, but may apply when the implementation does "Compulsory Tunneling" with the LAC residing in the NAS. I suspect part of the confusion with respect to applicability of the patent may be that PPTP has seen the most use in the former application while L2TP has seen greater use in the latter application, but this should not be construed to mean there is something wrong with L2TP with respect to that patent which isn't wrong with PPTP. With respect to Cisco revealing that it may have IPR related to L2TP, but failing to make the same assertion with respect to PPTP, do not mistakenly take this to mean that Cisco thinks it has IPR related to L2TP but not to PPTP. The IETF only requires IPR disclosure when the owner of the IPR (or its employees) participates in the standard development. Since Cisco wasn't involved with the development of PPTP it had no requirement to disclose any IPR which might relate to that protocol even if Cisco felt it had some. If anything Cisco's disclosure is of (small) benefit to L2TP, since for L2TP they've at least asserted that they'll license the patent under openly-specified, reasonable and non-discriminatory terms, while for PPTP they are free to license the patent under secret, unreasonable or discriminatory terms, or not at all, if they choose. It is getting progressively harder to do anything at all without the risk of running afoul with someone's lawyers, but in this case I don't think either of these protocols has either advantage or disadvantage with respect to the IPR we know about. If your use of L2TP would infringe on this patent then using PPTP for the same thing would also infringe, so you might as well disregard this altogether when choosing between the protocols for a particular application. They are both equally (un)encumbered. Dennis Ferguson From owner-ietf-ppp@merit.edu Sat Jan 4 04:47:26 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08566 for ; Sat, 4 Jan 2003 04:47:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 68C6491205; Sat, 4 Jan 2003 04:50:23 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3CAA49122F; Sat, 4 Jan 2003 04:50:23 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F020591205 for ; Sat, 4 Jan 2003 04:50:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id D68EB5DFCD; Sat, 4 Jan 2003 04:50:21 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by segue.merit.edu (Postfix) with ESMTP id 728175DDC2 for ; Sat, 4 Jan 2003 04:50:21 -0500 (EST) Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.12.6/8.12.6) with ESMTP id h049oKhn018793; Sat, 4 Jan 2003 01:50:20 -0800 Received: from vger.corp.google.com (vger.corp.google.com [10.3.4.85]) by moma.corp.google.com (8.12.6/8.12.3) with ESMTP id h049oKef018062; Sat, 4 Jan 2003 01:50:20 -0800 Received: (from frank@localhost) by vger.corp.google.com (8.10.2/8.10.2) id h049oKZ21819; Sat, 4 Jan 2003 01:50:20 -0800 Date: Sat, 4 Jan 2003 01:50:20 -0800 From: Frank Cusack To: Dennis Ferguson Cc: ietf-ppp@merit.edu Subject: Re: PPP Message-ID: <20030104015020.A21782@google.com> References: <20021227203749.A10935@google.com> <200301032054.h03KsYS55310@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200301032054.h03KsYS55310@merlot.juniper.net>; from dennis@juniper.net on Fri, Jan 03, 2003 at 12:54:34PM -0800 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu On Fri, Jan 03, 2003 at 12:54:34PM -0800, Dennis Ferguson wrote: > If I had to guess (I'm far from a lawyer) I suspect the patent claims > apply not at all when the implementation does what RFC 3193 defines to > be "Voluntary Tunneling", with the (LAC,PAC) residing on the client > machine, but may apply when the implementation does "Compulsory > Tunneling" with the LAC residing in the NAS. Is it possible to implement a LNS which can only terminate voluntary mode tunnels? > It is getting progressively harder to do anything at all without > the risk of running afoul with someone's lawyers :~( /fc From owner-ietf-ppp@merit.edu Sat Jan 4 15:13:12 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15347 for ; Sat, 4 Jan 2003 15:13:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D23C39120C; Sat, 4 Jan 2003 15:15:48 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9DC8D91258; Sat, 4 Jan 2003 15:15:48 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8762E9120C for ; Sat, 4 Jan 2003 15:15:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6895E5DE94; Sat, 4 Jan 2003 15:15:47 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id DE4EA5DE16 for ; Sat, 4 Jan 2003 15:15:46 -0500 (EST) Received: from gwzw2k (sjc-vpn2-392.cisco.com [10.21.113.136]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id MAA19016; Sat, 4 Jan 2003 12:15:45 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Frank Cusack" , "Dennis Ferguson" Cc: Subject: RE: PPP Date: Sat, 4 Jan 2003 12:15:44 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20030104015020.A21782@google.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit > On Fri, Jan 03, 2003 at 12:54:34PM -0800, Dennis Ferguson wrote: > > If I had to guess (I'm far from a lawyer) I suspect the patent claims > > apply not at all when the implementation does what RFC 3193 defines to > > be "Voluntary Tunneling", with the (LAC,PAC) residing on the client > > machine, but may apply when the implementation does "Compulsory > > Tunneling" with the LAC residing in the NAS. > > Is it possible to implement a LNS which can only terminate voluntary > mode tunnels? > > > It is getting progressively harder to do anything at all without > > the risk of running afoul with someone's lawyers > > :~( As I understand it, it's actually very easy to avoid running afoul of Cisco's patent lawyers: just don't sue Cisco over your own IPR. I am obviously not a lawyer, either., but AFAIK Cisco only uses its patents in a defensive manner, as is the case w/Alcatel. > > /fc > > From owner-ietf-ppp@merit.edu Wed Jan 15 09:26:56 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28353 for ; Wed, 15 Jan 2003 09:26:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 73DDF912B1; Wed, 15 Jan 2003 09:29:05 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2EE34912B8; Wed, 15 Jan 2003 09:29:05 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DCF84912B1 for ; Wed, 15 Jan 2003 09:28:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id CA9665E10B; Wed, 15 Jan 2003 09:28:58 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by segue.merit.edu (Postfix) with ESMTP id 513265DE16 for ; Wed, 15 Jan 2003 09:28:58 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h0FESvlG023108 for ; Wed, 15 Jan 2003 07:28:57 -0700 (MST) Received: [from zgr01exm01.corp.mot.com (zgr01exm01.corp.mot.com [10.162.168.200]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA04152 for ; Wed, 15 Jan 2003 07:28:56 -0700 (MST)] Received: by zgr01exm01.corp.mot.com with Internet Mail Service (5.5.2656.59) id ; Wed, 15 Jan 2003 16:28:54 +0200 Message-ID: <332B652C3E8ED411A4EA00B0D049C44C937326@zgr01exm01.corp.mot.com> From: Salkintzis Apostolis-Y1026C To: ietf-ppp@merit.edu Subject: The EAP GPRS protocol Date: Wed, 15 Jan 2003 16:28:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-7" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Dear all, The following I-D has recently been submitted and relates to PPPEXT area. I would appreciate your comments. Title : The EAP GPRS Protocol (EAP-GPRS) Author(s) : A. Salkintzis Filename : draft-salki-pppext-eap-gprs-00.txt Pages : 21 Date : 2003-1-6 This document specifies an extension to the Extensible Authentication Protocol (EAP) [2], referred to as EAP-GPRS, which allows GPRS clients to perform signaling procedures with a core GPRS network through devices that enforce EAP-based access control. For example, a GPRS client can use EAP-GPRS to attach to a GPRS network through an access point that enforces IEEE 802.1X [3] access control. In this case, the GPRS attach signaling is performed in the context of the underlying 802.1X procedure and the GPRS messages are encapsulated into EAP-GPRS packets. If the GPRS client is permitted to attach to the GPRS network, then the 802.1X procedure ends successfully and the client is authorized access to the access point. In general, EAP-GPRS allows any type of signaling to take place during the EAP authentication as an embedded signaling procedure. However, in this documents we particularly focus on GPRS specific signaling. A URL for this Internet-Draft is: --- Dr. Apostolis Salkintzis Motorola Tel: +30-210-8172335 Fax: +30-210-6810168 E-mail: salki@motorola.com From owner-ietf-ppp@merit.edu Wed Jan 15 10:17:11 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29533 for ; Wed, 15 Jan 2003 10:17:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 24C3C912AB; Wed, 15 Jan 2003 10:20:16 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D801D912AE; Wed, 15 Jan 2003 10:20:15 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9B5A5912AB for ; Wed, 15 Jan 2003 10:20:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 872725DF14; Wed, 15 Jan 2003 10:20:14 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by segue.merit.edu (Postfix) with ESMTP id 82AFB5DF11 for ; Wed, 15 Jan 2003 10:20:13 -0500 (EST) Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0FFH10j007973; Wed, 15 Jan 2003 16:18:42 +0100 (MET) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: The EAP GPRS protocol Date: Wed, 15 Jan 2003 16:20:05 +0100 Message-ID: Thread-Topic: The EAP GPRS protocol Thread-Index: AcK8oqHMJO9vOh5STi6ZPrF17G20UQAA7fUw From: "Mark Grayson (mgrayson)" To: "Salkintzis Apostolis-Y1026C" , Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA29533 Apostolis Can you explain the differences between your proposal and http://www.ietf.org/internet-drafts/draft-buckley-pppext-eap-sim-gmm-00. txt. Do you propose to transport more than GMM messages between the peer and EAP server? If so how are Radio Resource messages processed - since these relate specifically to GSM/GPRS/UMTS radio bearers. Keeping my comments to GMM, I would say that the GMM state machine is quite complex for WLAN authentication: according to 24.008, 115 pages of mobility management elementary procedures, 27 pages of GMM messages and 22 pages of GMM information elements. Hence, the limited appeal to those interested in tight coupling, although even for tight coupling, alternative techniques exist, e.g., EAP-SIM. In addition, some of these GMM procedures require interaction with Radio Specific information, e.g., using GSM broadcast information to trigger transitioning between different values of GPRS Update Status, which are not defined for WLAN. Best regards, Mark ___________________________________________________ Mark Grayson Consulting Engineer World Wide Mobile Service Providers Cisco Systems IP Phone: +33 (0)1.58.04.31.24 GSM: +33 (0)6.19.98.40.99 -----Original Message----- From: Salkintzis Apostolis-Y1026C [mailto:salki@motorola.com] Sent: 15 January 2003 15:29 To: ietf-ppp@merit.edu Subject: The EAP GPRS protocol Dear all, The following I-D has recently been submitted and relates to PPPEXT area. I would appreciate your comments. Title : The EAP GPRS Protocol (EAP-GPRS) Author(s) : A. Salkintzis Filename : draft-salki-pppext-eap-gprs-00.txt Pages : 21 Date : 2003-1-6 This document specifies an extension to the Extensible Authentication Protocol (EAP) [2], referred to as EAP-GPRS, which allows GPRS clients to perform signaling procedures with a core GPRS network through devices that enforce EAP-based access control. For example, a GPRS client can use EAP-GPRS to attach to a GPRS network through an access point that enforces IEEE 802.1X [3] access control. In this case, the GPRS attach signaling is performed in the context of the underlying 802.1X procedure and the GPRS messages are encapsulated into EAP-GPRS packets. If the GPRS client is permitted to attach to the GPRS network, then the 802.1X procedure ends successfully and the client is authorized access to the access point. In general, EAP-GPRS allows any type of signaling to take place during the EAP authentication as an embedded signaling procedure. However, in this documents we particularly focus on GPRS specific signaling. A URL for this Internet-Draft is: --- Dr. Apostolis Salkintzis Motorola Tel: +30-210-8172335 Fax: +30-210-6810168 E-mail: salki@motorola.com From owner-ietf-ppp@merit.edu Wed Jan 15 12:09:10 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03536 for ; Wed, 15 Jan 2003 12:09:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0B9CA9125B; Wed, 15 Jan 2003 12:12:02 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C5420912B0; Wed, 15 Jan 2003 12:12:01 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AD1629125B for ; Wed, 15 Jan 2003 12:12:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9A9545E12F; Wed, 15 Jan 2003 12:12:00 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id 2EDEF5E0F2 for ; Wed, 15 Jan 2003 12:12:00 -0500 (EST) Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h0FHBxp5029835 for ; Wed, 15 Jan 2003 10:11:59 -0700 (MST) Received: [from zgr01exm01.corp.mot.com (zgr01exm01.corp.mot.com [10.162.168.200]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id KAA20517 for ; Wed, 15 Jan 2003 10:11:58 -0700 (MST)] Received: by zgr01exm01.corp.mot.com with Internet Mail Service (5.5.2656.59) id ; Wed, 15 Jan 2003 19:11:07 +0200 Message-ID: <332B652C3E8ED411A4EA00B0D049C44C937327@zgr01exm01.corp.mot.com> From: Salkintzis Apostolis-Y1026C To: "'Mark Grayson (mgrayson)'" Cc: ietf-ppp@merit.edu Subject: RE: The EAP GPRS protocol Date: Wed, 15 Jan 2003 19:11:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Mark, Thanks for your response. EAP GPRS is virtually a simple encapsulating scheme tailored for UMTS/GPRS terminals, which, in addition to UTRAN/GPRS interfaces, they support an 802.11 radio interface. Note that these terminals already implement the GMM protocol, hence EAP GPRS assumes that GMM is already there. Note also that, UMTS/GPRS terminals already implement L2 protocols (in particular the RRC in UMTS and the LLC in GPRS), which provide a L2 transport for GMM messages. EAP GPRS does not encapsulate directly the GMM messages but rather it encapsulates the corresponding RRC/LLC messages. This way, we exploit the data link services of RRC/LLC, which include sequence control, re-transmissions, enciphering, integrity checking, etc. In other words, EAP GRPS operates right below RRC (in UTRAN mode) or LLC (in GPRS mode). The goal of EAP GPRS is to allow UMTS terminals to move between UTRAN and WLAN access. Our assumption is that the WLAN is "tightly-coupled" to UMTS core network. In this scenario, EAP GPRS acts as a scheme that allows RRC/LLC packets to pass through WLAN devices that enforce 802.1x access control. One of the benefits of using EAP GPRS is that it is very simple. In theory, EAP GPRS can carry any type of traffic, not only RRC/LLC. I agree that RRC/LLC operation or even GMM operation is coupled to some parameters broadcast on UTRAN/GPRS radio interface. We are seeing this as a separate issue and we deliberately left it outside the scope of EAP GPRS. Best regards, Apostolis --- -----Original Message----- From: Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com] Sent: Wednesday, January 15, 2003 5:20 PM To: Salkintzis Apostolis-Y1026C; ietf-ppp@merit.edu Subject: RE: The EAP GPRS protocol Apostolis Can you explain the differences between your proposal and http://www.ietf.org/internet-drafts/draft-buckley-pppext-eap-sim-gmm-00. txt. Do you propose to transport more than GMM messages between the peer and EAP server? If so how are Radio Resource messages processed - since these relate specifically to GSM/GPRS/UMTS radio bearers. Keeping my comments to GMM, I would say that the GMM state machine is quite complex for WLAN authentication: according to 24.008, 115 pages of mobility management elementary procedures, 27 pages of GMM messages and 22 pages of GMM information elements. Hence, the limited appeal to those interested in tight coupling, although even for tight coupling, alternative techniques exist, e.g., EAP-SIM. In addition, some of these GMM procedures require interaction with Radio Specific information, e.g., using GSM broadcast information to trigger transitioning between different values of GPRS Update Status, which are not defined for WLAN. Best regards, Mark ___________________________________________________ Mark Grayson Consulting Engineer World Wide Mobile Service Providers Cisco Systems IP Phone: +33 (0)1.58.04.31.24 GSM: +33 (0)6.19.98.40.99 -----Original Message----- From: Salkintzis Apostolis-Y1026C [mailto:salki@motorola.com] Sent: 15 January 2003 15:29 To: ietf-ppp@merit.edu Subject: The EAP GPRS protocol Dear all, The following I-D has recently been submitted and relates to PPPEXT area. I would appreciate your comments. Title : The EAP GPRS Protocol (EAP-GPRS) Author(s) : A. Salkintzis Filename : draft-salki-pppext-eap-gprs-00.txt Pages : 21 Date : 2003-1-6 This document specifies an extension to the Extensible Authentication Protocol (EAP) [2], referred to as EAP-GPRS, which allows GPRS clients to perform signaling procedures with a core GPRS network through devices that enforce EAP-based access control. For example, a GPRS client can use EAP-GPRS to attach to a GPRS network through an access point that enforces IEEE 802.1X [3] access control. In this case, the GPRS attach signaling is performed in the context of the underlying 802.1X procedure and the GPRS messages are encapsulated into EAP-GPRS packets. If the GPRS client is permitted to attach to the GPRS network, then the 802.1X procedure ends successfully and the client is authorized access to the access point. In general, EAP-GPRS allows any type of signaling to take place during the EAP authentication as an embedded signaling procedure. However, in this documents we particularly focus on GPRS specific signaling. A URL for this Internet-Draft is: --- Dr. Apostolis Salkintzis Motorola Tel: +30-210-8172335 Fax: +30-210-6810168 E-mail: salki@motorola.com From owner-ietf-ppp@merit.edu Wed Jan 15 14:11:28 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06882 for ; Wed, 15 Jan 2003 14:11:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0994E91207; Wed, 15 Jan 2003 14:14:32 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C57E691262; Wed, 15 Jan 2003 14:14:31 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A4F5591207 for ; Wed, 15 Jan 2003 14:14:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 820D65E0F3; Wed, 15 Jan 2003 14:14:30 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from gateway.hns.com (gateway.hns.com [208.236.67.13]) by segue.merit.edu (Postfix) with ESMTP id 10EA85DE97 for ; Wed, 15 Jan 2003 14:14:30 -0500 (EST) Received: from excore1.hns.com (excore1.hns.com [139.85.52.104]) by gateway.hns.com (Switch-3.0.0/Switch-3.0.0) with ESMTP id h0FJEMPM002356; Wed, 15 Jan 2003 14:14:23 -0500 (EST) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore1.hns.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0FJE7110608; Wed, 15 Jan 2003 14:14:17 -0500 (EST) To: Thomas Narten Cc: border@hns.com, James Carlson , Karl Fox , ietf-ppp@merit.edu Subject: Re: draft-heath-ppp-v44-02.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: jheath@hns.com Date: Wed, 15 Jan 2003 11:14:03 -0800 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.10 |March 22, 2002) at 01/15/2003 02:12:20 PM, Serialize complete at 01/15/2003 02:12:20 PM Content-Type: text/plain; charset="us-ascii" X-Filtered: Sendmail MIME Filter v1.0.7 excore1.hns.com h0FJE7110608 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Thomas & James Sorry, I have been too busy to reply to the last email from James. The basic point of discussion is whether or not this ID should have the same sequence number and dictionary synchronization mechanisms that other PPP compression RFC's (like 1974, 1977, etc) have defined for those modes that require reliable, in-sequence delivery. Firstly, this ID does not require that PPP Reliable Transport or LAPB be used, it just requires a reliable, in-sequence mechanism of some kind. I can change the ID to make that more clear if necessary. Secondly, if such a reliable, in-sequence mechanism is not already in place, or is too complex to implement just for compression then the other option is to use Datagram Mode as defined in the ID which does not require a reliable, in-sequence mechanism. Albeit the compression ratio may not be quite as good. I could add the sequence number and dictionary synchronization mechanisms used by RFC'c 1974, 1977, etc. but in my mind that brings up a host of issues that need to be addressed as follows: - do real implementations of RFC 1974, for instance, use single or multiple compression history modes that require sequence numbers and dictionary sequencing? Or do most real implementations just go with no history and compress each packet individually such that reliable, in-sequence delivery is not required. - just adding a sequence number to each packet does not seem to resolve the problem. What does the peer decompression function do when it receives an out of sequence packet? It must somehow tell the peer compressor function that transmitted the packet and try to get the dictionary back into sync, which is why RFC1977 and others rely on Reset-Request and Reset-Ack CCP packets or on renegotiation of the Compression Control Protocol to indicate loss of sync between transmitter and receiver. In the meantime the decompressor function must discard all packets received until dictionary sync between the transmitter and receiver is restored. - do we really want the compression function to be discarding packets without any mechanism to have them re-transmitted by the PPP link? And expect a higher layer like TCP to recover? What if it is UDP? Compression is supposed to save bandwidth, and in my mind the compression function itself should not add to bandwidth usage by tossing out of sequence packets and requiring feedback messages to indicate loss of dictionary syncronization. It seems that in that case Datagram Mode would be better since even though the compression ratio may be slightly worse it may improve bandwidth efficiency in the long run over a more complex , potentially bandwidth wasting, mechanism. If the answer to these issues is that: (1) yes, in real implementations of RFC 1974 single and multi compression histories are used, i.e. sequencing is used (2) yes, rely on Reset-Request and Reset-Ack CCP packets or on renegotiation of the Compression Control Protocol and let the receiver discard packets in the meantime. We don't want to use Datagram Mode instead. (3) yes, we want the compression function to discard packets and let the higher layer worry about them, regardless of the possible affect on bandwidth. We don't want to use Datagram Mode instead. then end of discussion, I will add that same capability to the V.44 draft if that is what is needed to make sure V.44 is used over PPP in all of its operating modes. If the answer to those issues is no, then I recommend we change the ID to make it clear that Datagram Mode should be used in the absence of a reliable transport. V.44 gets excellent compression doesn't suffer as much as other algorithms when compressing one packet at a time. regards Jeff Thomas Narten 01/15/2003 09:14 AM To: jheath@hns.com cc: James Carlson , Karl Fox , border@hns.com Subject: Re: draft-heath-ppp-v44-02.txt Just to clarify the status of this, I'm assuming that the document is still under active discussion and I should continue to wait for more followup? I.e., it's not quite ready for publication as an RFC yet? Thomas From owner-ietf-ppp@merit.edu Wed Jan 15 14:31:14 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07419 for ; Wed, 15 Jan 2003 14:31:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4886F912B6; Wed, 15 Jan 2003 14:34:16 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3484D912B4; Wed, 15 Jan 2003 14:32:04 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3399C91262 for ; Wed, 15 Jan 2003 14:32:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 203B85E102; Wed, 15 Jan 2003 14:32:01 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id 39EAA5DDC6 for ; Wed, 15 Jan 2003 14:31:51 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06892; Wed, 15 Jan 2003 12:31:41 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0FJVe4t023209; Wed, 15 Jan 2003 14:31:40 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6) with ESMTP id h0FJVexO086200; Wed, 15 Jan 2003 14:31:40 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6/Submit) id h0FJVeoc086197; Wed, 15 Jan 2003 14:31:40 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15909.46876.420381.824752@gargle.gargle.HOWL> Date: Wed, 15 Jan 2003 14:31:40 -0500 From: James Carlson To: jheath@hns.com Cc: Thomas Narten , border@hns.com, Karl Fox , ietf-ppp@merit.edu Subject: Re: draft-heath-ppp-v44-02.txt In-Reply-To: jheath@hns.com's message of 15 January 2003 11:14:03 References: X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit jheath@hns.com writes: > Firstly, this ID does not require that PPP Reliable Transport or LAPB be > used, it just requires a reliable, in-sequence mechanism of some kind. I > can change the ID to make that more clear if necessary. OK, though that's still out of step with the other RFCs. If an implementation elects not to do LAP-B, does it know for certain that the underlying transport is reliable and in-sequence? > Secondly, if such a reliable, in-sequence mechanism is not already in > place, or is too complex to implement just for compression then the other > option is to use Datagram Mode as defined in the ID which does not require > a reliable, in-sequence mechanism. Albeit the compression ratio may not > be quite as good. Understood, though that's not what the other RFCs do. > - do real implementations of RFC 1974, for instance, use single or > multiple compression history modes that require sequence numbers and > dictionary sequencing? Or do most real implementations just go with no > history and compress each packet individually such that reliable, > in-sequence delivery is not required. All of the ones I've seen use a single history -- the multiple history stuff is (mostly) unnecessary. I haven't seen any taht default to packet-by-packet mode. It's too weak. > - just adding a sequence number to each packet does not seem to resolve > the problem. What does the peer decompression function do when it > receives an out of sequence packet? It must somehow tell the peer > compressor function that transmitted the packet and try to get the > dictionary back into sync, which is why RFC1977 and others rely on > Reset-Request and Reset-Ack CCP packets or on renegotiation of the > Compression Control Protocol to indicate loss of sync between transmitter > and receiver. In the meantime the decompressor function must discard all > packets received until dictionary sync between the transmitter and > receiver is restored. Right. That mechanism is already defined by RFC 1962. No extra work is required here. > - do we really want the compression function to be discarding packets > without any mechanism to have them re-transmitted by the PPP link? Yes. PPP is generally a datagram service. RFC 1662, for instance, does not retransmit on a CRC error. IP has a checksum and specifies no recovery procedured. I don't think this is necessarily different. > And > expect a higher layer like TCP to recover? What if it is UDP? Compression > is supposed to save bandwidth, and in my mind the compression function > itself should not add to bandwidth usage by tossing out of sequence > packets and requiring feedback messages to indicate loss of dictionary > syncronization. Right. A smart implementation of *any* compression algorithm needs to be able to disable compression (shutting down CCP) if it knows (by configuration) or can find out (by monitoring statistics) that life is going badly. > (1) yes, in real implementations of RFC 1974 single and multi compression > histories are used, i.e. sequencing is used Just single. > (2) yes, rely on Reset-Request and Reset-Ack CCP packets or on > renegotiation of the Compression Control Protocol and let the receiver > discard packets in the meantime. We don't want to use Datagram Mode > instead. Yes. > (3) yes, we want the compression function to discard packets and let the > higher layer worry about them, regardless of the possible affect on > bandwidth. We don't want to use Datagram Mode instead. More or less, yes. It's not that there's "no worry," but rather that the drop-everything-and-restart mechanism is intended to handle the *occasional* error in a reasonable way such that the link doesn't just fall apart. Note that doing this is more robust for a number of reasons. One of these reasons is that "reliable" links are *not* perfect. There are occasional implementation flaws and unrecovered errors, no matter how improbable. If, for the single history mode, you don't have a way of detecting unexpected problems, then the occasional DMA error (or some such idiopathic problem) will cause the link to lock up solid -- it will fail and not recover. Mechanisms that can recover from failures tend to be a little more stable in the field than ones that cannot. Obviously, some implementations are bound to be better than others; that's life. > If the answer to those issues is no, then I recommend we change the ID to > make it clear that Datagram Mode should be used in the absence of a > reliable transport. V.44 gets excellent compression doesn't suffer as > much as other algorithms when compressing one packet at a time. I'd recommend adding *either* a one or two octet header for a sequence number *or* a one or two octet trailer for some sort of check data based on the uncompressed datagram. Either of those will handle the problem. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Wed Jan 15 14:41:15 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07671 for ; Wed, 15 Jan 2003 14:41:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DF27191262; Wed, 15 Jan 2003 14:44:18 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A8C7D912B4; Wed, 15 Jan 2003 14:44:18 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A4D8891262 for ; Wed, 15 Jan 2003 14:44:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9311E5E127; Wed, 15 Jan 2003 14:44:17 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id B67425DDB4 for ; Wed, 15 Jan 2003 14:44:16 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.7.Beta0/8.12.7.Beta0) id h0FJhssm012272 env-from ; Wed, 15 Jan 2003 12:43:54 -0700 (MST) Date: Wed, 15 Jan 2003 12:43:54 -0700 (MST) From: Vernon Schryver Message-Id: <200301151943.h0FJhssm012272@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: draft-heath-ppp-v44-02.txt Cc: james.d.carlson@east.sun.com, karlfox@columbus.rr.com, narten@us.ibm.com References: Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: jheath@hns.com > ... > - just adding a sequence number to each packet does not seem to resolve > the problem. What does the peer decompression function do when it > receives an out of sequence packet? It must somehow tell the peer > compressor function that transmitted the packet and try to get the > dictionary back into sync, which is why RFC1977 and others rely on > Reset-Request and Reset-Ack CCP packets or on renegotiation of the > Compression Control Protocol to indicate loss of sync between transmitter > and receiver. In the meantime the decompressor function must discard all > packets received until dictionary sync between the transmitter and > receiver is restored. In practice that is not a problem. If your PPP link is so lossy that it causes significant CCP reset chatter, it also loses so many IP packets that application performance is terrible. > - do we really want the compression function to be discarding packets > without any mechanism to have them re-transmitted by the PPP link? And > expect a higher layer like TCP to recover? What if it is UDP? Compression > is supposed to save bandwidth, and in my mind the compression function > itself should not add to bandwidth usage by tossing out of sequence > packets and requiring feedback messages to indicate loss of dictionary > syncronization. It seems that in that case Datagram Mode would be better > since even though the compression ratio may be slightly worse it may > improve bandwidth efficiency in the long run over a more complex , > potentially bandwidth wasting, mechanism. That's the sort of question that deserves an engineering answer instead of mere gut feelings. A bigger issue concerns the need for a v.44 PPP compression scheme. The problem with v.44 has always been the LZW patent and Unisys license fees. That has also been the problem with BSD PPP compression (RFC 1977), because BSD PPP compression performs at least as well as the other existing compresion schemes and better than those currently most popular. When that patent finally expires this year, an implementor considering some sort of LZW PPP compression could choose RFC 1977 or your varient of v.44. Since RFC 1977 is already present in a non-trivial number of implementations, why would someone choose your varient of v.44? How does your scheme perform on typical data (for some reasonable definition of "typical")? In other words, if the PPP compression RFCs were not all Informational (due of terrible long ago actions by the IESG), it would be more appropriate to ask which of them should be moved to "Historic" (possibly including RFC 1977) than to consider adding to the CCP tower of babel. There are many minor problems with the text. For example, I can't tell what section 2.3.6 should mean. Is the necessary inflation of the LCP MTU 2 or 4? Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Wed Jan 15 15:18:37 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08846 for ; Wed, 15 Jan 2003 15:18:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 675E4912B5; Wed, 15 Jan 2003 15:21:33 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3910B912B7; Wed, 15 Jan 2003 15:21:33 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 14B57912B5 for ; Wed, 15 Jan 2003 15:21:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id E80C95DFCD; Wed, 15 Jan 2003 15:21:31 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from gateway.hns.com (gateway.hns.com [208.236.67.14]) by segue.merit.edu (Postfix) with ESMTP id 870F55DD98 for ; Wed, 15 Jan 2003 15:21:31 -0500 (EST) Received: from excore1.hns.com (excore1.hns.com [139.85.52.104]) by gateway.hns.com (Switch-3.0.0/Switch-3.0.0) with ESMTP id h0FKLG7c011965; Wed, 15 Jan 2003 15:21:16 -0500 (EST) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore1.hns.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0FKL1106803; Wed, 15 Jan 2003 15:21:01 -0500 (EST) To: James Carlson Cc: border@hns.com, ietf-ppp@merit.edu, Karl Fox , Thomas Narten Subject: Re: draft-heath-ppp-v44-02.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: jheath@hns.com Date: Wed, 15 Jan 2003 12:20:58 -0800 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.10 |March 22, 2002) at 01/15/2003 03:19:14 PM, Serialize complete at 01/15/2003 03:19:14 PM Content-Type: text/plain; charset="us-ascii" X-Filtered: Sendmail MIME Filter v1.0.7 excore1.hns.com h0FKL1106803 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu James thanks for your comments. I will change the ID to include the same type of sequence and recovery mechanisms used in other RFC's. It seems like you are also saying that no one will use what I describe as "Individual Link Mode" which is multiple histories over a PPP link. If that is true, do you think I should I just remove that mode. thanks Jeff James Carlson 01/15/2003 11:31 AM To: jheath@hns.com cc: Thomas Narten , border@hns.com, Karl Fox , ietf-ppp@merit.edu Subject: Re: draft-heath-ppp-v44-02.txt jheath@hns.com writes: > Firstly, this ID does not require that PPP Reliable Transport or LAPB be > used, it just requires a reliable, in-sequence mechanism of some kind. I > can change the ID to make that more clear if necessary. OK, though that's still out of step with the other RFCs. If an implementation elects not to do LAP-B, does it know for certain that the underlying transport is reliable and in-sequence? > Secondly, if such a reliable, in-sequence mechanism is not already in > place, or is too complex to implement just for compression then the other > option is to use Datagram Mode as defined in the ID which does not require > a reliable, in-sequence mechanism. Albeit the compression ratio may not > be quite as good. Understood, though that's not what the other RFCs do. > - do real implementations of RFC 1974, for instance, use single or > multiple compression history modes that require sequence numbers and > dictionary sequencing? Or do most real implementations just go with no > history and compress each packet individually such that reliable, > in-sequence delivery is not required. All of the ones I've seen use a single history -- the multiple history stuff is (mostly) unnecessary. I haven't seen any taht default to packet-by-packet mode. It's too weak. > - just adding a sequence number to each packet does not seem to resolve > the problem. What does the peer decompression function do when it > receives an out of sequence packet? It must somehow tell the peer > compressor function that transmitted the packet and try to get the > dictionary back into sync, which is why RFC1977 and others rely on > Reset-Request and Reset-Ack CCP packets or on renegotiation of the > Compression Control Protocol to indicate loss of sync between transmitter > and receiver. In the meantime the decompressor function must discard all > packets received until dictionary sync between the transmitter and > receiver is restored. Right. That mechanism is already defined by RFC 1962. No extra work is required here. > - do we really want the compression function to be discarding packets > without any mechanism to have them re-transmitted by the PPP link? Yes. PPP is generally a datagram service. RFC 1662, for instance, does not retransmit on a CRC error. IP has a checksum and specifies no recovery procedured. I don't think this is necessarily different. > And > expect a higher layer like TCP to recover? What if it is UDP? Compression > is supposed to save bandwidth, and in my mind the compression function > itself should not add to bandwidth usage by tossing out of sequence > packets and requiring feedback messages to indicate loss of dictionary > syncronization. Right. A smart implementation of *any* compression algorithm needs to be able to disable compression (shutting down CCP) if it knows (by configuration) or can find out (by monitoring statistics) that life is going badly. > (1) yes, in real implementations of RFC 1974 single and multi compression > histories are used, i.e. sequencing is used Just single. > (2) yes, rely on Reset-Request and Reset-Ack CCP packets or on > renegotiation of the Compression Control Protocol and let the receiver > discard packets in the meantime. We don't want to use Datagram Mode > instead. Yes. > (3) yes, we want the compression function to discard packets and let the > higher layer worry about them, regardless of the possible affect on > bandwidth. We don't want to use Datagram Mode instead. More or less, yes. It's not that there's "no worry," but rather that the drop-everything-and-restart mechanism is intended to handle the *occasional* error in a reasonable way such that the link doesn't just fall apart. Note that doing this is more robust for a number of reasons. One of these reasons is that "reliable" links are *not* perfect. There are occasional implementation flaws and unrecovered errors, no matter how improbable. If, for the single history mode, you don't have a way of detecting unexpected problems, then the occasional DMA error (or some such idiopathic problem) will cause the link to lock up solid -- it will fail and not recover. Mechanisms that can recover from failures tend to be a little more stable in the field than ones that cannot. Obviously, some implementations are bound to be better than others; that's life. > If the answer to those issues is no, then I recommend we change the ID to > make it clear that Datagram Mode should be used in the absence of a > reliable transport. V.44 gets excellent compression doesn't suffer as > much as other algorithms when compressing one packet at a time. I'd recommend adding *either* a one or two octet header for a sequence number *or* a one or two octet trailer for some sort of check data based on the uncompressed datagram. Either of those will handle the problem. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Wed Jan 15 15:38:27 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09382 for ; Wed, 15 Jan 2003 15:38:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 87F39912B8; Wed, 15 Jan 2003 15:41:31 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 53805912B7; Wed, 15 Jan 2003 15:41:31 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E05BE912B8 for ; Wed, 15 Jan 2003 15:41:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id B1E515E0A6; Wed, 15 Jan 2003 15:41:29 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from gateway.hns.com (gateway.hns.com [208.236.67.14]) by segue.merit.edu (Postfix) with ESMTP id 3B0185DFFB; Wed, 15 Jan 2003 15:41:29 -0500 (EST) Received: from excore1.hns.com (excore1.hns.com [139.85.52.104]) by gateway.hns.com (Switch-3.0.0/Switch-3.0.0) with ESMTP id h0FKYh7c013691; Wed, 15 Jan 2003 15:34:43 -0500 (EST) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore1.hns.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0FKYR111501; Wed, 15 Jan 2003 15:34:27 -0500 (EST) To: Vernon Schryver Cc: ietf-ppp@merit.edu, james.d.carlson@east.sun.com, karlfox@columbus.rr.com, narten@us.ibm.com, owner-ietf-ppp@merit.edu Subject: Re: draft-heath-ppp-v44-02.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: jheath@hns.com Date: Wed, 15 Jan 2003 12:34:25 -0800 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.10 |March 22, 2002) at 01/15/2003 03:32:40 PM, Serialize complete at 01/15/2003 03:32:40 PM Content-Type: text/plain; charset="us-ascii" X-Filtered: Sendmail MIME Filter v1.0.7 excore1.hns.com h0FKYR111501 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Vernon I think you are confusing V.44 compression with V.42bis compression. V.44 compression (i.e. LZJH) is sufficiently different from LZW that no Unisys or other LZW variant license fees are required for it's use. In answer to your question, V.44 in this environment gets anywhere from 20% to 200% better compression than LZW, and thus BSD PPP, depending on the data. For HTML, etc. type web pages it is closer to the 200%. V.44 also gets better compression than LZS by ~10%. With faster execution times. The substantial increase in compression ratios that LZJH gets over LZW is the reason the ITU adopted V.44 in the first place to replace V.42bis in modems. If you send me a list of the minor problems you see in the text I can fix them before releasing a new version. thanks Jeff Vernon Schryver Sent by: owner-ietf-ppp@merit.edu 01/15/2003 11:43 AM To: ietf-ppp@merit.edu cc: james.d.carlson@east.sun.com, karlfox@columbus.rr.com, narten@us.ibm.com Subject: Re: draft-heath-ppp-v44-02.txt > From: jheath@hns.com > ... > - just adding a sequence number to each packet does not seem to resolve > the problem. What does the peer decompression function do when it > receives an out of sequence packet? It must somehow tell the peer > compressor function that transmitted the packet and try to get the > dictionary back into sync, which is why RFC1977 and others rely on > Reset-Request and Reset-Ack CCP packets or on renegotiation of the > Compression Control Protocol to indicate loss of sync between transmitter > and receiver. In the meantime the decompressor function must discard all > packets received until dictionary sync between the transmitter and > receiver is restored. In practice that is not a problem. If your PPP link is so lossy that it causes significant CCP reset chatter, it also loses so many IP packets that application performance is terrible. > - do we really want the compression function to be discarding packets > without any mechanism to have them re-transmitted by the PPP link? And > expect a higher layer like TCP to recover? What if it is UDP? Compression > is supposed to save bandwidth, and in my mind the compression function > itself should not add to bandwidth usage by tossing out of sequence > packets and requiring feedback messages to indicate loss of dictionary > syncronization. It seems that in that case Datagram Mode would be better > since even though the compression ratio may be slightly worse it may > improve bandwidth efficiency in the long run over a more complex , > potentially bandwidth wasting, mechanism. That's the sort of question that deserves an engineering answer instead of mere gut feelings. A bigger issue concerns the need for a v.44 PPP compression scheme. The problem with v.44 has always been the LZW patent and Unisys license fees. That has also been the problem with BSD PPP compression (RFC 1977), because BSD PPP compression performs at least as well as the other existing compresion schemes and better than those currently most popular. When that patent finally expires this year, an implementor considering some sort of LZW PPP compression could choose RFC 1977 or your varient of v.44. Since RFC 1977 is already present in a non-trivial number of implementations, why would someone choose your varient of v.44? How does your scheme perform on typical data (for some reasonable definition of "typical")? In other words, if the PPP compression RFCs were not all Informational (due of terrible long ago actions by the IESG), it would be more appropriate to ask which of them should be moved to "Historic" (possibly including RFC 1977) than to consider adding to the CCP tower of babel. There are many minor problems with the text. For example, I can't tell what section 2.3.6 should mean. Is the necessary inflation of the LCP MTU 2 or 4? Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Wed Jan 15 15:39:19 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09403 for ; Wed, 15 Jan 2003 15:39:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D0C47912B7; Wed, 15 Jan 2003 15:42:16 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A427D912B9; Wed, 15 Jan 2003 15:42:16 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AA7F6912B7 for ; Wed, 15 Jan 2003 15:42:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 95FF65DFFB; Wed, 15 Jan 2003 15:42:15 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id F0EDB5DE97 for ; Wed, 15 Jan 2003 15:42:14 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22674; Wed, 15 Jan 2003 13:42:12 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0FKgC4t010555; Wed, 15 Jan 2003 15:42:12 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6) with ESMTP id h0FKgBxO086308; Wed, 15 Jan 2003 15:42:11 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6/Submit) id h0FKgBdO086305; Wed, 15 Jan 2003 15:42:11 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15909.51107.692136.884245@gargle.gargle.HOWL> Date: Wed, 15 Jan 2003 15:42:11 -0500 From: James Carlson To: jheath@hns.com Cc: border@hns.com, ietf-ppp@merit.edu, Karl Fox , Thomas Narten Subject: Re: draft-heath-ppp-v44-02.txt In-Reply-To: jheath@hns.com's message of 15 January 2003 12:20:58 References: X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit jheath@hns.com writes: > thanks for your comments. I will change the ID to include the same type > of sequence and recovery mechanisms used in other RFC's. > > It seems like you are also saying that no one will use what I describe as > "Individual Link Mode" which is multiple histories over a PPP link. If > that is true, do you think I should I just remove that mode. Thanks for pointing that out; I'd missed that on the first read of the draft because I'd incorrectly assumed that this was just a redocumenting of RFC 1962 "Individual Link" mode operation. It's apparently not. For RFC 1962 individual link compression, each link is independent, and the peers need to negotiate CCP 80FB independently on each link. The mechanism described in this draft appears to be different. If I understand it correctly, CCP using 80FB is being negotiated once at the bundle level (meaning that all links must then use it), and the multiple dictionaries feature is used to separate out the traffic. Why does this draft redefine CCP operation in this way? How does the initial negotiator predict how many dictionaries might be needed? What happens if the allocated number of dictionaries is exceeded when MP link N+1 joins the bundle? -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Wed Jan 15 15:53:12 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09655 for ; Wed, 15 Jan 2003 15:53:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D3EDF912BB; Wed, 15 Jan 2003 15:56:08 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9344A912BA; Wed, 15 Jan 2003 15:56:08 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1E552912B9 for ; Wed, 15 Jan 2003 15:56:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id EB9DE5E00A; Wed, 15 Jan 2003 15:56:05 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 188B15DF3F; Wed, 15 Jan 2003 15:56:05 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.7.Beta0/8.12.7.Beta0) id h0FKtjof020396 env-from ; Wed, 15 Jan 2003 13:55:45 -0700 (MST) Date: Wed, 15 Jan 2003 13:55:45 -0700 (MST) From: Vernon Schryver Message-Id: <200301152055.h0FKtjof020396@calcite.rhyolite.com> To: jheath@hns.com Subject: Re: draft-heath-ppp-v44-02.txt Cc: ietf-ppp@merit.edu, james.d.carlson@east.sun.com, karlfox@columbus.rr.com, narten@us.ibm.com, owner-ietf-ppp@merit.edu References: Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: jheath@hns.com > ... > I think you are confusing V.44 compression with V.42bis compression. V.44 > compression (i.e. LZJH) is sufficiently different from LZW that no Unisys > or other LZW variant license fees are required for it's use. oh. > In answer to your question, V.44 in this environment gets anywhere from > 20% to 200% better compression than LZW, and thus BSD PPP, depending on > the data. For HTML, etc. type web pages it is closer to the 200%. V.44 > also gets better compression than LZS by ~10%. With faster execution > times. On which corpus was this measured and with which PPP implementations? When comparing to LZW, what size dictionary was used, the typical, barely useful 9 or 10-bit of v.42bis or something reasonable? I ask because the archives of this mailing list have plenty of marketing statements of compression performance (made up facts), although not as many as in the open literature (trade rags). I also ask because your numbers seem backwards. LZS as it is in PPP is a terrible compression scheme compared to others including LZW. I cannot imagine something bettering LZS by only 10% but LZW with a reasonable dictionary by 200%. For that matter, I cannot imagine anything beating LZW with a reasonable dictionary size by 200%. There simply is not that much entropy in LZW output, unless you do something dishonest such as using 9-bit codes or clearing the dictionary on every packet. > The substantial increase in compression ratios that LZJH gets over LZW is > the reason the ITU adopted V.44 in the first place to replace V.42bis in > modems. > ... I don't want to offend anyone, but the ITU is at least as bad as any other standards organization and frequently (or almost always) makes decisions for one set of reasons (e.g. patent fees) while claiming to have other reasons. In a case like this, what the ITU thinks is completely irrelevant. What does matter is measured performance and the recipes for evalutating and repeating those measurements. The bigger question remains. Is the de facto choice of LZS good enough, bad as it is on compression effectiveness grounds? Is v.44 enough better to justify adding to the CCP babel? How many implementations of v.44 PPP compression can reasonably be expected given the market dominence of LZS? Finally, I have a question about the expected status of a v.44 RFC. It would be Informational, right? Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Wed Jan 15 16:06:44 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10027 for ; Wed, 15 Jan 2003 16:06:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2C9C2912B9; Wed, 15 Jan 2003 16:09:51 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EC461912BA; Wed, 15 Jan 2003 16:09:50 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D222F912B9 for ; Wed, 15 Jan 2003 16:09:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id B959E5E000; Wed, 15 Jan 2003 16:09:49 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from gateway.hns.com (gateway.hns.com [208.236.67.14]) by segue.merit.edu (Postfix) with ESMTP id 540995DDBB for ; Wed, 15 Jan 2003 16:09:49 -0500 (EST) Received: from excore1.hns.com (excore1.hns.com [139.85.52.104]) by gateway.hns.com (Switch-3.0.0/Switch-3.0.0) with ESMTP id h0FL9d7c018974; Wed, 15 Jan 2003 16:09:40 -0500 (EST) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore1.hns.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0FL9O125486; Wed, 15 Jan 2003 16:09:24 -0500 (EST) To: James Carlson Cc: border@hns.com, ietf-ppp@merit.edu, Karl Fox , Thomas Narten Subject: Re: draft-heath-ppp-v44-02.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: jheath@hns.com Date: Wed, 15 Jan 2003 13:09:21 -0800 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.10 |March 22, 2002) at 01/15/2003 04:07:38 PM, Serialize complete at 01/15/2003 04:07:38 PM Content-Type: text/plain; charset="us-ascii" X-Filtered: Sendmail MIME Filter v1.0.7 excore1.hns.com h0FL9O125486 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu James It looks like I misunderstood the way a multi-link bundle is negotiated via CCP. If they are separately negotiated, as you say, then Individual Link Mode is not defined correctly. In fact that mode is probably not necessary at all since each link can negotiate and use Multi-Datagram mode, providing a history number is not needed to keep the links separate at the receiver. Maybe the best thing would be to remove Individual Link Mode if multiple histories are not used in real PPP implementations anyway. thanks Jeff James Carlson 01/15/2003 12:42 PM To: jheath@hns.com cc: border@hns.com, ietf-ppp@merit.edu, Karl Fox , Thomas Narten Subject: Re: draft-heath-ppp-v44-02.txt jheath@hns.com writes: > thanks for your comments. I will change the ID to include the same type > of sequence and recovery mechanisms used in other RFC's. > > It seems like you are also saying that no one will use what I describe as > "Individual Link Mode" which is multiple histories over a PPP link. If > that is true, do you think I should I just remove that mode. Thanks for pointing that out; I'd missed that on the first read of the draft because I'd incorrectly assumed that this was just a redocumenting of RFC 1962 "Individual Link" mode operation. It's apparently not. For RFC 1962 individual link compression, each link is independent, and the peers need to negotiate CCP 80FB independently on each link. The mechanism described in this draft appears to be different. If I understand it correctly, CCP using 80FB is being negotiated once at the bundle level (meaning that all links must then use it), and the multiple dictionaries feature is used to separate out the traffic. Why does this draft redefine CCP operation in this way? How does the initial negotiator predict how many dictionaries might be needed? What happens if the allocated number of dictionaries is exceeded when MP link N+1 joins the bundle? -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Wed Jan 15 16:25:11 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10561 for ; Wed, 15 Jan 2003 16:25:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2629F912BA; Wed, 15 Jan 2003 16:28:16 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EE00F912BC; Wed, 15 Jan 2003 16:28:15 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EC2F3912BA for ; Wed, 15 Jan 2003 16:28:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id D1BCB5E00A; Wed, 15 Jan 2003 16:28:14 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id 38D085DF92 for ; Wed, 15 Jan 2003 16:28:14 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21452; Wed, 15 Jan 2003 14:28:12 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0FLSB4t021694; Wed, 15 Jan 2003 16:28:11 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6) with ESMTP id h0FLSBxO086491; Wed, 15 Jan 2003 16:28:11 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6/Submit) id h0FLSBrU086488; Wed, 15 Jan 2003 16:28:11 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15909.53867.384304.253391@gargle.gargle.HOWL> Date: Wed, 15 Jan 2003 16:28:11 -0500 From: James Carlson To: jheath@hns.com Cc: border@hns.com, ietf-ppp@merit.edu, Karl Fox , Thomas Narten Subject: Re: draft-heath-ppp-v44-02.txt In-Reply-To: jheath@hns.com's message of 15 January 2003 13:09:21 References: X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit jheath@hns.com writes: > It looks like I misunderstood the way a multi-link bundle is negotiated > via CCP. If they are separately negotiated, RFC 1962: 2.1. Sending Compressed Datagrams [...] When using multiple PPP links to a single destination, there are two methods of employing data compression. The first method is to compress the data prior to sending it out through the multiple links. The second is to treat each link as a separate connection, that may or may not have compression enabled. In the second case, the PPP Protocol field MUST be type hex 00FB (Individual link compressed datagram). RFC 1990: 5. PPP Link Control Protocol Extensions [...] Compression may be used separately on each member link, or run over the bundle (as a logical group link). The use of multiple compression streams under the bundle (i.e., on each link separately) is indicated by running the Compression Control Protocol [5] but with an alternative PPP protocol ID. > as you say, then Individual > Link Mode is not defined correctly. In fact that mode is probably not > necessary at all since each link can negotiate and use Multi-Datagram > mode, providing a history number is not needed to keep the links separate > at the receiver. Correct. > Maybe the best thing would be to remove Individual Link Mode if multiple > histories are not used in real PPP implementations anyway. I can't say I've ever seen it used, except when doing testing. ;-} The problem is that (in implementation) you need to have a reason to want to use one history over another when deciding how to compress a given packet. Other than hashing over the 5-tuple (and hoping that the flows related to incompressible data cause only *some* of your histories to thrash), I haven't seen any concrete ideas put forward. Given the environments in which data compression is used (i.e., lower speed links often associated with small numbers of users and flows), it's not clear that there are important benefits to be gained. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Wed Jan 15 18:49:20 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14991 for ; Wed, 15 Jan 2003 18:49:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8F5E7912BE; Wed, 15 Jan 2003 18:52:24 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5CE31912BF; Wed, 15 Jan 2003 18:52:24 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C745B912BE for ; Wed, 15 Jan 2003 18:52:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9AC815E14D; Wed, 15 Jan 2003 18:52:22 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from gateway.hns.com (gateway.hns.com [208.236.67.14]) by segue.merit.edu (Postfix) with ESMTP id 274875DF23; Wed, 15 Jan 2003 18:52:22 -0500 (EST) Received: from excore1.hns.com (excore1.hns.com [139.85.52.104]) by gateway.hns.com (Switch-3.0.0/Switch-3.0.0) with ESMTP id h0FNqG7c009709; Wed, 15 Jan 2003 18:52:16 -0500 (EST) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore1.hns.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0FNq0126532; Wed, 15 Jan 2003 18:52:00 -0500 (EST) To: Vernon Schryver Cc: ietf-ppp@merit.edu, james.d.carlson@east.sun.com, karlfox@columbus.rr.com, narten@us.ibm.com, owner-ietf-ppp@merit.edu Subject: Re: draft-heath-ppp-v44-02.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: jheath@hns.com Date: Wed, 15 Jan 2003 15:51:57 -0800 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.10 |March 22, 2002) at 01/15/2003 06:50:14 PM, Serialize complete at 01/15/2003 06:50:14 PM Content-Type: text/plain; charset="us-ascii" X-Filtered: Sendmail MIME Filter v1.0.7 excore1.hns.com h0FNq0126532 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Vernon I am talking about apples to apples comparisons over a packet network environment where a stream of IP sized 1500 byte packets is compressed between two peers where: --- typical internet data is used, such as mail, HTML, word, etc. files. From actual mail folders and web HTML's, etc. --- comparable memory usage for each algorithm. Thus a LZS 2048 history is compared to LZW (V.42bis) 2048 dictionary (11 bits) and LZJH (V.44) 2048 dictionary (11 bits) such that with tables, etc. the memory usage is roughly equal +/- 20%. In that environment LZS and LZJH both get better compression than LZW (in all my testing over the past 3 years) and LZJH gets better than LZS. LZS supports only a 2048 history so I guess if you compare it to LZW with a 15 bit word size (32K dictionary) then it would do better than LZS. I have also tested LZW and LZJH against a LZS clone that supports various history sizes and the results were similiar using comparable history and dictionary sizes. Using the above I have compared LZJH with LZW for all dictionary sizes up through 13 bits and LZJH is clearly a superior algorithm. While a 200% improvement with LZJH certainly is not normal and is only with some highly compressible files, almost all HTML will provide 60% - 100% improvement. In an environment where the dictionary is cleared after every IP packet LZW is very inferior to LZJH and LZS. I agree that there are plenty of claims of compression performance all over the place. That is why you have to bound MIP's and memory to get an apples to apples comparison. You can trash the ITU if you please but they were at least forward looking enough to: --- require competing compression algorithms to get at least 20% better compression than V.42bis over a set of typical internet files while using no more than 20% more MIP's and no more than 20% more memory than V.42bis (i.e. the new algorithm had to run on existing hardware). Tests were run using dictionary sizes from 512 through 8192. --- recognize that LZJH was a better compression solution and adopt it as V.44 despite the fact that virtually 100% of the worlds modems at that time had V.42bis. They felt that as new modems were built V.44 would be phased in. The fact that V.42bis was the current de facto choice did not stop the ITU from adopting something better. --- recognize that the Calgary and Canterbury corpus were not representative of data being downloaded in todays internet and create a set of test files that are representative. --- run comparison tests against HTML files from web sites worldwide with many different languages. I would assume that the IETF is forward looking enough want to allow PPP implementors the choice if something better comes along regardless of the number of current CCP options and regardless of a current de facto choice. Most will run their own comparisons and decide for themselves which is best based on MIP's, memory, or other contraints which they may have. I would be happy to provide you with the source of LZJH if you want to run your own comparisons. Yes, it is going to be an Informational RFC. Jeff Vernon Schryver Sent by: owner-ietf-ppp@merit.edu 01/15/2003 12:55 PM To: jheath@hns.com cc: ietf-ppp@merit.edu, james.d.carlson@east.sun.com, karlfox@columbus.rr.com, narten@us.ibm.com, owner-ietf-ppp@merit.edu Subject: Re: draft-heath-ppp-v44-02.txt > From: jheath@hns.com > ... > I think you are confusing V.44 compression with V.42bis compression. V.44 > compression (i.e. LZJH) is sufficiently different from LZW that no Unisys > or other LZW variant license fees are required for it's use. oh. > In answer to your question, V.44 in this environment gets anywhere from > 20% to 200% better compression than LZW, and thus BSD PPP, depending on > the data. For HTML, etc. type web pages it is closer to the 200%. V.44 > also gets better compression than LZS by ~10%. With faster execution > times. On which corpus was this measured and with which PPP implementations? When comparing to LZW, what size dictionary was used, the typical, barely useful 9 or 10-bit of v.42bis or something reasonable? I ask because the archives of this mailing list have plenty of marketing statements of compression performance (made up facts), although not as many as in the open literature (trade rags). I also ask because your numbers seem backwards. LZS as it is in PPP is a terrible compression scheme compared to others including LZW. I cannot imagine something bettering LZS by only 10% but LZW with a reasonable dictionary by 200%. For that matter, I cannot imagine anything beating LZW with a reasonable dictionary size by 200%. There simply is not that much entropy in LZW output, unless you do something dishonest such as using 9-bit codes or clearing the dictionary on every packet. > The substantial increase in compression ratios that LZJH gets over LZW is > the reason the ITU adopted V.44 in the first place to replace V.42bis in > modems. > ... I don't want to offend anyone, but the ITU is at least as bad as any other standards organization and frequently (or almost always) makes decisions for one set of reasons (e.g. patent fees) while claiming to have other reasons. In a case like this, what the ITU thinks is completely irrelevant. What does matter is measured performance and the recipes for evalutating and repeating those measurements. The bigger question remains. Is the de facto choice of LZS good enough, bad as it is on compression effectiveness grounds? Is v.44 enough better to justify adding to the CCP babel? How many implementations of v.44 PPP compression can reasonably be expected given the market dominence of LZS? Finally, I have a question about the expected status of a v.44 RFC. It would be Informational, right? Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Wed Jan 15 19:22:34 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15715 for ; Wed, 15 Jan 2003 19:22:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A848D912BF; Wed, 15 Jan 2003 19:25:38 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 71C46912C1; Wed, 15 Jan 2003 19:25:38 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1CC6F912BF for ; Wed, 15 Jan 2003 19:25:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id EAC985E14D; Wed, 15 Jan 2003 19:25:36 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 10BB65DD9A; Wed, 15 Jan 2003 19:25:36 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.7.Beta0/8.12.7.Beta0) id h0G0PQxn022761 env-from ; Wed, 15 Jan 2003 17:25:26 -0700 (MST) Date: Wed, 15 Jan 2003 17:25:26 -0700 (MST) From: Vernon Schryver Message-Id: <200301160025.h0G0PQxn022761@calcite.rhyolite.com> To: jheath@hns.com Subject: Re: draft-heath-ppp-v44-02.txt Cc: ietf-ppp@merit.edu, james.d.carlson@east.sun.com, karlfox@columbus.rr.com, narten@us.ibm.com, owner-ietf-ppp@merit.edu Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: jheath@hns.com > ... > I am talking about apples to apples comparisons over a packet network > environment where a stream of IP sized 1500 byte packets is compressed > between two peers where: > --- typical internet data is used, such as mail, HTML, word, etc. files. > >From actual mail folders and web HTML's, etc. > --- comparable memory usage for each algorithm. Thus a LZS 2048 history > is compared to LZW (V.42bis) 2048 dictionary (11 bits) and LZJH (V.44) > 2048 dictionary (11 bits) such that with tables, etc. the memory usage is > roughly equal +/- 20%. > > In that environment LZS and LZJH both get better compression than LZW (in > all my testing over the past 3 years) and LZJH gets better than LZS. LZS > supports only a 2048 history so I guess if you compare it to LZW with a 15 > bit word size (32K dictionary) then it would do better than LZS. I have > also tested LZW and LZJH against a LZS clone that supports various history > sizes and the results were similiar using comparable history and > dictionary sizes. I still wonder about the PPP implementations you tested, because I'm not sure you are comparing apples (PPP compression) to apples (PPP compression) instead of grapes (bulk compression such as LZS) to watermelons (modem v.42bis). I do not recall hearing of a PPP implementation that used v.42bis CCP propsoal. For that matter, I don't recall that the v.42vis CCP proposal ever made it to an RFC. Yes, in theory it is possible to make comparisons of PPP compression outside complete implementations, but historically most such comparisons have been at best based on obviously false and grossly misleading assumptions. A typical bogus assumption is to assume that there are no TCP/IP headers among the data. > Using the above I have compared LZJH with LZW for all dictionary sizes up > through 13 bits and LZJH is clearly a superior algorithm. While a 200% > improvement with LZJH certainly is not normal and is only with some highly > compressible files, almost all HTML will provide 60% - 100% improvement. Please be more specific about the 200% difference between LZJH and LZW. Frankly, I do not believe that is possible in an honest, apples-to-apples comparison. I can believe no-history LZJH might do 200% better than 9 or 10-bit no-history LZW (clear on every packet), but no one would implement such a silly thing. > In an environment where the dictionary is cleared after every IP packet > LZW is very inferior to LZJH and LZS. Yes, but who cares about contrived and irrelevant tests? An apples-to-apples comparison must be among RFC 1977, RFC 1967, and something like your proposal. > I agree that there are plenty of claims of compression performance all > over the place. That is why you have to bound MIP's and memory to get an > apples to apples comparison. You can trash the ITU if you please but > they were at least forward looking enough to: > --- require competing compression algorithms to get at least 20% better > compression than V.42bis over a set of typical internet files while using > no more than 20% more MIP's and no more than 20% more memory than V.42bis > (i.e. the new algorithm had to run on existing hardware). Tests were run > using dictionary sizes from 512 through 8192. I hoped to make clear that I don't think the ITU is significantly vulnerable to smoke, mirrors, and marketing baloney than any other standards organization including the IETF. It is good to do tests, but they must be as you say, apples-to-apples. Comparing v.42bis to your CCP-LZJH implies nothing about how your CCP-LZJH compares to any IETF PPP compression protocol that I can see. > --- recognize that LZJH was a better compression solution and adopt it as > V.44 despite the fact that virtually 100% of the worlds modems at that > time had V.42bis. They felt that as new modems were built V.44 would be > phased in. The fact that V.42bis was the current de facto choice did not > stop the ITU from adopting something better. That is a point in favor of the ITU only if you assume your conclusion, that LZJH is better than v.42bis. I'm inclined to assume that LZJH is better than v.42bis, but that's not relevant to anything I see. > --- recognize that the Calgary and Canterbury corpus were not > representative of data being downloaded in todays internet and create a > set of test files that are representative. If you look at the archives for this mailing list, you'll find that those were not the only sets of test data consider or even the most influental. > --- run comparison tests against HTML files from web sites worldwide with > many different languages. That strikes me as a distinctly minor and probably bogus consideration for the test sets. Picking the test data is not easy, but it is quite wrong to involve political correctness. > I would assume that the IETF is forward looking enough want to allow PPP > implementors the choice if something better comes along regardless of the > number of current CCP options and regardless of a current de facto choice. > Most will run their own comparisons and decide for themselves which is > best based on MIP's, memory, or other contraints which they may have. That is mistaken. In the network world outside the ISO or ITU dream world, considerations of MIPs, memory, and so forth are minor compared to other issues starting with interoperation. (Yes, *this* is a slap at the standard old ISO OSI/ITU delusions of grandure that what a standards committee considers important and desirable must matter outside hotel meeting rooms.) > I would be happy to provide you with the source of LZJH if you want to run > your own comparisons. Thanks, but I trust that if you did apples-to-apples comparison, you would report the results accurately. > Yes, it is going to be an Informational RFC. That short-circuits most of my concerns. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Wed Jan 15 20:00:47 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16676 for ; Wed, 15 Jan 2003 20:00:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1795E912C0; Wed, 15 Jan 2003 20:03:52 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D5153912C1; Wed, 15 Jan 2003 20:03:51 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 434D4912C0 for ; Wed, 15 Jan 2003 20:02:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1A0EB5E152; Wed, 15 Jan 2003 20:02:29 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from gateway.hns.com (gateway.hns.com [208.236.67.13]) by segue.merit.edu (Postfix) with ESMTP id 3209C5E004; Wed, 15 Jan 2003 20:02:15 -0500 (EST) Received: from excore1.hns.com (excore1.hns.com [139.85.52.104]) by gateway.hns.com (Switch-3.0.0/Switch-3.0.0) with ESMTP id h0G11A7c015729; Wed, 15 Jan 2003 20:01:10 -0500 (EST) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore1.hns.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0G10w115342; Wed, 15 Jan 2003 20:00:58 -0500 (EST) To: Vernon Schryver Cc: ietf-ppp@merit.edu, james.d.carlson@east.sun.com, karlfox@columbus.rr.com, narten@us.ibm.com, owner-ietf-ppp@merit.edu Subject: Re: draft-heath-ppp-v44-02.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: jheath@hns.com Date: Wed, 15 Jan 2003 17:00:56 -0800 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.10 |March 22, 2002) at 01/15/2003 07:59:08 PM, Serialize complete at 01/15/2003 07:59:08 PM Content-Type: text/plain; charset="us-ascii" X-Filtered: Sendmail MIME Filter v1.0.7 excore1.hns.com h0G10w115342 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu I don't think this is getting us anywhere. I have only seen the 200% plus improvement on a couple very highly compressible files so it is very atypical, forget I mentioned it. But I am not going to back down on the claim of 20% to 100% improvement LZJH gets over LZW on typical internet data, regardless of TCP, IP, PPP, etc. headers. I have tested with and without such headers in the data. PPP or any other packet protocol isn't going to change the basic fact that LZJH is a superior algorithm and if you knew the differences between LZJH and LZW you would readily understand why. I am going to update the draft per James Carlsons comments and we can go from there. Jeff Vernon Schryver 01/15/2003 04:25 PM To: jheath@hns.com cc: ietf-ppp@merit.edu, james.d.carlson@east.sun.com, karlfox@columbus.rr.com, narten@us.ibm.com, owner-ietf-ppp@merit.edu Subject: Re: draft-heath-ppp-v44-02.txt > From: jheath@hns.com > ... > I am talking about apples to apples comparisons over a packet network > environment where a stream of IP sized 1500 byte packets is compressed > between two peers where: > --- typical internet data is used, such as mail, HTML, word, etc. files. > >From actual mail folders and web HTML's, etc. > --- comparable memory usage for each algorithm. Thus a LZS 2048 history > is compared to LZW (V.42bis) 2048 dictionary (11 bits) and LZJH (V.44) > 2048 dictionary (11 bits) such that with tables, etc. the memory usage is > roughly equal +/- 20%. > > In that environment LZS and LZJH both get better compression than LZW (in > all my testing over the past 3 years) and LZJH gets better than LZS. LZS > supports only a 2048 history so I guess if you compare it to LZW with a 15 > bit word size (32K dictionary) then it would do better than LZS. I have > also tested LZW and LZJH against a LZS clone that supports various history > sizes and the results were similiar using comparable history and > dictionary sizes. I still wonder about the PPP implementations you tested, because I'm not sure you are comparing apples (PPP compression) to apples (PPP compression) instead of grapes (bulk compression such as LZS) to watermelons (modem v.42bis). I do not recall hearing of a PPP implementation that used v.42bis CCP propsoal. For that matter, I don't recall that the v.42vis CCP proposal ever made it to an RFC. Yes, in theory it is possible to make comparisons of PPP compression outside complete implementations, but historically most such comparisons have been at best based on obviously false and grossly misleading assumptions. A typical bogus assumption is to assume that there are no TCP/IP headers among the data. > Using the above I have compared LZJH with LZW for all dictionary sizes up > through 13 bits and LZJH is clearly a superior algorithm. While a 200% > improvement with LZJH certainly is not normal and is only with some highly > compressible files, almost all HTML will provide 60% - 100% improvement. Please be more specific about the 200% difference between LZJH and LZW. Frankly, I do not believe that is possible in an honest, apples-to-apples comparison. I can believe no-history LZJH might do 200% better than 9 or 10-bit no-history LZW (clear on every packet), but no one would implement such a silly thing. > In an environment where the dictionary is cleared after every IP packet > LZW is very inferior to LZJH and LZS. Yes, but who cares about contrived and irrelevant tests? An apples-to-apples comparison must be among RFC 1977, RFC 1967, and something like your proposal. > I agree that there are plenty of claims of compression performance all > over the place. That is why you have to bound MIP's and memory to get an > apples to apples comparison. You can trash the ITU if you please but > they were at least forward looking enough to: > --- require competing compression algorithms to get at least 20% better > compression than V.42bis over a set of typical internet files while using > no more than 20% more MIP's and no more than 20% more memory than V.42bis > (i.e. the new algorithm had to run on existing hardware). Tests were run > using dictionary sizes from 512 through 8192. I hoped to make clear that I don't think the ITU is significantly vulnerable to smoke, mirrors, and marketing baloney than any other standards organization including the IETF. It is good to do tests, but they must be as you say, apples-to-apples. Comparing v.42bis to your CCP-LZJH implies nothing about how your CCP-LZJH compares to any IETF PPP compression protocol that I can see. > --- recognize that LZJH was a better compression solution and adopt it as > V.44 despite the fact that virtually 100% of the worlds modems at that > time had V.42bis. They felt that as new modems were built V.44 would be > phased in. The fact that V.42bis was the current de facto choice did not > stop the ITU from adopting something better. That is a point in favor of the ITU only if you assume your conclusion, that LZJH is better than v.42bis. I'm inclined to assume that LZJH is better than v.42bis, but that's not relevant to anything I see. > --- recognize that the Calgary and Canterbury corpus were not > representative of data being downloaded in todays internet and create a > set of test files that are representative. If you look at the archives for this mailing list, you'll find that those were not the only sets of test data consider or even the most influental. > --- run comparison tests against HTML files from web sites worldwide with > many different languages. That strikes me as a distinctly minor and probably bogus consideration for the test sets. Picking the test data is not easy, but it is quite wrong to involve political correctness. > I would assume that the IETF is forward looking enough want to allow PPP > implementors the choice if something better comes along regardless of the > number of current CCP options and regardless of a current de facto choice. > Most will run their own comparisons and decide for themselves which is > best based on MIP's, memory, or other contraints which they may have. That is mistaken. In the network world outside the ISO or ITU dream world, considerations of MIPs, memory, and so forth are minor compared to other issues starting with interoperation. (Yes, *this* is a slap at the standard old ISO OSI/ITU delusions of grandure that what a standards committee considers important and desirable must matter outside hotel meeting rooms.) > I would be happy to provide you with the source of LZJH if you want to run > your own comparisons. Thanks, but I trust that if you did apples-to-apples comparison, you would report the results accurately. > Yes, it is going to be an Informational RFC. That short-circuits most of my concerns. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Thu Jan 16 08:07:43 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09068 for ; Thu, 16 Jan 2003 08:07:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6D6A4912CA; Thu, 16 Jan 2003 08:10:49 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3CBEB912CB; Thu, 16 Jan 2003 08:10:49 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 22DCE912CA for ; Thu, 16 Jan 2003 08:10:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0B6D75E0FB; Thu, 16 Jan 2003 08:10:48 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 085455E0EA for ; Thu, 16 Jan 2003 08:10:47 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09009; Thu, 16 Jan 2003 08:07:23 -0500 (EST) Message-Id: <200301161307.IAA09009@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-rfc2284bis-09.txt Date: Thu, 16 Jan 2003 08:07:23 -0500 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Extensible Authentication Protocol (EAP) Author(s) : L. Blunk, J. Vollbrecht, B. Aboba, J. Carlson Filename : draft-ietf-pppext-rfc2284bis-09.txt Pages : 39 Date : 2003-1-15 This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mecha- nisms. EAP typically runs directly over the link layer without requiring IP, but is reliant on lower layer ordering guarantees as in PPP and IEEE 802. EAP does provide its own support for duplicate elimination and retransmission. Fragmentation is not supported within EAP itself; how- ever, individual EAP methods may support this. While EAP was originally developed for use with PPP, it is also now in use with IEEE 802. This document obsoletes RFC 2284. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-rfc2284bis-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-rfc2284bis-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-15130925.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-rfc2284bis-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-rfc2284bis-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-15130925.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp@merit.edu Wed Jan 22 16:23:17 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07641 for ; Wed, 22 Jan 2003 16:23:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 193EE91316; Wed, 22 Jan 2003 16:26:30 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D88FB913C1; Wed, 22 Jan 2003 16:26:29 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BED9991316 for ; Wed, 22 Jan 2003 16:26:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id A866D5DF42; Wed, 22 Jan 2003 16:26:28 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mail1.hyperchip.com (mail1.hyperchip.com [216.94.112.3]) by segue.merit.edu (Postfix) with ESMTP id 730BF5DF15 for ; Wed, 22 Jan 2003 16:26:28 -0500 (EST) Received: from hermes.hyperchip.com ([10.0.0.12] helo=hermes.hypernet.com) by mail1.hyperchip.com with esmtp (Exim 3.22 #1) id 18bSOB-0007Y4-00 for ietf-ppp@merit.edu; Wed, 22 Jan 2003 16:26:27 -0500 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Jan 2003 16:20:37 -0500 Message-ID: <8812A03F65CDD511AE98006008F5E8714CE15B@hermes.hyperchip.com> From: Stephane St Hilaire To: "Ietf-Ppp (E-mail)" Subject: PPP over Sonet default MRU Date: Wed, 22 Jan 2003 16:20:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C25C.1BAC9470" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C25C.1BAC9470 Content-Type: text/plain While doing POS interoperability testing with Juniper and Cisco routers we found the following behavior; Even though Juniper POS interfaces have a default MTU of 4470, no MRU information is sent during LCP negotiations. Even so Cisco routers that use the same default MTU, but DO send their MRU, still send packets of up to 4470 out. My question are the following: 1) Is 4470 the actual default MRU to be used for POS (and not 1500 as documented in rfc 1661) ? 2) If so, is this documented somewhere ? 3) If 1500 is in fact the default MRU, isn't there something "wrong" for lack of a better term with Juniper's behavior in not sending it's MRU and Cisco's in sending frames of more than 1500 bytes regardless. The behavior observed might be specific to the actual routers and OS versions used, but I am still curious as to what the actual "standard" is. Thanks for any clarifications. Stephane St-Hilaire ssthilaire@hyperchip.com T:514-906-4915 ------_=_NextPart_001_01C2C25C.1BAC9470 Content-Type: text/html Content-Transfer-Encoding: quoted-printable PPP over Sonet default MRU

While doing POS interoperability testing with Juniper = and Cisco routers we found the following behavior; Even though Juniper = POS interfaces have a default MTU of 4470, no MRU information is sent = during LCP negotiations.

Even so Cisco routers that use the same default MTU, = but DO send their MRU, still send packets of up to 4470 out. My = question are the following:

1) Is 4470 the actual default MRU to be used for POS = (and not 1500 as documented in rfc 1661) ?
2) If so, is this documented somewhere ?
3) If 1500 is in fact the default MRU, isn't there = something "wrong" for lack of a better term with Juniper's = behavior in not sending it's MRU and Cisco's in sending frames of more = than 1500 bytes regardless.

The behavior observed might be specific to the actual = routers and OS versions used, but I am still curious as to what the = actual "standard" is.

Thanks for any clarifications.

Stephane St-Hilaire
ssthilaire@hyperchip.com
T:514-906-4915

------_=_NextPart_001_01C2C25C.1BAC9470-- From owner-ietf-ppp@merit.edu Thu Jan 23 08:01:56 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05556 for ; Thu, 23 Jan 2003 08:01:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B269D913F1; Thu, 23 Jan 2003 08:05:07 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 72F44913F2; Thu, 23 Jan 2003 08:05:07 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5FC40913F1 for ; Thu, 23 Jan 2003 08:05:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 486165DF70; Thu, 23 Jan 2003 08:05:06 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id C23325DF6D for ; Thu, 23 Jan 2003 08:05:05 -0500 (EST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA09656; Thu, 23 Jan 2003 06:05:04 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0ND545f028617; Thu, 23 Jan 2003 08:05:04 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6) with ESMTP id h0ND54q5006334; Thu, 23 Jan 2003 08:05:04 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6/Submit) id h0ND53qS006331; Thu, 23 Jan 2003 08:05:03 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15919.59519.861022.575167@gargle.gargle.HOWL> Date: Thu, 23 Jan 2003 08:05:03 -0500 From: James Carlson To: Stephane St Hilaire Cc: "Ietf-Ppp (E-mail)" Subject: Re: PPP over Sonet default MRU In-Reply-To: Stephane St Hilaire's message of 22 January 2003 16:20:37 References: <8812A03F65CDD511AE98006008F5E8714CE15B@hermes.hyperchip.com> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Stephane St Hilaire writes: > While doing POS interoperability testing with Juniper and Cisco routers we > found the following behavior; Even though Juniper POS interfaces have a > default MTU of 4470, no MRU information is sent during LCP negotiations. > Even so Cisco routers that use the same default MTU, but DO send their MRU, > still send packets of up to 4470 out. My question are the following: Yes; I've seen that behavior. > 1) Is 4470 the actual default MRU to be used for POS (and not 1500 as > documented in rfc 1661) ? No. The default is still 1500. It's not changed by RFC 1619 or 2615. > 2) If so, is this documented somewhere ? I think it's just a configured MRU. There's nothing wrong with a configured (or even fixed) MRU. RFC 1661 PPP provides the advantage that the peers *can* negotiate the value on each end, providing very helpful diagnostic capabilities, but there's no requirement that anyone ever implement any of the options. (That said, failing to implement useful options seems like a rather poor choice to me.) It's the same way with IP addresses: it's a very good idea to negotiate the endpoint addresses (even if they're not distinct from the addresses uses by other links) in order to avoid configuration errors. There's no requirement that anyone do so. > 3) If 1500 is in fact the default MRU, isn't there something "wrong" for > lack of a better term with Juniper's behavior in not sending it's MRU and > Cisco's in sending frames of more than 1500 bytes regardless. If the Cisco side doesn't have its MTU specifically tuned to 4470, and it's sending packets larger than 1500 octets, then I'd worry about it. Otherwise, no. Things that are agreed to by some outside mechanism are fine. All that RFC 1661 says is that (absent some manual configuration data to the contrary) you have to be prepared to receive frames of at least 1500 octets in case LCP starts over. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Thu Jan 23 10:30:33 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10278 for ; Thu, 23 Jan 2003 10:30:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A65B691401; Thu, 23 Jan 2003 10:33:41 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 507EC91400; Thu, 23 Jan 2003 10:33:41 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F0B8A913FE for ; Thu, 23 Jan 2003 10:32:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id CC0545DFA3; Thu, 23 Jan 2003 10:32:42 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mail1.hyperchip.com (mail1.hyperchip.com [216.94.112.3]) by segue.merit.edu (Postfix) with ESMTP id 586DA5DEDD for ; Thu, 23 Jan 2003 10:32:42 -0500 (EST) Received: from hermes.hyperchip.com ([10.0.0.12] helo=hermes.hypernet.com) by mail1.hyperchip.com with esmtp (Exim 3.22 #1) id 18bjLH-0005Kw-00; Thu, 23 Jan 2003 10:32:35 -0500 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 10:26:43 -0500 Message-ID: <8812A03F65CDD511AE98006008F5E8714CE15E@hermes.hyperchip.com> From: Stephane St Hilaire To: "'James Carlson'" , Stephane St Hilaire Cc: "Ietf-Ppp (E-mail)" Subject: RE: PPP over Sonet default MRU Date: Thu, 23 Jan 2003 10:26:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C2F3.D49A7910" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C2F3.D49A7910 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: James Carlson [mailto:james.d.carlson@east.sun.com] > Sent: Thursday, January 23, 2003 8:05 AM > To: Stephane St Hilaire > Cc: Ietf-Ppp (E-mail) > Subject: Re: PPP over Sonet default MRU > > > I think it's just a configured MRU. There's nothing wrong with a > configured (or even fixed) MRU. I understand that. The MRU will most likely be fixed and may be due to some hardware constraint or foreseeable usage limit (and will in most case go beyond 4470 and reach around ~9K). > RFC 1661 PPP provides the advantage > that the peers *can* negotiate the value on each end, providing very > helpful diagnostic capabilities, but there's no requirement that > anyone ever implement any of the options. (That said, failing to > implement useful options seems like a rather poor choice to me.) I agree about the choice but my interpretation of the following excerpt: "The maximum length for the Information field, including Padding, but not including the Protocol field, is termed the Maximum Receive Unit (MRU), which defaults to 1500 octets. By negotiation, consenting PPP implementations may use other values for the MRU." Is that unless you receive MRU information from the other end, you have to assume that it can only receive up to 1500. One thing that is certain, is that by definition all implementations will discard input frames larger then the MRU, so if you don't tell the other end what your MRU is (and it isn't 1500), the other end has no way of knowing just how big a frame it can send (beyond 1500). > It's the same way with IP addresses: it's a very good idea to > negotiate the endpoint addresses (even if they're not distinct from > the addresses uses by other links) in order to avoid configuration > errors. There's no requirement that anyone do so. That's true but IP addresses are slightly less critical/mandatory connectivity wise (you could work in unnumbered mode) then an interface's MRU in my opinion. > > If the Cisco side doesn't have its MTU specifically tuned to 4470, and > it's sending packets larger than 1500 octets, then I'd worry about > it. As far as I know, NO configuration work is required by the operator, Cisco routers (or I should say the one we're testing with) is just using it's default MTU and sending out packets up to that MTU. Thanks for the reply. Steph ------_=_NextPart_001_01C2C2F3.D49A7910 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: PPP over Sonet default MRU

> -----Original Message-----
> From: James Carlson [mailto:james.d.carlson@east= .sun.com]
> Sent: Thursday, January 23, 2003 8:05 AM
> To: Stephane St Hilaire
> Cc: Ietf-Ppp (E-mail)
> Subject: Re: PPP over Sonet default MRU
>
>
> I think it's just a configured MRU.  = There's nothing wrong with a
> configured (or even fixed) MRU. 

I understand that. The MRU will most likely be fixed = and may be due to some hardware constraint or foreseeable usage limit = (and will in most case go beyond 4470 and reach around ~9K).


> RFC 1661 PPP provides the advantage
> that the peers *can* negotiate the value on = each end, providing very
> helpful diagnostic capabilities, but there's no = requirement that
> anyone ever implement any of the options.  = (That said, failing to
> implement useful options seems like a rather = poor choice to me.)

I agree about the choice but my interpretation of the = following excerpt:

"The maximum length for the Information field, = including Padding,
      but not including the = Protocol field, is termed the Maximum
      Receive Unit (MRU), = which defaults to 1500 octets.  By
      negotiation, = consenting PPP implementations may use other values
      for the = MRU."

Is that unless you receive MRU information from the = other end, you have to assume that it can only receive up to 1500. One = thing that is certain, is that by definition all implementations will = discard input frames larger then the MRU, so if you don't tell the = other end what your MRU is (and it isn't 1500), the other end has no = way of knowing just how big a frame it can send (beyond = 1500).


> It's the same way with IP addresses: it's a very = good idea to
> negotiate the endpoint addresses (even if = they're not distinct from
> the addresses uses by other links) in order to = avoid configuration
> errors.  There's no requirement that = anyone do so.

That's true but IP addresses are slightly less = critical/mandatory connectivity wise (you could work in unnumbered = mode) then an interface's MRU in my opinion.

>
> If the Cisco side doesn't have its MTU = specifically tuned to 4470, and
> it's sending packets larger than 1500 octets, = then I'd worry about
> it. 

As far as I know, NO configuration work is required = by the operator, Cisco routers (or I should say the one we're testing = with) is just using it's default MTU and sending out packets up to that = MTU.

Thanks for the reply.


Steph

------_=_NextPart_001_01C2C2F3.D49A7910-- From owner-ietf-ppp@merit.edu Thu Jan 23 10:45:13 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10621 for ; Thu, 23 Jan 2003 10:45:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A526491400; Thu, 23 Jan 2003 10:48:17 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6B16C91402; Thu, 23 Jan 2003 10:48:17 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4277891400 for ; Thu, 23 Jan 2003 10:48:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0A3B05DE74; Thu, 23 Jan 2003 10:48:16 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id 67F135DE5E for ; Thu, 23 Jan 2003 10:48:15 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09935; Thu, 23 Jan 2003 08:48:14 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0NFmD4t007892; Thu, 23 Jan 2003 10:48:13 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6) with ESMTP id h0NFmDq5006758; Thu, 23 Jan 2003 10:48:13 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6/Submit) id h0NFmDd4006755; Thu, 23 Jan 2003 10:48:13 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15920.3773.626764.900648@gargle.gargle.HOWL> Date: Thu, 23 Jan 2003 10:48:13 -0500 From: James Carlson To: Stephane St Hilaire Cc: "Ietf-Ppp (E-mail)" Subject: RE: PPP over Sonet default MRU In-Reply-To: Stephane St Hilaire's message of 23 January 2003 10:26:41 References: <8812A03F65CDD511AE98006008F5E8714CE15E@hermes.hyperchip.com> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Stephane St Hilaire writes: > > RFC 1661 PPP provides the advantage > > that the peers *can* negotiate the value on each end, providing very > > helpful diagnostic capabilities, but there's no requirement that > > anyone ever implement any of the options. (That said, failing to > > implement useful options seems like a rather poor choice to me.) > > I agree about the choice but my interpretation of the following excerpt: > > "The maximum length for the Information field, including Padding, > but not including the Protocol field, is termed the Maximum > Receive Unit (MRU), which defaults to 1500 octets. By > negotiation, consenting PPP implementations may use other values > for the MRU." > > Is that unless you receive MRU information from the other end, you have to > assume that it can only receive up to 1500. Right; that's what it says. > One thing that is certain, is > that by definition all implementations will discard input frames larger then > the MRU, so if you don't tell the other end what your MRU is (and it isn't > 1500), the other end has no way of knowing just how big a frame it can send > (beyond 1500). Exactly. However, you're still allowed to have the MRU configured manually to some other value at both ends, and you don't *have* to negotiate it. What the text is saying is that if you have *NO* other information about the peer's capabilities, then you are permitted to assume that it supports at least the required 1500 octet minimum. Of course, if you have some sort of external configuration that tells you what the peer's MRU actually is, then you don't have to assume that at all. > > It's the same way with IP addresses: it's a very good idea to > > negotiate the endpoint addresses (even if they're not distinct from > > the addresses uses by other links) in order to avoid configuration > > errors. There's no requirement that anyone do so. > > That's true but IP addresses are slightly less critical/mandatory > connectivity wise (you could work in unnumbered mode) then an interface's > MRU in my opinion. I think that's a red herring. Even in unnumbered mode, nodes that are able to communicate with IP at all *must* have at least one valid IP address. That address can be used as the local address for IPCP negotiation purposes, and doing that serves the goal of IPCP's IP-Address option -- making sure that the link isn't misconfigured. Conflating "unnumbered mode" operation with IPCP negotiation is an implementation error, in my opinion. > > If the Cisco side doesn't have its MTU specifically tuned to 4470, and > > it's sending packets larger than 1500 octets, then I'd worry about > > it. > > As far as I know, NO configuration work is required by the operator, Cisco > routers (or I should say the one we're testing with) is just using it's > default MTU and sending out packets up to that MTU. The "manual configuration" could be as simple as an implementation constant in my view. In order to do that, I think you should document the system usage something like this: "this equipment will fail to operate properly if the peer doesn't support an MRU of at least 4470 octets; sorry about that." That's why PPP added negotiation of these things; to avoid requiring everyone to synchronize their knobs and implementation constants throughout the universe. It's much better when peers negotiate rather than making assumptions. See RFC 1547 section 2.9 (as well as most of section 4). -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Thu Jan 23 11:19:58 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12107 for ; Thu, 23 Jan 2003 11:19:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0A95791405; Thu, 23 Jan 2003 11:23:09 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C093491406; Thu, 23 Jan 2003 11:23:08 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9FD7191405 for ; Thu, 23 Jan 2003 11:23:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8D0265DFD4; Thu, 23 Jan 2003 11:23:07 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mail1.hyperchip.com (mail1.hyperchip.com [216.94.112.3]) by segue.merit.edu (Postfix) with ESMTP id 187545DF98 for ; Thu, 23 Jan 2003 11:23:07 -0500 (EST) Received: from hermes.hyperchip.com ([10.0.0.12] helo=hermes.hypernet.com) by mail1.hyperchip.com with esmtp (Exim 3.22 #1) id 18bk89-00026J-00; Thu, 23 Jan 2003 11:23:05 -0500 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 11:17:13 -0500 Message-ID: <8812A03F65CDD511AE98006008F5E8714CE160@hermes.hyperchip.com> From: Stephane St Hilaire To: "'James Carlson'" , Stephane St Hilaire Cc: "Ietf-Ppp (E-mail)" Subject: RE: PPP over Sonet default MRU Date: Thu, 23 Jan 2003 11:17:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C2FA.E3337C90" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C2FA.E3337C90 Content-Type: text/plain; charset="iso-8859-1" > From: James Carlson [mailto:james.d.carlson@east.sun.com] > Sent: Thursday, January 23, 2003 10:48 AM > To: Stephane St Hilaire > Cc: Ietf-Ppp (E-mail) > Subject: RE: PPP over Sonet default MRU > > Exactly. However, you're still allowed to have the MRU configured > manually to some other value at both ends, and you don't *have* to > negotiate it. It's more frequent to see configuration commands to set the MTU than the MRU. At least that's what I've seen. And I don't think that by configuring one MTU, the other side's MRU would be in any way affected. I mean that I wouldn't necessarily equate configuring one side's MTU with configuring the other's MRU (which will remain unaffected no matter what commands I enter on the other equipment). Here's another question. Let's say router A has an MRU of 10K and a manually configured MTU of 4K and that router B has a MRU of 2K (which it does send during LCP negotiations). Is it "acceptable" for router A to send frames bigger than 2 K just because it is configured to do so ? I would tend to say no. > > Conflating "unnumbered mode" operation with IPCP negotiation is an > implementation error, in my opinion. Probably. I just didn't want to go into discussing IPCP at this time and focus on the MRU "issue". > > The "manual configuration" could be as simple as an implementation > constant in my view. Here I don't agree entirely. I do see a difference between something that is manually configured (operator intervention) and a "hard coded" default setting. > In order to do that, I think you should document > the system usage something like this: "this equipment will fail to > operate properly if the peer doesn't support an MRU of at least 4470 > octets; sorry about that." You could always dynamically lower your MTU to the other side's MRU, when it is discovered. > That's why PPP added negotiation of these things; to avoid requiring > everyone to synchronize their knobs and implementation constants > throughout the universe. It's much better when peers negotiate rather > than making assumptions. See RFC 1547 section 2.9 (as well as most of > section 4). Well of course that's exactly right, I'm still at a loss to know why an implementation supporting a larger MRU than 1500 (when the exact value actually varies from one product line to another) wouldn't send that information to it's peer. Is the other end supposed to guess or use some sort of PPP ESP-Extensions ? Steph ------_=_NextPart_001_01C2C2FA.E3337C90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: PPP over Sonet default MRU

> From: James Carlson [mailto:james.d.carlson@east= .sun.com]
> Sent: Thursday, January 23, 2003 10:48 = AM
> To: Stephane St Hilaire
> Cc: Ietf-Ppp (E-mail)
> Subject: RE: PPP over Sonet default MRU
>

> Exactly.  However, you're still allowed to = have the MRU configured
> manually to some other value at both ends, and = you don't *have* to
> negotiate it.

It's more frequent to see configuration commands to = set the MTU than the MRU. At least that's what I've seen. And I don't = think that by configuring one MTU, the other side's MRU would be in any = way affected. I mean that I wouldn't necessarily equate configuring one = side's MTU with configuring the other's MRU (which will remain = unaffected no matter what commands I enter on the other equipment). =

Here's another question.
Let's say router A has an MRU of 10K and a manually = configured MTU of 4K and that router B has a MRU of 2K (which it does = send during LCP negotiations). Is it "acceptable" for router = A to send frames bigger than 2 K just because it is configured to do so = ?  I would tend to say no.


>
> Conflating "unnumbered mode" = operation with IPCP negotiation is an
> implementation error, in my opinion.

Probably. I just didn't want to go into discussing = IPCP at this time and focus on the MRU "issue".

>
> The "manual configuration" could be = as simple as an implementation
> constant in my view. 

Here I don't agree entirely. I do see a difference = between something that is manually configured (operator intervention) = and a "hard coded" default setting.


> In order to do that, I think you should = document
> the system usage something like this: = "this equipment will fail to
> operate properly if the peer doesn't support an = MRU of at least 4470
> octets; sorry about that."

You could always dynamically lower your MTU to the = other side's MRU, when it is discovered.

 
> That's why PPP added negotiation of these = things; to avoid requiring
> everyone to synchronize their knobs and = implementation constants
> throughout the universe.  It's much better = when peers negotiate rather
> than making assumptions.  See RFC 1547 = section 2.9 (as well as most of
> section 4).

Well of course that's exactly right, I'm still at a = loss to know why an implementation supporting a larger MRU than 1500 = (when the exact value actually varies from one product line to another) = wouldn't send that information to it's peer. Is the other end supposed = to guess or use some sort of PPP ESP-Extensions ?


Steph

------_=_NextPart_001_01C2C2FA.E3337C90-- From owner-ietf-ppp@merit.edu Thu Jan 23 11:40:28 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12711 for ; Thu, 23 Jan 2003 11:40:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6CBFE9140A; Thu, 23 Jan 2003 11:43:35 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 34B7D9140B; Thu, 23 Jan 2003 11:43:35 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0FF4D9140A for ; Thu, 23 Jan 2003 11:43:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id F23DE5DFD6; Thu, 23 Jan 2003 11:43:33 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id 64CB05DE74 for ; Thu, 23 Jan 2003 11:43:29 -0500 (EST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18735; Thu, 23 Jan 2003 08:43:24 -0800 (PST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0NGhO5f015392; Thu, 23 Jan 2003 11:43:24 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6) with ESMTP id h0NGhOq5006814; Thu, 23 Jan 2003 11:43:24 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6/Submit) id h0NGhOpP006811; Thu, 23 Jan 2003 11:43:24 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15920.7083.945929.924627@gargle.gargle.HOWL> Date: Thu, 23 Jan 2003 11:43:23 -0500 From: James Carlson To: Stephane St Hilaire Cc: "Ietf-Ppp (E-mail)" Subject: RE: PPP over Sonet default MRU In-Reply-To: Stephane St Hilaire's message of 23 January 2003 11:17:12 References: <8812A03F65CDD511AE98006008F5E8714CE160@hermes.hyperchip.com> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Stephane St Hilaire writes: > > Exactly. However, you're still allowed to have the MRU configured > > manually to some other value at both ends, and you don't *have* to > > negotiate it. > > It's more frequent to see configuration commands to set the MTU than the > MRU. It depends on the implementation. Some implementations (e.g., CMU/ANU ppp) have controls for both. > At least that's what I've seen. And I don't think that by configuring > one MTU, the other side's MRU would be in any way affected. I don't think I understand that. If you *set* the MTU, then you're explicitly telling your system that the peer's MRU is at least that large. If you say it's so, then it must be so. What else could that possibly mean? > I mean that I > wouldn't necessarily equate configuring one side's MTU with configuring the > other's MRU (which will remain unaffected no matter what commands I enter on > the other equipment). That's the whole point of implementing negotiation. Negotiation is a good thing. It allows you to detect cases where the two configurations are in conflict and (in some cases) recover from the problem. The fact that one or more vendors didn't implement useful negotiation features is a problem to take up with those vendors. ("Dear Vendor: Please consider implementing this useful feature from RFC 1661 ...") > Here's another question. > Let's say router A has an MRU of 10K and a manually configured MTU of 4K and > that router B has a MRU of 2K (which it does send during LCP negotiations). > Is it "acceptable" for router A to send frames bigger than 2 K just because > it is configured to do so ? I would tend to say no. That's a configuration error. The administrator failed in setting it up incorrectly, and the implementations are lacking for failing to provide helpful negotiation to detect the problem. > > Conflating "unnumbered mode" operation with IPCP negotiation is an > > implementation error, in my opinion. > > Probably. I just didn't want to go into discussing IPCP at this time and > focus on the MRU "issue". That's fine. I was just pointing out that the issue is much broader and more generic: PPP allows you to negotiate things that were (in prior protocols) explicitly manually configured on both ends of a link. PPP doesn't *require* you to do that negotiation (which is why they're "options"), but it's obviously a very good thing to do so, and usually requires really good justification to avoid it. For example, some implementations fail to implement the LCP Magic Number option. This is clearly a Very Bad Thing because it allows looped-back interfaces to become established, and because implementing the option is no skin off anyone's nose: you don't need any additional hardware support to do it. However, it's still an option, and vendors are free to make implementation mistakes. > > The "manual configuration" could be as simple as an implementation > > constant in my view. > > Here I don't agree entirely. I do see a difference between something that is > manually configured (operator intervention) and a "hard coded" default > setting. From the perspective of the protocol, I don't. You either get the information from negotiation (the peer tells you its MRU, which then becomes a limit on the MTU that you may use), or you get it through some authoritative "external" mechanism. The protocol doesn't (and can't) care where that external mechanism gets its information -- the protocol knows nothing of user interfaces, #defines, or other such matters. That's an implementation matter. > > In order to do that, I think you should document > > the system usage something like this: "this equipment will fail to > > operate properly if the peer doesn't support an MRU of at least 4470 > > octets; sorry about that." > > You could always dynamically lower your MTU to the other side's MRU, when it > is discovered. Assuming your implementation actually is capable of doing that, then, yes, I agree that this is the best choice. I can imagine implementations that might not be able to do this -- e.g., ones that don't bother supporting IPv4 fragmentation and thus fix the MTU to be equal to the maximum MRU supported on any other interface. Obviously, those implementations should still negotiate the value; they'd just have to fail to bring up the link if the peer's MRU is too small. (Which is exactly the intent of the option; preventing broken configurations.) > > That's why PPP added negotiation of these things; to avoid requiring > > everyone to synchronize their knobs and implementation constants > > throughout the universe. It's much better when peers negotiate rather > > than making assumptions. See RFC 1547 section 2.9 (as well as most of > > section 4). > > Well of course that's exactly right, I'm still at a loss to know why an > implementation supporting a larger MRU than 1500 (when the exact value > actually varies from one product line to another) wouldn't send that > information to it's peer. Is the other end supposed to guess or use some > sort of PPP ESP-Extensions ? If you don't implement an option, then human intervention of some kind is required to handle that feature. If it's a fixed MRU or MTU, then the human will have to read the supplied documentation to determine if the link will work. It's out of PPP's hands at that point. There's no way (or reason) to "require" the implementation of features that vendors don't want to implement, at least not by way of the IETF. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Thu Jan 23 13:16:44 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15547 for ; Thu, 23 Jan 2003 13:16:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 79D009131D; Thu, 23 Jan 2003 13:19:55 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 48EE591322; Thu, 23 Jan 2003 13:19:55 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E888B9131D for ; Thu, 23 Jan 2003 13:19:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id D09295DFD9; Thu, 23 Jan 2003 13:19:53 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mail1.hyperchip.com (mail1.hyperchip.com [216.94.112.3]) by segue.merit.edu (Postfix) with ESMTP id 2DD3F5DFD4 for ; Thu, 23 Jan 2003 13:19:53 -0500 (EST) Received: from hermes.hyperchip.com ([10.0.0.12] helo=hermes.hypernet.com) by mail1.hyperchip.com with esmtp (Exim 3.22 #1) id 18blx5-000328-00; Thu, 23 Jan 2003 13:19:47 -0500 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 13:13:55 -0500 Message-ID: <8812A03F65CDD511AE98006008F5E8714CE162@hermes.hyperchip.com> From: Stephane St Hilaire To: "'James Carlson'" , Stephane St Hilaire Cc: "Ietf-Ppp (E-mail)" Subject: RE: PPP over Sonet default MRU Date: Thu, 23 Jan 2003 13:13:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C30B.30B0E0B0" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C30B.30B0E0B0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: James Carlson [mailto:james.d.carlson@east.sun.com] > It depends on the implementation. Some implementations (e.g., CMU/ANU > ppp) have controls for both. > > > At least that's what I've seen. And I don't think that by > configuring > > one MTU, the other side's MRU would be in any way affected. > > I don't think I understand that. If you *set* the MTU, then you're > explicitly telling your system that the peer's MRU is at least that > large. If you say it's so, then it must be so. > Actually when I say "it's so", I'm really saying "I want it so", I could easily be wrong. When I'm configuring my MTU I am in NO WAY affecting the actual MRU of the other system. Is that clearer ? > > > Here's another question. > > Let's say router A has an MRU of 10K and a manually > configured MTU of 4K and > > that router B has a MRU of 2K (which it does send during > LCP negotiations). > > Is it "acceptable" for router A to send frames bigger than > 2 K just because > > it is configured to do so ? I would tend to say no. > > That's a configuration error. The administrator failed in setting it > up incorrectly, and the implementations are lacking for failing to > provide helpful negotiation to detect the problem. I was going for a yes or no answer ; ). Configuration errors will occur no matter what. I'm just saying should router A disregard the MRU information it got from it's peer and still send according to it's configured MTU ? I don't expect that would actually work very well. > > From the perspective of the protocol, I don't. You either get the > information from negotiation (the peer tells you its MRU, which then > becomes a limit on the MTU that you may use), I guess this is where you answered my previous question. > or you get it through > some authoritative "external" mechanism. If you get diverging information which should take precedence ? The locally configured MTU or the ACTUAL MRU learned when bringing up the link ? I'm inclining towards the latter, what is your opinon ? > > You could always dynamically lower your MTU to the other > side's MRU, when it > > is discovered. > > Assuming your implementation actually is capable of doing that, then, > yes, I agree that this is the best choice. I can imagine > implementations that might not be able to do this -- e.g., ones that > don't bother supporting IPv4 fragmentation and thus fix the MTU to be Fragmentation is not an optionnal feature, at least for a IP V4 router (you may be talking about another type of equipment). Though I can imagine implementations that couldn't be bothered with the IETF and RFCs in general. > > It's out of PPP's hands at that point. There's no way (or reason) to > "require" the implementation of features that vendors don't want to > implement, at least not by way of the IETF. > If you really meant: There's no way (or reason) to "require" the implementation of OPTIONAL features that vendors don't want to implement, at least not by way of the IETF". Then I agree entirely. If not, then even though there may be no WAY, I can think of lots of REASONS to do so. Steph ------_=_NextPart_001_01C2C30B.30B0E0B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: PPP over Sonet default MRU

> -----Original Message-----
> From: James Carlson [mailto:james.d.carlson@east= .sun.com]
> It depends on the implementation.  Some = implementations (e.g., CMU/ANU
> ppp) have controls for both.
>
> > At least that's what I've seen. And I = don't think that by
> configuring
> > one MTU, the other side's MRU would be in = any way affected.
>
> I don't think I understand that.  If you = *set* the MTU, then you're
> explicitly telling your system that the peer's = MRU is at least that
> large.  If you say it's so, then it must = be so.
>

Actually when I say "it's so", I'm really = saying "I want it so", I could easily be wrong.
When I'm configuring my MTU I am in NO WAY affecting = the actual MRU of the other system. Is that clearer ?

>
> > Here's another question.
> > Let's say router A has an MRU of 10K and a = manually
> configured MTU of 4K and
> > that router B has a MRU of 2K (which it = does send during
> LCP negotiations).
> > Is it "acceptable" for router A = to send frames bigger than
> 2 K just because
> > it is configured to do so ?  I would = tend to say no.
>
> That's a configuration error.  The = administrator failed in setting it
> up incorrectly, and the implementations are = lacking for failing to
> provide helpful negotiation to detect the = problem.


I was going for a yes or no answer ; ). Configuration = errors will occur no matter what. I'm just saying should router A = disregard the MRU information it got from it's peer and still send = according to it's configured MTU ? I don't expect that would actually = work very well.


>
> From the perspective of the protocol, I = don't.  You either get the
> information from negotiation (the peer tells = you its MRU, which then
> becomes a limit on the MTU that you may use), =

I guess this is where you answered my previous = question.

> or you get it through
> some authoritative "external" = mechanism.

If you get diverging information which should take = precedence ? The locally configured MTU or the ACTUAL MRU learned when = bringing up the link ? I'm inclining towards the latter, what is your = opinon ?

> > You could always dynamically lower your MTU = to the other
> side's MRU, when it
> > is discovered.
>
> Assuming your implementation actually is = capable of doing that, then,
> yes, I agree that this is the best = choice.  I can imagine
> implementations that might not be able to do = this -- e.g., ones that
> don't bother supporting IPv4 fragmentation and = thus fix the MTU to be

Fragmentation is not an optionnal feature, at least = for a IP V4 router (you may be talking about another type of = equipment). Though I can imagine implementations that couldn't be = bothered with the IETF and RFCs in general.

>
> It's out of PPP's hands at that point.  = There's no way (or reason) to
> "require" the implementation of = features that vendors don't want to
> implement, at least not by way of the = IETF.
>

If you really meant: There's no way (or reason) = to
 "require" the implementation of = OPTIONAL features that vendors don't want to
 implement, at least not by way of the = IETF". Then I agree entirely. If not, then even though there may = be no WAY, I can think of lots of REASONS to do so.



Steph

------_=_NextPart_001_01C2C30B.30B0E0B0-- From owner-ietf-ppp@merit.edu Thu Jan 23 14:00:38 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16666 for ; Thu, 23 Jan 2003 14:00:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E3FB99140B; Thu, 23 Jan 2003 14:03:43 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B211D9140D; Thu, 23 Jan 2003 14:03:43 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7D02A9140B for ; Thu, 23 Jan 2003 14:03:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 65C395DE5E; Thu, 23 Jan 2003 14:03:42 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id C0B795DEB0 for ; Thu, 23 Jan 2003 14:03:41 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA07879; Thu, 23 Jan 2003 12:03:41 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0NJ3e4t025197; Thu, 23 Jan 2003 14:03:40 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6) with ESMTP id h0NJ3eq5007022; Thu, 23 Jan 2003 14:03:40 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6/Submit) id h0NJ3eqv007019; Thu, 23 Jan 2003 14:03:40 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15920.15500.292408.416592@gargle.gargle.HOWL> Date: Thu, 23 Jan 2003 14:03:40 -0500 From: James Carlson To: Stephane St Hilaire Cc: "Ietf-Ppp (E-mail)" Subject: RE: PPP over Sonet default MRU In-Reply-To: Stephane St Hilaire's message of 23 January 2003 13:13:54 References: <8812A03F65CDD511AE98006008F5E8714CE162@hermes.hyperchip.com> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Stephane St Hilaire writes: > > I don't think I understand that. If you *set* the MTU, then you're > > explicitly telling your system that the peer's MRU is at least that > > large. If you say it's so, then it must be so. > > > > Actually when I say "it's so", I'm really saying "I want it so", I could > easily be wrong. > When I'm configuring my MTU I am in NO WAY affecting the actual MRU of the > other system. Is that clearer ? Sure. But if you say that it's so, then you have to be right. It's like setting the clocking options on a T1 link. You have to be right. If you're not, then it just won't work right. Or like setting that "115/230" switch on the back of the router. You'll eventually know if you got it wrong. > > That's a configuration error. The administrator failed in setting it > > up incorrectly, and the implementations are lacking for failing to > > provide helpful negotiation to detect the problem. > > > I was going for a yes or no answer ; ). Configuration errors will occur no > matter what. I'm just saying should router A disregard the MRU information > it got from it's peer and still send according to it's configured MTU ? I > don't expect that would actually work very well. If you actually get an MRU option from your peer, then one of three things can happen (ultimately; when the dust of negotiation settles): 1. you agree to the peer's MRU -- this becomes a bound on the MTU that you can possibly use on the link. 2. you don't implement that option at all, just reject it as unrecognized (LCP Configure-Reject), and use some configured value. 3. you determine through negotiation that the peer doesn't have an MRU that you like and that you can't fix it, so you shut down the link and call for human intervention. Cases (1) and (3) are the good ones -- that's what negotiation is supposed to do for you. Case (2) is bad, but it's just the nature of options rather than requirements. (Of course, there's a subcase to 2 -- the peer could also shut down the link if it feels that you're being unreasonable.) It's not different from what you have to do if the peer sends IPCP Configure-Reject for your IP-Address option. You have to make a choice: plow on with whatever configured addresses you might have, or shut the link down and call for help. It's mostly a policy decision. > > or you get it through > > some authoritative "external" mechanism. > > If you get diverging information which should take precedence ? The locally > configured MTU or the ACTUAL MRU learned when bringing up the link ? I'm > inclining towards the latter, what is your opinon ? It depends. If you do recognize the option (i.e, you implement the LCP MRU option), *and* you return LCP Configure-Ack for that value, *then* you're compelled to use an MTU that's no larger than the MRU advertised by your peer. None of those two preconditions (recognizing the option, and returning Configure-Ack) are required. > > Assuming your implementation actually is capable of doing that, then, > > yes, I agree that this is the best choice. I can imagine > > implementations that might not be able to do this -- e.g., ones that > > don't bother supporting IPv4 fragmentation and thus fix the MTU to be > > Fragmentation is not an optionnal feature, at least for a IP V4 router (you > may be talking about another type of equipment). Though I can imagine > implementations that couldn't be bothered with the IETF and RFCs in general. I think you might have misunderstood what I wrote. If, in a given implementation, there's never a possibility of being in a position of having to transmit an IPv4 datagram that is larger than the link MTU, then it's certainly the case that you'll never have to fragment anything. If you never have to fragment, then you don't have to bother implementing fragmentation. Nobody can tell whether or not you implement features that you don't ever have occasion to use. In the scenario I suggest, if you have a link whose MTU (including any optional encapsulation you might support) is at least as large as the largest MRU on any link on your system, then there's no way you could ever be in a position where you'd have to fragment anything that you would forward onto that link. I can imagine that some implementations of "high speed" interfaces (for some definition of "high") might opt to avoid fragmentation. I'm not saying that it's necessarily goodness; merely that it's possible. > > It's out of PPP's hands at that point. There's no way (or reason) to > > "require" the implementation of features that vendors don't want to > > implement, at least not by way of the IETF. > > > > If you really meant: There's no way (or reason) to > "require" the implementation of OPTIONAL features that vendors don't want > to > implement, at least not by way of the IETF". Then I agree entirely. If not, > then even though there may be no WAY, I can think of lots of REASONS to do > so. Sure. That comes down to "quality of implementation." -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Thu Jan 23 17:01:21 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21507 for ; Thu, 23 Jan 2003 17:01:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9958691417; Thu, 23 Jan 2003 17:04:09 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3FA4991415; Thu, 23 Jan 2003 17:04:08 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2968891415 for ; Thu, 23 Jan 2003 17:02:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0CDA35DF43; Thu, 23 Jan 2003 17:02:45 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mail1.hyperchip.com (mail1.hyperchip.com [216.94.112.3]) by segue.merit.edu (Postfix) with ESMTP id 8CC065DF00 for ; Thu, 23 Jan 2003 17:02:44 -0500 (EST) Received: from hermes.hyperchip.com ([10.0.0.12] helo=hermes.hypernet.com) by mail1.hyperchip.com with esmtp (Exim 3.22 #1) id 18bpQo-0001G8-00; Thu, 23 Jan 2003 17:02:42 -0500 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 16:56:49 -0500 Message-ID: <8812A03F65CDD511AE98006008F5E8714CE164@hermes.hyperchip.com> From: Stephane St Hilaire To: "'James Carlson'" , Stephane St Hilaire Cc: "Ietf-Ppp (E-mail)" Subject: RE: PPP over Sonet default MRU Date: Thu, 23 Jan 2003 16:56:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C32A.545FC340" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C32A.545FC340 Content-Type: text/plain; charset="iso-8859-1" > > > > > Actually when I say "it's so", I'm really saying "I want it > so", I could > > easily be wrong. > > When I'm configuring my MTU I am in NO WAY affecting the > actual MRU of the > > other system. Is that clearer ? > > Sure. But if you say that it's so, then you have to be right. You don't really have to be right, the sytem can still work even if you're wrong, as mentionned earlier you could when discovering that the remote MRU is lower then your configured MTU, log something and lower your MTU to the discovered value, this is not the same as voltage or clocking. There are no voltage negociation protocols. There also is no such thing as a "universal" known default value for stuff like voltage and clocking options, whereas for PPP there is a default and by definition all PPP compliant equipment must AT LEAST support/work with the default values. > 2. you don't implement that option at all, just reject it as > unrecognized (LCP Configure-Reject), and use some > configured value. The ability to receive/understand the MRU option in LCP is not optional (the option negociation scheme is extensible but the MRU is not an extension to LCP). What IS optional is sending MRU information to your peer. Knowing full well that if you don't they will assume you only support the default 1500 value. If you don't like the received MRU you should send a NACK (it's too low for your MTU for example). Sending a reject would mean; I don't implement this "MRU feature". What would that mean anyway ? > It's not different from what you have to do if the peer sends IPCP > Configure-Reject for your IP-Address option. You have to make a > choice: plow on with whatever configured addresses you might have, or > shut the link down and call for help. It's mostly a policy decision. There is no default value for IP addresses for IPCP (how could there be...). This is quite another story. > I think you might have misunderstood what I wrote. > > If, in a given implementation, there's never a possibility of being in > a position of having to transmit an IPv4 datagram that is larger than > the link MTU, then it's certainly the case that you'll never have to > fragment anything. If you never have to fragment, then you don't have > to bother implementing fragmentation. Nobody can tell whether or not > you implement features that you don't ever have occasion to use. I see your point but it's not a very likely situation. I don't see a router removing all possibility of configuring interfaces MTU by design just to avoid the possibility of fragmentation. Steph ------_=_NextPart_001_01C2C32A.545FC340 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: PPP over Sonet default MRU

>
> >
> > Actually when I say "it's so", = I'm really saying "I want it
> so", I could
> > easily be wrong.
> > When I'm configuring my MTU I am in NO WAY = affecting the
> actual MRU of the
> > other system. Is that clearer ?
>
> Sure.  But if you say that it's so, then = you have to be right.

You don't really have to be right, the sytem can = still work even if you're wrong, as mentionned earlier you could when = discovering that the remote MRU is lower then your configured MTU, log = something and lower your MTU to the discovered value, this is not the = same as voltage or clocking. There are no voltage negociation = protocols. There also is no such thing as a "universal" known = default value for stuff like voltage and clocking options, whereas for = PPP there is a default and by definition all PPP compliant equipment = must AT LEAST support/work with the default values.

>       2. you don't = implement that option at all, just reject it as
>          = ;  unrecognized (LCP Configure-Reject), and use some
>          = ;  configured value.

The ability to receive/understand the MRU option in = LCP is not optional (the option negociation scheme is extensible but = the MRU is not an extension to LCP). What IS optional is sending MRU = information to your peer. Knowing full well that if you don't they will = assume you only support the default 1500 value. If you don't like the = received MRU you should send a NACK (it's too low for your MTU for = example). Sending a reject would mean; I don't implement this "MRU = feature". What would that mean anyway ?



> It's not different from what you have to do if = the peer sends IPCP
> Configure-Reject for your IP-Address = option.  You have to make a
> choice: plow on with whatever configured = addresses you might have, or
> shut the link down and call for help.  = It's mostly a policy decision.

There is no default value for IP addresses for IPCP = (how could there be...). This is quite another story.


> I think you might have misunderstood what I = wrote.
>
> If, in a given implementation, there's never a = possibility of being in
> a position of having to transmit an IPv4 = datagram that is larger than
> the link MTU, then it's certainly the case that = you'll never have to
> fragment anything.  If you never have to = fragment, then you don't have
> to bother implementing fragmentation.  = Nobody can tell whether or not
> you implement features that you don't ever have = occasion to use.


I see your point but it's not a very likely = situation. I don't see a router removing all possibility of configuring = interfaces MTU by design just to avoid the possibility of = fragmentation.




Steph

------_=_NextPart_001_01C2C32A.545FC340-- From owner-ietf-ppp@merit.edu Thu Jan 23 17:20:47 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21879 for ; Thu, 23 Jan 2003 17:20:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 96A8091419; Thu, 23 Jan 2003 17:23:53 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F3E849141A; Thu, 23 Jan 2003 17:23:51 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DB52D91419 for ; Thu, 23 Jan 2003 17:23:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id C0A205DFEC; Thu, 23 Jan 2003 17:23:50 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id 57B1A5DFEB for ; Thu, 23 Jan 2003 17:23:50 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05942; Thu, 23 Jan 2003 14:23:49 -0800 (PST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0NMNm4t014850; Thu, 23 Jan 2003 17:23:48 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6) with ESMTP id h0NMNmq5007515; Thu, 23 Jan 2003 17:23:48 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6/Submit) id h0NMNmtT007512; Thu, 23 Jan 2003 17:23:48 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15920.27508.139013.925653@gargle.gargle.HOWL> Date: Thu, 23 Jan 2003 17:23:48 -0500 From: James Carlson To: Stephane St Hilaire Cc: "Ietf-Ppp (E-mail)" Subject: RE: PPP over Sonet default MRU In-Reply-To: Stephane St Hilaire's message of 23 January 2003 16:56:49 References: <8812A03F65CDD511AE98006008F5E8714CE164@hermes.hyperchip.com> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Stephane St Hilaire writes: > > Sure. But if you say that it's so, then you have to be right. > > You don't really have to be right, the sytem can still work even if you're > wrong, as mentionned earlier you could when discovering that the remote MRU > is lower then your configured MTU, log something and lower your MTU to the > discovered value, this is not the same as voltage or clocking. There are no > voltage negociation protocols. There also is no such thing as a "universal" > known default value for stuff like voltage and clocking options, whereas for > PPP there is a default and by definition all PPP compliant equipment must AT > LEAST support/work with the default values. I think you're missing the point here. If you explicitly configure the MTU *AND* you're not willing to listen to what the peer says about his MRU, *THEN* you will indeed encounter breakage when the peer's MRU is less than what you configured. Large packets just won't go through, and there'll be no notification of this fact. This is not all that much different from picking the wrong clock sources and having a 200ppm drift -- it'll sometimes appear to sort of work (especially with small packets), and other times not. (For what it's worth, it might indeed be possible to write a suitable protocol based on FDL to negotiate a lot of those "necessary" parameters. The fact that this isn't there is the same sort of problem that PPP addresses in its own domain.) (And many modern power supplies can handle wide voltage ranges and adapt. Those that can't are sort of like PPP implementations that don't bother to go to the trouble of implementing the useful options.) > > 2. you don't implement that option at all, just reject it as > > unrecognized (LCP Configure-Reject), and use some > > configured value. > > The ability to receive/understand the MRU option in LCP is not optional (the > option negociation scheme is extensible but the MRU is not an extension to > LCP). I think that's at odds both with RFC 1661: 6. LCP Configuration Options [...] Design Philosophy The options indicate additional capabilities or requirements of the implementation that is requesting the option. An implementation which does not understand any option SHOULD interoperate with one which implements every option. ... and with existing practice. There are quite a few implementations that don't bother implementing every option listed in RFC 1661 (in particular, Quality-Protocol is somewhat rare). None are mandatory. If you'd like to call those implementations non-conformant with RFC 1661, that's up to you, but it's irrelevant for interoperability. > What IS optional is sending MRU information to your peer. Knowing full > well that if you don't they will assume you only support the default 1500 > value. If you don't like the received MRU you should send a NACK (it's too > low for your MTU for example). Sending a reject would mean; I don't > implement this "MRU feature". What would that mean anyway ? It means "I don't support negotiation of your MRU (my MTU); you'll have to live with whatever the default might be, or whatever your local configuration tells you to do." It's the same as with all PPP options. If the peer refuses to play the game, then you have to fall back on the information that you already know, or simply shut down the link. Which one you pick is purely a matter of local policy. > > It's not different from what you have to do if the peer sends IPCP > > Configure-Reject for your IP-Address option. You have to make a > > choice: plow on with whatever configured addresses you might have, or > > shut the link down and call for help. It's mostly a policy decision. > > There is no default value for IP addresses for IPCP (how could there be...). > This is quite another story. In practice there often is -- the implementation often has external information (explicit interface configuration or the result of an authentication database query, for example) that give any necessary IP addresses. Or, perhaps, it's happy to run without them at IPCP time, and then rely on BOOTP or DHCP over UDP/IP to establish addressing. (Yes, quite a few vendors do actually support that.) Obviously, the RFC can't specify a default. That's not the same thing as saying that there *is* no default. The story isn't different, and that's just the point. If the peer refuses to negotiate, then that's *ALL* that you know. He's refusing to negotiate, so you can assume what you want to, constrained only by the goal of interoperability. Basically, if you had a PPP implementation that refused *all* configuration options, that would be perfectly legal. It would then be functionally identical (in most respects; except for the CRC) to SLIP in operation -- all parameters must be configured explicitly at both ends, and life as we know it ceases if you happen to get any of them wrong. That, once again, was the very reason for developing option negotiation in PPP. Configuring both ends correctly is hard. Having the two ends validate and perhaps amend that configuration such that the link is usable is better. > > If, in a given implementation, there's never a possibility of being in > > a position of having to transmit an IPv4 datagram that is larger than > > the link MTU, then it's certainly the case that you'll never have to > > fragment anything. If you never have to fragment, then you don't have > > to bother implementing fragmentation. Nobody can tell whether or not > > you implement features that you don't ever have occasion to use. > > > I see your point but it's not a very likely situation. I don't see a router > removing all possibility of configuring interfaces MTU by design just to > avoid the possibility of fragmentation. I think you might be underestimating the perversity of nature. ;-} I'm not claiming that's what's going on with either of these vendors, but it's certainly not an impossible situation. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Thu Jan 23 18:01:55 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23375 for ; Thu, 23 Jan 2003 18:01:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E95DE9141B; Thu, 23 Jan 2003 18:04:58 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B35609141C; Thu, 23 Jan 2003 18:04:58 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7D4AF9141B for ; Thu, 23 Jan 2003 18:04:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6674B5DF90; Thu, 23 Jan 2003 18:04:57 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mail1.hyperchip.com (mail1.hyperchip.com [216.94.112.3]) by segue.merit.edu (Postfix) with ESMTP id DE0935DE09 for ; Thu, 23 Jan 2003 18:04:56 -0500 (EST) Received: from hermes.hyperchip.com ([10.0.0.12] helo=hermes.hypernet.com) by mail1.hyperchip.com with esmtp (Exim 3.22 #1) id 18bqP1-0008W6-00; Thu, 23 Jan 2003 18:04:55 -0500 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 17:59:02 -0500 Message-ID: <8812A03F65CDD511AE98006008F5E8714CE165@hermes.hyperchip.com> From: Stephane St Hilaire To: "'James Carlson'" , Stephane St Hilaire Cc: "Ietf-Ppp (E-mail)" Subject: RE: PPP over Sonet default MRU Date: Thu, 23 Jan 2003 17:59:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C333.05A84F20" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C333.05A84F20 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: James Carlson [mailto:james.d.carlson@east.sun.com] > 6. LCP Configuration Options > [...] > Design Philosophy > > ... and with existing practice. There are quite a few implementations > that don't bother implementing every option listed in RFC 1661 (in > particular, Quality-Protocol is somewhat rare). None are mandatory. > I think we're stuck in semantics. When negociating Quality Protocol (even if you reject this option), you're NOT negociating your "ability to negociate" link quality monitoring. You're specifying whether you support link quality monitoring or not. Yes link quality monitoring IS optional. Having a MRU however is not a negociable "feature". You may or may not support values other than the default but you can't say I don't support "MRU negociation". Heck just sending a NACK or a REJECT is PART of the negociation. Not that this matters a whole lot, it's just semantics. > It means "I don't support negotiation of your MRU (my MTU); you'll > have to live with whatever the default might be, or whatever your > local configuration tells you to do." If that ("your MRU is fine") is actually what you wanted to tell the remote end, a simple ACK would have done the trick. > Obviously, the RFC can't specify a default. That's not the same thing > as saying that there *is* no default. I meant of course that there is no RFC specified default, and I don't know why we are still talking about IPCP. > > Basically, if you had a PPP implementation that refused *all* > configuration options, that would be perfectly legal. Sure as long as the link came up using default values. > > I see your point but it's not a very likely situation. I > don't see a router > > removing all possibility of configuring interfaces MTU by > design just to > > avoid the possibility of fragmentation. > > I think you might be underestimating the perversity of nature. ;-} Believe me, I never do at least when it comes to human nature. > > I'm not claiming that's what's going on with either of these vendors, > but it's certainly not an impossible situation. I never said impossible, just unlikely. I believe we have definitively exhausted this particular subject. Thanks again Steph ------_=_NextPart_001_01C2C333.05A84F20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: PPP over Sonet default MRU

> -----Original Message-----
> From: James Carlson [mailto:james.d.carlson@east= .sun.com]
> 6.  LCP Configuration Options
> [...]
>    Design Philosophy
>
> ... and with existing practice.  There are = quite a few implementations
> that don't bother implementing every option = listed in RFC 1661 (in
> particular, Quality-Protocol is somewhat = rare).  None are mandatory.
>

I think we're stuck in semantics.
When negociating Quality Protocol (even if you = reject this option), you're NOT negociating your "ability to = negociate" link quality monitoring. You're specifying whether you = support link quality monitoring or not. Yes link quality monitoring IS = optional. Having a MRU however is not a negociable "feature". = You may or may not support values other than the default but you can't = say I don't support "MRU negociation". Heck just sending a = NACK or a REJECT is PART of the negociation. Not that this matters a = whole lot, it's just semantics.


> It means "I don't support negotiation of = your MRU (my MTU); you'll
> have to live with whatever the default might = be, or whatever your
> local configuration tells you to = do."

If that ("your MRU is fine") is actually = what you wanted to tell the remote end, a simple ACK would have done = the trick.



> Obviously, the RFC can't specify a = default.  That's not the same thing
> as saying that there *is* no default.

I meant of course that there is no RFC specified = default, and I don't know why we are still talking about IPCP.

>
> Basically, if you had a PPP implementation that = refused *all*
> configuration options, that would be perfectly = legal. 

Sure as long as the link came up using default = values.

> > I see your point but it's not a very likely = situation. I
> don't see a router
> > removing all possibility of configuring = interfaces MTU by
> design just to
> > avoid the possibility of fragmentation. =
>
> I think you might be underestimating the = perversity of nature.  ;-}

Believe me, I never do at least when it comes to = human nature.

>
> I'm not claiming that's what's going on with = either of these vendors,
> but it's certainly not an impossible = situation.

I never said impossible, just unlikely.


I believe we have definitively exhausted this = particular subject.

Thanks again


Steph


------_=_NextPart_001_01C2C333.05A84F20-- From owner-ietf-ppp@merit.edu Fri Jan 24 07:57:37 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17460 for ; Fri, 24 Jan 2003 07:57:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A563C9143B; Fri, 24 Jan 2003 08:00:19 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3214E9143D; Fri, 24 Jan 2003 08:00:19 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2D5F99143B for ; Fri, 24 Jan 2003 08:00:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 983D45E00B; Fri, 24 Jan 2003 08:00:14 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id C27CA5DE0F for ; Fri, 24 Jan 2003 08:00:13 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17351; Fri, 24 Jan 2003 07:56:45 -0500 (EST) Message-Id: <200301241256.HAA17351@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-rfc2284bis-10.txt Date: Fri, 24 Jan 2003 07:56:45 -0500 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Extensible Authentication Protocol (EAP) Author(s) : L. Blunk, J. Vollbrecht, B. Aboba, J. Carlson Filename : draft-ietf-pppext-rfc2284bis-10.txt Pages : 40 Date : 2003-1-23 This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms. EAP typically runs directly over the link layer without requiring IP, but is reliant on lower layer ordering guarantees as in PPP and IEEE 802. EAP does provide its own support for duplicate elimination and retransmission. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. While EAP was originally developed for use with PPP, it is also now in use with IEEE 802. This document obsoletes RFC 2284. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-rfc2284bis-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-rfc2284bis-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-23094001.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-rfc2284bis-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-rfc2284bis-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-23094001.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp@merit.edu Fri Jan 24 08:41:25 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19073 for ; Fri, 24 Jan 2003 08:41:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1BEB891440; Fri, 24 Jan 2003 08:44:27 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C738791441; Fri, 24 Jan 2003 08:44:26 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AED4891440 for ; Fri, 24 Jan 2003 08:44:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9D0A75E04F; Fri, 24 Jan 2003 08:44:25 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 4E6965E045 for ; Fri, 24 Jan 2003 08:44:25 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10773; Fri, 24 Jan 2003 06:44:24 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0ODiO4t009148; Fri, 24 Jan 2003 08:44:24 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6) with ESMTP id h0ODiNq5030032; Fri, 24 Jan 2003 08:44:24 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6/Submit) id h0ODiNtE030029; Fri, 24 Jan 2003 08:44:23 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15921.17206.960391.48107@gargle.gargle.HOWL> Date: Fri, 24 Jan 2003 08:44:22 -0500 From: James Carlson To: Stephane St Hilaire Cc: "Ietf-Ppp (E-mail)" Subject: RE: PPP over Sonet default MRU In-Reply-To: Stephane St Hilaire's message of 23 January 2003 17:59:02 References: <8812A03F65CDD511AE98006008F5E8714CE165@hermes.hyperchip.com> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Stephane St Hilaire writes: > I think we're stuck in semantics. I think we're just stuck. > When negociating Quality Protocol (even if you reject this option), you're > NOT negociating your "ability to negociate" link quality monitoring. The two are one and the same. When the peer says Configure-Reject, the only thing you know is that he's not willing to negotiate anything about that option. If he were willing to negotiate, he would have sent Configure-Nak or Configure-Ack instead. Configure-Reject can mean two things -- "I know what this is, but I don't want it" or "I have no idea what you're talking about." The way the protocol was designed, there is *NO* distinction between these two. They're equivalent. > You're > specifying whether you support link quality monitoring or not. Yes link > quality monitoring IS optional. Having a MRU however is not a negociable > "feature". You may or may not support values other than the default but you > can't say I don't support "MRU negociation". Heck just sending a NACK or a > REJECT is PART of the negociation. Not that this matters a whole lot, it's > just semantics. If you say "LCP Configure-Reject" for MRU, then you're saying that you don't want that option. > > It means "I don't support negotiation of your MRU (my MTU); you'll > > have to live with whatever the default might be, or whatever your > > local configuration tells you to do." > > If that ("your MRU is fine") is actually what you wanted to tell the remote > end, a simple ACK would have done the trick. Ah, but that's not the same. LCP Configure-Reject says "I don't feel like discussing this option with you at all -- I'm not going to suggest a different value with Configure-Nak, I'm not going to agree to it, so you'd better just withdraw it from your next Configure-Request." That's not the same thing as "your MRU is fine." What the peer issuing that Configure-Reject is saying is that he doesn't *care* what you think of that option. If, due to your own implementation decisions, you have to make some judgement about what the value ought to be or whether the resulting link is usable at all, that's up to the discretion of the implementor. > > Obviously, the RFC can't specify a default. That's not the same thing > > as saying that there *is* no default. > > I meant of course that there is no RFC specified default, and I don't know > why we are still talking about IPCP. Because the negotiation models are exactly the same. I'm trying to point out to you that there are *NO* privileged options. There are NO options that are "required" for implementation. There are NO options that you can rely on to be in any implementation. You CANNOT assume that the MRU option is somehow special. The fact that the peer sends the option says nothing about whether the option is understood to mean anything. > > Basically, if you had a PPP implementation that refused *all* > > configuration options, that would be perfectly legal. > > Sure as long as the link came up using default values. ... *OR* with explicitly configured values. Where there is no explicit configuration, there is a common default value. > I believe we have definitively exhausted this particular subject. [...] > I agree. And if we follow up to it, could we *PLEASE* switch to just plain text? -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Fri Jan 24 09:41:45 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20994 for ; Fri, 24 Jan 2003 09:41:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BF48C9122F; Fri, 24 Jan 2003 09:44:53 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8916391244; Fri, 24 Jan 2003 09:44:53 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5C5FC9122F for ; Fri, 24 Jan 2003 09:44:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 454645E05B; Fri, 24 Jan 2003 09:44:52 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mail.alcatel.be (alc239.alcatel.be [195.207.101.239]) by segue.merit.edu (Postfix) with ESMTP id 850415DE0F for ; Fri, 24 Jan 2003 09:44:51 -0500 (EST) Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by mail.alcatel.be (8.10.1/8.11.4) with ESMTP id h0OEioe07451 for ; Fri, 24 Jan 2003 15:44:50 +0100 (MET) Received: from alcatel.be ([138.203.65.127]) by bemail04.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003012415444882:4770 ; Fri, 24 Jan 2003 15:44:48 +0100 Message-ID: <3E31515D.1FECD737@alcatel.be> Date: Fri, 24 Jan 2003 15:44:45 +0100 From: suresh.leroy@alcatel.be Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ppp@merit.edu Subject: : typo in section 4.1 X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 01/24/2003 15:44:48, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 01/24/2003 15:44:50, Serialize complete at 01/24/2003 15:44:50 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hello, Should the MUST be MUST NOT in the following sentence of section 4.1 "Additional Request packets MUST be sent until a valid Response packet is received, or an optional retry counter expires." Regards, Suresh From owner-ietf-ppp@merit.edu Fri Jan 24 09:50:15 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21227 for ; Fri, 24 Jan 2003 09:50:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 20AF991220; Fri, 24 Jan 2003 09:53:21 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E2B8691441; Fri, 24 Jan 2003 09:53:20 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 092D391220 for ; Fri, 24 Jan 2003 09:53:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id E2A595E05C; Fri, 24 Jan 2003 09:53:19 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 77EC15DFCE for ; Fri, 24 Jan 2003 09:53:19 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h0ODgN505783; Fri, 24 Jan 2003 05:42:27 -0800 Date: Fri, 24 Jan 2003 05:42:23 -0800 (PST) From: Bernard Aboba To: suresh.leroy@alcatel.be Cc: ietf-ppp@merit.edu Subject: Re: : typo in section 4.1 In-Reply-To: <3E31515D.1FECD737@alcatel.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu It is indeed a MUST. That's how EAP provides reliable delivery. On Fri, 24 Jan 2003 suresh.leroy@alcatel.be wrote: > Hello, > > Should the MUST be MUST NOT in the following sentence of section 4.1 > "Additional Request packets MUST be sent until a valid Response packet > is received, or an optional retry counter expires." > > Regards, > Suresh > From owner-ietf-ppp@merit.edu Fri Jan 24 10:02:44 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21800 for ; Fri, 24 Jan 2003 10:02:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E0FDF91442; Fri, 24 Jan 2003 10:05:48 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A21F491443; Fri, 24 Jan 2003 10:05:48 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DBFC391442 for ; Fri, 24 Jan 2003 10:05:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id ABCEE5DE71; Fri, 24 Jan 2003 10:05:46 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by segue.merit.edu (Postfix) with ESMTP id 272055DD9B for ; Fri, 24 Jan 2003 10:05:46 -0500 (EST) Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id h0OF5Sm14939; Fri, 24 Jan 2003 16:05:28 +0100 Received: from alcatel.be ([138.203.65.127]) by bemail04.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003012416052618:4968 ; Fri, 24 Jan 2003 16:05:26 +0100 Message-ID: <3E315632.449D5E9E@alcatel.be> Date: Fri, 24 Jan 2003 16:05:22 +0100 From: suresh.leroy@alcatel.be Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: ietf-ppp@merit.edu Subject: Re: : typo in section 4.1 References: X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 01/24/2003 16:05:26, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 01/24/2003 16:05:28, Serialize complete at 01/24/2003 16:05:28 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Thanks, The problem seems to be my interpretation of an "additional request", here it is a retransmission not a new request. My fault. Suresh Bernard Aboba wrote: > It is indeed a MUST. That's how EAP provides reliable delivery. > > On Fri, 24 Jan 2003 suresh.leroy@alcatel.be wrote: > > > Hello, > > > > Should the MUST be MUST NOT in the following sentence of section 4.1 > > "Additional Request packets MUST be sent until a valid Response packet > > is received, or an optional retry counter expires." > > > > Regards, > > Suresh > > From owner-ietf-ppp@merit.edu Mon Jan 27 20:22:10 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02301 for ; Mon, 27 Jan 2003 20:22:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4F80E912D5; Mon, 27 Jan 2003 20:25:14 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0C83491277; Mon, 27 Jan 2003 20:25:13 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7A949912D7 for ; Mon, 27 Jan 2003 20:22:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5F0715DEEE; Mon, 27 Jan 2003 20:22:53 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from watervalley.net (mail.watervalley.net [12.168.164.3]) by segue.merit.edu (Postfix) with SMTP id 84E2B5DDE2 for ; Mon, 27 Jan 2003 20:22:51 -0500 (EST) Received: from [204.39.227.134] (HELO greendragon.com) by watervalley.net (Stalker SMTP Server 1.8b8) with ESMTP id S.0044024388; Mon, 27 Jan 2003 19:22:47 -0600 Message-ID: <3E35DB37.AF3256DD@greendragon.com> Date: Mon, 27 Jan 2003 20:23:43 -0500 From: William Allen Simpson Organization: DayDreamer X-Mailer: Mozilla 4.79 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "Ietf-Ppp (E-mail)" Subject: Re: PPP over Sonet default MRU References: <8812A03F65CDD511AE98006008F5E8714CE165@hermes.hyperchip.com> <15921.17206.960391.48107@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit I don't read the list regularly, but somebody asked me to look over this thread. I'd like to affirm some of what Carlson said, but correct a few mistakes. (And I also didn't read most of the HTML mail.) On Configure-Reject: Implementation of -Reject is mandatory. But it doesn't mean that you have implemented MRU or anything else. You're just rejecting a raw option number. Carlson says (which confuses the issue a bit) it could also mean "I know what this is, but I don't want it". That's not correct. When you know what it is, you MUST send -Nak, instead (except in the case of boolean options; see, it confuses the issue :-). On Configure-Nak: Implementation of -Nak is mandatory. In the case at hand, where an MTU is configured to 4470, the implementation MAY -Nak with MRU 4470: Finally, an implementation may be configured to request the negotiation of a specific Configuration Option. If that option is not listed, then that option MAY be appended to the list of Nak'd Configuration Options, in order to prompt the peer to include that option in its next Configure-Request packet. Any value fields for the option MUST indicate values acceptable to the Configure-Nak sender. That doesn't mean that the peer will send a -Request with MRU 4470. It "MAY"! (see the full text) On MRU: Implementation of MRU is optional. But MRU has a default. In most cases, that default is 1500. (For example, with some kinds of links, such as Frame Relay, it's 1600. We chose *NOT* to make it larger for SONET/SDH.) At the end of a successful negotiation, when all is said and done, and the peer has not negotiated MRU, it is absolutely prohibited to send more than 1500 bytes. The maximum length for the Information field, including Padding, but not including the Protocol field, is termed the Maximum Receive Unit (MRU), which defaults to 1500 octets. By negotiation, consenting PPP implementations may use other values for the MRU. [RFC 1661, Page 5] It doesn't matter than some miscreant operator has accidentally configured MTU 4470. Sending 4470 into a link with a 1500 MRU is non-conformant. As you say in your 1st message, it is "wrong". (And, in every implementation I've ever done, would be discarded.) Contrary to Carlson's assertion, manual configuration MUST NOT ignore the PPP negotiation. PPP is intended to be resilient in the face of operator error. ... implementor can specify improvements to the default configuration, which are automatically communicated to the peer without operator intervention. Finally, the operator may explicitly configure options for the link which enable the link to operate in environments where it would otherwise be impossible. [RFC 1661, Page 2] In order for an implementor to specify an improvement, or an operator to configure an option, that option MUST be implemented, and negotiated with the peer. The whole point of PPP is the option negotiation. We already knew that SLIP sucked, as did a host of others (SLFP, cisco HDLC, and on and on), because they were hard to successfully configure, as the implementors all had different ideas about what was "best", and the operators made too many mistakes. If it doesn't negotiate options, it's not PPP! -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 From owner-ietf-ppp@merit.edu Tue Jan 28 07:34:23 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23596 for ; Tue, 28 Jan 2003 07:34:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9E1C0912FB; Tue, 28 Jan 2003 07:33:55 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5EA04912FE; Tue, 28 Jan 2003 07:33:53 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D5AB5912FB for ; Tue, 28 Jan 2003 07:32:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id BA49B5DF0B; Tue, 28 Jan 2003 07:32:22 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from xmxpita.excite.com (nn5.excitenetwork.com [207.159.120.59]) by segue.merit.edu (Postfix) with ESMTP id A1D875DE32 for ; Tue, 28 Jan 2003 07:32:22 -0500 (EST) Received: by xmxpita.excite.com (Postfix, from userid 110) id 621541E490; Tue, 28 Jan 2003 07:32:20 -0500 (EST) To: ietf-ppp@merit.edu Subject: PPP API (programmer's guide) in Linux. Received: from [203.197.138.194] by xprdmailfe24.nwk.excite.com via HTTP; Tue, 28 Jan 2003 07:32:20 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = fe75b442abd8b64b40ec18a8534e2203 Reply-To: c.srinivasan@excite.com From: "Srinivasan Chakravarthy" MIME-Version: 1.0 X-Sender: c.srinivasan@excite.com X-Mailer: PHP Content-Type: multipart/alternative; boundary="EXCITEBOUNDARY_000__13e89ef6c3f928a5c97b72f87d4cb730"; Content-Transfer-Encoding: 7bit Message-Id: <20030128123220.621541E490@xmxpita.excite.com> Date: Tue, 28 Jan 2003 07:32:20 -0500 (EST) Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --EXCITEBOUNDARY_000__13e89ef6c3f928a5c97b72f87d4cb730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I am developing dial-up application in (RedHat) Linux. Pls let me know where i can find the Linux programmer's guide that provides APIs to open, close (and send/receive data) the PPP connections (over async/modem interfaces). Thanks very much for your help, Best Regards, Srinivasan. _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! --EXCITEBOUNDARY_000__13e89ef6c3f928a5c97b72f87d4cb730 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
Hi,

I am developing dial-up application in (RedHat) Linux. Pls let me know where i can find the Linux programmer's guide that provides APIs to open, close (and send/receive data) the PPP connections (over async/modem interfaces).

Thanks very much for your help,

Best Regards,

Srinivasan.





Join Excite! - http://www.excite.com
The most personalized portal on the Web! --EXCITEBOUNDARY_000__13e89ef6c3f928a5c97b72f87d4cb730-- From owner-ietf-ppp@merit.edu Tue Jan 28 07:38:18 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23811 for ; Tue, 28 Jan 2003 07:38:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D5C59912FE; Tue, 28 Jan 2003 07:41:29 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A3122912FF; Tue, 28 Jan 2003 07:41:29 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 892EF912FE for ; Tue, 28 Jan 2003 07:41:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 74BFE5DE4A; Tue, 28 Jan 2003 07:41:28 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id EBE885DE32 for ; Tue, 28 Jan 2003 07:41:27 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA06746; Tue, 28 Jan 2003 05:41:18 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0SCfI4t018657; Tue, 28 Jan 2003 07:41:18 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.7+Sun/8.12.7) with ESMTP id h0SCfIuH010296; Tue, 28 Jan 2003 07:41:18 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.7+Sun/8.12.7/Submit) id h0SCfIua010293; Tue, 28 Jan 2003 07:41:18 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15926.31342.74778.878089@gargle.gargle.HOWL> Date: Tue, 28 Jan 2003 07:41:18 -0500 From: James Carlson To: William Allen Simpson Cc: "Ietf-Ppp (E-mail)" Subject: Re: PPP over Sonet default MRU In-Reply-To: William Allen Simpson's message of 27 January 2003 20:23:43 References: <8812A03F65CDD511AE98006008F5E8714CE165@hermes.hyperchip.com> <15921.17206.960391.48107@gargle.gargle.HOWL> <3E35DB37.AF3256DD@greendragon.com> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit William Allen Simpson writes: > On Configure-Reject: > > Implementation of -Reject is mandatory. But it doesn't mean that you > have implemented MRU or anything else. You're just rejecting a raw > option number. > > Carlson says (which confuses the issue a bit) it could also mean > "I know what this is, but I don't want it". That's not correct. > When you know what it is, you MUST send -Nak, instead (except in the > case of boolean options; see, it confuses the issue :-). I'm afraid I must disagree. Suppose I get an LCP Configure-Request with the Authentication Protocol option, but I have no local credentials to offer, or I am configured to refuse to identify myself. In this case, I cannot possibly send a sensible Configure-Nak, and I must respond with Configure-Reject. Or suppose I have an implementation that supports MP, but only if the call arrives over a certain medium (e.g., I am configured to support MP for ISDN clients, but not for asynchronous callers). Again, I have to send Configure-Reject for an async caller who offers MRRU, because I have no sensible alternative. That's what I was trying to get across. The code that you're staring at might have the capability of responding to a particular option, but still be forced to send Configure-Reject anyway because (with the current configuration) there's no way to continue using that option. Thus, Configure-Reject can indeed mean "I know what this is, but I just don't want it at all." > If it doesn't negotiate options, it's not PPP! I mostly agree with that, and I certainly agree that it's at best completely foolhardy to ignore the benefits that negotiation provides, but I do disagree with outlawing "prior arrangement." Suitably configured peers may do anything they like -- including using encapsulations that aren't in the RFCs -- and there's not much that the RFCs can do about it. There's no "IETF police squad." Obviously, if someone does that, he's on his own. If you want to call all possible external arrangements "not PPP," I suppose that's fine, but it doesn't mean that such things are not done at all. (I've seen any of a number of tremendously feeble justifications for using *parts* of PPP without including crucial bits of the negotiation.) For what it's worth, I think this is all a moot discussion. The behavior described in the original post reveals plain old bugs in both implementations, and the poster should contact the vendors and complain. Instead, he asked if it was "possible" to refuse MRU negotiation at all, which is how we got here. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Tue Jan 28 09:22:04 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26406 for ; Tue, 28 Jan 2003 09:22:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D23FC9121D; Tue, 28 Jan 2003 09:25:18 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9DFD99130A; Tue, 28 Jan 2003 09:25:18 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 673429121D for ; Tue, 28 Jan 2003 09:25:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4DB565DEFB; Tue, 28 Jan 2003 09:25:17 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id F2D5F5DE22 for ; Tue, 28 Jan 2003 09:25:16 -0500 (EST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07228; Tue, 28 Jan 2003 07:25:16 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0SEPF5f023667; Tue, 28 Jan 2003 09:25:15 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.7+Sun/8.12.7) with ESMTP id h0SEPFuH014044; Tue, 28 Jan 2003 09:25:15 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.7+Sun/8.12.7/Submit) id h0SEPFML014041; Tue, 28 Jan 2003 09:25:15 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15926.37579.400964.177818@gargle.gargle.HOWL> Date: Tue, 28 Jan 2003 09:25:15 -0500 From: James Carlson To: c.srinivasan@excite.com Cc: ietf-ppp@merit.edu Subject: Re: PPP API (programmer's guide) in Linux. In-Reply-To: Srinivasan Chakravarthy's message of 28 January 2003 07:32:20 References: <20030128123220.621541E490@xmxpita.excite.com> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Srinivasan Chakravarthy writes: > Hi, I am developing dial-up application in (RedHat) Linux. Pls let > me know where i can find the Linux programmer's guide that provides > APIs to open, close (and send/receive data) the PPP connections > (over async/modem interfaces). Thanks very much for your help, Best Wrong mailing list; this isn't a protocol issue. Try the Linux PPP mailing list (linux-ppp@vger.kernel.org) instead. (For what it's worth, there's no such "API," other than exec(2) and kill(2).) -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Tue Jan 28 11:32:15 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00056 for ; Tue, 28 Jan 2003 11:32:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5946E9133E; Tue, 28 Jan 2003 11:33:48 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7BCC291346; Tue, 28 Jan 2003 11:33:45 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 861AF91348 for ; Tue, 28 Jan 2003 11:32:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6BAA45DF44; Tue, 28 Jan 2003 11:32:09 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from watervalley.net (mail.watervalley.net [12.168.164.3]) by segue.merit.edu (Postfix) with SMTP id 67C6D5DEC0 for ; Tue, 28 Jan 2003 11:32:08 -0500 (EST) Received: from [204.39.230.192] (HELO greendragon.com) by watervalley.net (Stalker SMTP Server 1.8b8) with ESMTP id S.0044084634; Tue, 28 Jan 2003 10:12:29 -0600 Message-ID: <3E36AC37.DBCB4B0C@greendragon.com> Date: Tue, 28 Jan 2003 11:14:10 -0500 From: William Allen Simpson Organization: DayDreamer X-Mailer: Mozilla 4.79 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "Ietf-Ppp (E-mail)" Subject: Re: PPP over Sonet default MRU References: <8812A03F65CDD511AE98006008F5E8714CE165@hermes.hyperchip.com> <15921.17206.960391.48107@gargle.gargle.HOWL> <3E35DB37.AF3256DD@greendragon.com> <15926.31342.74778.878089@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit James Carlson wrote: > > I'm afraid I must disagree. Suppose I get an LCP Configure-Request > with the Authentication Protocol option, but I have no local > credentials to offer, or I am configured to refuse to identify myself. > In this case, I cannot possibly send a sensible Configure-Nak, and I > must respond with Configure-Reject. > You don't seem to be disagreeing in *THIS* example. In the text, this scenario is clearly covered by: If some Configuration Options received in a Configure-Request are not recognizable or are not acceptable for negotiation (as configured by a network administrator), then the implementation MUST transmit a Configure-Reject. [RFC 1661, Page 31] > Or suppose I have an implementation that supports MP, but only if the > call arrives over a certain medium (e.g., I am configured to support > MP for ISDN clients, but not for asynchronous callers). Again, I have > to send Configure-Reject for an async caller who offers MRRU, because > I have no sensible alternative. > Likewise (op cit). Although, to be pedantic, multilink was first envisioned and implemented to cover multiple async links, and we argued for a long time about the size of fields to cover simultaneous use of async, ISDN, and FrameRelay links. (I'm pretty sure we gave up on async backup for SONET/SDH. ;-) So, that would seem to be a "self defeating" configuration.... > That's what I was trying to get across. The code that you're staring > at might have the capability of responding to a particular option, but > still be forced to send Configure-Reject anyway because (with the > current configuration) there's no way to continue using that option. > Ahh, you are talking about code reuse, and I was talking about operation. It may be true that there is code somewhere in the system that understands an option, but when the options are inapplicable to a particular *kind* of interface, I've always understood that to be "not recognizable". > > If it doesn't negotiate options, it's not PPP! > > I mostly agree with that, and I certainly agree that it's at best > completely foolhardy to ignore the benefits that negotiation provides, > but I do disagree with outlawing "prior arrangement." Suitably > configured peers may do anything they like -- including using > encapsulations that aren't in the RFCs -- and there's not much that > the RFCs can do about it. There's no "IETF police squad." > Well, actually, there _is_ a "police squad". It's the purchaser! When I've specified contracts, and I've been responsible for hundreds of millions of dollars of contracts over the years, I've always tried to specify those magic terms of "conformant", "compliant", and "interoperable". (Indeed, long before PPP, circa the mid-80s, the very first piece of boilerplate that I was able to insert in the Michigan appropriations statutes was a requirement that computer and telecommunications purchases required demonstration of interoperation with at least 3 implementations. Apple was very unhappy about it, as was Burroughs. But lo and hehold, a few months later, MacTCP appeared!) And yes, I've managed to force a complete refund when a vendor lied about it, and forfeit of a $250,000 performance bond. That's something like "policing". > Obviously, if someone does that, he's on his own. If you want to call > all possible external arrangements "not PPP," I suppose that's fine, > but it doesn't mean that such things are not done at all. (I've seen > any of a number of tremendously feeble justifications for using > *parts* of PPP without including crucial bits of the negotiation.) > I have also seen such "PPP Lite" idiocy. > For what it's worth, I think this is all a moot discussion. The > behavior described in the original post reveals plain old bugs in both > implementations, and the poster should contact the vendors and > complain. ... And here we agree, again. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 From owner-ietf-ppp@merit.edu Tue Jan 28 11:40:00 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00475 for ; Tue, 28 Jan 2003 11:40:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EDC699131B; Tue, 28 Jan 2003 11:41:03 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B46969131C; Tue, 28 Jan 2003 11:41:00 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 431909131B for ; Tue, 28 Jan 2003 11:40:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 22B245DF8B; Tue, 28 Jan 2003 11:40:57 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 94C165DF7F for ; Tue, 28 Jan 2003 11:40:56 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24054; Tue, 28 Jan 2003 08:40:51 -0800 (PST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0SGep4t004605; Tue, 28 Jan 2003 11:40:51 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.7+Sun/8.12.7) with ESMTP id h0SGepuH014363; Tue, 28 Jan 2003 11:40:51 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.7+Sun/8.12.7/Submit) id h0SGepZv014360; Tue, 28 Jan 2003 11:40:51 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15926.45715.151042.680937@gargle.gargle.HOWL> Date: Tue, 28 Jan 2003 11:40:51 -0500 From: James Carlson To: William Allen Simpson Cc: "Ietf-Ppp (E-mail)" Subject: Re: PPP over Sonet default MRU In-Reply-To: William Allen Simpson's message of 28 January 2003 11:14:10 References: <8812A03F65CDD511AE98006008F5E8714CE165@hermes.hyperchip.com> <15921.17206.960391.48107@gargle.gargle.HOWL> <3E35DB37.AF3256DD@greendragon.com> <15926.31342.74778.878089@gargle.gargle.HOWL> <3E36AC37.DBCB4B0C@greendragon.com> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit William Allen Simpson writes: > Although, to be pedantic, multilink was first envisioned and > implemented to cover multiple async links, and we argued for a long > time about the size of fields to cover simultaneous use of async, ISDN, > and FrameRelay links. (I'm pretty sure we gave up on async backup for > SONET/SDH. ;-) So, that would seem to be a "self defeating" > configuration.... Certainly -- and the first MP implementation I did was tested using async because that's all we had at the time. The point is not whether async is usable with MP, but rather what the local policy on its use might be. > > That's what I was trying to get across. The code that you're staring > > at might have the capability of responding to a particular option, but > > still be forced to send Configure-Reject anyway because (with the > > current configuration) there's no way to continue using that option. > > > Ahh, you are talking about code reuse, and I was talking about > operation. It may be true that there is code somewhere in the > system that understands an option, but when the options are > inapplicable to a particular *kind* of interface, I've always > understood that to be "not recognizable". OK; then it's just a word usage issue. By "not recognizable" I mean "not implemented in any way at all." "Not recognizable" covers what you do with options such as 201 -- never defined or used anywhere, no idea what it might mean, and must be Configure-Rejected. It's where you end up in the "default:" case in your switch statement. ;-} "Recognized but unwanted" was a slightly different case, at least for someone looking at some bit of PPP code and trying to understand how the options work, but it's indistinguishable in behavior on the wire. > Well, actually, there _is_ a "police squad". It's the purchaser! I completely agree. There's *no* IETF-related enforcement -- it's up to customers to complain when a vendor violates an RFC *AND* that violation causes interoperability trouble. I think that lack of specific IETF enforcement is a good thing, because it puts the focus right where it belongs -- on quality of implementation and interoperability rather than on abstract "conformance" to some specification. Using "conformance" as a proxy for correct operation is a problem seen in other standards bodies, and it tends to result in forcing customers to buy all of their equipment from a sole vendor because of minor differences in interpretation. Or, in other words, vendors are required to be smart, rather than being slaves to the standards process. As we well know, there are many possible violations that do not affect interoperability, or that actually make an implementation *more* interoperable. (E.g., violating the unnecessary RFC 2453 requirement of dropping authenticated datagrams when you have no authentication configured, even though a 1058 router would have accepted the those same datagrams.) > I have also seen such "PPP Lite" idiocy. As far as I've seen, the bug seems to bite people who think that PPP's default three second restart timer has something to do with "performance." It's a pretty profound bit of confusion, and often not repairable. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Tue Jan 28 12:56:38 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02353 for ; Tue, 28 Jan 2003 12:56:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 70E709131C; Tue, 28 Jan 2003 12:59:46 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1573191325; Tue, 28 Jan 2003 12:59:46 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CF5FB9131C for ; Tue, 28 Jan 2003 12:59:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id ABA205DF4C; Tue, 28 Jan 2003 12:59:44 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mail1.hyperchip.com (mail1.hyperchip.com [216.94.112.3]) by segue.merit.edu (Postfix) with ESMTP id 349E75DE8A for ; Tue, 28 Jan 2003 12:59:44 -0500 (EST) Received: from hermes.hyperchip.com ([10.0.0.12] helo=hermes.hypernet.com) by mail1.hyperchip.com with esmtp (Exim 3.22 #1) id 18da1P-0003vx-00 for ietf-ppp@merit.edu; Tue, 28 Jan 2003 12:59:43 -0500 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Jan 2003 12:53:38 -0500 Message-ID: <8812A03F65CDD511AE98006008F5E8714CE175@hermes.hyperchip.com> From: Stephane St Hilaire To: "Ietf-Ppp (E-mail)" Subject: RE: PPP over Sonet default MRU Date: Tue, 28 Jan 2003 12:53:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C6F6.2C4DB5E0" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C6F6.2C4DB5E0 Content-Type: text/plain > -----Original Message----- > From: James Carlson [mailto:james.d.carlson@east.sun.com] > Sent: Tuesday, January 28, 2003 11:41 AM > To: William Allen Simpson > Cc: Ietf-Ppp (E-mail) > Subject: Re: PPP over Sonet default MRU > > > Well, actually, there _is_ a "police squad". It's the purchaser! > > I completely agree. There's *no* IETF-related enforcement -- it's up > to customers to complain when a vendor violates an RFC *AND* that > violation causes interoperability trouble. Might is right ! The bigger the customer the more chances he has that is complaint will be taken seriously, regardless of its validity. The bigger the vendor the less he needs to care about conformance to standards. Sounds good to me. > > I think that lack of specific IETF enforcement is a good thing, > because it puts the focus right where it belongs -- on quality of > implementation and interoperability rather than on abstract So being non conformant would make for higher quality (based on what outside the IETF authority ?) or even better interoperability ? I don't see how. Standard: "4 : something set up and established by authority as a rule for the measure of quantity, weight, extent, value, or quality" > "conformance" to some specification. Using "conformance" as a proxy > for correct operation is a problem seen in other standards bodies, and > it tends to result in forcing customers to buy all of their equipment > from a sole vendor because of minor differences in interpretation. As opposed to non conformance which insures that every vendor interoperate well. > > Or, in other words, vendors are required to be smart, rather than > being slaves to the standards process. Anyone can participate to the standards process so I don't see how anyone could become a "slave" to it. As for a single vendor thinking that he's smarter than the IETF, it sounds a bit arrogant. > As we well know, there are many possible violations that do not affect > interoperability, or that actually make an implementation *more* I'd be curious to see a list of these violations. I'd even like these to show up in some new rfcs or drafts or else what is the point of the IETF in the first place ? To publish optional guidelines for vendors to disregard ? Steph ------_=_NextPart_001_01C2C6F6.2C4DB5E0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: PPP over Sonet default MRU

> -----Original Message-----
> From: James Carlson [mailto:james.d.carlson@east= .sun.com]
> Sent: Tuesday, January 28, 2003 11:41 AM
> To: William Allen Simpson
> Cc: Ietf-Ppp (E-mail)
> Subject: Re: PPP over Sonet default MRU
>
> > Well, actually, there _is_ a "police = squad".  It's the purchaser! 
>
> I completely agree.  There's *no* = IETF-related enforcement -- it's up
> to customers to complain when a vendor violates = an RFC *AND* that
> violation causes interoperability = trouble.

Might is right ! The bigger the customer the more = chances he has that is complaint will be taken seriously, regardless of = its validity. The bigger the vendor the less he needs to care about = conformance to standards. Sounds good to me.


>
> I think that lack of specific IETF enforcement = is a good thing,
> because it puts the focus right where it = belongs -- on quality of
> implementation and interoperability rather than = on abstract

So being non conformant would make for higher quality = (based on what outside the IETF authority ?) or even better = interoperability ? I don't see how.

Standard:
"4 : something set up and established by = authority as a rule for the measure of quantity, weight, extent, value, = or quality"



> "conformance" to some = specification.  Using "conformance" as a proxy
> for correct operation is a problem seen in = other standards bodies, and
> it tends to result in forcing customers to buy = all of their equipment
> from a sole vendor because of minor differences = in interpretation.

As opposed to non conformance which insures that = every vendor interoperate well.

>
> Or, in other words, vendors are required to be = smart, rather than
> being slaves to the standards process.

Anyone can participate to the standards process so I = don't see how anyone could become a "slave" to it.
As for a single vendor thinking that he's smarter = than the IETF, it sounds a bit arrogant.


> As we well know, there are many possible = violations that do not affect
> interoperability, or that actually make an = implementation *more*

I'd be curious to see a list of these violations. I'd = even like these to show up in some new rfcs or drafts or else what is = the point of the IETF in the first place ? To publish optional = guidelines for vendors to disregard ?


Steph

------_=_NextPart_001_01C2C6F6.2C4DB5E0-- From owner-ietf-ppp@merit.edu Tue Jan 28 13:19:38 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02782 for ; Tue, 28 Jan 2003 13:19:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3B1CE91224; Tue, 28 Jan 2003 13:19:50 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B5B159132B; Tue, 28 Jan 2003 13:19:48 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 99B2691224 for ; Tue, 28 Jan 2003 13:19:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7BD6C5DE74; Tue, 28 Jan 2003 13:19:45 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from watervalley.net (mail.watervalley.net [12.168.164.3]) by segue.merit.edu (Postfix) with SMTP id 596515DDEF for ; Tue, 28 Jan 2003 13:19:41 -0500 (EST) Received: from [204.39.230.192] (HELO greendragon.com) by watervalley.net (Stalker SMTP Server 1.8b8) with ESMTP id S.0044093555; Tue, 28 Jan 2003 12:00:14 -0600 Message-ID: <3E36C567.50D3A82C@greendragon.com> Date: Tue, 28 Jan 2003 13:02:02 -0500 From: William Allen Simpson Organization: DayDreamer X-Mailer: Mozilla 4.79 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "Ietf-Ppp (E-mail)" Subject: Re: PPP over Sonet default MRU References: <8812A03F65CDD511AE98006008F5E8714CE165@hermes.hyperchip.com> <15921.17206.960391.48107@gargle.gargle.HOWL> <3E35DB37.AF3256DD@greendragon.com> <15926.31342.74778.878089@gargle.gargle.HOWL> <3E36AC37.DBCB4B0C@greendragon.com> <15926.45715.151042.680937@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit James Carlson wrote: > > William Allen Simpson writes: > > Ahh, you are talking about code reuse, and I was talking about > > operation. It may be true that there is code somewhere in the > > system that understands an option, but when the options are > > inapplicable to a particular *kind* of interface, I've always > > understood that to be "not recognizable". > > OK; then it's just a word usage issue. By "not recognizable" I mean > "not implemented in any way at all." "Not recognizable" covers what > you do with options such as 201 -- never defined or used anywhere, no > idea what it might mean, and must be Configure-Rejected. It's where > you end up in the "default:" case in your switch statement. ;-} > > "Recognized but unwanted" was a slightly different case, at least for > someone looking at some bit of PPP code and trying to understand how > the options work, but it's indistinguishable in behavior on the wire. > In general, protocol specifications such as PPP are written about behaviour on the wire. Where an implementation hint was provided, I've always used the "Implementation Note" subsection. In the case at hand, "No Protocol Field Compression" is specified for SONET/SDH. Thus, PFC would be -Rejected. The router may very well have code to support some other kind of interface, but on this link, it is "unrecognized". > I think that lack of specific IETF enforcement is a good thing, > because it puts the focus right where it belongs -- on quality of > implementation and interoperability rather than on abstract > "conformance" to some specification. Using "conformance" as a proxy > for correct operation is a problem seen in other standards bodies, and > it tends to result in forcing customers to buy all of their equipment > from a sole vendor because of minor differences in interpretation. > Indeed, we had that problem with the first specification of PPP over SONET/SDH! Several manufacturers correctly built chips that had no problems with long strings of zeroes and quickly re-sync'd within two frames, as clearly indicated in the original Bellcore specification. Unfortunately, Lucent (and maybe Nortel, by hearsay, I didn't see a test of them), not only failed completely, but they were so cheap that they didn't include an independent clock, and unrelated signals sent in the return direction lost sync, too. Amazingly bad design, but "conformant" because it wasn't "prohibited". We have a tradition here of working around such flaws. Just as we used UI in the PPP header to get around a flaw in an early HDLC chipset, the WG agreed to change the specification to (optionally) scramble the signal for those bad early OC3 links. (I have no idea why Andy wanted to scramble OC12 and later links; there's certainly no technical reasons. Oh well, as long as it works and it's no cost, who cares?) > Or, in other words, vendors are required to be smart, rather than > being slaves to the standards process. > > As we well know, there are many possible violations that do not affect > interoperability, or that actually make an implementation *more* > interoperable. (E.g., violating the unnecessary RFC 2453 requirement > of dropping authenticated datagrams when you have no authentication > configured, even though a 1058 router would have accepted the those > same datagrams.) > Bad example. Certainly, those authenticated datagrams have to be dropped when the operator doesn't know the password -- it's the very definition of authenticated authorization. Sometimes, people confuse interoperability with "easy for dummies". Authentication of routes is for protection against those dummies. (And, technically, a 1058 router should also drop those datagrams, as there are non-zero must-be-zero fields, and the version is higher than 1.) -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 From owner-ietf-ppp@merit.edu Tue Jan 28 13:39:34 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03326 for ; Tue, 28 Jan 2003 13:39:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 60A3F9132B; Tue, 28 Jan 2003 13:42:48 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 33EEF9132D; Tue, 28 Jan 2003 13:42:48 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 307929132B for ; Tue, 28 Jan 2003 13:42:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1F4285DDEF; Tue, 28 Jan 2003 13:42:47 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 500615DDBA for ; Tue, 28 Jan 2003 13:42:46 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.7.Beta0/8.12.7.Beta0) id h0SIgjuI010797 for ietf-ppp@merit.edu env-from ; Tue, 28 Jan 2003 11:42:45 -0700 (MST) Date: Tue, 28 Jan 2003 11:42:45 -0700 (MST) From: Vernon Schryver Message-Id: <200301281842.h0SIgjuI010797@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: PPP over Sonet default MRU References: <3E36C567.50D3A82C@greendragon.com> Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: William Allen Simpson > > As we well know, there are many possible violations that do not affect > > interoperability, or that actually make an implementation *more* > > interoperable. (E.g., violating the unnecessary RFC 2453 requirement > > of dropping authenticated datagrams when you have no authentication > > configured, even though a 1058 router would have accepted the those > > same datagrams.) > > > Bad example. Certainly, those authenticated datagrams have to be dropped > when the operator doesn't know the password -- it's the very definition > of authenticated authorization. Nonsense. In the case at hand, the sender is authenticating its bits, but the receiver has no password and does not care. It is clearly an error in RFC 2453 that requires routers to accept unauthenticated RIPv2 packets but refuse authenticated RIPv2 packets on the same wire. Of course, if the receiving router cares about authentication, it should reject unauthenticated packets as well as packets with bogus authentication. The only way it would make sense reject authenticated packets is if RIPv2 authentication were required. RIPv2 is not required, and so it is silly to write RIPv1 or RIPv2 code that rejects a packet merely because it carries extra and unneeded authentication. > ... > (And, technically, a 1058 router should also drop those datagrams, as > there are non-zero must-be-zero fields, and the version is higher than 1.) RFC 1058 is not the authoritative definition of RIPv1. The BSD source is the authorative definition of the protocol that was created and defined in 4.2BSD and modified slightly over the years. That's just as well, because there are some serious errors in RFC 1058. If RIPv1 had been defined as requiring that packets with non-zero must-be-zero fields be rejected with a version higher than 1, it might have been reasonable to reject them. However, the authoriative definition of RIPv1 is in the ancient code BSD code. The biggest error in that last statement by Mr. Simipson is the self-important notion that the purposes of RFCs include punishing or policing. RFCs have a single legitimate purpose, to increase the likelihood of interoperation. The first and primary rule for all Internet standards is "be liberal in what you accept and conserative in what you send." Must-be-zero fields "MUST" be zero when sent, but when possible ought to be ignored on receipt. At most you might have a special compliance checking mode that logs non-zero must-be-zero fields for shaking down your own code in your own test networks. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Tue Jan 28 14:09:28 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04066 for ; Tue, 28 Jan 2003 14:09:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D22B491334; Tue, 28 Jan 2003 14:07:50 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 42C659133D; Tue, 28 Jan 2003 14:07:30 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EA1689135A for ; Tue, 28 Jan 2003 14:04:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id D713E5DF9A; Tue, 28 Jan 2003 14:04:57 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 592BA5DE74 for ; Tue, 28 Jan 2003 14:04:57 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02256; Tue, 28 Jan 2003 12:04:53 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0SJ4q4t010854; Tue, 28 Jan 2003 14:04:52 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.7+Sun/8.12.7) with ESMTP id h0SJ4quH014763; Tue, 28 Jan 2003 14:04:52 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.7+Sun/8.12.7/Submit) id h0SJ4qoq014760; Tue, 28 Jan 2003 14:04:52 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15926.54354.750836.442045@gargle.gargle.HOWL> Date: Tue, 28 Jan 2003 14:04:50 -0500 From: James Carlson To: William Allen Simpson Cc: "Ietf-Ppp (E-mail)" Subject: Re: PPP over Sonet default MRU In-Reply-To: William Allen Simpson's message of 28 January 2003 13:02:02 References: <8812A03F65CDD511AE98006008F5E8714CE165@hermes.hyperchip.com> <15921.17206.960391.48107@gargle.gargle.HOWL> <3E35DB37.AF3256DD@greendragon.com> <15926.31342.74778.878089@gargle.gargle.HOWL> <3E36AC37.DBCB4B0C@greendragon.com> <15926.45715.151042.680937@gargle.gargle.HOWL> <3E36C567.50D3A82C@greendragon.com> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit William Allen Simpson writes: > > "Recognized but unwanted" was a slightly different case, at least for > > someone looking at some bit of PPP code and trying to understand how > > the options work, but it's indistinguishable in behavior on the wire. > > > In general, protocol specifications such as PPP are written about > behaviour on the wire. Where an implementation hint was provided, > I've always used the "Implementation Note" subsection. Absolutely true, but I think the thread of conversation I had with the original poster revealed a difficulty in exactly this area. He seems to have interpreted "unrecognized" with reference to what the implementation might have in its code, not with reference to what appears on the wire. I think we're in violent agreement. > > As we well know, there are many possible violations that do not affect > > interoperability, or that actually make an implementation *more* > > interoperable. (E.g., violating the unnecessary RFC 2453 requirement > > of dropping authenticated datagrams when you have no authentication > > configured, even though a 1058 router would have accepted the those > > same datagrams.) > > > Bad example. Certainly, those authenticated datagrams have to be dropped > when the operator doesn't know the password -- it's the very definition > of authenticated authorization. No; I think you might be misinterpreting the example. If you're a RIP-2 router configured to accept routing datagrams *WITHOUT* authentication -- which is certainly one of the possible acceptable configurations -- then it's rather senseless to drop datagrams that happen to carry unwanted authentication information. What RFC 2453 says is this: 5.2 Authentication The following algorithm should be used to authenticate a RIP message. If the router is not configured to authenticate RIP-2 messages, then RIP-1 and unauthenticated RIP-2 messages will be accepted; authenticated RIP-2 messages shall be discarded. [...] Obviously, if you're configured to authenticate at all, then you must drop all messages with bad authentication data. If you're not configured to authenticate, though, then you obviously don't care about the security of the incoming message, and dropping it because it's "more secure" than you expect is just senseless. Why prefer unauthenticated data over authenticated data? Is unauthenticated somehow "better?" Worse still, it creates needless confusion. A RIP-1 router (or RIP-2 router that doesn't include authentication extensions) would have accepted those authenticated messages without thinking twice, and would have just ignored the odd address family 0xffff, so dropping the messages makes this compatibility mode operation essentially non-conformant. [See notes copied from RFC 1058 below.] (There's another good example in there that deals with the hop count handling and that results in truncating the maximum network diameter by one -- again, for no good reason, since it ends up being an internal implementation detail whether you increment by one on input or output. Violating this "requirement" is fairly common.) > Sometimes, people confuse interoperability with "easy for dummies". > Authentication of routes is for protection against those dummies. > > (And, technically, a 1058 router should also drop those datagrams, as > there are non-zero must-be-zero fields, and the version is higher than 1.) Nope; that's quite wrong. RIP-1 was intentionally designed to be upward-compatible. See RFC 1058: 3.1. Message formats [...] networks. The address family identifier for IP is 2. None of the RIP implementations available to the author implement any other type of address. However, to allow for future development, implementations are required to skip entries that specify address families that are not supported by the implementation. (The size of these entries will be the same as the size of an entry specifying an IP address.) Processing of the message continues normally after any unsupported entries are skipped. The IP address is the usual [...] 3.4. Input processing This section will describe the handling of datagrams received on UDP port 520. Before processing the datagrams in detail, certain general format checks must be made. These depend upon the version number field in the datagram, as follows: [...] >1 Datagrams whose version number are greater than one are to be processed as described in the rest of this specification. All fields that are described above as "must be zero" are to be ignored. Future versions of the protocol may put data into these fields. Version 1 implementations are to ignore this extra data and process only the fields specified in this document. If you know of an implementation that doesn't do this right, then you might want to notify the vendor, because it's just plain broken. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Tue Jan 28 14:51:30 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05114 for ; Tue, 28 Jan 2003 14:51:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9719B91336; Tue, 28 Jan 2003 14:54:35 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6247091338; Tue, 28 Jan 2003 14:54:35 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 62DFC91336 for ; Tue, 28 Jan 2003 14:54:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4FCE65DE60; Tue, 28 Jan 2003 14:54:34 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id C56035DDBA for ; Tue, 28 Jan 2003 14:54:33 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06730; Tue, 28 Jan 2003 12:54:32 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0SJsW4t023282; Tue, 28 Jan 2003 14:54:32 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.7+Sun/8.12.7) with ESMTP id h0SJsWuH014829; Tue, 28 Jan 2003 14:54:32 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.7+Sun/8.12.7/Submit) id h0SJsW7r014826; Tue, 28 Jan 2003 14:54:32 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15926.57336.229294.461139@gargle.gargle.HOWL> Date: Tue, 28 Jan 2003 14:54:32 -0500 From: James Carlson To: Stephane St Hilaire Cc: "Ietf-Ppp (E-mail)" Subject: RE: PPP over Sonet default MRU In-Reply-To: Stephane St Hilaire's message of 28 January 2003 12:53:32 References: <8812A03F65CDD511AE98006008F5E8714CE175@hermes.hyperchip.com> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Stephane St Hilaire writes: > > I completely agree. There's *no* IETF-related enforcement -- it's up > > to customers to complain when a vendor violates an RFC *AND* that > > violation causes interoperability trouble. > > Might is right ! The bigger the customer the more chances he has that is > complaint will be taken seriously, regardless of its validity. The bigger > the vendor the less he needs to care about conformance to standards. Sounds > good to me. That's about how it works. Assuming you have to live in the real world, where 800 pound gorillas are able to set wacky "standards" for all others to follow, this is what you will be living with. Even where the RFC "proves" that the customer is wrong, large customers with nice green bills are often considered to be "right." It doesn't much matter whether we (or anyone else for that matter) might think this is "good" or "right." > > I think that lack of specific IETF enforcement is a good thing, > > because it puts the focus right where it belongs -- on quality of > > implementation and interoperability rather than on abstract > > So being non conformant would make for higher quality (based on what outside > the IETF authority ?) or even better interoperability ? I don't see how. Just like I said -- you have to be smart about what you implement and why. It's not nearly enough merely to read the RFCs and translate them into semi-functional code. You must *understand* what those RFCs represent, what your customers will do with the product, and what other vendors in the same space are doing. RFCs are by no means a checklist. You won't find a list of "conditional requirements" as you might in some other documents. (In fact, there are some well-known implementations of particular protocols that are just literal translations of the RFCs, and suffer from substantial interoperability problems resulting from simple misunderstandings. I don't think it'd be right for me to name them here, but if you look around carefully, they're not too hard to find.) > Standard: > "4 : something set up and established by authority as a rule for the measure > of quantity, weight, extent, value, or quality" Note that it says "as a rule" -- not "as the only rule," or even "as the most important rule." > > "conformance" to some specification. Using "conformance" as a proxy > > for correct operation is a problem seen in other standards bodies, and > > it tends to result in forcing customers to buy all of their equipment > > from a sole vendor because of minor differences in interpretation. > > As opposed to non conformance which insures that every vendor interoperate > well. I can't parse that. The gold standard in Internet design is interoperability -- being able to communicate with equipment made by many different vendors. The goal of RFCs is to foster that sort of environment. The primary standard is still interoperability, which means that in the rare cases where the documentation says one thing, but everyone implementing that feature has always done another, it's the documentation that needs to change. In other words, you've got the cart in front of the horse. It's not the documents that are important -- it's the interoperability of multiple implementations that's important. > > Or, in other words, vendors are required to be smart, rather than > > being slaves to the standards process. > > Anyone can participate to the standards process so I don't see how anyone > could become a "slave" to it. > As for a single vendor thinking that he's smarter than the IETF, it sounds a > bit arrogant. Hardly. I see a smart developer who understands the rationale as being a peer of the people who wrote the document. Knowing and intentional violations of what the RFC says by someone who is well versed in the art are *not* a problem. They might well indicate places where the RFCs should be updated, but not everyone cares to do that. Having the working group participants at a particular point in time think they're collectively smarter than all designers of all types of equipment is, in my opinion, just as arrogant. They're not; they're peers. Unlike some purported standards processes, I think it's a good thing that RFCs are not considered to be golden references. Certainly, if you violate anything in an RFC (certainly a MUST, but even a SHOULD or a MAY), you need to understand what you're doing quite fully and understand the implications of it. > > As we well know, there are many possible violations that do not affect > > interoperability, or that actually make an implementation *more* > > I'd be curious to see a list of these violations. I'd even like these to > show up in some new rfcs or drafts or else what is the point of the IETF in > the first place ? To publish optional guidelines for vendors to disregard ? Those lists would be "Internet Drafts" and would eventually become replacement RFCs to correct the original ones. > > I don't recall if you're the one stuck behind that broken gateway, but if you're not, please turn HTML off. Talk about broken software ... :-/ -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Tue Jan 28 15:43:54 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06757 for ; Tue, 28 Jan 2003 15:43:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1DA9E9133B; Tue, 28 Jan 2003 15:44:12 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D2DBE9133C; Tue, 28 Jan 2003 15:44:11 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AC7939133B for ; Tue, 28 Jan 2003 15:44:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 90C895DF4E; Tue, 28 Jan 2003 15:44:07 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from watervalley.net (mail.watervalley.net [12.168.164.3]) by segue.merit.edu (Postfix) with SMTP id 33FB05DDBA for ; Tue, 28 Jan 2003 15:44:07 -0500 (EST) Received: from [204.39.227.79] (HELO greendragon.com) by watervalley.net (Stalker SMTP Server 1.8b8) with ESMTP id S.0044106730; Tue, 28 Jan 2003 14:43:23 -0600 Message-ID: <3E36EB8E.7533F5C1@greendragon.com> Date: Tue, 28 Jan 2003 15:45:10 -0500 From: William Allen Simpson Organization: DayDreamer X-Mailer: Mozilla 4.79 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "Ietf-Ppp (E-mail)" Subject: Re: PPP over Sonet default MRU References: <8812A03F65CDD511AE98006008F5E8714CE165@hermes.hyperchip.com> <15921.17206.960391.48107@gargle.gargle.HOWL> <3E35DB37.AF3256DD@greendragon.com> <15926.31342.74778.878089@gargle.gargle.HOWL> <3E36AC37.DBCB4B0C@greendragon.com> <15926.45715.151042.680937@gargle.gargle.HOWL> <3E36C567.50D3A82C@greendragon.com> <15926.54354.750836.442045@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit James Carlson wrote: > I think we're in violent agreement. > OK. > No; I think you might be misinterpreting the example. > Well, I'm remembering the discussion in the working group.... But this is way off topic for the PPP WG. > If you're a RIP-2 router configured to accept routing datagrams > *WITHOUT* authentication -- which is certainly one of the possible > acceptable configurations -- then it's rather senseless to drop > datagrams that happen to carry unwanted authentication information. In fact, we've long had problems with idiotic snooping of routing protocols, routing loops generated by idiotic misconfigurations, and on and on.... > What RFC 2453 says is this: > > 5.2 Authentication > > The following algorithm should be used to authenticate a RIP message. > If the router is not configured to authenticate RIP-2 messages, then > RIP-1 and unauthenticated RIP-2 messages will be accepted; > authenticated RIP-2 messages shall be discarded. [...] > > Obviously, if you're configured to authenticate at all, then you must > drop all messages with bad authentication data. If you're not > configured to authenticate, though, then you obviously don't care > about the security of the incoming message, and dropping it because > it's "more secure" than you expect is just senseless. Why prefer > unauthenticated data over authenticated data? Is unauthenticated > somehow "better?" > Authentication is an aspect of security, but this speaks to whether the router is properly configured to be a member of an authenticated confederation. > Worse still, it creates needless confusion. A RIP-1 router (or RIP-2 > router that doesn't include authentication extensions) There is no such thing. All conformant version 2 routers accept authentication: ... The Version field will specify version number 2 for RIP messages which use authentication or carry information in any of the newly defined fields. > (There's another good example in there that deals with the hop count > handling and that results in truncating the maximum network diameter > by one -- again, for no good reason, since it ends up being an > internal implementation detail whether you increment by one on input > or output. Violating this "requirement" is fairly common.) > Actually, it's not, and was a subject of much discussion. We had real operational problems to solve -- including rings of RS6000 boxes acting as a single router -- on deciding when and where to update the counts, and how to handle updates that come in with "infinity". The WG came to consensus. Hopefully, people fixed their implementations to reflect that consensus. If they didn't, then infinity might end up being smaller -- but in RIP that's not much of a problem, as RIP should never be used with a network diameter of more than 2 or 3. Really, the first implementation is not often the best. Remember D.P.'s first PPP implementation? If all we really needed was a copy of an implementation, and then told people, "make it work like that", then we wouldn't have bothered to spend all this time writing detailed specifications. Ah, well, the IETF ain't what she used to be.... -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 From owner-ietf-ppp@merit.edu Tue Jan 28 15:58:36 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07243 for ; Tue, 28 Jan 2003 15:58:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E661E9121C; Tue, 28 Jan 2003 16:01:47 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 84C3891339; Tue, 28 Jan 2003 16:01:47 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D1B479121C for ; Tue, 28 Jan 2003 16:01:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id B2E1E5DECF; Tue, 28 Jan 2003 16:01:26 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id E998E5DDFD for ; Tue, 28 Jan 2003 16:01:25 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.7.Beta0/8.12.7.Beta0) id h0SL1PFH027185 for ietf-ppp@merit.edu env-from ; Tue, 28 Jan 2003 14:01:25 -0700 (MST) Date: Tue, 28 Jan 2003 14:01:25 -0700 (MST) From: Vernon Schryver Message-Id: <200301282101.h0SL1PFH027185@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: PPP over Sonet default MRU References: <3E36EB8E.7533F5C1@greendragon.com> Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: William Allen Simpson > ... > > Worse still, it creates needless confusion. A RIP-1 router (or RIP-2 > > router that doesn't include authentication extensions) > > There is no such thing. All conformant version 2 routers accept > authentication: > ... The Version field will specify > version number 2 for RIP messages which use authentication or carry > information in any of the newly defined fields. Which conformant RIPv2 routers cannot be configured to not use authentication? There are or at least were RIPv2 implementations that did not have the faintest idea about RIPv2 authentication. I believe Cisco's first RIPv2 effort lacked RIPv2 authentication. Since RIPv2 was specified well before RIPv2 authentication and since the first version of RIPv2 authentication was a simplistic cleartext password, that was entirely understandable and reasonable. I've not checked the router requirements RFC, but I bet that if I did I would not find any words requiring that RIPv2 implementations include either flavor of RIPv2 authentication. > ... > being smaller -- but in RIP that's not much of a problem, as RIP should > never be used with a network diameter of more than 2 or 3. Few networks a diameter of 2 need more than static routing, usually of a default. There have been many RIPv1 internets with more than 1000 networks with diameters larger than 3. I don't think RIP is the best choice for more than a few gross of networks, but the old bit about a few dozen hosts being the limit for IP is stale old router salescritter and trade rag consultant e-spurt noise. > ... > If all we really needed was a copy of an implementation, and then told > people, "make it work like that", then we wouldn't have bothered to > spend all this time writing detailed specifications. > > Ah, well, the IETF ain't what she used to be.... The IETF has always suffered from people with pecuniary and other interests in getting their names on RFCs. (I don't mean to imply that RFC 1058 suffered from that syndrome. It was a useful document despite its shortcomings.) Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Tue Jan 28 16:21:07 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08130 for ; Tue, 28 Jan 2003 16:21:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 13DE491339; Tue, 28 Jan 2003 16:23:50 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C70DA9133C; Tue, 28 Jan 2003 16:23:49 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D361C91339 for ; Tue, 28 Jan 2003 16:23:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id C1E4A5DEC6; Tue, 28 Jan 2003 16:23:45 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id 44E625DE74 for ; Tue, 28 Jan 2003 16:23:45 -0500 (EST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00572; Tue, 28 Jan 2003 14:23:40 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0SLNe5f010941; Tue, 28 Jan 2003 16:23:40 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.7+Sun/8.12.7) with ESMTP id h0SLNeuH015015; Tue, 28 Jan 2003 16:23:40 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.7+Sun/8.12.7/Submit) id h0SLNeks015012; Tue, 28 Jan 2003 16:23:40 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15926.62683.881171.566933@gargle.gargle.HOWL> Date: Tue, 28 Jan 2003 16:23:39 -0500 From: James Carlson To: William Allen Simpson Cc: "Ietf-Ppp (E-mail)" Subject: Re: PPP over Sonet default MRU In-Reply-To: William Allen Simpson's message of 28 January 2003 15:45:10 References: <8812A03F65CDD511AE98006008F5E8714CE165@hermes.hyperchip.com> <15921.17206.960391.48107@gargle.gargle.HOWL> <3E35DB37.AF3256DD@greendragon.com> <15926.31342.74778.878089@gargle.gargle.HOWL> <3E36AC37.DBCB4B0C@greendragon.com> <15926.45715.151042.680937@gargle.gargle.HOWL> <3E36C567.50D3A82C@greendragon.com> <15926.54354.750836.442045@gargle.gargle.HOWL> <3E36EB8E.7533F5C1@greendragon.com> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit William Allen Simpson writes: > > No; I think you might be misinterpreting the example. > > > Well, I'm remembering the discussion in the working group.... > But this is way off topic for the PPP WG. It looks it. > Authentication is an aspect of security, but this speaks to whether > the router is properly configured to be a member of an authenticated > confederation. ... which, in turn, has something to do with whether the > > Worse still, it creates needless confusion. A RIP-1 router (or RIP-2 > > router that doesn't include authentication extensions) > > There is no such thing. All conformant version 2 routers accept > authentication: Not so. The protocol *allows* it, but nothing *requires* anyone to implement features they don't want to implement. If I had a RIP-2 implementation that didn't include authentication, it'd be equivalent to saying that the user interface knob to require authentication is permanently set to "no." For that matter, it's easy to envision cases in which configuration of authentication is simply impossible because the required key storage is lacking. > ... The Version field will specify > version number 2 for RIP messages which use authentication or carry > information in any of the newly defined fields. Note the "or" in the sentence above. In other words, you have to say "2" if you want to use any of the new RIP-2 features. It doesn't say that you *have* to implement either or both. > > (There's another good example in there that deals with the hop count > > handling and that results in truncating the maximum network diameter > > by one -- again, for no good reason, since it ends up being an > > internal implementation detail whether you increment by one on input > > or output. Violating this "requirement" is fairly common.) > > > Actually, it's not, and was a subject of much discussion. I maintain that if you cannot see the difference on the wire, then it's not a difference that matters to anyone looking at IETF documents. > We had real operational problems to solve -- including rings of RS6000 > boxes acting as a single router -- on deciding when and where to update > the counts, and how to handle updates that come in with "infinity". Agreed, but the RFC as written actually treats a route metric of 15 and 16 as being the same. 3.5 Protocol Specification [...] about each of these networks. The most important is its metric or "cost". The metric of a network is an integer between 1 and 15 [...] 3.9.2 Response Messages [...] Once the entry has been validated, update the metric by adding the cost of the network on which the message arrived. If the result is greater than infinity, use infinity. That is, metric = MIN (metric + cost, infinity) This handling means that when you receive a route with metric 15, you bump the metric by at least one before attempting to install it in your local table. You thus end up assuming that metric 15 routes advertised to you are all "unreachable," which is a fairly silly result. A more reasonable approach is to use a zero-based 'cost' for the link, so that metric 15 is installed in the local table and in the local forwarding entries, and then increment by 1 when you go to advertise to your peers, and do the check for infinity there. Since the sum ends up being the same either way, the routes that you pass along to your peers will be exactly the same either way, and your behavior in the protocol itself is thus the same, and interoperability is not affected. The only difference ends up being whether or not you install valid routes that you receive into your own IP forwarding table, which is a local matter. The RFC tells you not to, but my reading suggests otherwise. The fact that the RFC tells you to implement the +1 on the receive side rather than on the transmit side is, in my opinion, an implementation detail. In fact, if you confer with this section: 3.2 Limitations of the Protocol [...] - The protocol is limited to networks whose longest path (the network's diameter) is 15 hops. The designers believe that the basic protocol design is inappropriate for larger networks. Note that this statement of the limit assumes that a cost of 1 is used for each network. This is the way RIP is normally configured. If the system administrator chooses to use larger costs, the upper bound of 15 can easily become a problem. ... it becomes clear that this was perhaps just an oversight. The upper bound of the protocol as described by the RFC is actually 14 hops: link-->H1--m1-->H2--m2-->...--m13-->H14--m14-->RR The first hop (the advertising router with a connection to the actual network) must advertise a metric of no less than 1 (denoted "m1" above; metric 0 is not legal in RIP). If each hop adds the minimum link cost of 1, then you go through 14 hops before the route becomes unusable. (If that receiving router [RR] were to try to pass the route along to anyone, it'd have to pass along metric 15, and as shown above, that's effectively the same as infinity.) -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Tue Jan 28 16:36:36 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08654 for ; Tue, 28 Jan 2003 16:36:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6293291343; Tue, 28 Jan 2003 16:37:13 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A62A291345; Tue, 28 Jan 2003 16:37:12 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5EF8091343 for ; Tue, 28 Jan 2003 16:36:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 415795DE48; Tue, 28 Jan 2003 16:36:12 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id B310B5DD98 for ; Tue, 28 Jan 2003 16:36:11 -0500 (EST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08312; Tue, 28 Jan 2003 14:36:07 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0SLa75f014136; Tue, 28 Jan 2003 16:36:07 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.7+Sun/8.12.7) with ESMTP id h0SLa7uH015040; Tue, 28 Jan 2003 16:36:07 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.7+Sun/8.12.7/Submit) id h0SLa6bO015037; Tue, 28 Jan 2003 16:36:06 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15926.63430.827102.918686@gargle.gargle.HOWL> Date: Tue, 28 Jan 2003 16:36:06 -0500 From: James Carlson To: William Allen Simpson , "Ietf-Ppp (E-mail)" Subject: Re: PPP over Sonet default MRU In-Reply-To: James Carlson's message of 28 January 2003 16:23:39 References: <8812A03F65CDD511AE98006008F5E8714CE165@hermes.hyperchip.com> <15921.17206.960391.48107@gargle.gargle.HOWL> <3E35DB37.AF3256DD@greendragon.com> <15926.31342.74778.878089@gargle.gargle.HOWL> <3E36AC37.DBCB4B0C@greendragon.com> <15926.45715.151042.680937@gargle.gargle.HOWL> <3E36C567.50D3A82C@greendragon.com> <15926.54354.750836.442045@gargle.gargle.HOWL> <3E36EB8E.7533F5C1@greendragon.com> <15926.62683.881171.566933@gargle.gargle.HOWL> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit James Carlson writes: > > Authentication is an aspect of security, but this speaks to whether > > the router is properly configured to be a member of an authenticated > > confederation. > > ... which, in turn, has something to do with whether the whoops; truncated sentence there: ... which, in turn, has something to do with whether the router in question is able to *send* routes to those routers in the authenticated confederation. Obviously, if it doesn't have the credentials to do so, then it cannot. Note that I've already shown that a proper RFC 1058 compliant RIP-1 implementation *WILL* receive and process those authenticated RIP-2 messages, and will just ignore the unnecessary authentication bits. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Tue Jan 28 18:07:31 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10982 for ; Tue, 28 Jan 2003 18:07:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 49B8C91353; Tue, 28 Jan 2003 18:07:51 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 08CB091358; Tue, 28 Jan 2003 18:07:50 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A85E391353 for ; Tue, 28 Jan 2003 18:07:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 92D865DF58; Tue, 28 Jan 2003 18:07:45 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mail1.hyperchip.com (mail1.hyperchip.com [216.94.112.3]) by segue.merit.edu (Postfix) with ESMTP id E99FF5DD9E for ; Tue, 28 Jan 2003 18:07:44 -0500 (EST) Received: from hermes.hyperchip.com ([10.0.0.12] helo=hermes.hypernet.com) by mail1.hyperchip.com with esmtp (Exim 3.22 #1) id 18depS-0008I2-00; Tue, 28 Jan 2003 18:07:42 -0500 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Jan 2003 18:01:37 -0500 Message-ID: <8812A03F65CDD511AE98006008F5E8714CE179@hermes.hyperchip.com> From: Stephane St Hilaire To: "'James Carlson'" , Stephane St Hilaire Cc: "Ietf-Ppp (E-mail)" Subject: RE: PPP over Sonet default MRU Date: Tue, 28 Jan 2003 18:01:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C721.30325B90" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C721.30325B90 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: James Carlson [mailto:james.d.carlson@east.sun.com] > Sent: Tuesday, January 28, 2003 2:55 PM > To: Stephane St Hilaire > Cc: Ietf-Ppp (E-mail) > Subject: RE: PPP over Sonet default MRU > > > That's about how it works. Assuming you have to live in the real > world, where 800 pound gorillas are able to set wacky "standards" for > all others to follow, this is what you will be living with. > It doesn't much matter whether we (or anyone else for that matter) > might think this is "good" or "right." I'll have to look at your bank account before I decide whether or not you are right about this. > > > I think that lack of specific IETF enforcement is a good thing, My only contention is that you are saying this is a good thing and I don't agree. Having seen "The planet of the apes", I'd rather not let 800 pound gorillas set the standards. > > Just like I said -- you have to be smart about what you implement and > why. It's not nearly enough merely to read the RFCs and translate > them into semi-functional code. Why would it be semi-functional ? Do you equate RFC compliance with semi-functional code ? > > RFCs are by no means a checklist. You won't find a list of > "conditional requirements" as you might in some other documents. Hmm, MUST, SHOULD, MAY sounds like a checklist to me. > (In fact, there are some well-known implementations of particular > protocols that are just literal translations of the RFCs, and suffer > from substantial interoperability problems resulting from simple > misunderstandings. I don't think it'd be right for me to name them > here, but if you look around carefully, they're not too hard to find.) Come on, we want the names !!! > > "4 : something set up and established by authority as a > rule for the measure > > of quantity, weight, extent, value, or quality" > Note that it says "as a rule" -- not "as the only rule," or even "as > the most important rule." You're splitting hairs a little here. > > The gold standard in Internet design is interoperability -- being able > to communicate with equipment made by many different vendors. The > goal of RFCs is to foster that sort of environment. The primary > standard is still interoperability, which means that in the rare cases > where the documentation says one thing, but everyone implementing that > feature has always done another, it's the documentation that needs to > change. It's not about "everyone" or "many different vendors", you only need one BIG player to do whatever he wants, regardless of standards and then everyone else is "forced" to do the same. Is that a good thing ? > the documents that are important -- it's the interoperability of > multiple implementations that's important. No actually it's the interoperability with a few big guys/800 pound gorillas implementation that's important. > > > being slaves to the standards process. > > > > Anyone can participate to the standards process so I don't > see how anyone > > could become a "slave" to it. > > As for a single vendor thinking that he's smarter than the > IETF, it sounds a > > bit arrogant. > > Hardly. I see a smart developer who understands the rationale as > being a peer of the people who wrote the document. Knowing and I'm talking about not developers who just dismiss some RFC content for no good reason except perhaps laziness, plain forgot, or scheduling. > Unlike some purported standards processes, I think it's a good thing > that RFCs are not considered to be golden references. And why exactly ? Do the pros really outweigh the cons ? > Certainly, if > you violate anything in an RFC (certainly a MUST, but even a SHOULD or > a MAY), you need to understand what you're doing quite fully and > understand the implications of it. Of course it's easily understood. If you're a big vendor, you create problems and headaches for the other vendors who have to interoperate with you regardless of what you are doing. > > > > > > > I don't recall if you're the one stuck behind that broken gateway, but Yes. And as I have previously explained to you, as much as I keep sending in "plain ascii text" it still gets out with some HTML. Still I'm sure this can be filtered out at the input if it causes discomfort or confusion. Steph ------_=_NextPart_001_01C2C721.30325B90 Content-Type: text/html; charset="iso-8859-1" RE: PPP over Sonet default MRU

> -----Original Message-----
> From: James Carlson [mailto:james.d.carlson@east.sun.com]
> Sent: Tuesday, January 28, 2003 2:55 PM
> To: Stephane St Hilaire
> Cc: Ietf-Ppp (E-mail)
> Subject: RE: PPP over Sonet default MRU
>
>

> That's about how it works.  Assuming you have to live in the real
> world, where 800 pound gorillas are able to set wacky "standards" for
> all others to follow, this is what you will be living with.

> It doesn't much matter whether we (or anyone else for that matter)
> might think this is "good" or "right."

I'll have to look at your bank account before I decide whether or not you are right about this.

> > > I think that lack of specific IETF enforcement is a good thing,

My only contention is that you are saying this is a good thing and I don't agree.
Having seen "The planet of the apes", I'd rather not let 800 pound gorillas set the standards.


>
> Just like I said -- you have to be smart about what you implement and
> why.  It's not nearly enough merely to read the RFCs and translate
> them into semi-functional code. 

Why would it be semi-functional ? Do you equate RFC compliance with semi-functional code ?

>
> RFCs are by no means a checklist.  You won't find a list of
> "conditional requirements" as you might in some other documents.

Hmm, MUST, SHOULD, MAY sounds like a checklist to me.

> (In fact, there are some well-known implementations of particular
> protocols that are just literal translations of the RFCs, and suffer
> from substantial interoperability problems resulting from simple
> misunderstandings.  I don't think it'd be right for me to name them
> here, but if you look around carefully, they're not too hard to find.)

Come on, we want the names !!!


> > "4 : something set up and established by authority as a
> rule for the measure
> > of quantity, weight, extent, value, or quality"
 
> Note that it says "as a rule" -- not "as the only rule," or even "as
> the most important rule."

You're splitting hairs a little here.


>
> The gold standard in Internet design is interoperability -- being able
> to communicate with equipment made by many different vendors.  The
> goal of RFCs is to foster that sort of environment.  The primary
> standard is still interoperability, which means that in the rare cases
> where the documentation says one thing, but everyone implementing that
> feature has always done another, it's the documentation that needs to
> change.

It's not about "everyone" or "many different vendors", you only need one BIG player to do whatever he wants, regardless of standards and then everyone else is "forced" to do the same. Is that a good thing ?


> the documents that are important -- it's the interoperability of
> multiple implementations that's important.

No actually it's the interoperability with a few big guys/800 pound gorillas implementation that's important.


> > > being slaves to the standards process.
> >
> > Anyone can participate to the standards process so I don't
> see how anyone
> > could become a "slave" to it.
> > As for a single vendor thinking that he's smarter than the
> IETF, it sounds a
> > bit arrogant.
>
> Hardly.  I see a smart developer who understands the rationale as
> being a peer of the people who wrote the document.  Knowing and

I'm talking about not developers who just dismiss some RFC content for no good reason except perhaps laziness, plain forgot, or scheduling.



> Unlike some purported standards processes, I think it's a good thing
> that RFCs are not considered to be golden references.
And why exactly ? Do the pros really outweigh the cons ?


>  Certainly, if
> you violate anything in an RFC (certainly a MUST, but even a SHOULD or
> a MAY), you need to understand what you're doing quite fully and
> understand the implications of it.

Of course it's easily understood. If you're a big vendor, you create problems and headaches for the other vendors who have to interoperate with you regardless of what you are doing.


>
> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> > <HTML>
>
> I don't recall if you're the one stuck behind that broken gateway, but

Yes. And as I have previously explained to you, as much as I keep sending in "plain ascii text" it still gets out with some HTML. Still I'm sure this can be filtered out at the input if it causes discomfort or confusion.


Steph

------_=_NextPart_001_01C2C721.30325B90-- From owner-ietf-ppp@merit.edu Wed Jan 29 11:22:59 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22920 for ; Wed, 29 Jan 2003 11:22:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 802909136A; Wed, 29 Jan 2003 11:20:53 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AAC189136B; Wed, 29 Jan 2003 11:20:51 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 39E3F9136A for ; Wed, 29 Jan 2003 11:20:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 100255E0EA; Wed, 29 Jan 2003 11:20:48 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id B006A5E0E7 for ; Wed, 29 Jan 2003 11:20:47 -0500 (EST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06091; Wed, 29 Jan 2003 09:20:42 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h0TGKg5f019266; Wed, 29 Jan 2003 11:20:42 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.7+Sun/8.12.7) with ESMTP id h0TGKfuH016088; Wed, 29 Jan 2003 11:20:41 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.7+Sun/8.12.7/Submit) id h0TGKfZP016085; Wed, 29 Jan 2003 11:20:41 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15927.65369.254487.544415@gargle.gargle.HOWL> Date: Wed, 29 Jan 2003 11:20:41 -0500 From: James Carlson To: Stephane St Hilaire Cc: "Ietf-Ppp (E-mail)" Subject: RE: PPP over Sonet default MRU In-Reply-To: Stephane St Hilaire's message of 28 January 2003 18:01:27 References: <8812A03F65CDD511AE98006008F5E8714CE179@hermes.hyperchip.com> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Stephane St Hilaire writes: > > That's about how it works. Assuming you have to live in the real > > world, where 800 pound gorillas are able to set wacky "standards" for > > all others to follow, this is what you will be living with. > > > It doesn't much matter whether we (or anyone else for that matter) > > might think this is "good" or "right." > > I'll have to look at your bank account before I decide whether or not you > are right about this. I find that comment completely baffling. For what it's worth, and it's not much, my bank account is certainly *not* large. > > > > I think that lack of specific IETF enforcement is a good thing, > > My only contention is that you are saying this is a good thing and I don't > agree. > Having seen "The planet of the apes", I'd rather not let 800 pound gorillas > set the standards. I think you're greatly misunderstanding what I wrote. I said that it's a good thing that the IETF doesn't have an enforcement squad. I did *NOT* say that it's wonderful that monied interests sometimes make the decisions about what is done -- I simply said that it's unavoidable reality. One has to live with the fact that the world works this way. I do think things would be much *worse* if we elevated the documents above proven interoperability. > > Just like I said -- you have to be smart about what you implement and > > why. It's not nearly enough merely to read the RFCs and translate > > them into semi-functional code. > > Why would it be semi-functional ? Do you equate RFC compliance with > semi-functional code ? Once again, you've misunderstood what I wrote. Blind adherence to RFCs generally, in my experience, produces garbage -- the whole point of this process is to produce interoperable implementations. If you don't bother trying to make your implementation work with any other implementation, then you're completely missing the point. You're confusing the map and the terrain. I don't equate RFC compliance with semi-functional code. I do equate the notion of sitting down with a written specification in English, writing some code, and then shipping it without bothering to see if any of it works right when run against all available, current implementations of that specification, or checking to see if the way in which it operates actually fills the needs of those who'd be using it to be "semi-functional." You've done only a tiny fraction of the job. In other words, you can't do any of this while walling yourself off from the world. > > RFCs are by no means a checklist. You won't find a list of > > "conditional requirements" as you might in some other documents. > > Hmm, MUST, SHOULD, MAY sounds like a checklist to me. You need to read documents from other standards organizations. > > Note that it says "as a rule" -- not "as the only rule," or even "as > > the most important rule." > > You're splitting hairs a little here. Nope. I'm pointing out that the "standards" take you only so far. > It's not about "everyone" or "many different vendors", you only need one BIG > player to do whatever he wants, regardless of standards and then everyone > else is "forced" to do the same. Is that a good thing ? No, it's not a good thing, but it is the way life tends to work. In *some* cases, there is such a big player, and he'll generally make the mistakes that others have to follow. In *other* cases, there isn't such a player. And there are some vendors who are more cooperative and collaborative than others. The best case, I think, is that those with prototype implementations get together at a bake-off and settle the issues before the market ever sees them. This doesn't always happen, though, nor does it always catch every important error. > > the documents that are important -- it's the interoperability of > > multiple implementations that's important. > > No actually it's the interoperability with a few big guys/800 pound gorillas > implementation that's important. Get over it. Either you're interested in using equipment from multiple vendors that all works together, or you're not. Pick one. > > Hardly. I see a smart developer who understands the rationale as > > being a peer of the people who wrote the document. Knowing and > > I'm talking about not developers who just dismiss some RFC content for no > good reason except perhaps laziness, plain forgot, or scheduling. Agreed; those are either merely clumsy (and will correct their errors in due time) or idiots (and won't). There's no way any standards organization can turn a bad developer into a good one. Legislating intelligence or good engineering practice almost never works. > > Unlike some purported standards processes, I think it's a good thing > > that RFCs are not considered to be golden references. > And why exactly ? Do the pros really outweigh the cons ? Yes. Try working with documents based on those other standards- setting processes some time. It's an eye-opener. > > Certainly, if > > you violate anything in an RFC (certainly a MUST, but even a SHOULD or > > a MAY), you need to understand what you're doing quite fully and > > understand the implications of it. > > Of course it's easily understood. If you're a big vendor, you create > problems and headaches for the other vendors who have to interoperate with > you regardless of what you are doing. Wrong answer. If someone creates interoperability problems by intentionally violating some part of an RFC, then that person either (a) didn't fully understand what he was doing, and thus isn't in compliance with what I wrote above, or (b) is a miscreant. (Obviously, I'm talking here about intentional violation, not mere bugs or accidents.) Yes, there are certainly examples of both in the world, but I don't see that there's anything sensible that the IETF can do about either case. I still think you're missing the whole point of the IETF. We're here to try to create interoperable solutions. That's the shared goal. Those who are willfully engaged in producing non-interoperable junk are just not playing the game. They're vandals. Other than perhaps public humiliation, we don't really have any enforcement powers to make people "comply" with the IETF. More to the point: if someone wanted to take a selection of RFCs, and produce a "walled garden" in which the protocols were almost TCP/IP but just slightly different and incompatible, there's nothing we can or will do about it. (In fact there are at least two of those going on at the moment that I know about. If you're interested, look for groups trying to set "Internet standards" via bodies other than the IETF.) For what it's worth, I'm much more worried about folks who might add language to the documents that guarantee misunderstandings, who push proprietary nonsense through the standards process in an attempt to "bless" their market position, or who push non-answers to non- problems. Those cases cause far more trouble than the relatively minor issue of bug-for-bug compatibility. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Thu Jan 30 01:39:19 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10445 for ; Thu, 30 Jan 2003 01:39:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6AAA191201; Thu, 30 Jan 2003 01:42:36 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 388CC91211; Thu, 30 Jan 2003 01:42:36 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F1BFB91201 for ; Thu, 30 Jan 2003 01:42:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id CD2925E1D4; Thu, 30 Jan 2003 01:42:34 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 37B6F5DF93 for ; Thu, 30 Jan 2003 01:42:34 -0500 (EST) Received: from juniper.net (wawa.juniper.net [172.17.20.55]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h0U6fgS94757; Wed, 29 Jan 2003 22:41:43 -0800 (PST) (envelope-from dennis@juniper.net) Message-Id: <200301300641.h0U6fgS94757@merlot.juniper.net> X-Mailer: exmh version 2.0.2 2/24/98 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: inbox To: ssthilaire@hyperchip.com (Stephane St Hilaire) Cc: "Ietf-Ppp (E-mail)" Subject: Re: PPP over Sonet default MRU In-reply-to: Your message of "22 Jan 1903 21:20:37 GMT." <8812A03F65CDD511AE98006008F5E8714CE15B@hermes.hyperchip.com> Mime-Version: 1.0 Content-Type: text/plain Date: Wed, 29 Jan 2003 22:41:42 -0800 From: Dennis Ferguson Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Stephane, > While doing POS interoperability testing with Juniper and Cisco routers we > found the following behavior; Even though Juniper POS interfaces have a > default MTU of 4470, no MRU information is sent during LCP negotiations. > Even so Cisco routers that use the same default MTU, but DO send their MRU, > still send packets of up to 4470 out. My question are the following: > > 1) Is 4470 the actual default MRU to be used for POS (and not 1500 as > documented in rfc 1661) ? 4470 is the default MTU for POS when using what appears to still be the most commonly configured link encapsulations on this type of circuit (i.e. not PPP). For PPP over SONET, however, I can see no reading of RFC 2615 or 1661 which would lead one to any conclude the answer is any number other than 1500. > 2) If so, is this documented somewhere ? In the not-PPP cases, not in an IETF document. > 3) If 1500 is in fact the default MRU, isn't there something "wrong" for > lack of a better term with Juniper's behavior in not sending it's MRU and > Cisco's in sending frames of more than 1500 bytes regardless. There's something wrong with the Juniper router behaviour, certainly in the sense of not being "conservative in what you do". What I think the author of the code was trying to do was to express no opinion at all on the MRU, since the earliest router hardware could receive as big a packet as it was possible to send so whatever was configured as the MTU on the other end of the link was fine, but I think he misread the fact that there is no way to do this with PPP as specified. This will be fixed shortly. As for Cisco, however, it isn't so clear to me that what they do is in fact "wrong", despite the fact that it seems to violate RFC 1661. Since I once, long ago, went through this issue and came up with a similar answer I am going to guess that this could instead be an example of how old protocol documents sometimes never die. In RFC 1171 the text concerning the length of the Information Field said The default maximum length of the Information field is 1500 octets. By prior agreement, consenting PPP implementations may use other values for the maximum Information field length. I know this was often interpreted as meaning that if you chose the option of not implementing the MRU option at all then you were free to use the method everyone used prior to that, i.e. using configured MTUs on each end of the link. As it was rare that a pre-PPP user interface would even mention MRU, it is not surprising that this would be interpreted in a way which both made the option truly optional (i.e. you could have any MTU you wanted even if you didn't do the option) and allowed the easiest backward-compatibility. RFC 1331 removed any ambiguity by making it clearer that the option wasn't really optional unless you were happy keeping all MRUs at 1500 bytes, which is normally not what you want on "big" circuits. The problem was that this fix wasn't backward-compatible with RFC 1171 implementations (likely including your own, if you had one), in that if you did an implementation which insisted on RFC 1331 behaviour then installing it on a box talking to (your own implementation of?) RFC 1171 will cause you to drop your MTU on the circuit to 1500 with absolutely no way to change it short of replacing the software on the box at the other end (and then replacing the software of his neighbors, and so on). This was a deployment nightmare. I think what I decided to do instead to relieve the deployment issue while getting as close to the behaviour of the new standard as possible, in an MTU-configuration-centric implementation, was to: - Always send an MRU option, even if the value being sent was 1500 bytes, omitting it only to deal with a -Reject (the configured MTU was the first choice for the MRU, the hardware maximum was sent to respond to a -Nak). Always sending the option ensured that the new implementation would at least never end up confused talking to itself, or anyone else which always sends the option. - Take no received MRU option to mean, use the configured MTU. Otherwise, if he sent an MRU, use the configured MTU for the active MTU if the received MRU was greater than or equal to this, the received MRU otherwise. This appears to be approximately Cisco's behaviour too, for whatever reason. While I don't know their reason, if it is the same reason then I'd point out that this is behaviour which, once you've done it, is hard to ever undo, partly because you can't really tell when all the boxes you needed to interoperate with like this are gone, and partly because it allows a new generation of boxes which inadvertently depend on the behaviour to come to exist. And given that I now know boxes which have a bug which depends on this I suspect I have a good idea of how that bug will be fixed. I'd also just point out that the view expressed here that PPP should always negotiate MRUs (which is also the only way I can interpret RFC 1661 if the end result is supposed to be other than 1500), and that bad things will necessarily happen if PPP is ever allowed to let the link come up with an inconsistent MTU/MRU, is a bit PPP-myopic since there is at least one common situation where the PPP checks are actually redundant to checks made after the circuit is open. If the circuit is between two routers and OSPF (or IS-IS, I'm pretty sure) is in use, the IGP will also check that the MTUs in use are compatible and will fail to form an adjacency if they aren't, which prevents the circuit from ever being put to use even if PPP is up. In this case it may have been preferable to be able to have PPP not bother with MRU negotiation itself, if this were an option, since the problem will be caught regardless and it may be more convenient to have the circuit up when you need to fix it so you can use it to log into the neighbour box and repair its faulty configuration. We do have a pile of experience with link encapsulations which do not verify MTUs themselves which still seem to work out just fine in this application. And to share one other suprising thing I just noticed, while Juniper has built quite a large number of HDLC over SONET interfaces, and while I am aware of a big variety of equipment it has been connected to via these interfaces, there has never been a user-initiated bug report concerning this behaviour (it has be noticed internally a bunch of times, though not fixed for hysterical reasons), even though it should be failing to interoperate with implementations strictly conforming to RFC 1661 in an unfortunate way. I have no idea whether this means the Cisco implementation of MRU negotiation is common, or whether it means the use of PPP on interfaces of this type is fairly uncommon, however. Dennis Ferguson From owner-ietf-ppp@merit.edu Thu Jan 30 10:49:35 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02120 for ; Thu, 30 Jan 2003 10:49:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 03B4E912BF; Thu, 30 Jan 2003 10:49:50 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C2FD191279; Thu, 30 Jan 2003 10:49:47 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5C990912BA for ; Thu, 30 Jan 2003 10:49:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 457735DDE4; Thu, 30 Jan 2003 10:49:41 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from watervalley.net (mail.watervalley.net [12.168.164.3]) by segue.merit.edu (Postfix) with SMTP id A1BC05DDC4 for ; Thu, 30 Jan 2003 10:49:40 -0500 (EST) Received: from [204.39.230.159] (HELO greendragon.com) by watervalley.net (Stalker SMTP Server 1.8b8) with ESMTP id S.0044301253 for ; Thu, 30 Jan 2003 09:49:34 -0600 Message-ID: <3E3949AC.F31F7E5F@greendragon.com> Date: Thu, 30 Jan 2003 10:50:37 -0500 From: William Allen Simpson Organization: DayDreamer X-Mailer: Mozilla 4.79 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "Ietf-Ppp (E-mail)" Subject: Re: PPP over Sonet default MRU References: <200301300641.h0U6fgS94757@merlot.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit I'd thought this thread mercifully died off.... My comment is after the text: James Carlson wrote: >... > I do think things would be much *worse* if we elevated the documents > above proven interoperability. >... > Blind adherence to RFCs generally, in my experience, produces garbage > -- the whole point of this process is to produce interoperable > implementations. If you don't bother trying to make your > implementation work with any other implementation, then you're > completely missing the point. You're confusing the map and the > terrain. >... > In other words, you can't do any of this while walling yourself off > from the world. >... > In *some* cases, there is such a big player, and he'll generally make > the mistakes that others have to follow. In *other* cases, there > isn't such a player. And there are some vendors who are more > cooperative and collaborative than others. > > The best case, I think, is that those with prototype implementations > get together at a bake-off and settle the issues before the market > ever sees them. This doesn't always happen, though, nor does it > always catch every important error. >... > I still think you're missing the whole point of the IETF. We're here > to try to create interoperable solutions. That's the shared goal. > Those who are willfully engaged in producing non-interoperable junk > are just not playing the game. They're vandals. Other than perhaps > public humiliation, we don't really have any enforcement powers to > make people "comply" with the IETF. > Dennis Ferguson wrote: >... > As for Cisco, however, it isn't so clear to me that what they do is > in fact "wrong", despite the fact that it seems to violate RFC 1661. > Since I once, long ago, went through this issue and came up with a similar > answer I am going to guess that this could instead be an example of how old > protocol documents sometimes never die. In RFC 1171 the text concerning > the length of the Information Field said > > The default maximum length of the > Information field is 1500 octets. By prior agreement, consenting > PPP implementations may use other values for the maximum > Information field length. > > I know this was often interpreted as meaning that if you chose the option > of not implementing the MRU option at all then you were free to use the > method everyone used prior to that, i.e. using configured MTUs on > each end of the link. As it was rare that a pre-PPP user interface > would even mention MRU, it is not surprising that this would be > interpreted in a way which both made the option truly optional > (i.e. you could have any MTU you wanted even if you didn't do the > option) and allowed the easiest backward-compatibility. > > RFC 1331 removed any ambiguity by making it clearer that the option wasn't > really optional unless you were happy keeping all MRUs at 1500 bytes, As a historical note, RFC-1171 was tested for interoperability at InterOp 1990, and none (that's right, absolutely zero) of the vendors were able to interoperate using async, and only 2 with sync. This lead to the clarifications (and re-design) of RFC-1331, which had fairly widespread interoperability at InterOp 1991, such as: The default maximum length of the Information field is 1500 octets. By negotiation, consenting PPP implementations may use other values for the maximum Information field length. Eventually (when it was discovered that folks didn't understand whether to count Protocol and Padding, either) culminating in RFC-1661: The maximum length for the Information field, including Padding, but not including the Protocol field, is termed the Maximum Receive Unit (MRU), which defaults to 1500 octets. By negotiation, consenting PPP implementations may use other values for the MRU. As to the problem of failing to test against other vendors, in those days Cisco was the prime example. They had the biggest market share, and just expected everybody to follow them.... Indeed, this lead to "open" wars, such as the Open SPF. To this day, Cisco still ships boxen defaulting to their proprietary HDLC variant, instead of PPP. As noted by Carlson, sometimes we had to make allowances for the big guys. We ended up tweaking the PPP FSA, because otherwise nobody could talk to Cisco. Cisco had a terrible design flaw, where packets queued before a link went down, and then were sent out when the link came up. Every other vendor could flush their buffers. So, we figured out how to toss all the Cisco bogons and successfully interoperate. Later, there was an even more amazing example of failing to test an implementation. Shiva came out with a relatively inexpensive box that did well in the market. But, after selling thousands of units, they discovered that they'd miscalculated the FCS. They could only talk to themselves. This really clarified the need for interoperability testing at every step by everybody -- while drafting the RFC, and with quality assurance before sales, purchasing, and deployment. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 From owner-ietf-ppp@merit.edu Thu Jan 30 11:22:18 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02930 for ; Thu, 30 Jan 2003 11:22:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 53380912E6; Thu, 30 Jan 2003 11:23:20 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1467B912ED; Thu, 30 Jan 2003 11:23:19 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6CB3F912E6 for ; Thu, 30 Jan 2003 11:23:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 48E995DDBC; Thu, 30 Jan 2003 11:23:13 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mail1.hyperchip.com (mail1.hyperchip.com [216.94.112.3]) by segue.merit.edu (Postfix) with ESMTP id 6FAD35DDA3 for ; Thu, 30 Jan 2003 11:23:12 -0500 (EST) Received: from hermes.hyperchip.com ([10.0.0.12] helo=hermes.hypernet.com) by mail1.hyperchip.com with esmtp (Exim 3.22 #1) id 18eHT4-0006gi-00; Thu, 30 Jan 2003 11:23:10 -0500 Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Jan 2003 11:17:00 -0500 Message-ID: <8812A03F65CDD511AE98006008F5E8714CE184@hermes.hyperchip.com> From: Stephane St Hilaire To: "'Dennis Ferguson'" , Stephane St Hilaire Cc: "Ietf-Ppp (E-mail)" Subject: RE: PPP over Sonet default MRU Date: Thu, 30 Jan 2003 11:16:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C87B.0461B500" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C87B.0461B500 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Dennis Ferguson [mailto:dennis@juniper.net] > Sent: Thursday, January 30, 2003 1:42 AM > To: ssthilaire@hyperchip.com > Cc: Ietf-Ppp (E-mail) > Subject: Re: PPP over Sonet default MRU > > > Stephane, > > on the other end of the link was fine, but I think he misread the fact > that there is no way to do this with PPP as specified. This will be > fixed shortly. Now that's great news ! I'll have to work on being less cynical in the future. Could I get a target release version/date ? I might be pushing my luck a little ... > will cause you > to drop your MTU on the circuit to 1500 with absolutely no > way to change > it short of replacing the software on the box at the other > end (and then > replacing the software of his neighbors, and so on). This > was a deployment > nightmare. My idea was to have our local MTU adjust to the remote MRU (only if the latter was lower) all the time when our local MTU had NOT been MANUALLY configured (it's using the old 4470 default). However if our local MTU was manually configured, in the case where the remote MRU was not provided during LCP, we would have continued using our MTU even if above 1500. If we DID get the remote MRU and it was lower than our configured MTU we would not connect. The idea being that if the operator actually configured his MTU, he *really* wants it and to adjust it to something less then he wants is not necessarily desirable. If he wants this configuration to work he will have to do some configuration work on the peer. I guess there are many ways to solve this issue. > > I think what I decided to do instead to relieve the deployment issue > while getting as close to the behavior of the new standard > as possible, > in an MTU-configuration-centric implementation, was to: > > - Always send an MRU option, even if the value being sent was 1500 > bytes, omitting it only to deal with a -Reject (the configured MTU > was the first choice for the MRU, the hardware maximum was sent to > respond to a -Nak). Always sending the option ensured that the > new implementation would at least never end up confused talking to > itself, or anyone else which always sends the option. > > - Take no received MRU option to mean, use the configured MTU. > Otherwise, if he sent an MRU, use the configured MTU for the active > MTU if the received MRU was greater than or equal to this, the > received MRU otherwise. > In this do you see "configured MTU" has something different from the "default interface MTU" ? > This appears to be approximately Cisco's behavior too, for whatever > reason. While I don't know their reason, if it is the same With Cisco we've even tried connecting using a MRU smaller than 4470 (2048 just to see what would happen). Basically we got a bunch of NACKs telling us to raise our MRU to 4470 (raising our MRU is seen as more feasible then lowering theirs...) until we finally receive a reject. We might assume that this means they will now use the default of 1500 but we were still able to send 4K pings from the Cisco to our box. Considering that the Cisco's MTU wasn't *configured*, this appears a bit inflexible. We even have a router tester that when negociating his MRU at 4K will NACK our MRU of ~9K. So we can receive packets larger then he'll ever send, what's the problem ? > > I'd also just point out that the view expressed here that PPP > should always > negotiate MRUs (which is also the only way I can interpret RFC 1661 > if the end result is supposed to be other than 1500), and > that bad things > will necessarily happen if PPP is ever allowed to let the link come up > with an inconsistent MTU/MRU, is a bit PPP-myopic since there In some cases this won't cause a problem. If the MRUs on both sides is greater than the MTU on both sides (which in fact is generally the case), even if the MRUs are inconsistent OSPF can come up and so fourth. Perhaps if there were an actual IP MTU negotiation option in IPCP all ambiguities would go away. OSPF wouldn't even have to do MTU checks when running on a point to point link. Just a silly/half baked idea, please no flames ! > that the MTUs in use are compatible and will fail to form an adjacency > if they aren't, which prevents the circuit from ever being put to use > even if PPP is up. In this case it may have been preferable > to be able > to have PPP not bother with MRU negotiation itself, if this were an > option, since the problem will be caught regardless and it may be more > convenient to have the circuit up when you need to fix it so > you can use > it to log into the neighbour box and repair its faulty > configuration. We In general I myself would agree but we are seeing a lot of operators who don't want to provide access to their router management via data/forwarding links as opposed to network management specific interfaces. However that's another story. > > And to share one other surprising thing I just noticed, while Juniper > has built quite a large number of HDLC over SONET interfaces, > and while > I am aware of a big variety of equipment it has been connected to via > these interfaces, there has never been a user-initiated bug report Perhaps the bugs were sent to the "smaller" vendors (where the user will feel, perhaps wrongly in this case, that he has more leverage), and they adapted their side of the equation. > concerning this behavior (it has be noticed internally a > bunch of times, > though not fixed for hysterical reasons), even though it I thought we had a monopoly on those types of reasons (or did you mean hystorical ?): ) > should be failing > to interoperate with implementations strictly conforming to > RFC 1661 in > an unfortunate way. I have no idea whether this means the Cisco > implementation of MRU negotiation is common, or whether it means the > use of PPP on interfaces of this type is fairly uncommon, however. I'd combine both and come up with: PPP on sonet may not be all that uncommon but Cisco and Juniper perhaps *own* most of it ? I'm not really sure. Thanks a lot ! Steph ------_=_NextPart_001_01C2C87B.0461B500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: PPP over Sonet default MRU

> -----Original Message-----
> From: Dennis Ferguson [mailto:dennis@juniper.net]=
> Sent: Thursday, January 30, 2003 1:42 AM
> To: ssthilaire@hyperchip.com
> Cc: Ietf-Ppp (E-mail)
> Subject: Re: PPP over Sonet default MRU
>
>
> Stephane,
>
> on the other end of the link was fine, but I = think he misread the fact
> that there is no way to do this with PPP as = specified.  This will be
> fixed shortly.

Now that's great news ! I'll have to work on being = less cynical in the future.
Could I get a target release version/date ? I might = be pushing my luck a little ...

> will cause you
> to drop your MTU on the circuit to 1500 with = absolutely no
> way to change
> it short of replacing the software on the box = at the other
> end (and then
> replacing the software of his neighbors, and so = on).  This
> was a deployment
> nightmare.

My idea was to have our local MTU adjust to the = remote MRU (only if the latter was lower) all the time when our local = MTU had NOT been MANUALLY configured (it's using the old 4470 default). = However if our local MTU was manually configured, in the case where the = remote MRU was not provided during LCP, we would have continued using = our MTU even if above 1500. If we DID get the remote MRU and it was = lower than our configured MTU we would not connect. The idea being that = if the operator actually configured his MTU, he *really* wants it and = to adjust it to something less then he wants is not necessarily = desirable. If he wants this configuration to work he will have to do = some configuration work on the peer. I guess there are many ways to = solve this issue.


>
> I think what I decided to do instead to relieve = the deployment issue
> while getting as close to the behavior of the = new standard
> as possible,
> in an MTU-configuration-centric implementation, = was to:
>
> - Always send an MRU option, even if the value = being sent was 1500
>   bytes, omitting it only to deal = with a -Reject (the configured MTU
>   was the first choice for the MRU, = the hardware maximum was sent to
>   respond to a -Nak).  Always = sending the option ensured that the
>   new implementation would at least = never end up confused talking to
>   itself, or anyone else which always = sends the option.
>
> - Take no received MRU option to mean, use the = configured MTU.
>   Otherwise, if he sent an MRU, use = the configured MTU for the active
>   MTU if the received MRU was greater = than or equal to this, the
>   received MRU otherwise.
>

In this do you see "configured MTU" has = something different from the "default interface MTU" ? =


> This appears to be approximately Cisco's = behavior too, for whatever
> reason.  While I don't know their reason, = if it is the same

With Cisco we've even tried connecting using a MRU = smaller than 4470 (2048 just to see what would happen). Basically we = got a bunch of NACKs telling us to raise our MRU to 4470 (raising our = MRU is seen as more feasible then lowering theirs...) until we finally = receive a reject. We might assume that this means they will now use the = default of 1500 but we were still able to send 4K pings from the Cisco = to our box. Considering that the Cisco's MTU wasn't *configured*, this = appears a bit inflexible.

We even have a router tester that when negociating = his MRU at 4K will NACK our MRU of ~9K. So we can receive packets = larger then he'll ever send, what's the problem ?

>
> I'd also just point out that the view expressed = here that PPP
> should always
> negotiate MRUs (which is also the only way I = can interpret RFC 1661
> if the end result is supposed to be other than = 1500), and
> that bad things
> will necessarily happen if PPP is ever allowed = to let the link come up
> with an inconsistent MTU/MRU, is a bit = PPP-myopic since there

In some cases this won't cause a problem. If the MRUs = on both sides is greater than the MTU on both sides (which in fact is = generally the case), even if the MRUs are inconsistent OSPF can come up = and so fourth. Perhaps if there were an actual IP MTU negotiation = option in IPCP all ambiguities would go away. OSPF wouldn't even have = to do MTU checks when running on a point to point link. Just a = silly/half baked idea, please no flames !


> that the MTUs in use are compatible and will = fail to form an adjacency
> if they aren't, which prevents the circuit from = ever being put to use
> even if PPP is up.  In this case it may = have been preferable
> to be able
> to have PPP not bother with MRU negotiation = itself, if this were an
> option, since the problem will be caught = regardless and it may be more
> convenient to have the circuit up when you need = to fix it so
> you can use
> it to log into the neighbour box and repair its = faulty
> configuration.  We

In general I myself would agree but we are seeing a = lot of operators who don't want to provide access to their router = management via data/forwarding links as opposed to network management = specific interfaces. However that's another story.


>
> And to share one other surprising thing I just = noticed, while Juniper
> has built quite a large number of HDLC over = SONET interfaces,
> and while
> I am aware of a big variety of equipment it has = been connected to via
> these interfaces, there has never been a = user-initiated bug report

Perhaps the bugs were sent to the "smaller" = vendors (where the user will feel, perhaps wrongly in this case, that = he has more leverage), and they adapted their side of the = equation.


> concerning this behavior (it has be noticed = internally a
> bunch of times,
> though not fixed for hysterical reasons), even = though it

I thought we had a monopoly on those types of reasons = (or did you mean hystorical ?): )

> should be failing
> to interoperate with implementations strictly = conforming to
> RFC 1661 in
> an unfortunate way.  I have no idea = whether this means the Cisco
> implementation of MRU negotiation is common, or = whether it means the
> use of PPP on interfaces of this type is fairly = uncommon, however.

I'd combine both and come up with: PPP on sonet may = not be all that uncommon but Cisco and Juniper perhaps *own* most of it = ?

I'm not really sure.

Thanks a lot !


Steph

------_=_NextPart_001_01C2C87B.0461B500--