From ietf-ppp-request@ucdavis.ucdavis.edu Thu Oct 1 10:43:34 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25860; Thu, 1 Oct 92 10:36:24 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA18343; Thu, 1 Oct 92 09:14:42 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22608; Thu, 1 Oct 92 08:59:49 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from xap.xyplex.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19406; Thu, 1 Oct 92 06:55:34 -0700 Received: from sgw.xyplex.com by xap.xyplex.com id ; Thu, 1 Oct 92 09:31:18 -0500 Received: by sgw.xyplex.com (4.1/SMI-4.1) id AA16672; Thu, 1 Oct 92 09:35:08 EDT Date: Thu, 1 Oct 92 09:35:08 EDT From: sgw@sgw.xyplex.com (Scott Wasson) Message-Id: <9210011335.AA16672@sgw.xyplex.com> To: bill.simpson@um.cc.umich.edu, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: IPXCP Status The "no IPXWAN" option is clever, but not really useful unless you *do* support IPXWAN, and want to ignore it. Bill.Simpson@um.cc.umich.edu Actually, it might be rather useful: if an implementation has some form of PPP event logging (to a file or buffer, let's say), then the fact that the "IPXWAN compatability option" never converges would be highly enlightening -- it would tell you WHY it is that IPXCP opened, but the link isn't sending or receiving any useful data. It means one partner supports IPXWAN, requires the option "ON" or flat out rejects negotiation of that option (default assumed "ON"), and the other partner doesn't support IPXWAN, therefore requiring negotiation of that option to "OFF". The option will never help these two guys converge, but at least it gives you a clue as to why they can't talk. -----Scott Wasson------ Internetworking & Media Xyplex Boxborough, MA (508) 264-9901 x369 sgwasson@eng.xyplex.com ----------------------- From ietf-ppp-request@ucdavis.ucdavis.edu Thu Oct 1 17:12:37 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07436; Thu, 1 Oct 92 16:33:10 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA24015; Thu, 1 Oct 92 14:10:27 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02455; Thu, 1 Oct 92 14:03:45 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02240; Thu, 1 Oct 92 13:57:28 -0700 Received: from na.novell.com (na.SJF.Novell.COM) by newsun.novell.com with SMTP id AA07557 (5.65c/IDA-1.4.4 for ); Thu, 1 Oct 1992 13:57:05 -0700 Received: by na.novell.com (4.1/SMI-4.1) id AA25948; Thu, 1 Oct 92 14:00:17 PDT Date: Thu, 1 Oct 92 14:00:17 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9210012100.AA25948@na.novell.com> To: bill.simpson@um.cc.umich.edu, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: IPXCP Status Hi Y'all, > From: "William Allen Simpson" > > Thank you all for your status messages. Most enlightening. > > As far as I can tell, everyone wants IPXCP, and only Novell and Telebit > are supporting IPXWAN. Nobody is shipping any IPXCP options, but Telebit > and Shiva are ready (in beta). Novell can't talk to anyone else but > Telebit, even with static configuration. We have quite a few more direct confirmations that other companies WILL support IPXWAN. We encourage all vendors not to miss the boat. If you need help in IPXWAN development, or help in getting your executives and marketing folk to 'see the light', let us know. > The "no IPXWAN" option is clever, but not really useful unless you *do* > support IPXWAN, and want to ignore it. I strongly disagree. If two devices FAIL to converge, you would have to infer why from more than one source of information. With this option, you will have a definitive indication. Scott Wasson seems to agree. > I identified (with help from Bert@Shiva and Saroop@Telebit) a set of > required parameters. If they haven't been configured or negotiated, > then fall thru into IPXWAN. > > Now, I need implementors to look carefully at the spec (particularly > net and node numbers) and give some feedback (to the list). Please add back the NO IPXWAN option. More comments may follow. > Bill.Simpson@um.cc.umich.edu Thanks Bill. Another quality protocol spec... Chris Ranch > From: sgw@sgw.xyplex.com (Scott Wasson) > > The "no IPXWAN" option is clever, but not really useful unless you > *do* support IPXWAN, and want to ignore it. > > Bill.Simpson@um.cc.umich.edu > > Actually, it might be rather useful: if an implementation has some form of > PPP event logging (to a file or buffer, let's say), then the fact that the > "IPXWAN compatability option" never converges would be highly enlightening > -- it would tell you WHY it is that IPXCP opened, but the link isn't > sending or receiving any useful data. It means one partner supports IPXWAN, > requires the option "ON" or flat out rejects negotiation of that option > (default assumed "ON"), and the other partner doesn't support IPXWAN, > therefore requiring negotiation of that option to "OFF". The option will > never help these two guys converge, but at least it gives you a clue as to > why they can't talk. --- Chris Ranch Internetworking Products Division Novell, Inc. San Jose, CA (408)473-8667 cranch@novell.com I may work for Novell, but I don't speak for them... From ietf-ppp-request@ucdavis.ucdavis.edu Thu Oct 1 19:02:05 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11841; Thu, 1 Oct 92 18:58:53 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27730; Thu, 1 Oct 92 18:40:10 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11195; Thu, 1 Oct 92 18:35:02 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from alpha.Xerox.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10967; Thu, 1 Oct 92 18:28:20 -0700 Received: from avalon.parc.xerox.com ([13.1.101.241]) by alpha.xerox.com with SMTP id <11672>; Thu, 1 Oct 1992 18:27:30 PDT Received: by avalon.parc.xerox.com id <2439>; Thu, 1 Oct 1992 18:27:24 -0700 From: Mark Verber To: ietf-ppp@ucdavis.ucdavis.edu Subject: ppp for bridging Message-Id: <92Oct1.182724pdt.2439@avalon.parc.xerox.com> Date: Thu, 1 Oct 1992 18:27:18 PDT I am not on the IETF-PPP working group, but I am interested in what is the current state of PPP extensions for bridging. The most recent thing I found was the draft dated Dec 1990. Is there anything more current, and has anyone been working on maintaining message sequencing over multiple links? My primary interest is bridging ethernets over basic rate ISDN using both B channels. My IP protocol stack copes just fine with missequenced packets, but some of the other protocols don't cope as gracefully. The solution right now is running a hacked HDLC protocol with sequencing. We would rather be speaking a protocol someone else might use (eg ppp+bridging extensions). To head off any possible flames... yes I agree, bridging is evil. Unfortunately we still have need of XNS, PUP (gasp!), and a few other protocol stacks across these links. Even if XNS was the only protocol other than IP we had to worry about, it is not clear that it would make sense to implementing XNS over PPP since I am hoping that XNS will eventually goes away. Producing an implementation of XNS over PPP might unduly encourage people to continue to use XNS. --mark verber xerox parc From ietf-ppp-request@ucdavis.ucdavis.edu Fri Oct 2 07:42:39 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04122; Fri, 2 Oct 92 07:38:32 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA03280; Fri, 2 Oct 92 07:19:13 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03054; Fri, 2 Oct 92 07:04:04 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from nsco.network.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00578; Fri, 2 Oct 92 05:55:57 -0700 Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA26393; Fri, 2 Oct 92 07:55:12 -0500 Received: from zebo.network.com by anubis.network.com (4.1/SMI-4.1) id AA01903; Fri, 2 Oct 92 07:51:37 CDT Date: Fri, 2 Oct 92 07:51:37 CDT From: muchow@anubis.network.com (Jim Muchow) Message-Id: <9210021251.AA01903@anubis.network.com> Received: by zebo.network.com (4.1/SMI-4.1) id AA00261; Fri, 2 Oct 92 07:51:37 CDT To: verber@parc.xerox.com Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Mark Verber's message of Thu, 1 Oct 1992 18:27:18 PDT <92Oct1.182724pdt.2439@avalon.parc.xerox.com> Subject: ppp for bridging From: Mark Verber Date: Thu, 1 Oct 1992 18:27:18 PDT will eventually goes away. Producing an implementation of XNS over PPP might unduly encourage people to continue to use XNS. Too late. Unless you mean producing an "official" implementation of XNS. Jim Muchow - at fault From ietf-ppp-request@ucdavis.ucdavis.edu Fri Oct 2 08:57:19 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05439; Fri, 2 Oct 92 08:28:08 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA03546; Fri, 2 Oct 92 07:50:08 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04174; Fri, 2 Oct 92 07:41:15 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03933; Fri, 2 Oct 92 07:30:32 -0700 Received: from sjfsmtp.novell.com (ss.Corp.SJF.Novell.COM) by newsun.novell.com with SMTP id AA03475 (5.65c/IDA-1.4.4 for <@newsun.Novell.COM:ietf-ppp@ucdavis.edu>); Fri, 2 Oct 1992 07:30:11 -0700 Message-Id: <199210021430.AA03475@newsun.novell.com> From: MALLEN%sjfsmtp@novell.com (MALLEN) To: ietf-ppp@ucdavis.ucdavis.edu (X) Subject: IPXCP & Telebit Compression Date: Thu, 01 Oct 92 15:25 I have just digested the latest IPXCP draft (Sept 92) - looks good. I was of the understanding that the compression option (for Telebit) had the number of compression slots negotiated (an extra byte after the flags). I also was of the impression that length fields were NOT going to be included as the link levels were always able to determine the packet length - they need to know where the end of the packet is don't they? Michael Allen Novell Inc. From ietf-ppp-request@ucdavis.ucdavis.edu Fri Oct 2 11:27:46 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09622; Fri, 2 Oct 92 10:47:12 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05550; Fri, 2 Oct 92 10:01:39 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07858; Fri, 2 Oct 92 09:52:55 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from FENNEL.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07533; Fri, 2 Oct 92 09:42:34 -0700 Received: by fennel.acc.com (4.1/SMI-4.1) id AA07411; Fri, 2 Oct 92 09:42:30 PDT Date: Fri, 2 Oct 92 09:42:30 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9210021642.AA07411@fennel.acc.com> To: ietf-ppp@ucdavis.ucdavis.edu, verber@parc.xerox.com Subject: Re: ppp for bridging There is some work going on about multi-link PPP, which I have stalled on for lack of time. Soon. The draft you read is now RFC 1220. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Fri Oct 2 11:28:26 1992 Received: from [128.120.2.9] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09800; Fri, 2 Oct 92 10:53:39 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05671; Fri, 2 Oct 92 10:12:00 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08322; Fri, 2 Oct 92 10:08:10 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from alpha.Xerox.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08055; Fri, 2 Oct 92 10:00:01 -0700 Received: from dnsmaster.cinops.xerox.com ([13.252.44.4]) by alpha.xerox.com with SMTP id <11715>; Fri, 2 Oct 1992 09:59:28 PDT Received: from secundus.cinops.xerox.com by dnsmaster.cinops.xerox.com (4.1/SMI-4.1) id AA10572; Fri, 2 Oct 92 12:59:27 EDT Date: Fri, 2 Oct 1992 09:59:27 PDT From: eer@cinops.xerox.com (Edwards Reed) Message-Id: <9210021659.AA10572@dnsmaster.cinops.xerox.com> To: muchow@anubis.network.com, verber@parc.xerox.com Subject: Re: ppp for bridging Cc: ietf-ppp@ucdavis.ucdavis.edu From: muchow@anubis.network.com (Jim Muchow) From: Mark Verber Date: Thu, 1 Oct 1992 18:27:18 PDT will eventually goes away. Producing an implementation of XNS over PPP might unduly encourage people to continue to use XNS. Too late. Unless you mean producing an "official" implementation of XNS. Jim Muchow - at fault Jim - does that mean you have an 'unofficial' version? I know IBM does. I've an interest in talking to folks doing such things...are you one, or do you know of some? Ed From ietf-ppp-request@ucdavis.ucdavis.edu Fri Oct 2 17:02:34 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20749; Fri, 2 Oct 92 16:57:03 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09282; Fri, 2 Oct 92 15:00:31 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17040; Fri, 2 Oct 92 14:51:38 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16676; Fri, 2 Oct 92 14:40:02 -0700 Received: from napa.TELEBIT.COM by apache (4.1/SMI-4.1/Telebit-Apache-Brent-920708) id AA19386 to ietf-ppp@ucdavis.edu; Fri, 2 Oct 92 14:39:38 PDT Received: from yoyo.telebit.com by napa.TELEBIT.COM (4.1/napa.telebit.com-Brent-920717) id AA12169 to ietf-ppp@ucdavis.edu; Fri, 2 Oct 92 14:39:35 PDT Date: Fri, 2 Oct 92 14:39:35 PDT From: mlewis@napa.Telebit.COM (Mark S. Lewis) Message-Id: <9210022139.AA12169@napa.TELEBIT.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA28070; Fri, 2 Oct 92 14:39:56 PDT To: MALLEN%sjfsmtp@novell.com Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <199210021430.AA03475@newsun.novell.com> "MALLEN%sjfsmtp@novell.com" Subject: IPXCP & Telebit Compression > I have just digested the latest IPXCP draft (Sept 92) - looks good. > I was of the understanding that the compression option (for Telebit) had > the number of > compression slots negotiated (an extra byte after the flags). > I also was of the impression that length fields were NOT going to be > included as the link > levels were always able to determine the packet length - they need to know > where the end > of the packet is don't they? > Michael Allen > Novell Inc. Thanks Michael for pointing this out. I was just going thru it. You're correct. The IPXCP-Compression-Protocol option for Telebit (CIPX) is a 6 byte option that includes the requested number of slots. The IPXCP description should look something like this: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Length = 6 | CIPX = 0x0002 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Slots | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CIPX PPP COMPRESSION OPTION We prefer the term "Options" to the slightly less descriptive term "Flags". ... Mark =========----------- Mark S. Lewis -----------========== inet: mlewis@telebit.com Telebit Corp. Telebit (408) 745-3232 uucp: uunet!telebit!mlewis Fax (408) 745-3810 From ietf-ppp-request@ucdavis.ucdavis.edu Fri Oct 2 17:02:45 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20801; Fri, 2 Oct 92 16:58:56 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09387; Fri, 2 Oct 92 15:13:37 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17568; Fri, 2 Oct 92 15:09:31 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17036; Fri, 2 Oct 92 14:51:32 -0700 Received: from napa.TELEBIT.COM by apache (4.1/SMI-4.1/Telebit-Apache-Brent-920708) id AA19664 to ietf-ppp@ucdavis.edu; Fri, 2 Oct 92 14:51:00 PDT Received: from yoyo.telebit.com by napa.TELEBIT.COM (4.1/napa.telebit.com-Brent-920717) id AA12416 to bill.simpson@um.cc.umich.edu; Fri, 2 Oct 92 14:50:58 PDT Date: Fri, 2 Oct 92 14:50:58 PDT From: mlewis@napa.Telebit.COM (Mark S. Lewis) Message-Id: <9210022150.AA12416@napa.TELEBIT.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA28125; Fri, 2 Oct 92 14:51:20 PDT To: cranch@novell.com Cc: bill.simpson@um.cc.umich.edu, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <9210012100.AA25948@na.novell.com> "cranch@novell.com" Subject: IPXCP Status > Hi Y'all, >> From: "William Allen Simpson" >> >> I identified (with help from Bert@Shiva and Saroop@Telebit) a set of >> required parameters. If they haven't been configured or negotiated, >> then fall thru into IPXWAN. >> >> Now, I need implementors to look carefully at the spec (particularly >> net and node numbers) and give some feedback (to the list). > Please add back the NO IPXWAN option. More comments may follow. > Thanks Bill. Another quality protocol spec... > Chris Ranch > I would like to suggest a slightly different approach on this option. Seems like it would be more clear to have an "IPXCP-Only" option. Basically reverse the orientation of this option. This would be helpful to implementation that support IPXCP only and not IPXWAN. These implementations could request this option and clearly inform the other side that they don't do IPXWAN. Otherwise, implementations that do both may have to wait to timeout on IPXWAN timer requests to figure it out. ... Mark =========----------- Mark S. Lewis -----------========== inet: mlewis@telebit.com Telebit Corp. Telebit (408) 745-3232 uucp: uunet!telebit!mlewis Fax (408) 745-3810 From ietf-ppp-request@ucdavis.ucdavis.edu Fri Oct 2 18:08:32 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22655; Fri, 2 Oct 92 17:56:22 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA10871; Fri, 2 Oct 92 17:12:01 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20925; Fri, 2 Oct 92 17:01:00 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [130.57.4.1] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20627; Fri, 2 Oct 92 16:52:45 -0700 Received: from na.novell.com (na.SJF.Novell.COM) by newsun.novell.com with SMTP id AA13126 (5.65c/IDA-1.4.4 for ); Fri, 2 Oct 1992 16:51:44 -0700 Received: by na.novell.com (4.1/SMI-4.1) id AA08977; Fri, 2 Oct 92 16:54:55 PDT Date: Fri, 2 Oct 92 16:54:55 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9210022354.AA08977@na.novell.com> To: cranch@novell.com, mlewis@telebit.com Subject: Re: IPXCP Status Cc: bill.simpson@um.cc.umich.edu, ietf-ppp@ucdavis.ucdavis.edu Hi Mark, > From: mlewis@napa.Telebit.COM (Mark S. Lewis) > > > > Please add back the NO IPXWAN option. More comments may follow. > > > > Chris Ranch > > I would like to suggest a slightly different approach on this option. > Seems like it would be more clear to have an "IPXCP-Only" option. > Basically reverse the orientation of this option. > > This would be helpful to implementation that support IPXCP only and > not IPXWAN. These implementations could request this option and > clearly inform the other side that they don't do IPXWAN. Otherwise, > implementations that do both may have to wait to timeout on IPXWAN > timer requests to figure it out. > > ... Mark I thought this is functionally what we have been talking about. IPXCP-Only is equivalent to NO IPXWAN, right? Sounds like another vote for it, but by a different name. I don't care which is used. Under listed options, IPXWAN will still be listed as the default higer-layer behavior option, and IPXCP only (or NO IPXWAN) would be another option. Having this option would avoid the morass of deciding what to do when IPXWAN times out. Should it then close IPXCP? What about retries? Looking at MIBs, what would you see? IPXCP will be closed, but why? Look in the IPXWAN MIB, and see that it timed out? Who's going to teach a management console to be this smart? This option makes management nice and clean. Or am I suffering from sleep deprivation? Chris From ietf-ppp-request@ucdavis.ucdavis.edu Sat Oct 3 10:10:29 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18026; Sat, 3 Oct 92 10:05:20 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA14485; Sat, 3 Oct 92 09:39:55 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17063; Sat, 3 Oct 92 09:30:27 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from fear.demon.co.uk by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16567; Sat, 3 Oct 92 09:20:32 -0700 Date: Sat, 03 Oct 92 16:12:59 GMT Message-Id: <930@fear.demon.co.uk> From: ben@fear.demon.co.uk (Ben Laurie) To: ietf-ppp@ucdavis.ucdavis.edu Subject: Does the peer know best? Lines: 43 X-Mailer: PCElm 3.01 (1.3 gt) Hi, I've been using and implementing PPP for a while now, and one thing that keeps nagging at me is the assumption that the peer knows best (about LCP options). While this seems generally true, it doesn't seem right for the MRU. Consider a public access system with multistandard modems. People dialling in with low speed (V22, V22bis) modems want small packets to improve turnaround times in Telnet and the like. People on high speed modems would probably prefer larger packets, especially if they are using a standard which is only high speed in one direction, so line turnarounds are to be minimised (eg Courier HST). Now, so long as one end (normally the end that isn't the public access system) knows what packet size it needs, all is well. Even if the other end is uncooperative (refuses to negotiate the correct MRU), its MRU can be rejected (giving the default of 1500) and whatever size is desired can be sent (up to 1500 bytes, of course). The real snag comes when you look at the MIBs. There just isn't an option to set the remote MRU. I suppose it could be argued that the local MRU is a good candidate for the remote MRU, but that wouldn't work if the comms were asymmetric for some reason. What do people think? Ben. ================================================== Ben Laurie Tel: +44 (81) 994 6435 Fax: +44 (81) 994 6472 ben@fear.demon.co.uk 100014.1235@compuserve.com Technical Director, AL Systems Technical Consultant, AL Downloading Services Network Manager, AL Publishing Services Consultant Systems Programmer, Troy Systems Ltd. [Note for the paranoid: "fear" as in "Fear and Loathing in Las Vegas", "demon" as in Demon Internet Services, a public access Internet service] From ietf-ppp-request@ucdavis.ucdavis.edu Sat Oct 3 13:01:39 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22805; Sat, 3 Oct 92 12:51:01 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA14997; Sat, 3 Oct 92 12:30:11 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22013; Sat, 3 Oct 92 12:22:28 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21917; Sat, 3 Oct 92 12:19:00 -0700 Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA07697; Sat, 3 Oct 92 12:18:29 -0700 Date: Sat, 3 Oct 92 14:02:45 EDT From: "William Allen Simpson" Message-Id: <791.bill.simpson@um.cc.umich.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: IPXCP Status > From: mlewis@napa.Telebit.COM (Mark S. Lewis) > I would like to suggest a slightly different approach on this option. > Seems like it would be more clear to have an "IPXCP-Only" option. > Basically reverse the orientation of this option. > > This would be helpful to implementation that support IPXCP only and > not IPXWAN. These implementations could request this option and > clearly inform the other side that they don't do IPXWAN. Otherwise, > implementations that do both may have to wait to timeout on IPXWAN > timer requests to figure it out. > Good suggestion. I think a good name might be "Configuration-Complete", to indicate that no more configuration is required, other than the options listed. That way, even hand-configured systems could make use of it. This would also be helpful to implementations that support IPX-WAN, for faster setup time. Option #6, 2 octet boolean. How fast can you implement and test it, Mark? Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Sat Oct 3 13:11:20 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23075; Sat, 3 Oct 92 13:01:35 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA15011; Sat, 3 Oct 92 12:34:21 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22017; Sat, 3 Oct 92 12:22:33 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21922; Sat, 3 Oct 92 12:19:08 -0700 Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA07700; Sat, 3 Oct 92 12:18:38 -0700 Date: Sat, 3 Oct 92 14:10:40 EDT From: "William Allen Simpson" Message-Id: <792.bill.simpson@um.cc.umich.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: IPXCP & Telebit Compression > From: mlewis@napa.Telebit.COM (Mark S. Lewis) > The IPXCP description should look something like this: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 3 | Length = 6 | CIPX = 0x0002 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Options | Slots | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > We prefer the term "Options" to the slightly less descriptive term > "Flags". > OK, let's make it like the IPCP compression format then: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max-Slot-Id | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ What about Michael Allen's suggestion about removing the length option entirely? Why can't that be handled by a bit in the compressed header? Or should we require the self-describing-pad option? Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Mon Oct 5 10:10:31 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29174; Mon, 5 Oct 92 08:49:49 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA23578; Mon, 5 Oct 92 08:20:11 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27487; Mon, 5 Oct 92 08:11:39 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from xap.xyplex.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27196; Mon, 5 Oct 92 08:05:09 -0700 Received: from sgw.xyplex.com by xap.xyplex.com id ; Mon, 5 Oct 92 11:02:54 -0500 Received: by sgw.xyplex.com (4.1/SMI-4.1) id AA20996; Mon, 5 Oct 92 11:06:53 EDT Date: Mon, 5 Oct 92 11:06:53 EDT From: sgw@sgw.xyplex.com (Scott Wasson) Message-Id: <9210051506.AA20996@sgw.xyplex.com> To: bill.simpson@um.cc.umich.edu, cranch@novell.com, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: IPXCP Status Chris: Sounds like another vote for it, but by a different name. I don't care which is used. Under listed options, IPXWAN will still be listed as the default higer-layer behavior option, and IPXCP only (or NO IPXWAN) would be another option. Having this option would avoid the morass of deciding what to do when IPXWAN times out. Should it then close IPXCP? What about retries? Looking at MIBs, what would you see? IPXCP will be closed, but why? Look in the IPXWAN MIB, and see that it timed out? Who's going to teach a management console to be this smart? This option makes management nice and clean. Sounds good to me. Bill: This would also be helpful to implementations that support IPX-WAN, for faster setup time. You lost me. Please explain. -----Scott Wasson------ Internetworking & Media Xyplex Boxborough, MA (508) 264-9901 x369 sgwasson@eng.xyplex.com ----------------------- From ietf-ppp-request@ucdavis.ucdavis.edu Mon Oct 5 16:39:21 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20765; Mon, 5 Oct 92 16:28:15 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA28780; Mon, 5 Oct 92 14:31:34 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14560; Mon, 5 Oct 92 14:27:01 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from CAYMAN.CAYMAN.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13957; Mon, 5 Oct 92 14:14:52 -0700 Received: by cayman.Cayman.COM (4.1/SMI-4.0) id AA15004; Mon, 5 Oct 92 17:14:25 EDT Received: from stemwinder by stemwinder.fcr.com (4.1/SMI-4.1) id AA14689; Mon, 5 Oct 92 17:08:30 EDT Message-Id: <9210052108.AA14689@stemwinder.fcr.com> To: cranch@novell.com Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: IPXCP Status In-Reply-To: Mail from novell.com!cranch@cayman.Cayman.COM (Christopher Ranch) dated Wed, 23 Sep 92 16:45:07 PDT <9209232345.AA29097@na.novell.com> Date: Mon, 05 Oct 92 17:08:29 -0400 From: Brad Parker I'll probably be struck by lightning for saying this, (but that never stopped me before ;-) >> > From: sgw@sgw.xyplex.com (Scott Wasson) >> > >> > We have implemented and shipped IPXCP without options, and without IPXWAN. >> >> I hope you are aware that you will not interoperate with the >> NetWare MultiProtocol Router v2.0 without IPXWAN. So? This is not neccessarly such a huge sin. It just means you can't talk to a netware server which is acting as a router. Many folks don't want their servers to be routers (oh no, now I've gone and done it) >> > We have the IPXWAN spec and are reviewing it for merit, but we're waiting >> > for a statement of direction from the IETF. >> >> Well, we have not (yet ;) delegated to the IETF the design of IPX >> and related protocols, namely IPXWAN. It appears you are waiting >> for a statement from 'the IETF', which is really the PPP-EXT WG, >> on whether YOU should interoperate with NetWare. That sounds more >> like a question for your marketing folks. And this is a good reason why IPXCP can be a win. (it has no marketing folks ;-) >> > Personally I'd like to see >> > options in IPXCP, one of which is to negotiate to do IPXWAN. me too. >> > Thus an >> > implementation which has no options (including no IPXWAN) will be fully >> > interoperable with one that does. >> >> Not quite. You left out NetWare as being interoperable. The >> bottom line is: if your implementation has no options, you >> MUST do IPXWAN (unless you can convince your marketing folk >> that you don't need to interoperate with NetWare). I think we're confusing "interoperability with a netware server acting as a router" and "interoperability with a router implementing an IETF RFC". I might choose to implement IPXWAN for marketing reasons. However, I see nothing wrong with a vanilla IPXCP implementation which does not do IPXWAN and works just fine with itself and anyone else who implements the freely available and un-marketing-encumbered RFC. ( yowza. I just had to say that... ) Please don't take this as a beligerent flame. I like the idea of an independant CP for IPX which is in the spirit of all the other CP's. If Novell wants to add extensions to it to support their own protocols, great, but making IPXCP bow to IPXWAN seems like the tail wagging the dog. (uh oh. I can hear the rumbling of the clouds outside ;-) -brad From ietf-ppp-request@ucdavis.ucdavis.edu Mon Oct 5 18:51:33 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27218; Mon, 5 Oct 92 18:41:12 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA29630; Mon, 5 Oct 92 15:40:04 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17961; Mon, 5 Oct 92 15:32:25 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17354; Mon, 5 Oct 92 15:20:56 -0700 Received: from na.novell.com (na.SJF.Novell.COM) by newsun.novell.com with SMTP id AA08301 (5.65c/IDA-1.4.4 for ); Mon, 5 Oct 1992 15:20:21 -0700 Received: by na.novell.com (4.1/SMI-4.1) id AA26558; Mon, 5 Oct 92 15:23:34 PDT Date: Mon, 5 Oct 92 15:23:34 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9210052223.AA26558@na.novell.com> To: brad@fcr.com, cranch@novell.com Subject: Re: IPXCP Status Cc: ietf-ppp@ucdavis.ucdavis.edu Hi Brad, > From: Brad Parker > > I'll probably be struck by lightning for saying this, (but that never stopped > me before ;-) That's RED lightning to you! :-) > >> > From: sgw@sgw.xyplex.com (Scott Wasson) > >> > > >> > We have implement and shipped IPXCP without options, and without IPXWAN. > >> > >> I hope you are aware that you will not interoperate with the > >> NetWare MultiProtocol Router v2.0 without IPXWAN. > > So? This is not neccessarly such a huge sin. It just means you can't talk > to a netware server which is acting as a router. Many folks don't want > their servers to be routers (oh no, now I've gone and done it) We're selling the router stuff (no services) for $995 list. We're having fun articulating to customers when to do one over the other. My brain thinks it's simple, but telling this to customers is a little more challenging... Many people want cheap routers. Also with all of their server folks trained on NetWare, to them NetWare routers looks cheap and effective. > >> > We have the IPXWAN spc and are reviewing it for merit, but we're waiting > >> > for a statement of direction from the IETF. > >> > >> Well, we have not (yet ;) delegated to the IETF the design of IPX > >> and related protocols, namely IPXWAN. It appears you are waiting > >> for a statement from 'the IETF', which is really the PPP-EXT WG, > >> on whether YOU should interoperate with NetWare. That sounds more > >> like a question for your marketing folks. > > And this is a good reason why IPXCP can be a win. (it has no marketing > folks ;-) Well, remember that Novell will not be supporting IPXCP options for the forseeable future. As engineers, we can make 'pure' products all we want to. But the bottom line is product sales. Do you want to tell your marketing folk or your customers that your IPX product will not work in an NetWare enviromnent? (I know that last line may have gone a hair too far, but Brad used a simley too ;-). > >> > Personally I'd like to see > >> > options in IPXCP, one of which is to negotiate to do IPXWAN. > > me too. One more vote! I like Bill's latest suggestion of a 'done configuration' option. Handles manual configuration/IPXCP convergence too. > >> > Thus an > >> > implementation which has no options (including no IPXWAN) will be fully > >> > interoperable with one that does. > >> > >> Not quite. You left out NetWare as being interoperable. The > >> bottom line is: if your implementation has no options, you > >> MUST do IPXWAN (unless you can convince your marketing folk > >> that you don't need to interoperate with NetWare). > > I think we're confusing "interoperability with a netware server acting > as a router" and "interoperability with a router implementing an IETF > RFC". > > I might choose to implement IPXWAN for marketing reasons. However, I > see nothing wrong with a vanilla IPXCP implementation which does not > do IPXWAN and works just fine with itself and anyone else who implements > the freely available and un-marketing-encumbered RFC. > > ( yowza. I just had to say that... ) > > Please don't take this as a beligerent flame. I like the idea of an > independant CP for IPX which is in the spirit of all the other CP's. > If Novell wants to add extensions to it to support their own > protocols, great, but making IPXCP bow to IPXWAN seems like the tail > wagging the dog. > > (uh oh. I can hear the rumbling of the clouds outside ;-) Hmmm, nice and sunny here... What's the tail, and what's the dog? I read your statment to be IPXWAN/Novell is wagging the IETF and Internet Protocols. Our view is the IETF is trying to wag Novell and IPX. We're trying to 'play ball' (Brian's quote), and tell y'all how we do IPX over various WAN media, including PPP. So we did. My evaluation of the design vis a vis the spirit of PPP and NCPs, does not and will not change anything (I think you know me well enough to guess right :). At this point, I'm (we're) trying to encourage third party interoper- ability with NetWare, and monitor the IPXCP work to make sure nothing gets broken (at least the current architecture) for future compatibility. Your faithful IPXWAN nag, Chris Ranch From ietf-ppp-request@ucdavis.ucdavis.edu Mon Oct 5 21:31:45 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03071; Mon, 5 Oct 92 21:26:40 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA02740; Mon, 5 Oct 92 21:10:26 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02028; Mon, 5 Oct 92 21:02:37 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from wolf.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01747; Mon, 5 Oct 92 20:58:06 -0700 Received: from lager.cisco.com by wolf.cisco.com with TCP; Mon, 5 Oct 92 20:55:58 -0700 Message-Id: <9210060355.AA16223@wolf.cisco.com> To: fbaker@acc.com (Fred Baker), cranch@novell.com (Christopher Ranch) Cc: bert@Shiva.COM, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: IPXCP & IPXWAN In-Reply-To: Your message of "Thu, 24 Sep 92 16:21:15 PDT." <9209242321.AA03335@saffron.acc.com> Date: Mon, 05 Oct 92 20:55:56 PDT From: Jim Forster I realize this is a bit late, but... >> We too are using a null NCP for IPX, and would like to implement a >> standard PPP NCP with certain features. We don't find IPXWAN to be >> architecturally attractive, and would far rather implement its features >> in the NCP proper. I agree. >> And we would agree that PPP standard behavior is that a system with a >> NULL NCP and appropriate configuration is always acceptable link >> behavior. This is the crux of the issue. I believe that its important that all PPP implementations work with null NCP's. Chris, all your points about Novell market share, etc., are true, but no PPP spec says one MUST support IPXWAN. If Novell can't work with conforming implementations, then you shouldn't claim PPP interoperability. -- Jim From ietf-ppp-request@ucdavis.ucdavis.edu Mon Oct 5 22:32:22 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05566; Mon, 5 Oct 92 22:25:53 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA03106; Mon, 5 Oct 92 22:12:01 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04695; Mon, 5 Oct 92 22:03:48 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04399; Mon, 5 Oct 92 21:58:03 -0700 Received: from harry.lloyd.com. by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA14718; Mon, 5 Oct 92 21:54:50 PDT Date: Mon, 5 Oct 92 21:54:50 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9210060454.AA14718@ray.lloyd.com> Received: by harry.lloyd.com. (4.1/SMI-4.1) id AA02724; Mon, 5 Oct 92 21:54:49 PDT To: brad@fcr.com Cc: cranch@novell.com, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Brad Parker's message of Mon, 05 Oct 92 17:08:29 -0400 <9210052108.AA14689@stemwinder.fcr.com> Subject: IPXCP Status There appears to be a great deal of talking re IPXCP vs IPXWAN. While I personally prefer the IPXCP approach, if I were building a product that routes IPX I sure as hell would support IPXWAN since the marketroid in me thinks that my potential market would be larger if I support IPXWAN. I went over to Novell and whopped them up the side of the head (verbally) until they agreed to produce the IPXWAN document. A null IPXCP and IPXWAN is sufficient to enable IPX routing and to interoperate with Novell's current and probably future products. So let's get on with the real question here: will IPXCP with options provide a superset of capability over a null IPXCP and IPXWAN? If the answer is no, punt the options. If the answer is yes, proceed with the options. You then get to decide whether or not to implement the extra options. Let's not get into what feels "right" (gee, Novell *should* do things our way). Let's get this complete and put to bed. There are people out there wishing to create products and this moving target is a pain in their collective fanny. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 fax (916) 676-3442 From ietf-ppp-request@ucdavis.ucdavis.edu Tue Oct 6 13:15:46 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01323; Tue, 6 Oct 92 13:00:59 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08478; Tue, 6 Oct 92 10:43:50 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25924; Tue, 6 Oct 92 10:34:51 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [130.57.4.1] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25701; Tue, 6 Oct 92 10:29:58 -0700 Received: from na.novell.com (na.SJF.Novell.COM) by newsun.novell.com with SMTP id AA00203 (5.65c/IDA-1.4.4 for ); Tue, 6 Oct 1992 10:29:04 -0700 Received: by na.novell.com (4.1/SMI-4.1) id AA06727; Tue, 6 Oct 92 10:32:17 PDT Date: Tue, 6 Oct 92 10:32:17 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9210061732.AA06727@na.novell.com> To: brad@fcr.com, brian@lloyd.com Subject: Re: IPXCP Status Cc: cranch@novell.com, ietf-ppp@ucdavis.ucdavis.edu Hi Brian, Jim, Bill, Brad, et al, > From: brian@lloyd.com (Brian Lloyd) > > There appears to be a great deal of talking re IPXCP vs IPXWAN. While > I personally prefer the IPXCP approach, if I were building a product > that routes IPX I sure as hell would support IPXWAN since the > marketroid in me thinks that my potential market would be larger if I > support IPXWAN. > > So let's get on with the real question here: will IPXCP with options > provide a superset of capability over a null IPXCP and IPXWAN? If the > answer is no, punt the options. If the answer is yes, proceed with > the options. You then get to decide whether or not to implement the > extra options. Thanks, Brian, I couldn't have said it better. Chris From ietf-ppp-request@ucdavis.ucdavis.edu Wed Oct 7 13:08:07 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18160; Wed, 7 Oct 92 12:52:40 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA21528; Wed, 7 Oct 92 11:40:56 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15493; Wed, 7 Oct 92 11:34:39 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15141; Wed, 7 Oct 92 11:24:23 -0700 Received: from napa.TELEBIT.COM by apache (4.1/SMI-4.1/Telebit-Apache-Brent-920708) id AA11284 to ietf-ppp@ucdavis.edu; Wed, 7 Oct 92 11:23:48 PDT Received: from yoyo.telebit.com by napa.TELEBIT.COM (4.1/napa.telebit.com-Brent-920717) id AA13785 to ietf-ppp@ucdavis.edu; Wed, 7 Oct 92 11:23:46 PDT Date: Wed, 7 Oct 92 11:23:46 PDT From: mlewis@napa.Telebit.COM (Mark S. Lewis) Message-Id: <9210071823.AA13785@napa.TELEBIT.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA27410; Wed, 7 Oct 92 11:24:10 PDT To: bill.simpson@um.cc.umich.edu Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <791.bill.simpson@um.cc.umich.edu> Subject: IPXCP Status >> From: mlewis@napa.Telebit.COM (Mark S. Lewis) >> I would like to suggest a slightly different approach on this option. >> Seems like it would be more clear to have an "IPXCP-Only" option. >> Basically reverse the orientation of this option. >> >> This would be helpful to implementation that support IPXCP only and >> not IPXWAN. These implementations could request this option and >> clearly inform the other side that they don't do IPXWAN. Otherwise, >> implementations that do both may have to wait to timeout on IPXWAN >> timer requests to figure it out. >> > Good suggestion. I think a good name might be "Configuration-Complete", > to indicate that no more configuration is required, other than the > options listed. That way, even hand-configured systems could make use > of it. > This would also be helpful to implementations that support IPX-WAN, > for faster setup time. > Option #6, 2 octet boolean. How fast can you implement and test it, Mark? > Bill.Simpson@um.cc.umich.edu After some discussion with Bill, I have grown to like this option. Just for the benefit of the rest of list, we are implementing the "Configuration-Complete" option. We will let you know if we see any problems with it. ... Mark =========----------- Mark S. Lewis -----------========== inet: mlewis@telebit.com Telebit Corp. Telebit (408) 745-3232 uucp: uunet!telebit!mlewis Fax (408) 745-3810 From ietf-ppp-request@ucdavis.ucdavis.edu Wed Oct 7 23:01:02 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07107; Wed, 7 Oct 92 22:55:51 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA28562; Wed, 7 Oct 92 22:39:59 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06505; Wed, 7 Oct 92 22:30:38 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from wolf.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06242; Wed, 7 Oct 92 22:24:10 -0700 Received: from lager.cisco.com by wolf.cisco.com with TCP; Wed, 7 Oct 92 22:23:31 -0700 Message-Id: <9210080523.AA05610@wolf.cisco.com> To: brian@lloyd.com Cc: brad@fcr.com, cranch@novell.com (Christopher Ranch), ietf-ppp@ucdavis.ucdavis.edu Subject: Re: IPXCP Status In-Reply-To: Your message of "Tue, 06 Oct 92 10:32:17 PDT." <9210061732.AA06727@na.novell.com> Date: Wed, 07 Oct 92 22:23:29 PDT From: Jim Forster OK, how 'bout this question, for Brian mostly, but I'm also interested in what others think: Does Novell get to claim compliance with the IPXCP spec if they won't interoperate with others? I'm sorry I have to dwell on this, but I do feel its important. -- Jim From ietf-ppp-request@ucdavis.ucdavis.edu Fri Oct 9 14:36:16 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29399; Fri, 9 Oct 92 14:25:31 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17112; Fri, 9 Oct 92 12:05:37 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23884; Fri, 9 Oct 92 11:45:25 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21612; Fri, 9 Oct 92 09:11:51 -0700 Received: from harry.lloyd.com. by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA17091; Fri, 9 Oct 92 09:11:16 PDT Date: Fri, 9 Oct 92 09:11:16 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9210091611.AA17091@ray.lloyd.com> Received: by harry.lloyd.com. (4.1/SMI-4.1) id AA00316; Fri, 9 Oct 92 09:11:14 PDT To: forster@cisco.com Cc: brad@fcr.com, cranch@novell.com, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Jim Forster's message of Wed, 07 Oct 92 22:23:29 PDT <9210080523.AA05610@wolf.cisco.com> Subject: IPXCP Status From: Jim Forster Does Novell get to claim compliance with the IPXCP spec if they won't interoperate with others? If Novell's implementation of LCP and IPXCP properly negotiate options (and it should if there are no errors in their state machine) then I would have to say that they are technically interoperable as far as what the IETF controls. BTW, rejecting all options is valid as I understand PPP (heck Jim, the rest of us have been living with cisco routers that reject all LCP and IPCP options for quite some time now and we consider cisco routers to be in compliance with the spec). We are in a grey area here. IPX and its routing is defined by Novell. I discussed with them at length the possibility of moving IPX into the IETF and, hence, the Internet standards track. They declined; they do not want to relinquish control of their protocol. Therefore we have no control over the specification of compliance and interoperability. That continues to rest with Novell. What I feel that I accomplished is to get Novell to publish how they do things and to promise to continue to publish information via the RFC process that will allow other vendors to know what they have to do to be interoperable. As I have stated before, I feel that this is a big step toward "openness" for them. Perhaps with time they will become comfortable with the process and become willing to allow the full IPX specification to be published as an RFC. This whole problem is an interesting one. On one hand we have a protocol stack (Netware) that is controled by one organization (Novell) using a protocol (PPP) that is controled by another (IETF). I know of no way to "force" either entity into the other's camp. Folks, you gotta work this out amongst yourselves. For the sake of the industry (and everyone's bottom line) I would recommend against the "baseball bats at two paces" method for deciding this. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 fax (916) 676-3442 From ietf-ppp-request@ucdavis.ucdavis.edu Wed Oct 14 00:50:21 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08167; Wed, 14 Oct 92 00:45:45 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA25897; Wed, 14 Oct 92 00:30:12 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07224; Wed, 14 Oct 92 00:20:18 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Shiva.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06920; Wed, 14 Oct 92 00:11:29 -0700 Received: by Shiva.COM (1.34b) Wed, 14 Oct 92 03:10:16 EDT Date: Wed, 14 Oct 92 03:10:16 EDT From: Phil Budne Message-Id: <9210140710.AA13980@Shiva.COM> To: brian@lloyd.com, forster@cisco.com Subject: Re: IPXCP Status Cc: brad@fcr.com, cranch@novell.com, ietf-ppp@ucdavis.ucdavis.edu, phil@Shiva.COM As a non-particpant in the IPXCP brouhaha (I'm not involved with either IPX or a PPP here at Shiva) it seems to me that this discussion is failing to converge. > Date: Fri, 9 Oct 92 09:11:16 PDT > From: brian@lloyd.com (Brian Lloyd) > > From: Jim Forster > > Does Novell get to claim compliance with the IPXCP spec if they won't > interoperate with others? > > If Novell's implementation of LCP and IPXCP properly negotiate options > (and it should if there are no errors in their state machine) then I > would have to say that they are technically interoperable as far as > what the IETF controls. BTW, rejecting all options is valid as I > understand PPP (heck Jim, the rest of us have been living with cisco > routers that reject all LCP and IPCP options for quite some time now > and we consider cisco routers to be in compliance with the spec). So what you are saying is that upon rejection of all options for the FOOCP one should expect to then exchange datagrams of type FOO, without further ado. This is not my understanding of Novell's current implementation. > We are in a grey area here. IPX and its routing is defined by Novell. Poppycock!! Have DEC and Apple demanded control over the definitions of the DECnet and AppleTalk NCPs? Both DEC and Apple have their own standards for async communication, neither of which are required as part of their respective NCPs. Is the default (and required) behavior in any PPP NCP (or any Internet standard for that matter) defined in terms of proprietary standards?? > What I feel that I accomplished is to get Novell to publish how they > do things and to promise to continue to publish information via the > RFC process that will allow other vendors to know what they have to do > to be interoperable. As I have stated before, I feel that this is a > big step toward "openness" for them. And I applaud both your and Novell's efforts. I'm just don't think that because a vendor takes steps towards learning how to play the game (like everyone else) that the IETF owes them any favors, PARTICULARLY when it comes to requiring use of proprietary protocols in anything called an Internet standard. This came up recently with Apple and AURP. A solution that seems both fair and technically correct is to obsolete the current IPXCP type, and assign a new one which defines, from day one, an explicit "DO IPXWAN" option which can be rejected and that all compliant implementations MUST be able to function without IPXWAN. -Phil From ietf-ppp-request@ucdavis.ucdavis.edu Wed Oct 14 07:11:04 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29780; Wed, 14 Oct 92 07:07:01 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27384; Wed, 14 Oct 92 06:49:57 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28342; Wed, 14 Oct 92 06:41:51 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28245; Wed, 14 Oct 92 06:39:54 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA20944; Wed, 14 Oct 92 06:39:06 PDT Date: Wed, 14 Oct 92 06:39:06 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9210141339.AA20944@ray.lloyd.com> To: phil@Shiva.COM Cc: forster@cisco.com, brad@fcr.com, cranch@novell.com, ietf-ppp@ucdavis.ucdavis.edu, phil@Shiva.COM In-Reply-To: Phil Budne's message of Wed, 14 Oct 92 03:10:16 EDT <9210140710.AA13980@Shiva.COM> Subject: IPXCP Status Boy am I glad that I stuck my neck out and tried for a compromise in this area. Date: Wed, 14 Oct 92 03:10:16 EDT From: Phil Budne As a non-particpant in the IPXCP brouhaha (I'm not involved with either IPX or a PPP here at Shiva) it seems to me that this discussion is failing to converge. No kidding! > Date: Fri, 9 Oct 92 09:11:16 PDT > From: brian@lloyd.com (Brian Lloyd) > > From: Jim Forster > > Does Novell get to claim compliance with the IPXCP spec if they won't > interoperate with others? > > If Novell's implementation of LCP and IPXCP properly negotiate options > (and it should if there are no errors in their state machine) then I > would have to say that they are technically interoperable as far as > what the IETF controls. BTW, rejecting all options is valid as I > understand PPP (heck Jim, the rest of us have been living with cisco > routers that reject all LCP and IPCP options for quite some time now > and we consider cisco routers to be in compliance with the spec). So what you are saying is that upon rejection of all options for the FOOCP one should expect to then exchange datagrams of type FOO, without further ado. This is not my understanding of Novell's current implementation. OK, I agree. I retract my statement. If you implement IPXCP and successfully negotiate, you should be able to send IPX d'grams back and forth. > We are in a grey area here. IPX and its routing is defined by Novell. Poppycock!! Have DEC and Apple demanded control over the definitions of the DECnet and AppleTalk NCPs? Both DEC and Apple have their own standards for async communication, neither of which are required as part of their respective NCPs. Is the default (and required) behavior in any PPP NCP (or any Internet standard for that matter) defined in terms of proprietary standards?? If everyone in this working group wishes to use IPXCP and have their product start exchanging IPX d'grams without using IPXWAN, sobeit. I agree that is most technically correct. I do NOT wish to see a document from this working group depend on a proprietary protocol and I never intended that anyone should be required to implement IPXWAN. So, if you negotiate IPXCP, even without options, you should be able to start throwing IPX d'grams across the link at the conclusion of the NCP negotiation phase. Good. I agree. [sarcasm mode on] Novell, put your hands on the edge of the desk. [I pull out a good, old-fashioned wooden ruler and whack them on the knuckles ] Chris Ranch will now tell us that Novell Corporate is thoroughly chastened. But, wait! What's this? You still need to do IPXWAN to be interoperable with Netware? Whatever is this world coming to! Heck, on principal I sure wouldn't do IPXWAN. It isn't technically pure! I am sure that your marketing and sales deparments (you know, the guys who actually bring the money into your respective companies; you know, the money that probably pays your way to attend IETF) will rest easy now knowing that your implementation, e.g. IPXCP without IPXWAN support, is technically pure and rightous. Being technically pure is more important than sales. I am sure that, deep down in their hearts, they understand that. [sarcasm mode off] So think about this: it really doesn't matter whether or not we think Novell is or isn't interoperable, does it. The facts of life right now are: if you want to interoperate with Novell's Netware, you must do IPXWAN. Period, end-of-report. It makes no difference whether or not they are right, wrong, red, or green. [flame mode on] I want an IPXCP document and I want it in time for it to be approved by the working group before IETF, DC (next month)! I really don't give a rat's fanny whether or not anyone in this group thinks that Novell is right or wrong. As far as I am concerned the IPXCP document does not need any options. Negoitate all the options off and IPX d'grams should flow. It is up to your respective marketing departments as to whether or not your implementation needs to do IPXWAN. So quit this bellyaching and finish the document. [flame mode off] Bill Simpson: is your document describing IPXCP ready for approval by the working group? If not, please finish it. If so, say so and put out the last-call within the WG. I wish to move it to last-call within the IETF. I want to thank everybody for their work on creating this convergence document. Let's finish it up and put it behind us. We need to get to work on inverse multiplexing and compression. Brian Lloyd, President B.P. Lloyd & Associates, Inc. brian@lloyd.com 3420 Sudbury Road (916) 676-1147 - voice Cameron Park, CA 95682 (916) 676-3442 - fax From ietf-ppp-request@ucdavis.ucdavis.edu Wed Oct 14 12:06:04 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14187; Wed, 14 Oct 92 11:56:24 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01225; Wed, 14 Oct 92 10:50:00 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11531; Wed, 14 Oct 92 10:43:52 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [130.57.4.1] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10864; Wed, 14 Oct 92 10:23:48 -0700 Received: from na.novell.com (na.SJF.Novell.COM) by newsun.Novell.COM (4.1/SMI-4.1) id AA02291; Wed, 14 Oct 92 10:22:57 PDT Received: by na.novell.com (4.1/SMI-4.1) id AA07560; Wed, 14 Oct 92 10:26:11 PDT Date: Wed, 14 Oct 92 10:26:11 PDT From: Christopher_Ranch@Novell.COM (Christopher Ranch) Message-Id: <9210141726.AA07560@na.novell.com> To: brian@lloyd.com, forster@cisco.com, phil@Shiva.COM Subject: Re: IPXCP Status Cc: brad@fcr.com, cranch@Novell.COM, ietf-ppp@ucdavis.ucdavis.edu Hi Y'all, > From: Phil Budne > > So what you are saying is that upon rejection of all options for the > FOOCP one should expect to then exchange datagrams of type FOO, > without further ado. This is not my understanding of Novell's current > implementation. That's right. IPX itself has the additional requirement of IPXWAN, and IPXWAN really are IPX datagrams. > > We are in a grey area here. IPX and its routing is defined by Novell. > > Poppycock!! Have DEC and Apple demanded control over the definitions > of the DECnet and AppleTalk NCPs? Both DEC and Apple have their own > standards for async communication, neither of which are required as > part of their respective NCPs. This almost sounds like you think Apple and DEC have turned over their network layers to the IETF. I know you know this isn't so. Novell still has IPX, and we have defined a means of routing over _any_ WAN link. This all boils down to where you draw the line. We're willing to draw it above IETF protocols. IPX and associated protocols are on and above that line. > Is the default (and required) behavior in any PPP NCP (or any Internet > standard for that matter) defined in terms of proprietary standards?? OSI handles network layer parameters above this level; it also requires no options. Naturally, the network layer convergence is a subsequent, separate step. Decnet does the same thing. So do we. We're tired of being the scapegoat. Can we just get on with working on the problem at hand? Bill and Brian have both asked it, and all we can bicker about is who owns what and protocol purity (this is not intended to start another debate about PPP and it's various CP's transcending several layers). We think a 'Config Done'/'No IPXWAN' option adds value to PPP that IPXWAN cannot, and this is only for network management's debugging purposes. So, Bill, we look forward to the immenent conclusion of the IPX over PPP saga. Chris and Michael. From ietf-ppp-request@ucdavis.ucdavis.edu Thu Oct 15 08:50:40 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28575; Thu, 15 Oct 92 08:40:47 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11896; Thu, 15 Oct 92 08:10:01 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27104; Thu, 15 Oct 92 08:00:46 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26715; Thu, 15 Oct 92 07:50:14 -0700 Received: from harry.lloyd.com. by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA00426; Thu, 15 Oct 92 07:49:37 PDT Date: Thu, 15 Oct 92 07:49:37 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9210151449.AA00426@ray.lloyd.com> Received: by harry.lloyd.com. (4.1/SMI-4.1) id AA01323; Thu, 15 Oct 92 07:49:37 PDT To: ietf-ppp@ucdavis.ucdavis.edu Subject: Attendence in Amsterdam I have been requested to submit a tally of people likely to attend the IETF meeting in Amsterdam. How many of you think that you will be going to Amsterdam and need to meet to discuss PPP related issues? Right now I am not expecting to have a WG meeting in Amsterdam. Brian Lloyd, President B.P. Lloyd & Associates, Inc. brian@lloyd.com 3420 Sudbury Road (916) 676-1147 - voice Cameron Park, CA 95682 (916) 676-3442 - fax From ietf-ppp-request@ucdavis.ucdavis.edu Sun Oct 18 18:40:46 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10448; Sun, 18 Oct 92 18:35:55 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA12628; Sun, 18 Oct 92 18:20:19 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09306; Sun, 18 Oct 92 18:11:02 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08979; Sun, 18 Oct 92 18:03:19 -0700 Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA26658; Sun, 18 Oct 92 17:39:10 -0700 Date: Sun, 18 Oct 92 19:51:12 EDT From: "William Allen Simpson" Message-Id: <823.bill.simpson@um.cc.umich.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: IPXCP Status > Bill Simpson: is your document describing IPXCP ready for approval by > the working group? If not, please finish it. If so, say so and put > out the last-call within the WG. I wish to move it to last-call > within the IETF. > I believe that we have come to a convergence. I was waiting for Telebit's test experience with the difficulty of integrating a "configuration-complete" option. (Silly me, to want implementation experience before going forward.) I just returned from an out-of-town trip, and instead of reading 1 meg or so of email, I will finish off the IPXCP spec (still subject to Telebit's trials this week). Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Mon Oct 19 10:33:57 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26255; Mon, 19 Oct 92 10:28:35 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17345; Mon, 19 Oct 92 09:50:33 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24252; Mon, 19 Oct 92 09:45:17 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23702; Mon, 19 Oct 92 09:32:26 -0700 Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA27592; Mon, 19 Oct 92 09:31:40 -0700 Date: Mon, 19 Oct 92 12:15:52 EDT From: "William Allen Simpson" Message-Id: <829.bill.simpson@um.cc.umich.edu> To: internet-drafts@nri.reston.va.us Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: ipxcp - october There is a new IPXCP draft, which may be found at angband.stanford.edu:pub/ppp/ipxcp.txt This includes new information on interoperation with IPX-WAN, and a variety of new/revised configuration options. The document is ready for last-call. Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Mon Oct 19 13:56:44 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03451; Mon, 19 Oct 92 13:49:49 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA19245; Mon, 19 Oct 92 12:10:32 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29643; Mon, 19 Oct 92 12:01:22 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29225; Mon, 19 Oct 92 11:50:35 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA03435; Mon, 19 Oct 92 11:49:52 PDT Date: Mon, 19 Oct 92 11:49:52 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9210191849.AA03435@ray.lloyd.com> To: ietf-ppp@ucdavis.ucdavis.edu Cc: internet-drafts@nri.reston.va.us, bill.simpson@um.cc.umich.edu In-Reply-To: "William Allen Simpson"'s message of Mon, 19 Oct 92 12:15:52 EDT <829.bill.simpson@um.cc.umich.edu> Subject: ipxcp - october Everybody: please read the new IPXCP document on angband.stanford.edu (pub/ppp/ipxcp.txt) and comment. I would like to ask Greg Vaudreil to make a last call for this document in about a week, after we have had time for comments. Brian Lloyd, President B.P. Lloyd & Associates, Inc. brian@lloyd.com 3420 Sudbury Road (916) 676-1147 - voice Cameron Park, CA 95682 (916) 676-3442 - fax From ietf-ppp-request@ucdavis.ucdavis.edu Tue Oct 20 06:30:41 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07446; Tue, 20 Oct 92 06:25:18 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27708; Tue, 20 Oct 92 06:10:06 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06674; Tue, 20 Oct 92 06:00:52 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from antares.mcs.anl.gov by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06421; Tue, 20 Oct 92 05:53:59 -0700 Received: from athens.eid.anl.gov by antares.mcs.anl.gov (4.1/SMI-GAR) id AA19206; Tue, 20 Oct 92 07:53:09 CDT Received: from athens.eid.anl.gov by athens.eid.anl.gov (4.1/SMI-4.1) id AA13754; Tue, 20 Oct 92 07:53:08 CDT Message-Id: <9210201253.AA13754@athens.eid.anl.gov> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Current version of PPP Date: Tue, 20 Oct 92 07:53:07 -0500 From: Dick Eagan (708)252-3435 I have a version of PPP from CMU dated approximately Sep 21, 1989. Drew Perkins suggested that you might be able to tell me if this is the most current public domain version available. We would like to incorporate PPP functionality into a low-power, 680X0 VME system box with serial and other I/O. Twenty to thirty of these boxes will be placed in farm fields or other appropriate locations in the Oklahoma and Kansas. The boxes will be connected to various types of meteorological and radiometeric instrument platforms and a dial-up or dedicated line modem. We hope to develop the software, incorporating the PPP protocol, to allow the instrument platforms connected to the box to look like socket or telnet ports to Sun workstations at the other end of the phone line. We are running Brixton PPP on the Sun's. If you can point us to the current release or provide any pointers we would appreciate it. Thanks, in advance, for your assistance. Dick E. From ietf-ppp-request@ucdavis.ucdavis.edu Tue Oct 20 15:08:28 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25408; Tue, 20 Oct 92 14:55:43 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA03628; Tue, 20 Oct 92 14:00:36 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23172; Tue, 20 Oct 92 13:52:22 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22821; Tue, 20 Oct 92 13:44:36 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA04613; Tue, 20 Oct 92 13:43:51 PDT Date: Tue, 20 Oct 92 13:43:51 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9210202043.AA04613@ray.lloyd.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Finally!! A new Request for Comments is now available in online RFC libraries. RFC 1334: Title: PPP Authentication Protocols Author: Lloyd & Simpson Mailbox: brian@lloyd.com, Bill.Simpson@um.cc.umich.edu Pages: 16 Characters: 33,248 Updates/Obsoletes: none From ietf-ppp-request@ucdavis.ucdavis.edu Wed Oct 21 13:32:51 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11530; Wed, 21 Oct 92 13:23:11 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA15833; Wed, 21 Oct 92 12:30:56 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09447; Wed, 21 Oct 92 12:22:01 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09038; Wed, 21 Oct 92 12:12:41 -0700 Received: by volitans.morningstar.com (5.65a/92042102) id AA28862; Wed, 21 Oct 92 15:11:36 -0400 Date: Wed, 21 Oct 92 15:11:36 -0400 From: Bob Sutterfield Message-Id: <9210211911.AA28862@volitans.morningstar.com> To: brian@lloyd.com (Brian Lloyd) In-Reply-To: brian@lloyd.com's message of Tue, 20 Oct 92 13:43:51 PDT Subject: Finally!! Cc: ietf-ppp@ucdavis.ucdavis.edu Date: Tue, 20 Oct 92 13:43:51 PDT From: brian@lloyd.com (Brian Lloyd) A new Request for Comments is now available in online RFC libraries. RFC 1334: Title: PPP Authentication Protocols Darn! Mere hours after our updated PPP Quick Reference Card went to the printer with the "Internet Draft" citation. Oh well, get the exclusive collector's keepsake limited edition from Karl Fox at the PPP-A-Thon this week, or get a corrected version from ftp.morningstar.com:pub/ppp/ppp-refcard-{front,back}.ps.Z. From ietf-ppp-request@ucdavis.ucdavis.edu Wed Oct 21 17:17:35 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15933; Wed, 21 Oct 92 17:05:22 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA18306; Wed, 21 Oct 92 15:41:51 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14268; Wed, 21 Oct 92 15:36:39 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14022; Wed, 21 Oct 92 15:27:03 -0700 Received: from napa.TELEBIT.COM by apache (4.1/SMI-4.1/Telebit-Apache-Brent-920708) id AA18761 to ietf-ppp@ucdavis.edu; Wed, 21 Oct 92 15:26:10 PDT Received: from yoyo.telebit.com by napa.TELEBIT.COM (4.1/napa.telebit.com-Brent-920717) id AA12449 to internet-drafts@nri.reston.va.us; Wed, 21 Oct 92 15:26:08 PDT Date: Wed, 21 Oct 92 15:26:08 PDT From: mlewis@napa.Telebit.COM (Mark S. Lewis) Message-Id: <9210212226.AA12449@napa.TELEBIT.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA22921; Wed, 21 Oct 92 15:26:39 PDT To: bill.simpson@um.cc.umich.edu, brian@lloyd.com Cc: internet-drafts@nri.reston.va.us, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <829.bill.simpson@um.cc.umich.edu> Subject: ipxcp - october > There is a new IPXCP draft, which may be found at > angband.stanford.edu:pub/ppp/ipxcp.txt > This includes new information on interoperation with IPX-WAN, and > a variety of new/revised configuration options. > The document is ready for last-call. > Bill.Simpson@um.cc.umich.edu I hate to make these things wait, but I think we need a couple more weeks to polish this stuff. I think we are on track, but it looks like there are several loose ends. Many of us are busy this week with PPP interoperability testing and next week of course is InterOp. How about giving us a week after InterOp to look carefully at this. How about issuing the last-call no earlier than Friday November 13. (The next week is the IETF meeting.) ... Mark =========----------- Mark S. Lewis -----------========== inet: mlewis@telebit.com Telebit Corp. Telebit (408) 745-3232 uucp: uunet!telebit!mlewis Fax (408) 745-3810 From ietf-ppp-request@ucdavis.ucdavis.edu Wed Oct 21 18:11:35 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16888; Wed, 21 Oct 92 18:03:28 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA19374; Wed, 21 Oct 92 17:10:23 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15968; Wed, 21 Oct 92 17:08:00 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [158.222.1.2] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15559; Wed, 21 Oct 92 16:47:36 -0700 Received: from harry.lloyd.com. by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA05559; Wed, 21 Oct 92 16:45:48 PDT Date: Wed, 21 Oct 92 16:45:48 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9210212345.AA05559@ray.lloyd.com> Received: by harry.lloyd.com. (4.1/SMI-4.1) id AA00311; Wed, 21 Oct 92 16:45:48 PDT To: mlewis@Telebit.COM Cc: bill.simpson@um.cc.umich.edu, internet-drafts@nri.reston.va.us, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Mark S. Lewis's message of Wed, 21 Oct 92 15:26:08 PDT <9210212226.AA12449@napa.TELEBIT.COM> Subject: ipxcp - october Since we have most of the players at the interoperability testing, let's discuss it there. That should shorten the time to get this document out. Brian Lloyd, President B.P. Lloyd & Associates, Inc. brian@lloyd.com 3420 Sudbury Road (916) 676-1147 - voice Cameron Park, CA 95682 (916) 676-3442 - fax From ietf-ppp-request@ucdavis.ucdavis.edu Wed Oct 21 18:21:24 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17177; Wed, 21 Oct 92 18:19:36 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA19652; Wed, 21 Oct 92 17:40:13 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16467; Wed, 21 Oct 92 17:37:40 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [130.57.4.1] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16310; Wed, 21 Oct 92 17:29:51 -0700 Received: from na.SJF.Novell.COM by newsun.Novell.COM (4.1/SMI-4.1) id AA20062; Wed, 21 Oct 92 17:29:03 PDT Received: by na.SJF.Novell.COM (4.1/SMI-4.1) id AA28386; Wed, 21 Oct 92 17:32:33 PDT Date: Wed, 21 Oct 92 17:32:33 PDT From: Christopher_Ranch@Novell.COM (Christopher Ranch) Message-Id: <9210220032.AA28386@na.SJF.Novell.COM> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: october ipxcp Hi Y'all, Did anyone get my comments on the latest draft? I haven't seen the copy appear on the list. Chris From ietf-ppp-request@ucdavis.ucdavis.edu Wed Oct 21 20:20:31 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18784; Wed, 21 Oct 92 20:09:54 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27708; Tue, 20 Oct 92 06:10:06 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06674; Tue, 20 Oct 92 06:00:52 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from antares.mcs.anl.gov by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06421; Tue, 20 Oct 92 05:53:59 -0700 Received: from athens.eid.anl.gov by antares.mcs.anl.gov (4.1/SMI-GAR) id AA19206; Tue, 20 Oct 92 07:53:09 CDT Received: from athens.eid.anl.gov by athens.eid.anl.gov (4.1/SMI-4.1) id AA13754; Tue, 20 Oct 92 07:53:08 CDT Message-Id: <9210201253.AA13754@athens.eid.anl.gov> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Current version of PPP Date: Tue, 20 Oct 92 07:53:07 -0500 From: Dick Eagan (708)252-3435 I have a version of PPP from CMU dated approximately Sep 21, 1989. Drew Perkins suggested that you might be able to tell me if this is the most current public domain version available. We would like to incorporate PPP functionality into a low-power, 680X0 VME system box with serial and other I/O. Twenty to thirty of these boxes will be placed in farm fields or other appropriate locations in the Oklahoma and Kansas. The boxes will be connected to various types of meteorological and radiometeric instrument platforms and a dial-up or dedicated line modem. We hope to develop the software, incorporating the PPP protocol, to allow the instrument platforms connected to the box to look like socket or telnet ports to Sun workstations at the other end of the phone line. We are running Brixton PPP on the Sun's. If you can point us to the current release or provide any pointers we would appreciate it. Thanks, in advance, for your assistance. Dick E. From ietf-ppp-request@ucdavis.ucdavis.edu Thu Oct 22 12:57:35 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18493; Thu, 22 Oct 92 12:47:27 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA29556; Thu, 22 Oct 92 12:30:51 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17686; Thu, 22 Oct 92 12:22:24 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17312; Thu, 22 Oct 92 12:11:42 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA06051; Thu, 22 Oct 92 12:09:29 PDT Date: Thu, 22 Oct 92 12:09:29 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9210221909.AA06051@ray.lloyd.com> To: mlewis@napa.Telebit.COM Cc: bill.simpson@um.cc.umich.edu, internet-drafts@nri.reston.va.us, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Mark S. Lewis's message of Wed, 21 Oct 92 15:26:08 PDT <9210212226.AA12449@napa.TELEBIT.COM> Subject: ipxcp - october I hate to make these things wait, but I think we need a couple more weeks to polish this stuff. I think we are on track, but it looks like there are several loose ends. Many of us are busy this week with PPP interoperability testing and next week of course is InterOp. How about giving us a week after InterOp to look carefully at this. How about issuing the last-call no earlier than Friday November 13. (The next week is the IETF meeting.) ... Mark I appreciate your desire for due diligence on this but we have waited for a LLOONNGG time for this. I don't want to ram it down anyone's throat but I do want this completed quickly. Bill has put quite some time into this and it seems to be complete. Let's move forward. Actually, this week is a good time to discuss the document at the bake-off at Telebit. Almost everybody doing IPX is there so you can review it and comment in a day or two. Please try. Brian Lloyd, President B.P. Lloyd & Associates, Inc. brian@lloyd.com 3420 Sudbury Road (916) 676-1147 - voice Cameron Park, CA 95682 (916) 676-3442 - fax From ietf-ppp-request@ucdavis.ucdavis.edu Thu Oct 22 15:04:17 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22446; Thu, 22 Oct 92 14:51:04 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA02864; Thu, 22 Oct 92 14:20:40 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21104; Thu, 22 Oct 92 14:14:09 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20790; Thu, 22 Oct 92 14:03:12 -0700 Received: from na.SJF.Novell.COM by newsun.Novell.COM (4.1/SMI-4.1) id AA05854; Thu, 22 Oct 92 14:02:23 PDT Received: by na.SJF.Novell.COM (4.1/SMI-4.1) id AA10330; Thu, 22 Oct 92 14:05:53 PDT Date: Thu, 22 Oct 92 14:05:53 PDT From: Christopher_Ranch@Novell.COM (Christopher Ranch) Message-Id: <9210222105.AA10330@na.SJF.Novell.COM> To: bill.simpson@um.cc.umich.edu, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: october ipxcp Hi Y'all, These are Michael's and my comments on Bill's latest draft. We'll let Mark Lewis comment on the compression option. Since we're all harried with the connectathon and Interop, what say we extend the last call period to November 6, to allow one week after Interop for meaningful work? Nice work, Bill. Thanks. > 2.3. Co-existance with IPX-WAN > > Previous drafts of this specification have introduced a NCP with ^an > several configuration options, and another NCP having no > configuration options, with some NCP functions moved to the IPX-WAN > protocol. This version proposes the union of the previous proposals, > with instructions for interoperating between the two environments. > As time has progressed, Novell has improved IPX-WAN by adding the > functional equivalent of every feature proposed in earlier drafts of > this document. [We think the above paragraph should be scrapped altogether.] > Currently, Novell has implemented IPXCP without any Configuration > Options, and requires successful IPX-WAN negotiation, even when all > required parameters have been hand configured. This makes it > impossible for the Novell products to interoperate with > implementations which do not already include support for IPX-WAN. Novell has implemented IPXCP without any Configuration Options, and requires successful IPX-WAN negotiation completion before any other IPX packets may be forwarded over the link. Novell products cannot interoperate with implementations which do not support IPX-WAN, even if all required parameters have been manually configured and/or negotiated via IPXCP (and LQM for link delay measurements). > Therefore, it is the intent of this document to accomodate versions > of IPX and IPXCP which are implemented by other vendors, and to > provide features and functionality for those implementations which > are not directly connected to a NetWare network. It is hoped that > future Novell releases will support the complete IPXCP specification. Therefore, it is the intent of this document to accomodate versions of IPX and IPXCP which are implemented by other vendors, and to provide features and functionality for those implementations which are not directly connected to a NetWare network. > If unable to negotiate some required parameter, all non-IPX-WAN- > capable implementations MUST NOT reach Opened state. Conversely, an > IPX-WAN-capable implementation SHOULD reach Opened state, even when > no Configuration Options are successfully negotiated. > > IPX-WAN uses a "Timer Request" packet to set up the link. These MUST > NOT be sent until IPXCP has Opened the link. > > An implementation which provides both IPX-WAN and IPXCP Configuration > Options capability SHOULD only send a Timer Request packet when a > Timer Request packet is received, or upon failure to successfully > negotiate a required parameter. > > If unable to complete IPX-WAN setup when a required parameter is > unknown, by default IPXCP SHOULD terminate the link. However, some > implementations (such as half routers) might be capable of operating > without all indicated required parameters, in which case the > termination MUST be configurable. [Add:] IPX-WAN overrides any manually configured parameters or negotiated IPXCP options. > 2.4. Required Configuration Parameters > > Where applicable, each Configuration Option indicates the environment > where the parameter which is negotiated MAY be required by the > implementation for proper operation. This determination is highly > implementation dependent. Is this enough for everyone? Our minimum requirement of IPX-WAN is what _we_ need. If you want a minimum: 1) LQM Echo measurement, or a _good_ manually configured value for link delay for IPX RIP. 2) Net and node numbers _if_ you want addressed links. 3) Router name _if_ you want decent management identification. > 3.1. IPX-Network-Number > > IPX-Network-Number > > The four octet IPX-Network-Number is the desired local IPX network > number of the sender of the Configure-Request. This number may be > zero, which is interpreted as being a local network of unknown > number that requires no routing. > > Both ends of the link MUST have the same network number. In the > event of conflict, the end having the highest node number wins. [In the event of conflict, the end having the highest node number wins. ---> This won't work UNLESS a node id has been previously configured or negotiated. Bill, all cases need to be covered.] > 4. Telebit IPX header compression Mark Lewis' immenent comments will update this, so we won't bother. > References > > [4] Allen, M., "Novell IPX Over Various WAN Media", Novell Inc., > RFC 1362, June 1992. Add the RFC #. From ietf-ppp-request@ucdavis.ucdavis.edu Thu Oct 22 22:02:05 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08040; Thu, 22 Oct 92 21:59:00 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07871; Thu, 22 Oct 92 21:40:48 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07135; Thu, 22 Oct 92 21:33:03 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06669; Thu, 22 Oct 92 21:21:13 -0700 Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA02782; Thu, 22 Oct 92 21:20:01 -0700 Date: Thu, 22 Oct 92 23:12:39 EDT From: "William Allen Simpson" Message-Id: <839.bill.simpson@um.cc.umich.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: october ipxcp > These are Michael's and my comments on Bill's latest draft. We'll let > Mark Lewis comment on the compression option. Since we're all harried > with the connectathon and Interop, what say we extend the last call > period to November 6, to allow one week after Interop for meaningful > work? > OK. As long as you promise to talk about this stuff at the connectathon and InterOp. > Nice work, Bill. Thanks. > You're welcome. I just spent an hour and a half on the phone with Michael Allen, at my expense. We've some more questions, and clarifications, too. > > 2.3. Co-existance with IPX-WAN > > > > Previous drafts of this specification have introduced a NCP with > ^an No, it may "sound" better, but "en" is not a vowel (nor "el", nor "ex", etc). > [We think the above paragraph should be scrapped altogether.] > I like historical notes. They give us a sense of context, and provide rationale for the decisions presented. Some people prefer them in separate documents, but it's a lot harder to follow that way. > > Currently, Novell has implemented IPXCP without any Configuration > > Novell has implemented IPXCP without any Configuration Options, > and requires successful IPX-WAN negotiation completion before > any other IPX packets may be forwarded over the link. Novell > products cannot interoperate with implementations which do not > support IPX-WAN, even if all required parameters have been manually > configured and/or negotiated via IPXCP (and LQM for link delay > measurements). > I like my "currently", since it gives hope that things will change, perhaps due to market conditions. :-) And I don't think that LQM is designed to measure link delay. IPX-WAN purports to measure link delay, but is flawed. It measures the delay on a dead link, rather than a loaded, congested link. Michael tells me that both ends need to have the same link delay for correct operation of RIP/SAP. This means I should add a data parameter back on the RIP/SAP routing protocol? Any other views? > > Therefore, it is the intent of this document to accomodate versions > > of IPX and IPXCP which are implemented by other vendors, and to > > provide features and functionality for those implementations which > > are not directly connected to a NetWare network. It is hoped that > > future Novell releases will support the complete IPXCP specification. > > Therefore, it is the intent of this document to accomodate versions > of IPX and IPXCP which are implemented by other vendors, and to > provide features and functionality for those implementations which > are not directly connected to a NetWare network. > You don't like hope? OK, I'll take it out, it's hopeless. > [Add:] > IPX-WAN overrides any manually configured parameters or negotiated > IPXCP options. > Half-right; right now it doesn't have any IPXCP options. I've put in requirements for those who do both. So there! > > 2.4. Required Configuration Parameters > > > > Where applicable, each Configuration Option indicates the environment > > where the parameter which is negotiated MAY be required by the > > implementation for proper operation. This determination is highly > > implementation dependent. > > Is this enough for everyone? Our minimum requirement of IPX-WAN > is what _we_ need. If you want a minimum: > > 1) LQM Echo measurement, or a _good_ manually configured value > for link delay for IPX RIP. > > 2) Net and node numbers _if_ you want addressed links. > > 3) Router name _if_ you want decent management identification. > I tried to state in the option text how each option is used, and whether it overrides IPX-WAN or vice versa. Perhaps I should move the various requirements to a separate section at the end, like ATCP? > > Both ends of the link MUST have the same network number. In the > > event of conflict, the end having the highest node number wins. > > [In the event of conflict, the end having the highest node number > wins. ---> This won't work UNLESS a node id has been previously > configured or negotiated. Bill, all cases need to be covered.] > Dumb typo department. It's supposed to be "highest network number", just like IPX-WAN. I will also add a better description of when IPX-WAN request packets are sent, what a "half-router" is, and when the "no routing protocol" is used. Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Fri Oct 23 16:54:26 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13115; Fri, 23 Oct 92 16:48:16 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA16843; Fri, 23 Oct 92 15:34:11 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11589; Fri, 23 Oct 92 15:20:37 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11415; Fri, 23 Oct 92 15:11:02 -0700 Received: from la.SJF.Novell.COM by newsun.Novell.COM (4.1/SMI-4.1) id AA24421; Fri, 23 Oct 92 15:10:08 PDT Received: by la.SJF.Novell.COM (4.1/SMI-4.1) id AA22768; Fri, 23 Oct 92 15:07:42 PDT From: Neal_Castagnoli@Novell.COM (Neal Castagnoli) Message-Id: <9210232207.AA22768@la.SJF.Novell.COM> Subject: ipxcp beneficial? To: ietf-ppp@ucdavis.ucdavis.edu Date: Fri, 23 Oct 92 15:07:41 PDT X-Mailer: Elm [version 2.1 alpha-test] Before we create a new method in which IPX can operate over wide area links with PPP, I would like to suggest that we consider the following. Is the new way (ipxcp) technically superior to IPXWAN? That is, does it add functionality that may not reside in IPXWAN. Is the new way superior in some other way to IPXWAN? I would also propose that ipxcp has the following problems that make it inferior to IPXWAN. First, IPXWAN may operate over many WAN media, including frame relay, ISDN, X.25, and PPP, whereas ipxcp may only operate in conjunction with PPP. Secondly, IPXWAN has functionality in it that make it conducive to use with IPX, in that it calculates link delay. Thirdly, IPXWAN operates uniformly over all WAN media types. I would suggest that adding a second means by which wide area IPX connectivity may be achieved has the following disadvantages: 1) Even if two implementations can interoperate, it increases the chance that interoperability will not be achieved. 2) The amount of end-user configuration increases. For the above two reasons, I would suggest that it is incumbent upon the proponents of ipxcp to address these issues prior to creating another standard way of operating IPX over PPP. P.S. I am not on the mailing list, so please direct your comments, additionally, to cast@novell.com. From ietf-ppp-request@ucdavis.ucdavis.edu Sat Oct 24 14:31:58 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04720; Sat, 24 Oct 92 14:26:55 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA21960; Sat, 24 Oct 92 14:10:17 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04368; Sat, 24 Oct 92 14:00:29 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Shiva.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04240; Sat, 24 Oct 92 13:51:56 -0700 Received: by Shiva.COM (1.34b) Sat, 24 Oct 92 16:51:30 EDT Date: Sat, 24 Oct 92 16:51:30 EDT From: Robert D. Vincent Message-Id: <9210242051.AA25527@Shiva.COM> To: cast@novell.com, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: ipxcp beneficial? In-Reply-To: <1992Oct24.003821.11801@Shiva.COM> References: <1992Oct24.003821.11801@Shiva.COM> Organization: Shiva Corporation, Cambridge, Ma, USA Regarding your two points: 1) IPXWAN is an entirely new, unproven protocol to us, whereas the PPP framework is extensible and proven. In a well designed PPP implementation a new NCP can be created in just a few lines of code. Since all of the options in the NCP are exactly that (optional!), there is no increased burden to developers such as Novell which do not want to interoperate with PPP-only devices. There's so much redundancy in the information negotiated by the two protocols that end-user configuration is a non-issue. The IPXWAN document does not describe how IPXWAN is to be used over all WAN media - so the claim that it will work over all of them, unlike PPP, seems unnecessarily optimistic with respect to IPXWAN and pessimistic with respect to PPP. 2) One-time link delay measurement is of dubious value, even with IPX, since congestion and packet loss may affect round trip time tremendously over the lifetime of a link. See Van Jacobsen's work on TCP. In addition, IPXCP handles end-node-to-router links, something near and dear to my heart. IPXWAN doesn't have what we need for this. IPXCP is beneficial. Let's stop bickering and work with Bill's proposal. -bert From ietf-ppp-request@ucdavis.ucdavis.edu Sat Oct 24 14:43:05 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04908; Sat, 24 Oct 92 14:35:56 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA22024; Sat, 24 Oct 92 14:20:30 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04587; Sat, 24 Oct 92 14:17:18 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04381; Sat, 24 Oct 92 14:04:05 -0700 Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA04996; Sat, 24 Oct 92 14:01:07 -0700 Date: Sat, 24 Oct 92 14:45:13 EDT From: "William Allen Simpson" Message-Id: <853.bill.simpson@um.cc.umich.edu> To: Neal_Castagnoli@Novell.COM (Neal Castagnoli) Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: ipxcp beneficial? > From: Neal_Castagnoli@Novell.COM (Neal Castagnoli) > Before we create a new method in which IPX can operate over wide area links > with PPP, I would like to suggest that we consider the following. > These are very important questions, which is why we have already considered them. The consensus of the group was to continue IPXcp development. In fact, it was six or seven vendors to 1 (including some private email of un-announced products.) When IPXcp started, there was no announced IPX-WAN. The Shiva folks started the effort, and have a test implementation in the field. This is considered very positive in the "Internet Way". When IPX-WAN was announced, it was missing many of the features of IPXcp. Through the efforts of the Chair, Brian Lloyd, and the co-operation of your engineers with this working group, the IPX-WAN and IPXcp efforts have largely converged. Again, this is the "Internet Way". It is hoped that both will compete for their niches in the marketplace, and the result will be a stronger evolution. It is the "Internet Way" to encourage such alternatives and experimentation. > Is the new way (ipxcp) technically superior to IPXWAN? That is, does it add > functionality that may not reside in IPXWAN. > First, IPXcp is not a "new" way. From the point of view of the user community, it is older than IPX-WAN. It is merely that the publication of Internet Standards requires field experience, while "informational" RFCs about proprietary products do not. Second, here are some things that IPXcp still does that IPX-WAN does not: - The periodic routing packets may be negotiated away (no routing protocol). This is considered very useful for end-systems (workstations), since this frees up bandwidth. - More than one header compression protocol may be fielded and tested, since PPP allows each to have a different protocol number. In fact, there is already one compression protocol available (Shiva again). However, the recent cooperation between Novell and Telebit, together with the Shiva field experience, has resulted in a much better design (which I hope to see published soon). Third, IPXcp is more robust than IPX-WAN, since: - The state machine ensures cleaner configuration and termination. - User self-configuration and overrides are better handled. - The peer-peer negotiation (as opposed to master-slave) allows misconfiguration to be automatically corrected in both directions. > Is the new way superior in some other way to IPXWAN? > - It is easier to implement, since the state machine is the same for all of the NCPs, and must be implemented in any case. - It does not have a built-in WAN/LAN dichotomy, so it may be used transparently in more situations. - It may be used with older Novell products, which do not yet have IPX-WAN implemented, in a completely out-of-band fashion. - It is the result of a wider participation of sources, who have brought insight and implementation experience. This is not to fault your engineers, who (IMHO) have shown themselves competent, and have added greatly to the improvement of IPXcp through their helpful comments. > I would also propose that ipxcp has the following problems that make it > inferior to IPXWAN. First, IPXWAN may operate over many WAN media, including > frame relay, ISDN, X.25, and PPP, whereas ipxcp may only operate in > conjunction with PPP. Actually PPP operates over ISDN, too, and the Frame Relay folks have come to the realization that they may need some of PPP functionality. Also, there has been some feedback from the PPP WG to the IPX-WAN folks about possible problems over partially connected meshes. I hope your engineers have benefited from this synergy. It may be that IPX-WAN really only operates over point-to-point links, at which time you might as well use PPP. > Secondly, IPXWAN has functionality in it that make it > conducive to use with IPX, in that it calculates link delay. We had a link delay, but folks said it wasn't needed. Perhaps there is now sentiment to put it back in? For example, if one of the directions in the link has a lower bandwidth, IPXcp is capable of negotiating to the average, or to any value acceptable to both implementations. > Thirdly, IPXWAN > operates uniformly over all WAN media types. > I think that this is a generalization of your first point. > I would suggest that adding a second means by which wide area IPX > connectivity may be achieved has the following disadvantages: > > 1) Even if two implementations can interoperate, it increases the > chance that interoperability will not be achieved. > Which is why I have been adding all of those interoperability sections. And the new Configuration-Complete option. As noted above, IPXcp must be implemented in any case. It is only the Options that are optional. > 2) The amount of end-user configuration increases. > Since both protocols are supposed to be automatically detected, I do not believe this to be true. However, as noted above, IPXcp is more sensitive to end-user configuration than IPX-WAN. The current Novell implementation *requires* that IPX-WAN run, even when the user has completely hand-configured. This makes it *impossible* for Novell's product to talk to other vendor's equipment, or even older Novell products, which I would not list as an advantage. > P.S. I am not on the mailing list, so please direct your comments, > additionally, to cast@novell.com. > Hopefully this answers your very important questions, and your engineers who have participated can get you the relevant archives. Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Sat Oct 24 17:31:29 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07760; Sat, 24 Oct 92 17:29:47 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA22725; Sat, 24 Oct 92 17:10:20 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07058; Sat, 24 Oct 92 17:04:26 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06937; Sat, 24 Oct 92 16:54:38 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA07298; Sat, 24 Oct 92 16:54:05 PDT Date: Sat, 24 Oct 92 16:54:05 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9210242354.AA07298@ray.lloyd.com> To: mallen@novell.com, cast@novell.com Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: IPXCP vs IPXWAN > > My understanding is that both you AND Brian agree that IPXCP is not > providing > extra functionallity to IPXWAN. In that case, new implementations should > be > using IPXWAN (an existing RFC) and a NULL IPXCP, and we should be > attempting > to make others see this reason and document it that way. > > Michael Allen mallen@novell.com > Neal Castagnoli cast@novell.com > Novell Inc. > I do not agree with the above statement. Hopefully, my other message handles the details. Bill.Simpson@um.cc.umich.edu I do not agree either. IPXCP can always be extended to provide new features as they are required and still be backward compatible. There is no way for a vendor or experimentor to modify IPXWAN to provide new functionallity. Therefore I believe that IPXCP is providing (or can provide) extra functionallity above and beyond IPXWAN. My previous comments re compatibility with Netware and IPXWAN were pragmatic and of a marketing nature. Just because I think that people ought to implement IPXWAN to ensure compatibility with Netware does not mean that I think that IPXWAN is superior to IPXCP. (Heck, I prefer IP/TCP to IPX/Netware, Appletalk, OSI, DECnet, and SNA, but I am also a realist and believe that interoperability is of foremost importance.) Please stop fighting for a null IPXCP. It is pretty clear to me that there will be options in IPXCP. You have participated in the process and there will be many implementors who will go the route of implementing an IPXCP that supports no options and uses IPXWAN. On the other hand you are not likely to stop other vendors from using the options defined in the IPXCP document. I think that is the best you can hope for. Hopefully you will be able to interoperate using IPXCP only at some time in the future. Brian Lloyd, President B.P. Lloyd & Associates, Inc. brian@lloyd.com 3420 Sudbury Road (916) 676-1147 - voice Cameron Park, CA 95682 (916) 676-3442 - fax From ietf-ppp-request@ucdavis.ucdavis.edu Sat Oct 24 18:01:17 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09479; Sat, 24 Oct 92 17:58:22 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA22725; Sat, 24 Oct 92 17:10:20 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07058; Sat, 24 Oct 92 17:04:26 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06937; Sat, 24 Oct 92 16:54:38 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA07298; Sat, 24 Oct 92 16:54:05 PDT Date: Sat, 24 Oct 92 16:54:05 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9210242354.AA07298@ray.lloyd.com> To: mallen@novell.com, cast@novell.com Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: IPXCP vs IPXWAN > > My understanding is that both you AND Brian agree that IPXCP is not > providing > extra functionallity to IPXWAN. In that case, new implementations should > be > using IPXWAN (an existing RFC) and a NULL IPXCP, and we should be > attempting > to make others see this reason and document it that way. > > Michael Allen mallen@novell.com > Neal Castagnoli cast@novell.com > Novell Inc. > I do not agree with the above statement. Hopefully, my other message handles the details. Bill.Simpson@um.cc.umich.edu I do not agree either. IPXCP can always be extended to provide new features as they are required and still be backward compatible. There is no way for a vendor or experimentor to modify IPXWAN to provide new functionallity. Therefore I believe that IPXCP is providing (or can provide) extra functionallity above and beyond IPXWAN. My previous comments re compatibility with Netware and IPXWAN were pragmatic and of a marketing nature. Just because I think that people ought to implement IPXWAN to ensure compatibility with Netware does not mean that I think that IPXWAN is superior to IPXCP. (Heck, I prefer IP/TCP to IPX/Netware, Appletalk, OSI, DECnet, and SNA, but I am also a realist and believe that interoperability is of foremost importance.) Please stop fighting for a null IPXCP. It is pretty clear to me that there will be options in IPXCP. You have participated in the process and there will be many implementors who will go the route of implementing an IPXCP that supports no options and uses IPXWAN. On the other hand you are not likely to stop other vendors from using the options defined in the IPXCP document. I think that is the best you can hope for. Hopefully you will be able to interoperate using IPXCP only at some time in the future. Brian Lloyd, President B.P. Lloyd & Associates, Inc. brian@lloyd.com 3420 Sudbury Road (916) 676-1147 - voice Cameron Park, CA 95682 (916) 676-3442 - fax From ietf-ppp-request@ucdavis.ucdavis.edu Wed Oct 28 07:53:09 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25618; Wed, 28 Oct 92 07:38:22 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA24947; Wed, 28 Oct 92 07:10:52 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24255; Wed, 28 Oct 92 07:02:13 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from LOBSTER.WELLFLEET.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24048; Wed, 28 Oct 92 06:57:32 -0800 Received: from ginzo.wellfleet ([192.32.1.233]) by lobster.wellfleet.com (4.1/SMI-4.1) id AA28555; Wed, 28 Oct 92 09:53:49 EST Received: by ginzo.wellfleet (4.1/SMI-4.1) id AA02986; Wed, 28 Oct 92 10:01:45 EST From: ginsburg@wellfleet.com (Scott Ginsburg) Message-Id: <9210281501.AA02986@ginzo.wellfleet> Subject: Vines CP To: ietf-ppp@ucdavis.ucdavis.edu Date: Wed, 28 Oct 92 10:01:43 EST X-Mailer: ELM [version 2.3 PL11] Is anyone out there working on a Control Protocol for Vines? -- Scott Ginsburg Voice: 617-280-2336 Wellfleet Communications Internet: ginsburg@wellfleet.com 15 Crosby Drive Amateur Radio: WA2CJT Bedford, MA 01730 From ietf-ppp-request@ucdavis.ucdavis.edu Fri Oct 30 13:52:20 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16534; Fri, 30 Oct 92 13:43:18 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA23383; Fri, 30 Oct 92 13:11:17 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15056; Fri, 30 Oct 92 13:02:10 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.41.217.2] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14646; Fri, 30 Oct 92 12:50:29 -0800 Received: by pluto.dss.com (4.1/SMI-4.0) id AA05815; Fri, 30 Oct 92 15:47:13 EST Date: Fri, 30 Oct 92 15:47:13 EST From: irfan@pluto.dss.com (Syed Mohammad Irfan Ashraf) Message-Id: <9210302047.AA05815@pluto.dss.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: IP subnet mask along with IP address Hi guys, I am trying to get to the PPP extension group. I don't have the mailing list address handy so I am sending this to the main list. While trying to create network routes automatically to the peer's network, I feel a need for the peer's subnet mask. Is anyone already working on having it as an IPCP option assoicated with or without the IP address ? Or maybe we should start looking into this. Irfan From ietf-ppp-request@ucdavis.ucdavis.edu Fri Oct 30 16:41:15 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22836; Fri, 30 Oct 92 16:33:40 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA25475; Fri, 30 Oct 92 16:10:58 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21586; Fri, 30 Oct 92 16:01:31 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.41.217.2] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20841; Fri, 30 Oct 92 15:41:24 -0800 Received: by pluto.dss.com (4.1/SMI-4.0) id AA00403; Fri, 30 Oct 92 18:38:18 EST Date: Fri, 30 Oct 92 18:38:18 EST From: irfan@pluto.dss.com (Syed Mohammad Irfan Ashraf) Message-Id: <9210302338.AA00403@pluto.dss.com> To: jas@proteon.com Subject: Re: IP subnet mask along with IP address Cc: ietf-ppp@ucdavis.ucdavis.edu >Date: Fri, 30 Oct 92 17:49:37 EST >From: jas@proteon.com (John A. Shriver) >Message-Id: <9210302249.AA20692@fats.proteon.com> >To: irfan@dss.com >Subject: Re: IP subnet mask along with IP address >What's wrong with an ICMP subnet mask request. This is a universal >need, why solve it in something media specific like PPP? Oh yes; the ICMP subnet mask ;-) While testing at PPP Consortium, only 4 vendors gave me a reply for the address mask request. Further the RFC1122 also has a 'may' wording for this ICMP option. Use of this option is already threatening IP's integrity in our implementation. As long as I don't get an address mask reply, I am assuming a standard net-mask. This runs into conflict if the network is subnetted and I already have another route for a subnet of this network number or a route to the full network (exactly identical to newly created one) on some other interface. I would prefer to complete configuring IP with all relevant info needed for the PPP link, before sending any ICMPs on this interface. let's see what others have to add to it. Irfan From ietf-ppp-request@ucdavis.ucdavis.edu Sat Oct 31 21:14:46 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27640; Sat, 31 Oct 92 20:23:39 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA00773; Sat, 31 Oct 92 20:10:28 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26749; Sat, 31 Oct 92 20:00:25 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26593; Sat, 31 Oct 92 19:56:31 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA09957; Sat, 31 Oct 92 19:55:52 PST Date: Sat, 31 Oct 92 19:55:52 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9211010355.AA09957@ray.lloyd.com> To: ginsburg@wellfleet.com Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Scott Ginsburg's message of Wed, 28 Oct 92 10:01:43 EST <9210281501.AA02986@ginzo.wellfleet> Subject: Vines CP Sender: ietf-ppp-request@ucdavis.edu From: ginsburg@wellfleet.com (Scott Ginsburg) Date: Wed, 28 Oct 92 10:01:43 EST X-Mailer: ELM [version 2.3 PL11] Is anyone out there working on a Control Protocol for Vines? -- Scott Ginsburg Voice: 617-280-2336 Wellfleet Communications Internet: ginsburg@wellfleet.com 15 Crosby Drive Amateur Radio: WA2CJT Bedford, MA 01730 Why, you are! I am looking forward to seeing your draft. ;^) Brian Lloyd, President B.P. Lloyd & Associates, Inc. brian@lloyd.com 3420 Sudbury Road (916) 676-1147 - voice Cameron Park, CA 95682 (916) 676-3442 - fax From ietf-ppp-request@ucdavis.ucdavis.edu Sat Oct 31 21:15:35 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28807; Sat, 31 Oct 92 20:53:06 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA00801; Sat, 31 Oct 92 20:30:39 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27669; Sat, 31 Oct 92 20:24:29 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27458; Sat, 31 Oct 92 20:18:55 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA09969; Sat, 31 Oct 92 20:17:21 PST Date: Sat, 31 Oct 92 20:17:21 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9211010417.AA09969@ray.lloyd.com> To: irfan@pluto.dss.com Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Syed Mohammad Irfan Ashraf's message of Fri, 30 Oct 92 15:47:13 EST <9210302047.AA05815@pluto.dss.com> Subject: IP subnet mask along with IP address While trying to create network routes automatically to the peer's network, I feel a need for the peer's subnet mask. Is anyone already working on having it as an IPCP option assoicated with or without the IP address ? We were discussing this in the PPP demo booth at Interop this week. I pointed out that you do not need the subnet mask. On a point-to-point link there is only one other device (the device at the other end of the link) so the mask is superfluous on the link. If you have a network on the other side of a router at the remote end of the link your routing protocol should pass you that information rather than PPP. (What? You aren't running OSPF, RIP-II, or BGP?) The counter to this argument is that some routers do not support host routes and that a subnet mask may be required (seems to me that the router should be fixed to support host routes). I am personally uneasy about changing IPCP yet again. Comments on how to do this without breaking existing implemntations? Other comments pro or con? Brian Lloyd, President B.P. Lloyd & Associates, Inc. brian@lloyd.com 3420 Sudbury Road (916) 676-1147 - voice Cameron Park, CA 95682 (916) 676-3442 - fax