From owner-ietf-ppp-outgoing@merit.edu Wed Feb 2 14:38:55 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19293 for ; Wed, 2 Feb 2000 14:38:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id B9E3B5DDDB; Wed, 2 Feb 2000 14:33:37 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7DE8F5DDD8; Wed, 2 Feb 2000 14:33:37 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id 1BF925DDEE for ; Wed, 2 Feb 2000 14:33:30 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id MAA06336 env-from ; Wed, 2 Feb 2000 12:33:28 -0700 (MST) Date: Wed, 2 Feb 2000 12:33:28 -0700 (MST) From: Vernon Schryver Message-Id: <200002021933.MAA06336@calcite.rhyolite.com> To: ietf-ppp@merit.edu, rfc-ed@ISI.EDU Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: RFC Editor > ... > RFC 2759 > Title: Microsoft PPP CHAP Extensions, Version 2 > ... > This document is a product of the Point-to-Point Protocol Extensions > Working Group of the IETF. > ... Has that changed since the last zillion times we've gone around that that merry goround? Isn't MSCHAP still *NOT* a product of the working group? Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Thu Feb 3 06:40:30 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13297 for ; Thu, 3 Feb 2000 06:40:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 12BC55DDCC; Thu, 3 Feb 2000 06:40:04 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F0A6C5DDDA; Thu, 3 Feb 2000 06:40:03 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 4D4CA5DDCC for ; Thu, 3 Feb 2000 06:40:02 -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 GAA13282; Thu, 3 Feb 2000 06:40:01 -0500 (EST) Message-Id: <200002031140.GAA13282@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-bcp-03.txt Date: Thu, 03 Feb 2000 06:40:01 -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 : PPP Bridging Control Protocol (BCP) Author(s) : M. Higashiyama, F. Baker Filename : draft-ietf-pppext-bcp-03.txt Pages : 38 Date : 02-Feb-00 The Point-to-Point Protocol (PPP) [6] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols. This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. This document obsoletes RFC 1638, which was based on the IEEE 802.1D-1993 MAC Bridge[3]. This document extends that specification by including the IEEE 802.1D-1998 MAC Bridge[8] and IEEE 802.1Q Virtual LAN (VLAN)[9] standards. This document also improves the protocol in order to support high-speed switched LANs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-bcp-03.txt 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-bcp-03.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-bcp-03.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: <20000202122602.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-bcp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-bcp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000202122602.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp-outgoing@merit.edu Thu Feb 3 11:51:55 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22571 for ; Thu, 3 Feb 2000 11:51:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 649205DDFD; Thu, 3 Feb 2000 11:51:17 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 51D7B5DDFB; Thu, 3 Feb 2000 11:51:17 -0500 (EST) Received: from cujo.merit.edu (cujo.merit.edu [198.108.60.97]) by segue.merit.edu (Postfix) with ESMTP id 4DF035DDF6 for ; Thu, 3 Feb 2000 11:51:16 -0500 (EST) Received: (from bobsills@localhost) by cujo.merit.edu (8.9.3/8.9.1) id LAA09942 for ietf-ppp@merit.edu; Thu, 3 Feb 2000 11:51:16 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id BE3EE5DDF6 for ; Thu, 3 Feb 2000 11:41:41 -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 LAA22256; Thu, 3 Feb 2000 11:41:36 -0500 (EST) Message-Id: <200002031641.LAA22256@ietf.org> To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: The IESG SUBJECT: Last Call: PPP Bridging Control Protocol (BCP) to Proposed Standard Reply-To: iesg@ietf.org Date: Thu, 03 Feb 2000 11:41:36 -0500 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu The IESG has received a request from the Point-to-Point Protocol Extensions Working Group to consider PPP Bridging Control Protocol (BCP) as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by February 17, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pppext-bcp-03.txt From owner-ietf-ppp-outgoing@merit.edu Fri Feb 11 14:40:55 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18091 for ; Fri, 11 Feb 2000 14:40:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0BEDE5DF57; Fri, 11 Feb 2000 14:38:17 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 07E3F5DF68; Fri, 11 Feb 2000 14:36:49 -0500 (EST) Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by segue.merit.edu (Postfix) with ESMTP id B70535E0E1 for ; Fri, 11 Feb 2000 14:33:13 -0500 (EST) Received: from rhino (rhino.cisco.com [172.20.9.57]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id LAA23073; Fri, 11 Feb 2000 11:54:02 -0800 (PST) Received: from p7020-img-nt (fred-hm-dhcp1.cisco.com [171.69.128.116]) by rhino (SMI-8.6/CISCO.WS.1.1) with SMTP id LAA26509; Fri, 11 Feb 2000 11:38:09 -0800 Message-Id: <4.1.20000211111151.023f7010@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 11 Feb 2000 11:16:48 -0800 To: Mitsuru.Higashiyama@yy.anritsu.co.jp From: Fred Baker Subject: Re: PPP BCP proposed IETF standard Cc: "Ewart Tempest" , Thomas Narten , Erik Nordmark , ietf-ppp@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_48225764==_.ALT" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --=====================_48225764==_.ALT Content-Type: text/plain; charset="us-ascii" Mitsuru-san: This seems like a reasonable comment. We can take this as an IETF Last Call comment, unless there is concern from the Area Director. Fred At 01:37 PM 2/11/00 +0000, Ewart Tempest wrote: > > Hi Fred, > > I know that draft 0.3 of the PPP BCP has been put forward as a proposed IETF > standard. As one of the authors, I wondered whether the following > clarifications could be made to the texts: > > 1) In section 4.1.4: > "(a) If the bridge wants to terminate the connection, it sends a > Terminate-Request and terminates the connection. > (b) If the bridge wants to run the connection but not receive old BPDUs, its > only option is to run without the spanning tree on the link at all, which is > dangerous. It should Configure-Reject the option and advise > the network administration that it has done so." Ewart, are you asking us in this to specify the option? It should configure-reject the older Spanning Tree Bridge PDU option. > > 2) In the first paragraph of Appendix A, I assume that the sections 4.2 and > 4.3 being referred to are those of RFC 1638: > > "By default, Spanning Tree BPDUs MUST be carried with MAC or 802.2 LLC > header described in section 4.2 or 4.3 encoded as per section 4.2 or 4.3 of > RFC 1638. This format MUST be used when it connect connecting to old BCP > implementations to keep ensure backwards compatibility." > > Please confirm. Specifically, if an IETF draft compliant bridge entity > receives a Configure-Reject for the Management Inline option, the remote > bridge entity must be RFC 1638 compliant. If the IETF draft compliant bridge > entity does not implement/understand the RFC 1638 BPDU format, it must > negotate use of the NULL protocol wrt the Spanning-Tree-Protocol negotiation, > if any traffic is to be bridged over the link. > > Thanks. > > Ewart > > -------------------------------------------------------------------------- > ------------------------------------ > > Ewart Tempest > Nortel Networks, > Doagh Road, > Newtownabbey, County Antrim, > Northern Ireland, BT36 6XA > > Tel. (44)1232-363747 ESN 751-3747 > Fax. (44)1232-362626 ESN 751-2626 --=====================_48225764==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Mitsuru-san:

This seems like a reasonable comment. We can take this as an IETF Last Call comment, unless there is concern from the Area Director.

Fred

At 01:37 PM 2/11/00 +0000, Ewart Tempest wrote:

Hi Fred,

I know that draft 0.3 of the PPP BCP has been put forward as a proposed IETF standard. As one of the authors, I wondered whether the following clarifications could be made to the texts:

1) In section 4.1.4:
"(a) If the bridge wants to terminate the connection, it sends a Terminate-Request and terminates the connection.
(b) If the bridge wants to run the connection but not receive old BPDUs, its only option is to run without the spanning tree on the link at all, which is dangerous. It should Configure-Reject the <specify option> option and advise the network administration that it has done so."

Ewart, are you asking us in this to specify the option? It should configure-reject the older Spanning Tree Bridge PDU option.

2) In the first paragraph of Appendix A, I assume that the sections 4.2 and 4.3 being referred to are those of RFC 1638:

        "By default, Spanning Tree BPDUs MUST be carried with MAC or 802.2 LLC header described in section 4.2 or 4.3  encoded as per section 4.2 or 4.3 of RFC 1638. This format MUST be used when it connect connecting to old BCP implementations to keep ensure backwards compatibility."

Please confirm. Specifically, if an IETF draft compliant bridge entity receives a Configure-Reject for the Management Inline option, the remote bridge entity must be RFC 1638 compliant. If the IETF draft compliant bridge entity does not implement/understand the RFC 1638 BPDU format, it must negotate use of the NULL protocol wrt the Spanning-Tree-Protocol negotiation, if any traffic is to be bridged over the link.

Thanks.

Ewart

--------------------------------------------------------------------------------------------------------------

Ewart Tempest
Nortel Networks,
Doagh Road,
Newtownabbey, County Antrim,
Northern Ireland, BT36 6XA

Tel. (44)1232-363747    ESN 751-3747
Fax. (44)1232-362626    ESN 751-2626

