From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 2 09:32:55 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25966; Thu, 2 Jul 92 09:29:22 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05671; Thu, 2 Jul 92 09:09:45 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25386; Thu, 2 Jul 92 09:03:37 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25259; Thu, 2 Jul 92 08:59:36 -0700 Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA21666; Thu, 2 Jul 92 08:58:16 -0700 Date: Wed, 1 Jul 92 17:27:42 EDT From: "William Allen Simpson" Message-Id: <496.bsimpson@angband.stanford.edu> To: fbaker@acc.com (Fred Baker) Cc: ietf-ppp@ucdavis.ucdavis.edu, jkrey@ISI.EDU Subject: Re: [jkrey@ISI.EDU: re: PPP number assignment requests] > From: fbaker@acc.com (Fred Baker) > May I suggest a better approach? (at least I think it's better): > Well, it's not what your draft says.... Of course, you originally only planned on one protocol, rather than many.... But, it's OK by me, if that's what you think is right! > These numbers are used for the process that receives compressed > datagrams; it decompresses them and then sends them to other processes; > IP, etc. Since there is only one compression algorithm in use on any > link, I think we should use one protocol ID (there's only 128 and some > are reserved, we should preserve them) and use the compression option > to negotiate what algorithm the compression engine uses. > There are only 111 numbers in the 00xx series, 12 have been assigned so far. Not having a separate number for each protocol is different than anything else we've done so far. LQR, VJ etc, all have their own protocol numbers, and we use that protocol number in the negotiation. Are we sure we'll never run multiple compression protocols at the same time? It's certainly legal under the current LCP syntax. > Hence: > > Protocol: > >> 00FD Compressed Data > > LCP Option: > >> 10 Data-Compression-Protocol > > Compression Algorithm Identifier > 1 Zip Compression > 2 Splay Tree > 3 STAC DCS221-C > 4 V.42bis > > LCP Option: > >> 11 LAPB-Numbered-Mode > > Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 2 11:32:32 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28832; Thu, 2 Jul 92 11:10:59 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06761; Thu, 2 Jul 92 10:52:06 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28207; Thu, 2 Jul 92 10:46:22 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27926; Thu, 2 Jul 92 10:37:20 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA01656; Thu, 2 Jul 92 10:35:56 PDT Date: Thu, 2 Jul 92 10:35:56 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9207021735.AA01656@saffron.acc.com> To: bsimpson@angband.stanford.edu Subject: Re: [jkrey@ISI.EDU: re: PPP number assignment requests] Cc: ietf-ppp@ucdavis.ucdavis.edu >> Not having a separate number for each protocol is different than >> anything else we've done so far. LQR, VJ etc, all have their own >> protocol numbers, and we use that protocol number in the >> negotiation. True, but VJ only applies to IP; there isn't some generalized VJ algorithm that can contain DECNET or ... data. I could generalize the algorithm, and get a new protocol for each generalization, but those would now have the same attribute. Also, the data stream can arrive in two ways. It can arrive as IP data or a VJ compressed IP data. From one message to the next the same message stream might arrive either way. >> Are we sure we'll never run multiple compression protocols at the >> same time? It's certainly legal under the current LCP syntax. At least in *my* view, it is not a compression protocol, it is a compression algorithm. You might have compression protocols running over the compressed link, but that's at a different layer. Taking the aforementioned IP/VJ-IP intermixed stream, the messages would now be compressed using *the* negotiated algorithm and send to the decompressor in the receiver. It would decompress them and present them to the IP and VJ-IP handlers just as though they had been received in the clear. | IP | AT | | SNDCF | SNDCF | +--+ +--+--+ +--+--+ +--+--+ +--+ | IP | VJ-IP | AT | VJ-AT | | PPP | PPP | PPP | PPP | +--+ +--+--+ +--+--+ +--+--+ +--+ | Demultiplexor | +------+ +-------+ | |Data Compression| | +------+ +-------+ | | Demultiplexor | +--------------+ +--------------+ | LAPB or Broadcast/UI | +--------------+ +--------------+ The picture isn't as pretty as I'd like it, but perhaps you get the idea. It doesn't really make sense, to me, to have multiple data compression algorithms running in this context. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Sun Jul 5 19:01:14 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03170; Sun, 5 Jul 92 18:56:26 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA02610; Sun, 5 Jul 92 18:39:37 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02758; Sun, 5 Jul 92 18:30:26 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02628; Sun, 5 Jul 92 18:28:26 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA03433; Sun, 5 Jul 92 18:27:39 PDT Date: Sun, 5 Jul 92 18:27:39 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9207060127.AA03433@ray.lloyd.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: IETF, Boston We are one week away. There are a number of items that require resolution at the upcoming fun-and-games in Boston: 1. Rejoicing that RFC's 1331, 1332, and 1333 (and hopefully 1334) have been published 2. Discussion of the MIBs 3. Discussion of the proposed LAPB option 4. Discussion of the proposed compression options 5. Discussion of IPX (I think we need a subgroup to work this out) 6. Decide whether or not to move the Appletalk, CLNP, and DECNet NCPs forward to proposed standard level now that there is implementation experience I have the results of the PPP connect-athon held last month at Telebit. By mutual agreement the participants agreed not to publish the results to avoid having the marketing droids make use of the info for competitor-bashing. I will have the results with me for use in deciding if we want documentation to "prove" that we have interoperable implementations for purposes of recommending moving the documents forward on the standards track. Please respond to me if you feel that I have left anything out (I probably have since I am typing this off the top of my head) so that I can finishing putting together the loose agenda. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jul 6 13:12:07 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28607; Mon, 6 Jul 92 13:02:33 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08404; Mon, 6 Jul 92 12:29:48 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27264; Mon, 6 Jul 92 12:21:16 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26924; Mon, 6 Jul 92 12:12:15 -0700 Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA25192; Mon, 6 Jul 92 12:11:20 -0700 Date: Mon, 6 Jul 92 14:58:34 EDT From: "William Allen Simpson" Message-Id: <516.bsimpson@angband.stanford.edu> To: big-internet@munnari.oz.au Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: CLNP/IP7 over PPP Within the PPP Working Group, we have been discussing the use of OSI protocols over PPP. Dave Katz wrote a draft over two years ago, and we are just now seeing implementations. The problem is, his proposal depends on address negotiation using an ES-IS exchange, which is not yet completed by ISO. This was fine when the implementation was already committed to ISO, but is not good if it becomes a universal IP requirement. 1) this is another area that the OSI standard isn't sufficiently complete to migrate from IP to CLNP. 2) this means that all PPP IP links will need to implement ES-IS, even if they don't adopt other parts of ISO. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jul 6 14:52:11 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01996; Mon, 6 Jul 92 14:41:51 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09276; Mon, 6 Jul 92 14:20:06 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01035; Mon, 6 Jul 92 14:11:33 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from regal.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00787; Mon, 6 Jul 92 14:04:56 -0700 Received: by regal.cisco.com; Mon, 6 Jul 92 14:04:07 -0700 Date: Mon, 6 Jul 92 14:04:07 -0700 From: Dino Farinacci Message-Id: <9207062104.AA15749@regal.cisco.com> To: bsimpson@angband.stanford.edu Cc: big-internet@munnari.oz.au, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: "William Allen Simpson"'s message of Mon, 6 Jul 92 14:58:34 EDT <516.bsimpson@angband.stanford.edu> Subject: CLNP/IP7 over PPP >> The problem is, his proposal depends on address negotiation using an >> ES-IS exchange, which is not yet completed by ISO. This was fine when >> the implementation was already committed to ISO, but is not good if it >> becomes a universal IP requirement. See ISO 10589 for router-to-x operation over point-to-point links. Dino From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 7 09:15:05 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00351; Tue, 7 Jul 92 08:59:36 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA13053; Tue, 7 Jul 92 08:40:06 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29468; Tue, 7 Jul 92 08:33:17 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from cider.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29166; Tue, 7 Jul 92 08:26:00 -0700 Received: by cider.cisco.com; Tue, 7 Jul 92 08:23:48 -0700 Date: Tue, 7 Jul 92 08:23:48 -0700 From: Dave Katz Message-Id: <9207071523.AA25885@cider.cisco.com> To: eer@cinops.xerox.com Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Edwards Reed's message of Tue, 7 Jul 1992 04:58:50 PDT <9207071158.AA21411@dnsmaster> Subject: CLNP/IP7 over PPP In general, ISO standards are not available in machine readable form (or for free); however, there are efforts underway to change this. Let's keep the flame war on this subject somewhere else, thank you. ISO 10589 (IS-IS) is available for anonymous FTP from merit.edu (pub/iso/iso10589.ps.Z) since it hasn't quite been published by Geneva yet. CLNP (ISO8473) is available, sort of; the Draft International Standard version was published as an RFC back in '88 or so. This isn't good enough to be implemented from (there is a technical change in Record Route, at least) but should be good enough to give a feel for the curious. ES-IS (ISO 9542) has in fact been "completed" by ISO; it's been an international standard for several years now. The one part of it that is still in progress is the Address Administration addendum, which effectively is RARP. The ARP/ICMP redirect/Router discovery equivalent is done and widely implemented, as is the mechanism that systems (that might not be running IS-IS) would use to identify one another across a PPP link. ES-IS is *not* a big deal, and is superior to the equivalents in the internet suite (so there, I said it, flame me). From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 7 09:33:38 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01082; Tue, 7 Jul 92 09:20:22 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA13391; Tue, 7 Jul 92 08:59:55 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00150; Tue, 7 Jul 92 08:52:34 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from cider.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29647; Tue, 7 Jul 92 08:40:36 -0700 Received: by cider.cisco.com; Tue, 7 Jul 92 08:39:47 -0700 Date: Tue, 7 Jul 92 08:39:47 -0700 From: Dave Katz Message-Id: <9207071539.AA25942@cider.cisco.com> To: bsimpson@angband.stanford.edu Cc: big-internet@munnari.oz.au, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: "William Allen Simpson"'s message of Mon, 6 Jul 92 14:58:34 EDT <516.bsimpson@angband.stanford.edu> Subject: CLNP/IP7 over PPP ES-IS has been a full international standard for a number of years now. The only part of it that is still in progress is the address administration stuff (like RARP). The current ES-IS is just fine for the exchange of address information (and isn't even necessary for routers running IS-IS, which has its own mechanism), as well as router discovery and redirect. Where's the problem? Every existing CLNP implementation that I've seen has an ES-IS implementation sitting right beside it, and it's not exactly rocket science to implement. C'mon, there's plenty of other things to worry/complain/flame about without canards like this. Sender: ietf-ppp-request@ucdavis.edu Date: Mon, 6 Jul 92 14:58:34 EDT From: "William Allen Simpson" Within the PPP Working Group, we have been discussing the use of OSI protocols over PPP. Dave Katz wrote a draft over two years ago, and we are just now seeing implementations. The problem is, his proposal depends on address negotiation using an ES-IS exchange, which is not yet completed by ISO. This was fine when the implementation was already committed to ISO, but is not good if it becomes a universal IP requirement. 1) this is another area that the OSI standard isn't sufficiently complete to migrate from IP to CLNP. 2) this means that all PPP IP links will need to implement ES-IS, even if they don't adopt other parts of ISO. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 7 12:53:56 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07826; Tue, 7 Jul 92 12:43:20 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01515; Tue, 7 Jul 92 10:00:42 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02109; Tue, 7 Jul 92 09:52:31 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from MrBill.CAnet.CA by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01966; Tue, 7 Jul 92 09:47:46 -0700 Received: by MrBill.CAnet.CA id <105514>; Tue, 7 Jul 1992 12:46:49 +0100 From: Dennis Ferguson To: eer@cinops.xerox.com Subject: Re: CLNP/IP7 over PPP Cc: dino@cisco.com, ietf-ppp@ucdavis.ucdavis.edu Message-Id: <92Jul7.124649bst.105514@MrBill.CAnet.CA> Date: Tue, 7 Jul 1992 12:46:43 +0100 > Ok - here's a good neophyte question - exactly HOW would I see ISO 10589. For 10589, which is the standard for IS-IS, you could try merit.edu, file pub/iso/iso10589.ps. The problem is that this isn't going to provide you with the big picture without a half dozen or so other prerequisites on hand (ISO 8348 and addenda, for CLNS and addressing, ISO 8473 for CLNP and ISO 9542 for ES-IS at the very least). I've only ever seen the latter in dead tree form. Actually the dead tree stuff is kind of expensive as well. While I would never recommend violating anyone's copyright, buying A4 paper and a paper tray for your photocopier is probably a good investment for the Internet engineering shop of the future. Dennis Ferguson From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 7 13:12:40 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08715; Tue, 7 Jul 92 13:09:53 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA03149; Tue, 7 Jul 92 12:09:35 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06532; Tue, 7 Jul 92 12:02:15 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06327; Tue, 7 Jul 92 11:57:01 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA05066; Tue, 7 Jul 92 11:56:08 PDT Date: Tue, 7 Jul 92 11:56:08 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9207071856.AA05066@ray.lloyd.com> To: dkatz@cisco.com Cc: eer@cinops.xerox.com, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Dave Katz's message of Tue, 7 Jul 92 08:23:48 -0700 <9207071523.AA25885@cider.cisco.com> Subject: CLNP/IP7 over PPP Sender: ietf-ppp-request@ucdavis.edu Date: Tue, 7 Jul 92 08:23:48 -0700 From: Dave Katz ES-IS is *not* a big deal, and is superior to the equivalents in the internet suite (so there, I said it, flame me). Hmmm ... possible, but unlikely. ;-) Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 7 14:45:00 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11663; Tue, 7 Jul 92 14:39:07 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04553; Tue, 7 Jul 92 14:19:46 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10690; Tue, 7 Jul 92 14:11:37 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from bridge2.NSD.3Com.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10397; Tue, 7 Jul 92 14:02:36 -0700 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA18740 (5.65c/IDA-1.4.4nsd for ); Tue, 7 Jul 1992 14:01:38 -0700 Received: by jaspar.NSD.3Com.COM id AA04631 (5.65c/IDA-1.4.4-910730); Tue, 7 Jul 1992 14:01:36 -0700 Date: Tue, 7 Jul 1992 14:01:36 -0700 From: "Cyndi M. Jung" Message-Id: <199207072101.AA04631@jaspar.NSD.3Com.COM> To: brian@lloyd.com Subject: Re: CLNP/IP7 over PPP Cc: ietf-ppp@ucdavis.ucdavis.edu From: brian@lloyd.com (Brian Lloyd) To: dkatz@cisco.com Sender: ietf-ppp-request@ucdavis.edu Date: Tue, 7 Jul 92 08:23:48 -0700 From: Dave Katz ES-IS is *not* a big deal, and is superior to the equivalents in the internet suite (so there, I said it, flame me). Hmmm ... possible, but unlikely. ;-) Brian Lloyd Well, this one is on-line, as well as CLNP, as RFC 995 and 994, respectively, so you don't need to be victimized by ISOs publication policies. It doesn't take a lot of imagination to see elements of IP in the CLNP specification, and everything you have ever found useful in ARP and ICMP expressed in the ES-IS spec., though credit is due to RFC 1139 for providing the ECHO function. Cyndi Jung 3Com Corporation From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 7 15:22:48 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13042; Tue, 7 Jul 92 15:19:50 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05019; Tue, 7 Jul 92 14:59:45 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12065; Tue, 7 Jul 92 14:50:27 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from bridge2.NSD.3Com.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11716; Tue, 7 Jul 92 14:40:51 -0700 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA19933 (5.65c/IDA-1.4.4nsd for ); Tue, 7 Jul 1992 14:40:00 -0700 Received: by jaspar.NSD.3Com.COM id AA04684 (5.65c/IDA-1.4.4-910730); Tue, 7 Jul 1992 14:39:58 -0700 Date: Tue, 7 Jul 1992 14:39:58 -0700 From: "Cyndi M. Jung" Message-Id: <199207072139.AA04684@jaspar.NSD.3Com.COM> To: dennis@MrBill.CAnet.CA Subject: Re: CLNP/IP7 over PPP Cc: ietf-ppp@ucdavis.ucdavis.edu From: Dennis Ferguson To: eer@cinops.xerox.com > Ok - here's a good neophyte question - exactly HOW would I see ISO 10589. For 10589, which is the standard for IS-IS, you could try merit.edu, file pub/iso/iso10589.ps. The problem is that this isn't going to provide you with the big picture without a half dozen or so other prerequisites on hand (ISO 8348 and addenda, for CLNS and addressing, ISO 8473 for CLNP and ISO 9542 for ES-IS at the very least). I've only ever seen the latter in dead tree form. So now you know there have been activities over the past 8 years trying to put at least the CLNP documents into your hands - for "free." The only one that hasn't been rendered machine-readable is 8348 and its addenda, but I've really only made extensive use of the second addendum covering Addressing. As far as the "Big Picture" goes, 10589 does provide it better than any of the other specs, by laying out the relationship between the routing protocol and the addressing architecture, which is how the big picture of CLNP differs substantially from the big picture of IP. It isn't just longer addresses. Cyndi Jung 3Com Corporation From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 7 15:22:55 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13046; Tue, 7 Jul 92 15:19:52 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05092; Tue, 7 Jul 92 15:04:54 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12074; Tue, 7 Jul 92 14:50:48 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11743; Tue, 7 Jul 92 14:41:55 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA06604; Tue, 7 Jul 92 14:39:09 PDT Date: Tue, 7 Jul 92 14:39:09 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9207072139.AA06604@saffron.acc.com> To: dino@cisco.com, eer@cinops.xerox.com Subject: Re: CLNP/IP7 over PPP Cc: ietf-ppp@ucdavis.ucdavis.edu >> >> Are the ISO and CCITT documents ALL available (machine readable >> >> preferred) and if so, where and for how much? >> >> I'm generally not aware of any. You can find DIS 8473 and DP 8073 in >> the RFC index. Careful; if you could, ANSI would have material for a lawsuit. You can get the un-copyrighted version that was sent off for letter ballot. There are, I understand, minor variances between the RFCs and the DIS/DP versions. Fred From ietf-ppp-request@aggie.ucdavis.edu Tue Jul 7 17:32:31 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17164; Tue, 7 Jul 92 17:25:33 -0700 Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA06541; Tue, 7 Jul 92 17:11:10 -0700 Sender: ietf-ppp-request@aggie.ucdavis.edu Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA06388; Tue, 7 Jul 92 17:04:43 -0700 From: ccskiz@aggie.ucdavis.edu (Elizabeth St. Goar) Date: Tue, 7 Jul 92 17:04:43 -0700 Message-Id: <9207080004.AA06388@aggie.ucdavis.edu> To: ietf-ppp@aggie.ucdavis.edu Subject: ---------------------- Forwarded Message Follows ---------------------- Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04894; Tue, 7 Jul 92 14:44:27 -0700 Received: from netmail.microsoft.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11638; Tue, 7 Jul 92 14:38:17 -0700 Received: by netmail.microsoft.com (5.65/25-eef) id AA16796; Tue, 7 Jul 92 14:36:54 -0700 From: tommyd@microsoft.com Message-Id: <9207072136.AA16796@netmail.microsoft.com> X-Msmail-Message-Id: 8369BA0A X-Msmail-Parent-Message-Id: DF0BEAFB X-Msmail-Conversation-Id: DF0BEAFB X-Msmail-Fixed-Font: 0001 X-Msmail-Wiseremark: Microsoft Mail -- 3.0.620 To: ietf-ppp-request@ucdavis.ucdavis.edu Date: Tue, 7 Jul 92 13:49:18 PDT Subject: RE: Compression Proposal Ooops, I obviously meant... #define V42BIS_COMPRESSION 0x01 #define SPLAYTREE_COMPRESSION 0x02 #define ZIP_COMPRESSION 0x04 #define ARITHMETIC_COMPRESSION 0x08 .. in my pervious email. --Thomas From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 7 19:12:59 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20396; Tue, 7 Jul 92 19:08:29 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07079; Tue, 7 Jul 92 18:49:44 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19478; Tue, 7 Jul 92 18:41:15 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from GINGER.LCS.MIT.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19392; Tue, 7 Jul 92 18:37:40 -0700 Received: by ginger.lcs.mit.edu id AA21611; Tue, 7 Jul 92 21:36:28 -0400 Date: Tue, 7 Jul 92 21:36:28 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207080136.AA21611@ginger.lcs.mit.edu> To: cmj@nsd.3com.com, dennis@mrbill.canet.ca Subject: Re: CLNP/IP7 over PPP Cc: ietf-ppp@ucdavis.ucdavis.edu, jnc@ginger.lcs.mit.edu how the big picture of CLNP differs substantially from the big picture of IP. It isn't just longer addresses. Are you speaking here of the semantics of the layer 3, or the routing and addressing architecture, or what? My memory was that the difference between IP and CLNP in terms of semantics was pretty minimal; more room for options, fragmentation fields are optional, and longer addresses in CLNP. The IAB document sort of confirms this, when it lists all the limits CLNP and IP have in common (max packet length, message id size, ttl size, etc, etc). Can you clarify? Noel From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 7 19:31:39 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20868; Tue, 7 Jul 92 19:24:27 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07170; Tue, 7 Jul 92 19:09:43 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20174; Tue, 7 Jul 92 19:01:21 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19857; Tue, 7 Jul 92 18:52:31 -0700 Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA26630; Tue, 7 Jul 92 18:51:29 -0700 Date: Tue, 7 Jul 92 18:58:44 EDT From: "William Allen Simpson" Message-Id: <531.bsimpson@angband.stanford.edu> To: big-internet@munnari.oz.au Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: CLNP/IP7 over PPP > From: Dave Katz > ES-IS has been a full international standard for a number of years now. > The only part of it that is still in progress is the address administration > stuff (like RARP). The current ES-IS is just fine for the exchange of > address information (and isn't even necessary for routers running IS-IS, > which has its own mechanism), as well as router discovery and redirect. > Where's the problem? > The problem is that the IAB messages assured us that NO OTHER PART of the OSI suite would need to be implemented. We were asked to identify places where this was not so. I have just identified one. > Every existing CLNP implementation that I've seen has an ES-IS implementation > sitting right beside it, and it's not exactly rocket science to implement. > But how many IP installations have already implemented ES-IS? And how will this interact with the other Internet Suite protocols that duplicate those functions? Every IP system has to run both in parallel for ages to come. Since I don't have the slightest idea what ES-IS looks like, I can't make any judgement call. I just have to raise the issues so that I can get the answers from others. > C'mon, there's plenty of other things to worry/complain/flame about without > canards like this. > As I said, I'm identifying problems. In particular, this is a problem for the PPP working group. Since we may be required to support CLNP/IP7 without ES-IS, we may have to add more configuration options to OSI over PPP, a document that we thought was finished. As an alternative, we may need to send IP7 packets as a completely separate protocol flavor from CLNP. This abrogates some of the claimed advantages for CLNP/IP7. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 7 20:14:29 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22199; Tue, 7 Jul 92 20:05:22 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07289; Tue, 7 Jul 92 19:49:35 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21400; Tue, 7 Jul 92 19:40:35 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from bridge2.NSD.3Com.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21264; Tue, 7 Jul 92 19:36:07 -0700 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA28561 (5.65c/IDA-1.4.4nsd for ); Tue, 7 Jul 1992 19:35:05 -0700 Received: by jaspar.NSD.3Com.COM id AA04927 (5.65c/IDA-1.4.4-910730); Tue, 7 Jul 1992 19:34:33 -0700 Date: Tue, 7 Jul 1992 19:34:33 -0700 From: "Cyndi M. Jung" Message-Id: <199207080234.AA04927@jaspar.NSD.3Com.COM> To: jnc@ginger.lcs.mit.edu Subject: Re: CLNP/IP7 over PPP Cc: ietf-ppp@ucdavis.ucdavis.edu From: jnc@ginger.lcs.mit.edu (Noel Chiappa) how the big picture of CLNP differs substantially from the big picture of IP. It isn't just longer addresses. Are you speaking here of the semantics of the layer 3, or the routing and addressing architecture, or what? My memory was that the difference between IP and CLNP in terms of semantics was pretty minimal; more room for options, fragmentation fields are optional, and longer addresses in CLNP. The IAB document sort of confirms this, when it lists all the limits CLNP and IP have in common (max packet length, message id size, ttl size, etc, etc). Can you clarify? Noel I recommended 10589 to get a real idea of the difference in the addressing and routing architecture. It still might not be immediately clear from the reading, but the notion of an AREA in IS-IS has a big impact on addressing. A router needs only 1 network address, no matter how many different network interfaces it has. If you view the address as having 2 parts, an AREA part and a SYSTEM part, then the AREA can span many network segments, including many routers and end stations (how many? more than enough). Some of the benefits of this is that relocation of end stations within the same AREA does not require a change of address. Also, those plentiful addresses are conserved even further, allowing for both administrative and topological information to be carried in them. You can't get this out of the CLNP spec - it doesn't relate addresses to routing. Semantically, CLNP is virtually identical to IP, syntactically it is quite different. I prefer the fragmentation in CLNP - it lets you know how big the entire PDU is, which may help tune reassembly, but it's probably too fine a detail. Cyndi Jung 3Com Corporation From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 7 20:30:49 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22857; Tue, 7 Jul 92 20:26:04 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07347; Tue, 7 Jul 92 20:09:43 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22053; Tue, 7 Jul 92 20:01:23 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from GINGER.LCS.MIT.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21888; Tue, 7 Jul 92 19:57:15 -0700 Received: by ginger.lcs.mit.edu id AA21978; Tue, 7 Jul 92 22:56:23 -0400 Date: Tue, 7 Jul 92 22:56:23 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207080256.AA21978@ginger.lcs.mit.edu> To: bsimpson@angband.stanford.edu, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: CLNP/IP7 over PPP Cc: jnc@ginger.lcs.mit.edu Since we may be required to support CLNP/IP7 without ES-IS... As an alternative, we may need to send IP7 packets as a completely separate protocol flavor If if were you guys, I wouldn't waste a lot of cycles just yet discussing how to support IP7. My personal sense is that IP7, as mooted by the IAB, is not going to happen soon (i.e. within 6 months), if ever. There are some *very* big Indians on the warpath about this... (Obligatory apology for any insult offered to Native Americans, or whatever the term du jour is). Noel From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 7 21:00:23 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23785; Tue, 7 Jul 92 20:57:31 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07485; Tue, 7 Jul 92 20:39:42 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23069; Tue, 7 Jul 92 20:30:40 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from cider.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22887; Tue, 7 Jul 92 20:27:19 -0700 Received: by cider.cisco.com; Tue, 7 Jul 92 20:26:28 -0700 Date: Tue, 7 Jul 92 20:26:28 -0700 From: Dave Katz Message-Id: <9207080326.AA19702@cider.cisco.com> To: bsimpson@angband.stanford.edu Cc: big-internet@munnari.oz.au, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: "William Allen Simpson"'s message of Tue, 7 Jul 92 18:58:44 EDT <530.bsimpson@angband.stanford.edu> Subject: CLNP/IP7 over PPP Well, the choices would seem to be: (1) Invent a new protocol (2) Extend existing protocols to handle NSAP addresses (probably the same as (1)) (3) Use ES-IS as is If I were an implementor, which of these three approaches would appear to give the most return? Of the three of these, which is most likely to already have been done? The problem is that the IAB messages assured us that NO OTHER PART of the OSI suite would need to be implemented. We were asked to identify places where this was not so. I have just identified one. It's not the case that it's necessary to use ES-IS, it's just smart. The fact that the letters "OSI" appear to be anathema to you doesn't make the reinvention of yet another wheel a good idea. But how many IP installations have already implemented ES-IS? And how will this interact with the other Internet Suite protocols that duplicate those functions? Every IP system has to run both in parallel for ages to come. ES-IS is available in BSD Reno for those who don't have the patience to do it themselves. How many of these installations have implemented CLNP/IPv7? Those that have CLNP already have ES-IS. Those that don't have IPv7 will have to implement it, and while they're in there they'll have to implement *something* for address resolution and all that stuff. May as well be something they can use for other things. There are many systems out there that are already dual, and they're working just fine. Since I don't have the slightest idea what ES-IS looks like, I can't make any judgement call. I just have to raise the issues so that I can get the answers from others. Perhaps you should take a look at it. I'm sure that there are a number of helpful people in your neck of the woods that could give you a hand. You and I both know a number of nice folks in large midwestern university towns. In particular, this is a problem for the PPP working group. Since we may be required to support CLNP/IP7 without ES-IS, we may have to add more configuration options to OSI over PPP, a document that we thought was finished. The document as it exists should go forward as it is. If in fact somebody is crazy enough to "require" supporting CLNP without ES-IS, then the issue can be revisited. Certainly more options can be added after the fact. This is a non-problem--there would seem to me to be nothing unique to PPP in this situation. As an alternative, we may need to send IP7 packets as a completely separate protocol flavor from CLNP. This abrogates some of the claimed advantages for CLNP/IP7. If it looks, wags, barks, and rolls in smelly stuff like CLNP, it would seem to be the height of silliness to make technical changes to support the illusion that it is something else. From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 8 12:41:42 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16478; Wed, 8 Jul 92 12:38:59 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA13114; Wed, 8 Jul 92 11:49:49 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14472; Wed, 8 Jul 92 11:40:58 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14184; Wed, 8 Jul 92 11:32:44 -0700 Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA27406; Wed, 8 Jul 92 11:30:04 -0700 Date: Wed, 8 Jul 92 12:13:36 EDT From: "William Allen Simpson" Message-Id: <537.bsimpson@angband.stanford.edu> To: ietf-ppp@ucdavis.ucdavis.edu Cc: eer@cinops.xerox.com, jlarson@parc.xerox.com Subject: Re: CLNP/IP7 over PPP > Does a PPP 'terminal server' implementation for a networked protocol imply > that routing for that protocol is indeed being performed by the terminal > server? Thus, if an hypothetical PPP-XNS implementation is created, is it > assumed by others that an XNS routing function is also mandated? > PPP doesn't specify. It tries to be all things to all people, and limits the "requirements" to link-layer stuff. It has "options" at the network layer. At the network layer, you can be of the bridging faith, routing faith, or whatever. I've never used XNS. Never heard of SPTP. Sounds interesting. Wonder if that's where Drew got some of his basic ideas for the layering? > What concerns me is that by the time someone is trying to run TCP/IP, XNS, > CLNP, and (say, Novell or NETBios) over a serial link > (9.6, 19.2, or ISDN BRI at 64 or 128k), it's going to take a hefty little > box just to run all the appropriate routing algorithms. And, because it's > TCP/IP, it will have to handle RIP, OSPF, IGRP and/or any other variation > a vendor needs to sell into. Now, I suppose we add IPX, XNS, and IS-IS > routing, to boot. > Yes, but the major influences asking for PPP were router vendors. They needed a common link-layer to run all of those market niches. The first BOF was convened in Mike Ballard's hotel room. He was/is also a driving force behind the NetBlazer. The NetBlazer supports IP, IPX and AppleTalk (or will RSN). So it can be done, on a relatively inexpensive platform. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 8 13:43:36 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01726; Wed, 8 Jul 92 13:34:59 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA14088; Wed, 8 Jul 92 13:00:40 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00244; Wed, 8 Jul 92 12:52:40 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16507; Wed, 8 Jul 92 12:40:06 -0700 Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA27530; Wed, 8 Jul 92 12:38:57 -0700 Date: Wed, 8 Jul 92 15:30:22 EDT From: "William Allen Simpson" Message-Id: <541.bsimpson@angband.stanford.edu> To: big-internet@munnari.oz.au Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: CLNP/IP7 over PPP > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > If we're going to have a discussion about potential difficulties with > IP7, that's fine, but let's keep it on Big-I. Actually, I think this issue is completely plumbed. Fred's and Dave's comments cover everything I was asking. > Since it is not yet clear that IP-7 is going to happen, in the way > the IAB posited in its draft, let's keep it off the PPP list, OK, which > I'd prefer if it concentrated on documents it is working on? PPP just asked for "last call" on OSI/PPP a couple of weeks ago. I think the plan should be "we'll add it later if we have to", and go ahead with OSI/PPP as drafted. > Not trying to stifle discussion, just tired of getting multiple > copies of things! > me, too. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 8 17:41:53 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09745; Wed, 8 Jul 92 17:35:15 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17530; Wed, 8 Jul 92 17:20:04 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08897; Wed, 8 Jul 92 17:12:04 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08472; Wed, 8 Jul 92 16:59:47 -0700 Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA27744; Wed, 8 Jul 92 16:58:46 -0700 Date: Wed, 8 Jul 92 18:44:31 EDT From: "William Allen Simpson" Message-Id: <543.bsimpson@angband.stanford.edu> To: internet-drafts@nri.reston.va.us Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: ppp-ipx-simpson draft We have a problem. Over 8 months ago, a group of folks from Shiva posted a draft for IPX over PPP. It left some features undocumented, and its authors didn't update it by the time of the next IETF. It expired. Another group from Novell posted a different draft which eliminated all of the options in the previous draft, and required folks to buy proprietary Novell software. This draft wiped out the previous draft in your directories. Some vendors had started to implement to the first draft. In March, the chair asked the two parties to publish a compromise document. They did not. I have written a compromise document. Please publish it in place of the other two drafts, or beside them with the name -simpson after it. The document may be found at angband.stanford.edu:pub/ppp/ipxcp.txt Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 8 18:41:35 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11806; Wed, 8 Jul 92 18:38:58 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17833; Wed, 8 Jul 92 18:19:35 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10979; Wed, 8 Jul 92 18:10:30 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from CAYMAN.CAYMAN.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10691; Wed, 8 Jul 92 18:01:19 -0700 Received: from haiti.Cayman.COM (moon-patrol.cayman.com) by cayman.Cayman.COM (4.1/SMI-4.0) id AA23383; Wed, 8 Jul 92 21:00:24 EDT Received: from localhost by haiti.Cayman.COM (4.1/SMI-4.1) id AA20144; Wed, 8 Jul 92 21:04:22 EDT Message-Id: <9207090104.AA20144@haiti.Cayman.COM> To: internet-drafts@nri.reston.va.us Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: new PPP ATCP draft available Date: Wed, 08 Jul 92 21:04:22 -0400 From: brad@Cayman.COM There is a new draft of the AppleTalk-over-PPP text on ftp.cayman.com in "pub/ppp/ppp-atcp-jul-08-92". (I would like this file to be put up for ftp in the internet-drafts directories) This is the latested draft and hopefully *very* close to being final. Many thanks to Bill Simpson for his editing, coaching and help. -Brad Parker From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 8 22:30:43 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19302; Wed, 8 Jul 92 22:26:46 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA18870; Wed, 8 Jul 92 22:09:37 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18562; Wed, 8 Jul 92 22:00:19 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18433; Wed, 8 Jul 92 21:57:34 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA07075; Wed, 8 Jul 92 21:56:41 PDT Date: Wed, 8 Jul 92 21:56:41 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9207090456.AA07075@ray.lloyd.com> To: bsimpson@angband.stanford.edu Cc: internet-drafts@nri.reston.va.us, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: "William Allen Simpson"'s message of Wed, 8 Jul 92 18:44:31 EDT <543.bsimpson@angband.stanford.edu> Subject: ppp-ipx-simpson draft Yes, please publish Bill Simpson's draft for IPX over PPP as *the* draft. Thanks. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 9 06:50:35 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01016; Thu, 9 Jul 92 06:46:55 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA20448; Thu, 9 Jul 92 06:19:34 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29923; Thu, 9 Jul 92 06:10:22 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from babyoil.ftp.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29831; Thu, 9 Jul 92 06:04:19 -0700 Received: from stev.d-cell.ftp.com by ftp.com via PCMAIL with DMSP id AA22435; Thu, 9 Jul 92 08:44:43 -0400 Date: Thu, 9 Jul 92 08:44:43 -0400 Message-Id: <9207091244.AA22435@ftp.com> To: dkatz@cisco.com Subject: Re: CLNP/IP7 over PPP From: stev@ftp.com (stev knowles) Cc: ietf-ppp@ucdavis.ucdavis.edu Repository: babyoil.ftp.com Originating-Client: d-cell.ftp.com ES-IS is *not* a big deal, and is superior to the equivalents in the internet suite (so there, I said it, flame me). sorry, while it solves some interesting problems (gateway discovery and dead gateway fallover) anything that has broadcasts every N seconds is not going to scale well. oh, i'm sorry, was this suppose to be a flame:)? From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 9 09:13:14 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05055; Thu, 9 Jul 92 09:06:38 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA21790; Thu, 9 Jul 92 08:35:29 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03829; Thu, 9 Jul 92 08:27:21 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from sonny.proteon.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03499; Thu, 9 Jul 92 08:16:07 -0700 Received: by sonny.proteon.com (5.59/1.7) id AA17516; Thu, 9 Jul 92 11:14:25 EDT Date: Thu, 9 Jul 92 11:14:25 EDT From: jas@proteon.com (John A. Shriver) Message-Id: <9207091514.AA17516@sonny.proteon.com> To: bsimpson@angband.stanford.edu Cc: internet-drafts@nri.reston.va.us, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: "William Allen Simpson"'s message of Wed, 8 Jul 92 18:44:31 EDT <543.bsimpson@angband.stanford.edu> Subject: ppp-ipx-simpson draft A technical nit on this draft. It states: IPX-Node-Number The six octet IPX-Node-Number is the desired local IPX node number of the sender of the Configure-Request. If no more specific number has been assigned, the node number will be the 4 bytes of WNode ID followed by 2 bytes of zero. I'd think it might be wiser to "right justify" the WNode ID in the 6 byte IPX address. (Preceeded by two bytes of 0.) That would be consistent with every other LAN implementation of IPX for LANs with a less than 6 byte MAC address. For instance, ProNET-10 has it's one byte node address palced in the sixth byte of the IPX address, not the first. From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 9 09:32:52 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05592; Thu, 9 Jul 92 09:23:31 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA22173; Thu, 9 Jul 92 08:59:45 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04642; Thu, 9 Jul 92 08:52:23 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [132.151.1.35] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04531; Thu, 9 Jul 92 08:47:23 -0700 Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa04615; 9 Jul 92 11:36 EDT To: brad@cayman.com, brian@lloyd.com Cc: internet-drafts@NRI.Reston.VA.US, ietf-ppp@ucdavis.ucdavis.edu, gvaudre@NRI.Reston.VA.US Subject: Re: new PPP ATCP draft available In-Reply-To: Your message of "Wed, 08 Jul 92 21:04:22 EDT." <9207090104.AA20144@haiti.Cayman.COM> Date: Thu, 09 Jul 92 11:36:21 -0400 From: Greg Vaudreuil Message-Id: <9207091136.aa04615@IETF.NRI.Reston.VA.US> Arrrg! I received a request from the PPP chair last Thursday to issue a last call for the Appletalk over IP document and it went out a couple of days ago. Now I get a new version. Were these changes expected and I jumped the gun or what? Enjoying the week before IETF, Greg Vaudreuil IESG Secretary From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 9 12:04:45 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10842; Thu, 9 Jul 92 11:59:43 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA23213; Thu, 9 Jul 92 10:19:39 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07234; Thu, 9 Jul 92 10:12:41 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from bridge2.NSD.3Com.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06915; Thu, 9 Jul 92 10:03:00 -0700 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA26727 (5.65c/IDA-1.4.4nsd for ); Thu, 9 Jul 1992 10:02:00 -0700 Received: by jaspar.NSD.3Com.COM id AA06345 (5.65c/IDA-1.4.4-910730); Thu, 9 Jul 1992 10:01:28 -0700 Date: Thu, 9 Jul 1992 10:01:28 -0700 From: "Cyndi M. Jung" Message-Id: <199207091701.AA06345@jaspar.NSD.3Com.COM> To: stev@ftp.com Subject: Re: CLNP/IP7 over PPP Cc: ietf-ppp@ucdavis.ucdavis.edu >To: dkatz@cisco.com >From: stev@ftp.com (stev knowles) ES-IS is *not* a big deal, and is superior to the equivalents in the internet suite (so there, I said it, flame me). >sorry, while it solves some interesting problems (gateway discovery and dead >gateway fallover) anything that has broadcasts every N seconds is not going >to scale well. But the broadcasts are restricted to the segment, and the general trend is towards higher segmentation (fewer systems on a single cable), so the possible scaling issue is diminishing - it could have been a problem if the trend had gone towards larger and larger bridged LANs (like 18000 node LANs), but fortunately the state-of-the-art of routing has improved enough over the last 5 years that *most* people don't try to build that kind of network anymore. Cyndi Jung 3Com Corporation From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 9 12:22:56 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11083; Thu, 9 Jul 92 12:05:30 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA23341; Thu, 9 Jul 92 10:31:19 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07741; Thu, 9 Jul 92 10:28:43 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07385; Thu, 9 Jul 92 10:16:11 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA07776; Thu, 9 Jul 92 10:15:19 PDT Date: Thu, 9 Jul 92 10:15:19 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9207091715.AA07776@ray.lloyd.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: agenda next week Sometime during the week: IPX stuff off-line. I expect Bill Simpson, Chris Ranch, Marty Del Vecchio, and Mark Lewis to hammer on Bill's doc that merges the Novell and Shiva proposals. This should happen before Wednesday. 9:30-12:00 Tuesday (7/14) General "stuff" Overview of where the documents stand Review of interoperability testing (Mark Lewis should get up and talk about the bake-off at Telebit) LAPB Compression 9:30-12:00 Wednesday (7/15) IPX MIB(s) leftovers from Tuesday Please let me know if anyone feels a need to add anything. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 9 12:58:15 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12000; Thu, 9 Jul 92 12:31:38 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA00780; Thu, 9 Jul 92 12:09:48 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10973; Thu, 9 Jul 92 12:02:12 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from monk.proteon.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10649; Thu, 9 Jul 92 11:52:19 -0700 Received: by monk.proteon.com (5.65/1.8) id AA23122; Thu, 9 Jul 92 13:40:30 -0400 Date: Thu, 9 Jul 92 13:40:30 -0400 From: jmoy@proteon.com (John Moy) Message-Id: <9207091740.AA23122@monk.proteon.com> To: stev@ftp.com Cc: dkatz@cisco.com, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: (stev knowles's message of Thu, 9 Jul 92 08:44:43 -0400 <9207091244.AA22435@ftp.com> Subject: CLNP/IP7 over PPP Stev, I too would not want ES-IS running on my network. That's not to say that I think that it is a badly designed protocol. On the contrary, if IP routed to individual hosts instead of network segments, as OSI does, I think that we would have ended up with something like ES-IS too. Fortunately, IP doesn't route to individual hosts. At least not yet :-). John From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 9 12:58:45 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12237; Thu, 9 Jul 92 12:40:17 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA23452; Thu, 9 Jul 92 10:46:22 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08140; Thu, 9 Jul 92 10:38:45 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07670; Thu, 9 Jul 92 10:26:10 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA07798; Thu, 9 Jul 92 10:23:56 PDT Date: Thu, 9 Jul 92 10:23:56 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9207091723.AA07798@ray.lloyd.com> To: stev@ftp.com Cc: bsimpson@angband.stanford.edu, ietf-ppp@ucdavis.ucdavis.edu, eer@cinops.xerox.com, jlarson@parc.xerox.com In-Reply-To: (stev knowles's message of Thu, 9 Jul 92 10:49:14 -0400 <9207091449.AA27849@ftp.com> Subject: CLNP/IP7 over PPP Sender: ietf-ppp-request@ucdavis.edu Date: Thu, 9 Jul 92 10:49:14 -0400 From: stev@ftp.com (stev knowles) Repository: babyoil.ftp.com Originating-Client: d-cell.ftp.com The first BOF was convened in Mike Ballard's hotel room. He was/is also a driving force behind the NetBlazer. The NetBlazer supports IP, IPX and AppleTalk (or will RSN). So it can be done, on a relatively inexpensive platform. at interop87, at the crystal city marriot in virginia. as one of the (probably) few people on this list at that meeting, i would like to point out that it wasnt a PPP meeting, it was a son of slip meeting. it is a pity that the protocol we designed there never saw the light of day, would have been much better than PPP, IMHO. A rose by any other name still stinks. ;-) Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 9 12:59:30 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12522; Thu, 9 Jul 92 12:48:53 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA00845; Thu, 9 Jul 92 12:17:53 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11044; Thu, 9 Jul 92 12:04:33 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10836; Thu, 9 Jul 92 11:59:29 -0700 Received: from sjfsmtp.novell.com by newsun.novell.com (4.1/smi4.1.1.v91190) id AA20193; Thu, 9 Jul 92 11:58:31 PDT Message-Id: <9207091858.AA20193@newsun.novell.com> From: MALLEN.NOVELL@sjfsmtp.ucdavis.edu (MALLEN) To: ietf-ppp@ucdavis.ucdavis.edu (X) Subject: IPXWAN is freely available Date: Thu, 09 Jul 92 11:50 >Another group from Novell posted a different draft which eliminated all of >the options in the previous draft, and required folks to buy proprietary >Novell software. This draft wiped out the previous draft in your >directories. Novell is NOT requiring anyone to BUY anything for WAN interconnectivity. We have published the IPXCP & IPXWAN documents which fully explain to any router developer how to interoperate with Novell. However, a router implementor needing to know the RIP/SAP protocol for Novell may have to attend an SDK developers class to get relevant documentation. Thanks also to John Shriver (Proteon) for also stating this point. Regards, Michael Allen, Novell Inc. From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 9 13:13:24 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13152; Thu, 9 Jul 92 13:07:16 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01019; Thu, 9 Jul 92 12:30:10 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11592; Thu, 9 Jul 92 12:20:32 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10920; Thu, 9 Jul 92 12:00:24 -0700 Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA28687; Thu, 9 Jul 92 11:59:07 -0700 Date: Thu, 9 Jul 92 13:56:14 EDT From: "William Allen Simpson" Message-Id: <552.bsimpson@angband.stanford.edu> To: Greg Vaudreuil Cc: internet-drafts@NRI.Reston.VA.US, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: new PPP ATCP draft available > From: Greg Vaudreuil > Arrrg! I received a request from the PPP chair last Thursday to issue > a last call for the Appletalk over IP document and it went out a > couple of days ago. Now I get a new version. Were these changes > expected and I jumped the gun or what? > No, actually, the last call was too slow. I asked for last call three weeks ago on the list. The chair only got around to asking you for last call a week ago. You took another week. Meanwhile, we've completed the last call period. Presumably we have to wait yet another two weeks for the rest of the IETF. My guess is it's ready to go to the IESG now, even if somebody else finds another typo. There are several implementations. What you *could* do is get the IETF list fixed so that it doesn't take *days* for messages to fan out to the members. This is a real problem. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 9 13:13:29 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13163; Thu, 9 Jul 92 13:07:39 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01058; Thu, 9 Jul 92 12:33:09 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11599; Thu, 9 Jul 92 12:20:40 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10929; Thu, 9 Jul 92 12:00:44 -0700 Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA28693; Thu, 9 Jul 92 11:59:39 -0700 Date: Thu, 9 Jul 92 14:08:45 EDT From: "William Allen Simpson" Message-Id: <553.bsimpson@angband.stanford.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: ppp-ipx-simpson draft > A technical nit on this draft. > > It states: > > IPX-Node-Number > > The six octet IPX-Node-Number is the desired local IPX node number > of the sender of the Configure-Request. If no more specific > number has been assigned, the node number will be the 4 bytes of > WNode ID followed by 2 bytes of zero. > > I'd think it might be wiser to "right justify" the WNode ID in the 6 > byte IPX address. (Preceeded by two bytes of 0.) That would be > consistent with every other LAN implementation of IPX for LANs with a > less than 6 byte MAC address. For instance, ProNET-10 has it's one > byte node address palced in the sixth byte of the IPX address, not the > first. > The wording is verbatim from the IPX WAN document. I wrote the PPP options to do *exactly* what IPX WAN does, to be compatible. On the other hand, maybe we prefer to be backward compatible, to offer improved service over IPX WAN? It's up to you implementors. Or maybe you can get Novell to change..... ;-> Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 9 13:43:24 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13976; Thu, 9 Jul 92 13:32:30 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01146; Thu, 9 Jul 92 12:40:04 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12192; Thu, 9 Jul 92 12:38:14 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11680; Thu, 9 Jul 92 12:23:20 -0700 Received: from napa.TELEBIT.COM by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-Brent-920708) id AA25530 to ietf-ppp@ucdavis.edu; Thu, 9 Jul 92 12:22:22 PDT Received: from yoyo.telebit.com by napa.TELEBIT.COM (4.1/napa.telebit.com-DBC-910507) id AA01373 to ietf-ppp@ucdavis.edu; Thu, 9 Jul 92 12:22:17 PDT Date: Thu, 9 Jul 92 12:22:17 PDT From: mlewis@napa.Telebit.COM (Mark S. Lewis) Message-Id: <9207091922.AA01373@napa.TELEBIT.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA04792; Thu, 9 Jul 92 12:23:26 PDT To: jas@proteon.com Cc: ietf-ppp@ucdavis.ucdavis.edu, ppp-ipx@lloyd.com In-Reply-To: <9207091511.AA17510@sonny.proteon.com> "jas@proteon.com" Subject: ppp-ipx-simpson draft > I don't know how realistic it is to try and be different from Novell, > even if it is backwards compatible. > As am implementor, I'd be very wary of doing more than Novell's > IPXCP implementation. > I don't think that many router vendors would choose to do IPX PPP > without IPX WAN, as they would not interoperate with Novell > implementations. Novell customers think that the world rotates around > Orem, Utah, just as Novell does. (Heck, they have their own trade > show!) Customers are going to laugh you out the door if you don't do > IPX WAN over PPP. (Just as they expect you to duplicate every other > feature and bug of IPX. You can't tell them that it's wierd to send > RIP packets with a PXP IPX packet type!) > I admit that the IPXCP configuration options are just options. > With IPX WAN being more important in the marketplace, they're going to > be "optioned" out by many implementors. I agree that most, if not all, vendors will have to do IPXWAN to interoperate will Novell. It simply doesn't make sense to do IPX over PPP without it. In this realm, the world does revolve around Utah. One reason to be different and provide NCP options is extensibility. This is the case with IPX-Compression-Protocol. This option provides other vendors with a standard method to build upon the protocol. We do want to use our compression protocol and this provides a means to negotiate it. Nothing against Novell, but we have much more confidence in standardizing these extensions thru the Internet process than we do getting Novell to add options to IPXWAN. I'm not sure how they would respond to such requests. The other options in Bill's IPXCP are rather redundant. IPX-Address, IPX-Routing-Protocol, and IPX-Name can all be handled with IPXWAN. If we were starting from stratch, and we didn't have any plans to extend our IPX over PPP, we would probably just do IPXWAN. ... 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 Thu Jul 9 13:44:13 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14029; Thu, 9 Jul 92 13:33:58 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01244; Thu, 9 Jul 92 12:49:46 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12343; Thu, 9 Jul 92 12:44:03 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from sonny.proteon.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12041; Thu, 9 Jul 92 12:33:10 -0700 Received: by sonny.proteon.com (5.59/1.7) id AA19623; Thu, 9 Jul 92 15:31:13 EDT Date: Thu, 9 Jul 92 15:31:13 EDT From: jas@proteon.com (John A. Shriver) Message-Id: <9207091931.AA19623@sonny.proteon.com> To: mlewis@Telebit.COM Cc: ietf-ppp@ucdavis.ucdavis.edu, ppp-ipx@lloyd.com In-Reply-To: Mark S. Lewis's message of Thu, 9 Jul 92 12:22:17 PDT <9207091922.AA01373@napa.TELEBIT.COM> Subject: ppp-ipx-simpson draft That's a very good point on the toeholds for compression, and other new features. I can agree with that. I'd say maybe the most practical thing would be to not add anything to IPXCP that is redundant to IPX WAN. After all, I already have to allow my users to set the IPX network and node numbers for my own proprietary IPX over sync implementation, if I didn't have IPX WAN, I could use that. From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 9 14:26:48 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15489; Thu, 9 Jul 92 14:15:16 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01522; Thu, 9 Jul 92 13:10:07 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13153; Thu, 9 Jul 92 13:07:19 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12814; Thu, 9 Jul 92 12:59:46 -0700 Received: from na.novell.com.novell.com by newsun.novell.com (4.1/smi4.1.1.v91190) id AA21271; Thu, 9 Jul 92 12:56:23 PDT Received: by na.novell.com.novell.com (4.1/SMI-4.1) id AA21723; Thu, 9 Jul 92 12:58:33 PDT Date: Thu, 9 Jul 92 12:58:33 PDT From: cranch@na.novell.com (Christopher Ranch) Message-Id: <9207091958.AA21723@na.novell.com.novell.com> To: jas@proteon.com, mlewis@Telebit.COM Subject: Re: ppp-ipx-simpson draft Cc: cranch@novell.com, ietf-ppp@ucdavis.ucdavis.edu, ppp-ipx@lloyd.com Hi John and Mark, and the lists, > From: mlewis@napa.Telebit.COM (Mark S. Lewis) > In-Reply-To: <9207091511.AA17510@sonny.proteon.com> "jas@proteon.com" > > > I don't know how realistic it is to try and be different from Novell, > > even if it is backwards compatible. > [ deleted for brevity] > I agree that most, if not all, vendors will have to do IPXWAN to > interoperate will Novell. It simply doesn't make sense to do IPX over > PPP without it. In this realm, the world does revolve around Utah. Only if your customers want to connect your box up to a NetWare router ;). > One reason to be different and provide NCP options is extensibility. > This is the case with IPX-Compression-Protocol. This option provides > other vendors with a standard method to build upon the protocol. We > do want to use our compression protocol and this provides a means to > negotiate it. This is a good example of added value from the NCP. > Nothing against Novell, but we have much more confidence in > standardizing these extensions thru the Internet process than we do > getting Novell to add options to IPXWAN. I'm not sure how they would > respond to such requests. We would bend over backwards to allocate your request!!! Perhaps we need stronger language in the IPXWAN draft saying this. Now, Novell implementing it on our router is a different and seperable issue. I suspect that I can beat IANA's response time, no sweat. > The other options in Bill's IPXCP are rather redundant. IPX-Address, > IPX-Routing-Protocol, and IPX-Name can all be handled with IPXWAN. If > we were starting from stratch, and we didn't have any plans to extend > our IPX over PPP, we would probably just do IPXWAN. These are there because we would like to converge on IPXCP ONCE PPP is running over all WAN links. This is being actively discussed on the iplpdn mailing list NOW, and I'll be fighting for it next week. Don't get your hopes up that we will converge anytime soon. This is at least a year out, and you all know that getting customers to upgrade their software can be impossible. IPXWAN will need to be supported for a LONG time, so you might as well do it now. > ... Mark Chris Ranch From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 9 14:27:03 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15606; Thu, 9 Jul 92 14:18:07 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01971; Thu, 9 Jul 92 13:31:08 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13646; Thu, 9 Jul 92 13:22:32 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from GINGER.LCS.MIT.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13284; Thu, 9 Jul 92 13:11:06 -0700 Received: by ginger.lcs.mit.edu id AA06717; Thu, 9 Jul 92 16:10:06 -0400 Date: Thu, 9 Jul 92 16:10:06 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207092010.AA06717@ginger.lcs.mit.edu> To: jmoy@proteon.com, stev@ftp.com Subject: Re: CLNP/IP7 over PPP Cc: dkatz@cisco.com, ietf-ppp@ucdavis.ucdavis.edu, jnc@ginger.lcs.mit.edu Guys, this is an interesting discussion, but let's move it to Big-Internet, huh? Serial lines on this mailing list..... Noel From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 9 14:42:48 1992 Received: from [128.120.2.9] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16063; Thu, 9 Jul 92 14:31:36 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA02144; Thu, 9 Jul 92 13:37:57 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13689; Thu, 9 Jul 92 13:24:00 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from cider.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13531; Thu, 9 Jul 92 13:17:22 -0700 Received: by cider.cisco.com; Thu, 9 Jul 92 13:16:13 -0700 Date: Thu, 9 Jul 92 13:16:13 -0700 From: Dave Katz Message-Id: <9207092016.AA04490@cider.cisco.com> To: jmoy@proteon.com Cc: stev@ftp.com, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: John Moy's message of Thu, 9 Jul 92 13:40:30 -0400 <9207091740.AA23122@monk.proteon.com> Subject: CLNP/IP7 over PPP Routing to hosts vs. networks is orthogonal to ES-IS, but let's not drag this out on the PPP list. There seems to be agreement that the IPv7 thing should not affect the progression of the OSI over PPP draft, which was the real issue. From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 9 14:43:45 1992 Received: from [128.120.2.9] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16147; Thu, 9 Jul 92 14:34:26 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA02309; Thu, 9 Jul 92 13:49:49 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14274; Thu, 9 Jul 92 13:41:23 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13729; Thu, 9 Jul 92 13:25:36 -0700 Received: from na.novell.com.novell.com by newsun.novell.com (4.1/smi4.1.1.v91190) id AA21850; Thu, 9 Jul 92 13:24:18 PDT Received: by na.novell.com.novell.com (4.1/SMI-4.1) id AA22173; Thu, 9 Jul 92 13:26:20 PDT Date: Thu, 9 Jul 92 13:26:20 PDT From: cranch@na.novell.com (Christopher Ranch) Message-Id: <9207092026.AA22173@na.novell.com.novell.com> To: jas@proteon.com, mlewis@Telebit.COM Subject: Re: ppp-ipx-simpson draft Cc: cranch@novell.com, ietf-ppp@ucdavis.ucdavis.edu, ppp-ipx@lloyd.com Hi Y'all, > From: jas@proteon.com (John A. Shriver) > In-Reply-To: Mark S. Lewis's message of Thu, 9 Jul 92 12:22:17 PDT <9207091922.AA01373@napa.TELEBIT.COM> > Subject: ppp-ipx-simpson draft > > That's a very good point on the toeholds for compression, and other > new features. I can agree with that. Same here. > I'd say maybe the most practical thing would be to not add anything to > IPXCP that is redundant to IPX WAN. After all, I already have to > allow my users to set the IPX network and node numbers for my own > proprietary IPX over sync implementation, if I didn't have IPX WAN, I > could use that. I strongly disagree. We need to define IPXCP to be a superset of IPXWAN, or we will never be able to converge on pure PPP once it is adopted for all (relevant/appropriate) WAN links. These are, as you say, toeholds. Comments? Chris From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 9 15:33:01 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17736; Thu, 9 Jul 92 15:22:16 -0700 Received: from [128.120.2.1] by aggie.ucdavis.edu (5.61/UCD2.04) id AA03176; Thu, 9 Jul 92 14:51:14 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16304; Thu, 9 Jul 92 14:40:36 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [143.137.50.1] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15923; Thu, 9 Jul 92 14:29:38 -0700 Received: from haiti.Cayman.COM (moon-patrol.cayman.com) by cayman.Cayman.COM (4.1/SMI-4.0) id AA08226; Thu, 9 Jul 92 17:27:20 EDT Received: by haiti.Cayman.COM (4.1/SMI-4.1) id AA20619; Thu, 9 Jul 92 17:31:25 EDT Date: Thu, 9 Jul 92 17:31:25 EDT From: brad@Cayman.COM (Brad Parker) Message-Id: <9207092131.AA20619@haiti.Cayman.COM> To: ietf-ppp@ucdavis.ucdavis.edu Cc: apple-ip@Cayman.COM, internet-drafts@nri.reston.va.us X-Zippy: If elected, Zippy pledges to each and every American a 55-year-old houseboy... Comments: Hyperbole mail buttons accepted, v3.02P. A corrected draft of the AppleTalk-over-PPP text is available for ftp from ftp.cayman.com in the file pub/ppp/ppp-atcp-jul-09-92. The changes from yesterday are *non-technical* and reflect new requirements for draft documents only. Hopefully this one has the correct text ;-) -brad From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 9 17:40:32 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22245; Thu, 9 Jul 92 17:36:37 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05073; Thu, 9 Jul 92 17:19:35 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21408; Thu, 9 Jul 92 17:11:27 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21304; Thu, 9 Jul 92 17:08:53 -0700 Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA28835; Thu, 9 Jul 92 17:07:53 -0700 Date: Thu, 9 Jul 92 18:00:03 EDT From: "William Allen Simpson" Message-Id: <555.bsimpson@angband.stanford.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: agenda next week > 9:30-12:00 Tuesday (7/14) > > General "stuff" > Overview of where the documents stand > Review of interoperability testing (Mark Lewis should get up > and talk about the bake-off at Telebit) put in AppleTalk and OSI here, we're in the "last call" period. > LAPB > Compression > > 9:30-12:00 Wednesday (7/15) > > IPX DECnet? > MIB(s) > leftovers from Tuesday > Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jul 10 09:22:56 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16703; Fri, 10 Jul 92 09:19:22 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09818; Fri, 10 Jul 92 08:59:50 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15925; Fri, 10 Jul 92 08:51:36 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from babyoil.ftp.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15767; Fri, 10 Jul 92 08:45:40 -0700 Received: from stev.d-cell.ftp.com by ftp.com via PCMAIL with DMSP id AA14394; Fri, 10 Jul 92 11:44:14 -0400 Date: Fri, 10 Jul 92 11:44:14 -0400 Message-Id: <9207101544.AA14394@ftp.com> To: cmj@NSD.3Com.COM Subject: Re: CLNP/IP7 over PPP From: stev@ftp.com (stev knowles) Cc: ietf-ppp@ucdavis.ucdavis.edu Repository: babyoil.ftp.com Originating-Client: d-cell.ftp.com But the broadcasts are restricted to the segment, and the general trend is towards higher segmentation (fewer systems on a single cable), so the possible scaling issue is diminishing - it could have been a problem if the trend had gone towards larger and larger bridged LANs (like 18000 node LANs), but fortunately the state-of-the-art of routing has improved enough over the last 5 years that *most* people don't try to build that kind of network anymore. Cyndi Jung sorry, it was designed badly. saying a program is OK because you can buy faster hardware is not an excuse for writing a sloppy program. saying that smaller lan segments is a good reason to ignore this problem isnt an answer either. i have seen sites turn on broadcast flitering in bridges because their file servers are RWHOing each other every 30 seconds. makes it kind of hard to arp. having 30 hosts emit a packet every 30 seconds (even if they are evenly spaced), *really* makes it hard to look at your network and do useful things. i wont even mention the people who may end up paying packet charges for them. From ietf-ppp-request@ucdavis.ucdavis.edu Sun Jul 12 16:20:17 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29946; Sun, 12 Jul 92 16:13:45 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA22156; Sun, 12 Jul 92 15:59:45 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29493; Sun, 12 Jul 92 15:50:34 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Sun.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29444; Sun, 12 Jul 92 15:46:16 -0700 Received: from playground.Sun.COM by Sun.COM (4.1/SMI-4.1) id AA19781; Sun, 12 Jul 92 15:45:15 PDT Received: by playground.Sun.COM (4.1/SMI-4.1) id AA03161; Sun, 12 Jul 92 18:49:05 EDT Date: Sun, 12 Jul 92 18:49:05 EDT From: kessler@Sun.COM (Tom Kessler) Message-Id: <9207122249.AA03161@playground.Sun.COM> To: "Cyndi M. Jung" Cc: stev@ftp.com, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <199207091701.AA06345@jaspar.NSD.3Com.COM> Subject: Re: CLNP/IP7 over PPP A while ago, "Cyndi M. Jung" wrote: > > > But the broadcasts are restricted to the segment, and the general trend is > towards higher segmentation (fewer systems on a single cable), so the > possible scaling issue is diminishing - it could have been a problem if > the trend had gone towards larger and larger bridged LANs (like 18000 node > LANs), but fortunately the state-of-the-art of routing has improved enough > over the last 5 years that *most* people don't try to build that kind of > network anymore. > > Cyndi Jung > 3Com Corporation > From a network management standpoint an explosion of segments is a real mess. The trend to fewer hosts on a segment could well be only a temporary phenomenon because ethernet (and token ring etc) haven't been keeping up lately. Things like FDDI, CDDI, and ATM could change this drastically. There wouldn't be a problem putting a low number of thousands of machines on a single ATM network (though it's probably a bad idea from the adminstrative standpoint). Also what happens to my super "octupus" server that has 100 ethernets on it? Must it listen to all those dreary hosts babbling to their routers about ES-IS. It's pretty lame to use a broadcast based protocol like ES-IS when far superior technology (multi-cast) exists that solves these problems. From ietf-ppp-request@ucdavis.ucdavis.edu Sun Jul 12 23:20:02 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08486; Sun, 12 Jul 92 23:14:29 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA23316; Sun, 12 Jul 92 22:59:34 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08093; Sun, 12 Jul 92 22:50:06 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from cider.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08017; Sun, 12 Jul 92 22:45:45 -0700 Received: by cider.cisco.com; Sun, 12 Jul 92 22:44:48 -0700 Date: Sun, 12 Jul 92 22:44:48 -0700 From: Dave Katz Message-Id: <9207130544.AA19600@cider.cisco.com> To: kessler@Sun.COM Cc: cmj@NSD.3Com.COM, stev@ftp.com, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Tom Kessler's message of Sun, 12 Jul 92 18:49:05 EDT <9207122249.AA03161@playground.Sun.COM> Subject: CLNP/IP7 over PPP ES-IS *is* multicast, not broadcast. Sender: ietf-ppp-request@ucdavis.edu Date: Sun, 12 Jul 92 18:49:05 EDT From: kessler@Sun.COM (Tom Kessler) It's pretty lame to use a broadcast based protocol like ES-IS when far superior technology (multi-cast) exists that solves these problems. From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jul 13 12:33:47 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27166; Mon, 13 Jul 92 12:27:58 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA28672; Mon, 13 Jul 92 12:10:19 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26497; Mon, 13 Jul 92 12:04:21 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from inet-gw-1.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26234; Mon, 13 Jul 92 11:57:14 -0700 Received: by inet-gw-1.pa.dec.com; id AA27345; Mon, 13 Jul 92 11:55:59 -0700 Received: by tl.lkg.dec.com (5.57/cgg-100491);id AA11289; Mon, 13 Jul 92 14:55:49 -0400 Received: by tl.lkg.dec.com (5.57/Ultrix3.0-C)id AA04666; Sat, 13 Jun 92 13:52:05 -0400 Date: Sat, 13 Jun 92 13:52:05 -0400 From: MAILER-DAEMON@tl.lkg.dec.com (Mail Delivery Subsystem) Subject: Returned mail: Deferred: Host is unreachable To: lauck@tl.lkg.dec.com Message-Id: <920613135207.4670@tl.lkg.dec.com> Resent-To: ietf-ppp@ucdavis.ucdavis.edu Resent-From: Tony Lauck Resent-Date: Mon, 13 Jul 92 14:55:48 -0400 Resent-Message-Id: <920713145548.11257@tl.lkg.dec.com> ----- Transcript of session follows ----- 421 ucdavis.edu.tcp... Deferred: Host is unreachable 421 isi.edu.tcp... Deferred: Host is unreachable 421 nri.reston.va.us.tcp... Deferred: Host is unreachable ----- Unsent message follows ----- Received: by tl.lkg.dec.com (5.57/Ultrix3.0-C) id AA02136; Wed, 10 Jun 92 13:15:21 -0400 X-Mailer: Poste 2.0B3 From: Tony Lauck Date: Wed, 10 Jun 92 09:51:32 -0400 Message-Id: <920610095132.269@tl.lkg.dec.com> Subject: PPP FCS negotiation option -- patent release letter To: ietf-ppp@ucdavis.edu, iab@ISI.EDU, iesg@NRI.Reston.VA.US Sender: lauck The following is a copy of a letter which is being mailed out today (to Lyman Chapin's address) from my vice president releasing Digital's 48 CRC patent for use with the PPP LCP 16/32 bit FCS negotiation option. I believe this will resolve the issue which is keeping this option from being included in RFC1331. Tony =============================================== Internet Activities Board and Internet Engineering Steering Group 150 Cambridge Park Drive Cambridge, Ma 04923 Dear IAB and IESG Members: It is the position of Digital Equipment Corporation to offer its patent rights for 48 bit CRCs to the Internet Activities Board (IAB) and its Internet Engineering Task Force (IETF) for purposes of inclusion into the Point-to-Point Protocol (PPP) being standardized by the IAB. Digital Equipment Corporation agrees to offer to independent developers a license of its patent rights prerequisite to the implmentation of the 48 bit CRC on reasonable terms for the purpose of IAB-standardized integration into the PPP protocol. Digital Equipment Corporation has already distributed documentation sufficient to support independent implementations. This documentation is available in the Internet Draft directory as draft-ietf-ppp-32bitconfig-01.txt. Sincerely yours, Michael Thurk Vice President Networks and Communications Digital Equipment Corporation From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jul 13 14:22:19 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00826; Mon, 13 Jul 92 14:15:43 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA29516; Mon, 13 Jul 92 13:49:40 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29543; Mon, 13 Jul 92 13:41:31 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from OPAL.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29358; Mon, 13 Jul 92 13:35:13 -0700 Received: by opal.acc.com (4.1/SMI-4.0) id AA05115; Mon, 13 Jul 92 13:35:21 PDT Date: Mon, 13 Jul 92 13:35:21 PDT From: art@opal.acc.com (Art Berggreen) Message-Id: <9207132035.AA05115@opal.acc.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: PPP FCS negotiation option -- patent release letter > >Digital Equipment Corporation agrees to offer to independent developers >a license of its patent rights prerequisite to the implmentation of the 48 bit >CRC on reasonable terms for the purpose of IAB-standardized integration into >the PPP protocol. > I wonder what "reasonable terms" means? Why couldn't they just authorize its use, free of charge, for PPP? I wonder how many vendors will bother with it, if there is any charge or administration required. Wasn't DEC the original proponent for standardizing this option? Art From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 15 17:14:23 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28059; Wed, 15 Jul 92 17:06:37 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA22661; Wed, 15 Jul 92 16:19:51 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26120; Wed, 15 Jul 92 16:11:28 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from nsco.network.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25805; Wed, 15 Jul 92 16:01:53 -0700 Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA19310; Wed, 15 Jul 92 18:03:01 -0500 Received: from eros.network.com by anubis.network.com (4.0/SMI-4.0) id AA29938; Wed, 15 Jul 92 18:00:35 CDT Date: Wed, 15 Jul 92 18:00:35 CDT From: sjs@anubis.network.com (Steve Senum) Message-Id: <9207152300.AA29938@anubis.network.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: New draft of DECnet over PPP Cc: brian@lloyd.com, bsimpson@angband.stanford.edu The following is a new draft of DECnet over PPP. This draft reflects fairly minor changes requested at the current IETF meeting in Boston, as relayed to me by Craig Fox. I will wait until next week before having this moved into the internet drafts directory, as I know quite a few people from this group are at the current IETF meeting. After that, a last call will hopefully be issued, so please send any comments to me ASAP. Steve Senum, sjs@network.com, 612-493-1098 --------------- Network Working Group Steven J. Senum Request for Comments: Internet Draft Network Systems Corporation July 15, 1992 Point-to-Point Protocol Extensions for DECnet Phase IV Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other that as a ``working draft'' or ``work in progress.'' Please check the 1id- abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. This proposal is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list. The expiration date is 1/22/93. Distribution of this memo is unlimited. Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the NCP for establishing and configuring Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP. This document applies only to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc). Senum [Page 1] Internet Draft DECnet Point-to-Point July 15, 1992 1. Introduction There are two basic approaches to running the DNA Phase IV Routing protocol over a serial line: 1. The approached that several router vendors have taken which is to treat the serial link as an Ethernet, using the same data and control messages an Ethernet would use. 2. The approach defined by Digital, which uses DDCMP and slightly different control messages. This document will define a method that uses the first approach. 2. Overview Of Phase IV DNA Protocols The Phase IV DNA protocols which act as data link clients are: o DNA Phase IV Routing The Phase IV Digital Network Architecture (DNA) Routing protocol is a network layer protocol providing services similar to that of DoD IP. It routes messages in Phase IV DECnet networks and manages the packet flow. The complete definition of the DNA Phase IV Routing protocol can be found in [2]. o DNA System Console The Digital Network Architecture (DNA) System Console protocol is a maintenance protocol providing low level access to a system for the functions of: . Identify processor . Read data link counters . Boot system . Console carrier (a general purpose i/o channel) The complete definition of the DNA System Console protocol can be found in [3]. o Digital Customer Use The Digital Customer Use protocol type is a value reserved for use by Digital customers. It allocates a type for private use which will not conflict with Digital or other vendor protocols. o DNA Diagnostics The Digital Network Architecture (DNA) Diagnostics protocol type is reserved to allow diagnostic software communications in parallel with other data link clients. Senum [Page 2] Internet Draft DECnet Point-to-Point July 15, 1992 o DNA Naming Service (DNS) The Digital Network Architecture Naming Service (DNS) provides a distributed naming service. It allows clients to register named objects and to bind a set of attributes to the objects in a distributed database. o DNA Time Service (DTS) The Digital Network Architecture Time Service (DTS) is a protocol providing global clock synchronization in a distributed environment. o DNA Load/Dump The Digital Network Architecture (DNA) Load/Dump protocol is a maintenance protocol for copying the contents of processor memory to or from a remote system. For example, a system manager can load an operating system into an unattended, remote system. The complete definition of the Phase IV DNA Load/Dump protocol can be found in [3]. o DNA Experimental Use The Digital Network Architecture (DNA) Experimental Use protocol type allows Digital experimental protocols to share a data link with other data link clients. It is for use by Digital Equipment Corporation only. o DNA Communications Test The Digital Network Architecture (DNA) Communications Test protocol is a maintenance protocol for testing the data link communications path. The complete definition of the DNA Communications Test protocol can be found in [3]. o Digital Protocol X1 The Digital X1 protocol is a network layer protocol currently private to Digital. This document defines the NCP for establishing and configuring Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP. This document applies only to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc). Senum [Page 3] Internet Draft DECnet Point-to-Point July 15, 1992 3. A PPP Network Control Protocol for DNA Phase IV Routing The DNA Phase IV Routing Control Protocol (DNCP) is responsible for configuring, enabling, and disabling the DNA Phase IV Routing protocol modules on both ends of the point-to-point link. As with the Link Control Protocol (LCP, defined in [1]), this is accomplished through an exchange of packets. DNCP packets may not be exchanged until the LCP has reached the Network-Layer Protocol Configuration Negotiation phase. DNCP packets received before this phase is reached should be silently discarded. Likewise, DNA Phase IV Routing packets may not be exchanged until the DNCP has first opened the connection (reached the Open state). The DNCP is the same as the LCP with the following exceptions: Data Link Layer Protocol Field Exactly one DNCP packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 8027 (DNA Phase IV Control Protocol). Code field Only Codes 1 through 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack and Code-Reject) are used. Other Codes should be treated as unrecognized and should result in Code-Rejects. Timeouts DNCP packets may not be exchanged until the LCP has reached the network-layer Protocol Configuration Negotiation phase. An implementation should be prepared to wait for Link Quality testing to finish before timing out waiting for a Configure-Ack or other response. It is suggested that an implementation give up only after user intervention or a configurable amount of time. 4. DNA Phase IV Control Protocol Configuration Option Types The DNA Phase IV Control Protocol has no Configuration Options. Senum [Page 4] Internet Draft DECnet Point-to-Point July 15, 1992 5. Sending DNA Phase IV Routing Packets Before any DNA Phase IV Routing packets may be sent, both the Link Control Protocol and the DNA Phase IV Routing Control Protocol must reach Open state. Exactly one octet-count field and one DNA Phase IV Routing packet are encapsulated in the information field of PPP Data Link Layer frames where the Protocol field indicates type hex 0027 (DNA Phase IV Routing). The octet-count contains a count of the number of octets in the DNA Phase IV Routing packet. It is two octets in length itself, and is stored in VAX byte ordering, to be more consistent with DNA Phase IV Routing over Ethernet (i.e. least significant byte first). It is needed to disambiguate optional padding octets from real information. The maximum length of an DNA Phase IV Routing packet transmitted over a PPP link is the same as the maximum length of the Information field of a PPP data link layer frame minus 2 octets (for the Length field). The format of the packets themselves is the same as the format used over Ethernet, without the Ethernet header, Pad, and FCS fields. A summary of the information field is shown below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length LSB | Length MSB | DATA | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length LSB Least significant byte of length field Length MSG Most significant byte of length field DATA DNA Phase IV Routing data, as specified in [2] Senum [Page 5] Internet Draft DECnet Point-to-Point July 15, 1992 6. Security Considerations Security issues are not discussed in this memo. 7. Other Considerations When a topology change in the network occurs, DNA Phase IV Routing nodes immediately propagate changes via Level 1 and Level 2 Routing messages, with a 1 second minimum delay between updates. DNA Phase IV Routing nodes also periodically retransmit the complete Level 1 and Level 2 distance vectors to guard against data corruption in host memory, and (in the case of Ethernet) loss of packets due to media errors. Because Digital's serial links run a protocol that guarantees delivery of packets (DDCMP), the recommended default retransmit time is long (600 seconds), whereas for Ethernet, where packet delivery is not guaranteed, the recommended default is short (10 seconds), as documented in [1]. To achieve convergence of routes within a satisfactory time, the interval between updates should be based upon the error rate of underlying data link. As such, it is recommended that the time between routing updates be user configurable per PPP interface. The Hello timer and Listen timer should be set according to the recommendations for broadcast links (15 and 45 seconds, respectively). Routers are not required to send routing updates if the remote node connected via the PPP link is an endnode. Endnodes are required to discard all routing updates received over a PPP link. The type of a node (endnode versus routing) can be determined from the hello messages received from it. Senum [Page 6] Internet Draft DECnet Point-to-Point July 15, 1992 References [1] Simpson, W. A., "The Point-to-Point Protocol for the Transmission of Multi-Protocol of Datagrams Over Point-to-Point Links", RFC 1331, May 1992. [2] Digital Equipment Corporation, "DNA Routing Layer Functional Specification", Version 2.0.0, Order No. AA-X435A-TK. [3] Digital Equipment Corporation, "DNA Maintenance Operations Functional Specification", Version 3.0.0, Order No. AA-X436A-TK. Senum [Page 7] Internet Draft DECnet Point-to-Point July 15, 1992 Acknowledgments The author wishes to thank Jim Muchow (Network Systems Corporation), and Arthur Harvey (Digital Equipment Corporation) for their input to this memo. Chair's Address The working group can be contacted via the current chair: Brian Lloyd Llyod & Associates 3420 Sudbury Road Cameron Park, California 95682 Phone: (916) 676-1147 EMail: brian@lloyd.com Author's Address Questions about this memo can also be directed to the author: Steven J. Senum Network Systems Corporation 7600 Boone Avenue North Minneapolis, Minnesota 55428 Phone: (612) 424-4888 EMail: sjs@network.com Expiration Date The expiration date of this memo is 1/22/93. Senum [Page 8] From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 15 21:53:47 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07508; Wed, 15 Jul 92 21:49:28 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA25190; Wed, 15 Jul 92 21:29:51 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06673; Wed, 15 Jul 92 21:21:22 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SPECTRUM.CMC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06608; Wed, 15 Jul 92 21:19:27 -0700 Received: by Spectrum.CMC.COM (4.1/SMI-4.1(Spectrum)) id AA07348; Wed, 15 Jul 92 21:17:55 PDT Date: Wed, 15 Jul 92 21:17:55 PDT From: lars@CMC.COM (Lars Poulsen) Message-Id: <9207160417.AA07348@Spectrum.CMC.COM> To: art@opal.acc.com Subject: Re: PPP FCS negotiation option -- patent release letter In-Reply-To: <9207132035.AA05115@opal.acc.com> Organization: CMC Network Systems (Rockwell DCD), Santa Barbara, CA, USA Cc: ietf-ppp@ucdavis.ucdavis.edu In article <+9207132035.AA05115@opal.acc.com> you write: >I wonder what "reasonable terms" means? Why couldn't they just authorize >its use, free of charge, for PPP? I wonder how many vendors will bother >with it, if there is any charge or administration required. Wasn't DEC >the original proponent for standardizing this option? This issue came up in the PPP working group today. The answers are: (1) We will not know what the fee will be, until someone negotiates a license. Tony Lauck said he expects a fee from "a thousand to a few thousand dollars". (2) Apparently, in these lean times, Digital is hoping to make a small amount of profit from this patent. (3) Tony Lauck, who actually invented the thing, is as surprised as the rest of us at this turn. He was clearly embarrased at the situation. At one point he said he wished he had not filed the patent. / Lars -- / Lars Poulsen, SMTS Software Engineer Internet E-mail: lars@CMC.COM CMC (Rockwell Digital Systems) Telephone: +1-805-968-4262 Santa Barbara, CA 93117-5503 TeleFAX: +1-805-968-8256 From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 16 08:25:31 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24041; Thu, 16 Jul 92 08:10:49 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27861; Thu, 16 Jul 92 07:50:36 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23128; Thu, 16 Jul 92 07:41:52 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23014; Thu, 16 Jul 92 07:37:31 -0700 Received: from remora.morningstar.com by volitans.morningstar.com (5.65a/92042102) id AA25383; Thu, 16 Jul 92 10:34:43 -0400 Received: by remora.morningstar.com (5.65a/91072901) id AA01929; Thu, 16 Jul 92 10:34:32 -0400 Date: Thu, 16 Jul 92 10:34:32 -0400 From: Karl Fox Message-Id: <9207161434.AA01929@remora.morningstar.com> To: ietf-ppp@ucdavis.ucdavis.edu Cc: Tony Lauck Subject: Re: PPP FCS negotiation option -- patent release letter References: <9207132035.AA05115@opal.acc.com> <9207160417.AA07348@Spectrum.CMC.COM> Organization: Morning Star Technologies, Inc. Back in December, Tony Lauck said that DEC would license the 48-bit FCS algorithm to developers at `reasonable terms'. At the March IETF meeting in San Diego, he said that DEC would issue a letter to the IAB allowing use of the algorithm at no cost for use with PPP. Now they say it will cost from one to a few thousands of dollars. Assuming that this is a one-time fee, it is not a huge burden to sellers of PPP-speaking equipment, but: 1) We have had zero requests from customers for the feature, and anticipate few or none. 2) Manual configuration, although slightly less convenient, can be used in its stead (and already is, at least in our products). 3) Free PPP implementations will not be able to implement the option, or else any user of such free code will have to pay DEC one thousand to several thousand dollars. In fact, the 32-bit and 48-bit FCS code that I wrote for inclusion in the heretofore upcoming 32-bit FCS RFC may all by itself be in violation of the patent. Unless I am assured by DEC that it is not, I will have to withdraw it. Please, DEC, reconsider your position and allow no-cost use of the 48-bit FCS algorithm for use with PPP. It will cost you little and gain you a lot of good will. If you want to get something out of it, require only that users of the technology state in their documentation and product literature that their products ``use the 48-bit FCS technology developed by DEC and granted to the Internet community for use with PPP.'' From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 16 13:22:14 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04210; Thu, 16 Jul 92 13:17:26 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01301; Thu, 16 Jul 92 12:40:20 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02538; Thu, 16 Jul 92 12:36:52 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from anu.anu.edu.au by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01851; Thu, 16 Jul 92 12:15:29 -0700 Received: from cscgpo.anu.edu.au by anu.anu.edu.au (4.1/SMI-4.1) id AA17364; Thu, 16 Jul 92 22:29:05 EST Received: from huxley.anu.edu.au by cscgpo.anu.edu.au (4.1/SMI-4.1) id AA25480; Thu, 16 Jul 92 22:28:49 EST From: cmf851@cscgpo.anu.edu.au (Albert Langer) Message-Id: <9207161228.AA25480@cscgpo.anu.edu.au> Subject: Re: PPP FCS negotiation option -- patent release letter To: lars@CMC.COM (Lars Poulsen) Date: Thu, 16 Jul 92 22:28:48 EST Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <9207160417.AA07348@Spectrum.CMC.COM>; from "Lars Poulsen" at Jul 16, 92 09:17:55 pm X-Mailer: ELM [version 2.4dev PL32] > This issue came up in the PPP working group today. > The answers are: > (1) We will not know what the fee will be, until someone negotiates a > license. Tony Lauck said he expects a fee from "a thousand to a few > thousand dollars". Seems the letter offered nothing AT ALL. Description of patented technology in standards documents (or any other documents) is quite commonplace and requires no licence at all. Likewise for private experimentation. Only commercial exploitation requires a licence anyway (in those countries silly enough to permit patenting of algorithms), so the letter gave NOTHING. > (2) Apparently, in these lean times, Digital is hoping to make a small > amount of profit from this patent. I was hoping to hear it was a "defensive patent" simply filed for exchange against similar nonsense from others. I can't pretend to understand the U.S. judgments permitting patents of mathematical algorithms but I would be surprised if they covered something as transparent as this. The properties of cyclic groups may not be at all obvious to the average communications engineer, but surely the relevant "art" in this case is the mathematical art of factoring polynomial equations etc. My algebra is pretty rusty but I would have thought there is no "invention" in solving a pair of simultaneous equations in order to meet two conditions (CRC16 and CRC32) simultaneously. Surely both the existence of a solution and the couple of lines of algebra required to extract the 48bit FCS as a solution, would be "obvious" to anyone skilled in the "mathematical art". > (3) Tony Lauck, who actually invented the thing, is as surprised as the > rest of us at this turn. He was clearly embarrased at the situation. > At one point he said he wished he had not filed the patent. How about putting him out of his misery by sidestepping and adopting an alternative 32 bit FCS with alternative 16/32 bit simultaneous transition procedure? Fletcher's checksum has almost as good error detection capability as the 16 bit CRC and is MUCH easier and faster to calculate in software. A 32 bit equivalent of Fletcher's checksum has been described by Keith Sklower in "Improving the Efficiency of the OSI Checksum Calculation" (ftp from nnsc.nsf.net:CCR/oct89/sklower.ps - see also CCR/oct88/nakassis.ps). This can be calculated over 50% FASTER than the 16 bit Flecther checksum as well as having greatly extended error correction properties. Basically, the CRC procedures are designed for efficient implementation in shift register hardware such as U(S)ARTs, whereas the 48 bit combined 16/32 FCS is not available in hardware and requires inefficient 48 bit arithmetic software on 32 bit machines. (It can be combined with use of the 16 or 32 bit CRC hardware but still requires a much more CPU expensive computation.) The Fletcher checksum was specifically designed for efficient implementation in software, with the 32 bit version taking full advantage of 16 bit arithmetic on 16 and 32 bit machines. Leaving aside patent issues, it would make good sense to adopt the 32 bit Fletcher checksum purely because of the easier software calculations both for the 32 bit FCS itself and for the combined 16/32 bit FCS. (The 16 bit CCITT CRC polynomial remains a better choice for a 16 bit FCS simply because it is standardized and available in hardware, but these considerations do not apply when starting from a 16 bit FCS and negotiating a 32 bit FCS together with a suitable 16/32 bit compatible transition. Since standard 16/32 bit compatible hardware is not available, a software calculation is needed anyway and the algorithm chosen should be designed to optimize that.) Whereas the 16 bit CRC also has marginally superior error detection, I don't think the same can be said for the 32 bit CRC. Both the 32 bit CRC and 32 bit Fletcher's checksum will detect all single bit and two bit errors and all 32 bit burst errors. The main point of moving from 16 bits to 32 bits is that noise bursts longer than 16 bits are quite common and a 16 bit FCS will randomly be valid for about 1/64K of frames corrupted by such noise bursts. A 32 bit FCS has exactly the same problem that noise bursts longer than 32 bits are quite common, but it will randomly be valid for only about 1/4 billion of such corrupted frames, which results in much more acceptable undetected error rates than 1/64K. (Especially important with long frames and/or high noise levels). It is the LENGTH of the 32 bit FCS that is useful, not any special characteristics unique to CRC polynomials that are not availalble from the Fletcher checksum. As with 16/32 bit FCS, an efficient procedure for calculating a few bytes that will SIMULTANEOUSLY satisfy the 16 bit CCITT CRC and the 32 bit Fletcher checksum, should be just a matter of solving some trivial simultaneous equations (don't ask me - put the problem to sci.maths and/or sci.crypt :-) At a guess I suspect one could just use the usual procedures to calculate an ordinary 32 bit Fletcher's checksum on the frame extended by three or four null bytes, and simultaneously calculate the 16 bit CRC of the extended frame either in software or hardware, then do a very short calculation on the results of both, to replace the three or four null bytes with values that will simultaneously satisfy the 16 bit CRC and the 32 bit Fletcher checksum when calculated over the whole extended frame. Thus the combined 16/32 bit transition frames should be easier to calculate than by using the "patented" algorithm, while the final 32 bit only frames would actually be MUCH easier to calculate than frames with 16 bit CRCs. If the few bytes extra overhead per frame is acceptable, switching to the 32 bit FCS might be preferred simply for improved CPU performance, quite apart from more effective error detection. From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 16 21:02:44 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19254; Thu, 16 Jul 92 20:57:18 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05345; Thu, 16 Jul 92 20:39:31 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18617; Thu, 16 Jul 92 20:31:31 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18254; Thu, 16 Jul 92 20:22:01 -0700 Received: from crappie.morningstar.com by volitans.morningstar.com (5.65a/92042102) id AA28987; Thu, 16 Jul 92 23:20:52 -0400 Received: by crappie.morningstar.com (5.65a/910712902) id AA00533; Thu, 16 Jul 92 23:20:50 -0400 Date: Thu, 16 Jul 92 23:20:50 -0400 From: Karl Fox Message-Id: <9207170320.AA00533@crappie.morningstar.com> To: Albert Langer Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: PPP FCS negotiation option -- patent release letter References: <9207160417.AA07348@Spectrum.CMC.COM> <9207161228.AA25480@cscgpo.anu.edu.au> Organization: Morning Star Technologies, Inc. Albert Langer writes: > Description of patented technology in standards documents (or any > other documents) is quite commonplace and requires no licence at all. > Likewise for private experimentation. Only commercial exploitation > requires a licence anyway (in those countries silly enough to permit > patenting of algorithms), so the letter gave NOTHING. This is true for copyright in the U.S., but I'm pretty sure patent applies to any use at all. > I can't pretend to understand the U.S. judgments permitting patents of > mathematical algorithms but I would be surprised if they covered > something as transparent as this. The properties of cyclic groups may > not be at all obvious to the average communications engineer, but > surely the relevant "art" in this case is the mathematical art of > factoring polynomial equations etc. As far as I can tell, you can get a patent on anything that the patent officer doesn't understand. It's possible to fight patents on the basis of obviousness, but it's usually cheaper to just go head and pay the license fee, and business decisions are usually based on what's cheaper, not on someone's sense of justice. > How about putting him out of his misery by sidestepping and adopting > an alternative 32 bit FCS with alternative 16/32 bit simultaneous transition > procedure? ... > Since standard 16/32 bit compatible hardware is not available, a > software calculation is needed anyway and the algorithm chosen should > be designed to optimize that.) Unfortunately, this is far from true. Hardware capable of both 16-bit and 32-bit FCS computation is widely available. Ours, for example. :-) And the 32-bit CCITT CRC polynomial is THE 32-bit FCS algorithm to use. From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jul 17 08:43:49 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05744; Fri, 17 Jul 92 08:36:46 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07935; Fri, 17 Jul 92 08:19:34 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04887; Fri, 17 Jul 92 08:11:47 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04727; Fri, 17 Jul 92 08:05:38 -0700 Received: from sjfsmtp.Novell.COM by newsun.novell.com with SMTP id AA02537 (5.65c/IDA-1.4.4 for <@newsun.Novell.COM:ietf-ppp@ucdavis.edu>); Fri, 17 Jul 1992 08:04:34 -0700 Message-Id: <199207171504.AA02537@newsun.novell.com> From: MALLEN.NOVELL@novell.com (MALLEN) To: ietf-ppp@ucdavis.ucdavis.edu (X) Subject: IPXCP Compromise Draft Date: Fri, 17 Jul 92 08:00 I see some problems when attempting to use the "new" compromise IPXCP document (July 1992 - Simpson). 1. The IPXWAN protocol requires BOTH ends to send Timer Requests for the protocol to work. Page 3 incorrectly states that only one end of the link need send the Timer Request packet. Based on information in the Timer Requests, one end becomes the link owner. IPXWAN operation should be assumed if NO options could be negotiated. 2. Routing Protocol option - 2=Novell RIP/SAP required. Does this imply that the IPXWAN protocol is being used? If this parameter is negotiated WITHOUT negotiating a network number successfully (maybe using the IPX-Address option), the IPX layer will still not work. If on the other hand, this option implies the IPXWAN protocol, no other options need to be negotiated. 3. What does "No routing protocol required" mean? By definition, this is an IPX connection which needs a network number (for traditional RIP/SAP connections anyway). Any connection with a network number will have RIP & SAP flowing. 4. This IPXCP protocol does not seem to impose the necessity that certain options are required to be negotiated if other parameters are agreed upon. The IPXWAN document laid down a set of rules for the sequencing and content of all required information - with enough room for expansion of routing protocols later. 5. I do not feel that there is enough information in the proposal to allow IPX routing clients to interoperate successfully. This document still does not address the fact that current proprietary implementations exist (Other than IPXWAN) which also currently do not use IPXWAN and are currently use unspecified private options. If we are going to specify an IPXCP with options, we need to be agressive and specific - there should be no room for error. I have no objection to the NCP options, so long as they form a set of rules - i.e., they specify that if one set of options are negotiated, others MUST also, and that if NO options can be negotiated, the default option WILL be IPXWAN. This avoids any confusion among potential PPP IPXCP implementors. Hope these comments are useful, Michael Allen (mallen@novell.com) Novell Inc. From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jul 20 10:42:27 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19951; Mon, 20 Jul 92 10:30:22 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA25582; Mon, 20 Jul 92 10:02:05 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18902; Mon, 20 Jul 92 09:58:05 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18632; Mon, 20 Jul 92 09:47:54 -0700 Received: from na.novell.com.novell.com (na.Novell.COM) by newsun.novell.com with SMTP id AA14732 (5.65c/IDA-1.4.4 for ); Mon, 20 Jul 1992 09:46:46 -0700 Received: by na.novell.com.novell.com (4.1/SMI-4.1) id AA26806; Mon, 20 Jul 92 09:49:06 PDT Date: Mon, 20 Jul 92 09:49:06 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9207201649.AA26806@na.novell.com.novell.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Connect time option in IPXCP and ATCP Hi Y'all, During an off-IETF-site meeting where a number of us were hammering out IPXCP options, it was noted that a connect time option in an NCP is inappropriate. The right place for it is in an LCP option. That means we won't keep it in IPXCP. Should it be removed from ATCP? Brad? Who's going to write up the new connect time option for the LCP? Chris Ranch Novell, Inc. (408)473-8667 From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 21 17:32:17 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13946; Tue, 21 Jul 92 17:24:07 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09467; Tue, 21 Jul 92 16:49:52 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12352; Tue, 21 Jul 92 16:41:19 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12074; Tue, 21 Jul 92 16:32:46 -0700 Received: from na.novell.com.novell.com (na.Novell.COM) by newsun.novell.com with SMTP id AA21675 (5.65c/IDA-1.4.4 for ); Tue, 21 Jul 1992 16:31:36 -0700 Received: by na.novell.com.novell.com (4.1/SMI-4.1) id AA09902; Tue, 21 Jul 92 16:33:58 PDT Date: Tue, 21 Jul 92 16:33:58 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9207212333.AA09902@na.novell.com.novell.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Novell followup to Cambridge IETF IPXCP/IPXWAN meeting at Shiva Hi Y'all, This is an update and follow through on the meeting the IETF had at Shiva last week. I came away with some questions, and here are some answers. 1) What are WNodeID's and nodeID's in IPXCP for? Terminology mixup. The IPXWAN WNode ID is really the primary network number. Both sides send one, and the higher number becomes the 'master'. 2) How are Node ID's calculated? The first 4 bytes are the network number, and the last two are cleared to zero. (6 bytes total). Note that the IPX header's dest node ids are set to all ones, and source node are set to all zero for WPacket Type 0, 1, 2, and 3. 3) Opinions about splitting IPXCP's network number/node id into two options? Michael thought that they go hand in hand, so we might as well leave them together. 4) Policy on rejecting/acking network numbers? The higher one wins. 5) Where exactly are the timer values used? How does it affect things? Transport end-to-end? Does it need to be negotiated? IPX is RIP based. Each RIP entry has the cumulative time distance in it for that net. These propagate directly in RIP. Then when an SPX session is created, the transport retry timers are tuned accordingly. The vaules must be accurate, according to the algorithm defined in IPXWAN. It makes sense to communicate them through an IPXCP option instead of relying on manual configuration or an interface that provides the link's raw bit rate and doing some math. 6) Connect time in IPXCP. This was carried over from Shiva's draft. The feature makes sense, but we think it should be an LCP option, not an NCP option. 7) IPXWAN 3rd party compression number assignment. Mark Lewis from Telebit asked for and got an IPXWAN number for VJ like IPX/SPX header compression. Header compression option is to be negotiated in the Timer Request/Response exchange, that is, WPacket type = 0,1. The compression WOption Number is $80. The WOption Data is $00 for Telebit compression. Thus, the WOption Data Len is $0001. This assignment will be included in the IPXWAN draft cum informational rfc. Ask Mark for the design spec. In general, I thogh it was a productive meeting, with a minimum of bloodshed. Shiva lodged a complaint with Novell about making everyone do this, and was noted. We will continue with IPXWAN. It's here to stay. Bill Simpson is doing a fine job being our compromise draft coordinator (or is that target ;). Expect to see a new draft from him soon. Required options will be spelled out. Good work, Y'all. The IPXWAN draft will be updated soon, and repulished. Several things could be clarified. Once those who are actively participating agree that it's done, we'll send it to Jon Postel, our faithful rfc editor. Chris Novell/IPX/PPP Scapegoat From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 22 09:42:25 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11096; Wed, 22 Jul 92 09:37:48 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA14221; Wed, 22 Jul 92 09:19:44 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10241; Wed, 22 Jul 92 09:12:27 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09947; Wed, 22 Jul 92 09:02:34 -0700 Received: by volitans.morningstar.com (5.65a/92042102) id AA11427; Wed, 22 Jul 92 12:01:21 -0400 Date: Wed, 22 Jul 92 12:01:21 -0400 From: Bob Sutterfield Message-Id: <9207221601.AA11427@volitans.morningstar.com> To: ietf-ppp@ucdavis.ucdavis.edu Cc: cranch@novell.com (Christopher Ranch) In-Reply-To: cranch@novell.com's message of Tue, 21 Jul 92 16:33:58 PDT Subject: Novell followup to Cambridge IETF IPXCP/IPXWAN meeting at Shiva Date: Tue, 21 Jul 92 16:33:58 PDT From: cranch@novell.com (Christopher Ranch) 6) Connect time in IPXCP. This was carried over from Shiva's draft. The feature makes sense, but we think it should be an LCP option, not an NCP option. Please forgive my inability to find my copy of Shiva's draft, and my unfamiliarity with Novell's protocol family and with IPXWAN, but I'm terribly unclear about what this facility provides and why it makes more sense in LCP. Is this a protocol (like LQM?) by which the peers tell each other how long each thinks they've been connected? Or is it an option to negotiate how long the peers should stay connected? Or is it maybe some sort of idle timer? If it's in LCP, will it be useful to users of IP (and other protocol families) over PPP, or is it a Novell-specific sort of timer? I'd appreciate being *gently* brought up to speed. From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 22 10:02:12 1992 Received: from [128.120.2.9] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11520; Wed, 22 Jul 92 09:50:27 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA14478; Wed, 22 Jul 92 09:30:02 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10637; Wed, 22 Jul 92 09:24:55 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10406; Wed, 22 Jul 92 09:17:01 -0700 Received: from na.novell.com.novell.com (na.Novell.COM) by newsun.novell.com with SMTP id AA10294 (5.65c/IDA-1.4.4 for ); Wed, 22 Jul 1992 09:15:52 -0700 Received: by na.novell.com.novell.com (4.1/SMI-4.1) id AA14997; Wed, 22 Jul 92 09:18:05 PDT Date: Wed, 22 Jul 92 09:18:05 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9207221618.AA14997@na.novell.com.novell.com> To: bob@MorningStar.Com, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: Novell followup to Cambridge IETF IPXCP/IPXWAN meeting at Shiva Cc: cranch@novell.com Hi Bob, > From bob@MorningStar.Com Wed Jul 22 09:04:34 1992 > > Date: Tue, 21 Jul 92 16:33:58 PDT > From: cranch@novell.com (Christopher Ranch) > > 6) Connect time in IPXCP. > > This was carried over from Shiva's draft. The feature makes > sense, but we think it should be an LCP option, not an NCP > option. > > Please forgive my inability to find my copy of Shiva's draft, and my > unfamiliarity with Novell's protocol family and with IPXWAN, but I'm > terribly unclear about what this facility provides and why it makes > more sense in LCP. Is this a protocol (like LQM?) by which the peers > tell each other how long each thinks they've been connected? Or is it > an option to negotiate how long the peers should stay connected? Or > is it maybe some sort of idle timer? The intent is to inform the end system that is dialing in how much connect time they will have before they get booted off. Some commercial services (bbs's, AppleLink) have this feature. I believe it was introduced by Shiva into IPXCP to make their IPX dial-in servers functionally consistent with ARAP. ARAP has this feature built into the product and the protocol. The real use is for the end system's user interface to tell the user upon connecting how long they have, and to give a count-down warning as the connect time approaches zero. Assuming time is measured at the same rate on both sides ;). > If it's in LCP, will it be useful to users of IP (and other protocol > families) over PPP, or is it a Novell-specific sort of timer? I believe this is useful to all protocols. The resource being conserved here is the physical link (modem). I don't see much sense in closing one particular protocol as opposed to the whole connection. > I'd appreciate being *gently* brought up to speed. Gee, I hope I didn't step on too many toes in informing everyone about the IPXWAN requirement. Or maybe you're confusing me with Bill ;). Chris From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 22 15:16:15 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22049; Wed, 22 Jul 92 15:07:09 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA18065; Wed, 22 Jul 92 14:49:33 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21134; Wed, 22 Jul 92 14:40:46 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20866; Wed, 22 Jul 92 14:35:14 -0700 Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA10113; Wed, 22 Jul 92 14:33:37 -0700 Date: Wed, 22 Jul 92 12:02:42 EDT From: "William Allen Simpson" Message-Id: <569.bsimpson@angband.stanford.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: PPP work in progress At IETF-Boston, the PPP working group had several extremely productive sessions. The main two sessions covered general progress, and provided considerable feedback from implementors. Between and after the main sessions, small groups split off for *intense* discussion (including a fair amount of shouting, but not too much name calling), and developed fairly detailed proposals for Compression and "LAPB". Differences were resolved about DECnet and IPX over PPP. Altogether, PPP was easily the most productive of the WGs that I observed. Many thanks to all concerned! Now it's time to expose the results to a wider audience for close examination and criticism. I am preparing a PPP LCP Additional Options document, to cover: * FCS Alternatives * Trailing Pads * Connect Time (removed from Appletalk and IPX) * Callback (removed from Authentication) Fred Baker is preparing a "PPP Numbered Mode and Multilink Procedures (NMMP)" document (two more LCP options), and a separate "PPP Compression Configuration and Control Protocol (CCCP)". I will also finish off the IPXCP document. Brian: since we have now reached some degree of harmony on IPX, Compression and Numbered Mode, I don't think we need the separate discussion groups. All discussion should be on the main list. Thank you for providing the forum. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 22 17:41:31 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27093; Wed, 22 Jul 92 17:36:33 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA19235; Wed, 22 Jul 92 17:19:46 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26304; Wed, 22 Jul 92 17:12:51 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [143.191.3.1] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26185; Wed, 22 Jul 92 17:09:21 -0700 Received: from napa.TELEBIT.COM by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-Brent-920708) id AA09499 to ietf-ppp@ucdavis.edu; Wed, 22 Jul 92 17:07:41 PDT Received: from yoyo.telebit.com by napa.TELEBIT.COM (4.1/napa.telebit.com-Brent-920717) id AA09719 to ietf-ppp@ucdavis.edu; Wed, 22 Jul 92 17:07:38 PDT Date: Wed, 22 Jul 92 17:07:38 PDT From: mlewis@napa.Telebit.COM (Mark S. Lewis) Message-Id: <9207230007.AA09719@napa.TELEBIT.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA11286; Wed, 22 Jul 92 17:08:53 PDT To: bsimpson@angband.stanford.edu Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <569.bsimpson@angband.stanford.edu> Subject: PPP work in progress As I promised, I wanted to send some text that may help clarify the following section of your IPXCP draft. ... Mark ---------------------------- Original --------------------------- 1.2. IPX WAN protocol IPX may be used over a variety of data link protocols. Novell has recently announced a new specification called IPX WAN [4], which is intended to provide mechanisms similar to PPP NCP negotiation over all types of wide area links. It is the intent of this document to provide equivalent functionality for those implementations that do not already include IPX WAN, without interfering with those implementations that also include IPX WAN. > IPX WAN uses a "Timer Request" packet to set up the link. These MUST > NOT be sent until the NCP has Opened the link. > Since only one end of the link need send the Timer Request packet, it > is recommended that only those implementations which have failed to > successfully negotiate some required parameter send a Timer Request > packet. This will allow successful interoperation with non-IPX-WAN- > capable implementations. > Therefore, 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. > If unable to complete IPX WAN setup, the NCP MUST terminate the link. ---------------------------- Suggestion --------------------------- 1.2. IPX WAN protocol IPX may be used over a variety of data link protocols. Novell has recently announced a new specification called IPX WAN [4], which is intended to provide mechanisms similar to PPP NCP negotiation over all types of wide area links. It is the intent of this document to provide equivalent functionality for those implementations that do not already include IPX WAN, without interfering with those implementations that also include IPX WAN. The general strategy is to first attempt to negotiate and Open the link with IPXCP. If this is unsucessful, then attempt to negotiate and Open the link using IPX WAN. If this is unsuccessful, the link cannot be Opened. This established order of precedence will allow successful interoperation between implementations of IPXCP and IPX WAN. While attempting to negotiate and Open the link with IPXCP, IPXCP implementations will presumably exchange IPXCP configuration packets. During this time, IPX WAN packets of any type MUST NOT be sent. IPX WAN uses a "Timer Request" packet to set up the link. These MUST NOT be sent while attempting to negotiate and Open the link with IPXCP. It is left to each implementation to determine if it has successfully negotiated with IPXCP for the link to Open. If an implementation has determined that it cannot Open the link with IPXCP, then it SHOULD attempt to negotiate and Open the link with IPX WAN. IPX WAN implementations will exchange "Timer Request" packets. It is left to each implementation to determine if it has successfully negotiated with IPX WAN for the link to Open. Note that no IPXCP negotiations are required for successfully negotiating and Opening using IPX WAN. From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 22 21:33:07 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05283; Wed, 22 Jul 92 21:29:46 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA20440; Wed, 22 Jul 92 21:19:31 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04685; Wed, 22 Jul 92 21:10:08 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04456; Wed, 22 Jul 92 21:02:44 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA16365; Wed, 22 Jul 92 21:01:13 PDT Date: Wed, 22 Jul 92 21:01:13 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9207230401.AA16365@ray.lloyd.com> To: bob@MorningStar.Com Cc: ietf-ppp@ucdavis.ucdavis.edu, cranch@novell.com In-Reply-To: Bob Sutterfield's message of Wed, 22 Jul 92 12:01:21 -0400 <9207221601.AA11427@volitans.morningstar.com> Subject: Novell followup to Cambridge IETF IPXCP/IPXWAN meeting at Shiva Disclaimer: The following is a product of my memory and I could be wrong. The "connect time" concept is a holdover from ARAP. Apple wanted to keep track of the amount of time that the link was up so that they could kill the link if people stayed on too long (providing some form of "fairness" control, I guess). Shiva liked the idea and it got tossed into their NCP doc. I agree that keeping track of connect time (the time elapsed since the link came up and LCP was successfully negotiated) seems to me to be an LCP function and not an NCP function. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 22 21:41:58 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05652; Wed, 22 Jul 92 21:39:40 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA20464; Wed, 22 Jul 92 21:29:41 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05104; Wed, 22 Jul 92 21:22:20 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04821; Wed, 22 Jul 92 21:14:12 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA16389; Wed, 22 Jul 92 21:13:00 PDT Date: Wed, 22 Jul 92 21:13:00 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9207230413.AA16389@ray.lloyd.com> To: bsimpson@angband.stanford.edu Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: "William Allen Simpson"'s message of Wed, 22 Jul 92 12:02:42 EDT <569.bsimpson@angband.stanford.edu> Subject: PPP work in progress Brian: since we have now reached some degree of harmony on IPX, Compression and Numbered Mode, I don't think we need the separate discussion groups. All discussion should be on the main list. Thank you for providing the forum. I will leave the mailing lists (ppp-ipx@lloyd.com and ppp-compress@lloyd.com) in place for now. I will remove them later if there is no activity on them for a month. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 23 06:40:48 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18273; Thu, 23 Jul 92 06:35:48 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA22240; Thu, 23 Jul 92 06:19:29 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17599; Thu, 23 Jul 92 06:10:32 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17557; Thu, 23 Jul 92 06:09:16 -0700 Received: by volitans.morningstar.com (5.65a/92042102) id AA15570; Thu, 23 Jul 92 09:07:43 -0400 Date: Thu, 23 Jul 92 09:07:43 -0400 From: Bob Sutterfield Message-Id: <9207231307.AA15570@volitans.morningstar.com> To: brian@lloyd.com Cc: ietf-ppp@ucdavis.ucdavis.edu, cranch@novell.com In-Reply-To: Brian Lloyd's message of Wed, 22 Jul 92 21:01:13 PDT <9207230401.AA16365@ray.lloyd.com> Subject: Connect Timer in LCP Date: Wed, 22 Jul 92 21:01:13 PDT From: brian@lloyd.com (Brian Lloyd) [The connect timer is intended] to keep track of the amount of time that the link was up so that they could kill the link if people stayed on too long I agree that keeping track of connect time (the time elapsed since the link came up and LCP was successfully negotiated) seems to me to be an LCP function and not an NCP function. Yes, such a timer should be in LCP, not an NCP, so it would be available to users of any protocol family. But, staying in Columbus and being connected behind too slow a link to listen in on the real-time audiocast, I missed all the live discussions at the IETF meeting. So (being unfamiliar with traditional ARAP) I'd appreciate a brief discussion of the reason for including this. Why is such a timer considered a negotiable parameter at all? Each end of the link can maintain its own connection timer. The one that considers its resources more scarce will send the first Terminate-Request when it thinks its modem should be freed, and link taken down. (Our PPP can already do this: The administrator can configure the traffic filter so that no packets are "interesting enough" to count against the idle timer. It's single-ended and non-negotiable.) Or is the initial LCP connect timer "negotiation" actually only informational, so that (e.g.) the resource-limited server can inform the client that "you'll only have 5 minutes here, so inform your administrator to get expeditiously about h{is,er} business"? And you mentioned "keeping track of the connect time", from which I infer a different possible meaning than the above. Do you mean that the peers will periodically exchange packets describing how long they think the link has been up? Then why not put it into LQM? And why exchange the packets at all, if each peer has a clock anyway so that it knows what time value to put into the timer packets it sends? If the peers exchange periodic informational total-connect-time packets, what should they do if their values converge beyond some epsilon? Are we reimplementing NTP? Maybe I should just wait and read the draft... From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 23 08:35:07 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00187; Thu, 23 Jul 92 08:27:55 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA22734; Thu, 23 Jul 92 08:09:46 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20582; Thu, 23 Jul 92 08:00:58 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20498; Thu, 23 Jul 92 07:59:58 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA16778; Thu, 23 Jul 92 07:58:47 PDT Date: Thu, 23 Jul 92 07:58:47 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9207231458.AA16778@ray.lloyd.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: complaints I have received numerous complaints about Bill Simpson's subgroup mailing lists for compression and IPX. I have modified the mailing lists in question (ppp-compression@lloyd.com and ppp-ipx@lloyd.com) to be aliases for ietf-ppp@ucdavis.edu. This will force the discussions back onto the main mailing list. I appologize for the problems, confusion, and negative feelings. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 23 08:41:40 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00401; Thu, 23 Jul 92 08:33:05 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA22797; Thu, 23 Jul 92 08:19:57 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20973; Thu, 23 Jul 92 08:15:27 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20693; Thu, 23 Jul 92 08:05:40 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA16787; Thu, 23 Jul 92 08:04:09 PDT Date: Thu, 23 Jul 92 08:04:09 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9207231504.AA16787@ray.lloyd.com> To: bob@MorningStar.Com Cc: ietf-ppp@ucdavis.ucdavis.edu, cranch@novell.com In-Reply-To: Bob Sutterfield's message of Thu, 23 Jul 92 09:07:43 -0400 <9207231307.AA15570@volitans.morningstar.com> Subject: Connect Timer in LCP Gee, it has been quite a while since the discussion went on and, frankly, I don't remember why ARAP wanted/needed a connect-time timer. Since I appear to be so feeble minded could someone (Brad?) please enlighten me one more time. [Brian turns away from the workstation screen, gathers his shawl about his shoulders, and struggles to the upright position. He then slowly hobbles away using his walker.] :-) Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 23 08:54:07 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00766; Thu, 23 Jul 92 08:45:52 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA23041; Thu, 23 Jul 92 08:29:34 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00185; Thu, 23 Jul 92 08:27:52 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20860; Thu, 23 Jul 92 08:13:24 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA16814; Thu, 23 Jul 92 08:12:13 PDT Date: Thu, 23 Jul 92 08:12:13 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9207231512.AA16814@ray.lloyd.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: sublist archives For those of you who wish to read the archives for the ppp-compress and ppp-ipx mailing list you may use anonymous FTP to peruse the pub directory at ftp.lloyd.com (ray.lloyd.com). Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 23 12:27:21 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07349; Thu, 23 Jul 92 12:19:29 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA25604; Thu, 23 Jul 92 12:00:46 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06581; Thu, 23 Jul 92 11:53:08 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [130.57.4.1] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06456; Thu, 23 Jul 92 11:48:28 -0700 Received: from na.novell.com.novell.com (na.Novell.COM) by newsun.novell.com with SMTP id AA16804 (5.65c/IDA-1.4.4 for ); Thu, 23 Jul 1992 11:44:07 -0700 Received: by na.novell.com.novell.com (4.1/SMI-4.1) id AA06195; Thu, 23 Jul 92 11:46:28 PDT Date: Thu, 23 Jul 92 11:46:28 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9207231846.AA06195@na.novell.com.novell.com> To: bsimpson@angband.stanford.edu, mlewis@napa.Telebit.COM Subject: Re: PPP work in progress Cc: ietf-ppp@ucdavis.ucdavis.edu Hi, I like where this is going. I have some other suggestions. Chris > From: mlewis@napa.Telebit.COM (Mark S. Lewis) > > As I promised, I wanted to send some text that may help clarify the > following section of your IPXCP draft. > > ... Mark > > ---------------------------- Original --------------------------- > [deleted for brevity] > ---------------------------- Suggestion --------------------------- > > 1.2. IPX WAN protocol > > IPX may be used over a variety of data link protocols. Novell has > recently announced a new specification called IPX WAN [4], which is > intended to provide mechanisms similar to PPP NCP negotiation over > all types of wide area links. It is the intent of this document to > provide equivalent functionality for those implementations that do > not already include IPX WAN, without interfering with those > implementations that also include IPX WAN. IPX may be used over a variety of data link protocols. Novell has recently announced a new specification called IPX WAN [4], which is intended to provide mechanisms similar to PPP NCP negotiation, and link delay measurement over all types of wide area links. It is the intent of this document to provide equivalent functionality for those implementations that do not include IPX WAN, without interfering with implementations that do include IPX WAN. > The general strategy is to first attempt to negotiate and Open the > link with IPXCP. If this is unsucessful, then attempt to negotiate > and Open the link using IPX WAN. If this is unsuccessful, the link > cannot be Opened. This established order of precedence will allow > successful interoperation between implementations of IPXCP and IPX > WAN. [Note: IPXWAN is NOT intended to replace the IPXCP state machine. The IPX NCP MUST reach the Open state before anything else.] The general strategy is to first attempt to negotiate required options, and Open the link with IPXCP. If any of the required options are rejected, then IPXWAN MUST complete its packet exchange before IPX/SPX data may be forwarded down the link. Then, if IPXWAN fails to complete, IPXCP MUST enter into the closed state. This order of precedence will allow interoperation between IPXWAN implementations, and between IPXCP without IPXWAN implementations. > While attempting to negotiate and Open the link with IPXCP, IPXCP > implementations will presumably exchange IPXCP configuration packets. > During this time, IPX WAN packets of any type MUST NOT be sent. IPX > WAN uses a "Timer Request" packet to set up the link. These MUST NOT > be sent while attempting to negotiate and Open the link with IPXCP. > It is left to each implementation to determine if it has successfully > negotiated with IPXCP for the link to Open. The above paragraph is unnecessary. IPXCP specifies that nothing will happen until the NCP reaches the Open state. Successful negotiation must be specified in Bill's IPXCP doc. I know, you can't require options, or at least that's against the PPP option philosophy, but there ARE some basic requirements, like network number. Also, short of relying on manual link delay configuration on both ends, how do we reccommend an LQM echo measurement and calculation? > If an implementation has determined that it cannot Open the link with > IPXCP, then it SHOULD attempt to negotiate and Open the link with IPX > WAN. IPX WAN implementations will exchange "Timer Request" packets. > It is left to each implementation to determine if it has successfully > negotiated with IPX WAN for the link to Open. > > Note that no IPXCP negotiations are required for successfully > negotiating and Opening using IPX WAN. The above two paragraphs don't make sense in light of the requirement that no IPXWAN happens until IPXCP reaches the open state. Chris From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 23 12:52:32 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07965; Thu, 23 Jul 92 12:39:58 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA25806; Thu, 23 Jul 92 12:19:40 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07183; Thu, 23 Jul 92 12:14:17 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06952; Thu, 23 Jul 92 12:06:22 -0700 Received: from na.novell.com.novell.com (na.Novell.COM) by newsun.novell.com with SMTP id AA17299 (5.65c/IDA-1.4.4 for ); Thu, 23 Jul 1992 12:04:06 -0700 Received: by na.novell.com.novell.com (4.1/SMI-4.1) id AA06703; Thu, 23 Jul 92 12:06:24 PDT Date: Thu, 23 Jul 92 12:06:24 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9207231906.AA06703@na.novell.com.novell.com> To: bob@MorningStar.Com, brian@lloyd.com Subject: Re: Connect Timer in LCP Cc: cranch@novell.com, ietf-ppp@ucdavis.ucdavis.edu Hi, > From bob@MorningStar.Com Thu Jul 23 06:27:55 1992 > > Date: Wed, 22 Jul 92 21:01:13 PDT > From: brian@lloyd.com (Brian Lloyd) > > [The connect timer is intended] to keep track of the amount of time > that the link was up so that they could kill the link if people > stayed on too long > > I agree that keeping track of connect time (the time elapsed since > the link came up and LCP was successfully negotiated) seems to me > to be an LCP function and not an NCP function. > > Yes, such a timer should be in LCP, not an NCP, so it would be > available to users of any protocol family. Remember, the NCP's will all be affected, not selectivley available to certain protocols. > But, staying in Columbus and being connected behind too slow a link to > listen in on the real-time audiocast, I missed all the live > discussions at the IETF meeting. So (being unfamiliar with > traditional ARAP) I'd appreciate a brief discussion of the reason for > including this. The PPP discussions, nor the off-site ppp-ipx meeting were audiocast. > Why is such a timer considered a negotiable parameter at all? Each > end of the link can maintain its own connection timer. The one that > considers its resources more scarce will send the first > Terminate-Request when it thinks its modem should be freed, and link > taken down. (Our PPP can already do this: The administrator can > configure the traffic filter so that no packets are "interesting > enough" to count against the idle timer. It's single-ended and > non-negotiable.) This gets into the basic philosophy of what options are used for. Most are consistent with the original intent of truly negotiating parameters. Some, including this one, are there for communicating certain information, not negotiating it. > Or is the initial LCP connect timer "negotiation" actually only > informational, so that (e.g.) the resource-limited server can inform > the client that "you'll only have 5 minutes here, so inform your > administrator to get expeditiously about h{is,er} business"? Yep, informational. You explain well the intent of the feature. > And you mentioned "keeping track of the connect time", from which I > infer a different possible meaning than the above. Do you mean that > the peers will periodically exchange packets describing how long they > think the link has been up? Then why not put it into LQM? Not periodically, just while the LCP converges for the first time. > And why > exchange the packets at all, if each peer has a clock anyway so that > it knows what time value to put into the timer packets it sends? If > the peers exchange periodic informational total-connect-time packets, > what should they do if their values converge beyond some epsilon? Are > we reimplementing NTP? The intent is just to inform the other side how much time will be allowed, before they're booted off. That just will enable a background timer on the client's user interface to count down to disconnect. > Maybe I should just wait and read the draft... This shows the lack of detail in the ATCP option and the IPXCP option. > From brian@lloyd.com Thu Jul 23 08:06:58 1992 > > Gee, it has been quite a while since the discussion went on and, > frankly, I don't remember why ARAP wanted/needed a connect-time timer. > Since I appear to be so feeble minded could someone (Brad?) please > enlighten me one more time. I believe this grew out of a feature in AppleLink, which has been around for about 7 years. Count down, then you get disconnected. This was to free up modems so others can connect. > [Brian turns away from the workstation screen, gathers his shawl about > his shoulders, and struggles to the upright position. He then slowly > hobbles away using his walker.] :-) So you have a body double that you send to meetings? ;) Chris From ietf-ppp-request@ucdavis.ucdavis.edu Sun Jul 26 20:30:23 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06038; Sun, 26 Jul 92 20:21:03 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA14832; Sun, 26 Jul 92 20:09:30 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05616; Sun, 26 Jul 92 20:00:36 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05476; Sun, 26 Jul 92 19:54:22 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA19420; Sun, 26 Jul 92 19:53:07 PDT Date: Sun, 26 Jul 92 19:53:07 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9207270253.AA19420@ray.lloyd.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: DECnet draft Steve Senum has modified his document for DECnet over PPP. Please read it and comment. I would like to go to last call for this so that we can recommend it to the IESG quickly (assuming no problems, of course). This document reflects the activities of the WG in Boston so it should be pretty solid. 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 Jul 28 07:40:56 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01913; Tue, 28 Jul 92 07:31:26 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA25341; Tue, 28 Jul 92 07:09:32 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00982; Tue, 28 Jul 92 07:00:37 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from babyoil.ftp.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00822; Tue, 28 Jul 92 06:55:29 -0700 Received: from gordon.repeater.ftp.com by ftp.com via PCMAIL with DMSP id AA06777; Tue, 28 Jul 92 09:54:07 -0400 Date: Tue, 28 Jul 92 09:54:07 -0400 Message-Id: <9207281354.AA06777@ftp.com> To: CONGDON_PAUL/HP5200_15@hprdash.rose.hp.com Subject: Re: IPCP Address Negotiation From: gordon@ftp.com (Gordon Lee) Cc: ietf-ppp@ucdavis.ucdavis.edu Repository: babyoil.ftp.com Originating-Client: repeater.ftp.com > From: CONGDON_PAUL/HP5200_15@hprdash.rose.hp.com > > I've been thinking about the use of IP address negotiation > in PPP and was wondering how people us it today. > > A few problems: > > 1. Directory look-ups: How does your temporary IP > address to name mapping get updated? Is this a > problem? Some people "solve" (a better word would be "address") this problem by maintaining two different hostnames. However the tone of your message suggests that you want to have one hostname. (It is the optimal solution afterall). Clearly it is possible to list more than one address for a hostname in the DNS database. However, this is only half of the solution, and the problem lies elsewhere. The problem: A name resolution service can return a set of addresses which apply to a given hostname, but the receiving client will not know at any given time which address to use, and most existing applications will use the first address on the list and ignore the others. The solution: If you have control over the app (you're developing it, or have sufficient influence with those who are) then you can make it behave as follows: - contact first address - if failure, contact second address - if failure, contact third address, etc - if all addresses fail, then no contact can be made If you are using an off-the-shelf app which is not smart, you are stuck. But wait! A further complication: Dialup PPP routers are being designed to hand out IP addresses dynamically from a pool of available addresses. This complicates the above solution because in this scenario dial-in clients are not constrained to using a particular address. Thus the DNS database would have to list the entire pool of dialup PPP IP-addresses under a particular hostname, but then there are other hostnames which may be using these available addresses also, and the system admin cannot know which because they are assigned randomly and non-deterministically. The only solution I can think of off the top of my head would be some scheme where the PPP router updates the DNS system dynamically at the time it issues the IP-address. I assume this is blue sky at this point, but perhaps the PPP router vendors are already dealing with this problem ? (comments? confirmation? demial?) > 2. Security based on IP address (e.g. .rhosts): How > can it work? Prevailing wisdom has it that the two strongest security solutions are: - Physical security of the wire - End to end security of upper layer protocols Anything based on intermediate-system security is at a greater risk of compromise. - GL == Gordon Lee == voice: (617) 246-0900 == fax: (617) 245-7943 == FTP Software Inc. == 26 Princess St == Wakefield, MA 01880-3004 From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 29 08:41:29 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14786; Wed, 29 Jul 92 08:37:46 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05072; Wed, 29 Jul 92 07:59:32 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13425; Wed, 29 Jul 92 07:50:50 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [132.151.1.35] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13400; Wed, 29 Jul 92 07:50:00 -0700 Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa01435; 29 Jul 92 10:40 EDT Mime-Version: 1.0 Content-Type: text/plain; Charset="us-ascii" Org: Corp. for National Research Initiatives Phone: (703) 620-8990 ; Fax: (703) 620-0913 To: Brian Lloyd , The PPPext WG Cc: The IESG , Van Jacobsen Subject: TCP/IP Header Compression Date: Wed, 29 Jul 92 10:40:57 -0400 From: Greg Vaudreuil Message-Id: <9207291040.aa01435@IETF.NRI.Reston.VA.US> Brian and other PPPers, Several observations were made during the last call period for elevating RFC1144 to Draft Standard Status. The IESG solicits specific comments on the possible necessity of producing a new version of the specification given the following: Bill Simpson noted that several fixes were needed to the algorithm as documented in RFC1144. He offered CSLIP as a reference implementation to base changes to RFC1144. Are these fixes documented in any subsequent RFC's or is a new version of the document needed? RFC 1332 specifies extensions to the Header Compression protocol. Are these in any way incompatable with the current RFC1144, or will implementing RFC1144 without these extensions cause interoperability problems? RFC1132 is not available in an ASCII version. The IESG has interpreted this to mean that an ASCII version needs to be available for "older" protocols before they become Draft Standard. Is this reasonable? Please send comments to the IESG mailing list. Thanks. Greg Vaudreuil IESG Secretary From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 29 09:25:19 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15952; Wed, 29 Jul 92 09:14:26 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05351; Wed, 29 Jul 92 08:29:39 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14307; Wed, 29 Jul 92 08:20:41 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from rx7.ee.lbl.gov by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14256; Wed, 29 Jul 92 08:19:29 -0700 Received: by rx7.ee.lbl.gov for ietf-ppp@ucdavis.edu (5.65/1.44r) id AA25957; Wed, 29 Jul 92 08:19:16 -0700 Message-Id: <9207291519.AA25957@rx7.ee.lbl.gov> To: Greg Vaudreuil Cc: Brian Lloyd , The PPPext WG , The IESG Subject: Re: TCP/IP Header Compression In-Reply-To: Your message of Wed, 29 Jul 92 10:40:57 EDT. Date: Wed, 29 Jul 92 08:19:14 PDT From: Van Jacobson > Bill Simpson noted that several fixes were needed to the algorithm as > documented in RFC1144. He offered CSLIP as a reference implementation > to base changes to RFC1144. This is the first I've heard of fixes needed to the algorithm in 1144. Could someone tell me what they are? Thanks. I know of 3 one-line fixes that should be made to the sample code in appendix A of 1144 but the algorithm & the sample code are, of course, completely different things. Also could someone point me at Bill Simpson's CSLIP reference implementation? Thanks. - Van From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 29 15:52:42 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28370; Wed, 29 Jul 92 15:49:07 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09842; Wed, 29 Jul 92 14:59:55 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26393; Wed, 29 Jul 92 14:50:57 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26052; Wed, 29 Jul 92 14:40:54 -0700 Received: from na.novell.com.novell.com (na.Novell.COM) by newsun.novell.com with SMTP id AA08641 (5.65c/IDA-1.4.4 for ); Wed, 29 Jul 1992 14:39:33 -0700 Received: by na.novell.com.novell.com (4.1/SMI-4.1) id AA08015; Wed, 29 Jul 92 14:41:58 PDT Date: Wed, 29 Jul 92 14:41:58 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9207292141.AA08015@na.novell.com.novell.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: New IPXWAN Internet Draft Cc: cranch@novell.com, mallen@novell.com Hello All, There is a new version of IPXWAN on ftp.novell.com. There were no technical modifications except for adding a negotiation option for Telebit Compression. All other changes were clarification, boilerplates. expiration dates, and such. Please read and comment. Consider this to be the last call phase. Unless we get talked into doing otherwise, we will submit it to Jon Postel, our faithful rfc editor, as an informational rfc on Wednesday August 12, 1992. Your favorite IPXWAN scapegoat, Chris Ranch From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 30 11:52:34 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03994; Thu, 30 Jul 92 11:47:47 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA16428; Thu, 30 Jul 92 10:29:53 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01253; Thu, 30 Jul 92 10:22:04 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01166; Thu, 30 Jul 92 10:19:28 -0700 Received: from napa.TELEBIT.COM by apache (4.1/SMI-4.1/Telebit-Apache-Brent-920708) id AA14919 to ietf-ppp@ucdavis.edu; Thu, 30 Jul 92 10:17:57 PDT Received: from yoyo.telebit.com by napa.TELEBIT.COM (4.1/napa.telebit.com-Brent-920717) id AA00229 to bsimpson@angband.stanford.edu; Thu, 30 Jul 92 10:17:55 PDT Date: Thu, 30 Jul 92 10:17:55 PDT From: mlewis@napa.Telebit.COM (Mark S. Lewis) Message-Id: <9207301717.AA00229@napa.TELEBIT.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA18877; Thu, 30 Jul 92 10:19:14 PDT To: cranch@novell.com Cc: bsimpson@angband.stanford.edu, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <9207231846.AA06195@na.novell.com.novell.com> "cranch@novell.com" Subject: PPP work in progress Chris, I have been thinking about your comments. There seem to be a couple of key points that change the way this document goes. 1) My first assumption was that you try IPXCP first then IPXWAN. This is an either or thing. If IPXCP fails use IPXWAN. They are alternate negotiation techniques. You are saying that they work together. The IPXCP NCP must go open before you can use IPXWAN. A couple of things bother me about your approach. First, it seems inconsistent to open without exchanging any IPXCP config requests/acks. Isn't this true that IPXWAN only implementations will just presume that the NCP goes open and then exchange IPXWAN timer request packets. Are there any other NCPs were you go open by assumtion and not by a satisfactory exchange of at least one NCP config request packet. Second, why do we need the NCP for connections that use IPXWAN? Initially, I don't see any benefit to keeping track of the IPXCP NCP state etc. when the link is negotiated and managed with IPXWAN. Perhaps this has been discussed but I would like to know why we need it here. It seems to me that these are alternate techniques and we should treat them as such. 2) It seems to me that implementations should determine what IPXCP options they require to go open. I can't forsee any applications which would not require the network number, but some may require the node number and other not. Likewise other options may be required for some implementations and not others. Also, some implementations statically configure options and don`t need to negotiate. In other NCPs like IPCP, if you need want to negotiate address you do so. There is no requirement. I think we should leave it up to the application to determine it's own requirements for its specific application. ... Mark > Hi, > I like where this is going. I have some other suggestions. > Chris >> From: mlewis@napa.Telebit.COM (Mark S. Lewis) >> >> As I promised, I wanted to send some text that may help clarify the >> following section of your IPXCP draft. >> >> ... Mark >> >> ---------------------------- Original --------------------------- >> [deleted for brevity] >> ---------------------------- Suggestion --------------------------- >> >> 1.2. IPX WAN protocol >> >> IPX may be used over a variety of data link protocols. Novell has >> recently announced a new specification called IPX WAN [4], which is >> intended to provide mechanisms similar to PPP NCP negotiation over >> all types of wide area links. It is the intent of this document to >> provide equivalent functionality for those implementations that do >> not already include IPX WAN, without interfering with those >> implementations that also include IPX WAN. > > IPX may be used over a variety of data link protocols. Novell has > recently announced a new specification called IPX WAN [4], which is > intended to provide mechanisms similar to PPP NCP negotiation, and > link delay measurement over all types of wide area links. It is the > intent of this document to provide equivalent functionality for those > implementations that do not include IPX WAN, without interfering with > implementations that do include IPX WAN. > >> The general strategy is to first attempt to negotiate and Open the >> link with IPXCP. If this is unsucessful, then attempt to negotiate >> and Open the link using IPX WAN. If this is unsuccessful, the link >> cannot be Opened. This established order of precedence will allow >> successful interoperation between implementations of IPXCP and IPX >> WAN. > [Note: IPXWAN is NOT intended to replace the IPXCP state > machine. The IPX NCP MUST reach the Open state before anything > else.] > The general strategy is to first attempt to negotiate required options, > and Open the link with IPXCP. If any of the required options are > rejected, then IPXWAN MUST complete its packet exchange before IPX/SPX > data may be forwarded down the link. Then, if IPXWAN fails to complete, > IPXCP MUST enter into the closed state. This order of precedence will > allow interoperation between IPXWAN implementations, and between IPXCP > without IPXWAN implementations. >> While attempting to negotiate and Open the link with IPXCP, IPXCP >> implementations will presumably exchange IPXCP configuration packets. >> During this time, IPX WAN packets of any type MUST NOT be sent. IPX >> WAN uses a "Timer Request" packet to set up the link. These MUST NOT >> be sent while attempting to negotiate and Open the link with IPXCP. >> It is left to each implementation to determine if it has successfully >> negotiated with IPXCP for the link to Open. > The above paragraph is unnecessary. IPXCP specifies that nothing > will happen until the NCP reaches the Open state. Successful > negotiation must be specified in Bill's IPXCP doc. I know, > you can't require options, or at least that's against the PPP > option philosophy, but there ARE some basic requirements, like > network number. Also, short of relying on manual link delay > configuration on both ends, how do we reccommend an LQM echo > measurement and calculation? >> If an implementation has determined that it cannot Open the link with >> IPXCP, then it SHOULD attempt to negotiate and Open the link with IPX >> WAN. IPX WAN implementations will exchange "Timer Request" packets. >> It is left to each implementation to determine if it has successfully >> negotiated with IPX WAN for the link to Open. >> >> Note that no IPXCP negotiations are required for successfully >> negotiating and Opening using IPX WAN. > The above two paragraphs don't make sense in light of the > requirement that no IPXWAN happens until IPXCP reaches the > open state. > Chris From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 30 12:22:29 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04969; Thu, 30 Jul 92 12:17:35 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17084; Thu, 30 Jul 92 11:39:43 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03562; Thu, 30 Jul 92 11:33:27 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03355; Thu, 30 Jul 92 11:28:51 -0700 Received: from na.novell.com.novell.com (na.Novell.COM) by newsun.novell.com with SMTP id AA04694 (5.65c/IDA-1.4.4 for ); Thu, 30 Jul 1992 11:27:21 -0700 Received: by na.novell.com.novell.com (4.1/SMI-4.1) id AA19166; Thu, 30 Jul 92 11:29:45 PDT Date: Thu, 30 Jul 92 11:29:45 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9207301829.AA19166@na.novell.com.novell.com> To: cranch@novell.com, mlewis@telebit.com Subject: Re: PPP work in progress Cc: bsimpson@angband.stanford.edu, ietf-ppp@ucdavis.ucdavis.edu Hi Mark, > I have been thinking about your comments. There seem to be a couple > of key points that change the way this document goes. > > 1) My first assumption was that you try IPXCP first then IPXWAN. This > is an either or thing. If IPXCP fails use IPXWAN. They are alternate > negotiation techniques. You are saying that they work together. The > IPXCP NCP must go open before you can use IPXWAN. IPXCP open + IPXWAN done = ok to send traffic. Your last sentence is accurate. > A couple of things bother me about your approach. First, it seems > inconsistent to open without exchanging any IPXCP config > requests/acks. Huh? Ask away, NetWare will just reject them all. The state machine is totally unchanged. Please expand on your view of the inconsistencies. > Isn't this true that IPXWAN only implementations will > just presume that the NCP goes open and then exchange IPXWAN timer > request packets. Absolutely not! IPXWAN must *WAIT* for IPXCP to go open. Or an X.25 call to complete, or anything else media specific that's analogous. > Are there any other NCPs were you go open by > assumtion and not by a satisfactory exchange of at least one NCP > config request packet. Assuming you were asking for another example of an NCP opening without asking for at least one option, AppleTalk is a good example. You don't need any options whatsoever to be a real half-router link. > Second, why do we need the NCP for connections that use IPXWAN? > Initially, I don't see any benefit to keeping track of the IPXCP NCP > state etc. when the link is negotiated and managed with IPXWAN. > Perhaps this has been discussed but I would like to know why we need > it here. So you can demultiplex multiple protocols concurrently. So we can maintain backwards and forwards comptaibility with IPXCP only implementations and IPXWAN only implementations. By definition, I understand you *can't* send certain protocol packets *until* the NCP is open! I could go on! > It seems to me that these are alternate techniques and we should treat > them as such. I most strongly disagree. Furthermore, this would be a signifcant protocol change, and we cannot change it. > 2) It seems to me that implementations should determine what IPXCP > options they require to go open. I can't forsee any applications > which would not require the network number, but some may require the > node number and other not. Likewise other options may be required for > some implementations and not others. Yes, I agree. I remember Bill agreeing that we must specify a required list of options for various scenarios. I know this goes against the PPP rule that options are *optional*. Isn't that what rules are for [to be broken ;]? Something tells me the cumulative blood pressure is increasing in Michigan :). > Also, some implementations statically configure options and don`t need > to negotiate. In other NCPs like IPCP, if you need want to negotiate > address you do so. There is no requirement. I think we should leave > it up to the application to determine it's own requirements for its > specific application. I thought the manual configuration problem is one of the *goals* for LCP and NCP options! We could fall back to manual configuration of everything, then what do we need PPP at all for? That may seem sarcastic, but what are you getting at? Oh, leaving it up to the implementation as to what options it requires. That seems to contradict your previous paragraph. Implementors may want Novell's advice as to what options we would require for various scenarios if we were to rely soley on IPXCP. That would also require LQM echoes to do link delay measurements. You may be able to rely on modem bit rate or serial port bit rate to do a psuedo-manual configuration/calculation for your current async implementations, but this will fall to pieces over any switched virtual circuit. [Side note, can you get the bit rate out of a synchronous interface that's being externally clocked?] I hope I don't sound like I'm in too bad of a mood. :) Chris > ... Mark > > > > Hi, > > > I like where this is going. I have some other suggestions. > > > Chris > > >> From: mlewis@napa.Telebit.COM (Mark S. Lewis) > >> > >> As I promised, I wanted to send some text that may help clarify the > >> following section of your IPXCP draft. > >> > >> ... Mark > >> > >> ---------------------------- Original --------------------------- > >> [deleted for brevity] > >> ---------------------------- Suggestion --------------------------- > >> > >> 1.2. IPX WAN protocol > >> > >> IPX may be used over a variety of data link protocols. Novell has > >> recently announced a new specification called IPX WAN [4], which is > >> intended to provide mechanisms similar to PPP NCP negotiation over > >> all types of wide area links. It is the intent of this document to > >> provide equivalent functionality for those implementations that do > >> not already include IPX WAN, without interfering with those > >> implementations that also include IPX WAN. > > > > IPX may be used over a variety of data link protocols. Novell has > > recently announced a new specification called IPX WAN [4], which is > > intended to provide mechanisms similar to PPP NCP negotiation, and > > link delay measurement over all types of wide area links. It is the > > intent of this document to provide equivalent functionality for those > > implementations that do not include IPX WAN, without interfering with > > implementations that do include IPX WAN. > > > >> The general strategy is to first attempt to negotiate and Open the > >> link with IPXCP. If this is unsucessful, then attempt to negotiate > >> and Open the link using IPX WAN. If this is unsuccessful, the link > >> cannot be Opened. This established order of precedence will allow > >> successful interoperation between implementations of IPXCP and IPX > >> WAN. > > > [Note: IPXWAN is NOT intended to replace the IPXCP state > > machine. The IPX NCP MUST reach the Open state before anything > > else.] > > > The general strategy is to first attempt to negotiate required options, > > and Open the link with IPXCP. If any of the required options are > > rejected, then IPXWAN MUST complete its packet exchange before IPX/SPX > > data may be forwarded down the link. Then, if IPXWAN fails to complete, > > IPXCP MUST enter into the closed state. This order of precedence will > > allow interoperation between IPXWAN implementations, and between IPXCP > > without IPXWAN implementations. > > >> While attempting to negotiate and Open the link with IPXCP, IPXCP > >> implementations will presumably exchange IPXCP configuration packets. > >> During this time, IPX WAN packets of any type MUST NOT be sent. IPX > >> WAN uses a "Timer Request" packet to set up the link. These MUST NOT > >> be sent while attempting to negotiate and Open the link with IPXCP. > >> It is left to each implementation to determine if it has successfully > >> negotiated with IPXCP for the link to Open. > > > The above paragraph is unnecessary. IPXCP specifies that nothing > > will happen until the NCP reaches the Open state. Successful > > negotiation must be specified in Bill's IPXCP doc. I know, > > you can't require options, or at least that's against the PPP > > option philosophy, but there ARE some basic requirements, like > > network number. Also, short of relying on manual link delay > > configuration on both ends, how do we reccommend an LQM echo > > measurement and calculation? > > >> If an implementation has determined that it cannot Open the link with > >> IPXCP, then it SHOULD attempt to negotiate and Open the link with IPX > >> WAN. IPX WAN implementations will exchange "Timer Request" packets. > >> It is left to each implementation to determine if it has successfully > >> negotiated with IPX WAN for the link to Open. > >> > >> Note that no IPXCP negotiations are required for successfully > >> negotiating and Opening using IPX WAN. > > > The above two paragraphs don't make sense in light of the > > requirement that no IPXWAN happens until IPXCP reaches the > > open state. > > > Chris > > From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 30 13:55:23 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07806; Thu, 30 Jul 92 13:43:20 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA18431; Thu, 30 Jul 92 13:19:42 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06784; Thu, 30 Jul 92 13:11:09 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06533; Thu, 30 Jul 92 13:03:57 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA22716; Thu, 30 Jul 92 13:01:12 PDT Date: Thu, 30 Jul 92 13:01:12 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9207302001.AA22716@ray.lloyd.com> To: mlewis@napa.Telebit.COM Cc: cranch@novell.com, bsimpson@angband.stanford.edu, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Mark S. Lewis's message of Thu, 30 Jul 92 10:17:55 PDT <9207301717.AA00229@napa.TELEBIT.COM> Subject: PPP work in progress Well, if it is PPP you have to do a negotiation. You cannot assume that the NCP is open until you have successfully exchanged and acked config requests. This means that, if you do IPXWAN, you must negotiate a set of null config requests. THEN you can negotiate using the IPXWAN technique. The key point here is that the IPX NCP goes open and you are free to send anything you want back and forth using the IPX protocol ID, including IPXWAN packets. 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 Thu Jul 30 14:17:22 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08695; Thu, 30 Jul 92 14:09:41 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA18683; Thu, 30 Jul 92 13:49:42 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07800; Thu, 30 Jul 92 13:43:08 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07419; Thu, 30 Jul 92 13:30:19 -0700 Received: from napa.TELEBIT.COM by apache (4.1/SMI-4.1/Telebit-Apache-Brent-920708) id AA18255 to ietf-ppp@ucdavis.edu; Thu, 30 Jul 92 13:27:19 PDT Received: from yoyo.telebit.com by napa.TELEBIT.COM (4.1/napa.telebit.com-Brent-920717) id AA09196 to brian@lloyd.com; Thu, 30 Jul 92 13:27:18 PDT Date: Thu, 30 Jul 92 13:27:18 PDT From: mlewis@napa.Telebit.COM (Mark S. Lewis) Message-Id: <9207302027.AA09196@napa.TELEBIT.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA18921; Thu, 30 Jul 92 13:28:35 PDT To: cranch@novell.com Cc: brian@lloyd.com, mallen@novell.com, bsimpson@angband.stanford.edu, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <9207301829.AA19166@na.novell.com.novell.com> "cranch@novell.com" Subject: PPP work in progress I don't think you quite understood what I didn't like about how IPXCP opens. The document as written says IPXCP must be open before IPXWAN packets can be sent. However, you say Novell stuff will reject any IPXCP option request. So there is not option request and corresponding ack, but IPXCP is supposed to go open. It must go open because it thinks it's the right thing to do not because of a successful IPXCP config exchange. Doesn't sound right to me. I think IPXCP should exchange null config requests and ack them. This means we don't need options but we negotiate the link open. The problem here is, Novell's implementation will not send nor ack a null IPXCP config request. So I guess thats how we got into this implicit open action. Also, I now see why we need the NCP when using IPXWAN. I officially recant my suggestion. We need the IPXCP NCP to work with IPXWAN. ... Mark > Hi Mark, >> I have been thinking about your comments. There seem to be a couple >> of key points that change the way this document goes. >> >> 1) My first assumption was that you try IPXCP first then IPXWAN. This >> is an either or thing. If IPXCP fails use IPXWAN. They are alternate >> negotiation techniques. You are saying that they work together. The >> IPXCP NCP must go open before you can use IPXWAN. > IPXCP open + IPXWAN done = ok to send traffic. Your last > sentence is accurate. >> A couple of things bother me about your approach. First, it seems >> inconsistent to open without exchanging any IPXCP config >> requests/acks. > Huh? Ask away, NetWare will just reject them all. The state > machine is totally unchanged. Please expand on your view of the > inconsistencies. >> Isn't this true that IPXWAN only implementations will >> just presume that the NCP goes open and then exchange IPXWAN timer >> request packets. > Absolutely not! IPXWAN must *WAIT* for IPXCP to go open. > Or an X.25 call to complete, or anything else media specific > that's analogous. >> Are there any other NCPs were you go open by >> assumtion and not by a satisfactory exchange of at least one NCP >> config request packet. > Assuming you were asking for another example of an NCP opening > without asking for at least one option, AppleTalk is a good > example. You don't need any options whatsoever to be a real > half-router link. >> Second, why do we need the NCP for connections that use IPXWAN? >> Initially, I don't see any benefit to keeping track of the IPXCP NCP >> state etc. when the link is negotiated and managed with IPXWAN. >> Perhaps this has been discussed but I would like to know why we need >> it here. > So you can demultiplex multiple protocols concurrently. So we > can maintain backwards and forwards comptaibility with IPXCP > only implementations and IPXWAN only implementations. By > definition, I understand you *can't* send certain protocol > packets *until* the NCP is open! I could go on! >> It seems to me that these are alternate techniques and we should treat >> them as such. > I most strongly disagree. Furthermore, this would be a signifcant > protocol change, and we cannot change it. >> 2) It seems to me that implementations should determine what IPXCP >> options they require to go open. I can't forsee any applications >> which would not require the network number, but some may require the >> node number and other not. Likewise other options may be required for >> some implementations and not others. > Yes, I agree. I remember Bill agreeing that we must specify > a required list of options for various scenarios. I know this > goes against the PPP rule that options are *optional*. Isn't that > what rules are for [to be broken ;]? Something tells me the > cumulative blood pressure is increasing in Michigan :). >> Also, some implementations statically configure options and don`t need >> to negotiate. In other NCPs like IPCP, if you need want to negotiate >> address you do so. There is no requirement. I think we should leave >> it up to the application to determine it's own requirements for its >> specific application. > I thought the manual configuration problem is one of the *goals* > for LCP and NCP options! We could fall back to manual configuration > of everything, then what do we need PPP at all for? That may seem > sarcastic, but what are you getting at? Oh, leaving it up to the > implementation as to what options it requires. That seems to > contradict your previous paragraph. Implementors may want Novell's > advice as to what options we would require for various scenarios > if we were to rely soley on IPXCP. That would also require LQM > echoes to do link delay measurements. You may be able to rely > on modem bit rate or serial port bit rate to do a psuedo-manual > configuration/calculation for your current async implementations, > but this will fall to pieces over any switched virtual circuit. > [Side note, can you get the bit rate out of a synchronous interface > that's being externally clocked?] > I hope I don't sound like I'm in too bad of a mood. :) > Chris From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 30 14:33:01 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09312; Thu, 30 Jul 92 14:26:24 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA18905; Thu, 30 Jul 92 14:09:33 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08441; Thu, 30 Jul 92 14:01:08 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08278; Thu, 30 Jul 92 13:57:14 -0700 Received: from na.novell.com.novell.com (na.Novell.COM) by newsun.novell.com with SMTP id AA07934 (5.65c/IDA-1.4.4 for ); Thu, 30 Jul 1992 13:54:30 -0700 Received: by na.novell.com.novell.com (4.1/SMI-4.1) id AA27677; Thu, 30 Jul 92 13:56:52 PDT Date: Thu, 30 Jul 92 13:56:52 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9207302056.AA27677@na.novell.com.novell.com> To: brian@lloyd.com, mlewis@napa.Telebit.COM Subject: Re: PPP work in progress Cc: bsimpson@angband.stanford.edu, ietf-ppp@ucdavis.ucdavis.edu Hi Everyone, > From brian@lloyd.com Thu Jul 30 13:05:26 1992 > In-Reply-To: Mark S. Lewis's message of Thu, 30 Jul 92 10:17:55 PDT <9207301717.AA00229@napa.TELEBIT.COM> > > Well, if it is PPP you have to do a negotiation. You cannot assume > that the NCP is open until you have successfully exchanged and acked > config requests. This means that, if you do IPXWAN, you must > negotiate a set of null config requests. THEN you can negotiate using > the IPXWAN technique. The key point here is that the IPX NCP goes > open and you are free to send anything you want back and forth using > the IPX protocol ID, including IPXWAN packets. One thing to add, in IPXCP Bill is specifying that if you don't get the options you need (read: none), IPXWAN completion is required before IPX packets can be sent. The way you put it, Brian, was a little too ambiguous, and assicoated with the latest confusion. I guess I'm still in a bad mood (but getting better :). Chris From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 30 15:18:02 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10731; Thu, 30 Jul 92 15:06:35 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA19170; Thu, 30 Jul 92 14:39:37 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09546; Thu, 30 Jul 92 14:31:48 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09283; Thu, 30 Jul 92 14:25:08 -0700 Received: from na.novell.com.novell.com (na.Novell.COM) by newsun.novell.com with SMTP id AA08509 (5.65c/IDA-1.4.4 for ); Thu, 30 Jul 1992 14:22:52 -0700 Received: by na.novell.com.novell.com (4.1/SMI-4.1) id AA01029; Thu, 30 Jul 92 14:25:14 PDT Date: Thu, 30 Jul 92 14:25:14 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9207302125.AA01029@na.novell.com.novell.com> To: cranch@novell.com, mlewis@telebit.com Subject: Re: PPP work in progress Cc: brian@lloyd.com, bsimpson@angband.stanford.edu, ietf-ppp@ucdavis.ucdavis.edu, mallen@novell.com Hi Mark, > From: mlewis@napa.Telebit.COM (Mark S. Lewis) > > I don't think you quite understood what I didn't like about how IPXCP > opens. The fact that I haven't watched this converge myself is relected in my ability to articulate what I mean. I'll try to get it right... > The document as written says IPXCP must be open before IPXWAN > packets can be sent. Right. > However, you say Novell stuff will reject any > IPXCP option request. NetWare will reject options, and ack a null configure request. Anything less will be breaking the defined state machine. > So there is not option request and > corresponding ack, but IPXCP is supposed to go open. We send a configure request with no options in it. We expect the same, and we will ack it. Requested options will be rejected in the normal way. > It must go open > because it thinks it's the right thing to do not because of a > successful IPXCP config exchange. Doesn't sound right to me. How about now? > I think IPXCP should exchange null config requests and ack them. We do. > This means we don't need options but we negotiate the link open. Right. I think this could be made more clear in IPXWAN. > The > problem here is, Novell's implementation will not send nor ack a null > IPXCP config request. Yes, we do. Always have, always will. > So I guess thats how we got into this implicit > open action. That, or something that needed explicit discussion in the IPXWAN spec. We'll add some more words so nobody else will to go down this path. Chris From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 30 15:25:51 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11121; Thu, 30 Jul 92 15:17:11 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA19197; Thu, 30 Jul 92 14:43:00 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09571; Thu, 30 Jul 92 14:32:46 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09401; Thu, 30 Jul 92 14:29:51 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA22765; Thu, 30 Jul 92 14:28:28 PDT Date: Thu, 30 Jul 92 14:28:28 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9207302128.AA22765@ray.lloyd.com> To: mlewis@Telebit.COM Cc: cranch@novell.com, mallen@novell.com, bsimpson@angband.stanford.edu, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Mark S. Lewis's message of Thu, 30 Jul 92 13:27:18 PDT <9207302027.AA09196@napa.TELEBIT.COM> Subject: PPP work in progress This is what the NCP exchange would look like in the IPXWAN case: Telebit side Novell Side Config-REQ (bunch of options) ---> <--------- Config-REQ (no options) <--- Config-NAK (bunch of options) Config-ACK (no options) ---------> Config-REQ (no options) ---------> <--------- Config-ACK (no options) *** Now start doing the IPXWAN packet exchange here *** Note that the Novell side will config-NAK any options you try to send forcing you to fall back to sending an empty config-REQ. They wills send you an empty config-REQ the first time which you should ACK. Simple and completely within the protocol. 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 Fri Jul 31 17:12:01 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25094; Fri, 31 Jul 92 17:00:20 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA28464; Fri, 31 Jul 92 15:39:40 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22297; Fri, 31 Jul 92 15:31:25 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22101; Fri, 31 Jul 92 15:27:18 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA26298; Fri, 31 Jul 92 15:25:23 PDT Date: Fri, 31 Jul 92 15:25:23 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9207312225.AA26298@saffron.acc.com> To: sjs@anubis.network.com Subject: Re: Bridging over PPP Cc: ietf-ppp@ucdavis.ucdavis.edu >> Craig Fox mentioned that you were considering makeing some changes >> to the current Bridging over PPP RFC. I was wondering if you could >> tell me what they might be. There seems to be a consensus behind obsoleting the Mac Type option and the LAN ID. I have had three vendors specifically ask me for a MAC Address Negotiation option. I need to tighten up the language in the source routing options to guide negotiations. If I say, for example, that I am running a transparent link, I might send a ring-and-bridge option saying that my (virtual or real) ring number is FOO and I consider my self bridge 2. If you say you have ring FOO, we're in trouble, and I have to reject it or something. If you say you have ring BAR and bridge 1, I might NAK that you have ring BAR and bridge 2. But the "who wins" rule is not specified. There is no substantive reason to choose one rule over another; the point is to break the tie. I suggest (consistent with a couple of other specifications) that the NUMERICALLY HIGHER number wins. I have not planned to do anything with the TR BPDU, although Kirke Preiss and I are playing telephone tag to discuss the subject. My take at the moment is: that is 802.5 specific, leave it in an 802.5 frame. Fred