From owner-ietf-ppp-outgoing@merit.edu Mon May 1 14:58:06 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 OAA02700 for ; Mon, 1 May 2000 14:58:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1F3E35DDED; Mon, 1 May 2000 14:57:32 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0D9B65DDEA; Mon, 1 May 2000 14:57:32 -0400 (EDT) Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by segue.merit.edu (Postfix) with ESMTP id 9DAD85DDB1 for ; Mon, 1 May 2000 14:57:30 -0400 (EDT) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id LAA92941; Mon, 1 May 2000 11:56:52 -0700 (PDT) From: Archie Cobbs Message-Id: <200005011856.LAA92941@bubba.whistle.com> Subject: Re: IPCP within MP? In-Reply-To: <200004282200.QAA23004@calcite.rhyolite.com> from Vernon Schryver at "Apr 28, 2000 04:00:53 pm" To: vjs@calcite.rhyolite.com (Vernon Schryver) Date: Mon, 1 May 2000 11:56:52 -0700 (PDT) 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 Vernon Schryver writes: > > > 3. My side attempts to send an IPCP Configure-Request that's > > > split into two parts and sent as two multi-link fragments > > > over the two links. > > > > No problem with that. (I don't think I've seen an implementation yet > > that does this, though ...) > > > > > 4. The remote side responds with an LCP Protocol-Reject > > > of protocol 0x003d (the multilink protocol) on link #2, > > > and ignores my IPCP Configure-Request. The protocol > > > reject contains enough of the packet to show that it's > > > rejecting one of the IPCP Configure-Request MP fragments. > > > > Assuming that the second link is actually configured to run MP, that's > > a rather horrible bug. > > Yes, #4 indicates serious problems in the peer, but ... > while #3 doesn't violate the standard, it does violate the dictum to be > conservative in what you send. Given how many PPP implementations are > put together, fragmenting any PPP control packet is asking for trouble. > > Consider also that IPCP Configure-Requests are necessarily very tiny, > and that fragmenting tinygrams is a bad idea on performance grounds. FYI, After a little more testing it appears that what's really happening is that the device can't handle IPCP being negotiated *after* both links have come up. It has nothing to do with how the IPCP packets are fragmented, or even whether they are contained in MP or not. That is, this works: - Link 1 reaches NETWORK phase - IPCP is negotiated - Link 2 reaches NETWORK phase But this fails: - Link 1 reaches NETWORK phase - Link 2 reaches NETWORK phase - IPCP is negotiated Whatever. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-ietf-ppp-outgoing@merit.edu Tue May 2 06:44:20 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 GAA26842 for ; Tue, 2 May 2000 06:44:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AB7585DD99; Tue, 2 May 2000 06:43:32 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 914865DDBE; Tue, 2 May 2000 06:43:32 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id B66705DD99 for ; Tue, 2 May 2000 06:43:30 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26715; Tue, 2 May 2000 06:43:29 -0400 (EDT) Message-Id: <200005021043.GAA26715@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-04.txt Date: Tue, 02 May 2000 06:43:28 -0400 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-04.txt Pages : 38 Date : 01-May-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-04.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-04.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-04.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: <20000501102221.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-bcp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-bcp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000501102221.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp-outgoing@merit.edu Thu May 18 11:51:31 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 LAA09266 for ; Thu, 18 May 2000 11:51:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AFD1E5DDC8; Thu, 18 May 2000 11:50:59 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 98BAE5DDF8; Thu, 18 May 2000 11:50:59 -0400 (EDT) Received: from cliff.extant.net (cliff.extant.net [12.17.197.35]) by segue.merit.edu (Postfix) with ESMTP id EFD905DDC8 for ; Thu, 18 May 2000 11:50:57 -0400 (EDT) Received: from karl.extant.net (mojo.extant.net [216.28.121.14]) by cliff.extant.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KD1WP5F1; Thu, 18 May 2000 09:50:56 -0600 Message-Id: <4.3.2.6.2.20000518114830.04a1f5e0@127.0.0.1> X-Sender: kfox@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2.6 (Beta) Date: Thu, 18 May 2000 11:50:53 -0400 To: ietf-ppp@merit.edu From: Karl Fox Subject: PPP Multiplexed Frame Option - 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 PPP Multiplexed Frame Option () to Proposed Standard on June 2, 2000 unless there is substantive comment raised on this list. Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Fri May 19 10:25:19 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 KAA05557 for ; Fri, 19 May 2000 10:25:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4D3ED5DE13; Fri, 19 May 2000 10:24:48 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3AE9E5DDB7; Fri, 19 May 2000 10:24:48 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 509E55DD98 for ; Fri, 19 May 2000 10:24:46 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA25289 for ; Fri, 19 May 2000 07:24:45 -0700 (PDT) Received: from dhcp-174-233.east.sun.com (dhcp-174-233.East.Sun.COM [129.148.174.233]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA01168 for ; Fri, 19 May 2000 10:24:44 -0400 (EDT) Received: (from carlsonj@localhost) by dhcp-174-233.east.sun.com (8.9.3+Sun/8.9.3) id KAA04939; Fri, 19 May 2000 10:24:43 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14629.20138.903736.299605@gargle.gargle.HOWL> Date: Fri, 19 May 2000 10:24:42 -0400 (EDT) From: James Carlson To: pppext Subject: RFC 1979 Deflate / zlib warning X-Mailer: VM 6.75 under Emacs 20.6.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit I've found a potentially serious bug in all popular versions of zlib (0.99, 1.0.4, and the latest 1.1.3) by Jean-loup Gailly and Mark Adler. This library is used to implement RFC 1979 Deflate compression. The short version: If the deflate window size is set to 8, zlib will corrupt memory and (depending on your implementation) cause a kernel panic. The recommended fix is to reply with Configure-Nak if the peer the Window parameter set to 0000 (size 8) in its Configure-Request and ignore Configure-Nak with Window set to 0000. The long version: The problem is that s->strstart gets set to a very large positive integer when wsize (local copy of s->w_size) is subtracted in deflate.c:fill_window(). This happens because MAX_DIST(s) resolves as a negative number when the window size is 8 -- MAX_DIST(s) is defined as s->w_size-MIN_LOOKAHEAD in deflate.h. MIN_LOOKAHEAD is MAX_MATCH+MIN_MATCH+1, and that is 258+3+1 or 262. Since a window size of 8 gives s->w_size 256, MAX_DIST(s) is 256-262 or -6. This results in read_buf() writing over memory outside of s->window, and a crash. I tried experimenting with the definition of MAX_MATCH, MAX_LOOKAHEAD, and MAX_DIST(s) using cargo-cult techniques without much success. I was able to get deflate() (the compression call) to avoid crashing, but I rewarded with either "invalid stored block lengths" or "oversubscribed dynamic bit lengths tree" on calling inflate() on the resulting compressed data, and I wasn't able to fix this. Patches: I've posted patches for ANU PPP and a short example program that crashes zlib to my Sun web site: http://playground.sun.com/~carlsonj/ -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Mon May 22 11:10: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 LAA03495 for ; Mon, 22 May 2000 11:10:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2B20B5DDCF; Mon, 22 May 2000 11:09:56 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 134FC5DDD3; Mon, 22 May 2000 11:09:56 -0400 (EDT) Received: from hclhprnd.hclt.com (unknown [202.54.64.5]) by segue.merit.edu (Postfix) with ESMTP id AE3125DDCF for ; Mon, 22 May 2000 11:09:47 -0400 (EDT) Received: from indus.hclt.com (indus.hclt.com [204.160.251.52]) by hclhprnd.hclt.com (8.9.3/8.9.3) with ESMTP id UAA15206 for ; Mon, 22 May 2000 20:47:26 +0530 From: vijayk@indus.hclt.com Received: from vijaykpc ([192.168.210.22]) by indus.hclt.com (8.8.5/SCO5) with ESMTP id PAA15747; Mon, 22 May 2000 15:18:39 GMT Message-Id: <200005221518.PAA15747@indus.hclt.com> To: ietf-ppp@merit.edu Date: Mon, 22 May 2000 20:40:38 +0530 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: "PPP Link Quality Monitoring" Cc: vijayk@indus.hclt.com X-mailer: Pegasus Mail for Win32 (v3.12b) Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7BIT Hi, I had some questions on PPP Link Quality Monitoring (RFC1989): 1. Is PPP link quality monitoring appropriate for PPP links over Frame Relay and AAL5 ? 2. The RFC 1989 section 2.2 says : " Each Link Quality Monitoring implementation maintains counts of packets and octets transmitted and successfully received" Does this mean that the LQM implementation should maintain all the ifTable counters like IfInOctets, IfInErrors etc. or can LQM depend on the statistics that the underlying protocol driver maintains for these values ? is there any reason for the LQM to maintain these counters ? Thanks, Vijay From owner-ietf-ppp-outgoing@merit.edu Mon May 22 11:23: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 LAA03620 for ; Mon, 22 May 2000 11:23:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 094365DE4E; Mon, 22 May 2000 11:22:59 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DF9125DE50; Mon, 22 May 2000 11:22:58 -0400 (EDT) Received: from cliff.extant.net (cliff.extant.net [12.17.197.35]) by segue.merit.edu (Postfix) with ESMTP id D95F15DE4E for ; Mon, 22 May 2000 11:22:52 -0400 (EDT) Received: from karl.extant.net (mojo.extant.net [216.28.121.14]) by cliff.extant.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KD1WP8MY; Mon, 22 May 2000 09:22:49 -0600 Message-Id: <4.3.2.6.2.20000522112149.00e2ec20@127.0.0.1> X-Sender: kfox@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2.6 (Beta) Date: Mon, 22 May 2000 11:22:42 -0400 To: vijayk@indus.hclt.com, ietf-ppp@merit.edu From: Karl Fox Subject: Re: "PPP Link Quality Monitoring" Cc: vijayk@indus.hclt.com In-Reply-To: <200005221518.PAA15747@indus.hclt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu It doesn't matter who maintains the counters, as long as the values counted are exactly as described in RFC 1989. Otherwise it will appear that data is being lost (or magically generated!). Karl At 11:10 AM 5/22/00, vijayk@indus.hclt.com wrote: >Hi, > >I had some questions on PPP Link Quality Monitoring (RFC1989): > >1. Is PPP link quality monitoring appropriate for PPP links over > Frame Relay and AAL5 ? > >2. The RFC 1989 section 2.2 says : > " Each Link Quality Monitoring implementation maintains counts > of packets and octets transmitted and successfully received" > > Does this mean that the LQM implementation should maintain > all the ifTable counters like IfInOctets, IfInErrors etc. or can > LQM depend on the statistics that the underlying protocol > driver maintains for these values ? is there any reason > for the LQM to maintain these counters ? > > >Thanks, > >Vijay Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Tue May 23 11:37: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 LAA05257 for ; Tue, 23 May 2000 11:37:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0DA055DDAE; Tue, 23 May 2000 11:36:56 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 094D65DDB4; Tue, 23 May 2000 11:36:49 -0400 (EDT) Received: from tenornetworks.com (rtu.tenornetworks.com [63.77.213.2]) by segue.merit.edu (Postfix) with ESMTP id E6A2E5DDAE for ; Tue, 23 May 2000 11:36:46 -0400 (EDT) Received: from tenornetworks.com (hoda [192.168.0.146]) by tenornetworks.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA04254 for ; Tue, 23 May 2000 11:36:46 -0400 (EDT) Message-ID: <392AA602.8740B8B@tenornetworks.com> Date: Tue, 23 May 2000 11:38:42 -0400 From: Omar Hoda X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ppp@merit.edu Subject: NCP interdependence 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 Hi All, Is there anything in PPP stating that one NCP cannot be dependant on another? I apprecaite that all NCPs have independant state machines, however, which part of the RFC would I violating if I linked two NCPs, for example, mandating that one runs before the other. The linkage I was thinking about: 1. IPCP negotiates and moves to the Open state (and learns an IP address during the negotiation) 2. Then XYZCP starts using this IP address in its negotiation. I couldn't find any info. regarding this in the PPP RFC. It sounds wrong to me, but I couldn't find anything to disallow linkage between NCPs. If you know of any NCPs with such dependencies please let me know. Any text that sheads light on this issue would be great too. TIA, Omar.. From owner-ietf-ppp-outgoing@merit.edu Tue May 23 11:55: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 LAA05513 for ; Tue, 23 May 2000 11:55:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EFB905DE05; Tue, 23 May 2000 11:55:05 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D44A15DE0B; Tue, 23 May 2000 11:55:05 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 66C795DE05 for ; Tue, 23 May 2000 11:54:59 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA07176; Tue, 23 May 2000 08:54:56 -0700 (PDT) Received: from dhcp-174-233.east.sun.com (dhcp-174-233.East.Sun.COM [129.148.174.233]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA22604; Tue, 23 May 2000 11:54:52 -0400 (EDT) Received: (from carlsonj@localhost) by dhcp-174-233.east.sun.com (8.9.3+Sun/8.9.3) id LAA13362; Tue, 23 May 2000 11:54:52 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14634.43468.498854.524885@gargle.gargle.HOWL> Date: Tue, 23 May 2000 11:54:52 -0400 (EDT) From: James Carlson To: Omar Hoda Cc: ietf-ppp@merit.edu Subject: Re: NCP interdependence In-Reply-To: Omar Hoda's message of 23 May 2000 11:38:42 References: <392AA602.8740B8B@tenornetworks.com> X-Mailer: VM 6.75 under Emacs 20.6.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Omar Hoda writes: > Is there anything in PPP stating that one NCP cannot be dependant > on another? No. That's outside the standard. > I apprecaite that all NCPs have independant state machines, > however, which part of the RFC would I violating if I linked > two NCPs, for example, mandating that one runs before the > other. There is some precedent for this -- implementations of ECP require that ECP be in Opened state before running any other NCPs, for security reasons. That doesn't mean it's a good thing, but there is an example to point to. > The linkage I was thinking about: > 1. IPCP negotiates and moves to the Open state (and learns > an IP address during the negotiation) > 2. Then XYZCP starts using this IP address in its negotiation. This particular case doesn't look like it's a good thing; I suspect that you might be thinking of doing something via an NCP that would be better done by an IP-based protocol. Can you be more specific about the application of XYZCP? -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Tue May 23 13:54:35 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 NAA07084 for ; Tue, 23 May 2000 13:54:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5F7F05DDF8; Tue, 23 May 2000 13:51:21 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2CC1A5DF82; Tue, 23 May 2000 13:51:21 -0400 (EDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by segue.merit.edu (Postfix) with ESMTP id 5982D5DDF8 for ; Tue, 23 May 2000 13:51:19 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA262310 for ; Tue, 23 May 2000 13:49:34 -0400 From: jmartz@us.ibm.com Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.9) with SMTP id NAA164462 for ; Tue, 23 May 2000 13:51:16 -0400 Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568E8.006213AD ; Tue, 23 May 2000 13:51:15 -0400 X-Lotus-FromDomain: IBMUS To: ietf-ppp@merit.edu Message-ID: <852568E8.00621214.00@D51MTA04.pok.ibm.com> Date: Tue, 23 May 2000 13:51:13 -0400 Subject: Handling LCP Code-Reject Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu I recently got a problem report on my PPP implementation because it terminates the connection after receiving a code-reject for LCP code 11, Discard Request. I went back to RFC 1661 and re-read the section on code-reject on page 34. It states (in part) "Upon reception of the Code-Reject of a code which is fundamental to this version of the protocol, the implementation SHOULD report the problem and drop the connection, since it is unlikely that the situation can be rectified automatically". In hindsight, it's clear to me that I did not really think hard enough about what I was doing when I wrote the code that handles a Code-Reject from the peer. Certainly I wouldn't try to argue that support of Discard Request is "fundamental" to my implementation. So why am I dropping the connection? But on the other hand, where should the line be drawn? Before I jump in to tinker with this I thought it was worth posting a note to the list to see if I could get feedback about what other folks implementations deal with this issue. Where do you draw the line on what is a fundamental code? Discard-Request and below? Protocol-Reject and below? Or some other boundary? Any feedback appreciated. Thanks, -john martz, 8-852-5539, jmartz@us.ibm.com IBM AS/400 TCP/IP PPP development (and stuff) From owner-ietf-ppp-outgoing@merit.edu Tue May 23 14:00:41 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 OAA07203 for ; Tue, 23 May 2000 14:00:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C19185DE1D; Tue, 23 May 2000 13:59:55 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AD3895DE12; Tue, 23 May 2000 13:59:55 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id C0F935DE09 for ; Tue, 23 May 2000 13:59:53 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20644; Tue, 23 May 2000 10:59:45 -0700 (PDT) Received: from dhcp-174-233.east.sun.com (dhcp-174-233.East.Sun.COM [129.148.174.233]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA17723; Tue, 23 May 2000 13:59:44 -0400 (EDT) Received: (from carlsonj@localhost) by dhcp-174-233.east.sun.com (8.9.3+Sun/8.9.3) id NAA13893; Tue, 23 May 2000 13:59:43 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14634.50959.608851.324923@gargle.gargle.HOWL> Date: Tue, 23 May 2000 13:59:43 -0400 (EDT) From: James Carlson To: jmartz@us.ibm.com Cc: ietf-ppp@merit.edu Subject: Re: Handling LCP Code-Reject In-Reply-To: jmartz@us.ibm.com's message of 23 May 2000 13:51:13 References: <852568E8.00621214.00@D51MTA04.pok.ibm.com> X-Mailer: VM 6.75 under Emacs 20.6.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit jmartz@us.ibm.com writes: > But on the other hand, where should the line be drawn? Before I jump in to > tinker with this I thought it was worth posting a note to the list to see > if I could get feedback about what other folks implementations deal with > this issue. Where do you draw the line on what is a fundamental code? > Discard-Request and below? Protocol-Reject and below? Or some other > boundary? The usual rule is >= Configure-Request and <= Protocol-Reject -- those codes cannot be rejected. (Don't forget that 0 is the Vendor-Extension code number.) The others are fair game. (For what it's worth, many implementations have many unsubtle bugs in Code-Reject handling; partly because of the old RFCs, and partly just because.) -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Tue May 23 15:03:59 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 PAA08212 for ; Tue, 23 May 2000 15:03:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4505B5DE48; Tue, 23 May 2000 15:02:05 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 24A6F5DE01; Tue, 23 May 2000 15:02:05 -0400 (EDT) Received: from ossc.ossc.com (oss-gw-pm3.pcnet.net [206.105.29.20]) by segue.merit.edu (Postfix) with SMTP id 1464D5DE44 for ; Tue, 23 May 2000 15:01:45 -0400 (EDT) Received: from raj.ossc.com by ossc.ossc.com (AIX 3.2/UCB 5.64/4.03) id AA10702; Tue, 23 May 2000 14:52:43 -0400 From: milind@ossc.ossc.com (Milind Kulkarni) Message-Id: <012401bfc4e7$b5e27570$11f2f9cc@ossc.com> To: Subject: PPP in PoS Date: Tue, 23 May 2000 14:50:04 -0400 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0121_01BFC4C6.2E1F86D0" X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This is a multi-part message in MIME format. ------=_NextPart_000_0121_01BFC4C6.2E1F86D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello All, A SONET network element implementing IP Over SONET normally uses HDLC = framing and PPP protocol. Do this network element has to implement LCP part of PPP also ? Regards, Milind ------=_NextPart_000_0121_01BFC4C6.2E1F86D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello All,
 
A SONET network = element implementing IP Over=20 SONET normally uses HDLC framing and PPP protocol.
Do this network element has to = implement LCP part=20 of PPP also ?
 
Regards,
Milind
 
------=_NextPart_000_0121_01BFC4C6.2E1F86D0-- From owner-ietf-ppp-outgoing@merit.edu Tue May 23 15:36:36 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 PAA08578 for ; Tue, 23 May 2000 15:36:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2CA9F5DD94; Tue, 23 May 2000 15:36:11 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 09F8A5DDCA; Tue, 23 May 2000 15:36:11 -0400 (EDT) Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by segue.merit.edu (Postfix) with ESMTP id C19285DD94 for ; Tue, 23 May 2000 15:36:04 -0400 (EDT) Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA24563 for ; Tue, 23 May 2000 15:36:04 -0400 (EDT) Received: from pai820exch001h.wins.lucent.com (h135-14-3-59.lucent.com [135.14.3.59]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA24545 for ; Tue, 23 May 2000 15:36:04 -0400 (EDT) Received: by pai820exch001h.micro.lucent.com with Internet Mail Service (5.5.2448.0) id ; Tue, 23 May 2000 15:36:03 -0400 Message-ID: <15A2D77655CDD1118B5500805F6FE87A0587EDAD@pai820exch002u.micro.lucent.com> From: "Langner, Paul (Paul)" To: ietf-ppp@merit.edu, "'milind@ossc.ossc.com'" Subject: RE: PPP in PoS Date: Tue, 23 May 2000 15:36:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Many implementations don't - especially the first ones. A lot of it is because the link is turned on once, and everything else is provisioned. > ---------- > From: milind@ossc.ossc.com[SMTP:milind@ossc.ossc.com] > Sent: Tuesday, May 23, 2000 2:50 PM > To: ietf-ppp@merit.edu > Subject: PPP in PoS > > Hello All, > > A SONET network element implementing IP Over SONET normally uses HDLC > framing and PPP protocol. > Do this network element has to implement LCP part of PPP also ? > > Regards, > Milind > > From owner-ietf-ppp-outgoing@merit.edu Tue May 23 16:48:52 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 QAA09432 for ; Tue, 23 May 2000 16:48:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B0AE85DD9B; Tue, 23 May 2000 16:46:30 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9BCAF5DDFC; Tue, 23 May 2000 16:46:30 -0400 (EDT) Received: from daystrom.abatis-sys.com (unknown [216.13.164.98]) by segue.merit.edu (Postfix) with ESMTP id DCC925DD9B for ; Tue, 23 May 2000 16:46:28 -0400 (EDT) Received: by daystrom.abatissys.com with Internet Mail Service (5.5.2650.21) id ; Tue, 23 May 2000 12:01:22 -0700 Message-ID: <811670B03A7DD211A2730008C709C20959F478@daystrom.abatissys.com> From: "Li, Renwei" To: "'ietf-ppp@merit.edu'" Subject: PPP over Ethernet Date: Tue, 23 May 2000 12:01:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This is a question about the termination point in the PPP over Ethernet Protocol (RFC 2516) for the DSL broadband service deployment. Suppose a few hosts are connected to each other by Ethernet. When a user wants to connect to his ISP through DSL. Consider the following: host --- PPPoE ---> xDSL modem --- PPPoE over ATM over xDSL ---> DSLAM In this scenario, xDSL modem bridges the PPPoE frame. Depending on where DSLAM is connected to, the PPPoE is terminated at LAC or LNS or other devices when they are deployed for this purpose. To save the argument, let's assume DSLAM terminates PPPoE. Now does it actually mean that DSLAM (or LNS/LAC if they terminate PPPoE) has an Ethernet MAC address? Intuitively, they don't have a MAC address. If they don't, how do they respond to PPPoE Active Discovery Initiation packet PADI? If they do, is it really necessary? Your comments are appreciated. Renwei Li Abatis Systems Corporation 4190-200 Still Creek Drive Burnaby, B.C. Canada V5C 6C6 Phone: (604) 918-4706 Fax: (604) 294-8830 Email: rli@abatis-sys.com Web: www.abatis-sys.com From owner-ietf-ppp-outgoing@merit.edu Tue May 23 17:05:41 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 RAA09688 for ; Tue, 23 May 2000 17:05:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0ABD45DDC1; Tue, 23 May 2000 17:05:16 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DCEC65DDC3; Tue, 23 May 2000 17:05:15 -0400 (EDT) Received: from cliff.extant.net (cliff.extant.net [12.17.197.35]) by segue.merit.edu (Postfix) with ESMTP id 238C65DDC1 for ; Tue, 23 May 2000 17:05:14 -0400 (EDT) Received: from karl.extant.net (mojo.extant.net [216.28.121.14]) by cliff.extant.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KD1WP09H; Tue, 23 May 2000 15:05:11 -0600 Message-Id: <4.3.2.6.2.20000523170238.04a318e0@127.0.0.1> X-Sender: kfox@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2.6 (Beta) Date: Tue, 23 May 2000 17:05:09 -0400 To: "Li, Renwei" , "'ietf-ppp@merit.edu'" From: Karl Fox Subject: Re: PPP over Ethernet In-Reply-To: <811670B03A7DD211A2730008C709C20959F478@daystrom.abatissys. com> 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 Hello, PPP over Ethernet discussions belong on mailing lists maintained by the PPP over Ethernet people. This mailing list is for discussing work associated with the PPP Extensions Working Group of the IETF. We have nothing to do with PPPOE. Thanks, Karl At 03:01 PM 5/23/00, Li, Renwei wrote: >This is a question about the termination point in the PPP over Ethernet >Protocol (RFC 2516) for the DSL broadband service deployment. > >Suppose a few hosts are connected to each other by Ethernet. When a user >wants to connect to his ISP through DSL. Consider the following: > >host --- PPPoE ---> xDSL modem --- PPPoE over ATM over xDSL ---> DSLAM > >In this scenario, xDSL modem bridges the PPPoE frame. Depending on where >DSLAM is connected to, the PPPoE is terminated at LAC or LNS or other >devices when they are deployed for this purpose. To save the argument, let's >assume DSLAM terminates PPPoE. Now does it actually mean that DSLAM (or >LNS/LAC if they terminate PPPoE) has an Ethernet MAC address? Intuitively, >they don't have a MAC address. If they don't, how do they respond to PPPoE >Active Discovery Initiation packet PADI? If they do, is it really necessary? > >Your comments are appreciated. > >Renwei Li >Abatis Systems Corporation >4190-200 Still Creek Drive >Burnaby, B.C. >Canada V5C 6C6 >Phone: (604) 918-4706 >Fax: (604) 294-8830 >Email: rli@abatis-sys.com >Web: www.abatis-sys.com Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Wed May 24 02:48: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 CAA00213 for ; Wed, 24 May 2000 02:48:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 78C175DDE0; Wed, 24 May 2000 02:45:47 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6559C5DDDC; Wed, 24 May 2000 02:45:47 -0400 (EDT) Received: from smtp.mail.yahoo.com (smtp.mail.yahoo.com [128.11.68.32]) by segue.merit.edu (Postfix) with SMTP id 746A45DDBC for ; Wed, 24 May 2000 02:45:44 -0400 (EDT) Received: from ppp-203-197-9-201.bom.vsnl.net.in (HELO muralidharan) (203.197.9.201) by smtp.mail.yahoo.com with SMTP; 23 May 2000 23:45:38 -0700 X-Apparently-From: Message-ID: <001d01bfc54b$dfd8a700$1000a8c0@muralidharan> Reply-To: "R. Muralidharan" From: "R. Muralidharan" To: "Langner, Paul (Paul)" , References: <15A2D77655CDD1118B5500805F6FE87A0587EDAD@pai820exch002u.micro.lucent.com> Subject: Re: PPP in PoS Date: Wed, 24 May 2000 12:16:58 +0530 Organization: OSS Systems (India) Pvt Ltd/IEEE Bombay section MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hi Paul, If the network elements implementing PoS (Packet Over SONET as per RFC 2615) do not make use of LCP/NCP, how do they tackle the following: 1) Connection breaks and the subsequent starts 2) Dynamic provisioning commands such as Bandwidth on demand etc (probably network elements are Managed ones) which might need LCP/NCP or is it that these are not needed 3) Link monitoring parameters acquisition (if LCP and associated packets are not recognized) TIA muralidharan ----- Original Message ----- From: Langner, Paul (Paul) To: ; Sent: Wednesday, May 24, 2000 1:06 AM Subject: RE: PPP in PoS > Many implementations don't - especially the first ones. A lot of it is > because the link is turned on once, and everything else is provisioned. > > > ---------- > > From: milind@ossc.ossc.com[SMTP:milind@ossc.ossc.com] > > Sent: Tuesday, May 23, 2000 2:50 PM > > To: ietf-ppp@merit.edu > > Subject: PPP in PoS > > > > Hello All, > > > > A SONET network element implementing IP Over SONET normally uses HDLC > > framing and PPP protocol. > > Do this network element has to implement LCP part of PPP also ? > > > > Regards, > > Milind > > > > __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-ietf-ppp-outgoing@merit.edu Wed May 24 08:12: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 IAA04201 for ; Wed, 24 May 2000 08:12:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7DE095DDE1; Wed, 24 May 2000 08:12:21 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6B3715DDBC; Wed, 24 May 2000 08:12:21 -0400 (EDT) Received: from h006008986325.ne.mediaone.net (h006008986325.ne.mediaone.net [24.218.16.153]) by segue.merit.edu (Postfix) with ESMTP id D05C45DDA0 for ; Wed, 24 May 2000 08:12:19 -0400 (EDT) Received: (from carlson@localhost) by h006008986325.ne.mediaone.net (8.9.3/8.9.3) id IAA27022; Wed, 24 May 2000 08:12:14 -0400 From: James Carlson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14635.50974.607142.241522@h006008986325.ne.mediaone.net> Date: Wed, 24 May 2000 08:12:14 -0400 (EDT) To: "Langner, Paul (Paul)" Cc: ietf-ppp@merit.edu, "'milind@ossc.ossc.com'" Subject: RE: PPP in PoS In-Reply-To: Langner, Paul (Paul)'s message of 23 May 2000 15:36:02 References: <15A2D77655CDD1118B5500805F6FE87A0587EDAD@pai820exch002u.micro.lucent.com> X-Mailer: VM 6.75 under Emacs 20.6.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Langner, Paul (Paul) writes: > Many implementations don't - especially the first ones. A lot of it is > because the link is turned on once, and everything else is provisioned. This is known as "prior arrangement." Basically, consenting peers can do anything at all that they like. None of the standard implementations of IP over SONET that I've used omit LCP or IPCP, though. I'd be fairly surprised if someone could actually ship a product broken in that manner today. -- James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Wed May 24 12:58: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 MAA08986 for ; Wed, 24 May 2000 12:58:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B6DDF5DDF6; Wed, 24 May 2000 12:58:22 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A174E5DDF2; Wed, 24 May 2000 12:58:22 -0400 (EDT) Received: from fs-sd-exch2.coppermountain.com (unknown [209.246.224.234]) by segue.merit.edu (Postfix) with ESMTP id C8F4A5DDCB for ; Wed, 24 May 2000 12:58:20 -0400 (EDT) Received: by mail.coppermountain.com with Internet Mail Service (5.5.2650.21) id ; Wed, 24 May 2000 10:00:28 -0700 Message-ID: <9FFFAB5D74FFD31191EA00D0B74178C80CCDE1@mail.coppermountain.com> From: Bonnie Hutchings To: ietf-ppp@merit.edu Subject: PPP protocol field compression Date: Wed, 24 May 2000 10:00:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu RFC-1973 describes an encapsulated PPP frame format without protocol field compression as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | Flag (0x7e) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Q.922 Address | Control | NLPID(0xcf) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PPP Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Then it describes protocol field compression as follows: Protocol-Field-Compression Note that unlike PPP in HDLC-like framing, the Frame Relay framing does not align the Information field on a 32-bit boundary. Alignment to a 32-bit boundary occurs when the NLPID is removed and the Protocol field is compressed to a single octet. When this improves throughput, Protocol-Field-Compression SHOULD be negotiated. So does a protocol-compressed frame look like this (call it example 1)?: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | Flag (0x7e) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Q.922 Address | Control | PPP Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Or does it look like this (example 2): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | Flag (0x7e) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Q.922 Address | Control | NLPID(0xcf) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PPP Protocol | +-+-+-+-+-+-+-+-+ Example 1 seems to conform to 'the NLPID is removed and the Protocol field is compressed to a single octet', but not to 'Alignment to a 32-bit boundary' whereas in Example 2, the NLPID has not been removed, but the PPP payload is 32-bit aligned. Can anyone clarify this for me? Thanks, Bonnie From owner-ietf-ppp-outgoing@merit.edu Wed May 24 13:18: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 NAA09379 for ; Wed, 24 May 2000 13:18:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EE99F5DDF2; Wed, 24 May 2000 13:15:31 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 791785DE04; Wed, 24 May 2000 13:15:31 -0400 (EDT) Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by segue.merit.edu (Postfix) with ESMTP id 8DF5A5DDCB for ; Wed, 24 May 2000 13:15:29 -0400 (EDT) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id KAA53507; Wed, 24 May 2000 10:15:28 -0700 (PDT) From: Archie Cobbs Message-Id: <200005241715.KAA53507@bubba.whistle.com> Subject: Re: PPP protocol field compression In-Reply-To: <9FFFAB5D74FFD31191EA00D0B74178C80CCDE1@mail.coppermountain.com> from Bonnie Hutchings at "May 24, 2000 10:00:27 am" To: bhutchings@coppermountain.com (Bonnie Hutchings) Date: Wed, 24 May 2000 10:15:28 -0700 (PDT) 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 Bonnie Hutchings writes: > So does a protocol-compressed frame look like this (call it example 1)?: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+ > | Flag (0x7e) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Q.922 Address | Control | PPP Protocol | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Or does it look like this (example 2): > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+ > | Flag (0x7e) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Q.922 Address | Control | NLPID(0xcf) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PPP Protocol | > +-+-+-+-+-+-+-+-+ > > Example 1 seems to conform to 'the NLPID is removed and the Protocol field > is compressed to a single octet', but not to 'Alignment to a 32-bit > boundary' whereas in Example 2, the NLPID has not been removed, but the PPP > payload is 32-bit aligned. Can anyone clarify this for me? I believe example 1 is what is intended. Example 1 *is* aligned to a 32-bit boundary: there are four data bytes. The "flag byte" is not really a byte, but a repeated bit pattern on the synchronous line for which there is no "alignment" because there is no data... it's just inter-frame fill. The Q.922 address is the beginning of the data. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-ietf-ppp-outgoing@merit.edu Wed May 24 13:40:46 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 NAA09822 for ; Wed, 24 May 2000 13:40:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6EF205DE7F; Wed, 24 May 2000 13:39:09 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5405B5DE38; Wed, 24 May 2000 13:39:09 -0400 (EDT) Received: from fs-sd-exch2.coppermountain.com (unknown [209.246.224.234]) by segue.merit.edu (Postfix) with ESMTP id B11225DE81 for ; Wed, 24 May 2000 13:39:04 -0400 (EDT) Received: by mail.coppermountain.com with Internet Mail Service (5.5.2650.21) id ; Wed, 24 May 2000 10:41:10 -0700 Message-ID: <9FFFAB5D74FFD31191EA00D0B74178C80CCDE2@mail.coppermountain.com> From: Bonnie Hutchings To: "'Archie Cobbs'" , Bonnie Hutchings Cc: ietf-ppp@merit.edu Subject: RE: PPP protocol field compression Date: Wed, 24 May 2000 10:41:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu If example 1 is correct, it raises another question. Since 0x00cf is a valid value for the Protocol field, and compressed it is indistinguishable from the NLPID, how can intermediate forwarding devices, which are not privy to the configuration options selected for the link, distinguish between a compressed vs an uncompressed frame? It looks to me as though they can't. Is that true? Thanks, Bonnie > -----Original Message----- > From: Archie Cobbs [mailto:archie@whistle.com] > Sent: Wednesday, May 24, 2000 10:15 AM > To: bhutchings@coppermountain.com > Cc: ietf-ppp@merit.edu > Subject: Re: PPP protocol field compression > > > Bonnie Hutchings writes: > > So does a protocol-compressed frame look like this (call it > example 1)?: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+ > > | Flag (0x7e) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Q.922 Address | Control | PPP Protocol | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Or does it look like this (example 2): > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+ > > | Flag (0x7e) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Q.922 Address | Control | NLPID(0xcf) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | PPP Protocol | > > +-+-+-+-+-+-+-+-+ > > > > Example 1 seems to conform to 'the NLPID is removed and the > Protocol field > > is compressed to a single octet', but not to 'Alignment to a 32-bit > > boundary' whereas in Example 2, the NLPID has not been > removed, but the PPP > > payload is 32-bit aligned. Can anyone clarify this for me? > > I believe example 1 is what is intended. Example 1 *is* aligned to > a 32-bit boundary: there are four data bytes. The "flag byte" is > not really a byte, but a repeated bit pattern on the synchronous > line for which there is no "alignment" because there is no data... > it's just inter-frame fill. The Q.922 address is the beginning of > the data. > > -Archie > > ______________________________________________________________ > _____________ > Archie Cobbs * Whistle Communications, Inc. * > http://www.whistle.com > From owner-ietf-ppp-outgoing@merit.edu Wed May 24 13:47:41 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 NAA09906 for ; Wed, 24 May 2000 13:47:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 86B465DE25; Wed, 24 May 2000 13:45:23 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 710715DE35; Wed, 24 May 2000 13:45:22 -0400 (EDT) Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by segue.merit.edu (Postfix) with ESMTP id B00375DE25 for ; Wed, 24 May 2000 13:45:16 -0400 (EDT) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id KAA54638; Wed, 24 May 2000 10:45:15 -0700 (PDT) From: Archie Cobbs Message-Id: <200005241745.KAA54638@bubba.whistle.com> Subject: Re: PPP protocol field compression In-Reply-To: <9FFFAB5D74FFD31191EA00D0B74178C80CCDE2@mail.coppermountain.com> from Bonnie Hutchings at "May 24, 2000 10:41:09 am" To: bhutchings@coppermountain.com (Bonnie Hutchings) Date: Wed, 24 May 2000 10:45:15 -0700 (PDT) Cc: archie@whistle.com ('Archie Cobbs'), 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 Bonnie Hutchings writes: > If example 1 is correct, it raises another question. Since 0x00cf is a > valid value for the Protocol field, and compressed it is indistinguishable > from the NLPID, how can intermediate forwarding devices, which are not privy > to the configuration options selected for the link, distinguish between a > compressed vs an uncompressed frame? It looks to me as though they can't. > Is that true? Why would they care? If they see 0x00cf, it's a PPP frame no matter what. In addition, from the RFC: Currently, there are no conflicts between NLPID and PPP Protocol values. If a future implementation is configured to send a NLPID value which is the same as a compressed Protocol field, that Protocol field MUST NOT be sent compressed. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-ietf-ppp-outgoing@merit.edu Thu May 25 14:49: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 OAA17719 for ; Thu, 25 May 2000 14:49:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E55835DE57; Thu, 25 May 2000 14:46:42 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 922655DE56; Thu, 25 May 2000 14:46:39 -0400 (EDT) Received: from ossc.ossc.com (oss-gw-pm3.pcnet.net [206.105.29.20]) by segue.merit.edu (Postfix) with SMTP id B65BF5DE26 for ; Thu, 25 May 2000 14:46:28 -0400 (EDT) Received: from raj.ossc.com by ossc.ossc.com (AIX 3.2/UCB 5.64/4.03) id AA11614; Thu, 25 May 2000 14:38:42 -0400 From: milind@ossc.ossc.com (Milind Kulkarni) Message-Id: <014101bfc678$18a98040$11f2f9cc@ossc.com> To: Subject: Wide band PoS Date: Thu, 25 May 2000 14:36:08 -0400 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013E_01BFC656.90D44220" X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This is a multi-part message in MIME format. ------=_NextPart_000_013E_01BFC656.90D44220 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello All, Are there any standards/RFCs/drafts available for 'Wide-band Packet Over = SONET' technology ? This is a new term to me. The Cisco's ONS 15303 product datasheet refers = this implementation. Regards, Milind ------=_NextPart_000_013E_01BFC656.90D44220 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello All,
 
Are there any standards/RFCs/drafts = available=20 for 'Wide-band Packet Over SONET' technology ?
This is a new term to me. The Cisco's ONS 15303 product datasheet = refers this=20 implementation.
 
Regards,
Milind
 
 
------=_NextPart_000_013E_01BFC656.90D44220-- From owner-ietf-ppp-outgoing@merit.edu Thu May 25 15:51: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 PAA19147 for ; Thu, 25 May 2000 15:51:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A494B5DDDF; Thu, 25 May 2000 15:50:51 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8B3035DDDB; Thu, 25 May 2000 15:50:51 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id 5ED635DDDF for ; Thu, 25 May 2000 15:50:49 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA16352; Thu, 25 May 2000 13:50:44 -0600 (MDT) Received: from dhcp-174-233.east.sun.com (dhcp-174-233.East.Sun.COM [129.148.174.233]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA21520; Thu, 25 May 2000 15:50:43 -0400 (EDT) Received: (from carlsonj@localhost) by dhcp-174-233.east.sun.com (8.9.3+Sun/8.9.3) id PAA02590; Thu, 25 May 2000 15:50:42 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14637.33809.832655.187482@gargle.gargle.HOWL> Date: Thu, 25 May 2000 15:50:41 -0400 (EDT) From: James Carlson To: milind@ossc.ossc.com (Milind Kulkarni) Cc: Subject: Re: Wide band PoS In-Reply-To: Milind Kulkarni's message of 25 May 2000 14:36:08 References: <014101bfc678$18a98040$11f2f9cc@ossc.com> X-Mailer: VM 6.75 under Emacs 20.6.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Milind Kulkarni writes: > Are there any standards/RFCs/drafts available for 'Wide-band Packet Over SONET' technology ? > This is a new term to me. The Cisco's ONS 15303 product datasheet > refers this implementation. Looks like marketing stuff. There's a terse description of the "wideband" aspects here: http://www.cisco.com/warp/public/cc/cisco/mkt/optical/optrans/prodlit/15303_ds.htm It appears to mean that you can channelize the SONET/SDH interfaces down to VT1.5 instead of dedicating an entire STS-n for a PPP link. If that's all it entails, then it's not actually covered by any RFCs. It would be in ITU-T documents, if any. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Fri May 26 15: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 PAA23631 for ; Fri, 26 May 2000 15:34:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 123585DE29; Fri, 26 May 2000 15:32:55 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F003A5DE28; Fri, 26 May 2000 15:32:54 -0400 (EDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by segue.merit.edu (Postfix) with ESMTP id 9103E5DD9F for ; Fri, 26 May 2000 15:32:53 -0400 (EDT) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA308568 for ; Fri, 26 May 2000 15:31:08 -0400 Received: from TROUBLE (DIP005899END.endicott.ibm.com [9.130.69.192]) by northrelay01.pok.ibm.com (8.8.8m3/NCO v2.07) with SMTP id PAA210428 for ; Fri, 26 May 2000 15:32:50 -0400 Message-ID: <003001bfc749$40b3abc0$c0458209@endicott.ibm.com> From: "John R. Martz" To: Subject: picking an MRRU for MP Date: Fri, 26 May 2000 15:32:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Folks, Would appreciate getting opinions/advice on how to select the Multilink Protocol MRRU value to offer for negotiation to the remote peer. I'm not sure I'm considering all the pros and cons involved. I also have next to no experience with the choices made by other PPP-MP implementations for the MRRU. I see that when negotiating MP over a single link, Windows 2000 Professional uses the default MRU value of 1500 and specifies an MRRU of 1614. Anyone know ... or want to speculate ... on why 1614 would be chosen for the MRRU. The more I think about this the more I lean towards making the MRRU choice a customer configuration choice. That way I can blame it on the customer if the chosen value is "bad". -john martz IBM AS/400 TCP/IP PPP (and stuff) From owner-ietf-ppp-outgoing@merit.edu Fri May 26 15:41: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 PAA23746 for ; Fri, 26 May 2000 15:41:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1B75A5DE16; Fri, 26 May 2000 15:41:28 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 099FC5DE0A; Fri, 26 May 2000 15:41:28 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 407365DD9F for ; Fri, 26 May 2000 15:41:26 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA13211; Fri, 26 May 2000 12:41:23 -0700 (PDT) Received: from dhcp-174-233.east.sun.com (dhcp-174-233.East.Sun.COM [129.148.174.233]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA12550; Fri, 26 May 2000 15:41:22 -0400 (EDT) Received: (from carlsonj@localhost) by dhcp-174-233.east.sun.com (8.9.3+Sun/8.9.3) id PAA07899; Fri, 26 May 2000 15:41:21 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14638.54113.478233.783827@gargle.gargle.HOWL> Date: Fri, 26 May 2000 15:41:21 -0400 (EDT) From: James Carlson To: "John R. Martz" Cc: Subject: Re: picking an MRRU for MP In-Reply-To: John R. Martz's message of 26 May 2000 15:32:38 References: <003001bfc749$40b3abc0$c0458209@endicott.ibm.com> X-Mailer: VM 6.75 under Emacs 20.6.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit John R. Martz writes: > Would appreciate getting opinions/advice on how to select the > Multilink Protocol MRRU value to offer for negotiation to the remote > peer. I'm not sure I'm considering all the pros and cons involved. As long as you do the negotiation correctly and you allow the user to configure desired values, it's hard to see how you can go too terribly wrong here. > I also have next to no experience with the choices made by other > PPP-MP implementations for the MRRU. I see that when negotiating MP > over a single link, Windows 2000 Professional uses the default MRU > value of 1500 and specifies an MRRU of 1614. Anyone know ... or want > to speculate ... on why 1614 would be chosen for the MRRU. 1524 is a very common MRRU among MP implementations. I've also seen 1540 on a few others. 1614 is rather special, and I don't see a particular reason for it. > The more I think about this the more I lean towards making the MRRU > choice a customer configuration choice. That way I can blame it on > the customer if the chosen value is "bad". Yep. Of course, you'll still want *some* kind of default. Since MP is most often used with ISDN, and since the compression protocols commonly used on ISDN (primarily STAC) can also expand by a few bytes, it's probably a good idea to set the default to 1500 (the world's IP MTU ;-}) plus a few bytes. 1524 would be an unsurprising number. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Fri May 26 17:37:08 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 RAA26602 for ; Fri, 26 May 2000 17:37:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EF61F5DDBB; Fri, 26 May 2000 17:36:42 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DDD1F5DDA5; Fri, 26 May 2000 17:36:42 -0400 (EDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by segue.merit.edu (Postfix) with ESMTP id 903195DD9C for ; Fri, 26 May 2000 17:36:41 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA132116 for ; Fri, 26 May 2000 17:34:56 -0400 From: jmartz@us.ibm.com Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.9) with SMTP id RAA45244 for ; Fri, 26 May 2000 17:36:39 -0400 Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568EB.0076AF2E ; Fri, 26 May 2000 17:36:20 -0400 X-Lotus-FromDomain: IBMUS To: ietf-ppp@merit.edu Message-ID: <852568EB.0076ADA4.00@D51MTA04.pok.ibm.com> Date: Fri, 26 May 2000 17:36:16 -0400 Subject: Re: picking an MRRU for MP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu James, > As long as you do the negotiation correctly and you allow the user > to configure desired values, it's hard to see how you can go too > terribly wrong here. What I failed to state clearly in my previous note is that currently I was NOT going to allow the user to configure the MRRU value directly. I'd prefer not to throw "yet another" configuration choice at our customers unless I see a compelling reason the customer needs to choose. And so far, I just don't see this. I would prefer that the code choose a "good" value for the MRRU. Probably based on the configured MRU values for the links that could be bundled together so that the customer's settings for the MRU gets reflected into the MRRU. Currently the code sets the MRRU equal to the MRU of the first link in the bundle "plus a few 10's of bytes". The feeling I'm getting is that choice is probably consistent with the typical settings of other PPP-MP implementations. Yes? No? Maybe? -john martz, 8-852-5539, jmartz@us.ibm.com IBM AS/400 TCP/IP PPP development (and stuff) From owner-ietf-ppp-outgoing@merit.edu Fri May 26 19:41:12 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 TAA27974 for ; Fri, 26 May 2000 19:41:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CEF8C5DDA5; Fri, 26 May 2000 19:40:43 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B4ABE5DDBD; Fri, 26 May 2000 19:40:43 -0400 (EDT) Received: from h006008986325.ne.mediaone.net (h006008986325.ne.mediaone.net [24.218.16.153]) by segue.merit.edu (Postfix) with ESMTP id 184B95DDA5 for ; Fri, 26 May 2000 19:40:42 -0400 (EDT) Received: (from carlson@localhost) by h006008986325.ne.mediaone.net (8.9.3/8.9.3) id TAA18810; Thu, 26 May 1994 19:40:35 -0400 From: James Carlson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <11749.13171.48210.578976@h006008986325.ne.mediaone.net> Date: Thu, 26 May 1994 19:40:35 -0400 (EDT) To: jmartz@us.ibm.com Cc: ietf-ppp@merit.edu Subject: Re: picking an MRRU for MP In-Reply-To: jmartz@us.ibm.com's message of 26 May 2000 17:36:16 References: <852568EB.0076ADA4.00@D51MTA04.pok.ibm.com> X-Mailer: VM 6.75 under Emacs 20.6.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit jmartz@us.ibm.com writes: > What I failed to state clearly in my previous note is that currently I was > NOT going to allow the user to configure the MRRU value directly. I'd > prefer not to throw "yet another" configuration choice at our customers > unless I see a compelling reason the customer needs to choose. And so far, > I just don't see this. If all that you're supporting is low-speed (async and sync dial-up) links, I guess that wouldn't cause too much trouble. I agree that the customer shouldn't *have* to choose. That's what default values are for. As a general matter, I absolutely hate software that thinks it knows better than I about what I need to do in all cases. Hide the option in a "for experts only" menu if you must, but omitting configuration variables entirely in the name of ease-of-use is (in my opinion) simply wrong. AIX is after all Unix, not Windows. ;-} (And, for what it's worth, AIX is the OS I'm using at home ...) In other words, the metric shouldn't be a compelling reason to choose -- it should be a compelling reason to be *unable* to choose. > I would prefer that the code choose a "good" value for the MRRU. Probably > based on the configured MRU values for the links that could be bundled > together so that the customer's settings for the MRU gets reflected into > the MRRU. ? There's no particularly good relationship between MRU and MRRU that I think you can use here. MRRU on MP links is basically the IP MTU. The MRU is hidden by MP and constitutes the maximum fragment size. > Currently the code sets the MRRU equal to the MRU of the first link in the > bundle "plus a few 10's of bytes". The feeling I'm getting is that choice > is probably consistent with the typical settings of other PPP-MP > implementations. Yes? No? Maybe? Possibly so. That's certainly not true in any of the implementations I've worked on, but I can see how such a thing could happen ... -- James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Sat May 27 09:33:42 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 JAA17734 for ; Sat, 27 May 2000 09:33:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 648075DDAF; Sat, 27 May 2000 09:31:10 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 491365DDCC; Sat, 27 May 2000 09:31:10 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id 75D6E5DDAF for ; Sat, 27 May 2000 09:31:08 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id HAA03302 for ietf-ppp@merit.edu env-from ; Sat, 27 May 2000 07:31:07 -0600 (MDT) Date: Sat, 27 May 2000 07:31:07 -0600 (MDT) From: Vernon Schryver Message-Id: <200005271331.HAA03302@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: picking an MRRU for MP Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: James Carlson > ... > > I would prefer that the code choose a "good" value for the MRRU. Probably > > based on the configured MRU values for the links that could be bundled > > together so that the customer's settings for the MRU gets reflected into > > the MRRU. I don't think you can escape that easily. Yes, an arbitrary value is ok for your initial Configure Request, but how do you respond to values in Configure Nak's or Configure Requests from the peer? How do you know whether to ignore or go along with a Nak, send a Nak in response to a Configure Request, or refuse to bring the link up? I think you must compute what your code is willing to receive (perhaps limited above by your buffering machinery) and what it needs to send (perhaps limited below by what you PPP code has already told the upper layers about IP, whether you're doing bridging, and what you hope do do with ECP and CCP). > ? There's no particularly good relationship between MRU and MRRU that > I think you can use here. MRRU on MP links is basically the IP MTU. > The MRU is hidden by MP and constitutes the maximum fragment size. > ... Yes, except that the MRRU must be large enough to hold any PPP overhead plus an IP MTU or if you're bridging, an Ethernet (or other) datagram. The PPP overhead I'm thinking of is for CCP, ECP, and probably something else. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Mon May 29 10:59:04 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 KAA00854 for ; Mon, 29 May 2000 10:59:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6438D5DDC6; Mon, 29 May 2000 10:58:33 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 52AD35DDC5; Mon, 29 May 2000 10:58:33 -0400 (EDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by segue.merit.edu (Postfix) with ESMTP id DCD285DD9D for ; Mon, 29 May 2000 10:58:31 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA94282 for ; Mon, 29 May 2000 10:56:45 -0400 From: jmartz@us.ibm.com Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.9) with SMTP id KAA167894 for ; Mon, 29 May 2000 10:58:29 -0400 Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568EE.00523E9D ; Mon, 29 May 2000 10:58:19 -0400 X-Lotus-FromDomain: IBMUS To: ietf-ppp@merit.edu Message-ID: <852568EE.00523E1C.00@D51MTA04.pok.ibm.com> Date: Mon, 29 May 2000 10:58:20 -0400 Subject: Re: picking an MRRU for MP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu James, > As a general matter, I absolutely hate software that > thinks it knows better than I about what I need to do > in all cases. > ... AIX is after all Unix, not Windows. ;-} Yes, I agree in principal with what you're saying. But speaking for myself, I often have trouble locating the correct design balance point. Hence this note requesting feedback about choosing the MRRU. As AIX is not Windows, it also true that the AS/400 ... the platform I'm working for ... is definitely not AIX. there is a history and (I think) a strong customer preference on the AS/400 for a *CALC configuration parameter. A cynical explanation of *CALC might be: "I don't know. I don't care. I just want this frickin' thing to work because it is just a means to an end that I have not reached yet. Machine, YOU figure it out and stop irritating me!" This is the option I'd prefer to provide my customers. However, your comments do have me reconsidering exposing the MRRU as a customer configuration value. But I still feel that all this does is toss my ignore about the MRRU over the fence into the lap of an even more confused customer. And just what is the point of that? When and why would someone using MP want to choose a MRRU value larger than, say, 1524 bytes (or so)? And, most important to me: Does this reason apply to my customers? The type of physical links we could bundle together won't be much different that what Windows can do: aynch (or synch) modem over a phone line and basic rate ISDN. Given this context, is it really a benefit to a customer to flog s/he with another configuration choice? Or is the way Windows does it sufficient enough to be preferable? -john martz, 8-852-5539, jmartz@us.ibm.com IBM AS/400 TCP/IP PPP development (and stuff) From owner-ietf-ppp-outgoing@merit.edu Mon May 29 11:46: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 LAA01125 for ; Mon, 29 May 2000 11:46:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C7D855DDD5; Mon, 29 May 2000 11:45:21 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B54CC5DDCA; Mon, 29 May 2000 11:45:21 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id DEFDD5DDC5 for ; Mon, 29 May 2000 11:45:19 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id JAA23414 for ietf-ppp@merit.edu env-from ; Mon, 29 May 2000 09:45:19 -0600 (MDT) Date: Mon, 29 May 2000 09:45:19 -0600 (MDT) From: Vernon Schryver Message-Id: <200005291545.JAA23414@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: picking an MRRU for MP Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: jmartz@us.ibm.com > ... > When and why would someone using MP want to choose a MRRU value larger > than, say, 1524 bytes (or so)? And, most important to me: Does this reason > apply to my customers? ... I think a important questions are: 1. How is the IP MTU for your PPP link computed? 2. How is the TCP MSS computed? In a typical UNIX box, the IP MTU is the related to the MTU of the so called network interface. For example, if the network interface has a physical MTU of 1518, but has a 14 byte header and 4 byte trailer, then the typical UNIX system will use an IP MTU of 1500. If the interface has an MTU of 1524 (obtained from a PPP peer's MRRU value in its Configure-Request) but it is using CCP over instead of below MP, then the IP MTU will be about 1518 (assuming no special considerations). In many UNIX boxes the TCP MSS is computed from the IP MTU and. For example, ignoring complications such as TCP-LW, if the IP MTU is 1500, then the negotiated TCP MSS will be 1460. If of the two TCP peers' IP MTU is 1518, then it is likely to ask for a TCP MSS of 1478. In some boxes, the requested TCP MSS for all TCP connections even on Ethernets. Most BSD dervived TCP/IP implements cannot understand a network interface with an IP MTU that changes. At best, you must turn down the interface to let IP know that the interface's MTU has changed, and that can have distinct unpleasant effects on applications. What does your code do when CCP is negotiated after LCP? Does it renege on the initial IP MTU negotiated and reported to the IP code? What happens if the CCP scheme negotiated changes? Slogging through the "IP fragmentation considered harmful," "PMTU Discovery," "blackholes," etc. swamps would need 1000's more words. So let's just say on many systems, an IP MTU that changes or that is not one of the familiar values is distinctly undesirable. So what does your code do when it encounters a PPP peer that wants a strange PPP MRRU, MTRU, MRU, or MTU? If you just go along with the peer, you'll need to worry about those swamps. If you don't, your customers will probably find some lame PPP peers that won't work with your code. Thus, what choice do you have except well chosen default values and knobs controlling the values for emergency use? Vernon Schryver vjs@rhyolite.com