--=====================_48225764==_.ALT-- From owner-ietf-ppp-outgoing@merit.edu Mon Feb 14 12:20:29 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18119 for ; Mon, 14 Feb 2000 12:20:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 687CF5DDC4; Mon, 14 Feb 2000 12:18:34 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 50F1C5DDC3; Mon, 14 Feb 2000 12:18:34 -0500 (EST) Received: from ns.anritsu.co.jp (ns.anritsu.co.jp [133.236.48.2]) by segue.merit.edu (Postfix) with ESMTP id EC7FC5DDBC for ; Mon, 14 Feb 2000 12:18:00 -0500 (EST) Received: from gatekeeper.noc.anritsu.co.jp (root@gatekeeper.noc.anritsu.co.jp [133.236.19.3]) by ns.anritsu.co.jp (8.9.3+3.1W/3.7W/19991218.23/C) with ESMTP id CAA28643 for ; Tue, 15 Feb 2000 02:17:32 +0900 (JST) (envelope-from Mitsuru.Higashiyama@yy.anritsu.co.jp) Received: (from root@localhost) by gatekeeper.noc.anritsu.co.jp (8.8.8+2.7Wbeta7/CF-3.5Wpl7/19991218.23/N) id CAA15424; Tue, 15 Feb 2000 02:17:29 +0900 (JST) Received: from mail0.cr.anritsu.co.jp (mail0.cr.anritsu.co.jp [172.16.32.22]) by gatekeeper.noc.anritsu.co.jp (8.8.8+2.7Wbeta7/CF-3.5Wpl7/19991218.23/C) with ESMTP id CAA15415 for ; Tue, 15 Feb 2000 02:17:28 +0900 (JST) Received: from yy.anritsu.co.jp ([172.16.97.52]) by mail0.cr.anritsu.co.jp (Netscape Messaging Server 3.54) with ESMTP id AAA3D4B; Tue, 15 Feb 2000 02:20:05 +0900 Message-ID: <38A83877.EF36A78@yy.anritsu.co.jp> Date: Tue, 15 Feb 2000 02:16:39 +0900 From: Mitsuru Higashiyama Reply-To: Mitsuru.Higashiyama@yy.anritsu.co.jp Organization: Anritsu Corp. X-Mailer: Mozilla 4.5 [ja] (Win98; I) X-Accept-Language: ja MIME-Version: 1.0 To: Fred Baker Cc: Ewart Tempest , Thomas Narten , Erik Nordmark , ietf-ppp@merit.edu Subject: Re: PPP BCP proposed IETF standard References: <4.1.20000211111151.023f7010@flipper.cisco.com> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hello, Fred Baker wrote: > > Mitsuru-san: > > This seems like a reasonable comment. We can take this as an IETF Last > Call comment, unless there is concern from the Area Director. I see. > Fred > > At 01:37 PM 2/11/00 +0000, Ewart Tempest wrote: > > > Hi Fred, > > > > I know that draft 0.3 of the PPP BCP has been put forward as a > > proposed IETF standard. As one of the authors, I wondered whether > > the following clarifications could be made to the texts: > > > > 1) In section 4.1.4: > > "(a) If the bridge wants to terminate the connection, it sends a > > Terminate-Request and terminates the connection. > > (b) If the bridge wants to run the connection but not receive old > > BPDUs, its only option is to run without the spanning tree on the > > link at all, which is dangerous. It should Configure-Reject the > > option and advise the network administration that > > it has done so." > > Ewart, are you asking us in this to specify the option? It should > configure-reject the older Spanning Tree Bridge PDU option. Ewart, thanks your english corrections. I would like to wait your answer to Fred's question, too. > > 2) In the first paragraph of Appendix A, I assume that the sections > > 4.2 and 4.3 being referred to are those of RFC 1638: No, it reffers to sections 4.2 and 4.3 in this I-D. The sections 4.2 and 4.3 defines new BCP frame formats. The first paragraph of Appendix A mean that: By default, Spanning Tree BPDUs MUST be carried with MAC or 802.2 LLC header described in section 4.2 or 4.3 of this I-D. If you wants to connect to old BCP implementations, you will use Spanning Tree Frame format of old BCP described in Appendix A. > > > > "By default, Spanning Tree BPDUs MUST be carried with MAC or > > 802.2 LLC header described in section 4.2 or 4.3 encoded as per > > section 4.2 or 4.3 of RFC 1638. This format MUST be used when it > > connect connecting to old BCP implementations to keep ensure > > backwards compatibility." > > > > Please confirm. Specifically, if an IETF draft compliant bridge > > entity receives a Configure-Reject for the Management Inline option, > > the remote bridge entity must be RFC 1638 compliant. If the IETF > > draft compliant bridge entity does not implement/understand the RFC > > 1638 BPDU format, it must negotate use of the NULL protocol wrt the > > Spanning-Tree-Protocol negotiation, if any traffic is to be bridged > > over the link. We have already define this manner in 4.1.4. It said: (b) If the bridge wants to run the connection but not receive old BPDUs, its only option is to run without spanning tree on the link at all, which is dangerous. It should Configure-Reject the option and advise the network administration that it has done so. We have two options, first is sending Configure-Reject described in BCP-03, second is sending NULL Spanning-Tree-Protocol option. Is there any advantage on using NULL Spanning-Tree-Protocol option ? Best regards, Mitsuru -- Mitsuru Higashiyama ANRITSU CORPORATION Systems Development Department, Information & Network Division Telephone Office +81 462 96 6625 Fax +81 462 25 8387 From owner-ietf-ppp-outgoing@merit.edu Tue Feb 15 04:24:23 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21294 for ; Tue, 15 Feb 2000 04:24:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id A4D335DDD7; Tue, 15 Feb 2000 04:23:57 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 91BB85DDDB; Tue, 15 Feb 2000 04:23:57 -0500 (EST) Received: from gwa2.fe.bosch.de (gwa2.fe.bosch.de [195.71.148.2]) by segue.merit.edu (Postfix) with ESMTP id 853545DDD7 for ; Tue, 15 Feb 2000 04:23:55 -0500 (EST) Received: (from uucp@localhost) by gwa2.fe.bosch.de (8.9.1/8.9.1) id KAA28655 for ; Tue, 15 Feb 2000 10:24:13 +0100 (MET) Received: from fez7540.fe.bosch.de( 10.8.2.28) by gwa2.fe.bosch.de via smap (V2.1) id xma027456; Tue, 15 Feb 00 10:23:22 +0100 Received: by fez7202.server.bosch.de with Internet Mail Service (5.5.2651.58) id <1981KM5S>; Tue, 15 Feb 2000 10:22:54 +0100 Message-ID: <7DE0D5F41A2FD311AB6B08002BB6B39F9E600C@bkmail2.bk.bosch.de> From: "Buerkle Joachim (UC-ON/EMY2) *" To: "'ietf-ppp@merit.edu'" Subject: Compression Algorithms supported by CCP Date: Tue, 15 Feb 2000 10:22:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi, I have several questions about the different kind of Compression Algorithms which are supported by CCP: - Is there a comparison of these compression algorithms available? - Which one is the most common one? MPPC? - In July Vernon wrote: >>The only special thing I can see about low speed PPP is compression (both >>modem v.42bis and PPP CCP), which effectively makes the raw bandwidth of >>a link appear to vary from about 90% to more than 400% of the nominal bit >>rate. has somebody more details about these figures? - In July there was discussion about "Guessing the link speed." on this list. What was the result? Thank You Best Regards Joachim - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From owner-ietf-ppp-outgoing@merit.edu Tue Jul 20 14:17:17 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1F06A44412; Tue, 20 Jul 1999 14:17:17 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id 75F4444403 for ; Tue, 20 Jul 1999 14:16:10 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id MAA29167 env-from ; Tue, 20 Jul 1999 12:16:05 -0600 (MDT) Date: Tue, 20 Jul 1999 12:16:05 -0600 (MDT) From: Vernon Schryver Message-Id: <199907201816.MAA29167@calcite.rhyolite.com> To: ietf-ppp@merit.edu, jmartz@us.ibm.com Subject: Re: Guessing the link speed. Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: "John R. Martz" > To: > Over the next few weeks we have to start wrestling with addressing how much "usage" a PPP line is > getting relative to it's "capacity". My first thought is that I'm not sure I really know what these > terms mean. Or how to algorithmically take a guess at what these values are for an active link. > > Can anyone point me towards code or text that discusses these topics in the context of managing a > PPP link? Would like to get some idea what others have done rather than reinvent the proverbial > wheel. (Or worse, implement a square wheel :) In particular, I was wondering how the transmission > speed of a link is usually determined. How do the capacity and usage of a low speed point to point link differ from the capacity and usage of a higher speed link? I don't see how whether you run PPP, SLIP, or one of the old proprietary protocols makes an interesting difference. Aren't questions of raw capacity vs. usable bandwidth very old and still very active topics elsewhere, including in the differential services, RSVP, End-to-End, and TCP implementors working groups? The only special thing I can see about low speed PPP is compression (both modem v.42bis and PPP CCP), which effectively makes the raw bandwidth of a link appear to vary from about 90% to more than 400% of the nominal bit rate. (Isn't 64K ISDN now always available, and 56K used only for DOV?) Why do you care? Wouldn't the most useful operational answer be short, long, and medium term bit rates compared to either 30 kbit/sec (lumping all modems) or 64 kbps (any ISDN B channel)? If the need is to fill a meaningless slot in a MIB used only by people who don't understand the inevitable inaccuraces of any single answer (e.g. comopression), why not just report the nominal bit rate? Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Tue Feb 15 09:22:21 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03240 for ; Tue, 15 Feb 2000 09:22:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5F8C75DDEB; Tue, 15 Feb 2000 09:14:52 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4E4F15DDEA; Tue, 15 Feb 2000 09:14:52 -0500 (EST) Received: from ironbridgenetworks.com (ibn-host12.ironbridgenetworks.com [146.115.140.12]) by segue.merit.edu (Postfix) with ESMTP id 307C15DDE6 for ; Tue, 15 Feb 2000 09:14:48 -0500 (EST) Received: (from news@localhost) by ironbridgenetworks.com (8.9.3/8.9.3) id JAA29032 for ietf-ppp@merit.edu; Tue, 15 Feb 2000 09:14:44 -0500 (EST) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: Compression Algorithms supported by CCP Date: 15 Feb 2000 09:14:44 -0500 Organization: IronBridge Networks Lines: 72 Message-ID: <86ya8m5z8r.fsf@ironbridgenetworks.com> References: <7DE0D5F41A2FD311AB6B08002BB6B39F9E600C@bkmail2.bk.bosch.de> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Joachim.Buerkle@marconicomms.com ("Buerkle Joachim (UC-ON/EMY2) *") writes: > - Is there a comparison of these compression algorithms available? On what basis? Number of implementations? Market penetration? IPR restrictions? Availability? CPU cycles? Compression ratios (best, average, or worst-case)? Prevalence of bugs in common implementations? There are a large number of ways to compare these things. In a test I ran some time ago on Predictor, STAC, BSD Compress, and Deflate, I got the highest compression ratios out of Deflate; about 1.5 times that of STAC. It took about 5 times the CPU effort to compress with Deflate, but was almost identical to STAC on decompression. > - Which one is the most common one? MPPC? More likely, it's STAC. Win9x supports both STAC and MPPC, and most ISDN-based systems support either only STAC or a combination of STAC and several other algorithms. WinNT supports only MPPC, but there are far fewer of those systems around. For what it's worth, MPPC is a derivative of STAC. > - In July Vernon wrote: > > >>The only special thing I can see about low speed PPP is compression (both > >>modem v.42bis and PPP CCP), which effectively makes the raw bandwidth of > >>a link appear to vary from about 90% to more than 400% of the nominal bit > >>rate. > > has somebody more details about these figures? Not really. It depends *STRONGLY* on the data you have. In particular, GIF and JPEG images (which are already compressed) do not compress well at all. Some algorithms (notably BSD Compress and Deflate) have zero-overhead mechanisms to avoid compressing incompressible data. Others do not. Note that a significant amount of data passing over the link to a web-surfing PC user is graphical and therefore incompressible. > - In July there was discussion about "Guessing the link speed." on this > list. > What was the result? The list archives are at: ftp://ftp.merit.edu/mail.archives/ietf-ppp-archive/ The quick summary is that John Martz (IBM) posted a question about finding the link speed for use in throughput comparisons. Archie Cobbs followed up to say that for ISDN you know the speed (it's either 64K or 56K per B channel) and that modems can report the DCE speed on connection and that, if all else fails, you can measure it directly. Karl Fox noted that modems are difficult -- actual throughput varies over time. There were several other follow-ups that digressed into how you measure instantaneous speed, whether the link layer protocol matters, and whether any of this is even useful information at all. You'll probably want to fetch a copy of ietf-ppplog.1999.07 and read it for yourself. The general answer is that your mileage will certainly vary ... -- James Carlson, System Architect IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Wed Feb 16 14:39:53 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11166 for ; Wed, 16 Feb 2000 14:39:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 742895DD93; Wed, 16 Feb 2000 14:38:58 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5A44C5DD9B; Wed, 16 Feb 2000 14:38:58 -0500 (EST) Received: from ns.anritsu.co.jp (ns.anritsu.co.jp [133.236.48.2]) by segue.merit.edu (Postfix) with ESMTP id 05B225DD93 for ; Wed, 16 Feb 2000 14:38:51 -0500 (EST) Received: from gatekeeper.noc.anritsu.co.jp (root@gatekeeper.noc.anritsu.co.jp [133.236.19.3]) by ns.anritsu.co.jp (8.9.3+3.1W/3.7W/19991218.23/C) with ESMTP id EAA03253 for ; Thu, 17 Feb 2000 04:38:44 +0900 (JST) (envelope-from Mitsuru.Higashiyama@yy.anritsu.co.jp) Received: (from root@localhost) by gatekeeper.noc.anritsu.co.jp (8.8.8+2.7Wbeta7/CF-3.5Wpl7/19991218.23/N) id EAA22939; Thu, 17 Feb 2000 04:38:41 +0900 (JST) Received: from mail0.cr.anritsu.co.jp (mail0.cr.anritsu.co.jp [172.16.32.22]) by gatekeeper.noc.anritsu.co.jp (8.8.8+2.7Wbeta7/CF-3.5Wpl7/19991218.23/C) with ESMTP id EAA22931 for ; Thu, 17 Feb 2000 04:38:40 +0900 (JST) Received: from yy.anritsu.co.jp ([172.16.97.52]) by mail0.cr.anritsu.co.jp (Netscape Messaging Server 3.54) with ESMTP id AAA4FB9; Thu, 17 Feb 2000 04:41:17 +0900 Message-ID: <38AAFC9A.4A0273B9@yy.anritsu.co.jp> Date: Thu, 17 Feb 2000 04:38:02 +0900 From: Mitsuru Higashiyama Reply-To: Mitsuru.Higashiyama@yy.anritsu.co.jp Organization: Anritsu Corp. X-Mailer: Mozilla 4.5 [ja] (Win98; I) X-Accept-Language: ja MIME-Version: 1.0 To: Ewart Tempest Cc: Fred Baker , Thomas Narten , Erik Nordmark , ietf-ppp@merit.edu Subject: Re: PPP BCP proposed IETF standard References: Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hello Ewart, Thank you for your comments and suggestions. > Ewart Tempest wrote: > > Mitsuru, > > I have included my comments below, and many thanks for the useful > feedback. > > I asked Fred whether or not he was aware of any reference > implementations of the I-D, or of any product groups that were > implementing the I-D, since I have an interest in modifying our > 3rd-party supplied PPP implementation to implement the I-D and > doing some interop. Do you know of any development groups/e-mail > contacts working on I-D implementations? I am implementing it now. But my PPP implementation only support SONET interface. What kind of line do you want to use in interop ? > > Thanks. > > Ewart > > -----Original Message----- > From: Mitsuru Higashiyama > [SMTP:Mitsuru.Higashiyama@yy.anritsu.co.jp] > Sent: Monday, February 14, 2000 5:17 PM > To: Fred Baker > Cc: Tempest, Ewart [IRE07:GC72:EXCH]; Thomas Narten; > Erik Nordmark; ietf-ppp@merit.edu > Subject: Re: PPP BCP proposed IETF standard > > Hello, > > Fred Baker wrote: > > > > Mitsuru-san: > > > > This seems like a reasonable comment. We can take this as > an IETF Last > > Call comment, unless there is concern from the Area > Director. > > I see. > > > Fred > > > > At 01:37 PM 2/11/00 +0000, Ewart Tempest wrote: > > > > > Hi Fred, > > > > > > I know that draft 0.3 of the PPP BCP has been put > forward as a > > > proposed IETF standard. As one of the authors, I > wondered whether > > > the following clarifications could be made to the texts: > > > > > > > 1) In section 4.1.4: > > > "(a) If the bridge wants to terminate the connection, it > sends a > > > Terminate-Request and terminates the connection. > > > (b) If the bridge wants to run the connection but not > receive old > > > BPDUs, its only option is to run without the spanning > tree on the > > > link at all, which is dangerous. It should > Configure-Reject the > > > option and advise the network > administration that > > > it has done so." > > > > Ewart, are you asking us in this to specify the option? It > should > > configure-reject the older Spanning Tree Bridge PDU > option. > > Ewart, thanks your english corrections. > I would like to wait your answer to Fred's question, too. > [Tempest, Ewart [IRE07:GF62-M:EXCH]] > I was asking for the option to be explicitly specified in > the texts, yes. O.K. I understand what was you asking. As your other comment for NULL Spanning-Tree-Protocol option and Configure-Reject issue, I would like to change the paragraph in 4.1.4 as bellow: (b) If the bridge wants to run the connection but not receive old BPDUs, its only option is to run without spanning tree on the link at all, which is dangerous. It should send NULL Spanning Tree-Protocol option and advise the network administration that it has done so. > > > > 2) In the first paragraph of Appendix A, I assume that > the sections > > > 4.2 and 4.3 being referred to are those of RFC 1638: > > No, it reffers to sections 4.2 and 4.3 in this I-D. The > sections 4.2 > and 4.3 defines new BCP frame formats. The first paragraph > of Appendix A > mean that: > By default, Spanning Tree BPDUs MUST be carried with MAC > or 802.2 LLC > header described in section 4.2 or 4.3 of this I-D. If you > wants to > connect to old BCP implementations, you will use Spanning > Tree Frame > format of old BCP described in Appendix A. > [Tempest, Ewart [IRE07:GF62-M:EXCH]] > OK. The first paragraph in Appendix A needs clarification: > > "By default, Spanning Tree BPDU MUST be carried with MAC or > 802.2 LLC header described in section 4.2 or 4.3. This > format MUST be used when it connect to old BCP > implementation to keep backward compatibility." > > In order to achieve backwards compatibility (with RFC 1638 > compliant bridges), you have to encode BPDUs as per sections > 4.2 and 4.3 of RFC 1638, not the I-D, although I appreciate > that one would have to use the Spanning-Tree-Protocol option > to negotiate to this position. In the description for the > Management-Inline option, it clearly states that this (the > Management-Inline) option would typically be the first > option to be negotiated so that one could determine what > kind of compliant entity was at the other end of the link. > Only once you know this would one be in a reasonable > position to decide whether, and if so how, to negotiate > use/non-use of the STP over the link. > > A suggested rewording for the above paragraph would be: > > "By default, Spanning Tree BPDUs MUST be encoded with a MAC > or 802.2 LLC header as described in section 4.2 or 4.3 of > this document. However, should the remote entity > Configure-Reject the Management-Inline option, thereby > indicating that it is a purely RFC 1638 compliant device, > the local entity may subsequently encode BPDUs as described > in section 4.3 of RFC 1638 provided that use of a suitable > non-NULL STP protocol across the link is successfully > negotiated using the (old) Spanning-Tree-Protocol option." Thanks, I will add this explanation. > > Within the I-D, the need to negotiate the type of STP used > over the link seems to have been negated (the > Spanning-Tree-Protocol and Management-Inline options are > incompatible). It would be useful to add some texts to the > I-D which specify why this was done. Was this because, with > the option to enable VLAN tagging across the link, one could > have multiple STP instances of the same and/or different > type operating over the link at the same time? Yes, as my opinion, BCP bridge should connect LAN to LAN transpearently. Bridge can decide which kind of STP should be send/recv by himself. Because he have already done so on LAN interfaces. On the LAN interfaces, he never negotiate with other bridges which kind of STP will he use. This rule will be applied for Link Aggregation and GARP. All management protocols will work well on the layer of their protocol entities without line level negotiations. > > > > > > "By default, Spanning Tree BPDUs MUST be carried > with MAC or > > > 802.2 LLC header described in section 4.2 or 4.3 > encoded as per > > > section 4.2 or 4.3 of RFC 1638. This format MUST be used > when it > > > connect connecting to old BCP implementations to keep > ensure > > > backwards compatibility." > > > > > > Please confirm. Specifically, if an IETF draft compliant > bridge > > > entity receives a Configure-Reject for the Management > Inline option, > > > the remote bridge entity must be RFC 1638 compliant. If > the IETF > > > draft compliant bridge entity does not > implement/understand the RFC > > > 1638 BPDU format, it must negotate use of the NULL > protocol wrt the > > > Spanning-Tree-Protocol negotiation, if any traffic is to > be bridged > > > over the link. > > We have already define this manner in 4.1.4. It said: > (b) If the bridge wants to run the connection but not > receive old > BPDUs, its only option is to run without spanning > tree on the > link at all, which is dangerous. It should > Configure-Reject > the option and advise the network administration > that it has > done so. > > We have two options, first is sending Configure-Reject > described in > BCP-03, second is sending NULL Spanning-Tree-Protocol > option. > Is there any advantage on using NULL Spanning-Tree-Protocol > option ? > [Tempest, Ewart [IRE07:GF62-M:EXCH]] > So rejecting an option should really be reserved for meaning > "I do not understand the option, period", as is the case for > the new Management-Inline option, for example, when trying > to communicate with pure RFC 1638 bridges. Given that both > the IETF draft and RFC 1638 both mandate support for the > Spanning-Tree-Protocol option, use of Configure-Reject for > this option, should, strictly speaking, be an illegal thing > to do. Are you aware of any RFC 1638 implementations today > which will ever Configure-Reject this option? > > Best regards, > Mitsuru > -- > Mitsuru Higashiyama > ANRITSU CORPORATION > Systems Development Department, Information & Network > Division > Telephone Office +81 462 96 6625 Fax +81 462 25 8387 -- Mitsuru Higashiyama ANRITSU CORPORATION Systems Development Department, Information & Network Division Telephone Office +81 462 96 6625 Fax +81 462 25 8387 From owner-ietf-ppp-outgoing@merit.edu Mon Feb 21 05:34:11 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02259 for ; Mon, 21 Feb 2000 05:34:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 29E255DE2D; Mon, 21 Feb 2000 05:18:34 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BD40B5DE5C; Mon, 21 Feb 2000 05:18:20 -0500 (EST) Received: from ums5.nifty.ne.jp (ums5.nifty.ne.jp [192.47.24.155]) by segue.merit.edu (Postfix) with ESMTP id 408885DE5E for ; Mon, 21 Feb 2000 05:08:13 -0500 (EST) Received: (from root@localhost) by ums5.nifty.ne.jp (8.9.3+3.2W/3.7W990929) id TAA23734; Mon, 21 Feb 2000 19:08:12 +0900 (JST) Message-Id: <200002211008.TAA23734@ums5.nifty.ne.jp> Date: Mon, 21 Feb 2000 19:07:59 +0900 From: =?ISO-2022-JP?B?GyRCNVdKXUVEISE/PxsoQg==?= Subject: about ip header compression on pos To: ietf-ppp@merit.edu MIME-Version: 1.0 Content-type: text/plain; charset="iso-2022-jp" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hello. I have a doubt about IP header Compression on POS. Now, there seems to be some Protocol IDs used for IPv4, - 0x0021:IPv4 - 0x002d:Van Jacobson Compressed TCP/IP - 0x002f:Van Jacobson Uncompressed TCP/IP … and my doubt is about the type used for POS normally? I think that is '0x0021'. The reason is that the target of POS is high-speed network, so it will have less priority to use compression techniques and it will have more priority to simplify the system. right? I will appliciate anyone's help. Thanks in advance. From owner-ietf-ppp-outgoing@merit.edu Mon Feb 21 11:28:48 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10826 for ; Mon, 21 Feb 2000 11:28:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 45FFA5DE09; Mon, 21 Feb 2000 11:28:18 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3501B5DE02; Mon, 21 Feb 2000 11:28:18 -0500 (EST) Received: from ironbridgenetworks.com (ibn-host12.ironbridgenetworks.com [146.115.140.12]) by segue.merit.edu (Postfix) with ESMTP id 55E615DDFF for ; Mon, 21 Feb 2000 11:28:16 -0500 (EST) Received: (from news@localhost) by ironbridgenetworks.com (8.9.3/8.9.3) id LAA10460 for ietf-ppp@merit.edu; Mon, 21 Feb 2000 11:28:15 -0500 (EST) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: about ip header compression on pos Date: 21 Feb 2000 11:28:15 -0500 Organization: IronBridge Networks Lines: 23 Message-ID: <86d7pqa5b4.fsf@ironbridgenetworks.com> References: <200002211008.TAA23734@ums5.nifty.ne.jp> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu KXD01513@nifty.ne.jp (=?ISO-2022-JP?B?GyRCNVdKXUVEISE/PxsoQg==?=) writes: > and my doubt is about the type used for POS normally? I know of no implementations of VJ header compression for SONET/SDH links. This would seem to me to be a pointless excercise. > I think that is '0x0021'. > The reason is that the target of POS is high-speed network, > so it will have less priority to use compression techniques > and it will have more priority to simplify the system. > right? No. The problem is that VJ compression works well only when there are a very small number of TCP flows over the link and the packets are relatively small (as with interactive TELNET/rlogin traffic). Given that most POS links have hundreds or thousands of flows and little interactive data, VJ compression does no good. -- James Carlson, System Architect IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Mon Feb 21 21:18:44 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20324 for ; Mon, 21 Feb 2000 21:18:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 15F905DE32; Mon, 21 Feb 2000 21:16:20 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 04EEA5DE30; Mon, 21 Feb 2000 21:16:20 -0500 (EST) Received: from ums5.nifty.ne.jp (ums5.nifty.ne.jp [192.47.24.155]) by segue.merit.edu (Postfix) with ESMTP id 8F6915DE2E for ; Mon, 21 Feb 2000 21:16:17 -0500 (EST) Received: (from root@localhost) by ums5.nifty.ne.jp (8.9.3+3.2W/3.7W990929) id LAA11588; Tue, 22 Feb 2000 11:16:16 +0900 (JST) Date: Tue, 22 Feb 2000 11:16:08 +0900 From: "M. Kubota" Message-ID: <20000222111608.398405e9.30105@nifty.ne.jp> To: ietf-ppp@merit.edu Subject: Re: about ip header compression on pos MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: INTERWAY Version 2.60 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu "James Carlson" wrote: > > I think that is '0x0021'. > > The reason is that the target of POS is high-speed network, > > so it will have less priority to use compression techniques > > and it will have more priority to simplify the system. > > right? > > No. The problem is that VJ compression works well only when there are > a very small number of TCP flows over the link and the packets are > relatively small (as with interactive TELNET/rlogin traffic). Given > that most POS links have hundreds or thousands of flows and little > interactive data, VJ compression does no good. I understand. Thanks James. From owner-ietf-ppp-outgoing@merit.edu Tue Feb 22 17:51:54 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26469 for ; Tue, 22 Feb 2000 17:51:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 426F85DE4B; Tue, 22 Feb 2000 17:49:28 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 267ED5DE64; Tue, 22 Feb 2000 17:49:28 -0500 (EST) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by segue.merit.edu (Postfix) with ESMTP id 750A95DE4B for ; Tue, 22 Feb 2000 17:49:21 -0500 (EST) Received: from rhino (rhino.cisco.com [172.20.9.57]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id OAA19007; Tue, 22 Feb 2000 14:38:26 -0800 (PST) Received: from p7020-img-nt (fred-hm-dhcp1.cisco.com [171.69.128.116]) by rhino (SMI-8.6/CISCO.WS.1.1) with SMTP id OAA28081; Tue, 22 Feb 2000 14:53:53 -0800 Message-Id: <4.1.20000222143904.01eb8c30@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 22 Feb 2000 14:40:28 -0800 To: "Ewart Tempest" From: Fred Baker Subject: Re: Clarification request for proposed IETF draft "PPP BCP Issue 0.3 (February 2000)" Cc: "'ietf-ppp@merit.edu'" , Mitsuru Higashiyama In-Reply-To: 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 At 05:02 PM 2/22/00 +0000, Ewart Tempest wrote: > > I request a qualification be added to the IETF draft in that there are no > explicit texts in the document that specify whether Ethernet encapsulated > frames sent over POS links, and encoded as per sections > 4.2(untagged)/4.3(tagged), must be padded out to the minimum frame length > required for 802.3. I should think that if the message contains an e2e FCS, it would have to be able to be transmitted on any wire unaltered. If it doesn't contain one, it would not be so constrained. Can you explain why that would not be true? From owner-ietf-ppp-outgoing@merit.edu Wed Feb 23 11:52:24 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26073 for ; Wed, 23 Feb 2000 11:52:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8BD2F5DDFD; Wed, 23 Feb 2000 11:51:46 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 713E35DE01; Wed, 23 Feb 2000 11:51:46 -0500 (EST) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by segue.merit.edu (Postfix) with ESMTP id A65A45DDFD for ; Wed, 23 Feb 2000 11:51:44 -0500 (EST) Received: from rhino (rhino.cisco.com [172.20.9.57]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id IAA18552; Wed, 23 Feb 2000 08:41:04 -0800 (PST) Received: from p7020-img-nt (fred-hm-dhcp1.cisco.com [171.69.128.116]) by rhino (SMI-8.6/CISCO.WS.1.1) with SMTP id IAA28180; Wed, 23 Feb 2000 08:56:29 -0800 Message-Id: <4.1.20000223084335.00ade080@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 23 Feb 2000 08:50:59 -0800 To: "Ewart Tempest" From: Fred Baker Subject: RE: Clarification request for proposed IETF draft "PPP BCP Issue 0.3 (February 2000)" Cc: "'ietf-ppp@merit.edu'" In-Reply-To: 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 At 06:58 AM 2/23/00 +0000, Ewart Tempest wrote: > > So for bridged data, what you say above is clearly true. For PDUs which > purely have point-to-point significance, like BPDUs, the need to have these > padded to the minimum Ethernet frame length is less clear (e.g. TCN BPDU data > length 4 bytes => would need to add 42 bytes of pad if Ethernet frame not > tagged). To remove any ambiguity, I would like to see an explicit statement > wrt minimum length of the LLC data field. So you have proposed that they always be augmented, and you have agreed with me that such is unnecessary. If it is unnecessary and it is done, there is no harm, and if it is not done, there is no harm. Which leaves me really confused. Yes, we can put in a sentence, but would there be an interoperability impact if someone ignored it? Is there any combination which gets all the user or control traffic through and which is non-interoperable with the other solutions? Maybe it's just me, but I'm not fond of specifying things that don't need to be specified. My experience is that they lead to fruitless arguments about what the sentence should say and why, and fail to promote interoperability. What I'd like to hear is a case where it is important to have this specified. From owner-ietf-ppp-outgoing@merit.edu Thu Feb 24 17:44:15 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12174 for ; Thu, 24 Feb 2000 17:44:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id AEC095DDC0; Thu, 24 Feb 2000 17:43:48 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9EBBF5DDB9; Thu, 24 Feb 2000 17:43:48 -0500 (EST) Received: from intra0.extant.net (intra0.extant.net [216.28.121.11]) by segue.merit.edu (Postfix) with ESMTP id 301FD5DD9A for ; Thu, 24 Feb 2000 17:43:47 -0500 (EST) Received: from karl ([216.28.121.202]) by intra0.extant.net (Netscape Messaging Server 3.6) with ESMTP id AAA6E6D; Thu, 24 Feb 2000 15:43:59 -0700 Message-Id: <4.2.2.20000224174059.00ca7a90@mail.extant.net> X-Sender: kfox@mail.extant.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 24 Feb 2000 17:43:45 -0500 To: ietf-ppp@merit.edu From: "Karl Fox" Subject: Microsoft Point-To-Point Encryption (MPPE) Protocol - Working Group Last Call 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 This is last call. I will advise the area directors that we want to take Microsoft Point-To-Point Encryption (MPPE) Protocol (draft-ietf-pppext-mppe-04.txt) to Informational on March 9, 2000 unless there is substantive comment raised on the list. Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Thu Feb 24 17:44:49 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12191 for ; Thu, 24 Feb 2000 17:44:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 082305DDF0; Thu, 24 Feb 2000 17:44:25 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DEF275DDC5; Thu, 24 Feb 2000 17:44:24 -0500 (EST) Received: from intra0.extant.net (intra0.extant.net [216.28.121.11]) by segue.merit.edu (Postfix) with ESMTP id A14515DDCC for ; Thu, 24 Feb 2000 17:44:19 -0500 (EST) Received: from karl ([216.28.121.202]) by intra0.extant.net (Netscape Messaging Server 3.6) with ESMTP id AAA6E75; Thu, 24 Feb 2000 15:44:32 -0700 Message-Id: <4.2.2.20000224173147.043bd7a0@mail.extant.net> X-Sender: kfox@mail.extant.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 24 Feb 2000 17:42:42 -0500 To: ietf-ppp@merit.edu From: "Karl Fox" Subject: MPPE Key Derivation - Working Group Last Call 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 This is last call. I will advise the area directors that we want to take MPPE Key Derivation (draft-ietf-pppext-mppe-keys-02.txt) to Informational on March 9, 2000 unless there is substantive comment raised on the list. Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Thu Feb 24 19:38:15 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13178 for ; Thu, 24 Feb 2000 19:38:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3E7885DDC5; Thu, 24 Feb 2000 19:37:40 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 256215DD9A; Thu, 24 Feb 2000 19:37:40 -0500 (EST) Received: from shambhala.mayannetworks.com (h253.mayannetworks.com [206.184.145.253]) by segue.merit.edu (Postfix) with ESMTP id 075EE5DD9A for ; Thu, 24 Feb 2000 19:37:38 -0500 (EST) Received: (from henrikk@localhost) by shambhala.mayannetworks.com (8.8.8/8.8.8) id QAA10556; Thu, 24 Feb 2000 16:37:37 -0800 (PST) Date: Thu, 24 Feb 2000 16:37:37 -0800 (PST) From: Henrik Kristensen Message-Id: <200002250037.QAA10556@shambhala.mayannetworks.com> To: ietf-ppp@merit.edu Subject: (ML)PPP State Machine Issues Cc: henrikk@mayannetworks.com X-Sun-Charset: US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi, Please forgive me if I'm missing what ought to be "common knowledge": I've seen problems with (ML)PPP LCP/NCP negotiation sequences that didn't converge even when the two ends agreed on all options. I have a couple of changes to the RFC1661 state machine that seem to solve the problem and be backwards compatible but, I was wondering whether any specified or de-facto standard solution already exists that I'm not aware of ? (While useful for realigning two ends using different timer algorithms/constants, exponential timeout doesn't always help in the case where the two ends use the same algorithm.) Thanks, Henrik Kristensen Mayan Networks From owner-ietf-ppp-outgoing@merit.edu Thu Feb 24 19:57:51 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13335 for ; Thu, 24 Feb 2000 19:57:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id A73265DDC1; Thu, 24 Feb 2000 19:57:26 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7DDBE5DD9A; Thu, 24 Feb 2000 19:57:26 -0500 (EST) Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by segue.merit.edu (Postfix) with ESMTP id C72635DDC1 for ; Thu, 24 Feb 2000 19:57:24 -0500 (EST) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id QAA91690; Thu, 24 Feb 2000 16:56:53 -0800 (PST) From: Archie Cobbs Message-Id: <200002250056.QAA91690@bubba.whistle.com> Subject: Re: (ML)PPP State Machine Issues In-Reply-To: <200002250037.QAA10556@shambhala.mayannetworks.com> from Henrik Kristensen at "Feb 24, 2000 04:37:37 pm" To: henrikk@mayannetworks.com (Henrik Kristensen) Date: Thu, 24 Feb 2000 16:56:53 -0800 (PST) Cc: ietf-ppp@merit.edu X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 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 Henrik Kristensen writes: > Please forgive me if I'm missing what ought to be "common > knowledge": > > I've seen problems with (ML)PPP LCP/NCP negotiation sequences > that didn't converge even when the two ends agreed on all > options. In my experience this is usually because the link latency is too high compared to the retransmit delay... does increasing the retransmit time not solve your problem? -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-ietf-ppp-outgoing@merit.edu Thu Feb 24 20:18:53 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13681 for ; Thu, 24 Feb 2000 20:18:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7D3A05DE5D; Thu, 24 Feb 2000 20:16:56 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6AE5A5DE5B; Thu, 24 Feb 2000 20:16:56 -0500 (EST) Received: from shambhala.mayannetworks.com (h253.mayannetworks.com [206.184.145.253]) by segue.merit.edu (Postfix) with ESMTP id 80B0D5DD9A for ; Thu, 24 Feb 2000 20:16:54 -0500 (EST) Received: (from henrikk@localhost) by shambhala.mayannetworks.com (8.8.8/8.8.8) id RAA10656; Thu, 24 Feb 2000 17:16:52 -0800 (PST) Date: Thu, 24 Feb 2000 17:16:52 -0800 (PST) From: Henrik Kristensen Message-Id: <200002250116.RAA10656@shambhala.mayannetworks.com> To: henrikk@mayannetworks.com, archie@whistle.com Subject: Re: (ML)PPP State Machine Issues Cc: ietf-ppp@merit.edu X-Sun-Charset: US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Thanks for the sugegstion. Increasing timeout value didn't help in this case (and latency was low; I was only running a few feet of fiber in a lab). (What happened was that one end restarted without the other end noticing, which can happen if there are switches or cross-connects in the telecom path and, one end doesn't get the chance to send TERM_ACK before it is disconnected. This causes the "innocent end" to jump back from OPENED to REQSENT or ACKSENT when it gets the CONF_REQ and in this situation there's a chance the two ends will end up cycling between OPENED and REQSENT/ACKSENT.) Thanks, --Henrik > From owner-ietf-ppp-outgoing@merit.edu Thu Feb 24 16:57 PST 2000 > Delivered-To: ietf-ppp-outgoing@merit.edu > From: Archie Cobbs > Subject: Re: (ML)PPP State Machine Issues > To: henrikk@mayannetworks.com (Henrik Kristensen) > Date: Thu, 24 Feb 2000 16:56:53 -0800 (PST) > Cc: ietf-ppp@merit.edu > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > > Henrik Kristensen writes: > > Please forgive me if I'm missing what ought to be "common > > knowledge": > > > > I've seen problems with (ML)PPP LCP/NCP negotiation sequences > > that didn't converge even when the two ends agreed on all > > options. > > In my experience this is usually because the link latency is > too high compared to the retransmit delay... does increasing > the retransmit time not solve your problem? > > -Archie > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com > > From owner-ietf-ppp-outgoing@merit.edu Thu Feb 24 20:33:44 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13961 for ; Thu, 24 Feb 2000 20:33:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1A9155DDC4; Thu, 24 Feb 2000 20:31:08 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 084925DDBC; Thu, 24 Feb 2000 20:31:07 -0500 (EST) Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by segue.merit.edu (Postfix) with ESMTP id 6CBE05DD9A for ; Thu, 24 Feb 2000 20:31:06 -0500 (EST) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id RAA95044; Thu, 24 Feb 2000 17:30:35 -0800 (PST) From: Archie Cobbs Message-Id: <200002250130.RAA95044@bubba.whistle.com> Subject: Re: (ML)PPP State Machine Issues In-Reply-To: <200002250116.RAA10656@shambhala.mayannetworks.com> from Henrik Kristensen at "Feb 24, 2000 05:16:52 pm" To: henrikk@mayannetworks.com (Henrik Kristensen) Date: Thu, 24 Feb 2000 17:30:35 -0800 (PST) Cc: ietf-ppp@merit.edu X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 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 Henrik Kristensen writes: > Thanks for the sugegstion. Increasing timeout value didn't help in > this case (and latency was low; I was only running a few feet of > fiber in a lab). > > (What happened was that one end restarted without the other end > noticing, which can happen if there are switches or cross-connects > in the telecom path and, one end doesn't get the chance to send > TERM_ACK before it is disconnected. > This causes the "innocent end" to jump back from OPENED to REQSENT > or ACKSENT when it gets the CONF_REQ and in this situation there's > a chance the two ends will end up cycling between OPENED and > REQSENT/ACKSENT.) Hmm... do you have a log trace of this? I still don't see how that would happen (though I believe you that it does).. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-ietf-ppp-outgoing@merit.edu Thu Feb 24 21:25:38 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14516 for ; Thu, 24 Feb 2000 21:25:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4F5775DE1D; Thu, 24 Feb 2000 21:25:14 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3DCBF5DDBC; Thu, 24 Feb 2000 21:25:14 -0500 (EST) Received: from shambhala.mayannetworks.com (h253.mayannetworks.com [206.184.145.253]) by segue.merit.edu (Postfix) with ESMTP id 2A4165DD9A for ; Thu, 24 Feb 2000 21:25:12 -0500 (EST) Received: (from henrikk@localhost) by shambhala.mayannetworks.com (8.8.8/8.8.8) id SAA10726; Thu, 24 Feb 2000 18:25:10 -0800 (PST) Date: Thu, 24 Feb 2000 18:25:10 -0800 (PST) From: Henrik Kristensen Message-Id: <200002250225.SAA10726@shambhala.mayannetworks.com> To: henrikk@mayannetworks.com, archie@whistle.com Subject: Re: (ML)PPP State Machine Issues Cc: ietf-ppp@merit.edu X-Sun-Charset: US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu No, I'm sorry I didn't keep the log; we don't have a PPP analyzer that can run on our interfaces and in cases with crossed signaling it's hard to exactly reconcile packet dumps from the two ends. One case of crossed signaling was provoked by the non-restarting end receiving RCA in state OPENED. Another was caused by receiving a left-over RCR+ in stat OPENED. I might be able to run the tests with the original code again in a couple of weeks. --Henrik > From archie@whistle.com Thu Feb 24 17:31 PST 2000 > From: Archie Cobbs > Subject: Re: (ML)PPP State Machine Issues > To: henrikk@mayannetworks.com (Henrik Kristensen) > Date: Thu, 24 Feb 2000 17:30:35 -0800 (PST) > Cc: ietf-ppp@merit.edu > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > > Henrik Kristensen writes: > > Thanks for the sugegstion. Increasing timeout value didn't help in > > this case (and latency was low; I was only running a few feet of > > fiber in a lab). > > > > (What happened was that one end restarted without the other end > > noticing, which can happen if there are switches or cross-connects > > in the telecom path and, one end doesn't get the chance to send > > TERM_ACK before it is disconnected. > > This causes the "innocent end" to jump back from OPENED to REQSENT > > or ACKSENT when it gets the CONF_REQ and in this situation there's > > a chance the two ends will end up cycling between OPENED and > > REQSENT/ACKSENT.) > > Hmm... do you have a log trace of this? I still don't see how > that would happen (though I believe you that it does).. > > -Archie > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com > From owner-ietf-ppp-outgoing@merit.edu Fri Feb 25 12:20:44 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15128 for ; Fri, 25 Feb 2000 12:20:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1D5F15DDB9; Fri, 25 Feb 2000 12:20:19 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 064BF5DDB7; Fri, 25 Feb 2000 12:20:19 -0500 (EST) Received: from shambhala.mayannetworks.com (h253.mayannetworks.com [206.184.145.253]) by segue.merit.edu (Postfix) with ESMTP id 4D2975DDCE for ; Fri, 25 Feb 2000 12:19:56 -0500 (EST) Received: (from henrikk@localhost) by shambhala.mayannetworks.com (8.8.8/8.8.8) id JAA12652; Fri, 25 Feb 2000 09:19:52 -0800 (PST) Date: Fri, 25 Feb 2000 09:19:52 -0800 (PST) From: Henrik Kristensen Message-Id: <200002251719.JAA12652@shambhala.mayannetworks.com> To: henrikk@mayannetworks.com, dflowers@nexabit.com Subject: RE: (ML)PPP State Machine Issues Cc: ietf-ppp@merit.edu X-Sun-Charset: US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu I made two changes, both with the purpose of avoiding getting kicked out of OPENED state when unnecessary, and a third change which is already valid according to RFC1661. The changes were: 1) Ignore Duplicate CONFACK received in state OPENED. Described in RFC 1661 [1], sect.4.1 as a "crossed connection", in some cases duplicate Configure-Ack's may be received in state OPENED, causing the generation of a new Configure-Request and a move back to state REQSENT. Depending on the actual scenario (delays and state to the other end), this can cause either delayed link establishment or, start configuration loops (e.g. involving further timeouts). Although it could be argued that the transition from OPENED to REQSENT and the generation of the new Configure-Request might by themselves be harmless, causing delays and not loops, ignoring duplicate Configure- Ack's in state OPENED appears to be safe and backwards compatible. (RFC 1661 [1] sect.5.2 already requires that the Identifier and options must match those sent in the Configure- Request, which protects against Configure-Ack's from a diffenrent (mis)configured link!). 2) Ignore "Truly Duplicate" CONFREQ received in state OPENED. In one scenario, link establishment can fail if one end of the link, after having reached state OPENED receives a duplicate Configure- Request (RCR+) which would cause it to go back to state ACKSENT and generate what is effectively another duplicate Configure-Request (RCR+) towards the other end. The other end might in the meantime have received a Configure-Ack (RCA) and reached state OPENED but, upon receipt of this new Configure-Request (RCR+) go back to state ACKSENT, and the cycle would repeat indefinitely. The solution to this is to ignore duplicate Configure-Requests which may have been caused by timeouts or delays on the link. But, since a received Configure-Request could also be the result of the other end either requesting a change in configuration options (in which case the Identifier must be changed according to [1]) or restarting, only "truly duplicate" Configure-Requests can be ignored. Relying only on the Identifier is insufficient since this value may be "repeated" in the case of the other end restarting and, since it is only an 8 bit value. To ensure uniqueness, an identical Magic number is required as well. This leads to the following suggested change to the PPP State Transition Table [1]. For RCR+ is received in state OPENED (9): IF Identifier is unchanged AND Identifier is different from zero AND Magic number option is present AND Magic number value is unchanged THEN sca/9 ELSE tld,scr,sca/8 That is, if Identifier and Magic number are present and equal to the last received values, and Identifier is different from zero, send Configure-Ack and remain in state OPENED. Otherwise, act as originally specified in RFC 1661 [1]. (Many implementations default to starting with Identifier value zero, hence the extra check against Identifier = zero.) 3) Reuse Identifier when REtransmitting CONFREQ. In order for the second change to be effective, it is also necessary to reuse the same Identifier when retransmitting a CONFREQ (i.e. on TO+ event). This is already mentioned as allowed (though neither recommended for or against) in RFC1661. --Henrik > From dflowers@nexabit.com Fri Feb 25 06:38 PST 2000 > From: Dan Flowers > To: Henrik Kristensen > Subject: RE: (ML)PPP State Machine Issues > Date: Fri, 25 Feb 2000 09:29:09 -0500 > MIME-Version: 1.0 > > Hi Henrik, > > I'm curious, what changes to the FSM solved your problem? > > Thanks, > Dan > > > -----Original Message----- > > From: Henrik Kristensen [SMTP:henrikk@mayannetworks.com] > > Sent: Thursday, February 24, 2000 7:38 PM > > To: ietf-ppp@merit.edu > > Cc: henrikk@mayannetworks.com > > Subject: (ML)PPP State Machine Issues > > > > Hi, > > > > Please forgive me if I'm missing what ought to be "common > > knowledge": > > > > I've seen problems with (ML)PPP LCP/NCP negotiation sequences > > that didn't converge even when the two ends agreed on all > > options. > > > > I have a couple of changes to the RFC1661 state machine that > > seem to solve the problem and be backwards compatible but, I > > was wondering whether any specified or de-facto standard > > solution already exists that I'm not aware of ? > > > > (While useful for realigning two ends using different timer > > algorithms/constants, exponential timeout doesn't always help > > in the case where the two ends use the same algorithm.) > > > > Thanks, > > Henrik Kristensen > > Mayan Networks > From owner-ietf-ppp-outgoing@merit.edu Fri Feb 25 13:15:50 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16483 for ; Fri, 25 Feb 2000 13:15:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5FED85DDD0; Fri, 25 Feb 2000 13:14:53 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4F6575DDCE; Fri, 25 Feb 2000 13:14:53 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id 1E3715DDBC for ; Fri, 25 Feb 2000 13:14:50 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id LAA10100 for ietf-ppp@merit.edu env-from ; Fri, 25 Feb 2000 11:14:48 -0700 (MST) Date: Fri, 25 Feb 2000 11:14:48 -0700 (MST) From: Vernon Schryver Message-Id: <200002251814.LAA10100@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: RE: (ML)PPP State Machine Issues Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Henrik Kristensen > 1) Ignore Duplicate CONFACK received in state OPENED. > > Described in RFC 1661 [1], sect.4.1 as a "crossed connection", in > some cases duplicate Configure-Ack's may be received in state OPENED, > causing the generation of a new Configure-Request and a move back to > state REQSENT. Depending on the actual scenario (delays and state to > the other end), this can cause either delayed link establishment or, > start configuration loops (e.g. involving further timeouts). > ... It is impossible to receive a duplicate Configure-Ack unless you either fail to check packet ID's, or if you send Configure-Requests with duplicate ID's. Otherwise, there is no such thing as the very idea a duplicate Configure-Ack. If you do bend the standard by re-using ID's on your Configure-Requests, then you must do something about the consequences. > 2) Ignore "Truly Duplicate" CONFREQ received in state OPENED. > > In one scenario, link establishment can fail if one end of the link, > after having reached state OPENED receives a duplicate Configure- > Request (RCR+) which would cause it to go back to state ACKSENT and > generate what is effectively another duplicate Configure-Request > (RCR+) towards the other end. The other end might in the meantime > have received a Configure-Ack (RCA) and reached state OPENED but, > upon receipt of this new Configure-Request (RCR+) go back to state > ACKSENT, and the cycle would repeat indefinitely. > > The solution to this is to ignore duplicate Configure-Requests which > may have been caused by timeouts or delays on the link. > ... That is a mistake. PPP links are universally assumed to deliver all packets (that they deliver) in the order in which they were sent. That implies that if you ignore a Configure-Request from a peer that is compliant with RFC 1661, then you will break the link. The peer will be waiting for your Configure-Ack. You cannot ignore the peer's Configure-Request, even if it has the same ID as its previous Configure-Request. Are you failing to change or check the LCP packet ID? > ... > That is, if Identifier and Magic number are present and equal to the > last received values, and Identifier is different from zero, send > Configure-Ack and remain in state OPENED. Otherwise, act as > originally specified in RFC 1661 [1]. > (Many implementations default to starting with Identifier value zero, > hence the extra check against Identifier = zero.) Some other implementations start with an intentionally random ID, and will use an ID of zero after having used a non-zero ID. Anything that assumes anything special about ID 0 is a mistake. > 3) Reuse Identifier when REtransmitting CONFREQ. > > In order for the second change to be effective, it is also necessary > to reuse the same Identifier when retransmitting a CONFREQ (i.e. on > TO+ event). This is already mentioned as allowed (though neither > recommended for or against) in RFC1661. I may have been the person who argued vigorously for re-using ID's when retransmitting Configure-Requests and for changing the draft to allow them. I know that I eventually decided it was a bad idea for my own code. Regardless, if you do re-use ID's, you "MUST NOT" assume that the peer will know or understand that you are doing so. You also "MUST NOT" assume that the peer is or is not re-using ID's. If you do re-use ID's, then you "MUST" also warp your own implementation of the state table as required, probably including introducing the non-standard idea of a "duplicate Configure-Ack", although I do not know how you can define a "duplicate Configure-Ack" and still interoperate with existing implementations. As I said, I eventually decided that re-using ID's is a bad idea at least for my own code. There are a bazillion PPP implementations in the field. They work, do not get stuck, and do not make unnecessary trips through the initial states. Anything you do that requires changes in the state table that they implement is wrong, even if the changes result in a better protocol. I suspect that re-using ID's is exactly such an idea, that the protocol would have been better (e.g. quicker to converge on a lossy link) if it allowed for in duplicate ID's, the original state table, but that duplicate ID's cannot be retrofitted. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Fri Feb 25 13:57:57 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17550 for ; Fri, 25 Feb 2000 13:57:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 172365DDD6; Fri, 25 Feb 2000 13:57:17 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 054325DDD3; Fri, 25 Feb 2000 13:57:17 -0500 (EST) Received: from shambhala.mayannetworks.com (h253.mayannetworks.com [206.184.145.253]) by segue.merit.edu (Postfix) with ESMTP id 25EA95DDD2 for ; Fri, 25 Feb 2000 13:57:15 -0500 (EST) Received: (from henrikk@localhost) by shambhala.mayannetworks.com (8.8.8/8.8.8) id KAA12717; Fri, 25 Feb 2000 10:57:14 -0800 (PST) Date: Fri, 25 Feb 2000 10:57:14 -0800 (PST) From: Henrik Kristensen Message-Id: <200002251857.KAA12717@shambhala.mayannetworks.com> To: ietf-ppp@merit.edu, vjs@calcite.rhyolite.com Subject: RE: (ML)PPP State Machine Issues X-Sun-Charset: US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu I wasn't trying to start a big discussion. It appears RFC1661 is perfect by definition, in which case I must be wrong. Just let me add in closing: Duplicates can happen (for example in what's described as "crossed connection" in RFC1661 sect.4.1's table or, if one end times out a number of times(TO+) before the other end's first CONFACK gets back.) I still think my changes would be backwards compatible with 1661- conformant implementations. (However some of my changes would not have any effect when "talking to" a 1661-conformant version. For example, if the other end doesn't reuse the Identifier, we don't ignore CONFREQ.) The "zero check" was an extra protection AGAINST altering the standard behavior in the zero case..: For RCR+ is received in state OPENED (9): IF Identifier is unchanged AND Identifier is different from zero AND Magic number option is present AND Magic number value is unchanged THEN sca/9 ELSE tld,scr,sca/8 (Obviously, I've extended my stay on this list by now. My apologies.) --Henrik > From owner-ietf-ppp-outgoing@merit.edu Fri Feb 25 10:15 PST 2000 > Delivered-To: ietf-ppp-outgoing@merit.edu > Date: Fri, 25 Feb 2000 11:14:48 -0700 (MST) > From: Vernon Schryver > To: ietf-ppp@merit.edu > Subject: RE: (ML)PPP State Machine Issues > > > From: Henrik Kristensen > > > 1) Ignore Duplicate CONFACK received in state OPENED. > > > > Described in RFC 1661 [1], sect.4.1 as a "crossed connection", in > > some cases duplicate Configure-Ack's may be received in state OPENED, > > causing the generation of a new Configure-Request and a move back to > > state REQSENT. Depending on the actual scenario (delays and state to > > the other end), this can cause either delayed link establishment or, > > start configuration loops (e.g. involving further timeouts). > > ... > > It is impossible to receive a duplicate Configure-Ack unless you either > fail to check packet ID's, or if you send Configure-Requests with duplicate > ID's. Otherwise, there is no such thing as the very idea a duplicate > Configure-Ack. If you do bend the standard by re-using ID's on your > Configure-Requests, then you must do something about the consequences. > > > > 2) Ignore "Truly Duplicate" CONFREQ received in state OPENED. > > > > In one scenario, link establishment can fail if one end of the link, > > after having reached state OPENED receives a duplicate Configure- > > Request (RCR+) which would cause it to go back to state ACKSENT and > > generate what is effectively another duplicate Configure-Request > > (RCR+) towards the other end. The other end might in the meantime > > have received a Configure-Ack (RCA) and reached state OPENED but, > > upon receipt of this new Configure-Request (RCR+) go back to state > > ACKSENT, and the cycle would repeat indefinitely. > > > > The solution to this is to ignore duplicate Configure-Requests which > > may have been caused by timeouts or delays on the link. > > ... > > That is a mistake. PPP links are universally assumed to deliver > all packets (that they deliver) in the order in which they were > sent. That implies that if you ignore a Configure-Request from a > peer that is compliant with RFC 1661, then you will break the link. > The peer will be waiting for your Configure-Ack. You cannot ignore > the peer's Configure-Request, even if it has the same ID as its > previous Configure-Request. > > Are you failing to change or check the LCP packet ID? > > > > ... > > That is, if Identifier and Magic number are present and equal to the > > last received values, and Identifier is different from zero, send > > Configure-Ack and remain in state OPENED. Otherwise, act as > > originally specified in RFC 1661 [1]. > > (Many implementations default to starting with Identifier value zero, > > hence the extra check against Identifier = zero.) > > Some other implementations start with an intentionally random ID, > and will use an ID of zero after having used a non-zero ID. Anything > that assumes anything special about ID 0 is a mistake. > > > > 3) Reuse Identifier when REtransmitting CONFREQ. > > > > In order for the second change to be effective, it is also necessary > > to reuse the same Identifier when retransmitting a CONFREQ (i.e. on > > TO+ event). This is already mentioned as allowed (though neither > > recommended for or against) in RFC1661. > > I may have been the person who argued vigorously for re-using ID's when > retransmitting Configure-Requests and for changing the draft to allow > them. I know that I eventually decided it was a bad idea for my own code. > Regardless, if you do re-use ID's, you "MUST NOT" assume that the peer > will know or understand that you are doing so. You also "MUST NOT" assume > that the peer is or is not re-using ID's. If you do re-use ID's, then > you "MUST" also warp your own implementation of the state table as > required, probably including introducing the non-standard idea of a > "duplicate Configure-Ack", although I do not know how you can define a > "duplicate Configure-Ack" and still interoperate with existing > implementations. As I said, I eventually decided that re-using ID's is > a bad idea at least for my own code. > > There are a bazillion PPP implementations in the field. They work, do > not get stuck, and do not make unnecessary trips through the initial > states. Anything you do that requires changes in the state table that > they implement is wrong, even if the changes result in a better protocol. > I suspect that re-using ID's is exactly such an idea, that the protocol > would have been better (e.g. quicker to converge on a lossy link) if it > allowed for in duplicate ID's, the original state table, but that duplicate > ID's cannot be retrofitted. > > > Vernon Schryver vjs@rhyolite.com > > From owner-ietf-ppp-outgoing@merit.edu Fri Feb 25 14:34:24 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18788 for ; Fri, 25 Feb 2000 14:34:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id C13DD5DDD4; Fri, 25 Feb 2000 14:33:54 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9B8565DDD1; Fri, 25 Feb 2000 14:33:54 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id 245905DDCE for ; Fri, 25 Feb 2000 14:33:52 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id MAA11672 for ietf-ppp@merit.edu env-from ; Fri, 25 Feb 2000 12:33:51 -0700 (MST) Date: Fri, 25 Feb 2000 12:33:51 -0700 (MST) From: Vernon Schryver Message-Id: <200002251933.MAA11672@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: RE: (ML)PPP State Machine Issues Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Henrik Kristensen > I wasn't trying to start a big discussion. It appears RFC1661 is > perfect by definition, in which case I must be wrong. That depends on whether you care more about writing a PPP implementation that interoperatoes than about the theoretically best possible point-to-point protocol. Before PPP was widely deployed, I think you would have been right. > Just let me add in closing: > > Duplicates can happen (for example in what's described as "crossed > connection" in RFC1661 sect.4.1's table or, if one end times out a > number of times(TO+) before the other end's first CONFACK gets > back.) Unless you fail to change the ID in your Configure-Requests, there is no such thing as a duplicate Configure-Ack. > I still think my changes would be backwards compatible with 1661- > conformant implementations. Wasn't the basis of your complaint or proposal is that existing RFC 1661 conformant implementations that do not re-use ID"s do not work well with your implementation? > (However some of my changes would not > have any effect when "talking to" a 1661-conformant version. For > example, if the other end doesn't reuse the Identifier, we don't > ignore CONFREQ.) How do you know whether the peer reuses ID's? The peer might have sent you 257 Configure-Requests, starting and ending with ID #1, but with 255 lost. (well, assuming it has very generous/persistent timers and counters) > The "zero check" was an extra protection AGAINST altering the > standard behavior in the zero case..: > For RCR+ is received in state OPENED (9): > IF Identifier is unchanged > AND Identifier is different from zero > AND Magic number option is present > AND Magic number value is unchanged > THEN sca/9 > ELSE tld,scr,sca/8 But once again, you cannot infer anything from a zero ID. More than one implementation does not start with ID 0. Besides, why would the magic number value ever change, assuming there is no evidence of loop-back? Thus, your test is necessarily reduced to only "if the ID is unchanged." > (Obviously, I've extended my stay on this list by now. My apologies.) I also disagree with that. I think you have made a compelling case that the words in RFC 1661 that allow duplicate ID's should be removed. The idea of duplicate ID's was neat (even if I do say so myself), but based on the assumption that losses of Configure-Requests packets are common. That assumption is wrong, at least today, with ISDN, DSL, v.42 modems, and the other media where PPP is used. Thus, reusing ID's is not valuable. Without changes in RFC 1661 implementations that do not reuse ID's, re-using ID's does not work. A conformant RFC 1661 implementation will always assume that the peer is starting over when it receives a Configure-Request. It is impossible in theory and in practice to change all or even most of the literally 100's of 1,000,000's of deployed PPP implementations (every Microsoft Windows installation has one). Thus, re-using ID's is a bad idea today, and it should be officiall deprecated. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Fri Feb 25 14:52:16 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19253 for ; Fri, 25 Feb 2000 14:52:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 940DE5DD91; Fri, 25 Feb 2000 14:51:49 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 67E205DDD1; Fri, 25 Feb 2000 14:51:49 -0500 (EST) Received: from ironbridgenetworks.com (ibn-host12.ironbridgenetworks.com [146.115.140.12]) by segue.merit.edu (Postfix) with ESMTP id 397175DD91 for ; Fri, 25 Feb 2000 14:51:47 -0500 (EST) Received: (from news@localhost) by ironbridgenetworks.com (8.9.3/8.9.3) id OAA10670 for ietf-ppp@merit.edu; Fri, 25 Feb 2000 14:51:42 -0500 (EST) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: (ML)PPP State Machine Issues Date: 25 Feb 2000 14:51:42 -0500 Organization: IronBridge Networks Lines: 50 Message-ID: <86snyhysa9.fsf@ironbridgenetworks.com> References: <200002251857.KAA12717@shambhala.mayannetworks.com> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu henrikk@mayannetworks.com (Henrik Kristensen) writes: > I wasn't trying to start a big discussion. It appears RFC1661 is > perfect by definition, in which case I must be wrong. If you're taking it personally, don't. There's ample evidence that getting all of RFC 1661 correct in a given implementation is not quite easy. If you're asking for help, don't forget that this is a working group mailing list, and take the replies in the helpful spirit that they're given. ;-} > Just let me add in closing: > > Duplicates can happen (for example in what's described as "crossed > connection" in RFC1661 sect.4.1's table or, if one end times out a > number of times(TO+) before the other end's first CONFACK gets > back.) Real duplicates of Configure-Ack just can't happen. Nobody sends Configure-{Ack,Nak,Rej} except in response to an explicit Configure-Request. Any implementation that resends these messages without solicitation is completely broken. Since all of those are explicitly triggered messages (not timed), apparent duplicates can't happen at all unless these two things (or any of a number of analogous implementation errors) are true: - You're sending the same ID number when handling the restart timer, and - You have your restart timer set shorter than the link's RTT. Jumping back to the start of the discussion, it's quite likely that the restart timer is too short. > I still think my changes would be backwards compatible with 1661- > conformant implementations. (However some of my changes would not > have any effect when "talking to" a 1661-conformant version. For > example, if the other end doesn't reuse the Identifier, we don't > ignore CONFREQ.) I'm with Vern on this one. Assuming *ANY* characteristics -- initial values, special values, monotonicity, et cetera -- of the peer's ID number in its Configure-Request message is a bug, not a feature. If you have to do that, then something else is quite wrong. -- James Carlson, System Architect IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Fri Feb 25 15:38:55 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20214 for ; Fri, 25 Feb 2000 15:38:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id AEDA35DDE0; Fri, 25 Feb 2000 15:38:24 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 96C545DDDF; Fri, 25 Feb 2000 15:38:24 -0500 (EST) Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by segue.merit.edu (Postfix) with ESMTP id 438BE5DDD7 for ; Fri, 25 Feb 2000 15:38:22 -0500 (EST) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id MAA06437; Fri, 25 Feb 2000 12:37:36 -0800 (PST) From: Archie Cobbs Message-Id: <200002252037.MAA06437@bubba.whistle.com> Subject: Re: (ML)PPP State Machine Issues In-Reply-To: <86snyhysa9.fsf@ironbridgenetworks.com> from James Carlson at "Feb 25, 2000 02:51:42 pm" To: carlson@ironbridgenetworks.com (James Carlson) Date: Fri, 25 Feb 2000 12:37:36 -0800 (PST) Cc: ietf-ppp@merit.edu X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 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 writes: > > I wasn't trying to start a big discussion. It appears RFC1661 is > > perfect by definition, in which case I must be wrong. > > If you're taking it personally, don't. There's ample evidence that > getting all of RFC 1661 correct in a given implementation is not quite > easy. If you're asking for help, don't forget that this is a working > group mailing list, and take the replies in the helpful spirit that > they're given. ;-} For what it's worth.. Here are four changes I had to make to the RFC 1661 state machine to resolve certain race conditions: RCR+ in state STOPPED: add tls RCR- in state STOPPED: add tls OPEN in state CLOSED: add tls DOWN in state CLOSING: add tlf Note: I'm not claiming RFC 1661 is broken, just that my implementation of it was broken until these changes were added. What this does is insure that the lower layer always knows what it is supposed to do -- i.e., either come up or stay down. For example, without the "tlf" action in state CLOSING upon receipt of a DOWN event, the lower layer still "thinks" that it's needed, because a "tls" was the last thing it heard from this layer, when in actuality if you're in the CLOSING state it's not needed. In my implementation this problem led to a modem redialing when it was supposed to stay on-hook, etc. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-ietf-ppp-outgoing@merit.edu Fri Feb 25 19:33:57 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23696 for ; Fri, 25 Feb 2000 19:33:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id DDBFF5DDE2; Fri, 25 Feb 2000 19:33:02 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CC4525DDDD; Fri, 25 Feb 2000 19:33:01 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id 664915DDDB for ; Fri, 25 Feb 2000 19:32:59 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id RAA16876 for ietf-ppp@merit.edu env-from ; Fri, 25 Feb 2000 17:32:58 -0700 (MST) Date: Fri, 25 Feb 2000 17:32:58 -0700 (MST) From: Vernon Schryver Message-Id: <200002260032.RAA16876@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: (ML)PPP State Machine Issues Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Archie Cobbs > Here are four changes I had to make to the RFC 1661 state machine > to resolve certain race conditions: > > RCR+ in state STOPPED: add tls > ... > In my implementation this problem led to a modem redialing when it > was supposed to stay on-hook, etc. I've always found the inter-state machine interactions in RFC 1661, confusing, wrong, simplistic, or all of those. I'm willing to believe that they are close someone's real code, but I've never seen any code where they made sense. I've also also figured they're outside the proper scope of the protocol (that which can be seen on the wire), and so not worth arguing about. I guess their main problem is that they try to formalize simple, obvious ideas that get more confusing as you make them more formal, such as "don't redial when you've been told to shut down" and "1+1=2". If you never have, try to prove, in the sense a mathematician uses the word, that 1+1=2, but without basically saying "because it is" by quoting a definition of 2. Vernon Schryver vjs@rhyolite.com