From ietf-ppp-request@ucdavis.ucdavis.edu Sun Dec 1 22:01:45 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA29292; Sun, 1 Dec 91 21:45:34 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ALLSPICE.LCS.MIT.EDU by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA29054; Sun, 1 Dec 91 21:33:09 -0800 Received: by PTT.LCS.MIT.EDU id AA24296; Mon, 2 Dec 91 00:31:57 EST Date: Mon, 2 Dec 91 00:31:57 EST From: jnc@PTT.LCS.MIT.EDU (Noel Chiappa) Message-Id: <9112020531.AA24296@PTT.LCS.MIT.EDU> To: bsimpson@vela.acs.oakland.edu, ietf-ppp@ucdavis.edu Subject: Re: CFV: Passive Open Cc: jnc@PTT.LCS.MIT.EDU You guys can run your WG any way you want, but the tradition in the IETF has been to pick the thing which is 'technically right', not the thing which had the most votes (lest we degenerate into Congresstrolls). I know, picking the thing which is T.R. is not always a solvable problem (who is to judge) but let's hold that up as our shining, idealistic, star. Noel From ietf-ppp-request@ucdavis.ucdavis.edu Sun Dec 1 23:16:32 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00707; Sun, 1 Dec 91 23:00:10 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.124.48.2] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00562; Sun, 1 Dec 91 22:51:11 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA03286; Sun, 1 Dec 91 22:48:46 PST Date: Sun, 1 Dec 91 22:48:46 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9112020648.AA03286@ray.lloyd.com> To: jnc@PTT.LCS.MIT.EDU Cc: bsimpson@vela.acs.oakland.edu, ietf-ppp@ucdavis.edu, jnc@PTT.LCS.MIT.EDU In-Reply-To: Noel Chiappa's message of Mon, 2 Dec 91 00:31:57 EST <9112020531.AA24296@PTT.LCS.MIT.EDU> Subject: CFV: Passive Open Noel, basically the active open appears to be a useless appendage. All the implementations of which I am aware always perform an Active Open (AO) to ensure that the link always comes up (it is the safe thing to do). Therefore there appears to be no use for the Passive Open. The 'call for votes' was really a "we want to do away with this but we don't want to cause a problem for someone who thinks that he/she really needs this," call. The point is: if noone can come up with an objection to doing away with PO, PO goes. Is that better? 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 Dec 2 01:45:33 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA03190; Mon, 2 Dec 91 01:15:09 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from enet-gw.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA03031; Mon, 2 Dec 91 01:07:16 -0800 Received: by enet-gw.pa.dec.com; id AA02153; Mon, 2 Dec 91 01:05:45 -0800 Message-Id: <9112020905.AA02153@enet-gw.pa.dec.com> Received: from marvin.enet; by decwrl.enet; Mon, 2 Dec 91 01:05:54 PST Date: Mon, 2 Dec 91 01:05:54 PST From: SEMPER INFACEBO SUMUS - SOLE PROFUNDUM VARIAT 02-Dec-1991 0905 To: jnc@allspice.lcs.mit.edu, ietf-ppp@ucdavis.edu Apparently-To: ietf-ppp@ucdavis.edu, jnc@allspice.lcs.mit.edu Subject: Voting for dropping the Passive Open. > You guys can run your WG any way you want, but the tradition in > the IETF has been to pick the thing which is 'technically right', not the > thing which had the most votes (lest we degenerate into Congresstrolls). > I know, picking the thing which is T.R. is not always a solvable problem > (who is to judge) but let's hold that up as our shining, idealistic, star. > > Noel I believe dropping the Passive Open is technically right beyond any reasonable doubt. That's why I'm voting for it. Dean Morris From ietf-ppp-request@ucdavis.ucdavis.edu Mon Dec 2 08:49:39 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA13058; Mon, 2 Dec 91 08:31:55 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA12865; Mon, 2 Dec 91 08:26:31 -0800 Received: from remora.morningstar.com by volitans.morningstar.com (5.65a/91111501) id AA00771; Mon, 2 Dec 91 11:24:56 -0500 Received: by remora.morningstar.com (5.65a/91072901) id AA06537; Mon, 2 Dec 91 11:24:46 -0500 Date: Mon, 2 Dec 91 11:24:46 -0500 From: Karl Fox Message-Id: <9112021624.AA06537@remora.morningstar.com> To: bsimpson@vela.acs.oakland.edu (Bill Simpson) Cc: MUSSAR@bnr.ca (Gary), ietf-ppp@ucdavis.edu In-Reply-To: <9111292120.AA07858@vela.acs.oakland.edu> Subject: Re: 16/32 bit CRC Negotiation Bill Simpson writes: > There hasn't been a lot of interest in the topic, however. > There doesn't seem to be hardware that requires 32 bit FCS, as yet. Our SnapLink interface can use either 16-bit or 32-bit FCS frames. I got all the appropriate bits coded and tested a number of months ago to use the 48-bit negotiation scheme, but didn't get around to putting them into our PPP product. Now, I don't dare touch it until I find out more about the DEC patent. From ietf-ppp-request@ucdavis.ucdavis.edu Mon Dec 2 10:03:49 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA16467; Mon, 2 Dec 91 09:47:47 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from gateway.bnr.ca by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA15871; Mon, 2 Dec 91 09:36:05 -0800 Received: from BNRECADA.BNR.CA by gateway.bnr.ca (5.61/1.34) id AA12553; Mon, 2 Dec 91 12:34:54 -0500 Message-Id: <9112021734.AA12553@gateway.bnr.ca> Received: from BNRECADA.BNR.CA by BNRECADA.BNR.CA (IBM VM SMTP R1.2.1) with BSMTP id 4072; Mon, 02 Dec 91 12:34:46 EST Date: 2 Dec 91 12:34:00 EST To: Cc: brian@lloyd.com, bsimpson@vela.acs.oakland.edu From: Gary (G.P.) Mussar Subject: re:16/32 bit CRC Negotiation In message "re:16/32 bit CRC Negotiation", you write: >Please put a copy of the software in merit.edu:pub/ppp/incoming. >I'll add it to the 32-bit FCS draft sometime in the next couple of weeks. > >Bill Simpson I've uploaded what I have and called it ppp48.tar.Z. It remains to be seen whether the 48 bit CRC will go anywhere with Dec's patent. BTW, my code (for what ever it is worth) contains a statement that it can be freely used (even in commercial stuff). I would be interested in feedback (good or bad) about improvements or (heaven forbid) bugs. I don't have 32 bit CRC hardware to test on. Gary ------------------------------------------------------------------------------- Gary Mussar |Internet: mussar@bnr.ca | Phone: (613) 763-4937 BNR Ltd. | | FAX: (613) 763-2626 From ietf-ppp-request@ucdavis.ucdavis.edu Mon Dec 2 10:35:38 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA17725; Mon, 2 Dec 91 10:18:03 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from xap.xyplex.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA17244; Mon, 2 Dec 91 10:08:04 -0800 Received: from sgw.xyplex.com by xap.xyplex.com id ; Mon, 2 Dec 91 13:05:21 -0500 Received: by xyplex.com (4.1/SMI-4.1) id AA02881; Mon, 2 Dec 91 13:07:43 EST Date: Mon, 2 Dec 91 13:07:43 EST From: sgw@sgw.xyplex.com (Scott Wasson) Message-Id: <9112021807.AA02881@xyplex.com> To: ietf-ppp@ucdavis.edu Subject: Passive Open Our implementation has no use for Passive Open and I would feel no remorse if it ceased to exist. The only possible purpose of Passive Open is that it wouldn't unnecessarily send Config Req's to the partner if he's not running. But Config Req's now time-out after N retries anyway, so that greatly obviates any reason I can see for having it. - Scott Wasson, Xyplex ----- Begin Included Message ----- From ietf-ppp-request@ucdavis.edu Sat Nov 30 21:24:49 1991 Return-Path: Received: from xap.xyplex.com by xyplex.com (4.1/SMI-4.1) id AA01704; Sat, 30 Nov 91 21:24:48 EST Received: from ucdavis.ucdavis.edu by xap.xyplex.com id ; Sat, 30 Nov 91 21:22:25 -0500 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00432; Sat, 30 Nov 91 17:47:30 -0800 Sender: ietf-ppp-request@ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00247; Sat, 30 Nov 91 17:41:26 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA17875; Sat, 30 Nov 91 19:43:13 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9112010043.AA17875@vela.acs.oakland.edu> Subject: CFV: Passive Open To: ietf-ppp@ucdavis.edu Date: Sat, 30 Nov 91 19:43:12 EST X-Mailer: ELM [version 2.3 PL11] Status: RO There has been a suggestion to eliminate the Passive Open from the FSA. This is a Call for Votes. Please send your vote to the list (unlike NetNews). If your vote is negative, it should include an explanation of why your implementation actually uses the Passive Open. Votes will be tabulated after 19:00 EST (16:00 PST) December 6th, 1991. Technical details: Analysis has shown that with the addition of a specific Up event, there is no longer a need for the Passive Open. If the implementation desires to delay the Active Open, the Up event is delayed instead. For example, if your implementation detects 0x7EFF at the login prompt to switch to PPP mode, the Up event would be sent to the PPP FSA at that time, rather than when carrier was initially detected. In the case where there is no Up event available (ie. because the link is a 3-wire line through a null modem), there will be no harm in sending configuration packets until the restart counter expires, and then listening for the other end (the Opening-Up state). This should be upwardly compatible with previous implementations, since an Active Open will be generated, triggering the Passive Open at the peer. Bill Simpson ----- End Included Message ----- From ietf-ppp-request@ucdavis.ucdavis.edu Mon Dec 2 10:49:38 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18363; Mon, 2 Dec 91 10:31:05 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from EMERALD.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA17779; Mon, 2 Dec 91 10:19:18 -0800 Received: by emerald.acc.com (4.1/SMI-4.1) id AA15015; Mon, 2 Dec 91 10:12:48 PST Date: Mon, 2 Dec 91 10:12:48 PST From: fbaker@acc.com (Fred Baker) Message-Id: <9112021812.AA15015@emerald.acc.com> To: bsimpson@vela.acs.oakland.edu Subject: Re: CFV: Passive Open Cc: ietf-ppp@ucdavis.edu Bill: The justification for Passive Open was for links which were brought up without sending anything at all. I'm not sure I ever bought into it, and your modification, as you note, obviates the requirement if it ever truly existed. My vote: remove passive open. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Mon Dec 2 12:35:27 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA23043; Mon, 2 Dec 91 12:17:40 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from research.att.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA22644; Mon, 2 Dec 91 12:05:58 -0800 Message-Id: <9112022005.AA22644@ucdavis.ucdavis.edu> Received: by inet; Mon Dec 2 15:04 EST 1991 From: smb@ulysses.att.com To: lauck@tl.enet.dec.com Cc: ietf-ppp@ucdavis.edu Subject: Re: 16/32 bit CRC Negotiation Date: Mon, 02 Dec 91 15:04:32 EST I am one of the inventors of the 16/32 negotiation scheme. As I told the working group, it was my intention to get a formal letter out of a Digital Official indicating that it would license the patent for use with PPP on reasonable terms to all implementers. (This is now a specific IAB requriement for constributors and is similar to that used by other organizations such as IEEE and ANSI.) Is that the requirement? I thought that the policy was that proprietary ideas, even if available on ``reasonable'' terms, would not be used if there were other alternatives available. Given the lack of clamor for 16/32, it's hard to see it fitting that model. Has the IAB blessed anything patented except for RSA in the context of privacy-enhanced email? --Steve Bellovin From ietf-ppp-request@ucdavis.ucdavis.edu Mon Dec 2 13:08:14 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA24696; Mon, 2 Dec 91 12:51:51 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from xap.xyplex.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA23856; Mon, 2 Dec 91 12:36:51 -0800 Received: from sgw.xyplex.com by xap.xyplex.com id ; Mon, 2 Dec 91 15:34:07 -0500 Received: by xyplex.com (4.1/SMI-4.1) id AA03227; Mon, 2 Dec 91 15:36:29 EST Date: Mon, 2 Dec 91 15:36:29 EST From: sgw@sgw.xyplex.com (Scott Wasson) Message-Id: <9112022036.AA03227@xyplex.com> To: ietf-ppp@ucdavis.edu Subject: state of flux I disagree. The protocol packet format is currently (and *must* be) backwards-compatible. Including a protocol version would mess that up. The changes being made to the state machine are to make the inner-workings of its operation more apparent without breaking older implementations. A Protocol Version should be unnecessary anyway, since a PPP implementation simply has to REJect any option or protocol-reject any protocol it doesn't recognize as some future enhancement. -Scott Wasson, Xyplex ----- Begin Included Message ----- From ietf-ppp-request@ucdavis.edu Mon Dec 2 15:21:14 1991 Return-Path: Received: from xap.xyplex.com by xyplex.com (4.1/SMI-4.1) id AA03219; Mon, 2 Dec 91 15:21:11 EST Received: from aggie.ucdavis.edu by xap.xyplex.com id ; Mon, 2 Dec 91 15:18:38 -0500 Received: by aggie.ucdavis.edu (5.61/UCD2.03) id AA15960; Mon, 2 Dec 91 11:46:49 -0800 Sender: ietf-ppp-request@ucdavis.edu Received: by aggie.ucdavis.edu (5.61/UCD2.03) id AA15868; Mon, 2 Dec 91 11:44:40 -0800 Message-Id: <9112021944.AA15868@aggie.ucdavis.edu> Date: Mon, 2 Dec 91 10:54:53 PST From: jthomas@na.novell.com (Bill Thomas) To: ietf-ppp-request@ucdavis.edu Subject: state of flux Status: R the need for some form of version number would be nice in terms of this state of flux and future state of fluxes. oh for the final do all end all protocol! ----- End Included Message ----- From ietf-ppp-request@ucdavis.ucdavis.edu Mon Dec 2 13:17:09 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA24986; Mon, 2 Dec 91 12:57:14 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from bridge2.NSD.3Com.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA23900; Mon, 2 Dec 91 12:37:51 -0800 Received: from batura.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA23505 (5.65c/IDA-1.4.4nsd for ); Mon, 2 Dec 1991 12:36:42 -0800 Received: by batura.NSD.3Com.COM id AA17312 (5.65c/IDA-1.4.4-910730 for ietf-ppp@ucdavis.edu); Mon, 2 Dec 1991 12:36:40 -0800 Date: Mon, 2 Dec 1991 12:36:40 -0800 From: "B.V. Jagadeesh" Message-Id: <199112022036.AA17312@batura.NSD.3Com.COM> To: ietf-ppp@ucdavis.edu Subject: Voting for dropping the Passive Open We found no need for Passive Open and hence my vote is Drop Passive Open. /Jagadeesh bvj@3Com.com From ietf-ppp-request@ucdavis.ucdavis.edu Mon Dec 2 13:36:40 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA25271; Mon, 2 Dec 91 13:01:31 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA23970; Mon, 2 Dec 91 12:39:38 -0800 Received: by volitans.morningstar.com (5.65a/91111501) id AA01575; Mon, 2 Dec 91 15:35:39 -0500 Date: Mon, 2 Dec 91 15:35:39 -0500 From: Bob Sutterfield Message-Id: <9112022035.AA01575@volitans.morningstar.com> To: lauck@tl.enet.dec.com Cc: ietf-ppp@ucdavis.edu In-Reply-To: lauck@tl.enet.dec.com's message of Mon, 2 Dec 91 11:12:53 PST <9112021912.AA04234@enet-gw.pa.dec.com> Subject: 16/32 bit CRC Negotiation From: lauck@tl.enet.dec.com Date: Mon, 2 Dec 91 11:12:53 PST [I intended] to get a formal letter out of a Digital Official indicating that it would license the patent for use with PPP on reasonable terms to all implementers. This is exactly the problem with using patented algorithms. What if someone wanted to enter the PPP marketplace, and the terms DEC extended to them turned out to be something they (the new market entry) were unable to accept? What if, years down the road, this WG issued an RFC with SHOULD or MUST next to a feature that is only legally implementable by someone who has satisfied the terms of a patent license agreement? The new player would be barred from entry into a supposedly open, standards-based marketplace. If I remembered enough from my long-ago mathematical education, I might try to build a 16/32-bit FCS negotiation scheme from scratch, and would then donate it to the public domain so that it would be useful to the community. But even that might render me vulnerable to DEC's lawyers, since I have read Arthur Harvey's draft RFC, and they might claim that I used ideas from that document. Apparently the IAB and IEEE and ANSI think they have good reasons for going along with this sort of foolishness. I think it's unfortunate. Software patents are a quagmire into which we too willingly fall, and from which it's terribly difficult to struggle back to the air. From ietf-ppp-request@ucdavis.ucdavis.edu Mon Dec 2 15:28:10 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA29886; Mon, 2 Dec 91 14:51:00 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ALLSPICE.LCS.MIT.EDU by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA29469; Mon, 2 Dec 91 14:40:06 -0800 Received: by PTT.LCS.MIT.EDU id AA28529; Mon, 2 Dec 91 17:37:26 EST Date: Mon, 2 Dec 91 17:37:26 EST From: jnc@PTT.LCS.MIT.EDU (Noel Chiappa) Message-Id: <9112022237.AA28529@PTT.LCS.MIT.EDU> To: bob@morningstar.com, ietf-ppp@ucdavis.edu Subject: Re: 16/32 bit CRC Negotiation Cc: jnc@PTT.LCS.MIT.EDU Whether you've read the draft RFC or not is irrelevant when it comes to patents. I'm not sure what's in the patent, but if it is drawn broadly enough it could cover anything you come up with in terms of dual length checksums, even if it is original work. I think we all realize this is a problem, but I think experience has shown that standards bodies can use patented concepts if they are careful to nail down the (reasonable) terms under which the patent will be made available. (I think Ethernet is covered under patents which are licensable in this manner, no?) Also, realize that often times the reason a large company patents something is not to keep others out, but to make sure *they* can't be kept out, which is why they are often happy to license them for fairly nominal amounts, and why you see so much mass cross-licensing. Finally, you can still be screwed by a patent even if the spec does not knowingly use one. If I have a patent in process for X (and they can be in the pipe for years), some IETF WG which doesn't know about it could come along and standardize something which conflicts with the application, and 3 years later, after everyone has implemented it and is busy depending on it, the patent could issue. Bang, you're screwed. There is no 100% sure way to win; even if you patent whatever is patentable in each IETF PS (which will take years and mega-$$$), there's still no guarantee that you patent was not issued as an enhancement to a prior patent. You just can't guarantee that there's no conflict. Again, none of this is to say that we don't have to be very careful about making sure that the terms of any license to a patent are nailed down. However, it's premature to turn something down just because there's a patent somewhere. Noel From ietf-ppp-request@ucdavis.ucdavis.edu Mon Dec 2 16:00:45 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA01546; Mon, 2 Dec 91 15:31:29 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA01172; Mon, 2 Dec 91 15:22:41 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA07320; Mon, 2 Dec 91 18:21:27 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9112022321.AA07320@vela.acs.oakland.edu> Subject: Re: CFV: Passive Open To: jnc@ALLSPICE.LCS.MIT.EDU (Noel Chiappa) Date: Mon, 2 Dec 91 18:21:26 EST Cc: ietf-ppp@ucdavis.edu In-Reply-To: <9112021626.AA26039@PTT.LCS.MIT.EDU>; from "Noel Chiappa" at Dec 2, 91 11:26 am X-Mailer: ELM [version 2.3 PL11] We have been talking about improving participantion via mailing list as opposed to everyone having to show up at the IETF meetings to vote. This was a short experiment in mailing list participation. Bill Simpson > > Ah, your restatement makes things much clearer (and, as I said, even > if you guys wanted to vote, you could :-). I just thought I detected some > creeping formalisms.... > > Noel > From ietf-ppp-request@ucdavis.ucdavis.edu Mon Dec 2 16:17:26 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA01677; Mon, 2 Dec 91 15:36:31 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA01251; Mon, 2 Dec 91 15:24:49 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA07423; Mon, 2 Dec 91 18:23:30 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9112022323.AA07423@vela.acs.oakland.edu> Subject: re:16/32 bit CRC Negotiation To: MUSSAR@bnr.ca (Gary) Date: Mon, 2 Dec 91 18:23:30 EST Cc: ietf-ppp@ucdavis.edu In-Reply-To: <9112021734.AA12553@gateway.bnr.ca>; from "Gary" at Dec 2, 91 12:34 pm X-Mailer: ELM [version 2.3 PL11] Thanks, I'll look at it. I doubt any patents would be valid, as there is considerable prior art (someone else sent me a list of previous publication, which I'll have to go find). Bill From ietf-ppp-request@ucdavis.ucdavis.edu Mon Dec 2 18:21:43 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA05919; Mon, 2 Dec 91 18:01:09 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ALLSPICE.LCS.MIT.EDU by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA05767; Mon, 2 Dec 91 17:59:05 -0800 Received: by PTT.LCS.MIT.EDU id AA29387; Mon, 2 Dec 91 20:57:51 EST Date: Mon, 2 Dec 91 20:57:51 EST From: jnc@PTT.LCS.MIT.EDU (Noel Chiappa) Message-Id: <9112030157.AA29387@PTT.LCS.MIT.EDU> To: bsimpson@vela.acs.oakland.edu, ietf-ppp@ucdavis.edu Subject: re:16/32 bit CRC Negotiation Cc: jnc@PTT.LCS.MIT.EDU All patents are valid until proven otherwise via a court case; i.e. you can't go to the patent office and say 'look, prior art on a patent you issued, please fix'. Note that these cases can be extensive. In fact, so expensive that often people with good cases will not bother to fight them out. Case in point (and especially relevant to us) is the Soderblum patent on token rings. Turns out he rescoped his patent after he looked at what Proteon was doing, to include stuff they had been selling for years, and which wasn't covered under his old patent. Proteon decided to sign up for a license anyway, even thought hey had great grounds to fight it on. This patent is another illustration of what I said in a previous message; a patent can show up out of the woodwork with no warning which applies to something a standards group does. Doesn't matter that the standards group did their work independantly..... they lose. Noel From ietf-ppp-request@ucdavis.ucdavis.edu Mon Dec 2 22:51:05 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA12651; Mon, 2 Dec 91 22:30:40 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.124.48.2] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA12359; Mon, 2 Dec 91 22:18:40 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA00428; Mon, 2 Dec 91 22:17:12 PST Date: Mon, 2 Dec 91 22:17:12 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9112030617.AA00428@ray.lloyd.com> To: jnc@PTT.LCS.MIT.EDU Cc: ietf-ppp@ucdavis.edu, jnc@PTT.LCS.MIT.EDU In-Reply-To: Noel Chiappa's message of Mon, 2 Dec 91 11:26:14 EST <9112021626.AA26039@PTT.LCS.MIT.EDU> Subject: CFV: Passive Open Ha! Us? Formal? I repeat *HA* 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 Dec 2 23:01:15 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA12755; Mon, 2 Dec 91 22:41:09 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.124.48.2] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA12503; Mon, 2 Dec 91 22:27:07 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA00447; Mon, 2 Dec 91 22:24:19 PST Date: Mon, 2 Dec 91 22:24:19 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9112030624.AA00447@ray.lloyd.com> To: lauck@tl.enet.dec.com Cc: "karl@morningstar.com"@us1rmc.enet.dec.com, lauck@tl.enet.dec.com, ietf-ppp@ucdavis.edu In-Reply-To: lauck@tl.enet.dec.com's message of Mon, 2 Dec 91 11:12:53 PST <9112021912.AA04234@enet-gw.pa.dec.com> Subject: 16/32 bit CRC Negotiation I am the PPP working group chaircritter. Please send a copy of the letter, should you wrangle it out of your legal department, to my address below. 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 Mon Dec 2 23:17:19 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA12884; Mon, 2 Dec 91 22:45:28 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.124.48.2] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA12653; Mon, 2 Dec 91 22:30:53 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA00450; Mon, 2 Dec 91 22:28:15 PST Date: Mon, 2 Dec 91 22:28:15 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9112030628.AA00450@ray.lloyd.com> To: jthomas@na.novell.com Cc: ietf-ppp@ucdavis.edu In-Reply-To: Bill Thomas's message of Mon, 2 Dec 91 10:54:53 PST <9112021944.AA15868@aggie.ucdavis.edu> Subject: state of flux Bill, The changes that we have wrought are backward compatible with the exception to the change to IPCP address negotiation and the new LQM stuff. Since these are options and the old options are not being retired, this should cause no backward compatibility problems. This eliminates the need for a version number in the protocol. If an implementation tries to negotiate options that you don't support in your implementation, simply REJect them and go on. Ah, the [sometimes faded] beauty of PPP. :-) 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 Dec 3 11:37:04 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA29894; Tue, 3 Dec 91 11:17:00 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA29450; Tue, 3 Dec 91 11:05:02 -0800 Received: by aggie.ucdavis.edu (5.61/UCD2.03) id AA06675; Tue, 3 Dec 91 10:51:10 -0800 Date: Tue, 3 Dec 91 10:51:10 -0800 Message-Id: <9112031851.AA06675@aggie.ucdavis.edu> From: jthomas@na.novell.com (Bill Thomas) To: ietf-ppp-request@ucdavis.ucdavis.edu Subject: KEEP PO & PLEASE KEEP SIMPSON's DRAFT & PUBLIC CODE We are in the final stages of a multi protocol PPP with call support. We are using PO (LISTEN). It seems so right and it works. Please Please keep PO! AO lasts only through a connection (MakeCall). PO lasts until cancelled (CancelledListen). A Listen (PO) for a given Protocol enables all attached circuits to accept incomming traffic for that NCP and Protocol. The act of MakeCall or Listen registers that protocol with PPP. Our code is based on the DRAFT and Wm Simpson's code. It seems so right and it works. Please Please keep it! I think you can understand what the FLUX is doing to PPP at NOVELL. There are other stable protocols which are now being discussed here instead of PPP. Could not just a few words make clear any ambiguity (rather than tossing out any prior PPP implementations)? Simpson's code is easy to understand and cleared up any ambiguity I had with the RFC & DRAFT. From ietf-ppp-request@ucdavis.ucdavis.edu Wed Dec 4 01:31:42 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA22014; Wed, 4 Dec 91 01:15:09 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from enet-gw.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA21772; Wed, 4 Dec 91 01:00:55 -0800 Received: by enet-gw.pa.dec.com; id AA03883; Wed, 4 Dec 91 00:59:12 -0800 Message-Id: <9112040859.AA03883@enet-gw.pa.dec.com> Received: from marvin.enet; by decwrl.enet; Wed, 4 Dec 91 00:59:24 PST Date: Wed, 4 Dec 91 00:59:24 PST From: SEMPER INFACEBO SUMUS - SOLE PROFUNDUM VARIAT 04-Dec-1991 0858 To: bsimpson@vela.acs.oakland.edu, ietf-ppp@ucdavis.edu Apparently-To: ietf-ppp@ucdavis.edu, bsimpson@vela.acs.oakland.edu Subject: Omitting Passive Opens or "PPP made simple". We have now had a vote in favour of Passive Opens, so we may have to keep them. As far as I can see, the Passive Open is a purely local event and omitting them will not adversely affect interoperability. (I reckon that *INCLUDING* them adversely affects interoperability, but not omitting them). Thus I feel the inclusion of Passive Opens can be left as an implementation decision. The question now arises, do we need a seperate, (Oh my God - Not another one), FSA for PPP without Passive Opens, or is it up to implementors to work it out for themselves? If you would like a seperate table, Bill, I don't mind having a stab at it myself. (Anyone not implementing Passive Opens is going to have to work it out anyway). Dean Morris - DEC Corporate Backbone Networks Group, Reading. From ietf-ppp-request@ucdavis.ucdavis.edu Wed Dec 4 08:32:34 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00747; Wed, 4 Dec 91 08:17:08 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00198; Wed, 4 Dec 91 08:01:04 -0800 Received: by aggie.ucdavis.edu (5.61/UCD2.03) id AA24701; Wed, 4 Dec 91 07:56:01 -0800 Date: Wed, 4 Dec 91 07:56:01 -0800 Message-Id: <9112041556.AA24701@aggie.ucdavis.edu> From: brian@lloyd.com (Brian Lloyd) To: ietf-ppp@ucdavis.ucdavis.edu Subject: KEEP PO & PLEASE KEEP SIMPSON's DRAFT & PUBLIC CODE Bill, consider also that there are MANY hours of experience with PPP at this point and that all the other implementors have agreed that PO is not very useful. Therefore it makes sense to remove the PO and the associated states and state changes. This simplifies the life of the implementor considerably. There is nothing preventing you from having the equivalent of passive open in your implementation. You can consider it your very own enhancement to PPP. The key is that having a passive open does not make you non-interoperable. The rest of us will simply simplify our code and still have complete implementations. 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 Dec 4 12:08:35 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA06333; Wed, 4 Dec 91 11:33:24 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.80.57.1] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA05944; Wed, 4 Dec 91 11:21:52 -0800 Received: by Shiva.COM (1.34b) Wed, 4 Dec 91 14:20:07 EST Date: Wed, 4 Dec 91 14:20:07 EST From: Marty Del Vecchio Message-Id: <9112041920.AA07546@Shiva.COM> To: ietf-ppp@ucdavis.edu Subject: Connection Establishment At the IETF meeting in Santa Fe, Brian Lloyd talked about establishing connections (such as phone lines). The conclusion was that a PPP originator identified itself solely by sending PPP packets. At Shiva, the originator has always sent a specific character repeatedly until it got a specific character in return, and then both sides started PPP. At the meeting, I was convinced that this was redundant--the PPP frame identifies the originator, and a PPP response finishes the identification. However, there is another purpose of our character handshake that I had forgotten about--for auto-bauding. For PPP host devices that depend on an external modem, there can be no guarantee that the host will be able to identify the connect BPS rate based solely on the modem's connect message. So the repeated character transmission allows the host to change its BPS rate until it gets a correctly-framed specific character, and it knows it is at the correct BPS rate. In other words, it sounds like we have a problem with the "PPP-only" edict. From ietf-ppp-request@ucdavis.ucdavis.edu Wed Dec 4 12:54:28 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA07712; Wed, 4 Dec 91 12:16:15 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from enet-gw.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA07491; Wed, 4 Dec 91 12:10:21 -0800 Received: by enet-gw.pa.dec.com; id AA07584; Wed, 4 Dec 91 12:06:43 -0800 From: lauck@tl.enet.dec.com Message-Id: <9112042006.AA07584@enet-gw.pa.dec.com> Received: from tl.enet; by decwrl.enet; Wed, 4 Dec 91 12:07:20 PST Date: Wed, 4 Dec 91 12:07:20 PST To: emv@ox.com Cc: lauck@tl.enet.dec.com, gunner@osicwg.enet.dec.com, shand@shand.enet.dec.com, ietf-ppp@ucdavis.edu Apparently-To: ietf-ppp@ucdavis.edu, emv@ox.com Subject: re: 16/32 bit CRC Negotiation Our patent on the 16/32 bit CRC is currently pending, and therefore has no number as of yet. It will probably take several years for it to issue. If you have any technical questions regarding the method, or comments or revisions to Art Harvey's internet draft (DRAFT-IETF-PPP-32BITCONFIG-01.TXT), please let me know. Tony From ietf-ppp-request@ucdavis.ucdavis.edu Wed Dec 4 13:13:20 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA08277; Wed, 4 Dec 91 12:33:28 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from gamma.biostats.hmc.psu.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA07907; Wed, 4 Dec 91 12:23:57 -0800 Return-Path: Received: by gamma.biostats.hmc.psu.edu (4.1/1.34) id AA04547; Wed, 4 Dec 91 15:22:43 EST Date: Wed, 4 Dec 91 15:22:43 EST From: jkaylor@biostats.hmc.psu.edu (James L. Kaylor) Message-Id: <9112042022.AA04547@gamma.biostats.hmc.psu.edu> To: ietf-ppp@ucdavis.edu Subject: X-windows over PPP Your help is requested!! I would like to run X-windows over dial-up lines. My host (X-client) platforms will be Sun SparcStations for this initial configuration. My X-server platforms with be 386-sized DOS platforms and Apple Macs. I will also be considering X-terminals as this project gets rolling. At the moment, I plan to run 9600 baud modems with at least V.32bis/V.42bis to achieve a minimum effective 38,400bps (hopefully 57,600bps) so the interface is useable. At this point, I am open to _all_ suggestions for this type of configuration. DOS X-servers, Macs X-servers, TCP/IP, SLIP, PPP,..etc. ### PPP ### Are there any sites running X over PPP?? My questions are general at this time. What software (preferably public domain, but this is not a requirement) is available? What software works well together? Where can I retrieve those products? What experiences have you had installing those products? Please e-mail directly to jkaylor@biostats.hmc.psu.edu Thank you. +~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+ James Kaylor ~ Network Support Specialist ! NET: jkaylor@biostats.hmc.psu.edu Center for Biostatistics and Epidemiology ! BELL: 717/531-7178 College of Medicine ~ Penn State ! FAX: 717/531-5779 The Milton S. Hershey Medical Center ! P.O.Box 850; Hershey, PA. 17033 ! +~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+ ----- End Included Message ----- From ietf-ppp-request@ucdavis.ucdavis.edu Wed Dec 4 14:04:46 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10408; Wed, 4 Dec 91 13:46:40 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10062; Wed, 4 Dec 91 13:32:22 -0800 Received: by volitans.morningstar.com (5.65a/91111501) id AA09516; Wed, 4 Dec 91 16:30:05 -0500 Date: Wed, 4 Dec 91 16:30:05 -0500 From: Bob Sutterfield Message-Id: <9112042130.AA09516@volitans.morningstar.com> To: marty@Shiva.COM Cc: ietf-ppp@ucdavis.edu In-Reply-To: Marty Del Vecchio's message of Wed, 4 Dec 91 14:20:07 EST <9112041920.AA07546@Shiva.COM> Subject: Connection Establishment Date: Wed, 4 Dec 91 14:20:07 EST From: Marty Del Vecchio At the IETF meeting in Santa Fe, Brian Lloyd talked about establishing connections (such as phone lines). The conclusion was that a PPP originator identified itself solely by sending PPP packets. Could someone please elaborate on this, for someone who wasn't there for the discussion? When originating a connection, our PPP can be configured to AO when CD comes up, but the normal way is to use a chat script to get through a login/password exchange. Then, the answering system starts up a PPP process, usually as a "login shell", that will be ready to hear the AO. Must we distribute a hacked getty(8) that that will recognize 0x7eff and arrange to start a PPP process? Or we could put pppd(8) into the ttytab entry, but that would render the port unusable by interactive users, UUCP, etc. For PPP host devices that depend on an external modem, there can be no guarantee that the host will be able to identify the connect BPS rate based solely on the modem's connect message. This isn't a problem for us, since init(8) and getty(8) take care of that sort of stuff before handing the line to pppd(8). From ietf-ppp-request@ucdavis.ucdavis.edu Wed Dec 4 14:51:54 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA11465; Wed, 4 Dec 91 14:17:14 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from EMERALD.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10989; Wed, 4 Dec 91 14:04:48 -0800 Received: by emerald.acc.com (4.1/SMI-4.1) id AA04259; Wed, 4 Dec 91 13:58:45 PST Date: Wed, 4 Dec 91 13:58:45 PST From: fbaker@acc.com (Fred Baker) Message-Id: <9112042158.AA04259@emerald.acc.com> To: marty@Shiva.COM Subject: Re: Connection Establishment Cc: ietf-ppp@ucdavis.edu >> The conclusion was that a PPP originator identified itself solely by >> sending PPP packets. I thought that this was in the specia; case where the fellow only implemented PPP; in a more general system, we used an ISO 8885 XID exchange? That's certainly what IPLPDN walked away with. It seems that autobaud is solvable using XID... Fred From ietf-ppp-request@ucdavis.ucdavis.edu Wed Dec 4 15:41:02 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA12899; Wed, 4 Dec 91 15:08:24 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from mathom.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA12594; Wed, 4 Dec 91 14:57:17 -0800 Date: Wed 4 Dec 91 14:54:04-PST From: William "Chops" Westfield Subject: Re: X-windows over PPP To: jkaylor@biostats.hmc.psu.edu Cc: ietf-ppp@ucdavis.edu In-Reply-To: <9112042022.AA04547@gamma.biostats.hmc.psu.edu> Message-Id: <12738875678.20.BILLW@mathom.cisco.com> You should run NCD's Xremote protocol. It's about 10 times faster than "slip", and is inherently faster than any scheme based on IP. Xremote does its own compression, so v.42 bis/etc is not useful. Xremote essentially elminates the overhead of X for typical applications: "cat /etc/termcap" to an X window via Xremote will complete in about the same time as it would to a dumb terminal. Graphics will be somewhat more painful. Text windows are quite pleasant with a plain v.32 modem, and usable at even lower speeds. NCD is pushing Xremote along a standards track, and Xremote support is currentlt shipping in cisco terminal servers, and has been announced by Xyplex for their terminal servers too. Bill Westfield cisco Systems. ------- From ietf-ppp-request@ucdavis.ucdavis.edu Wed Dec 4 19:51:54 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA21100; Wed, 4 Dec 91 19:31:16 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA20743; Wed, 4 Dec 91 19:22:03 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA09959; Wed, 4 Dec 91 22:20:39 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9112050320.AA09959@vela.acs.oakland.edu> Subject: Re: Omitting Passive Opens or "PPP made simple". To: morris@marvin.enet.dec.com (SEMPER INFACEBO SUMUS - SOLE PROFUNDUM VARIAT 04-Dec-1991 0858) Date: Wed, 4 Dec 91 22:20:37 EST Cc: ietf-ppp@ucdavis.edu In-Reply-To: <9112040859.AA03883@enet-gw.pa.dec.com>; from "SEMPER INFACEBO SUMUS - SOLE PROFUNDUM VARIAT 04-Dec-1991 0858" at Dec 4, 91 12:59 am X-Mailer: ELM [version 2.3 PL11] > > > We have now had a vote in favour of Passive Opens, so we may have to keep > them. As far as I can see, the Passive Open is a purely local event and omitting > them will not adversely affect interoperability. (I reckon that *INCLUDING* them > adversely affects interoperability, but not omitting them). Thus I feel the > inclusion of Passive Opens can be left as an implementation decision. The No, we have one implementor out of dozens who wants to keep Passive Open because he's almost done implementing. No solid technical reasons were given. So far, no one has given a good *reason* to keep it. > question now arises, do we need a seperate, (Oh my God - Not another one), FSA > for PPP without Passive Opens, or is it up to implementors to work it out for > themselves? If you would like a seperate table, Bill, I don't mind having a > stab at it myself. (Anyone not implementing Passive Opens is going to have to > work it out anyway). > > Dean Morris - DEC Corporate Backbone Networks Group, Reading. > We can only have a single table. The PPP MIB (you've all read it, right?) has fields for the current state number, which will need to be consistent across implementations. I've already started the No Passive Open FSA (thanks anyway). I will post it Sunday or Monday, along with the hundreds of other minor language changes to the Draft to support it. Fortunately, most of the changes are deletions, this time around. On Wednesday, Glenn McGregor will post his IPCP Draft, and on Friday, I will post the PAP&CHAP Draft. There will be an additional 2 week comment period. Then they will be made RFCs (according to the IESG guidelines), and we will all take a break for Holidays (hooray)! Bill Simpson From ietf-ppp-request@ucdavis.ucdavis.edu Wed Dec 4 20:07:06 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA21437; Wed, 4 Dec 91 19:45:35 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA21248; Wed, 4 Dec 91 19:36:33 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA10791; Wed, 4 Dec 91 22:35:05 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9112050335.AA10791@vela.acs.oakland.edu> Subject: Re: Connection Establishment To: marty@shiva.com (Marty Del Vecchio) Date: Wed, 4 Dec 91 22:35:02 EST Cc: ietf-ppp@ucdavis.edu In-Reply-To: <9112041920.AA07546@Shiva.COM>; from "Marty Del Vecchio" at Dec 4, 91 2:20 pm X-Mailer: ELM [version 2.3 PL11] > In other words, it sounds like we have a problem with the "PPP-only" edict. > > There was no edict. There are many ways of link establishment. When the speed is known, it is possible to automatically detect PPP by the 7eff frame header. I suspect that you will have some problems with your mechanism, however. The one that I like best, so far, for auto-speed detection is the simple "hit a CR until the prompt you want shows up". This works for both dumb terminal users and scripts. On your end, you could still auto-detect with any arbitrary character, by simply changing speeds when you see framing errors. In this way, both PPP frame and CR sensing work correctly. Bill Simpson From ietf-ppp-request@ucdavis.ucdavis.edu Wed Dec 4 20:18:01 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA21833; Wed, 4 Dec 91 20:01:53 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA21744; Wed, 4 Dec 91 19:59:19 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA12065; Wed, 4 Dec 91 22:57:54 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9112050357.AA12065@vela.acs.oakland.edu> Subject: Re: SLIP vs. PPP To: davek@clesun.central.sun.com (Dave Kalb Sun Cleveland SE) Date: Wed, 4 Dec 91 22:57:53 EST Cc: ietf-ppp@ucdavis.edu In-Reply-To: <9112042232.AA18730@clesun.Central.Sun.COM>; from "Dave Kalb Sun Cleveland SE" at Dec 4, 91 5:32 pm X-Mailer: ELM [version 2.3 PL11] > > Bill, > > I am a systems engineer with Sun Microsystems. I got your name off the PPP > RFC Draft. I have a customer who wants to use SLIP and I'm pretty sure > that PPP is a better solution. But, I don't have enough good hard reasons > to convince him. Would you be able to help me out??? Or can you point me > to a white paper that discusses this? > > Any assistance would be greatly appreciated. > > Regards, > > David Kalb > Sun Microsystems, Inc. > Cleveland, Ohio > I just did such a talk at Telebit, so I'm primed.... First of all, it's easier to configure. It has all these fancy options, but you don't actually have to worry about them. The implementor picked reasonable defaults. Each end tells the other what it can do, and then they settle down and start talking. In SLIP, you have to set up the MTU for both ends to match, set up the VJ header compression (if you even know what it is), set up the addresses, set up the routing, etc.... Second of all, the packet is checksummed, so that if it's bad, it gets thrown away right away, and you get all these lovely counters that tell you whether your lines are any good. Thirdly, you can send many kinds of packets over the line, not just IP. It doesn't matter to you today, but it will when you want your Macs on the net, when you want to remotely talk to your Netware applications, etc, etc. Finally, remember those fancy options? They allow you to fix things that you can't handle with SLIP, like characters that can't go through your modem. They even allow you to detect when your line is down, or looped back, so that you can auto-magically redial. Bill Simpson From ietf-ppp-request@ucdavis.ucdavis.edu Wed Dec 4 22:01:45 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA24601; Wed, 4 Dec 91 21:46:01 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.124.48.2] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA24481; Wed, 4 Dec 91 21:42:12 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA01612; Wed, 4 Dec 91 21:39:48 PST Date: Wed, 4 Dec 91 21:39:48 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9112050539.AA01612@ray.lloyd.com> To: marty@Shiva.COM Cc: ietf-ppp@ucdavis.edu In-Reply-To: Marty Del Vecchio's message of Wed, 4 Dec 91 14:20:07 EST <9112041920.AA07546@Shiva.COM> Subject: Connection Establishment Virtually all modems offer a means to lock the interface speed so that the modem performs all speed conversion. This eliminates the need for an autobaud routine. 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 Dec 4 22:31:23 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA25233; Wed, 4 Dec 91 22:15:42 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.124.48.2] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA24952; Wed, 4 Dec 91 22:01:38 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA01629; Wed, 4 Dec 91 21:59:07 PST Date: Wed, 4 Dec 91 21:59:07 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9112050559.AA01629@ray.lloyd.com> To: jkaylor@biostats.hmc.psu.edu Cc: ietf-ppp@ucdavis.edu In-Reply-To: James L. Kaylor's message of Wed, 4 Dec 91 15:22:43 EST <9112042022.AA04547@gamma.biostats.hmc.psu.edu> Subject: X-windows over PPP NCD is pushing X-remote. It is a good protocol and seems to eke the best performance out of a slow serial link. The problem with X is that it tends to send many small packets. This gets expensive when you add the 40 octets of IP and TCP header to each small packet. I have not experimented personally but I suspect that SLIP or PPP running with VJ header compression combined with V.42bis modems might perform reasonably well but probably not quite as well as X-remote. 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 Dec 5 00:16:41 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA27643; Thu, 5 Dec 91 00:01:10 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SGI.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA27415; Wed, 4 Dec 91 23:53:11 -0800 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (911016.SGI/910110.SGI) for ietf-ppp@ucdavis.edu id AA23932; Wed, 4 Dec 91 23:51:57 -0800 Received: by rhyolite.wpd.sgi.com (911016.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@ucdavis.edu id AA22638; Wed, 4 Dec 91 23:51:55 -0800 Date: Wed, 4 Dec 91 23:51:55 -0800 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9112050751.AA22638@rhyolite.wpd.sgi.com> To: bsimpson@vela.acs.oakland.edu Cc: ietf-ppp@ucdavis.edu Subject: Re: SLIP vs. PPP > > I have a customer who wants to use SLIP and I'm pretty sure > > that PPP is a better solution..... > > I just did such a talk at Telebit, so I'm primed.... > > First of all, it's easier to configure. It has all these fancy options, > but you don't actually have to worry about them. The implementor > picked reasonable defaults. Each end tells the other what it can do, > and then they settle down and start talking. Ok, reasonable implementations work well, like many things including SLIP. > In SLIP, you have to set up the MTU for both ends to match, set up > the VJ header compression (if you even know what it is), set up the > addresses, set up the routing, etc.... This is mostly wrong. Reasonable SLIP implementations work regardless of the other end's MTU, just like PPP. If you run the auto-compression- detection code in the 4.3BSD VJ header compression code, compression is as automatic in SLIP as in PPP. I don't like that hack, and so perhaps that part of this comparison is right in spirit if wrong in fact. The link layer has trouble fixing routing problems. You must worry equally about routing whether you use SLIP or PPP. In some circumstances, not at all. A lot in others. I know of one commercial SLIP implementation where if you'll tolerate the default use of RIP, you need not worry at all. You must worry about addressing equally with SLIP and PPP. Automatic address assignment doesn't contact the NIC for a network. It doesn't allocate a chunk of your class-B for pt-to-pt connections. It may allow "roving", but that's not what "set up the address" means to most people. Claims for no-brain PPP routing and addressing are surprising if you read comp.protocols.ppp. > Second of all, the packet is checksummed, so that if it's bad, > it gets thrown away right away, and you get all these lovely > counters that tell you whether your lines are any good. All TCP/IP packets are already checksummed. All UDP/IP packets from responsible computer vendors are already checksummed. Packets with bad checksums are immediately discarded by TCP/IP (plus or minus a few msec of ethernet forwarding). PPP link level checksums are nice, but not compelling. Counters are nice, if your TCP stack doesn't already have bad checksum counters, and so is incompatible with SNMP. > Thirdly, you can send many kinds of packets over the line, not just IP. > It doesn't matter to you today, but it will when you want your Macs > on the net, when you want to remotely talk to your Netware applications, > etc, etc. A clear advantage of PPP. > Finally, remember those fancy options? They allow you to fix things > that you can't handle with SLIP, like characters that can't go through > your modem. They even allow you to detect when your line is down, > or looped back, so that you can auto-magically redial. I know of a commerical SLIP implementation which does this. There are many such UUCP implementations with this, and it is easy to steal it from UUCP and graft into your SLIP code. Over selling things makes them look bad. There is one solid reason to like PPP over SLIP in the preceding, the non-IP packet forwarding, but I suspect it is not universally implemented. I think there are other, unlisted advantages of PPP, but PPP is not perfect--it's already been over-perfected. Vernon Schryver, vjs@sgi.com P.S. I hope my sarcasm detecter is ok. I just realized that the list of PPP advantages could have been tongue-in-cheek. From ietf-ppp-request@ucdavis.ucdavis.edu Thu Dec 5 07:47:44 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA08627; Thu, 5 Dec 91 07:31:49 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA08446; Thu, 5 Dec 91 07:26:14 -0800 Received: from roughy.morningstar.com by volitans.morningstar.com (5.65a/91111501) id AA11781; Thu, 5 Dec 91 10:24:36 -0500 Received: by roughy.morningstar.com (5.65a/910712902) id AA01450; Thu, 5 Dec 91 10:22:04 -0500 Date: Thu, 5 Dec 91 10:22:04 -0500 From: Bob Sutterfield Message-Id: <9112051522.AA01450@roughy.morningstar.com> To: vjs@sgi.com Cc: bsimpson@vela.acs.oakland.edu, ietf-ppp@ucdavis.edu In-Reply-To: Vernon Schryver's message of Wed, 4 Dec 91 23:51:55 -0800 <9112050751.AA22638@rhyolite.wpd.sgi.com> Subject: SLIP vs. PPP Date: Wed, 4 Dec 91 23:51:55 -0800 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) > First of all, [PPP]'s easier to configure. Ok, reasonable implementations work well, like many things including SLIP. And there are lots of unreasonable SLIP implementations out there. The problem is that SLIP is so loosely specified, and many of the techniques you describe are the result of recent work, having learned from RFC-1055's deficiencies and ambiguities. But something can call itself SLIP and still lack many of the useful features you describe. Those lackings must be compensated for by personal communication between the administrators of each end of the link, outside the protocol. A PPP can omit features and still call itself PPP, and the peer can discover its lackings in the process of negotiations. When we tested our PPP against cisco's router last summer, cisco declined almost all the options we proposed, but the link came up to pass IP packets on the first try. When we tested against Brixton's async PPP we hadn't yet implemented PAP or CHAP, and they hadn't implemented VJ, but the link came up on the first try anyway. > In SLIP, you have to set up the MTU for both ends to match, Reasonable SLIP implementations work regardless of the other end's MTU, just like PPP. Some SLIP implementations out there cannot accomodate MTUs they weren't expecting. When talking to ISC UNIX's SLIP, we need to explicitly crank our MTU down to 576 because they aren't liberal enough in what they accept. > set up the VJ header compression (if you even know what it is), If you run the auto-compression- detection code in the 4.3BSD VJ header compression code, compression is as automatic in SLIP as in PPP. I don't like that hack, and so perhaps that part of this comparison is right in spirit if wrong in fact. Some SLIP implementations out there don't know anything about VJ, they'll just pass the packet up to IP where it (best case) gets pitched. (In the worst case, it will splash your kernel with an "mclput panic".) And some of those that know about VJ don't know about the auto-detection hack. The peer can't count on anything, so the configuration discovery must be done outside the protocol. > set up the routing, etc.... The link layer has trouble fixing routing problems. You must worry equally about routing whether you use SLIP or PPP. True. > set up the addresses, You must worry about addressing equally with SLIP and PPP. Automatic address assignment doesn't contact the NIC for a network. But once you have a chunk of the address space, PPP allows it to be allocated more easily. There are schemes that allow a remote host to discover its address when talking to SLIP, but those are outside SLIP itself. For example, one terminal server reportedly prints your assigned address after you type "slip" at it, but before sending any packets. Incoming implementations are supposed to watch for that string and make intelligent use of it. It doesn't allocate a chunk of your class-B for pt-to-pt connections. We don't burn an address, or a pair of addresses, for each link, whether we're using SLIP or PPP. You're welcome to if you like, but we generally don't. It may allow "roving", but that's not what "set up the address" means to most people. I don't think "most people" expect their software to contact the NIC. I think they are more realistic than that, and only expect the software to implement what it can. Yes, contacting the NIC is outside the protocol, but everyone has to do it someday anyway. Claims for no-brain PPP routing and addressing are surprising if you read comp.protocols.ppp. The great majority of our customers' problems are related to modem configurations, not addressing and routing. > Second of all, the packet is checksummed, so that if it's bad, > it gets thrown away right away, All TCP/IP packets are already checksummed. In our implementation, it costs a trip from the daemon into the kernel to pass a (group of) packet(s) up to IP. If a bad packet can be discovered earlier, the expense of that write() can be saved. All UDP/IP packets from responsible computer vendors are already checksummed. But we can all name "less responsible" vendors whose machines are in very common use, can't we? Users become cranky and disagreeable when we must instruct them to change too many things on their system, because they perceive us as inflexible and unable to work with things as they are shipped from the vendor. Packets with bad checksums are immediately discarded by TCP/IP (plus or minus a few msec of ethernet forwarding). PPP link level checksums are nice, but not compelling. One vendor's most recently-shipped version of the kernel will croak (the infamous "mclput panic") if handed a packet that's malformed in certain ways. Those packets are particularly prone to arrive at link shutdown time, before the SLIP implementation knows that it's supposed to be shutting down. We fixed our SLIP to watch for unreasonable packets before passing them up to IP, just as a workaround for our customers who haven't yet installed the widely-available kernel patch. But again, this is outside the purvey of the SLIP spec, and there's no discussion in the RFC of ways to accomplish this, so each SLIP vendor may or may not do it, and still call themselves SLIP. The PPP FSA renders it immune to these particular sorts of link shutdown-time difficulties, and the PPP FCS protects each packet before we even think of passing it up to IP. > and you get all these lovely counters that tell you whether your > lines are any good. Counters are nice, if your TCP stack doesn't already have bad checksum counters, and so is incompatible with SNMP. Sometimes it's helpful to be able to separate link problems from malformed TCP packets that originated on the peer. And ICMP and UDP and other protocol families may not have nice checksum counters built in. > Thirdly, you can send many kinds of packets over the line, not > just IP. A clear advantage of PPP. It's a slight functional advantage, depending upon your needs, and a substantial performance advantage. Most non-IP protocol families are regularly encapsulated within IP packets, for transmission across an IP internet. Either SLIP or PPP will handle this equally well, though encapsulation hits your performance. Some users of non-IP protocol families may still prefer encapsulation because of the ability to traverse the ubiquitous Internet, rather than just one link. > Finally, remember those fancy options? They allow you to fix > things that you can't handle with SLIP, like characters that > can't go through your modem. They even allow you to detect when > your line is down, or looped back, so that you can auto-magically > redial. I know of a commerical SLIP implementation which does this. There are many such UUCP implementations with this, and it is easy to steal it from UUCP and graft into your SLIP code. I'm not sure whether by "this" you mean bit stuffing or loopback detection or auto-dialing. The SLIP standard knows nothing of character escaping (except the frame flag character and the escape character), so any commercial SLIP that does it won't be guaranteed to work with any other SLIP that doesn't. Loopback detection techniques would likewise be specific to a particular SLIP implementation. Marble's Teleconnect SLIP apparently has on-demand dialing. Our SLIP implementation got its on-demand feature because our SLIP is only an optional feature (I think of it as a colostomy bag :-) in our PPP daemon, which already had it. On-demand dialing and other such features (e.g. packet filtering) are part of particular implementations, not the protocol itself (nor part of PPP). But they don't cause interoperability problems with other SLIPs or PPPs that aren't featureful enough. Over selling things makes them look bad. Well taken. There is one solid reason to like PPP over SLIP in the preceding, the non-IP packet forwarding, but I suspect it is not universally implemented. I think there are other, unlisted advantages of PPP, but PPP is not perfect--it's already been over-perfected. Agreed. Many SLIPs have some of the advantages of PPP. But SLIP is so loosely specified that many of the techniques you describe have grown up around it through years of experience, and are essentially part of the oral folklore surrounding the basic protocol. Many are not universally implemented, and if your peer doesn't do something you want it to, there's no way within the protocol to discover it, so you'll need to fall back on verbal negotiations betwen host administrators over the telephone. It's not that I don't like to talk to people, but I shouldn't be forced to waste time talking about things like VJ and MTU, before getting on to more pleasant topics. Maybe it's time for an updated SLIP RFC, describing some of the features that modern, reasonable implementations provide. But it will be just as tough as it is now to make existing 1055-compatible SLIPs work well with the new ones. And nobody should be putting any substantial engineering effort into SLIP any more, now that PPP is available. P.S. I hope my sarcasm detecter is ok. I just realized that the list of PPP advantages could have been tongue-in-cheek. No, Bill's list just wasn't explicit enough. From ietf-ppp-request@ucdavis.ucdavis.edu Thu Dec 5 09:49:37 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA13014; Thu, 5 Dec 91 09:31:59 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from asylum.sf.ca.us by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA12382; Thu, 5 Dec 91 09:18:09 -0800 Received: by asylum.sf.ca.us id AA18666; Thu, 5 Dec 91 12:18:48 -0500 (EST) Date: Thu, 5 Dec 91 12:18:48 -0500 (EST) From: romkey@asylum.sf.ca.us (John Romkey) Message-Id: <9112051718.AA18666@asylum.sf.ca.us> To: vjs@RHYOLITE.WPD.SGI.COM Cc: bsimpson@VELA.ACS.OAKLAND.EDU, ietf-ppp@UCDAVIS.EDU In-Reply-To: Vernon Schryver's message of Wed, 4 Dec 91 23:51:55 -0800 <9112050751.AA22638@rhyolite.wpd.sgi.com> Subject: SLIP vs. PPP Sender: ietf-ppp-request@UCDAVIS.EDU Date: Wed, 4 Dec 91 23:51:55 -0800 From: vjs@RHYOLITE.WPD.SGI.COM (Vernon Schryver) All TCP/IP packets are already checksummed. All UDP/IP packets from responsible computer vendors are already checksummed. Packets with bad checksums are immediately discarded by TCP/IP (plus or minus a few msec of ethernet forwarding). PPP link level checksums are nice, but not compelling. Counters are nice, if your TCP stack doesn't already have bad checksum counters, and so is incompatible with SNMP. MIB II, not SNMP. If it doesn't count bad TCP checksums, it can still run SNMP fine, it just won't be able to provide full MIB II support over SNMP. It's a minor, but important distinction. - john romkey Epilogue Technology USENET/UUCP/Internet: romkey@asylum.sf.ca.us voice: 617 942-0915 From ietf-ppp-request@ucdavis.ucdavis.edu Thu Dec 5 13:07:21 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA19280; Thu, 5 Dec 91 12:32:14 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SGI.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18694; Thu, 5 Dec 91 12:16:30 -0800 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (911016.SGI/910110.SGI) for ietf-ppp@ucdavis.edu id AA22575; Thu, 5 Dec 91 12:14:12 -0800 Received: by rhyolite.wpd.sgi.com (911016.SGI/911001.SGI) for @sgi.sgi.com:bob@roughy.MorningStar.Com id AA23390; Thu, 5 Dec 91 12:14:05 -0800 Date: Thu, 5 Dec 91 12:14:05 -0800 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9112052014.AA23390@rhyolite.wpd.sgi.com> To: bob@roughy.MorningStar.Com Subject: Re: SLIP vs. PPP Cc: ietf-ppp@ucdavis.edu, bsimpson@vela.acs.oakland.edu > From bob@roughy.MorningStar.Com Thu Dec 5 07:25:44 1991 > From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) > > > First of all, [PPP]'s easier to configure. > Ok, reasonable implementations work well, like many things > including SLIP. > > And there are lots of unreasonable SLIP implementations out there. ... The problems you describe with ISC's SLIP can't be due to age, since I think that's a new implementation. Newer than this working group, and newer than many good SLIP implementations. There will plenty of unreasonable things calling themselves PPP, given a little time. It's hardly surprising that you and Cisco had few problems, just as it is unsurprising that Dave Borman and Van Jacobson had no problems making the TCP extensions work. > ... > We don't burn an address, or a pair of addresses, for each link, > whether we're using SLIP or PPP. ... Me neither, but you do have to have an address for every host in your net. That's the hard part, at least for me. > Claims for no-brain PPP routing and addressing are surprising if > you read comp.protocols.ppp. > > The great majority of our customers' problems are related to modem > configurations, not addressing and routing. I saw your interesting note. I believe it from my own experience. If I didn't know I'm completely sane, I'd think only a few crazies were capable of distinguising between DCD and DTR. What is the next largest catagory after modem related problems? IP addressing and routing? > ... > > Second of all, the packet is checksummed, so that if it's bad, > > it gets thrown away right away, > > All TCP/IP packets are already checksummed. > > In our implementation, it costs a trip from the daemon into the kernel > to pass a (group of) packet(s) up to IP. If a bad packet can be > discovered earlier, the expense of that write() can be saved. I can't believe even a user-level implementation (yours?) is CPU bound in error recovery, where SLIP might be used instead of PPP. You're talking about ~19Kbit/sec, around 1000 times slower than ethernet. Any reasonable machine can drive at least one full ethernet. If bad packets happen often enough to waste many CPU cycles, then the valid data pushed thru a 19Kb pipe will be too little to matter to the user! > One vendor's most recently-shipped version of the kernel will croak > (the infamous "mclput panic") if handed a packet that's malformed in > certain ways. Those packets are particularly prone to arrive at link > shutdown time, before the SLIP implementation knows that it's supposed > to be shutting down. We fixed our SLIP to watch for unreasonable > packets before passing them up to IP, just as a workaround for our > customers who haven't yet installed the widely-available kernel patch. > But again, this is outside the purvey of the SLIP spec, and there's no > discussion in the RFC of ways to accomplish this, so each SLIP vendor > may or may not do it, and still call themselves SLIP. Your stuff is evidently good, whether SLIP or PPP. That has no bearing on whether to chose PPP instead of SLIP. Bad software calls itself by the same name as good. Even good housekeeping seals of approval don't change that. > Counters are nice, if your TCP stack doesn't already have bad > checksum counters, and so is incompatible with SNMP. > > Sometimes it's helpful to be able to separate link problems from > malformed TCP packets that originated on the peer. And ICMP and UDP > and other protocol families may not have nice checksum counters built > in. Yes, more counters are nicer. No, normal 4.3BSD implementations do have UDP & ICMP checksum counters built in. Doesn't the new SNMP MIP require them? > > Finally, remember those fancy options? They allow you to fix > > things that you can't handle with SLIP, like characters that > > can't go through your modem. They even allow you to detect when > > your line is down, or looped back, so that you can auto-magically > > redial. > > I know of a commerical SLIP implementation which does this. There > are many such UUCP implementations with this, and it is easy to > steal it from UUCP and graft into your SLIP code. > > I'm not sure whether by "this" you mean bit stuffing or loopback > detection or auto-dialing. I meant problem detection and auto-redial. I'm not impressed with this form of bit stuffing for pipes which might use SLIP. Anyone smart enough to tell PPP which characters to escape also knows to not run with XON/XOFF modem flow control. > .... On-demand dialing and other such > features (e.g. packet filtering) are part of particular > implementations, not the protocol itself (nor part of PPP). But they > don't cause interoperability problems with other SLIPs or PPPs that > aren't featureful enough. Well said. > ... Many SLIPs have some of the advantages of PPP. But SLIP is > so loosely specified that many of the techniques you describe have > grown up around it through years of experience, and are essentially > part of the oral folklore surrounding the basic protocol. Many are > not universally implemented, and if your peer doesn't do something you > want it to, there's no way within the protocol to discover it, so > you'll need to fall back on verbal negotiations betwen host > administrators over the telephone. It's not that I don't like to talk > to people, but I shouldn't be forced to waste time talking about > things like VJ and MTU, before getting on to more pleasant topics. > > Maybe it's time for an updated SLIP RFC, describing some of the > features that modern, reasonable implementations provide. But it will > be just as tough as it is now to make existing 1055-compatible SLIPs > work well with the new ones. And nobody should be putting any > substantial engineering effort into SLIP any more, now that PPP is > available. I agree with almost all of this. I thought the main advantage of PPP was that the wide area router vendors would use it, allowing me to mix-and-match routers. Or maybe to build cheap, low performance routers with just software. We didn't need the fancy HDLC FSA blah-de-blah in a replacement for SLIP. All we needed in a replacement for SLIP was the "folklore" or actually simple, good design you mention above, and header compression. The sad part of PPP is that it is showing signs of the ANSI/IEEE/CCITT/OSI disease, whose most positive outcome is typified by FDDI. Too complicated, far too long in the standardization process, too expensive, too slow, too little, and nearly too late to survive in the market. Remember when this was supposed to last just a few months? Vernon Schryver, vjs@sgi.com From ietf-ppp-request@ucdavis.ucdavis.edu Thu Dec 5 13:38:54 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA20324; Thu, 5 Dec 91 13:10:01 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA19892; Thu, 5 Dec 91 12:55:43 -0800 Received: from roughy.morningstar.com by volitans.morningstar.com (5.65a/91111501) id AA13219; Thu, 5 Dec 91 15:54:11 -0500 Received: by roughy.morningstar.com (5.65a/910712902) id AA02016; Thu, 5 Dec 91 15:54:07 -0500 Date: Thu, 5 Dec 91 15:54:07 -0500 From: Bob Sutterfield Message-Id: <9112052054.AA02016@roughy.morningstar.com> To: vjs@rhyolite.wpd.sgi.com Cc: ietf-ppp@ucdavis.edu, bsimpson@vela.acs.oakland.edu In-Reply-To: Vernon Schryver's message of Thu, 5 Dec 91 12:14:05 -0800 <9112052014.AA23390@rhyolite.wpd.sgi.com> Subject: SLIP vs. PPP Date: Thu, 5 Dec 91 12:14:05 -0800 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) > From bob@roughy.MorningStar.Com Thu Dec 5 07:25:44 1991 > And there are lots of unreasonable SLIP implementations out there. ... There will plenty of unreasonable things calling themselves PPP, given a little time. Probably so. But at least we can discover them in an organized way by a few well-placed punches with an LCP Code-Reject :-) (Has anyone written a PPP stress-tester suite? You know, something that will throw all sorts of known good and bad packets at another implementation and watch how it responds, then produce a grade card? We use them all the time to certify our X.25, and it would be helpful for PPP too.) What is the next largest catagory after modem related problems? IP addressing and routing? Certainly. People trying to bend Proxy ARP into all sorts of weird contortions just because they can't talk their number czar into giving them what they need. People who haven't read even chapters 1-3 of Comer's book, let alone up through 8 plus 16, which would give them all they need. Ah, the life of a doc writer... > In our implementation, it costs a trip from the daemon into the > kernel to pass a (group of) packet(s) up to IP. If a bad packet > can be discovered earlier, the expense of that write() can be > saved. I can't believe even a user-level implementation (yours?) is CPU bound in error recovery, where SLIP might be used instead of PPP. You're talking about ~19Kbit/sec, around 1000 times slower than ethernet. Any reasonable machine can drive at least one full ethernet. You're right, for situations where one might be tempted to use SLIP. But when we're pumping a T1 link 98% full, every trip across the kernel boundary costs dearly. Even at the highest speeds at which we do FCS in software, the time required is negligible in comparison to the time spent pumping packets. If bad packets happen often enough to waste many CPU cycles, then the valid data pushed thru a 19Kb pipe will be too little to matter to the user! If there are that many errors on the line, wouldn't it be better to have the error counters in the daemon, where we can potentially make link management decisions based on the results? I'm not impressed with this form of bit stuffing for pipes which might use SLIP. Anyone smart enough to tell PPP which characters to escape also knows to not run with XON/XOFF modem flow control. But sometimes you need to go through other people's communications gear, with odd configurations you can't anticipate. For example, I'm helping set up dial-up anonymous PPP at OSU CIS, similar to their anon-UUCP service. One route goes through some XON/XOFF modems at the campus computer center, then through a terminal server and across a telnet connection to a pty on the destination Sun, where our pppd answers the phone. Somewhere along the way, some layer is "helpfully" appending eight 0x00 bytes after each 0x08 byte it sees traveling outbound. So the async-map on that connection must be 0xa0100. It's amazing that it even works... All we needed in a replacement for SLIP was the "folklore" or actually simple, good design you mention above, and header compression. I'd say the FSA just embodies the folklore. The sad part of PPP ... Too complicated, far too long in the standardization process, too expensive, too slow, too little, and nearly too late to survive in the market. Since the FSA encapsulates the folklore into an algorithmic form, I see the evolution as just the result of acquiring more and more "conventional wisdom." The authors are now working harder to freeze the silly thing and get a version out the door. Then we can all start adding more wisdom to the next version. From ietf-ppp-request@ucdavis.ucdavis.edu Thu Dec 5 14:17:29 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA21627; Thu, 5 Dec 91 13:46:43 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SGI.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA21213; Thu, 5 Dec 91 13:33:17 -0800 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (911016.SGI/910110.SGI) for ietf-ppp@ucdavis.edu id AA27042; Thu, 5 Dec 91 13:31:18 -0800 Received: by rhyolite.wpd.sgi.com (911016.SGI/911001.SGI) for @sgi.sgi.com:bob@MorningStar.Com id AA23574; Thu, 5 Dec 91 13:31:16 -0800 Date: Thu, 5 Dec 91 13:31:16 -0800 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9112052131.AA23574@rhyolite.wpd.sgi.com> To: bob@MorningStar.Com (Bob Sutterfield) Subject: Re: SLIP vs. PPP Cc: bsimpson@vela.acs.oakland.edu, ietf-ppp@ucdavis.edu > From bob@roughy.MorningStar.Com Thu Dec 5 12:56:15 1991 > There will plenty of unreasonable things calling themselves PPP, > given a little time. > > Probably so. But at least we can discover them in an organized way by > a few well-placed punches with an LCP Code-Reject :-) Do you really think so? I have more respect for the idiots of the world. Their code will say it supports things, but will do it wrong. > (Has anyone written a PPP stress-tester suite? You know, something > that will throw all sorts of known good and bad packets at another > implementation and watch how it responds, then produce a grade card? > We use them all the time to certify our X.25, and it would be helpful > for PPP too.) The magic of industry standard test suites. Sigh. Do you think that the "famous mcluput" or whatever bug you mentioned was not passed by a test suite? I'd talk about the reliability, stability, and basic correctness of FDDI systems which passed both ANTC and UNH, but that would get SGI excluded from Interop92. I will say that good implementations came with good people in each of the InterOP FDDI demos, that sick implementations one year are sick the next year, and that having attempted or not the test suites was not correlated with health, that almost everyone had tried and passed and none had failed. Test suites keep out the non-starters, not the junk. They help good guys do even better, and fool others into thinking they're good. > What is the next largest catagory after modem related problems? IP > addressing and routing? > Certainly. ... > ... > You're right, for situations where one might be tempted to use SLIP. > But when we're pumping a T1 link 98% full, every trip across the > kernel boundary costs dearly. ... Agreed. It would be silly or at least crazy to run SLIP over T1. > ... > All we needed in a replacement for SLIP was the "folklore" or > actually simple, good design you mention above, and header > compression. > > I'd say the FSA just embodies the folklore. Maybe. I think reference C source is a better, more difficult to misunderstand and misimplement reference model. > The sad part of PPP ... Too complicated, far too long in the > standardization process, too expensive, too slow, too little, and > nearly too late to survive in the market. > > Since the FSA encapsulates the folklore into an algorithmic form, I > see the evolution as just the result of acquiring more and more > "conventional wisdom." The authors are now working harder to freeze > the silly thing and get a version out the door. Then we can all start > adding more wisdom to the next version. Agreed. vjs From ietf-ppp-request@ucdavis.ucdavis.edu Thu Dec 5 20:34:39 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA03873; Thu, 5 Dec 91 20:16:11 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.124.48.2] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA03465; Thu, 5 Dec 91 20:00:32 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA02400; Thu, 5 Dec 91 19:58:02 PST Date: Thu, 5 Dec 91 19:58:02 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9112060358.AA02400@ray.lloyd.com> To: morris@marvin.enet.dec.com Cc: "\"fred baker\""@enet-gw.pa.dec.com, ietf-ppp@ucdavis.edu In-Reply-To: SEMPER INFACEBO SUMUS - SOLE PROFUNDUM VARIAT 05-Dec-1991 0830's message of Thu, 5 Dec 91 00:31:51 PST <9112050831.AA25501@enet-gw.pa.dec.com> Subject: Connection Establishment The process of using XID to determine the protocol that will run on a link occurs before starting the protocol therefore there is no ambiguity. The case of one end starting PPP without going through the XID negotiation may occur if one end knows how to do PPP and nothing else. In that case the system will send the initial configuration request for the LCP negotiation with no compression of the fields (address and control compression may not be turned on until LCP option negotiation is complete). The only time I can think of where there might be a problem is if one end reboots and tries to XID while the other end thinks that it is still in the open state. 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 Dec 5 23:16:49 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA07563; Thu, 5 Dec 91 23:01:02 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.124.48.2] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA07314; Thu, 5 Dec 91 22:49:15 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA02545; Thu, 5 Dec 91 22:46:39 PST Date: Thu, 5 Dec 91 22:46:39 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9112060646.AA02545@ray.lloyd.com> To: vjs@rhyolite.wpd.sgi.com Cc: bsimpson@vela.acs.oakland.edu, ietf-ppp@ucdavis.edu In-Reply-To: Vernon Schryver's message of Wed, 4 Dec 91 23:51:55 -0800 <9112050751.AA22638@rhyolite.wpd.sgi.com> Subject: SLIP vs. PPP Well I guess that you think that SLIP is just as good as PPP. In many cases, yes. Here are a few other items: PPP will work on sync links. This is quite nice when you want brand c router to talk to brand 3, brand W, or brand N (and soon brand P) over a 56K or T1 line. Async PPP will work on links that swallow certain control characters, like XON and XOFF, ^c, etc. PPP provides a means by which a terminal server/dial-up router can tell the remote device what its IP address is. Quite useful for the person on-the-go with his/her laptop who calls into different POPs at different times and doesn't want to have to manually change the IP address in his/her portable every time he/she connects to the network. PPP is extendable to include new features when such features become desirable. The negotiation also makes it possible for the latest and greatest PPP implementation to be backward compatible with the earliest. I happen to agree that the CRC is probably overkill but it will help to reduce traffic in the network in the case where the PPP link is losing. If you rely on the TCP checksum you have to wait until the d'gram makes it all the way to the destination before TCP can discard it. With PPP it gets discarded right away and you don't waste bandwidth sending the damage d'gram all the way to the end. Lastly and most importantly, PPP gives me an opportunity to be chaircritter of an IETF working group. ;-) ;-) 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 Fri Dec 6 01:53:08 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10820; Fri, 6 Dec 91 01:26:26 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from enet-gw.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10357; Fri, 6 Dec 91 01:05:07 -0800 Received: by enet-gw.pa.dec.com; id AA08196; Fri, 6 Dec 91 01:02:30 -0800 Message-Id: <9112060902.AA08196@enet-gw.pa.dec.com> Received: from marvin.enet; by decwrl.enet; Fri, 6 Dec 91 01:02:37 PST Date: Fri, 6 Dec 91 01:02:37 PST From: SEMPER INFACEBO SUMUS - SOLE PROFUNDUM VARIAT 06-Dec-1991 0902 To: brian@lloyd.com Cc: ietf-ppp@ucdavis.edu Apparently-To: ietf-ppp@ucdavis.edu, brian@lloyd.com Subject: XID negotiation > The process of using XID to determine the protocol that will run on a > link occurs before starting the protocol therefore there is no > ambiguity. The case of one end starting PPP without going through > the XID negotiation may occur if one end knows how to do PPP and > nothing else. In that case the system will send the initial > configuration request for the LCP negotiation with no compression of > the fields (address and control compression may not be turned on until > LCP option negotiation is complete). > > The only time I can think of where there might be a problem is if one > end reboots and tries to XID while the other end thinks that it is > still in the open state. Precisely. If one end thinks it's still open, it may well be sending packets that look like XIDs. Similarily, the end that's just rebooted may be sending packets that its peer thinks are perfectly valid PPP frames. Basically, the question is, how likely is the above scenario and do we need to cater for it? Automatic configuration is obviously a nice thing, but if it can produce non-deterministic and ambiguous results then I feel most network managers would prefer to configure both ends manually. Comments? Dean Morris - DEC Corporate Backbone Networks Groups, Reading. From ietf-ppp-request@ucdavis.ucdavis.edu Fri Dec 6 13:10:53 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA26358; Fri, 6 Dec 91 12:48:26 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.124.48.2] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA26145; Fri, 6 Dec 91 12:40:33 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA03037; Fri, 6 Dec 91 12:38:53 PST Date: Fri, 6 Dec 91 12:38:53 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9112062038.AA03037@ray.lloyd.com> To: morris@marvin.enet.dec.com Cc: ietf-ppp@ucdavis.edu In-Reply-To: SEMPER INFACEBO SUMUS - SOLE PROFUNDUM VARIAT 06-Dec-1991 0902's message of Fri, 6 Dec 91 01:02:37 PST <9112060902.AA08196@enet-gw.pa.dec.com> Subject: XID negotiation Well, the XID hack that they came up with in the IPLPDN WG was aimed at circuit switched links. In that case the physical layer would ALWAYS indicate the link down-to-up transition thus removing the ambiguity. I cannot on first pass see how a problem would occur except in the case of a hard-wired link that does not propagate the state of the physical link. Of course part of bringing the physical link up should be to ensure that it is down first so that the initial down-to-up transistion is guaranteed to be valid. 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 Fri Dec 6 13:36:51 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA26753; Fri, 6 Dec 91 13:02:47 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from merit.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA26378; Fri, 6 Dec 91 12:49:02 -0800 Return-Path: Received: from asterix.merit.edu by merit.edu (5.65/1123-1.0) id AA08346; Fri, 6 Dec 91 15:47:23 -0500 Received: by asterix.merit.edu (4.1/dumb-0.9) id AA25634; Fri, 6 Dec 91 15:47:21 EST Message-Id: <9112062047.AA25634@asterix.merit.edu> From: Glenn.McGregor@merit.edu To: ietf-ppp@ucdavis.edu Cc: ghm@merit.edu Subject: IPCP draft Date: Fri, 06 Dec 91 15:47:20 -0500 Here's a version of the IPCP draft with the changes discussed at the Santa Fe IETF. The major change is the IP addresss negotiation. Glenn McGregor Merit Network, Inc. Glenn.McGregor@Merit.edu -------- Network Working Group G McGregor Request for Comments: DRAFT Merit Obsoletes: RFC 1172 December 1991 The PPP Internet Protocol Control Protocol (IPCP) Status of this Memo This RFC specifies an IAB standards track protocol for the Internet community. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. 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. 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 the Internet Protocol [2] over PPP, and a method to negotiate and use Van Jacobson TCP/IP header compression [3] with PPP. McGregor [Page i] RFC DRAFT PPP IPCP December 1991 1. Introduction PPP has three main components: 1. A method for encapsulating datagrams over serial links. PPP uses HDLC as a basis for encapsulating datagrams over point- to-point links. At this time, PPP specifies the use of asynchronous or synchronous duplex circuits, either dedicated or circuit switched. 2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. 3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. PPP is designed to allow the simultaneous use of multiple network- layer protocols. In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure and test the data link. After the link has been established and optional facilities have been negotiated as needed by the LCP, PPP must send NCP packets to choose and configure one or more network-layer protocols. Once each of the chosen network-layer protocols has been configured, datagrams from each network-layer protocol can be sent over the link. The link will remain configured for communications until explicit LCP or NCP packets close the link down, or until some external event occurs (an inactivity timer expires or network administrator intervention). McGregor [Page 1] RFC DRAFT PPP IPCP December 1991 2. A PPP Network Control Protocol (NCP) for IP The IP Control Protocol (IPCP) is responsible for configuring, enabling, and disabling the IP protocol modules on both ends of the point-to-point link. IPCP uses the same packet exchange machanism as the Link Control Protocol (LCP). IPCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. IPCP packets received before this phase is reached should be silently discarded. The IP Control Protocol is exactly the same as the Link Control Protocol [1] with the following exceptions: Data Link Layer Protocol Field Exactly one IPCP packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 8021 (IP 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 IPCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. An implementation should be prepared to wait for Authentication and Link Quality Determination 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. Configuration Option Types IPCP has a distinct set of Configuration Options, which are defined below. 2.1. Sending IP Datagrams Before any IP packets may be communicated, PPP must reach the Network-Layer Protocol phase, and the IP Control Protocol must reach the Opened state. Exactly one IP packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 0021 (Internet Protocol). McGregor [Page 2] RFC DRAFT PPP IPCP December 1991 The maximum length of an IP packet transmitted over a PPP link is the same as the maximum length of the Information field of a PPP data link layer frame. Larger IP datagrams must be fragmented as necessary. If a system wishes to avoid fragmentation and reassembly, it should use the TCP Maximum Segment Size option [4], and MTU discovery [5]. McGregor [Page 3] RFC DRAFT PPP IPCP December 1991 3. IPCP Configuration Options IPCP Configuration Options allow negotiatiation of desirable Internet Protocol parameters. IPCP uses the same Configuration Option format defined for LCP [1], with a separate set of Options. The most up-to-date values of the IPCP Option Type field are specified in the most recent "Assigned Numbers" RFC [6]. Current values are assigned as follows: 1 IP-Addresses 2 IP-Compression-Protocol 3 IP-Address McGregor [Page 4] RFC DRAFT PPP IPCP December 1991 3.1. IP-Addresses Description This Configuration Option has been deprecated. RFC 1172 [7] provides information for implementations requiring backwards compatability. The IP-Address Configuration Option replaces this option, and its use is preferred. McGregor [Page 5] RFC DRAFT PPP IPCP December 1991 3.2. IP-Compression-Protocol Description This Configuration Option provides a way to negotiate the use of a specific compression protocol. By default, compression is not enabled. A summary of the IP-Compression-Protocol Configuration Option format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | IP-Compression-Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+ Type 2 Length >= 4 IP-Compression-Protocol The IP-Compression-Protocol field is two octets and indicates the compression protocol desired. Values for this field are always the same as the PPP Data Link Layer Protocol field values for that same compression protocol. The most up-to-date values of the IP-Compression-Protocol field are specified in the most recent "Assigned Numbers" RFC [6]. Current values are assigned as follows: Value (in hex) Protocol 002d Van Jacobson Compressed TCP/IP Data The Data field is zero or more octets and contains additional data as determined by the particular compression protocol. McGregor [Page 6] RFC DRAFT PPP IPCP December 1991 Default No compression protocol enabled. McGregor [Page 7] RFC DRAFT PPP IPCP December 1991 3.3. IP-Address Description This Configuration Option provides a way to negotiate the IP address to be used on the local end of the link. It allows the sender of the Configuration-Req to state which IP-address is desired, or to request that the peer provide the information. The peer can provide this information by NAKing the option, and returning a valid IP-address. If negotiation about the remote IP-address is required, and the peer did not provide the option in its Configuration-Request, the option SHOULD be appended to a Configuration-Nak. The value of the IP-address given must be acceptable as the remote IP-address, or indicate a request that the peer provide the information. By default, no IP address is assigned. A summary of the IP-Address Configuration Option format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | IP-Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP-Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 3 Length 6 IP-Address The four octet IP-Address is the desired local address of the sender of a Configure-Request. If all four octets are set to zero, it indicates a request that the peer provide the IP-Address information. Default No IP address is assigned. McGregor [Page 8] RFC DRAFT PPP IPCP December 1991 4. Van Jacobson TCP/IP header compression Van Jacobson TCP/IP header compression reduces the size of the TCP/IP headers to as few as three bytes. This can be a significant improvement on slow serial lines, particularly for interactive traffic. The IP-Compression-Protocol Configuration Option is used to indicate the ability to receive compressed packets. Each end of the link must seperately request this option if bi-directional compression is desired. The PPP Protocol field is set to the following values when transmitting IP packets: Value (in hex) 0021 Type IP. The IP protocol is not TCP, or the packet is a fragment, or cannot be compressed. 002d Compressed TCP. The TCP/IP headers are replaced by the compressed header. 002f Uncompressed TCP. The IP protocol field is replaced by the slot identifier. 4.1. Configuration Option Format A summary of the IP-Compression-Protocol Configuration Option format to negotiate Van Jacobson TCP/IP header compression 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | IP-Compression-Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max-Slot-Id | Comp-Slot-Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 Length 6 McGregor [Page 9] RFC DRAFT PPP IPCP December 1991 IP-Compression-Protocol 002d (hex) for Van Jacobson Compressed TCP/IP headers. Max-Slot-Id The Max-Slot-Id field is one octet and indicates the maximum slot identifier. This is one less than the actual number of slots; the slot identifier has values from zero to Max-Slot-Id. Note: There may be implementations that have problems with only one slot (Max-Slot-Id = 0). See the discussion in reference [3]. The example implementation in [3] will only work with 3 through 254 slots. Comp-Slot-Id The Comp-Slot-Id field is one octet and indicates whether the slot identifier field may be compressed. 0 The slot identifier must not be compressed. All compressed TCP packets must set the C bit in every change mask, and must include the slot identifier. 1 The slot identifer may be compressed. The slot identifier must not be compressed if there is no ability for the PPP link level to indicate an error in reception to the decompression module. Synchronization after errors depends on receiving a packet with the slot identifier. See the discussion in reference [3]. McGregor [Page 10] RFC DRAFT PPP IPCP December 1991 A. IPCP Recommended Options The following Configurations Options are recommended: IP-Addresses - only after the IP-Address option has been rejected. IP-Compression-Protocol -- with at least 4 slots, usually 16 slots. IP-Address -- only on dial-up lines. McGregor [Page 11] RFC DRAFT PPP IPCP December 1991 References [1] Simpson, W. A., "The Point-to-Point Protocol for the Transmission of Multi-Protocol of Datagrams Over Point-to-Point Links", RFC in progress. [2] Postel, J., "Internet Protocol", RFC 791, USC/Information Sciences Institute, September 1981. [3] Jacobson, V., "Compressing TCP/IP Headers", RFC 1144, January 1990. [4] Postel, J., "The TCP Maximum Segment Size Option and Related Topics", RFC 879, USC/Information Sciences Institute, November 1983. [5] Mogul, J.C., Deering, S.E., "Path MTU Discovery", RFC 1191, November 1990. [6] Reynolds, J., Postel,J., "Assigned Numbers", RFC 1060, USC/Information Sciences Institute, March 1990. [7] Perkins, D., Hobby, R., "Point-to-Point Protocol (PPP) initial configuration options", RFC 1172, August 1990. Security Considerations Security issues are not discussed in this memo. Acknowledgments Some of the text in this document is taken from RFCs 1171 & 1172, by Drew Perkins of Carnegie Mellon University, and by Russ Hobby of the University of California at Davis. Information leading to the expanded IP-Compression option provided by Van Jacobson at SIGCOMM '90. Bill Simpson helped with the document formatting. Chair's Address The working group can be contacted via the current chair: Brian Lloyd McGregor [Page 12] RFC DRAFT PPP IPCP December 1991 Lloyd & Associates 3420 Sudbury Road Cameron Park, California 95682 Phone: (916) 676-1147 EMail: brian@ray.lloyd.com Author's Address Questions about this memo can also be directed to: Glenn McGregor Merit Network, Inc. 1071 Beal Avenue Ann Arbor, MI 48109-2103 Phone: (313) 763-1203 EMail: Glenn.McGregor@Merit.edu McGregor [Page 13] RFC DRAFT PPP IPCP December 1991 Table of Contents 1. Introduction .......................................... 1 2. A PPP Network Control Protocol (NCP) for IP ........... 2 2.1 Sending IP Datagrams ............................ 2 3. IPCP Configuration Options ............................ 4 3.1 IP-Addresses .................................... 5 3.2 IP-Compression-Protocol ......................... 6 3.3 IP-Address ...................................... 8 4. Van Jacobson TCP/IP header compression ................ 9 4.1 Configuration Option Format ..................... 9 APPENDICES ................................................... 11 A. IPCP Recommended Options .............................. 11 REFERENCES ................................................... 12 SECURITY CONSIDERATIONS ...................................... 12 ACKNOWLEDGEMENTS ............................................. 12 CHAIR'S ADDRESS .............................................. 12 AUTHOR'S ADDRESS ............................................. 13 McGregor [Page ii] From ietf-ppp-request@ucdavis.ucdavis.edu Fri Dec 6 18:32:20 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA05860; Fri, 6 Dec 91 18:15:42 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA05624; Fri, 6 Dec 91 18:04:41 -0800 Received: from crappie.morningstar.com by volitans.morningstar.com (5.65a/91111501) id AA17599; Fri, 6 Dec 91 21:03:02 -0500 Received: by crappie.morningstar.com (5.65a/910712902) id AA01759; Fri, 6 Dec 91 21:02:30 -0500 Date: Fri, 6 Dec 91 21:02:30 -0500 From: Karl Fox Message-Id: <9112070202.AA01759@crappie.morningstar.com> To: Glenn.McGregor@merit.edu Cc: ietf-ppp@ucdavis.edu, ghm@merit.edu In-Reply-To: <9112062047.AA25634@asterix.merit.edu> Subject: IPCP draft Glenn.McGregor@merit.edu writes: > Here's a version of the IPCP draft with the changes discussed at the > Santa Fe IETF. The major change is the IP addresss negotiation. Could someone who attended the Santa Fe meeting please fill me in on the reasoning behind the address negotiation change? Maybe I'm just dim, but I can't see any change in function; only in technique. This assumes, of course, that it's still OK to Nak a non-zero IP-Address. From ietf-ppp-request@ucdavis.ucdavis.edu Fri Dec 6 23:15:44 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10541; Fri, 6 Dec 91 23:00:45 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.124.48.2] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10406; Fri, 6 Dec 91 22:52:24 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA03414; Fri, 6 Dec 91 22:48:19 PST Date: Fri, 6 Dec 91 22:48:19 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9112070648.AA03414@ray.lloyd.com> To: karl@crappie.MorningStar.Com Cc: Glenn.McGregor@merit.edu, ietf-ppp@ucdavis.edu, ghm@merit.edu In-Reply-To: Karl Fox's message of Fri, 6 Dec 91 21:02:30 -0500 <9112070202.AA01759@crappie.morningstar.com> Subject: IPCP draft Actually the IP address negotiation issue is an old one. The "new" mechanism is the one that was originally proposed back at the Usenix BOF about four years ago (the one where PPP was conceived). It does everything that the current negotiation will do but it is much simpler (both to code AND to test). It is also unambiguous and is guaranteed to converge on proper addresses for both ends under all cases. This will lead to more implementations that work properly, e.g., it is much harder for the programmer to screw up. :-) 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 Sun Dec 8 12:45:44 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA23220; Sun, 8 Dec 91 12:30:19 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SGI.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA22962; Sun, 8 Dec 91 12:17:27 -0800 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (911016.SGI/910110.SGI) for ietf-ppp@ucdavis.edu id AA02971; Sun, 8 Dec 91 12:16:00 -0800 Received: by rhyolite.wpd.sgi.com (911016.SGI/911001.SGI) for @sgi.sgi.com:olling@taeko.jnoc.go.jp id AA28241; Sun, 8 Dec 91 12:15:59 -0800 Date: Sun, 8 Dec 91 12:15:59 -0800 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9112082015.AA28241@rhyolite.wpd.sgi.com> To: olling@taeko.jnoc.go.jp (Cliff Olling) Subject: Re: SLIP throughput on T2500 Cc: news.comp.protocols.ppp@rhyolite.wpd.sgi.com, ietf-ppp@ucdavis.edu References: <1991Dec6.022629.8486@jvnc.net> > From ccut.cc.u-tokyo.ac.jp!trc!taeko.jnoc.go.jp!olling Sun Dec 8 04:29:02 1991 > > On 7 Dec 91 20:04:11 GMT in comp.protocols.ppp, you wrote: > >One of these newsgroups is comp.protocols.ppp. PPP is different from SLIP. > > In these groups, it's interesting reading about these two, but is there > anything I can find (via ftp or otherwise) that backs up a level and says > what ppp and slip *do* and why one might be better suited for a particular > application than another? > > Thanks in advance, > -- > Clifford Olling Japan National Oil Corporation ~~$@@PL}8xCD~~(J > Technology Research Center ~~$@@PL}3+H/5;=Q~~(J Chiba City, Japan > olling@jnoc.go.jp ~~$@KkD%K\6?1X~~(J 24hrs/day=>81+472-73-5831 > put this in .rnmac to read my .sig: [ | sed s/~~/\\033/g | more\012 Ouch! Hoist by my own petard. In the IETF PPP mailing list I just finished flaming what I considered over selling of PPP. So, here's my attempt: -PPP is full featured point-to-point protocol intended to link routers over high speed sync. lines as well as hosts over async modems. PPP includes IP address assignment mechanisms, HDLC style checksums, authentication gadgets, connection re-establishment mechanisms, mechanisms to negotiate mutually agreed subsets, support for reduced character sets, support for many non-IP protocols, and other things. -The effort complete the PPP standard is years old. There continues to be hope that it will be finished real soon now. -SLIP was a quick hack many years ago to connect TCP/IP machines using async. modems. The RFC which describes SLIP is so concise that it leaves plenty of room to fail to build a high quality implementation. -Some companies including Morning Star Technologies and Telebit are selling PPP software and hardware for previous versions of the developing PPP standard. (New versions are intended to be upward compatible.) There are also public domain software implementations available for some popular UNIX workstations, including Suns. -There are many public domain and commercial SLIP implementations. Some include most of the features of PPP useful for connecting TCP/IP hosts, from auto-(re)dial to header compression. Others are less complete. Many are related to the medium-quality SLIP code in 4.3BSD-reno, which does include header compression. -I think the great advantage of PPP is the hope that wide area router vendors will adopt it, allowing us to mix and match router vendors on a single dedicated line. There is evidence not all router vendors consider this desirable. -The main advantage of SLIP is its simplicity. A competant UNIX kernel hack should be able to get a SLIP implemenation running very quickly. A trivial advantage is that SLIP "wastes" fewer bits in overhead. (I think about 8 bits/packet). -The main disadvantage of SLIP is its simplicity. If you want more than IP over a modem, you must roll your own protocol. Its simplicity has also encouraged the appearance of incompatible extensions. I don't know where to obtain public domain PPP or SLIP source, except to point at UUNET for 4.3BSD in general. A big thing I don't know is whether people will run PPP or something else over ISDN or frame-relay. If other things are used over those lines, and if those lines become as popular as their advocates hope, PPP will be left compeating with SLIP over async lines in that shrink niche. Vernon Schryver, vjs@sgi.com From ietf-ppp-request@ucdavis.ucdavis.edu Sun Dec 8 16:46:42 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA27899; Sun, 8 Dec 91 16:30:38 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA27668; Sun, 8 Dec 91 16:25:52 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA00565; Sun, 8 Dec 91 16:23:16 PST Date: Sun, 8 Dec 91 16:23:16 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9112090023.AA00565@ray.lloyd.com> To: vjs@rhyolite.wpd.sgi.com Cc: olling@taeko.jnoc.go.jp, news.comp.protocols.ppp@rhyolite.wpd.sgi.com, ietf-ppp@ucdavis.edu In-Reply-To: Vernon Schryver's message of Sun, 8 Dec 91 12:15:59 -0800 <9112082015.AA28241@rhyolite.wpd.sgi.com> Subject: ISDN and PPP The IPLPDN WG at IETF discussed PPP, frame relay, and X.25 over circuit-switched ISDN. Basically they said that all are acceptable and are working on the details. 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 Dec 9 12:49:03 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA24704; Mon, 9 Dec 91 12:31:37 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA24418; Mon, 9 Dec 91 12:24:44 -0800 Received: by Angband.Stanford.EDU (5.65/inc-1.0) id AA02917; Mon, 9 Dec 91 12:23:27 -0800 Date: Mon, 9 Dec 91 12:23:27 -0800 From: brian@Angband.Stanford.EDU (Brian Lloyd) Message-Id: <9112092023.AA02917@Angband.Stanford.EDU> To: ietf-ppp@ucdavis.edu Subject: DECnet I received a call from Steve Senum at NSC indicating that he is still active in the area of doing DECnet over PPP. Since Steve is the original author of the document describing DECnet over PPP it is logical that he continue to be the clearing point for information. The conflict is that I had (rather offhandedly) indicated in the minutes of the most recent IETF meeting that Michelle Wright of Timeplex would be the clearing point for info. To rectify this would Michelle and Steve please get together and exchange information. I am sorry but I do not seem to have either of your email addresses at hand and neither of you appear in the "whois" database at the NIC. Brian Lloyd, WB6RQN Lloyd and Associates Network Architect 3420 Sudbury Road brian@ray.lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Mon Dec 9 15:46:43 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00415; Mon, 9 Dec 91 15:34:58 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA29676; Mon, 9 Dec 91 15:15:44 -0800 Received: by volitans.morningstar.com (5.65a/91111501) id AA23544; Mon, 9 Dec 91 18:12:08 -0500 Date: Mon, 9 Dec 91 18:12:08 -0500 From: Bob Sutterfield Message-Id: <9112092312.AA23544@volitans.morningstar.com> To: vjs@rhyolite.wpd.sgi.com Cc: olling@taeko.jnoc.go.jp, news.comp.protocols.ppp@rhyolite.wpd.sgi.com, ietf-ppp@ucdavis.edu In-Reply-To: Vernon Schryver's message of Sun, 8 Dec 91 12:15:59 -0800 <9112082015.AA28241@rhyolite.wpd.sgi.com> Subject: SLIP throughput on T2500 You may be interested in the paper I presented mere hours ago at the Sun User Group on "Low-Cost IP Connectivity", which addresses several of these comparison questions. Get ftp.morningstar.com:pub/papers/sug91-cheapIP.ps[34]00.Z From ietf-ppp-request@ucdavis.ucdavis.edu Mon Dec 9 20:32:18 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA08980; Mon, 9 Dec 91 20:15:40 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA08747; Mon, 9 Dec 91 20:09:05 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA01997; Mon, 9 Dec 91 20:07:29 PST Date: Mon, 9 Dec 91 20:07:29 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9112100407.AA01997@ray.lloyd.com> To: ietf-ppp@ucdavis.edu Subject: working group meeting in SD? Well, it is already time to plan for the next IETF meeting in San Diego (March '92). Several questions: 1. Do we need to meet? (I think so) 2. What are the items that need to be covered? (rejoicing that we have RFCs for LCP and IPCP :-) (Appletalk) (IPX) (encryption) More? Feedback please. 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 Dec 10 10:17:32 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA26930; Tue, 10 Dec 91 09:32:14 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [130.57.4.1] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA26430; Tue, 10 Dec 91 09:17:56 -0800 Received: from na.novell.com by newsun.novell.com (4.1/smi4.1.1) id AA05099; Tue, 10 Dec 91 09:12:22 PST Received: by na.novell.com (4.1/SMI-4.1) id AA01480; Tue, 10 Dec 91 09:16:06 PST Date: Tue, 10 Dec 91 09:16:06 PST From: jthomas@na.novell.com (Bill Thomas) Message-Id: <9112101716.AA01480@na.novell.com> To: ietf-ppp@ucdavis.edu Subject: Request for Your NEW RFC's???? This is a formal request for these NEW RFC's Brian. Oh best of luck with your new PPP certification & OEM software. From ietf-ppp-request@ucdavis.ucdavis.edu Tue Dec 10 12:14:07 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00799; Tue, 10 Dec 91 11:33:50 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA29710; Tue, 10 Dec 91 11:04:15 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA02549; Tue, 10 Dec 91 11:02:15 PST Date: Tue, 10 Dec 91 11:02:15 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9112101902.AA02549@ray.lloyd.com> To: jthomas@na.novell.com Cc: ietf-ppp@ucdavis.edu In-Reply-To: Bill Thomas's message of Tue, 10 Dec 91 09:11:44 PST <9112101711.AA01345@na.novell.com> Subject: New LCP & IPCP RFC's ???? The RFC's don't exist yet. The point I was making is that we will have RFCs by March IETF if Ihave to move heaven and hell to make it so. Therefore we will have cause to rejoice. As for the drafts, the IPCP draft floated by here a week ago. The LCP doc and the IPCP doc will be up in the internet-drafts dir at nri in a few days. 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 Dec 10 14:57:26 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA06327; Tue, 10 Dec 91 14:36:39 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA05059; Tue, 10 Dec 91 13:57:39 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA24308; Tue, 10 Dec 91 16:56:19 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9112102156.AA24308@vela.acs.oakland.edu> Subject: IPCP nits To: ietf-ppp@ucdavis.edu Date: Tue, 10 Dec 91 16:56:18 EST X-Mailer: ELM [version 2.3 PL11] Found a couple of nits in the IPCP. "Configuration-Req" should be "Configure-Request". "seperately" should be "separately". Could you put a reason for the deprecation in Code 1? Something like, "Through experience, this option was found to be difficult if not impossible to implement without convergence problems." Don't bother reposting to the list. Just add any suggestions to the text before sending it off as an RFC. Bill Simpson From ietf-ppp-request@ucdavis.ucdavis.edu Tue Dec 10 15:01:51 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA06455; Tue, 10 Dec 91 14:43:49 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA05991; Tue, 10 Dec 91 14:28:02 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA25718; Tue, 10 Dec 91 17:24:40 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9112102224.AA25718@vela.acs.oakland.edu> Subject: Re: IPCP draft To: karl@crappie.morningstar.com (Karl Fox) Date: Tue, 10 Dec 91 17:24:39 EST Cc: ietf-ppp@ucdavis.edu In-Reply-To: <9112070202.AA01759@crappie.morningstar.com>; from "Karl Fox" at Dec 6, 91 9:02 pm X-Mailer: ELM [version 2.3 PL11] The reason for the change to IP address negotiation was simple: the old option couldn't be done without convergence problems in certain cases. I spent a lot of time trying to get it to work in all possible instances: neither end has an address; both ends do, but don't know the other end; both ends think they know, but are willing to accept the other, etc, etc. This is a really thorny problem, because the packets can be passing each other on the wire. It was probably the hardest part of PPP to write. I thought that I had it right. McGregor announced that he had found another flaw in my code. He also pointed out that this option did not follow the "philosophy" of the rest of the options; that is, each end of the link negotiates *ONLY* for its end of the link. We also had some history from Russ Hobby. As Brian has already mentioned, there were other suggested forms for this option, including the one which we are now going to use. The down side of this format is that in some common instances (where a terminal server wants to enforce an address on the other end), this format will require one additional packet exchange. The up side is, this format should *always* work correctly. That is what the RFC process is all about. We require test implementations and interoperability *before* we finalize a standard. In this case, we learned from implementation experience. Bill Simpson From ietf-ppp-request@ucdavis.ucdavis.edu Thu Dec 12 01:22:04 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02245; Thu, 12 Dec 91 01:00:30 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02134; Thu, 12 Dec 91 00:54:37 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA28073; Thu, 12 Dec 91 03:53:13 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9112120853.AA28073@vela.acs.oakland.edu> Subject: No Passive FSA To: ietf-ppp@ucdavis.edu Date: Thu, 12 Dec 91 3:53:10 EST X-Mailer: ELM [version 2.3 PL11] I've been poking away at this, and thought I'd post it for comment. This is the FSA without Passive Opens. Please post your comments to the list. Bill Simpson .nf Events Actions U = Lower-Layer-Up - = illegal event D = Lower-Layer-Down O = Open C = Close tll = Terminate-Lower-Layer TO+ = Timeout with counter > 0 TO- = Timeout with counter expired RCR+ = Receive-Configure-Request (Good) scr = Send-Configure-Request RCR- = Receive-Configure-Request (Bad) RCA = Receive-Configure-Ack sca = Send-Configure-Ack RCN = Receive-Configure-Nak/Rej scn = Send-Configure-Nak/Rej RTR = Receive-Terminate-Request str = Send-Terminate-Request RTA = Receive-Terminate-Ack sta = Send-Terminate-Ack RUC = Receive-Unknown-Code scj = Send-Code-Reject RCJ = Receive-Code-Reject RER = Receive-Echo-Request ser = Send-Echo-Reply .fi .RE .Nh 2 State Transition Table .LP .RS The complete state transition table follows. Implementation should be done by consulting it rather than the state diagram. States are indicated horizontally, and events are read vertically. State transitions and actions are represented in the form action/new-state. Multiple actions are separated by commas, and may continue on succeeding lines as space requires. .LP .RS Historical Note: In previous versions of this table, a simplified non-deterministic finite-state automaton was used, with considerable detailed information specified in the semantics. This lead to interoperability problems from differing interpretations. .LP This table functions similarly to the previous versions, with the up/down flags expanded to explicit states, and the active/passive paradigm eliminated. It is believed that this table interoperates with previous versions better than those versions themselves. .RE .RE .LP .nf | State | 0 1 2 3 4 5 | Closed Opening Closed Listening Closing Resuming Events| Down Up ------+----------------------------------------------------------- U | 2 scr/6 - - - - D | - - 0 1 0 1 O | 1 1 scr/6 scr/6 5 5 C | 0 0 2 2 4 4 | TO+ | - - - - str/4 str/5 TO- | - - - - tll/2 tll/3 | RCR+ | - - sta/2 scr,sca/8 4 5 RCR- | - - sta/2 scr,scn/6 4 5 RCA | - - 2 3 4 5 RCN | - - 2 3 4 5 | RTR | - - sta/2 sta/3 sta/4 sta/5 RTA | - - 2 3 tll/2 tll/3 | RUC | - - scj/2 scj/3 scj/4 scj/5 RCJ | - - tll/2 tll/3 tll/2 tll/3 | RER | - - 2 3 4 5 .fi .bp .nf | State | 6 7 8 9 Events| Req-Sent Ack-Rcvd Ack-Sent Opened ------+--------------------------------------- U | - - - - D | 1 1 1 1 O | 6 7 8 scr/6 C | str/4 str/4 str/4 str/4 | TO+ | scr/6 scr/6 scr/8 - TO- | tll/3 tll/3 tll/3 - | RCR+ | sca/8 sca/9 sca/8 scr,sca/8 RCR- | scn/6 scn/7 scn/6 scr,scn/6 RCA | 7 - 9 - RCN | scr/6 - scr/8 - | RTR | sta/6 sta/6 sta/6 sta,tll/3 RTA | 6 6 6 scr/6 | RUC | scj/6 scj/7 scj/8 scj,scr/6 RCJ | tll/3 tll/3 tll/3 tll/3 | RER | 6 7 8 ser/9 .fi .LP .RS The states in which the Timer is running are identifiable by the presence of TO events. Only the Send-Configure-Request and Send-Terminate-Request actions start or re-start the Timer. The Timer SHOULD be stopped when transitioning from any state where the Timer is running to a state where the Timer is not running. .RE Bill Simpson From ietf-ppp-request@ucdavis.ucdavis.edu Thu Dec 12 01:46:45 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02877; Thu, 12 Dec 91 01:30:30 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02745; Thu, 12 Dec 91 01:28:36 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA29188; Thu, 12 Dec 91 04:27:11 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9112120927.AA29188@vela.acs.oakland.edu> Subject: Re: No Passive FSA To: bsimpson@vela.acs.oakland.edu (bsimpson) Date: Thu, 12 Dec 91 4:27:10 EST Cc: ietf-ppp@ucdavis.edu, foxcj@nsco.network.com, fujisawa@sm.sony.co.jp In-Reply-To: ; from "bsimpson" at Dec 12, 91 3:53 am X-Mailer: ELM [version 2.3 PL11] There is one fairly minor change from 1171 which I would like to single out. That is the TO event in the Ack-Sent state. In 1171, all TO go to Req-Sent. There was a bit of traffic here awhile ago that wanted to know whether we could "remember" that the other end is half-open. After much head scratching, and hours of staring at the FSA (expanding and contracting it, and so forth), I have concluded that it doesn't seem to be absolutely necessary to go back to Req-Sent. Instead, just leave it in Ack-Sent. If the other end missed getting the Ack, it'll retry. This should cause 1 less timeout when a packet is dropped. This should also go partway to fixing FTP Software's interoperability problems with callee's who active open. If anyone can see why we have to stick with 1171 here, give a holler. Many thanks to Craig Fox for bringing this up at IETF, and arguing with me long enough to get the idea through my thick skull. Bill Simpson From ietf-ppp-request@ucdavis.ucdavis.edu Thu Dec 12 14:49:07 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA24142; Thu, 12 Dec 91 14:16:57 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA23851; Thu, 12 Dec 91 14:08:43 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA03761; Thu, 12 Dec 91 14:06:42 PST Date: Thu, 12 Dec 91 14:06:42 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9112122206.AA03761@ray.lloyd.com> To: gvaudre@NRI.Reston.VA.US Cc: ietf-ppp@ucdavis.edu In-Reply-To: Greg Vaudreuil's message of Wed, 11 Dec 91 11:45:32 -0500 <9112111145.aa11899@NRI.NRI.Reston.VA.US> Subject: PPP documents. The IPCP draft you have just received from Glenn McGregor is the final draft. There are not going to be any changes. Please post an announcement that the draft is available for review for a period of two weeks. The LCP draft is being modifed by Bill Simpson. He has been held up for a few days as a result of some of his equipment becoming lost in shipment. The new LCP draft should be along in about a week. That will give Bill time to complete the draft, post it to the ietf-ppp working group mailing list for last minute comments, and then give it to you for posting as an internet draft. It too will be a final document. The PPP authentication document will follow shortly on the heels of the LCP document. The hope is to have all this out of the way and to have RFC numbers assigned by the end of the year. 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 Dec 12 18:18:29 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA01088; Thu, 12 Dec 91 18:01:08 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Sun.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00910; Thu, 12 Dec 91 17:57:13 -0800 Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA12123; Thu, 12 Dec 91 17:55:33 PST Received: from sparky.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA06220; Thu, 12 Dec 91 10:21:40 PST Received: from owl.Eng.Sun.COM by sparky.Eng.Sun.COM (4.1/SMI-4.1) id AA14275; Thu, 12 Dec 91 10:21:35 PST Date: Thu, 12 Dec 91 10:21:35 PST From: cjr@sparky.Eng.Sun.COM (Jerry Chen) Message-Id: <9112121821.AA14275@sparky.Eng.Sun.COM> To: ietf-ppp@ucdavis.edu Subject: a question about RFC 1171 On page 13, the table shows that if the state is 7 (closing) and the event is passive open, then the resulting state should be state 3 (Req-Sent). Of course, the context also mentions that we need to wait until the state would normally transit to the closed state before going to any other state. It seems to me that we should go to state 2 (listen) since passive open does not imply a configure-request should be sent. The table also says that the action for the event PO on state 7 is sta(send terminate ack), not scr(send configure req). Am I missing something? Please enlighten me. Thanks. Jerry Chen From ietf-ppp-request@ucdavis.ucdavis.edu Fri Dec 13 06:15:37 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA15928; Fri, 13 Dec 91 06:01:35 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from NRI.RESTON.VA.US by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA15817; Fri, 13 Dec 91 05:57:19 -0800 Received: from NRI.NRI.Reston.Va.US by NRI.NRI.Reston.VA.US id aa07948; 13 Dec 91 8:53 EST To: brian@lloyd.com Cc: gvaudre@NRI.Reston.VA.US, ietf-ppp@ucdavis.edu Subject: Re: PPP documents. In-Reply-To: Your message of "Thu, 12 Dec 91 14:06:42 PST." <9112122206.AA03761@ray.lloyd.com> Date: Fri, 13 Dec 91 08:53:51 -0500 From: Greg Vaudreuil Message-Id: <9112130853.aa07948@NRI.NRI.Reston.VA.US> Brian, I eagerly await the second document (LCP) from Bill Simpson. When I receive it, I will send out a "last call" for comments. After some (presumably short) time after the last call period, the IESG will issue a recommendation to the IAB. The IAB will then consider the documents, and presumably make them proposed standards. A short time after this action, the RFC editor will issue an RFC number and publish the RFC. It is unlikely that a new RFC number will be assigned this year. Given the holidays, and the several steps in the process left to complete, I would expect the documents to be published as RFC's sometime in Mid-January. Greg Vaudreuil From ietf-ppp-request@ucdavis.ucdavis.edu Fri Dec 13 12:14:38 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA25333; Fri, 13 Dec 91 11:48:04 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from azea.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA25003; Fri, 13 Dec 91 11:36:47 -0800 Received: by azea.clearpoint.com (4.1/1.34) id AA03332; Fri, 13 Dec 91 14:30:33 EST Date: Fri, 13 Dec 91 14:30:33 EST From: martillo@azea.clearpoint.com (Joachim Martillo @ azea) Message-Id: <9112131930.AA03332@azea.clearpoint.com> To: vjs@rhyolite.wpd.sgi.com Cc: olling@taeko.jnoc.go.jp, news.comp.protocols.ppp@rhyolite.wpd.sgi.com, ietf-ppp@ucdavis.edu, martillo@azea.clearpoint.com In-Reply-To: Vernon Schryver's message of Sun, 8 Dec 91 12:15:59 -0800 <9112082015.AA28241@rhyolite.wpd.sgi.com> Subject: SLIP throughput on T2500 > On 7 Dec 91 20:04:11 GMT in comp.protocols.ppp, you wrote: > >One of these newsgroups is comp.protocols.ppp. PPP is different from SLIP. > In these groups, it's interesting reading about these two, but is there > anything I can find (via ftp or otherwise) that backs up a level and says > what ppp and slip *do* and why one might be better suited for a particular > application than another? > Thanks in advance, > Clifford Olling Japan National Oil Corporation ~~$@@PL}8xCD~~(J So, here's my attempt: -PPP is full featured point-to-point protocol intended to link routers over high speed sync. lines as well as hosts over async modems. PPP includes IP address assignment mechanisms, HDLC style checksums, authentication gadgets, connection re-establishment mechanisms, mechanisms to negotiate mutually agreed subsets, support for reduced character sets, support for many non-IP protocols, and other things. A single "protocol" which includes all this random stuff in the manner of PPP is more correctly described as a hodge-podge than as fully featured. Also, PPP is perhaps more correctly described as a link-layer encapsulation than as a link-layer protocol. Link layer protocols like ethernet for example have a frame format, a medium access arbitration procedure and a method for path selection between end hosts attached to the link layer. Now, one could argue that PPP does provide for extremely trivial medium access arbitration (there are separate receive and transmit circuits) and that PPP provides trivial path selection (there is but one path to select), but considering PPP anything more than a link-layer encapsulation with delusions of being a protocol is really pushing it. -I think the great advantage of PPP is the hope that wide area router vendors will adopt it, allowing us to mix and match router vendors on a single dedicated line. There is evidence not all router vendors consider this desirable. This statement is simply unfair. Router (bridge and hybrid router) vendors do not necessarily consider interoperability across point to point links a bad feature to offer. PPP is the feature which is less than desirable as an offering. If more than one type of routable traffic needs to be interconnected across a WAN link, putting a multiprotocol router which supports PPP at both ends of the WAN link is a silly way to achieve wide area interconnection between two geographically distant sites. What happens if there is network traffic which the routers can't route? Do you go to the router vendor and ask for an upgrade for which he will charge you? And of course, he might not even have an upgrade to sell to you. Of course, there is the solution which several hybrid router vendors supply which is to route all routable traffic and to bridge all other traffic. Such a solution (the parallel router filtering bridge) breaks boths the DOD Internet Architecture and the ISO OSI architecture, and can easily lead to the creation of network topologies which neither route nor bridge correctly. PPP (and MPI/FR) by incorrectly treating MAC frames and Network Packets as operating at the same protocol layer is actually designed to break both the DOD Internet Architecture and the ISO OSI architecture in the same way that the parallel router filtering bridge breaks these architectures. -The main disadvantage of SLIP is its simplicity. If you want more than IP over a modem, you must roll your own protocol. Its simplicity has also encouraged the appearance of incompatible extensions. Actually, SLIP does one thing and does it right. A similar claim cannot be made about PPP. There is no evidence in the RFCs relating to PPP (and MPI/FR)that the designers ever truly chose one thing to do right. The problem of Wide-Area interconnect actually refers to three quite separate problems. 1) One problem is point-to-point end host connectivity, which SLIP provides very well between two IP end hosts, an IP end host and an IP router or between two IP routers. 2) The second problem is providing universal end host interconnect, which X.25 networks provides between terminals and computers at remote sites. 3) The third problem is providing universal subnetwork interconnect, which is basically what the ARPANET used to provide, and what NSFNET and other wide area provides provide unfortunately only in the context of IP. PPP never really addresses any of these problems explicitly and as a consequence rather botches as a solution to any of them. In fact since PPP provides no means of path selection of multiple wide area hops or between alternate routes among wide area hops, PPP cannot provide any solution to the third problem at all. In view of the general trend of network evolution, the third problem is really the problem which customers want solved and in fact is the problem which router vendors address with their products. So there really should be no surprise that router (bridge and hybrid bridge router) vendors are less than interested in PPP. SLITHERNET is a hack but unlike PPP really does address the third problem which is essentially the provision of a wide area switching fabric communications subnet with alternate routing and fault tolerance capabilities (with correct network topology design). SLITHER-F and SLITHER-X provide the same capabilities on frame relay and X.25 networks. In fact, a box which supports SLITHERNET, SLITHER-X and SLITHER-F provides transparent interworking between point-to-point leased, X.25 networks and Frame Relay networks. Thus by concentrating on solving the third problem correctly, SLITHERNET solves problems 1 and 2 (these problems are degenerate cases of problem 3) as well as the interworking problem which many network managers face now or in the near future. Now I would be willing to experiment with interoperability with the products of other vendors that use either SLITHERNET or some similar correctly defined link-layer protocol (assuming the similar protocol is not tremendously difficult to implement). But PPP is essentially a non-starter except as a solution for some very specific topologically trivial problems of low speed asynchronous interconnect. Vernon Schryver, vjs@sgi.com Joachim Carlo Santos Martillo Ajami (martillo@azea.clearpoint.com) From ietf-ppp-request@ucdavis.ucdavis.edu Fri Dec 13 20:15:47 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA08809; Fri, 13 Dec 91 20:00:44 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [130.57.4.1] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA08545; Fri, 13 Dec 91 19:51:56 -0800 Received: from na.novell.com by newsun.novell.com (4.1/smi4.1.1) id AA24266; Fri, 13 Dec 91 19:46:00 PST Received: by na.novell.com (4.1/SMI-4.1) id AA08332; Fri, 13 Dec 91 19:50:03 PST Date: Fri, 13 Dec 91 19:50:03 PST From: jthomas@na.novell.com (Bill Thomas) Message-Id: <9112140350.AA08332@na.novell.com> To: ietf-ppp@ucdavis.edu Subject: questions about latest PPP FSM To: Some Kind Person How Will Give Me a Clue From: Bill Thomas Subject: Questions on Latest & Greatest PPP FSM Why is event RCA & state Ack)Rcvd not scr/7 ? The Resuming state escapes me. I see that it is reached only via event O & state Closing & transitions to either Closed Up or Listening on RTR, TOm. Does this mean that we have to get the O event up just right(before a RTR or TOm) to divert the FSM to Resuming? From ietf-ppp-request@ucdavis.ucdavis.edu Fri Dec 13 20:45:51 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA09530; Fri, 13 Dec 91 20:30:34 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA09219; Fri, 13 Dec 91 20:19:44 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA04609; Fri, 13 Dec 91 20:16:37 PST Date: Fri, 13 Dec 91 20:16:37 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9112140416.AA04609@ray.lloyd.com> To: martillo@azea.clearpoint.com Cc: vjs@rhyolite.wpd.sgi.com, olling@taeko.jnoc.go.jp, news.comp.protocols.ppp@rhyolite.wpd.sgi.com, ietf-ppp@ucdavis.edu, martillo@azea.clearpoint.com In-Reply-To: martillo@azea.clearpoint.com (Joachim Martillo's message of Fri, 13 Dec 91 14:30:33 EST <9112131930.AA03332@azea.clearpoint.com> Subject: SLIP throughput on T2500 Sr. Joachim Carlo Santos Martillo Ajami, Again you rant that PPP is broken. I respect your opinion. However, I am beginning to become annoyed that you have, once again, transmitted a message to the same group who have heard your complaints before -- repeatedly. I have taken time to talk with you (at Interop) and tried to explain how PPP will work for both routers and bridges. I attempted to explain how a device may negotiate with its peer which NCPs it will use (transmission of MAC layer packets for bridging included), and how a device can force its peer to perform routing, bridging, or both, using the same link. You would not listen. As for PPP being an encapsulation, it is. As for being a protocol, it is that too. A protocol describes a way to do something. It is very clear what the process is for bringing up a link and then negotiating what you wish to send over it. Now I will ask you again: please participate in the PPP specification process in a productive manner or please leave us alone. We are trying to get work done and you continue to joggle our collective elbow. 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 Fri Dec 13 21:15:42 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA09991; Fri, 13 Dec 91 21:00:39 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from azea.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA09768; Fri, 13 Dec 91 20:45:31 -0800 Received: by azea.clearpoint.com (4.1/1.34) id AA03559; Fri, 13 Dec 91 23:39:19 EST Date: Fri, 13 Dec 91 23:39:19 EST From: martillo@azea.clearpoint.com (Joachim Martillo @ azea) Message-Id: <9112140439.AA03559@azea.clearpoint.com> To: brian@lloyd.com Cc: vjs@rhyolite.wpd.sgi.com, olling@taeko.jnoc.go.jp, news.comp.protocols.ppp@rhyolite.wpd.sgi.com, ietf-ppp@ucdavis.edu In-Reply-To: Brian Lloyd's message of Fri, 13 Dec 91 20:16:37 PST <9112140416.AA04609@ray.lloyd.com> Subject: SLIP throughput on T2500 Date: Fri, 13 Dec 91 20:16:37 PST From: brian@lloyd.com (Brian Lloyd) Reply-To: brian@lloyd.com Sr. Joachim Carlo Santos Martillo Ajami, Again you rant that PPP is broken. I respect your opinion. However, I am beginning to become annoyed that you have, once again, transmitted a message to the same group who have heard your complaints before -- repeatedly. I posted the message specifically because Schryver implied that router vendors (we are about to become one) are not implementing PPP because they somehow object to providing the capability to mix and match their products and the products of competitors on point to point links. This insinuation merited a rebuttal. Router vendors have legitimate problems with PPP. I have taken time to talk with you (at Interop) and tried to explain how PPP will work for both routers and bridges. I attempted to explain how a device may negotiate with its peer which NCPs it will use (transmission of MAC layer packets for bridging included), and how a device can force its peer to perform routing, bridging, or both, using the same link. You would not listen. I did listen. You simply do not understand the DOD Internet Architecture or the ISO OSI model. Treating a MAC protocol as a peer with Network protocols (as PPP and MPI/FR do) breaks the architectures and causes routing anomalies at layer 2 and layer 3. As for forcing a peer to send only MAC frames on a link, this is only possible if implementations of PPP are obligated to have the capability to transmit full MAC frames. As far as I can tell, this requirement has not been made. And by the way if all devices which support PPP implement the ability to transmit MAC frames, this brain-dead reject mechanism only guarantees that the router will cease to transmit rejected network packets, the mechanism does not guarantee that the device *will* transmit rejected network packets as MAC encapsulated frames which will be accepted. As for PPP being an encapsulation, it is. As for being a protocol, it is that too. A protocol describes a way to do something. If you consider flag framing on an HDLC link a networking protocol, then PPP is a networking protocol. From the standpoint of moderate to high speed synchronous links PPP is simply an extended and broken version of flag framing which most people consider simply an encapsulation. It is very clear what the process is for bringing up a link and then negotiating what you wish to send over it. Now I will ask you again: please participate in the PPP specification process in a productive manner or please leave us alone. We are trying to get work done and you continue to joggle our collective elbow. Have a meeting in the Boston or Worcester area and I will come. I don't like to travel and travel as little as I can, and still travel too much for my tastes. Brian Lloyd, WB6RQN Lloyd & Associates Joachim Carlo Santos Martillo Ajami From ietf-ppp-request@ucdavis.ucdavis.edu Fri Dec 13 22:01:13 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10813; Fri, 13 Dec 91 21:46:04 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SGI.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10670; Fri, 13 Dec 91 21:38:38 -0800 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (911016.SGI/910110.SGI) for ietf-ppp@ucdavis.edu id AA22974; Fri, 13 Dec 91 21:36:32 -0800 Received: by rhyolite.wpd.sgi.com (911016.SGI/911001.SGI) for @sgi.sgi.com:brian@lloyd.com id AA00793; Fri, 13 Dec 91 21:36:30 -0800 Date: Fri, 13 Dec 91 21:36:30 -0800 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9112140536.AA00793@rhyolite.wpd.sgi.com> To: martillo@azea.clearpoint.com, brian@lloyd.com Subject: Re: SLIP throughput on T2500 Cc: ietf-ppp@ucdavis.edu > From martillo@azea.clearpoint.com Fri Dec 13 20:44:24 1991 > > I posted the message specifically because Schryver implied that router > vendors (we are about to become one) are not implementing PPP because > they somehow object to providing the capability to mix and match their > products and the products of competitors on point to point links. > > This insinuation merited a rebuttal. Router vendors have legitimate > problems with PPP. > ... I hoped my statement was more direct than an insinuation. Your rebuttal was insufficient. I've drawn conclusions about router vendor intentions, based on facts and logic. After years, the only router vendor PPP implementation of which I've heard public mention is Cisco's minimal one. The logic was that the router market is such that most customers have minimized the vendors they deal with, in part because of the lack of a common standard. Current large router vendors who implement any common protocol are not going to increase their penetration of any single customer, but would make it easier for competators to sell to their existing customers. As long as all of the big router vendors continue to not make PPP their primary, best supported, fastest protocol, they protect their customer base and do not seem to be bad guys, since "no one is shipping it." There is nothing illegal, fattening, immoral, or wrong in this strategy. It would be at best naive to claim such considerations never occurred to the big router vendors (or the small ones). There may be other considerations which will overcome these. We'll all know 30 days after that happens, because they'll be advertising the delivery dates of their implementations, whether of PPP or any other common protocol. Actually, I bet we'll hear sooner, because I think many of the router vendors have PPP implementations, which they'll push as soon as it makes marketting sense. Everyone has "legitimate problems" with everything. Given a good enough protocol, such "problems" are not the primary considerations in what to implement and sell. It is likely that everyone on the mailing list considers PPP "broken." What isn't broken? What is there that could not be done better by any of us, if we only had the time, inclination, and political power? > I did listen. You simply do not understand the DOD Internet > Architecture or the ISO OSI model. Treating a MAC protocol as a peer > with Network protocols (as PPP and MPI/FR do) breaks the architectures I'm sick unto anger with people who argue by layers. Layering is an important intellectual tool, along with Turing machines, P vs. NP, and prohibitions against GOTO's. Only those who produce slow and broken implementations use the "DOD Internet Architecture" as implementation models. The history of the "DOD Internet" protocols is one of intentional violations of preceding versions of the "Architecture". Who today argues against header compression, header predicting, slow start, and RTT measuring? Consider FDDI. Those who believe the standards are implementation models get at most 50% and often only 20% of the performance of the several groups who treat the standards as Turing machine descriptions or black-box models. Speaking of marketting sense, I bet this mailing list reaches most of the people in the world who might buy, either figuratively or literally, an alternative to PPP. An alternative to PPP would have to be sold here, to IEEE, or ANSI. If I had such an alternative, I'd talk nice or not at all to all of the PPP fans, no matter how stupid or ignorant of their own protocols I thought them. Vernon Schryver, vjs@sgi.com From ietf-ppp-request@ucdavis.ucdavis.edu Sat Dec 14 12:46:45 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA28038; Sat, 14 Dec 91 12:30:21 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA27818; Sat, 14 Dec 91 12:21:08 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA04737; Sat, 14 Dec 91 12:17:59 PST Date: Sat, 14 Dec 91 12:17:59 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9112142017.AA04737@ray.lloyd.com> To: martillo@azea.clearpoint.com Cc: vjs@rhyolite.wpd.sgi.com, olling@taeko.jnoc.go.jp, news.comp.protocols.ppp@rhyolite.wpd.sgi.com, ietf-ppp@ucdavis.edu In-Reply-To: martillo@azea.clearpoint.com (Joachim Martillo's message of Fri, 13 Dec 91 23:39:19 EST <9112140439.AA03559@azea.clearpoint.com> Subject: SLIP throughput on T2500 Date: Fri, 13 Dec 91 23:39:19 EST From: martillo@azea.clearpoint.com (Joachim Martillo @ azea) I posted the message specifically because Schryver implied that router vendors (we are about to become one) are not implementing PPP because they somehow object to providing the capability to mix and match their products and the products of competitors on point to point links. This insinuation merited a rebuttal. Router vendors have legitimate problems with PPP. Funny, the router vendors with whom I am familiar are all working toward a full implementation of PPP. Within this group I include 3Com, cisco, Wellfleet, Network System, and Proteon. Some have working versions of PPP and some are still working toward that goal. I do not think that the router vendors are holding back nor has anyone complained that PPP is unable to meet their needs (with the exception of you). I did listen. You simply do not understand the DOD Internet Architecture or the ISO OSI model. Treating a MAC protocol as a peer with Network protocols (as PPP and MPI/FR do) breaks the architectures and causes routing anomalies at layer 2 and layer 3. I suspect that I understand layering as well as you. I also understand when rigid adherence to the OSI layering model is counter productive (vis a vis Internet model having its layers and interfaces at a different place from the ISO model). The key here is functionallity, not rigidity. I could quote Padlipsky at you but I suspect the reference would be lost. As for forcing a peer to send only MAC frames on a link, this is only possible if implementations of PPP are obligated to have the capability to transmit full MAC frames. As far as I can tell, this requirement has not been made. Nor should it. A few people want to bridge at the MAC layer. Many people want to route at the Network layer, and still more want to route at the Internetwork layer. It is up to the administrator to make that judgement as to how his/her network will operate. The beauty of PPP is that it will permit the administrator to make that decision and continue to use the same link protocol. And by the way if all devices which support PPP implement the ability to transmit MAC frames, this brain-dead reject mechanism only guarantees that the router will cease to transmit rejected network packets, the mechanism does not guarantee that the device *will* transmit rejected network packets as MAC encapsulated frames which will be accepted. Again, this is a configuration issue. The administrator gets to choose. The mechanism ensures that one side tells the other what it is willing to accept. If the administrator chooses not to accept a particular NCP, he can tell his router to reject that particular NCP. Multiprotocol routers are a fact of life. There is a lot of configuration that goes into a multiprotocol router/bridge to get it to do precisely what the administrator wishes it to do. PPP is an attempt to allow as much flexibility as possible without unnecessarily forcing an administrator to do things one particular way. If you consider flag framing on an HDLC link a networking protocol, then PPP is a networking protocol. From the standpoint of moderate to high speed synchronous links PPP is simply an extended and broken version of flag framing which most people consider simply an encapsulation. It matters not what you call it. It works. May I point out that Frame Relay is essentially the removal of the link layer "enhancements" of X.25. Does that mean that Frame Relay is not a networking protocol or that it serves no useful purpose? Now I will ask you again: please participate in the PPP specification process in a productive manner or please leave us alone. We are trying to get work done and you continue to joggle our collective elbow. Have a meeting in the Boston or Worcester area and I will come. I don't like to travel and travel as little as I can, and still travel too much for my tastes. Much of the work on PPP takes place on the ietf-ppp mailing list (ietf-ppp@ucdavis.edu). If you need a particular feature please participate. We welcome your CONSTRUCTIVE input. As for your desire not to travel, that is your problem, not mine. Do not blame us for your dislikes and/or phobias. We encourage you to meet with us at the upcoming IETF meeting and/or participate constructively in the discussions on the ietf-ppp mailing list. Joachim Carlo Santos Martillo Ajami 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 Sun Dec 15 00:43:58 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10768; Sun, 15 Dec 91 00:17:10 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10636; Sun, 15 Dec 91 00:11:50 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA17826; Sun, 15 Dec 91 03:10:25 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9112150810.AA17826@vela.acs.oakland.edu> Subject: third pass FSA To: ietf-ppp@ucdavis.edu Date: Sun, 15 Dec 91 3:10:23 EST X-Mailer: ELM [version 2.3 PL11] Last night, I spent 6.5 hours talking with McGregor about PPP. He raised the issue that we haven't specified error recovery well enough. Here are some expanded states to cover errors. Also, some of the transitions that are appropriate for dial-up lines are meaningless for dedicated lines. I have flagged a few implementation options. I think that it is better (since people are going to do them anyway) to have the options well defined. Also, he wanted to know explicitly where all of the layer up/down signals are in the machine. Since this was similar to the mandate at the last IETF, I have have added 3 more actions. Finally, the new state names were confusing. I changed them so that they are more unique. Keep those questions coming, folks. Bill Simpson Events Actions U = lower layer is Up llu = Lower-Layer-Up D = lower layer is Down lld = Lower-Layer-Down O = Open ulu = Upper-Layer-Up C = Close uld = Upper-Layer-Down TO+ = Timeout with counter > 0 TO- = Timeout with counter expired RCR+ = Receive-Configure-Request (Good) scr = Send-Configure-Request RCR- = Receive-Configure-Request (Bad) RCA = Receive-Configure-Ack sca = Send-Configure-Ack RCN = Receive-Configure-Nak/Rej scn = Send-Configure-Nak/Rej RTR = Receive-Terminate-Request str = Send-Terminate-Request RTA = Receive-Terminate-Ack sta = Send-Terminate-Ack RUC = Receive-Unknown-Code scj = Send-Code-Reject RXJ+ = Receive-Code-Reject (permitted) or Receive-Protocol-Reject RXJ- = Receive-Code-Reject (catastrophic) or Receive-Protocol-Reject RXR = Receive-Echo-Request ser = Send-Echo-Reply or Receive-Echo-Reply or Receive-Discard-Request .fi .RE .bp .Nh 2 State Transition Table .LP .RS The complete state transition table follows. States are indicated horizontally, and events are read vertically. State transitions and actions are represented in the form action/new-state. Multiple actions are separated by commas, and may continue on succeeding lines as space requires. The state may be followed by a letter, which indicates an explanatory footnote. .LP .RS Historical Note: In previous versions of this table, a simplified non-deterministic finite-state automaton was used, with considerable detailed information specified in the semantics. This lead to interoperability problems from differing interpretations. .LP This table functions similarly to the previous versions, with the up/down flags expanded to explicit states, and the active/passive paradigm eliminated. It is believed that this table interoperates with previous versions better than those versions themselves. .RE .RE .LP .nf | State | 0 1 2 3 4 5 Events| Initial Starting Closed Stopped Closing Stopping ------+----------------------------------------------------------- U | 2 scr/6 - - - - D | - - 0 1 0 1 O | llu/1 1 scr/6 3m 5m 5 C | 0 0 2 2 4 4 | TO+ | - - - - str/4 str/5 TO- | - - - - lld/2 lld/3 | RCR+ | - - sta/2 sta/3 4 5 | (scr,sca/8p) RCR- | - - sta/2 sta/3 4 5 | (scr,scn/6p) RCA | - - sta/2 sta/3 4 5 RCN | - - sta/2 sta/3 4 5 | RTR | - - sta/2 sta/3 sta/4 sta/5 RTA | - - 2 3 lld/2 lld/3 | RUC | - - scj/2 scj/3 scj/4 scj/5 RXJ+ | - - sta/2 sta/3 4 5 RXJ- | - - lld/2 lld/3 lld/2 lld/3 | RXR | - - sta/2 sta/3 4 5 .fi .bp .nf | State | 6 7 8 9 Events| Req-Sent Ack-Rcvd Ack-Sent Opened ------+----------------------------------------- U | - - - - D | 1 1 1 uld/1 O | 6 7 8 uld/9m C | str/4 str/4 str/4 uld,str/4 | TO+ | scr/6 scr/6 scr/8 - TO- | lld/3p lld/3p lld/3p - | RCR+ | sca/8 sca,ulu/9 sca/8 uld,scr,sca/8 RCR- | scn/6 scn/7 scn/6 uld,scr,scn/6 RCA | 7 scr/6x ulu/9 uld,scr/6x RCN | scr/6 scr/6x scr/8 uld,scr/6x | RTR | sta/6 sta/6 sta/6 uld,sta,lld/3 RTA | 6 6 8 uld,scr/6 | RUC | scj/6 scj/7 scj/8 uld,scj,scr/6 RXJ+ | 6 6 8 uld,scr/6 RXJ- | lld/3 lld/3 lld/3 uld,str/4 | RXR | 6 7 8 ser/9 .fi .LP .RS The states in which the Timer is running are identifiable by the presence of TO events. Only the Send-Configure-Request and Send-Terminate-Request actions start or re-start the Timer. The Timer SHOULD be stopped when transitioning from any state where the Timer is running to a state where the Timer is not running. .LP .IP [m] 6 Multiple Open events option; see Open event discussion. .IP [p] 6 Passive Open option; see Stopped state discussion. .IP [x] 6 Crossed connection discussion; see RCA event discussion. .RE From ietf-ppp-request@ucdavis.ucdavis.edu Sun Dec 15 00:53:12 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10997; Sun, 15 Dec 91 00:30:21 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10782; Sun, 15 Dec 91 00:19:40 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA17858; Sun, 15 Dec 91 03:17:57 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9112150817.AA17858@vela.acs.oakland.edu> Subject: Re: `-' illegal events in new FSM To: bsimpson@vela.acs.oakland.edu (Bill Simpson) Date: Sun, 15 Dec 91 3:17:54 EST Cc: karl@morningstar.com, ietf-ppp@ucdavis.edu In-Reply-To: <9112140004.AA00988@vela.acs.oakland.edu>; from "Bill Simpson" at Dec 13, 91 7:04 pm X-Mailer: ELM [version 2.3 PL11] I recant! I recant! I had a long talk with McGregor. He pointed out that the RCA or RCN in the Opened state could come from a switched link which misconfigures in the middle of negotiation. Pretty far-fetched, but just the kind of defensive thinking we need. I'm going back to 1171 on those items. See the latest FSA draft. Thanks for bringing it up! Bill Simpson From ietf-ppp-request@ucdavis.ucdavis.edu Sun Dec 15 01:00:05 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA11256; Sun, 15 Dec 91 00:47:05 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA11143; Sun, 15 Dec 91 00:43:10 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA18057; Sun, 15 Dec 91 03:41:28 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9112150841.AA18057@vela.acs.oakland.edu> Subject: Re: questions about latest PPP FSM To: jthomas@na.novell.com (Bill Thomas) Date: Sun, 15 Dec 91 3:41:26 EST Cc: ietf-ppp@ucdavis.edu In-Reply-To: <9112140350.AA08332@na.novell.com>; from "Bill Thomas" at Dec 13, 91 7:50 pm X-Mailer: ELM [version 2.3 PL11] > > Why is event RCA & state Ack)Rcvd not scr/7 ? > It shouldn't be scr/7, but I made it scr/6 (see recant in earlier message). I had thought it was completely illegal. It turns out to very complicated. > The Resuming state escapes me. I see that it is reached only via event O > & state Closing & transitions to either Closed Up or Listening on RTR, > TOm. > > Does this mean that we have to get the O event up just right(before a > RTR or TOm) to divert the FSM to Resuming? > The Resuming (now the Stopping) state is one (of several) states left out of the old design. These states became more evident when expanding the non-deterministic FSA to a deterministic FSA model. If you are Closing because of Authentication failure, or some other catastrophic failure, you need to guarantee that the link actually finished termination and disconnected. However, it is perfectly legal to issue the Open command without actually waiting for the Close to finish. By its very nature, the Close takes time to send the T-R packet, and receive the T-A reply. Therefore, under the 1171 FSA, it is possible to infinite loop. You Open, configure, fail authentication, Close, Open, configure, etc. The desired path is now Opened -> Closing -> Stopping -> Stopped -> Starting. Events: Close Open T-A Down Got that? Thanks for asking! Bill Simpson From ietf-ppp-request@ucdavis.ucdavis.edu Sun Dec 15 11:00:07 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA20128; Sun, 15 Dec 91 10:45:13 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from sol.sura.net by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA19999; Sun, 15 Dec 91 10:35:09 -0800 Received: from localhost.sura.net by sol.sura.net with SMTP (5.65+/($Id: sendmail.cf,v 1.19 1991/07/18 01:38:01 jmalcolm Exp $)) id AA24536; Sun, 15 Dec 91 13:31:05 -0500 Message-Id: <9112151831.AA24536@sol.sura.net> To: Bob Sutterfield Cc: vjs@rhyolite.wpd.sgi.com, martillo@azea.clearpoint.com, brian@lloyd.com, ietf-ppp@ucdavis.edu, oleary@sura.net Subject: Re: PPP market penetration (was: SLIP throughput on T2500) In-Reply-To: Your message of Sat, 14 Dec 91 14:49:03 -0500. <9112141949.AA10033@volitans.morningstar.com> Date: Sun, 15 Dec 91 13:31:04 EST From: oleary@sura.net The folks at Wellfleet that we talk to tell us that they should be shipping synch. PPP for their routers Real Soon Now. The IETF meeting for Summer, 1992 (probably August) is scheduled for Boston. dave From ietf-ppp-request@ucdavis.ucdavis.edu Sun Dec 15 15:00:31 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA24720; Sun, 15 Dec 91 14:45:44 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA24599; Sun, 15 Dec 91 14:41:59 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA05199; Sun, 15 Dec 91 14:38:52 PST Date: Sun, 15 Dec 91 14:38:52 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9112152238.AA05199@ray.lloyd.com> To: gvaudre@NRI.Reston.VA.US Cc: gvaudre@NRI.Reston.VA.US, ietf-ppp@ucdavis.edu In-Reply-To: Greg Vaudreuil's message of Fri, 13 Dec 91 08:53:51 -0500 <9112130853.aa07948@NRI.NRI.Reston.VA.US> Subject: PPP documents. OK, so we don't make the end of the year. At least we can proceed pretty quickly and put this one to rest. It has been a LONG time. 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 Dec 16 16:36:34 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA29577; Mon, 16 Dec 91 16:29:54 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Mail.Think.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA29195; Mon, 16 Dec 91 16:14:26 -0800 Return-Path: Received: from Think.COM by mail.think.com; Mon, 16 Dec 91 19:12:56 -0500 Received: from signet.UUCP by Early-Bird.Think.COM; Mon, 16 Dec 91 19:12:54 EST Received: from sigma17.signet.UUCP by signet.UUCP (4.0/SMI-4.0) id AA00552; Mon, 16 Dec 91 14:05:06 EST Date: Mon, 16 Dec 91 14:05:06 EST From: signet!gloria@Think.COM (Hwae-wen Gloria Liu) Message-Id: <9112161905.AA00552@signet.UUCP> To: ietf-ppp@ucdavis.edu Subject: Public PPP code Can anyone send me the latest PPP code from the public domain? I don't have FTP to retrieve files from the Net. Thanks! Gloria Liu Sigma Network Systems Reading, MA think!signet!gloria (617) 942-0200 ext. 109 From ietf-ppp-request@ucdavis.ucdavis.edu Mon Dec 16 21:31:28 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA06412; Mon, 16 Dec 91 21:15:56 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA06153; Mon, 16 Dec 91 21:04:26 -0800 Received: from roughy.morningstar.com by volitans.morningstar.com (5.65a/91111501) id AA15940; Tue, 17 Dec 91 00:02:53 -0500 Received: by roughy.morningstar.com (5.65a/910712902) id AA06371; Tue, 17 Dec 91 00:02:49 -0500 Date: Tue, 17 Dec 91 00:02:49 -0500 From: Bob Sutterfield Message-Id: <9112170502.AA06371@roughy.morningstar.com> To: signet!gloria@Think.COM Cc: ietf-ppp@ucdavis.edu In-Reply-To: Hwae-wen Gloria Liu's message of Mon, 16 Dec 91 14:05:06 EST <9112161905.AA00552@signet.UUCP> Subject: Public PPP code Date: Mon, 16 Dec 91 14:05:06 EST From: signet!gloria@Think.COM (Hwae-wen Gloria Liu) Can anyone send me the latest PPP code from the public domain? I don't have FTP to retrieve files from the Net. I don't know of any PPP software that's in the public domain; most of what you probably want is copyrighted by its various authors, but freely available. If you don't have FTP access, you can get the latest KA9Q and SunOS 4.1 PPP sources (and some other stuff too) via anonymous UUCP from osu-cis, and probably from uunet as well. Write to uucp@cis.ohio-state.edu or info@uunet.uu.net for instructions if you need them. From ietf-ppp-request@ucdavis.ucdavis.edu Tue Dec 17 00:23:52 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA09564; Tue, 17 Dec 91 00:00:39 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA09389; Mon, 16 Dec 91 23:54:08 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA20241; Tue, 17 Dec 91 02:52:38 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9112170752.AA20241@vela.acs.oakland.edu> Subject: fourth pass FSA with text To: ietf-ppp@ucdavis.edu Date: Tue, 17 Dec 91 2:52:37 EST X-Mailer: ELM [version 2.3 PL11] Here's the FSA, with all the state, event, action text. Please try looking at it in two passes: 1) forget you know anything about PPP. Is there anything you don't understand easily? 2) Is there anything which you have a gut feeling could be better? Bill Simpson RFC DRAFT Point-to-Point Protocol December 1991 5. The Option Negotiation Automaton The finite-state automaton is defined by events, actions and state transitions. Events include receipt of external commands such as Open and Close, expiration of the Restart timer, and receipt of packets from a peer. Actions include the starting of the Restart timer and transmission of packets to the peer. Some types of packets -- Configure-Naks and Configure-Rejects, or Code-Rejects and Protocol-Rejects, or Echo-Requests, Echo-Replies and Discard-Requests -- are not differentiated in the automaton descriptions. As will be described later, these packets do indeed serve different functions. However, they always cause the same transitions. Events Actions U = lower layer is Up ulu = Upper-Layer-Up D = lower layer is Down uld = Upper-Layer-Down O = Open llg = Lower-Layer-Go C = Close llq = Lower-Layer-Quit TO+ = Timeout with counter > 0 TO- = Timeout with counter expired RCR+ = Receive-Configure-Request (Good) scr = Send-Configure-Request RCR- = Receive-Configure-Request (Bad) RCA = Receive-Configure-Ack sca = Send-Configure-Ack RCN = Receive-Configure-Nak/Rej scn = Send-Configure-Nak/Rej RTR = Receive-Terminate-Request str = Send-Terminate-Request RTA = Receive-Terminate-Ack sta = Send-Terminate-Ack RUC = Receive-Unknown-Code scj = Send-Code-Reject RXJ+ = Receive-Code-Reject (permitted) or Receive-Protocol-Reject RXJ- = Receive-Code-Reject (catastrophic) or Receive-Protocol-Reject RXR = Receive-Echo-Request ser = Send-Echo-Reply or Receive-Echo-Reply or Receive-Discard-Request Simpson [Page 13] RFC DRAFT Point-to-Point Protocol December 1991 5.1. State Diagram The simplified state diagram which follows describes the sequence of events for reaching agreement on Configuration Options (opening the PPP link) and for later termination of the link. This diagram is not a complete representation of the automaton. Implementation MUST be done by consulting the actual state transition table. Events are in upper case. Actions are in lower case. For these purposes, the state machine is initially in the Closed state. Once the Opened state has been reached, both ends of the link have met the requirement of having both sent and received a Configure-Ack packet. RCR TO+ +-sta-+ +--------+ | | | | +-------+ | RTA +-------+ | CLOSE +-------+ | |<--+<---------| |<-str-+<------| | |Closed | |Closing| |Opened | | | OPEN | | | | | |------+ | | | | +-------+ | +-------+ +-------+ | ^ | | | +-sca----------------->+ | | | RCN,TO+ | RCR+ | RCR- RCA | RCN,TO+ +------->+ | +--------+ | +-scr-+ | | | | | | | | +-------+ | TO+ +-------+ | +-------+ | | |<-scr-+<------| |<-scn-+ | |<--+ | Req- | | Ack- | | Ack- | | Sent | RCA | Rcvd | | Sent | +-scn->| |------------->| | +-sca->| | | +-------+ +-------+ | +-------+ | RCR- | | RCR+ | RCR+ | | RCR- | | +------------------------------->+--------+ | | | | +--------+<------------------------------------------------+ Simpson [Page 14] RFC DRAFT Point-to-Point Protocol December 1991 5.2. State Transition Table The complete state transition table follows. States are indicated horizontally, and events are read vertically. State transitions and actions are represented in the form action/new-state. Multiple actions are separated by commas, and may continue on succeeding lines as space requires. The state may be followed by a letter, which indicates an explanatory footnote. Rationale: In previous versions of this table, a simplified non-deterministic finite-state automaton was used, with considerable detailed information specified in the semantics. This lead to interoperability problems from differing interpretations. This table functions similarly to the previous versions, with the up/down flags expanded to explicit states, and the active/passive paradigm eliminated. It is believed that this table interoperates with previous versions better than those versions themselves. | State | 0 1 2 3 4 5 Events| Initial Starting Closed Stopped Closing Stopping ------+----------------------------------------------------------- U | 2 scr/6 - - - - D | - - 0 llg/1 0 1 O | llg/1 1 scr/6 3r 5r 5r C | 0 0 2 2 4 4 | TO+ | - - - - str/4 str/5 TO- | - - - - llq/2 llq/3 | RCR+ | - - sta/2 scr,sca/8 4 5 RCR- | - - sta/2 scr,scn/6 4 5 RCA | - - sta/2 sta/3 4 5 RCN | - - sta/2 sta/3 4 5 | RTR | - - sta/2 sta/3 sta/4 sta/5 RTA | - - 2 3 llq/2 llq/3 | RUC | - - scj/2 scj/3 scj/4 scj/5 RXJ+ | - - 2 3 4 5 RXJ- | - - llq/2 llq/3 llq/2 llq/3 | RXR | - - 2 3 4 5 Simpson [Page 15] RFC DRAFT Point-to-Point Protocol December 1991 | State | 6 7 8 9 Events| Req-Sent Ack-Rcvd Ack-Sent Opened ------+----------------------------------------- U | - - - - D | 1 1 1 uld/1 O | 6 7 8 9r C | str/4 str/4 str/4 uld,str/4 | TO+ | scr/6 scr/6 scr/8 - TO- | llq/3p llq/3p llq/3p - | RCR+ | sca/8 sca,ulu/9 sca/8 uld,scr,sca/8 RCR- | scn/6 scn/7 scn/6 uld,scr,scn/6 RCA | 7 scr/6x ulu/9 uld,scr/6x RCN | scr/6 scr/6x scr/8 uld,scr/6x | RTR | sta/6 sta/6 sta/6 uld,sta/3 RTA | 6 6 8 uld,scr/6 | RUC | scj/6 scj/7 scj/8 uld,scj,scr/6 RXJ+ | 6 6 8 9 RXJ- | llq/3 llq/3 llq/3 uld,str/5 | RXR | 6 7 8 ser/9 The states in which the Restart timer is running are identifiable by the presence of TO events. Only the Send-Configure-Request and Send-Terminate-Request actions start or re-start the Restart timer. The Restart timer SHOULD be stopped when transitioning from any state where the timer is running to a state where the timer is not running. [p] Passive option; see Stopped state discussion. [r] Restart option; see Open event discussion. [x] Crossed connection; see RCA event discussion. Simpson [Page 16] RFC DRAFT Point-to-Point Protocol December 1991 5.3. States Following is a more detailed description of each automaton state. Initial In the Initial state, the lower layer is unavailable (Down), and no Open has occurred. The Restart timer is not running in the Initial state. Starting The Starting state is the Open counterpart to the Initial state. An administrative Open has been initiated, but the lower layer is still unavailable (Down). The Restart timer is not running in the Starting state. When the lower layer becomes available (Up), a Configure-Request is sent. Closed In the Closed state, the link is available (Up), but no Open has occurred. The Restart timer is not running in the Closed state. Upon receipt of Configure-Request packets, a Terminate-Ack is sent. Terminate-Acks are silently discarded to avoid creating a loop. Stopped The Stopped state is the Open counterpart to the Closed state. It is entered when the automaton is waiting for a Down event after the Lower-Layer-Quit action, or after sending a Terminate-Ack. The Restart timer is not running in the Stopped state. Upon receipt of Configure-Request packets, an appropriate response is sent. Upon receipt of other packets, a Terminate-Ack is sent. Terminate-Acks are silently discarded to avoid creating a loop. Rationale: The Stopped state is a junction state for link termination, link configuration failure, and other automaton failure modes. These potentially separate states have been combined. There is a race condition between the Down event response (from the Lower-Layer-Quit action) and the Receive-Configure-Request Simpson [Page 17] RFC DRAFT Point-to-Point Protocol December 1991 event. When a Configure-Request arrives before the Down event, the Down event will supercede by returning the automaton to the Starting state. This prevents attack by repetition. Implementation Option: After the peer fails to respond to Configure-Requests, an implementation MAY wait passively for the peer to send Configure-Requests. In this case, the Lower-Layer-Quit action is not used for the TO- event in states Req-Sent, Ack-Rcvd and Ack-Sent. This option is useful for dedicated circuits, or circuits which have no status signals available, but SHOULD NOT be used for switched circuits. Closing In the Closing state, an attempt is made to terminate the connection. A Terminate-Request has been sent and the Restart timer is running, but a Terminate-Ack has not yet been received. Upon receipt of a Terminate-Ack, the Closed state is entered. Upon the expiration of the Restart timer, a new Terminate-Request is transmitted and the Restart timer is restarted. After the Restart timer has expired Max-Terminate times, this action may be skipped, and the Closed state may be entered. Stopping The Stopping state is the Open counterpart to the Closing state. A Terminate-Request has been sent and the Restart timer is running, but a Terminate-Ack has not yet been received. Rationale: The Stopping state provides a well defined opportunity to terminate a link before allowing new traffic. After the link has terminated, a new configuration may occur via the Stopped or Starting states. Request-Sent In the Request-Sent state an attempt is made to configure the connection. A Configure-Request has been sent and the Restart timer is running, but a Configure-Ack has not yet been received nor has one been sent. Simpson [Page 18] RFC DRAFT Point-to-Point Protocol December 1991 Ack-Received In the Ack-Received state, a Configure-Request has been sent and a Configure-Ack has been received. The Restart timer is still running since a Configure-Ack has not yet been sent. Ack-Sent In the Ack-Sent state, a Configure-Request and a Configure-Ack have both been sent but a Configure-Ack has not yet been received. The Restart timer is always running in the Ack-Sent state. Opened In the Opened state, a Configure-Ack has been both sent and received. The Restart timer is not running in the Opened state. When entering the Opened state, the implementation SHOULD signal the upper layers that it is now Up. Conversely, when leaving the Opened state, the implementation SHOULD signal the upper layers that it is now Down. 5.4. Events Transitions and actions in the automaton are caused by events. Up (U) The Up event occurs when a lower layer indicates that it is ready to carry packets. Typically, this event is used to signal LCP that the link is entering Link Establishment phase, or used to signal a NCP that the link is entering Network-Layer Protocol phase. Down (D) The Down event occurs when a lower layer indicates that it is no longer ready to carry packets. Typically, this event is used to signal LCP that the link is entering Link Dead phase, or used to signal a NCP that the link is leaving Network-Layer Protocol phase. Open (O) The Open event indicates that the link is administratively available for traffic; that is, the network administrator (human or program) has indicated that the link is allowed to be Opened. When this event occurs, and the link is not Opened, the automaton Simpson [Page 19] RFC DRAFT Point-to-Point Protocol December 1991 attempts to send configuration packets to the peer. If the automaton is not able to begin configuration (the lower layer is Down, or a previous Close event has not completed), the establishment of the link is automatically delayed. When a Terminate-Request is received, or other events occur which cause the link to become unavailable, the automaton will progress to a state where the link is ready to re-open. No additional administrative intervention should be necessary. Implementation Note: Experience has shown that users will execute an additional Open command when they want to renegotiate the link. Since this is not the meaning of the Open event, it is suggested that when an Open user command is executed in the Opened, Closing, Stopping, or Stopped states, the implementation issue a Down event, immediately followed by an Up event. This will cause the renegotiation of the link, without any harmful side effects. Close (C) The Close event indicates that the link is not available for traffic; that is, the network administrator (human or program) has indicated that the link is not allowed to be Opened. When this event occurs, and the link is not Closed, the automaton attempts to terminate the connection. Futher attempts to re-configure the link are denied until a new Open event occurs. Timeout (TO+,TO-) This event indicates the expiration of the Restart timer. The Restart timer is used to time responses to Configure-Request and Terminate-Request packets. The TO+ event indicates that the Restart counter continues to be greater than zero, which triggers the corresponding Configure- Request or Terminate-Request packet to be retransmitted. The TO- event indicates that no further packets need to be retransmitted. Receive-Configure-Request (RCR+,RCR-) This event occurs when a Configure-Request packet is received from the peer. The Configure-Request packet indicates the desire to open a connection and may specify Configuration Options. The Simpson [Page 20] RFC DRAFT Point-to-Point Protocol December 1991 Configure-Request packet is more fully described in a later section. The RCR+ event indicates that the Configure-Request was acceptable, and triggers the transmission of a corresponding Configure-Ack. The RCR- event indicates that the Configure-Request was unacceptable, and triggers the transmission of a corresponding Configure-Nak or Configure-Reject. Implementation Note: These events may occur on a connection which is already in the Opened state. The implementation MUST be prepared to immediately renegotiate the Configuration Options. Receive-Configure-Ack (RCA) The Receive-Configure-Ack event occurs when a valid Configure-Ack packet is received from the peer. The Configure-Ack packet is a positive response to a Configure-Request packet. An out of sequence or otherwise invalid packet is silently discarded. Implementation Note: Since the correct packet has already been received before reaching the Ack-Rcvd or Opened states, it is extremely unlikely that another such packet will arrive. As specified, all invalid Ack/Nak/Rej packets are silently discarded, and do not affect the transitions of the automaton. However, it is not impossible that a correctly formed packet will arrive through a coincidentally-timed cross-connection. It is more likely to be the result of an implementation error. At the very least, this occurance should be logged. Receive-Configure-Nak/Rej (RCN) This event occurs when a valid Configure-Nak or Configure-Reject packet is received from the peer. The Configure-Nak and Configure-Reject packets are negative responses to a Configure- Request packet. An out of sequence or otherwise invalid packet is silently discarded. Implementation Note: Although the Configure-Nak and Configure-Reject cause the same Simpson [Page 21] RFC DRAFT Point-to-Point Protocol December 1991 state transition in the automaton, these packets have significantly different effects on the Configuration Options sent in the resulting Configure-Request packet. Receive-Terminate-Request (RTR) The Receive-Terminate-Request event occurs when a Terminate- Request packet is received. The Terminate-Request packet indicates the desire of the peer to close the connection. Implementation Note: This event is not identical to the Close event (see above), and does not override the Open commands of the local network administrator. The implementation MUST be prepared to receive a new Configure-Request without network administrator intervention. Receive-Terminate-Ack (RTA) The Receive-Terminate-Ack event occurs when a Terminate-Ack packet is received from the peer. The Terminate-Ack packet is usually a response to a Terminate-Request packet. The Terminate-Ack packet may also indicate that the peer is in Closed or Stopped states, and serves to re-synchronize the link configuration. Receive-Unknown-Code (RUC) The Receive-Unknown-Code event occurs when an un-interpretable packet is received from the peer. A Code-Reject packet is sent in response. Receive-Code-Reject, Receive-Protocol-Reject (RXJ+,RXJ-) This event occurs when a Code-Reject or a Protocol-Reject packet is received from the peer. The RXJ- event arises when the rejected value is acceptable, such as a Code-Reject of an extended code, or a Protocol-Reject of a NCP. These are within the scope of normal operation. The implementation MUST stop sending the offending packet type. The RXJ- event arises when the rejected value is catastrophic, such as a Code-Reject of Configure-Request, or a Protocol-Reject of LCP! This event communicates an unrecoverable error that terminates the connection. Simpson [Page 22] RFC DRAFT Point-to-Point Protocol December 1991 Receive-Echo-Request, Receive-Echo-Reply, Receive-Discard-Request (RXR) This event occurs when an Echo-Request, Echo-Reply or Discard- Request packet is received from the peer. The Echo-Reply packet is a response to a Echo-Request packet. There is no reply to an Echo-Reply or Discard-Request packet. 5.5. Actions Actions in the automaton are caused by events and typically indicate the transmission of packets and/or the starting or stopping of the Restart timer. Illegal-Event (-) This indicates an event that SHOULD NOT occur. The implementation probably has an internal error. Upper-Layer-Up (ulu) The Upper-Layer-Up action indicates to the upper layers that the automaton is entering the Opened state. Typically, this action MAY be used by the LCP to signal the Up event to a NCP, Authentication Protocol, or Link Quality Protocol, or MAY be used by a NCP to indicate that the link is available for its traffic. Upper-Layer-Down (uld) The Upper-Layer-Down action indicates to the upper layers that the automaton is leaving the Opened state. Typically, this action MAY be used by the LCP to signal the Down event to a NCP, Authentication Protocol, or Link Quality Protocol, or MAY be used by a NCP to indicate that the link is no longer available for its traffic. Lower-Layer-Go (llg) The Lower-Layer-Go action indicates that the lower layer is needed for the link. The lower layer should respond with an Up event when the lower layer is available. This action is highly implementation dependant. Simpson [Page 23] RFC DRAFT Point-to-Point Protocol December 1991 Lower-Layer-Quit (llq) The Lower-Layer-Quit action indicates that the lower layer is no longer needed for the link. The lower layer should respond with a Down event when the lower layer has terminated. Typically, this action MAY be used by the LCP to advance to the Link Dead phase, or MAY be used by a NCP to indicate to the LCP that the link may terminate when there are no other NCPs open. This action is highly implementation dependant. Send-Configure-Request (scr) The Send-Configure-Request action transmits a Configure-Request packet. This indicates the desire to open a connection with a specified set of Configuration Options. The Restart timer is started when the Configure-Request packet is transmitted, to guard against packet loss. Send-Configure-Ack (sca) The Send-Configure-Ack action transmits a Configure-Ack packet. This acknowledges the receipt of a Configure-Request packet with an acceptable set of Configuration Options. Send-Configure-Nak (scn) The Send-Configure-Nak action transmits a Configure-Nak or Configure-Reject packet, as appropriate. This negative response reports the receipt of a Configure-Request packet with an unacceptable set of Configuration Options. Configure-Nak packets are used to refuse a Configuration Option value, and to suggest a new, acceptable value. Configure-Reject packets are used to refuse all negotiation about a Configuration Option, typically because it is not recognized or implemented. The use of Configure-Nak versus Configure-Reject is more fully described in the section on LCP Packet Formats. Send-Terminate-Request (str) The Send-Terminate-Request action transmits a Terminate-Request packet. This indicates the desire to close a connection. The Restart timer is started when the Terminate-Request packet is transmitted, to guard against packet loss. Simpson [Page 24] RFC DRAFT Point-to-Point Protocol December 1991 Send-Terminate-Ack (sta) The Send-Terminate-Ack action transmits a Terminate-Ack packet. This acknowledges the receipt of a Terminate-Request packet or otherwise serves to synchronize the state machines. Send-Code-Reject (scj) The Send-Code-Reject action transmits a Code-Reject packet. This indicates the receipt of an unknown type of packet. Send-Echo-Reply (ser) The Send-Echo-Reply action transmits an Echo-Reply packet. This acknowledges the receipt of an Echo-Request packet. 5.6. Loop Avoidance The protocol makes a reasonable attempt at avoiding Configuration Option negotiation loops. However, the protocol does NOT guarantee that loops will not happen. As with any negotiation, it is possible to configure two PPP implementations with conflicting policies that will never converge. It is also possible to configure policies which do converge, but which take significant time to do so. Implementors should keep this in mind and should implement loop detection mechanisms or higher level timeouts. If a timeout is implemented, it MUST be configurable. 5.7. Timers and Counters Restart Timer There is one special timer used by the automaton. The Restart timer is used to time out transmissions of Configure-Request and Terminate-Request packets. Expiration of the Restart timer causes a Timeout event, and retransmission of the corresponding Configure- Request or Terminate-Request packet. The Restart timer MUST be configurable, but MAY default to three (3) seconds. Implementation Note: The Restart timer SHOULD be based on the speed of the link. The default value is designed for low speed (19,200 bps or less), high switching latency links (typical telephone lines). Higher speed links, or links with low switching latency, SHOULD have correspondingly faster retransmission times. Simpson [Page 25] RFC DRAFT Point-to-Point Protocol December 1991 Max-Terminate There is one required restart counter. Max-Terminate indicates the number of Terminate-Request packet transmissions that are required before there is reasonable assurance that the link closed. Max- Terminate MUST be configurable, but should default to two (2) transmissions. Max-Configure A similar counter is recommended for Configure-Request restarts. Max-Configure indicates the number of Configure-Request packet transmissions that are sent without receiving a Configure-Ack or Configure-Nak before assuming that the peer is unable to respond. Max-Configure MUST be configurable, but should default to twenty (20) transmissions. Max-Failure A related counter is recommended for Configure-Nak. Max-Failure indicates the number of Configure-Nak packet transmissions that are sent before assuming that configuration is not converging. Any further Configure-Nak packets are converted to Configure-Reject packets. Max-Failure MUST be configurable, but should default to ten (10) transmissions. Simpson [Page 26] From ietf-ppp-request@ucdavis.ucdavis.edu Tue Dec 17 00:30:43 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA09879; Tue, 17 Dec 91 00:15:16 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from azea.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA09690; Tue, 17 Dec 91 00:05:08 -0800 Received: by azea.clearpoint.com (4.1/1.34) id AA00906; Tue, 17 Dec 91 02:58:50 EST Date: Tue, 17 Dec 91 02:58:50 EST From: martillo@azea.clearpoint.com (Joachim Martillo @ azea) Message-Id: <9112170758.AA00906@azea.clearpoint.com> To: vjs@rhyolite.wpd.sgi.com Cc: brian@lloyd.com, ietf-ppp@ucdavis.edu, martillo@azea.clearpoint.com In-Reply-To: Vernon Schryver's message of Fri, 13 Dec 91 21:36:30 -0800 <9112140536.AA00793@rhyolite.wpd.sgi.com> Subject: SLIP throughput on T2500 Date: Fri, 13 Dec 91 21:36:30 -0800 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) > From martillo@azea.clearpoint.com Fri Dec 13 20:44:24 1991 > > I posted the message specifically because Schryver implied that router > vendors (we are about to become one) are not implementing PPP because > they somehow object to providing the capability to mix and match their > products and the products of competitors on point to point links. > > This insinuation merited a rebuttal. Router vendors have legitimate > problems with PPP. > ... I hoped my statement was more direct than an insinuation. Your rebuttal was insufficient. I've drawn conclusions about router vendor intentions, based on facts and logic. A lot of PPP partisans disagree with this point as later discussion indicated. For me the issue is irrelevant because PPP is broken strictly on technical grounds. After years, the only router vendor PPP implementation of which I've heard public mention is Cisco's minimal one. The Cisco hybrid bridge routers according to Communications Week Dec. 9, 1991, p.24 "[bridge] all protocols not routed." This implementation sounds like a parallel router filtering bridge [PRFB] implementation of an hybrid bridge router. Parallel router filtering bridges are inherently broken. If a system's architecture is already broken, there is likely to be less inertia to adding in yet another broken feature, since the new broken feature may be less likely to break anything not already broken. PPP assumes a PRFB architecture for hybrid WAN LAN bridge router. If a company's hybrid bridge router already used this broken PRFB architecture, adding a WAN extension conforming to the broken architecture is not a problem. If a company implements hybrid bridging routing correctly, adding a broken WAN extension is much more distressing and problematic. To see the broken nature of PRFBs, consider the following topology: router--------------L1-------------bridge[B1]--------L2-------------bridge[B2] | | |_________________________________L3________________________________| IP hosts on L1 and L2 correspond to IP subnetwork A, and IP hosts on L3 correspond to IP subnetwork B. The router does not route but bridges some protocol P. The topology with respect to protocol P provides some fault tolerance against failure of one of the bridges. If the port from B2 onto L2 blocks according to STP, this topology works correctly but if the port from B1 to L2 blocks, the connectivity of some IP hosts on subnetwork A is lost. Now this topology can be configured to work correctly, but for more complex topologies the configuration problem quickly becomes intractable. The same problem exists for STP, SR and SRT bridges. The logic was that the router market is such that most customers have minimized the vendors they deal with, in part because of the lack of a common standard. Current large router vendors who implement any common protocol are not going to increase their penetration of any single customer, but would make it easier for competators to sell to their existing customers. Wow, I don't have to visit my family in Syria to hear paranoic conspiratorial fantasies anymore. I just have to pay more attention to the technical newsgroups. Now, as with many paranoic fantasies there may be some elements of truth to this theory, but if PPP actually offered some useful feature (like the ability to build switching fabric communicatsion subnets), there would be reason to implement PPP despite the marketing considerations. Because as currently defined PPP offers nothing positive to bridge, router or hybrid bridge router vendors, the marketing consideration may actually be one valid reason not to implement PPP. As long as all of the big router vendors continue to not make PPP their primary, best supported, fastest protocol, they protect their customer base and do not seem to be bad guys, since "no one is shipping it." The complexity of the protocol specs and the stupidities associated with the headers suggests that considerations of the implementation of high performance embedded systems played practically no role in the implementation of PPP. The variable length PPP headers may force reallignment of many packets. For a Unix environments where packets are often copied two or three times, forcing reallignment is not utterly horrible. In a high performance bridge environment, extraneous copies are deadly. There is nothing illegal, fattening, immoral, or wrong in this strategy. It would be at best naive to claim such considerations never occurred to the big router vendors (or the small ones). There may be other considerations which will overcome these. We'll all know 30 days after that happens, because they'll be advertising the delivery dates of their implementations, whether of PPP or any other common protocol. Actually, I bet we'll hear sooner, because I think many of the router vendors have PPP implementations, which they'll push as soon as it makes marketting sense. Everyone has "legitimate problems" with everything. Given a good enough protocol, such "problems" are not the primary considerations in what to implement and sell. It is likely that everyone on the mailing list considers PPP "broken." What isn't broken? What is there that could not be done better by any of us, if we only had the time, inclination, and political power? PPP assumes a broken hybrid WAN LAN bridge router architecture which implies a broken hybrid bridge router architecture. The issue is important enough that PPP should be quashed as soon as possible. > I did listen. You simply do not understand the DOD Internet > Architecture or the ISO OSI model. Treating a MAC protocol as a peer > with Network protocols (as PPP and MPI/FR do) breaks the architectures I'm sick unto anger with people who argue by layers. Layering is an important intellectual tool, along with Turing machines, P vs. NP, and prohibitions against GOTO's. Only those who produce slow and broken implementations use the "DOD Internet Architecture" as implementation models. The history of the "DOD Internet" protocols is one of intentional violations of preceding versions of the "Architecture". Who today argues against header compression, header predicting, slow start, and RTT measuring? Oh, the IP purists suddenly think it is okay to break architecture. And to tell the truth I am not an architecture dogmatist (no one competent who has been doing protocol architecture and implementation for 16 years is), but breaking the architecture as PPP breaks the architecture ruins network layer routing logic and breaks bridging path selection. There is no obvious tremendous performance gain (if any) in sending a packet to the router entity on the basis of packet type rather than link layer address. Schryver's justification for the stupidity of PPP is an example of attempting to baffle us with irrelevant nonsense when he has no cogent technical rejoinder. Consider FDDI. Those who believe the standards are implementation models get at most 50% and often only 20% of the performance of the several groups who treat the standards as Turing machine descriptions or black-box models. FDDI has its own rather unique problems which are irrelevant to this discussion. Speaking of marketting sense, I bet this mailing list reaches most of the people in the world who might buy, either figuratively or literally, an alternative to PPP. An alternative to PPP would have to be sold here, to IEEE, or ANSI. If I had such an alternative, I'd talk nice or not at all to all of the PPP fans, no matter how stupid or ignorant of their own protocols I thought them. And of course if baffling them with nonsense might not work and one is incapable of valid technical argumentation, there is always intimidation by implicit and explicit threats. 1) This sort of intimidation does not work against someone who has lived for many years in a part of the world where people intimidate you by shoving a Kalashnikov up your nose. 2) Clearpoint battles DEC before breakfast and triumphs despite the common wisdom for relaxation in the afternoon. 3) We have more strategic depth than the other networking companies because we also sell memory boards and subsystems. As a consequence, we don't have to strong arm people into perhaps unnecessary networking solutions but have the freedom to develop correct solutions in any of our areas of endeavor and sell customers the solution to their performance problems which may actually be something other than a networking solution. Ignorant threats will not dissuade us from a business strategy which has proven rather successful for us. Vernon Schryver, vjs@sgi.com Joachim Carlo Santos Martillo Ajami From ietf-ppp-request@ucdavis.ucdavis.edu Tue Dec 17 02:00:48 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA11456; Tue, 17 Dec 91 01:46:29 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SGI.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA11239; Tue, 17 Dec 91 01:31:35 -0800 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (911016.SGI/910110.SGI) for ietf-ppp@ucdavis.edu id AA20009; Tue, 17 Dec 91 01:30:06 -0800 Received: by rhyolite.wpd.sgi.com (911016.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@ucdavis.edu id AA05460; Tue, 17 Dec 91 01:30:05 -0800 Date: Tue, 17 Dec 91 01:30:05 -0800 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9112170930.AA05460@rhyolite.wpd.sgi.com> To: ietf-ppp@ucdavis.edu Subject: Re: SLIP throughput on T2500 ] from me ] ... ] The logic was that the router market is such that most customers have ] minimized the vendors they deal with, in part because of the lack of a ] common standard. Current large router vendors who implement any common ] protocol are not going to increase their penetration of any single ] customer, but would make it easier for competators to sell to their ] existing customers. ... ] Speaking of marketting sense, I bet this mailing list reaches most of the ] people in the world who might buy, either figuratively or literally, an ] alternative to PPP. An alternative to PPP would have to be sold here, to ] IEEE, or ANSI. If I had such an alternative, I'd talk nice or not at all ] to all of the PPP fans, no matter how stupid or ignorant of their own ] protocols I thought them. > From: martillo@azea.clearpoint.com (Joachim Martillo @ azea) > ... > Wow, I don't have to visit my family in Syria to hear paranoic > conspiratorial fantasies anymore.... > Oh, the IP purists suddenly think it is okay to break architecture. > ... > .... Schryver's justification for the > stupidity of PPP is an example of attempting to baffle us with > irrelevant nonsense when he has no cogent technical rejoinder. > ... > And of course if baffling them with nonsense might not work and one is > incapable of valid technical argumentation, there is always > intimidation by implicit and explicit threats. > > 1) This sort of intimidation does not work against someone who has > lived for many years in a part of the world where people intimidate > you by shoving a Kalashnikov up your nose. > > 2) Clearpoint battles DEC before breakfast and triumphs despite the > common wisdom for relaxation in the afternoon. > > 3) We have more strategic depth than the other networking companies because > we also sell memory boards and subsystems. As a consequence, we don't > have to strong arm people into perhaps unnecessary networking solutions > but have the freedom to develop correct solutions in any of our areas > of endeavor and sell customers the solution to their performance problems > which may actually be something other than a networking solution. Ignorant > threats will not dissuade us from a business strategy which has proven > rather successful for us. > > Joachim Carlo Santos Martillo Ajami I have finally realized that the "Clearpoint" represented by the person signed above is the same which I understood made good 3rd party memory products. This is unfortunate, because no company which takes my advice will ever buy anything from or sell or give anything to this Clearpoint. No company which allows its employees to indulge in such public ad homiem "technical discussions" would be capable of useful customer support. Any company whose main representative to a technical standards organization central to its business consistently conducts technical discussions like this would be a joy when dealing with a bad board or dead router. Can you imagine the pleasure of cooperating with Clearpoint on the development of their Slithernet protocol, product, or whatever? This is not a threat, but a description of my professional evaluation of the management of a particular commercial organization. This evalution may not materially affect Clearpoint. I do not write letters to the editor nor columns in the trade press, but I do have some responsibility for advising and consenting to various business activities. Such evaluations are one kind that I, like other senior developers and designers on this mailing list, been involved in over these last years (many more than 16, but let's not get down to bragging about career duration or personal obsolence). When dealing with a vendor, you figure out from the evidence at hand how they will treat you after they have your P.O. When thinking about products, you predict how the other guys and your present and future customers will react. Anyone company which doesn't pay attention to what new products will do to their market either has no existing products or is soon out of business. Since this is not a lecture on elementary Product Marketing, and since many of us have old experiences too painful to remember and recent ones which cannot be discussed publicly, I'll leave it at that. Vernon Schryver. From ietf-ppp-request@ucdavis.ucdavis.edu Tue Dec 17 08:23:23 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18191; Tue, 17 Dec 91 08:00:28 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from azea.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA17701; Tue, 17 Dec 91 07:44:57 -0800 Received: by azea.clearpoint.com (4.1/1.34) id AA01010; Tue, 17 Dec 91 10:36:36 EST Date: Tue, 17 Dec 91 10:36:36 EST From: martillo@azea.clearpoint.com (Joachim Martillo @ azea) Message-Id: <9112171536.AA01010@azea.clearpoint.com> To: brian@lloyd.com Cc: vjs@rhyolite.wpd.sgi.com, olling@taeko.jnoc.go.jp, news.comp.protocols.ppp@rhyolite.wpd.sgi.com, ietf-ppp@ucdavis.edu In-Reply-To: Brian Lloyd's message of Sat, 14 Dec 91 12:17:59 PST <9112142017.AA04737@ray.lloyd.com> Subject: SLIP throughput on T2500 Date: Sat, 14 Dec 91 12:17:59 PST From: brian@lloyd.com (Brian Lloyd) Reply-To: brian@lloyd.com Date: Fri, 13 Dec 91 23:39:19 EST From: martillo@azea.clearpoint.com (Joachim Martillo @ azea) This insinuation merited a rebuttal. Router vendors have legitimate problems with PPP. Funny, the router vendors with whom I am familiar are all working toward a full implementation of PPP. Within this group I include 3Com, cisco, Wellfleet, Network System, and Proteon. Some have working versions of PPP and some are still working toward that goal. I do not think that the router vendors are holding back nor has anyone complained that PPP is unable to meet their needs (with the exception of you). We apparently travel in different circles. I know other router/bridge implementers who have the same problems with PPP that I do. I did listen. You simply do not understand the DOD Internet Architecture or the ISO OSI model. Treating a MAC protocol as a peer with Network protocols (as PPP and MPI/FR do) breaks the architectures and causes routing anomalies at layer 2 and layer 3. I suspect that I understand layering as well as you. I also understand when rigid adherence to the OSI layering model is counter productive (vis a vis Internet model having its layers and interfaces at a different place from the ISO model). The key here is functionallity, not rigidity. I could quote Padlipsky at you but I suspect the reference would be lost. The issue is not functionality versus rigidity. PPP as defined contravenes fundamental features of both DOD IP routing and ISO OSI architechture and interferes with basic routing and path selection functionality. As for forcing a peer to send only MAC frames on a link, this is only possible if implementations of PPP are obligated to have the capability to transmit full MAC frames. As far as I can tell, this requirement has not been made. Nor should it. A few people want to bridge at the MAC layer. Many people want to route at the Network layer, and still more want to route at the Internetwork layer. It is up to the administrator to make that judgement as to how his/her network will operate. The beauty of PPP is that it will permit the administrator to make that decision and continue to use the same link protocol. Here lies the central bogosity of PPP. Only the receiver of a frame can really make the decision that the frame should be bridged or forwarded to some network layer functionality. The transmitter may have no knowledge at all of the structure of the remote network and may not be able to acquire such knowledge. The PPP model of bridges and routers is fundamentally retrograde. The internal bus of a bridge or router is just as much a LAN bus as an ethernet bus. If the network device contains two router entities on the internal bus to which IP packets can be sent, a mechanism is necessary to address or the other of the router entities. PPP provides only a confused and non-obligatory mechanism for addressing entities which network on the internal bus. And by the way if all devices which support PPP implement the ability to transmit MAC frames, this brain-dead reject mechanism only guarantees that the router will cease to transmit rejected network packets, the mechanism does not guarantee that the device *will* transmit rejected network packets as MAC encapsulated frames which will be accepted. Again, this is a configuration issue. The administrator gets to choose. No he doesn't. He can only make choices about a router under his own control and he may not have authority, access or knowledge of the remote end. The mechanism ensures that one side tells the other what it is willing to accept. If the administrator chooses not to accept a particular NCP, he can tell his router to reject that particular NCP. Multiprotocol routers are a fact of life. But they are a ridiculous means of interconnection of geographically distant LANs by point to point links. There is a lot of configuration that goes into a multiprotocol router/bridge to get it to do precisely what the administrator wishes it to do. PPP is an attempt to allow as much flexibility as possible without unnecessarily forcing an administrator to do things one particular way. PPP by assuming a Parallel Router Filtering Bridge architecture makes the configuration problem practically intractable. If you consider flag framing on an HDLC link a networking protocol, then PPP is a networking protocol. From the standpoint of moderate to high speed synchronous links PPP is simply an extended and broken version of flag framing which most people consider simply an encapsulation. It matters not what you call it. It works. May I point out that Frame Relay is essentially the removal of the link layer "enhancements" of X.25. Does that mean that Frame Relay is not a networking protocol or that it serves no useful purpose? Frame relay may not serve any useful purpose, but the communications subnet in the case of frame relay can perform path selection as needed. PPP has no capabilities for path selection and therefore offers considerably less than frame relay. Now I will ask you again: please participate in the PPP specification process in a productive manner or please leave us alone. We are trying to get work done and you continue to joggle our collective elbow. Have a meeting in the Boston or Worcester area and I will come. I don't like to travel and travel as little as I can, and still travel too much for my tastes. Much of the work on PPP takes place on the ietf-ppp mailing list (ietf-ppp@ucdavis.edu). If you need a particular feature please participate. We welcome your CONSTRUCTIVE input. If the ability to send and receive complete MAC frames is made obligatory at the request of either end point, I will go away. As for your desire not to travel, that is your problem, not mine. Do not blame us for your dislikes and/or phobias. We encourage you to meet with us at the upcoming IETF meeting and/or participate constructively in the discussions on the ietf-ppp mailing list. To tell the truth, I don't really see the need for face to face meetings because e-mail is perfectly adequate for technical discussion. And as far as I can tell your idea of constructive contribution is dotting the i's and crossing the t's on protocol methods which proved themselves essentially unworkable at AT&T 20 years ago. There really is a reason for separating link layer and circuit layer set up as is done everywhere in the telephony world. They are both hard issues and if you try to do them in one FSM as is being done in PPP, there is little probability of getting it right. The correct way to handle the issue is for the link layer protocols to assume that the circuit is there, and leave the circuit layer problem to circuit layer software. In this formalism, leased lines are not a special case for the link layer. Joachim Carlo Santos Martillo Ajami Brian Lloyd, WB6RQN Lloyd & Associates Joachim Carlo Santos Martillo Ajami From ietf-ppp-request@ucdavis.ucdavis.edu Tue Dec 17 08:51:24 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18713; Tue, 17 Dec 91 08:19:15 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from azea.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18470; Tue, 17 Dec 91 08:11:42 -0800 Received: by azea.clearpoint.com (4.1/1.34) id AA01020; Tue, 17 Dec 91 11:03:55 EST Date: Tue, 17 Dec 91 11:03:55 EST From: martillo@azea.clearpoint.com (Joachim Martillo @ azea) Message-Id: <9112171603.AA01020@azea.clearpoint.com> To: brian@lloyd.com Cc: vjs@rhyolite.wpd.sgi.com, olling@taeko.jnoc.go.jp, news.comp.protocols.ppp@rhyolite.wpd.sgi.com, ietf-ppp@ucdavis.edu, martillo@azea.clearpoint.com In-Reply-To: Brian Lloyd's message of Sat, 14 Dec 91 12:17:59 PST <9112142017.AA04737@ray.lloyd.com> Subject: SLIP throughput on T2500 Date: Sat, 14 Dec 91 12:17:59 PST From: brian@lloyd.com (Brian Lloyd) Reply-To: brian@lloyd.com Date: Fri, 13 Dec 91 23:39:19 EST From: martillo@azea.clearpoint.com (Joachim Martillo @ azea) This insinuation merited a rebuttal. Router vendors have legitimate problems with PPP. Funny, the router vendors with whom I am familiar are all working toward a full implementation of PPP. Within this group I include 3Com, cisco, Wellfleet, Network System, and Proteon. Some have working versions of PPP and some are still working toward that goal. I do not think that the router vendors are holding back nor has anyone complained that PPP is unable to meet their needs (with the exception of you). We apparently travel in different circles. I know other router/bridge implementers who have the same problems with PPP that I do. I did listen. You simply do not understand the DOD Internet Architecture or the ISO OSI model. Treating a MAC protocol as a peer with Network protocols (as PPP and MPI/FR do) breaks the architectures and causes routing anomalies at layer 2 and layer 3. I suspect that I understand layering as well as you. I also understand when rigid adherence to the OSI layering model is counter productive (vis a vis Internet model having its layers and interfaces at a different place from the ISO model). The key here is functionallity, not rigidity. I could quote Padlipsky at you but I suspect the reference would be lost. The issue is not functionality versus rigidity. PPP as defined contravenes fundamental features of both DOD IP routing and ISO OSI architechture and interferes with basic routing and path selection functionality. As for forcing a peer to send only MAC frames on a link, this is only possible if implementations of PPP are obligated to have the capability to transmit full MAC frames. As far as I can tell, this requirement has not been made. Nor should it. A few people want to bridge at the MAC layer. Many people want to route at the Network layer, and still more want to route at the Internetwork layer. It is up to the administrator to make that judgement as to how his/her network will operate. The beauty of PPP is that it will permit the administrator to make that decision and continue to use the same link protocol. Here lies the central bogosity of PPP. Only the receiver of a frame can really make the decision that the frame should be bridged or forwarded to some network layer functionality. The transmitter may have no knowledge at all of the structure of the remote network and may not be able to acquire such knowledge. The PPP model of bridges and routers is fundamentally retrograde. The internal bus of a bridge or router is just as much a LAN bus as an ethernet bus. If the network device contains two router entities on the internal bus to which IP packets can be sent, a mechanism is necessary to address or the other of the router entities. PPP provides only a confused and non-obligatory mechanism for addressing entities which network on the internal bus. And by the way if all devices which support PPP implement the ability to transmit MAC frames, this brain-dead reject mechanism only guarantees that the router will cease to transmit rejected network packets, the mechanism does not guarantee that the device *will* transmit rejected network packets as MAC encapsulated frames which will be accepted. Again, this is a configuration issue. The administrator gets to choose. No he doesn't. He can only make choices about a router under his own control and he may not have authority, access or knowledge of the remote end. The mechanism ensures that one side tells the other what it is willing to accept. If the administrator chooses not to accept a particular NCP, he can tell his router to reject that particular NCP. Multiprotocol routers are a fact of life. But they are a ridiculous means of interconnection of geographically distant LANs by point to point links. There is a lot of configuration that goes into a multiprotocol router/bridge to get it to do precisely what the administrator wishes it to do. PPP is an attempt to allow as much flexibility as possible without unnecessarily forcing an administrator to do things one particular way. PPP by assuming a Parallel Router Filtering Bridge architecture makes the configuration problem practically intractable. If you consider flag framing on an HDLC link a networking protocol, then PPP is a networking protocol. From the standpoint of moderate to high speed synchronous links PPP is simply an extended and broken version of flag framing which most people consider simply an encapsulation. It matters not what you call it. It works. May I point out that Frame Relay is essentially the removal of the link layer "enhancements" of X.25. Does that mean that Frame Relay is not a networking protocol or that it serves no useful purpose? Frame relay may not serve any useful purpose, but the communications subnet in the case of frame relay can perform path selection as needed. PPP has no capabilities for path selection within a communications subnet and therefore offers considerably less than frame relay. Now I will ask you again: please participate in the PPP specification process in a productive manner or please leave us alone. We are trying to get work done and you continue to joggle our collective elbow. Have a meeting in the Boston or Worcester area and I will come. I don't like to travel and travel as little as I can, and still travel too much for my tastes. Much of the work on PPP takes place on the ietf-ppp mailing list (ietf-ppp@ucdavis.edu). If you need a particular feature please participate. We welcome your CONSTRUCTIVE input. If the ability to send and receive complete MAC frames is made obligatory at the request of either end point, I will go away. As for your desire not to travel, that is your problem, not mine. Do not blame us for your dislikes and/or phobias. We encourage you to meet with us at the upcoming IETF meeting and/or participate constructively in the discussions on the ietf-ppp mailing list. To tell the truth, I don't really see the need for face to face meetings because e-mail is perfectly adequate for technical discussion. And as far as I can tell your idea of constructive contribution is dotting the i's and crossing the t's on protocol methods which proved themselves essentially unworkable at AT&T 20 years ago. There really is a reason for separating link layer and circuit layer set up as is done everywhere in the telephony world. They are both hard issues and if you try to do them in one FSM as is being done in PPP, there is little probability of getting it right. The correct way to handle the issue is for the link layer protocols to assume that the circuit is there, and leave the circuit layer problem to circuit layer software. In this formalism, leased lines are not a special case for the link layer. Joachim Carlo Santos Martillo Ajami Brian Lloyd, WB6RQN Lloyd & Associates Joachim Carlo Santos Martillo Ajami From ietf-ppp-request@ucdavis.ucdavis.edu Tue Dec 17 09:19:36 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA19293; Tue, 17 Dec 91 08:41:22 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from sayshell.umd.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18761; Tue, 17 Dec 91 08:22:00 -0800 Received: by sayshell.umd.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0) id AA01575; Tue, 17 Dec 91 11:20:07 EST Message-Id: <9112171620.AA01575@sayshell.umd.edu> To: kasten@europa.clearpoint.com (Frank Kastenholz) Cc: ietf-ppp@ucdavis.edu, vjs@rhyolite.wpd.sgi.com Subject: Re: SLIP throughput on T2500 In-Reply-To: Your message of "Tue, 17 Dec 91 09:46:13 EST." <9112171446.AA21273@europa.clearpoint.com> Date: Tue, 17 Dec 91 11:20:06 EST From: "Louis A. Mamakos" > Vern, et al > > As many (but not all) of you all know, Mr. Martillo is NOT > our "main representative to a technical standards organization > central to its business". This is a perceptual problem that Clearpoint needs to address. What other conclusion can readers of the PPP mailing list come to? > We do, however, believe in some degree of freedom of expression, > and do not wish to place restrictions on what people may or may > not post on the net. While his style may be abrasive to some people, > there is technical content in the postings and that content may > be valid and important. Mr. Martillo's style is such that he is totally ineffective in persuading anyone about anything. There might (maybe, but I'm not certain) be some valid points which he makes in his diatribe, but who wants to read though insulting prose to extract them? > Perhaps we have all been too close to PPP > for too long to see the failings that Mr. Martillo is trying to > point out. On the other hand, they may not be failings and by > addressing the issues, we will have proved to ourselves that what > we have done is correct. My perception is that Mr. Martillo is trying to solve problems that the vast majority of people just don't have. He seems bent on accomodating a general purpose switching fabric, which I don't think is what PPP is trying to solve. POINT-to-POINT protocol. I sent a mail message to Mr. Martillo some time ago expressing the same sorts of ideas and concernts that Vernon's message did; perhaps not worded as well.. I, in my role as a customer of router vendors and provider of network services to MY customers, am not thrilled with the prospect of dealing with a company with abusive employees that don't seem to understand what my needs are. If I bought a Clearpoint product, I might potentially have to depend on the likes of Mr. Martillo for support in the future, and I am uneasy at the prospect. There are plenty of other vendors who understand the architecture of the types of networks that I (and all of my peers at other Universites and gov't agencies) are trying to build. And they are not abusive and insulting to potential customers before the sale or to participants at standards groups. I happen to be in both those groups. It is not just other vendors and your competitors that Mr. Martillo is insulting and antagonizing, but your (potential) customers as well. The IETF is not made up of vendors exclusively, though it seems like it these days.. Mr. Martillo convinced me that my time would be wasted to even bother to take a look at any of Clearpoint's products at the Interop show. I spent my time talking to your competition whose technical representatives participate in meaningful dialog in standards groups like the IETF, and who are pleasent to communicate with. Perhaps Mr. Martillo's "style" is somewhat counter-productive? If you were on the other end of the PPP mailing list and read Mr. Martillo's contributions, what conclusions could you come to? I find myself angry and disturbed after reading each of Mr. Martillo's postings, and that feeling can't help but be associated with the company that he represents. Like it or not, he represents your company. Your marketing folks must be thrilled at the damage he does, going out of his way to antagonize potential customers. Now, just an example: > 3) We have more strategic depth than the other networking companies because > we also sell memory boards and subsystems. As a consequence, we don't > have to strong arm people into perhaps unnecessary networking solutions > but have the freedom to develop correct solutions in any of our areas > of endeavor and sell customers the solution to their performance problems > which may actually be something other than a networking solution. Ignorant > threats will not dissuade us from a business strategy which has proven > rather successful for us. If Clearpoint supports the architecture that Mr. Martillo vents his speen over from time to time, the let the marketplace decide. Personally, I'm not interested. Our bid requirements will continue to specify standards like OSPF and PPP. If Clearpoint feels it can be sucessful pursuing the architecture Mr. Martillo supports, by all means do so! Just don't impede the progress of standards that *I* am interested in, which solve problems that *I* have. > Frank Kastenholz > Clearpoint Research Corp. Louis A. Mamakos Network Infrastructure Group University of Maryland, College Park From ietf-ppp-request@ucdavis.ucdavis.edu Tue Dec 17 10:20:43 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA21550; Tue, 17 Dec 91 10:05:58 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from GORDIUS.GORDIAN.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA21065; Tue, 17 Dec 91 09:46:03 -0800 Received: from geryon (geryon.gordian.com) by gordius.gordian.com (4.1/SMI-4.1) id AA23233; Tue, 17 Dec 91 09:45:54 PST Received: by geryon (5.61/1.34) id AA08258; Tue, 17 Dec 91 09:45:05 -0800 From: johnk@gordian.com (John Kalucki) Message-Id: <9112171745.AA08258@geryon> To: ietf-ppp@ucdavis.edu Cc: johnk@gordian.com Subject: Re: SLIP throughput on T2500 In-Reply-To: Your message of Tue, 17 Dec 91 09:46:13 -0500. <9112171446.AA21273@europa.clearpoint.com> Date: Tue, 17 Dec 91 09:45:04 PST >Vern, et al > >As many (but not all) of you all know, Mr. Martillo is NOT >our "main representative to a technical standards organization >central to its business". > >We do, however, believe in some degree of freedom of expression, >and do not wish to place restrictions on what people may or may >not post on the net. While his style may be abrasive to some people, >there is technical content in the postings and that content may >be valid and important. Perhaps we have all been too close to PPP >for too long to see the failings that Mr. Martillo is trying to >point out. I have been reading this mail distribution for about a year now, mostly out of curiosity, and partially in case I am called to implement PPP in the near future. I don't consider myself close to the 'process' in any way. Let me also disclaim that I, in general, feel that routing over a wide area link is a superior solution to bridging. Despite giving him the benefit of the doubt, I've failed to grasp Mr Martillo's arguments against PPP. I've tried to penetrate the religious rantings, and I haven't seen much technical merit. He appears to be worrying about some issues that effectivly make Clearpoint's products difficult to use in conjunction with other vendor's bride/router products. His example given to show the "brokeness" of PPP does not appear to be a likely, or even useful, configuration when dealing with wide area links. While we all would like to have perfectly generic protocols and implementations, I fail to see Mr Martillo's points of contention as important or valid. > On the other hand, they may not be failings and by >addressing the issues, we will have proved to ourselves that what >we have done is correct. > >Frank Kastenholz >Clearpoint Research Corp. I would like to see a clear and well organized technical reason why I shouldn't implement PPP for my (bridge/router/brouter/dial-up ip) wide area links. I'd love to avoid the work involved in bringing up PPP from scratch, but the benefits appear great at the moment, the detractions few. As a user and implementor of WAN products, I need things that I can make work, as opposed to things that I cannot make work. -John Kalucki johnk@gordian.com Disclaimer: These are opinions. I haven't gone back over every single posting to the PPP list before composing this. I most definitely do not represent Gordian, Gordian's opinions or Gordian's intentions in this matter. From ietf-ppp-request@ucdavis.ucdavis.edu Tue Dec 17 11:59:15 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA23800; Tue, 17 Dec 91 11:22:24 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from azea.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA23511; Tue, 17 Dec 91 11:14:40 -0800 Received: by azea.clearpoint.com (4.1/1.34) id AA01148; Tue, 17 Dec 91 14:07:45 EST Date: Tue, 17 Dec 91 14:07:45 EST From: martillo@azea.clearpoint.com (Joachim Martillo @ azea) Message-Id: <9112171907.AA01148@azea.clearpoint.com> To: johnk@gordian.com Cc: ietf-ppp@ucdavis.edu, johnk@gordian.com, martillo@azea.clearpoint.com In-Reply-To: John Kalucki's message of Tue, 17 Dec 91 09:45:04 PST <9112171745.AA08258@geryon> Subject: SLIP throughput on T2500 Sender: ietf-ppp-request@ucdavis.edu From: johnk@gordian.com (John Kalucki) Date: Tue, 17 Dec 91 09:45:04 PST I have been reading this mail distribution for about a year now, mostly out of curiosity, and partially in case I am called to implement PPP in the near future. I don't consider myself close to the 'process' in any way. Let me also disclaim that I, in general, feel that routing over a wide area link is a superior solution to bridging. Only if you have but one routable protocol and no non-routable protocol. Despite giving him the benefit of the doubt, I've failed to grasp Mr Martillo's arguments against PPP. I've tried to penetrate the religious rantings, and I haven't seen much technical merit. He appears to be worrying about some issues that effectivly make Clearpoint's products difficult to use in conjunction with other vendor's bride/router products. No, our products interoperate with no problem with other bridging router products. We provide a parallel router filter bridge mode (broken mode) in which you can obtain exactly the same sorts of networking anomalies with Constellation products that you will get with any other paraller router filter bridge product. His example given to show the "brokeness" of PPP does not appear to be a likely, or even useful, configuration when dealing with wide area links. While we all would like to have perfectly generic protocols and implementations, I fail to see Mr Martillo's points of contention as important or valid. The example was an example of the brokenness of parallel router filter bridge implementations not the specific WAN problem. A specific PPP problem follows. Router --------------------------Bridge-Router | | | | | | | | | | | | | | | | L1 L2 L3 L4 The bridge router bridges between L1 and L2 while it routes between L3 and L4. If the router uses PPP-IP encapsulation on a packet, it goes to the router. If the router uses PPP-MAC encapsulation on a packet, it goes to the bridge. Thus in this case it is legitimate to send both IP and MAC encapsulation PPP frames. Suppose hosts H1, H2, H3 and H4 are attached respectively to L1, L2, L3 and L4. If the router sends only IP PPP encapsulation, H1 and H2 will not be reachable. If the router sends only MAC encapsulation, H3 and H4 will be unreachable. There is no mechanism for the router to maintain the level of detail so that it may know how to encapsulate packets destined for each host. Now I suppose the implementer could make an arbitray decision that in the IP address of H1, H2 and the PPP interface of the router indicate that these hosts are all attached to the same subnetwork, then MAC PPP encapsulation should be used. If the hosts are not attached to the same subnetwork then MAC IP encapsulation would be used. But maybe the bridge-router administrator decides to alter his network as follows. And in fact he does not even want his counterpart on the other end to know. Router --------------------------Bridge------L5-------Router | | | | | | | | | | | | | | | | L1 L2 L3 L4 Now of course the bridge will reject the IP encapsulation, but under the PPP spec the router has no obligation at this point to send those frames in the MAC encapsulation and may instead simply drop them. A major problem with PPP lies in this scenario. > On the other hand, they may not be failings and by >addressing the issues, we will have proved to ourselves that what >we have done is correct. > >Frank Kastenholz >Clearpoint Research Corp. I would like to see a clear and well organized technical reason why I shouldn't implement PPP for my (bridge/router/brouter/dial-up ip) wide area links. I'd love to avoid the work involved in bringing up PPP from scratch, but the benefits appear great at the moment, the detractions few. As a user and implementor of WAN products, I need things that I can make work, as opposed to things that I cannot make work. SLITHERNET works really well, interworks with SLITHER-F and SLITHER-X and is much simpler to implement. -John Kalucki johnk@gordian.com From ietf-ppp-request@ucdavis.ucdavis.edu Tue Dec 17 12:58:31 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA25955; Tue, 17 Dec 91 12:36:16 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from GORDIUS.GORDIAN.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA25394; Tue, 17 Dec 91 12:18:12 -0800 Received: from geryon (geryon.gordian.com) by gordius.gordian.com (4.1/SMI-4.1) id AA24465; Tue, 17 Dec 91 12:18:02 PST Received: by geryon (5.61/1.34) id AA08723; Tue, 17 Dec 91 12:17:13 -0800 From: johnk@gordian.com (John Kalucki) Message-Id: <9112172017.AA08723@geryon> To: ietf-ppp@ucdavis.edu Cc: johnk@gordian.com Subject: Re: SLIP throughput on T2500 In-Reply-To: Your message of Tue, 17 Dec 91 14:07:45 -0500. <9112171907.AA01148@azea.clearpoint.com> Date: Tue, 17 Dec 91 12:17:12 PST I do not want this to degenerate into a back and forth, but I'd like to address Mr Martillo's example. > > Sender: ietf-ppp-request@ucdavis.edu > From: johnk@gordian.com (John Kalucki) > Date: Tue, 17 Dec 91 09:45:04 PST > > I have been reading this mail distribution for about a year now, > mostly out of curiosity, and partially in case I am called to > implement PPP in the near future. I don't consider myself close to > the 'process' in any way. Let me also disclaim that I, in general, > feel that routing over a wide area link is a superior solution to > bridging. > >Only if you have but one routable protocol and no non-routable >protocol. Sigh, putting words into my mouth. Baiting. Whatever. In any case I think this bridges-are-better-because-they-work-with-everything view is a bit overstated. Currently there aren't all many protocols that are in use. I'd venture to say that if you purchased a bridge/router that did IP, IPX, DecNet, Appletalk, and Vines, you'd be pretty safe for the present and for some time in the future. Unroutable protocols (LAT) can be bridged, and by definition won't run into the problems given below, which are essentially bridge vs. routing issues. > His example given to show the > "brokeness" of PPP does not appear to be a likely, or even useful, > configuration when dealing with wide area links. While we all would > like to have perfectly generic protocols and implementations, I > fail to see Mr Martillo's points of contention as important or > valid. > >The example was an example of the brokenness of parallel router filter >bridge implementations not the specific WAN problem. > >A specific PPP problem follows. > >Router --------------------------Bridge-Router > | | | | > | | | | > | | | | > | | | | > L1 L2 L3 L4 > >The bridge router bridges between L1 and L2 while it routes between L3 >and L4. If the router uses PPP-IP encapsulation on a packet, it goes >to the router. If the router uses PPP-MAC encapsulation on a packet, >it goes to the bridge. I'm assuming that the entity on the right is a single unit bridge/router and there are still things that aren't clear to me. If the Bridge/Router on the right doesn't support IP routing, then it should be bridged on both sides, correct? If the router on the left can send MAC frames, it's a bridge also, correct? How would the router on the left make the mistake of bridging the IP packet anyway? This all appears to boil down to bridging and routing the same protocol over the same link. Doing this appears to be a recipe for disaster, no matter how you move the packets around. If you simply say, I'm always routing IP and bridging everything else over this link, the problem given goes away. You can even "bridge" locally amongst L1, L2, L3 and L4, assuming that they are on the same subnet. If they aren't, you have to route IP between them anyway. >But maybe the bridge-router administrator decides to alter his network >as follows. And in fact he does not even want his counterpart on the >other end to know. > >Router --------------------------Bridge------L5-------Router > | | | | > | | | | > | | | | > | | | | > L1 L2 L3 L4 In all networks there must be some level of management communication. The people connecting networks aren't enemies, but cooperating entities. Hiding complexity is good, but hiding it at the cost of interoperability doesn't make sense. You can't expect any one protocol to solve all issues involving non-communicative administrators. > >Now of course the bridge will reject the IP encapsulation, but under >the PPP spec the router has no obligation at this point to send those >frames in the MAC encapsulation and may instead simply drop them. A >major problem with PPP lies in this scenario. Although I don't know the inner workings of PPP, it seems that the problem here is that a bridge is talking to a router. A more sensible configuration would be a bridge talking to a bridge. This appears to boil down to the routing and bridging the same protocol on the same link problem. > I would like to see a clear and well organized technical reason > why I shouldn't implement PPP for my (bridge/router/brouter/dial-up > ip) wide area links. I'd love to avoid the work involved in bringing > up PPP from scratch, but the benefits appear great at the moment, > the detractions few. As a user and implementor of WAN products, I > need things that I can make work, as opposed to things that I cannot > make work. > > >SLITHERNET works really well, interworks with SLITHER-F and SLITHER-X >and is much simpler to implement. My last statement was "I need things that I can make work". I cannot make SLITHERNET work. Why? Because it doesn't run on any other vendor's router. -John Kalucki johnk@gordian.com From ietf-ppp-request@ucdavis.ucdavis.edu Tue Dec 17 13:01:56 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA26251; Tue, 17 Dec 91 12:49:36 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA25978; Tue, 17 Dec 91 12:37:39 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA06525; Tue, 17 Dec 91 12:35:39 PST Date: Tue, 17 Dec 91 12:35:39 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9112172035.AA06525@ray.lloyd.com> To: ietf-ppp@ucdavis.edu Subject: Joachim etc. Martillo I have received several messages from people requesting that messages from Joachim Martillo be filtered so that they do not have to read them. While I am not sure that mail from Sr. Martillo can be effectively filtered, we can remove him from the mailing list. Therefore I request general feedback from the group. 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 Dec 17 13:18:01 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA26360; Tue, 17 Dec 91 12:53:57 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SGI.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA25984; Tue, 17 Dec 91 12:37:54 -0800 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (911016.SGI/910110.SGI) for ietf-ppp@ucdavis.edu id AA22090; Tue, 17 Dec 91 12:36:23 -0800 Received: by rhyolite.wpd.sgi.com (911016.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@ucdavis.edu id AA06331; Tue, 17 Dec 91 12:36:22 -0800 Date: Tue, 17 Dec 91 12:36:22 -0800 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9112172036.AA06331@rhyolite.wpd.sgi.com> To: ietf-ppp@ucdavis.edu Subject: Re: SLIP throughput on T2500 > From martillo@azea.clearpoint.com Tue Dec 17 07:45:12 1991 > ... > There is a lot of > configuration that goes into a multiprotocol router/bridge to get it > to do precisely what the administrator wishes it to do. PPP is an > attempt to allow as much flexibility as possible without unnecessarily > forcing an administrator to do things one particular way. > > PPP by assuming a Parallel Router Filtering Bridge architecture makes > the configuration problem practically intractable. For years there have been companies building and selling boxes which "bridge" ethernets and other media through "encapsulating FDDI bridges". This is despite the fact that it is impossible to simply copy MAC frames between FDDI and other media. Somehow, those people figured out how to spread spanning tree or other information around. Somehow they bridge source-routed packets. Somehow, their devices were "plug-and-play" with no configuration problems. Most or all of those companies are switching to "translating bridges". > .... > If the ability to send and receive complete MAC frames is made > obligatory at the request of either end point, I will go away. This facility is now and always has been present. Simply "encapsulate" MAC frames and send them to the other side. True, until the idea has been shown good by virtual of a significant installed base, the other side will have to be prepared to decode the frames, and so would be a Clearpoint router. The extra bandwidth needed by encapsulating will be insignificant among all of the ethernet and token ring broadcasts and multicasts which are trying to squeeze from 10Mhz or 16Mhz down to 56KHz. > To tell the truth, I don't really see the need for face to face > meetings because e-mail is perfectly adequate for technical > discussion. > And as far as I can tell your idea of constructive contribution is > dotting the i's and crossing the t's on protocol methods which proved > themselves essentially unworkable at AT&T 20 years ago. Based on the email "technical discussions," if there is such a face to face meeting, please let me know. I'll sell tickets, provided the automatic rifle users are disarmed. I have not understood the technical part of the "technical discussion" from Clearpoint since the initial 2 or 3 messages. Those initial messages seemed to have something to say, although I found them a little prolix. The only technical point from in subsequent messages Clearpoint which I understand is that PPP should be discarded because it is "supid" "garbage", and that we should all switch to Sliternet. That would suite me. You router guys would go away and I could have a nice simple replacement for SLIP over async lines. No more HDLC framing nonsense. Simpler state machines. However, after all these years, you'll never hear me support such a motion. ---- > The correct way to handle the issue is for the link layer protocols to > assume that the circuit is there, and leave the circuit layer problem > to circuit layer software. In this formalism, leased lines are not a > special case for the link layer. I think this is a good position before sitting down to design the finite state machines. However, where do you put the FSM which creates and maintains the circuit? Where is the machinery to dial and re-dial the phone? Practically, what does it matter whether PPP is an implementation of one layer some called "link", or an implementation of two layers called "link" and "circuit"? Both are needed. Neither fits in the TCP/IP state machines. This is a mailing list of the Internet Engineering Task Force. The word "Internet" is not just coincidently similar to the IP in TCP/IP. That is good or bad, depending. It is indisputable. If PPP somehow manages to support "multi-protocol bridge/routers", it will be a novel broadening of scope. If the PPP group were run according to normal standards committee rules, wouldn't the whole question of non-IP packets belong to some other jurisdiction? Vernon Schryver, vjs@sgi.com From ietf-ppp-request@ucdavis.ucdavis.edu Tue Dec 17 14:20:51 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA28301; Tue, 17 Dec 91 14:03:47 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from abacus.sura.net by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA28072; Tue, 17 Dec 91 13:51:21 -0800 Received: by abacus.sura.net (5.65b/($Id: sendmail.cf,v 1.17 1991/02/11 14:07:23 jmalcolm Exp $)) id AA02497; Tue, 17 Dec 91 16:49:40 -0500 Date: Tue, 17 Dec 91 16:49:40 -0500 From: bjp@sura.net Message-Id: <9112172149.AA02497@abacus.sura.net> To: brian@lloyd.com, ietf-ppp@ucdavis.edu Subject: Re: Joachim etc. Martillo While I do not enjoy the sometimes endless slithernet-ppp "discussions" I strongly disagree with removing anyone from the mailing list that is writing something that remotely makes sense. (as opposed to mailing uuencoded gifs to the list) This strikes me as a dangerous precedant. Also I have no problem just deleting mail from people I feel are unreasonable without reading it: in fact MH can probably do it for you. So there seems to me to be no real reason to do it. Brad Passwaters (301)(982-3214) SURAnet Operations bjp@sura.net From ietf-ppp-request@ucdavis.ucdavis.edu Tue Dec 17 14:34:04 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA28694; Tue, 17 Dec 91 14:17:15 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA28545; Tue, 17 Dec 91 14:13:34 -0800 Received: by volitans.morningstar.com (5.65a/91111501) id AA18646; Tue, 17 Dec 91 17:11:00 -0500 Date: Tue, 17 Dec 91 17:11:00 -0500 From: Bob Sutterfield Message-Id: <9112172211.AA18646@volitans.morningstar.com> To: brian@lloyd.com Cc: ietf-ppp@ucdavis.edu In-Reply-To: Brian Lloyd's message of Tue, 17 Dec 91 12:35:39 PST <9112172035.AA06525@ray.lloyd.com> Subject: Joachim etc. Martillo Date: Tue, 17 Dec 91 12:35:39 PST From: brian@lloyd.com (Brian Lloyd) I have received several messages from people requesting that messages from Joachim Martillo be filtered so that they do not have to read them. While I am not sure that mail from Sr. Martillo can be effectively filtered, we can remove him from the mailing list. Therefore I request general feedback from the group. The first issues are technical: Removing somone from the list will not prevent h{im,er} from sending messages to the list, unless you install a filter in the list-forwarding mechanism that looks at the From: line and other important cues. This is feasible but aesthetically ugly. Let me know if you really want it, and I'll send you a real-life example of such a prior-restraint mechanism. The other issues are socio-legal: If you were to decide to remove me from this mailing list because I'm a little overweight and my beard is graying a little more each winter, my employer's legal staff could certainly raise a major league stink about being formally excluded from the IETF's supposedly open arena for standards development. Someone who is excluded because of interpersonal friction would have even better grounds for complaint, particularly since the entire network community is accustomed to interacting via electronic media with individuals who, shall we say, hold forth strongly for their own viewpoint. I'm no lawyer, and I don't even play one on television, but excluding and pre-filtering sounds like a bad idea to me. For me, Sr. Martillo's contributions to these discussions have gone from mildly interesting, to morbidly amusing, to irritating. They're now almost completely ignored. You needn't install a filter on the entire mailing list for my benefit, my "d" key does quite nicely already. From ietf-ppp-request@ucdavis.ucdavis.edu Tue Dec 17 15:16:37 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA29593; Tue, 17 Dec 91 14:50:09 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from babyoil.ftp.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA29309; Tue, 17 Dec 91 14:41:34 -0800 Received: from stev.d-cell.ftp.com by ftp.com via PCMAIL with DMSP id AA26201; Tue, 17 Dec 91 17:42:53 -0500 Date: Tue, 17 Dec 91 17:42:53 -0500 Message-Id: <9112172242.AA26201@ftp.com> To: brian@lloyd.com Subject: Re: Joachim etc. Martillo From: stev@ftp.com (stev knowles) Cc: ietf-ppp@ucdavis.edu Repository: babyoil.ftp.com Originating-Client: d-cell.ftp.com while i respect a person's right to participate in a group, i would suggest you flush joachim {} from the list. you *realize*, however, that you cannot stop his mail unless you have all the PPP mail go to one person, who filters out the messages, before forwarding them on. someone shoudl tell clearpoint (some VP there, i would suppose) about it if it happens, so that they can place someone else on the list if they are interested. stev knowles stev@ftp.com vp engineering, ftp software From ietf-ppp-request@ucdavis.ucdavis.edu Tue Dec 17 15:45:19 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00518; Tue, 17 Dec 91 15:18:31 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SGI.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00184; Tue, 17 Dec 91 15:07:56 -0800 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (911016.SGI/910110.SGI) for ietf-ppp@ucdavis.edu id AA01467; Tue, 17 Dec 91 15:06:26 -0800 Received: by rhyolite.wpd.sgi.com (911016.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@ucdavis.edu id AA06725; Tue, 17 Dec 91 15:06:25 -0800 Date: Tue, 17 Dec 91 15:06:25 -0800 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9112172306.AA06725@rhyolite.wpd.sgi.com> To: brian@lloyd.com Cc: ietf-ppp@ucdavis.edu Subject: Re: Joachim etc. Martillo In-Reply-To: your article News-Path: sgi!ucdavis.edu!ietf-ppp-request > Therefore I request general feedback from the group. > > 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 I oppose removing anyone from this or any other public newsgroup. Anyone who is allowed to roam the streets should be allowed to roam the network. The better solution would be for more of us, including me, to ignore to the irritant. My excuse for not taking that advice is that I sometimes really do try to discover and understand the technical points. Vernon Schryver, vjs@sgi.com From ietf-ppp-request@ucdavis.ucdavis.edu Tue Dec 17 17:06:41 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA03172; Tue, 17 Dec 91 16:47:50 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from azea.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02710; Tue, 17 Dec 91 16:31:35 -0800 Received: by azea.clearpoint.com (4.1/1.34) id AA01339; Tue, 17 Dec 91 19:25:17 EST Date: Tue, 17 Dec 91 19:25:17 EST From: martillo@azea.clearpoint.com (Joachim Martillo @ azea) Message-Id: <9112180025.AA01339@azea.clearpoint.com> To: vjs@rhyolite.wpd.sgi.com Cc: ietf-ppp@ucdavis.edu, martillo@azea.clearpoint.com In-Reply-To: Vernon Schryver's message of Tue, 17 Dec 91 01:30:05 -0800 <9112170930.AA05460@rhyolite.wpd.sgi.com> Subject: SLIP throughput on T2500 Sender: ietf-ppp-request@ucdavis.edu Date: Tue, 17 Dec 91 01:30:05 -0800 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) > From: martillo@azea.clearpoint.com (Joachim Martillo @ azea) > ... > Wow, I don't have to visit my family in Syria to hear paranoic > conspiratorial fantasies anymore.... > Oh, the IP purists suddenly think it is okay to break architecture. > ... > .... Schryver's justification for the > stupidity of PPP is an example of attempting to baffle us with > irrelevant nonsense when he has no cogent technical rejoinder. > ... > And of course if baffling them with nonsense might not work and one is > incapable of valid technical argumentation, there is always > intimidation by implicit and explicit threats. > 1) This sort of intimidation does not work against someone who has > lived for many years in a part of the world where people intimidate > you by shoving a Kalashnikov up your nose. > 2) Clearpoint battles DEC before breakfast and triumphs despite the > common wisdom for relaxation in the afternoon. > 3) We have more strategic depth than the other networking companies because > we also sell memory boards and subsystems. As a consequence, we don't > have to strong arm people into perhaps unnecessary networking solutions > but have the freedom to develop correct solutions in any of our areas > of endeavor and sell customers the solution to their performance problems > which may actually be something other than a networking solution. Ignorant > threats will not dissuade us from a business strategy which has proven > rather successful for us. > Joachim Carlo Santos Martillo Ajami I have finally realized that the "Clearpoint" represented by the person signed above is the same which I understood made good 3rd party memory products. This is unfortunate, because no company which takes my advice will ever buy anything from or sell or give anything to this Clearpoint. A trifle oversensitive aren't you? We are after all talking about a serial line communications encapsulation and not about your mother. No company which allows its employees to indulge in such public ad homiem "technical discussions" would be capable of useful customer support. If I say PPP is wrong because Shryver beats his wife, such an argument is an ad hominem argument. If I call PPP stupid or claim that a given argument is not technically valid, such an argument is not an ad hominem argument. Any company whose main representative to a technical standards organization I did not know we had a main representative to any technical standards organization. central to its business consistently conducts technical discussions like ^^^^^^^ Providing quality at low cost, customer satisfaction, solutions to hard problems and technical leadership is the focus of Clearpoint's business not technical standards organizations. Clearpoint concentrates on essentials. this would be a joy when dealing with a bad board or dead router. Can you imagine the pleasure of cooperating with Clearpoint on the development of their Slithernet protocol, product, or whatever? I will make a PC-based Slithernet implementation available if anyone desires, and I am willing to talk to anyone about it if they want. In any case, as far as I can tell, Clearpoint strives to be direct, correct and helpful. Clearpoint has promised quality to customers but doesn't cringe (especially not to DEC). Would you prefer that if we were to perceive a real problem, we remained silent because of intimidation originating in the "It's my ball" syndrome (I have read Padlipsky too). This is not a threat, but a description of my professional evaluation of the management of a particular commercial organization. This evalution may not materially affect Clearpoint. I do not write letters to the editor nor columns in the trade press, but I do have some responsibility for advising and consenting to various business activities. Such evaluations are one kind that I, like other senior developers and designers on this mailing list, been involved in over these last years (many more than 16, but let's not get down to bragging about career duration or personal obsolence). When dealing with a vendor, you figure out from the evidence at hand how they will treat you after they have your P.O. Well, I personally won't grovel or be intimidated but I will analyze needs and problems to the limits and provide a straightforward clear evaluation and recommendation (to the point of bluntness if necessary). When thinking about products, you predict how the other guys and your present and future customers will react. Anyone company which doesn't pay attention to what new products will do to their market either has no existing products or is soon out of business. I dump on PPP precisely because I do pay attention to it. It would not be the first time nonsense came out of the IETF. I vaguely remember reading a host requirements document which demanded that a conformant internet end host provide a configurable hop count capability and other random features totally irrelevant to devices like network printers and other special purpose devices which attach to the internet as end hosts. I guess you could require that all network devices support command interpreters and simple to complex operating systems but such requirements do seem rather excessive. Since this is not a lecture on elementary Product Marketing, and since many of us have old experiences too painful to remember and recent ones which cannot be discussed publicly, I'll leave it at that. How tantalizingly cryptic! Vernon Schryver. From ietf-ppp-request@ucdavis.ucdavis.edu Tue Dec 17 18:01:36 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA04515; Tue, 17 Dec 91 17:37:28 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from azea.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA04203; Tue, 17 Dec 91 17:24:16 -0800 Received: by azea.clearpoint.com (4.1/1.34) id AA01348; Tue, 17 Dec 91 20:11:07 EST Date: Tue, 17 Dec 91 20:11:07 EST From: martillo@azea.clearpoint.com (Joachim Martillo @ azea) Message-Id: <9112180111.AA01348@azea.clearpoint.com> To: karl@crappie.morningstar.com Cc: kasten@europa.clearpoint.com, ietf-ppp@ucdavis.edu, vjs@rhyolite.wpd.sgi.com, martillo@azea.clearpoint.com In-Reply-To: Karl Fox's message of Tue, 17 Dec 91 11:15:31 -0500 <9112171615.AA00929@crappie.morningstar.com> Subject: SLIP throughput on T2500 Sender: ietf-ppp-request@ucdavis.edu Date: Tue, 17 Dec 91 11:15:31 -0500 From: Karl Fox What you say is only partially true -- Mr. Martillo's earlier messages to the ietf-ppp list, while abrasive, *did* contain valid and cogent information. Careful reading of his latest few messages, however, show no new concepts, significant personal attacks and insults, and frequent misunderstanding and misinterpretation of the messages to which he is responding. Like it or not, his persona sheds a bright light on your company. I'm glad my employees are more controlled in their public speech. Karl Fox, V.P. of Engineering, Morning Star Technologies +1 800 558 7827 In this discussion, I have discussed the following issues: 1) Is PPP full-featured or a mish-mash? 2) Reasons why router/bridge vendors might be less than enthusiastic about PPP. 3) The usefulness of multiprotocol routers for WAN interconnection of geographically distant network sites. 4) Architecture breaking by PPP. 5) The different meanings of wide-area networking. 6) Interworking among point-to-point communications systems. 7) The PPP reject mechanism. 8) Parallel router filtering bridge [PRFB] architectures versus logical subbridge [LSB] architectures. 9) Cisco hybrid bridge router architecture. 10) Routing anomalies associated with PRFB architectures in the context of STP, SR and SRT bridges. 11) Performance considerations in performing routing and bridging. 12) Corporate exposure or lack thereof. 13) Should the receiver or transmitter decide how to encapsulate frames on a PPP link? 14) Viewing a bridge or router as a very high speed network system built around the internal bus which is functionally equivalent to an ethernet bus. 15) Administrative issues associated with PPP. 16) Configruation issues. 17) Frame relay versus PPP. 18) How to fix PPP. 19) how to handle CSC and link layer setup. 20) Constellation bridge/router modes and interoperability. 21) A PPP interconnect problem. These items represent a reasonable technical contribution to this forum. I have to wonder why Fox does not consider such contribution valid. If I am not mistaken, Morningstar pushes a number of PPP based products. Perhaps there is a stronger concern for recouping investment than either technical correctness or serving customer needs. As for controlled speech, senior management increases the value of employees to the firm and to the employees themselves by encouraging the employees to overcome those fears which hinder employee effectiveness. Unfortunately, for some types of management control of employees via intimidation is more important than increasing employee effectiveness. I would not boast about the controlled speech of my employees. Such controlled speech may reflect badly on management techniques used at a firm. Joachim Carlo Santos Martillo Ajami From ietf-ppp-request@ucdavis.ucdavis.edu Tue Dec 17 20:48:22 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA08938; Tue, 17 Dec 91 20:31:11 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA08653; Tue, 17 Dec 91 20:19:13 -0800 Received: from crappie.morningstar.com by volitans.morningstar.com (5.65a/91111501) id AA19385; Tue, 17 Dec 91 23:17:27 -0500 Received: by crappie.morningstar.com (5.65a/910712902) id AA02153; Tue, 17 Dec 91 23:16:45 -0500 Date: Tue, 17 Dec 91 23:16:45 -0500 From: Karl Fox Message-Id: <9112180416.AA02153@crappie.morningstar.com> To: martillo@azea.clearpoint.com (Joachim Martillo @ azea) Cc: karl@crappie.MorningStar.Com, kasten@europa.clearpoint.com, ietf-ppp@ucdavis.edu, vjs@rhyolite.wpd.sgi.com In-Reply-To: <9112180110.AA01347@azea.clearpoint.com> Subject: SLIP throughput on T2500 Joachim Martillo @ azea writes: > Unfortunately, for some types of management control of employees via > intimidation is more important than increasing employee effectiveness. > > I would not boast about the controlled speech of my employees. Such > controlled speech may reflect badly on management techniques used at > a firm. Again, you misunderstand. I was talking about *self* control, not mind control by upper management. Verbal incontinence is no virtue. From ietf-ppp-request@ucdavis.ucdavis.edu Tue Dec 17 22:15:23 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10616; Tue, 17 Dec 91 22:00:13 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10397; Tue, 17 Dec 91 21:46:54 -0800 Received: from roughy.morningstar.com by volitans.morningstar.com (5.65a/91111501) id AA19939; Wed, 18 Dec 91 00:45:06 -0500 Received: by roughy.morningstar.com (5.65a/910712902) id AA07991; Wed, 18 Dec 91 00:44:11 -0500 Date: Wed, 18 Dec 91 00:44:11 -0500 From: Bob Sutterfield Message-Id: <9112180544.AA07991@roughy.morningstar.com> To: martillo@azea.clearpoint.com Cc: karl@MorningStar.Com, kasten@europa.clearpoint.com, ietf-ppp@ucdavis.edu, vjs@rhyolite.wpd.sgi.com In-Reply-To: martillo@azea.clearpoint.com (Joachim Martillo's message of Tue, 17 Dec 91 20:11:07 EST <9112180111.AA01348@azea.clearpoint.com> Subject: SLIP throughput on T2500 (I keep telling myself to stay out of this... I keep telling myself to stay out of this...) Date: Tue, 17 Dec 91 20:11:07 EST From: martillo@azea.clearpoint.com (Joachim Martillo @ azea) Date: Tue, 17 Dec 91 11:15:31 -0500 From: Karl Fox Like it or not, [Martillo's] persona sheds a bright light on [Clearpoint]. I'm glad my employees are more controlled in their public speech. Unfortunately, for some types of management control of employees via intimidation is more important than increasing employee effectiveness. (*snicker*) Karl? Controlling? Intimidating? To me? (*snicker*) I would not boast about the controlled speech of my employees. Such controlled speech may reflect badly on management techniques used at a firm. I think what Karl meant, and what most everyone else would have read, was "self-controlled". Our management trusts its employees to represent themselves and the company well in public, and has never received any indication from outside that we might be creating a negative impression among our collaborators, customers, or competitors. From ietf-ppp-request@ucdavis.ucdavis.edu Wed Dec 18 05:31:40 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18693; Wed, 18 Dec 91 05:15:23 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from TIS.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18523; Wed, 18 Dec 91 05:08:08 -0800 Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA28135; Wed, 18 Dec 91 08:06:54 EST Message-Id: <9112181306.AA28135@TIS.COM> To: stev@ftp.com (stev knowles) Cc: brian@lloyd.com, balenson@TIS.COM, ietf-ppp@ucdavis.edu Subject: Re: minutes of PPPWG meeting In-Reply-To: 's message of Mon, 25 Nov 91 12:05:49 EST. <9111251705.AA20341@ftp.com> Date: Wed, 18 Dec 91 08:06:53 -0500 From: James M Galvin i'll tell you folks what i told the SNMP security boyz. if you dont tell people who to export the code with MD5 in it, there are people (like ftp) who will not implement it. it will require too much overhead to find out what is going on with exporting it, and we dont have the resources to keep and police two packages. This is an old note, but I don't remember seeing a reply so I thought I would do that. To the best of my knowledge (noting I am not a lawyer), there are no export restrictions on MD5. It is a hash algorithm and its usage in PPP should not restrict its exportability. I really wish I could give you a definitive answer. Part of the problem right now is the rules may change a bit, sooner rather than later. I think that Vint's document will be helpful, but I know he is reluctant to release anything until he feels he knows as much as he can. Jim From ietf-ppp-request@ucdavis.ucdavis.edu Wed Dec 18 11:36:51 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA27922; Wed, 18 Dec 91 11:16:50 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from europa.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA27063; Wed, 18 Dec 91 10:48:24 -0800 Received: by europa.clearpoint.com (4.1/1.34) id AA21991; Wed, 18 Dec 91 13:41:55 EST Date: Wed, 18 Dec 91 13:41:55 EST From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9112181841.AA21991@europa.clearpoint.com> To: ietf-ppp@ucdavis.edu Subject: Re: Joachim etc. Martillo One person's freedom of speech is not another person's obligation to listen. If you truly believe that what someone is saying is worthless drivel that is on a par with the rantings of used car salesmen and congressmen, you are free to ignore that drivel. Drivel and other such non-sequiturs do not require responses. Generally if you ignore it, it goes away. And yes, Clearpoint does have another person (or two) on the mailing list -- otherwise how would I be aware of this brou-ha-ha-ha-ha-ha and make the responses that I do? As to MY opinion on the technical parts of the discussion -- which is NOT served by talking about placing Kalishnikovs up peoples noses, or taking other people off mailing lists because we don't like them -- I do not really care. I believe that Joachim raises some valid points in basically claiming that PPP is not a full function, general purpose, does everything, serial line-WAN protocol. However, I do not think that we were ever attempting to make one of these things. Perhaps what has been blurred over the many years of discussion is the goals of this effort. In fact, I believe that PPP is not meant to be a does-everything protocol. The effort was started to solve the problem of interoperability among routers and dial-up IP hosts. In these environments there are a few factors that constrain the problem in such a way that a general-purpose solution is NOT needed: 1) The links are all truly of a point-to-point nature. The serial lines, when taken as a collection, are not simply another network. The serial lines are simply the links that connect the switching devices (routers). The switching of packets through the internetwork is done by the routers, not by some level-2 switching scheme. 2) PPP Links have two nodes on them, one at each end. The issues of addressing the packet, data-link level switching, etc, do not apply here. The assumption was made that if I put a packet in at this end, it is truly meant to be received by the box at the other end. I seem to recall a discussion several years ago about expanding PPP to cover "multi-host" link-level networks. It was dropped because we felt that PPP did not expand well into this arena. I do not recall the reasons, someone would have to grovel through the archives.... 3) The ends of the links are somewhat controlled in what they can produce. They also tend to be controlled by administrations that can do manually the configuration that Joachim has been arguing should be done automatically 4) The model of bridges and routers has evolved so that bridging is a peer of routing -- basically one routes what one can route, and one bridges the rest. This allows a certain solution form that; one that is inconsistant with Joachim's. Frank Kastenholz Clearpoint Research Corp. From ietf-ppp-request@ucdavis.ucdavis.edu Wed Dec 18 23:33:28 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA12541; Wed, 18 Dec 91 22:18:17 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA12348; Wed, 18 Dec 91 22:04:58 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA07682; Wed, 18 Dec 91 22:03:01 PST Date: Wed, 18 Dec 91 22:03:01 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9112190603.AA07682@ray.lloyd.com> To: ietf-ppp@ucdavis.edu Subject: Mr. Martillo I received numerous message regarding my request for input about removing Mr. Martillo from the list. FYI, about a third of the messages said "remove him". Two thirds believe in the First Amendment; that he has the right to talk and everyone else has the option to ignore through use of the "delete" key. I happen to agree with the latter sentiment. 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 Dec 19 04:32:13 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA16562; Thu, 19 Dec 91 04:15:44 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from azea.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA16475; Thu, 19 Dec 91 04:12:39 -0800 Received: by azea.clearpoint.com (4.1/1.34) id AA01845; Thu, 19 Dec 91 07:05:39 EST Date: Thu, 19 Dec 91 07:05:39 EST From: martillo@azea.clearpoint.com (Joachim Martillo @ azea) Message-Id: <9112191205.AA01845@azea.clearpoint.com> To: brian@lloyd.com Cc: kasten@europa.clearpoint.com, ietf-ppp@ucdavis.edu, martillo@azea.clearpoint.com In-Reply-To: Brian Lloyd's message of Wed, 18 Dec 91 22:20:21 PST <9112190620.AA07696@ray.lloyd.com> Subject: Joachim etc. Martillo Sender: ietf-ppp-request@ucdavis.edu Date: Wed, 18 Dec 91 22:20:21 PST From: brian@lloyd.com (Brian Lloyd) Thanks for the note. It is often difficult to see the content for the tone. No, PPP is not perfect nor does it solve all the problems. In the mean time we will continue to try to make it work in as many point-to-point environments as possible. 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 Since tone has become an issue, reviewing Lloyd's tone is probably worthwhile. Here is Lloyd's first reply to me. Date: Fri, 13 Dec 91 20:16:37 PST From: brian@lloyd.com (Brian Lloyd) To: martillo@azea.clearpoint.com Cc: vjs@rhyolite.wpd.sgi.com, olling@taeko.jnoc.go.jp, news.comp.protocols.ppp@rhyolite.wpd.sgi.com, ietf-ppp@ucdavis.edu, martillo@azea.clearpoint.com In-Reply-To: martillo@azea.clearpoint.com (Joachim Martillo's message of Fri, 13 Dec 91 14:30:33 EST <9112131930.AA03332@azea.clearpoint.com> Subject: SLIP throughput on T2500 Reply-To: brian@lloyd.com Sr. Joachim Carlo Santos Martillo Ajami, ^^ Patronizing over politeness. Again you rant that PPP is broken. I respect your opinion. However, ^^^^ ^^^^^^^ So I am rantining. Sure you do. I am beginning to become annoyed that you have, once again, transmitted a message to the same group who have heard your complaints before -- repeatedly. I have taken time to talk with you (at Interop) and tried to explain how PPP will work for both routers and bridges. No you took time to lecture me quite pedantically as if I were a child. I attempted to explain how a device may negotiate with its peer which NCPs it will use (transmission of MAC layer packets for bridging included), and how a device can force its peer to perform routing, bridging, or both, using the same link. You would not listen. I knew perfectly well how the negotiating procedure worked. The problem lies not in the negotiating procedure but in the limited range of responses as I have repeatedly pointed out, a criticism which you continuously ignore. As for PPP being an encapsulation, it is. As for being a protocol, it is that too. A protocol describes a way to do something. It is very clear what the process is for bringing up a link and then negotiating what you wish to send over it. Now I will ask you again: please participate in the PPP specification process in a productive manner or please leave us alone. Excuse me, but if you continue to engage in this patronizing overpoliteness and continue to insult me, I don't quite see how it is possible to participate meaningfully in this forum. Maybe my tone could be better but Lloyd is totally disingenous. We are trying to get work done and you continue to joggle our collective elbow. 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 Now as to getting router/bridge vendors to fully commit resources (especially in a miserable economy) to implementing PPP, you have to provide an incentive. PPP by breaking routing/path selection procedures and by making the implementation of a switching fabric communications subnet and load-sharing practically impossible provides considerably less functionality than what Clearpoint and probably the other router and bridge vendors have in place. As a consequence, committing resources to developing such a functionality is hard to justify especially when we have lots of functionality which we would like to add. Anyway, here is my original note to which Lloyd is replying. To me the tone is not nearly as obnoxious as Lloyd's and I am trying unlike Lloyd to provide some useful technical insight. Date: Fri, 13 Dec 91 14:30:33 EST From: martillo (Joachim Martillo @ azea) To: vjs@rhyolite.wpd.sgi.com Cc: olling@taeko.jnoc.go.jp, news.comp.protocols.ppp@rhyolite.wpd.sgi.com, ietf-ppp@ucdavis.edu, martillo In-Reply-To: Vernon Schryver's message of Sun, 8 Dec 91 12:15:59 -0800 <9112082015.AA28241@rhyolite.wpd.sgi.com> Subject: SLIP throughput on T2500 > On 7 Dec 91 20:04:11 GMT in comp.protocols.ppp, you wrote: > >One of these newsgroups is comp.protocols.ppp. PPP is different from SLIP. > In these groups, it's interesting reading about these two, but is there > anything I can find (via ftp or otherwise) that backs up a level and says > what ppp and slip *do* and why one might be better suited for a particular > application than another? > Thanks in advance, > Clifford Olling Japan National Oil Corporation ~~$@@PL}8xCD~~(J So, here's my attempt: -PPP is full featured point-to-point protocol intended to link routers over high speed sync. lines as well as hosts over async modems. PPP includes IP address assignment mechanisms, HDLC style checksums, authentication gadgets, connection re-establishment mechanisms, mechanisms to negotiate mutually agreed subsets, support for reduced character sets, support for many non-IP protocols, and other things. A single "protocol" which includes all this random stuff in the manner of PPP is more correctly described as a hodge-podge than as fully featured. Also, PPP is perhaps more correctly described as a link-layer encapsulation than as a link-layer protocol. Link layer protocols like ethernet for example have a frame format, a medium access arbitration procedure and a method for path selection between end hosts attached to the link layer. Now, one could argue that PPP does provide for extremely trivial medium access arbitration (there are separate receive and transmit circuits) and that PPP provides trivial path selection (there is but one path to select), but considering PPP anything more than a link-layer encapsulation with delusions of being a protocol is really pushing it. -I think the great advantage of PPP is the hope that wide area router vendors will adopt it, allowing us to mix and match router vendors on a single dedicated line. There is evidence not all router vendors consider this desirable. This statement is simply unfair. Router (bridge and hybrid router) vendors do not necessarily consider interoperability across point to point links a bad feature to offer. PPP is the feature which is less than desirable as an offering. If more than one type of routable traffic needs to be interconnected across a WAN link, putting a multiprotocol router which supports PPP at both ends of the WAN link is a silly way to achieve wide area interconnection between two geographically distant sites. What happens if there is network traffic which the routers can't route? Do you go to the router vendor and ask for an upgrade for which he will charge you? And of course, he might not even have an upgrade to sell to you. Of course, there is the solution which several hybrid router vendors supply which is to route all routable traffic and to bridge all other traffic. Such a solution (the parallel router filtering bridge) breaks boths the DOD Internet Architecture and the ISO OSI architecture, and can easily lead to the creation of network topologies which neither route nor bridge correctly. PPP (and MPI/FR) by incorrectly treating MAC frames and Network Packets as operating at the same protocol layer is actually designed to break both the DOD Internet Architecture and the ISO OSI architecture in the same way that the parallel router filtering bridge breaks these architectures. -The main disadvantage of SLIP is its simplicity. If you want more than IP over a modem, you must roll your own protocol. Its simplicity has also encouraged the appearance of incompatible extensions. Actually, SLIP does one thing and does it right. A similar claim cannot be made about PPP. There is no evidence in the RFCs relating to PPP (and MPI/FR)that the designers ever truly chose one thing to do right. The problem of Wide-Area interconnect actually refers to three quite separate problems. 1) One problem is point-to-point end host connectivity, which SLIP provides very well between two IP end hosts, an IP end host and an IP router or between two IP routers. 2) The second problem is providing universal end host interconnect, which X.25 networks provides between terminals and computers at remote sites. 3) The third problem is providing universal subnetwork interconnect, which is basically what the ARPANET used to provide, and what NSFNET and other wide area provides provide unfortunately only in the context of IP. PPP never really addresses any of these problems explicitly and as a consequence rather botches as a solution to any of them. In fact since PPP provides no means of path selection of multiple wide area hops or between alternate routes among wide area hops, PPP cannot provide any solution to the third problem at all. In view of the general trend of network evolution, the third problem is really the problem which customers want solved and in fact is the problem which router vendors address with their products. So there really should be no surprise that router (bridge and hybrid bridge router) vendors are less than interested in PPP. SLITHERNET is a hack but unlike PPP really does address the third problem which is essentially the provision of a wide area switching fabric communications subnet with alternate routing and fault tolerance capabilities (with correct network topology design). SLITHER-F and SLITHER-X provide the same capabilities on frame relay and X.25 networks. In fact, a box which supports SLITHERNET, SLITHER-X and SLITHER-F provides transparent interworking between point-to-point leased, X.25 networks and Frame Relay networks. Thus by concentrating on solving the third problem correctly, SLITHERNET solves problems 1 and 2 (these problems are degenerate cases of problem 3) as well as the interworking problem which many network managers face now or in the near future. Now I would be willing to experiment with interoperability with the products of other vendors that use either SLITHERNET or some similar correctly defined link-layer protocol (assuming the similar protocol is not tremendously difficult to implement). But PPP is essentially a non-starter except as a solution for some very specific topologically trivial problems of low speed asynchronous interconnect. Vernon Schryver, vjs@sgi.com Joachim Carlo Santos Martillo Ajami (martillo@azea.clearpoint.com) From ietf-ppp-request@ucdavis.ucdavis.edu Thu Dec 19 06:00:38 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA17825; Thu, 19 Dec 91 05:46:45 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from azea.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA17404; Thu, 19 Dec 91 05:33:15 -0800 Received: by azea.clearpoint.com (4.1/1.34) id AA01884; Thu, 19 Dec 91 08:25:38 EST Date: Thu, 19 Dec 91 08:25:38 EST From: martillo@azea.clearpoint.com (Joachim Martillo @ azea) Message-Id: <9112191325.AA01884@azea.clearpoint.com> To: johnk@gordian.com Cc: ietf-ppp@ucdavis.edu, johnk@gordian.com, martillo@azea.clearpoint.com, tcp-ip@nic.ddn.mil In-Reply-To: John Kalucki's message of Tue, 17 Dec 91 12:17:12 PST <9112172017.AA08723@geryon> Subject: SLIP throughput on T2500 Sender: ietf-ppp-request@ucdavis.edu From: johnk@gordian.com (John Kalucki) Date: Tue, 17 Dec 91 12:17:12 PST I do not want this to degenerate into a back and forth, but I'd like to address Mr Martillo's example. > Sender: ietf-ppp-request@ucdavis.edu > From: johnk@gordian.com (John Kalucki) > Date: Tue, 17 Dec 91 09:45:04 PST > I have been reading this mail distribution for about a year now, > mostly out of curiosity, and partially in case I am called to > implement PPP in the near future. I don't consider myself close to > the 'process' in any way. Let me also disclaim that I, in general, > feel that routing over a wide area link is a superior solution to > bridging. >Only if you have but one routable protocol and no non-routable >protocol. Sigh, putting words into my mouth. Baiting. I merely stated the conditions under which routing over a wide area link is a superior solution to bridging. If I had, "So John Kalucki thinks .....," then I would have been putting words in your mouth. And the comment only represents baiting, if you have some deep-seated religious or psychological biases against bridges. From the standpoint of our (router vendor) businesses, it might be better if customers bought more powerful more expensive multiprotocol routers for wide-area interconnection, but I am not personally enthused with using two multiprotocol routers for wide-area interconnection because it seems like expensive overkill in comparison with a couple of bridges. Whatever. In any case I think this bridges-are-better-because-they-work-with-everything view is a bit overstated. I have to point out that I hadn't mentioned bridges in the original article. Currently there aren't all many protocols that are in use. I'd venture to say that if you purchased a bridge/router that did IP, IPX, DecNet, Appletalk, and Vines, you'd be pretty safe for the present and for some time in the future. Unless you have to deal with SNA, OSI and a lot of the less well-known but still rather frequently encountered protocols used in materials handling, manufacturing, data acquisition and many real-world environments. Unroutable protocols (LAT) can be bridged, and by definition won't run into the problems given below, which are essentially bridge vs. routing issues. Actually, I see nothing wrong with either bridging or routing. Both are use interconnection technologies and have their proper applications. The issue is not bridging versus routing but how to architect a hybrid bridge router and the assumptions which PPP, MPI/FR and some of the other proposals make about hybrid bridge router design. > His example given to show the > "brokeness" of PPP does not appear to be a likely, or even useful, > configuration when dealing with wide area links. While we all would > like to have perfectly generic protocols and implementations, I > fail to see Mr Martillo's points of contention as important or > valid. >The example was an example of the brokenness of parallel router filter >bridge implementations not the specific WAN problem. The example, as it was stated, pointed out that a network built from bridge-routers which bridge all protocols not routed will possibly run into routing/path selection anomalies (i.e. the network will not function correctly), if 1) all the bridge-routers do not route the exact same suite of protocols and if 2) the network contains any pure MAC bridges. There may also be problems with some topologies which contain pure routers as well as hybrid bridge routers. The problem arises because routers and bridges operating at different protocol layers do not necessarily have the same view of network connectivity. In the STP bridge case, a router might believe a route exists through a port which is blocked at the MAC layer. In the SRT and SR case, different views of network connectivity might lead to packets getting stuck in routing loops. >A specific PPP problem follows. >Router --------------------------Bridge-Router > | | | | > | | | | > | | | | > | | | | > L1 L2 L3 L4 >The bridge router bridges between L1 and L2 while it routes between L3 >and L4. If the router uses PPP-IP encapsulation on a packet, it goes >to the router. If the router uses PPP-MAC encapsulation on a packet, >it goes to the bridge. I'm assuming that the entity on the right is a single unit bridge/router and there are still things that aren't clear to me. If the Bridge/Router on the right doesn't support IP routing, then it should be bridged on both sides, correct? The device on the right is supposed to support bridging and routing. I don't understant the comment about bridging on both sides. In a pure ethernet case interconnecting bridges and routers make perfect sense. Bridges interoperate with routers by being transparent to the routers and the following topology makes perfect sense. Router---------------Bridge---------------Router If the router on the left can send MAC frames, it's a bridge also, correct? Why? Routers generally transmit IP packets encapsulated in MAC frames. PPP and MPI/FR just specify unusual behavior. How would the router on the left make the mistake of bridging the IP packet anyway? Under PPP and MPI/FR the transmitter might have the option of either transmitting an IP packet according to the IP encapsulation or according to the MAC encapsulation, but there is no obvious procedure by which the transmitter may choose which encapsulation to use. In such a case, choosing the wrong encapsulation seems possible. This all appears to boil down to bridging and routing the same protocol over the same link. Actually bridging and routing frames on ethernet links is very common. But on ethernet links the bridges and routers use the same encapsulation which makes correct interoperation possible. With PPP (and MPI/FR) bridges and routers do not use the same encapsulation which can break path selection/routing. Doing this appears to be a recipe for disaster, no matter how you move the packets around. No, it is only a recipe for disaster according to the PPP forwarding scheme. If you simply say, I'm always routing IP and bridging everything else over this link, the problem given goes away. You can even "bridge" locally amongst L1, L2, L3 and L4, assuming that they are on the same subnet. If they aren't, you have to route IP between them anyway. But the administration on the right might want three IP subnetworks where one subnetwork corresponds to L1+L2+the WAN link, another corresponds to L3 and the 3rd corresponds to L4. >But maybe the bridge-router administrator decides to alter his network >as follows. And in fact he does not even want his counterpart on the >other end to know. >Router --------------------------Bridge------L5-------Router > | | | | > | | | | > | | | | > | | | | > L1 L2 L3 L4 In all networks there must be some level of management communication. The people connecting networks aren't enemies, but cooperating entities. Hiding complexity is good, but hiding it at the cost of interoperability doesn't make sense. You can't expect any one protocol to solve all issues involving non-communicative administrators. If the WAN link had been an etherlink the substitution would have worked seamlessly. There is no real reason for more work to be required when a WAN link replaces an etherlink. And it might not be a question of mere non-communicativeness. The subnetwork spanning L1 and L2 might be in some sense less secure and more open to the outside world and the routing functionality is interposed between this subnetwork and the subnetworks on L3 and L4 in order to provide some sort of filtering. If security is the point, the network administrator might not be allowed to describe to his peers how his network is set up. >Now of course the bridge will reject the IP encapsulation, but under >the PPP spec the router has no obligation at this point to send those >frames in the MAC encapsulation and may instead simply drop them. A >major problem with PPP lies in this scenario. Although I don't know the inner workings of PPP, it seems that the problem here is that a bridge is talking to a router. A more sensible configuration would be a bridge talking to a bridge. No, bridges are supposed to be able to interoperate with routers. Because PPP (and MPI/FR) are misspecified, they make interoperation difficult. This appears to boil down to the routing and bridging the same protocol on the same link problem. It happens on token rings and ethernets, there is no reason bridging and routing on the same link should be impossible on a WAN link. -John Kalucki johnk@gordian.com Joachim Carlo Santos Martillo Ajami From ietf-ppp-request@ucdavis.ucdavis.edu Thu Dec 19 09:54:48 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA21249; Thu, 19 Dec 91 09:33:23 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from babyoil.ftp.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA21110; Thu, 19 Dec 91 09:29:30 -0800 Received: from stev.d-cell.ftp.com by ftp.com via PCMAIL with DMSP id AA07887; Thu, 19 Dec 91 12:31:11 -0500 Date: Thu, 19 Dec 91 12:31:11 -0500 Message-Id: <9112191731.AA07887@ftp.com> To: kasten@europa.clearpoint.com Subject: Re: Joachim etc. Martillo From: stev@ftp.com (stev knowles) Cc: ietf-ppp@ucdavis.edu Repository: babyoil.ftp.com Originating-Client: d-cell.ftp.com One person's freedom of speech is not another person's obligation to listen. If you truly believe that what someone is saying is worthless drivel that is on a par with the rantings of used car salesmen and congressmen, you are free to ignore that drivel. Drivel and other such non-sequiturs do not require responses. Generally if you ignore it, it goes away. ok, frank, i am willing to make say that i made a mistake agreeing that he should be removed from the list. it is a facist thing, certainly, but the ranting and raving has *just* got to stop. i would rather joachim go away content in his knowledge that the PPP folks are going in the wrong direction, and invest his considerable effort in promoting his on solution, rather than pounding on someone else's solution. certainly, the kind of postings that this list has been recently seeing are of the type that 1) should be embarassing to clearpoint, based on the comments that others on the list are making, and 2) will probably look bad to someone joining us now . . . joachim, go off and write an RFC, and send it off to be posted to the "usual places". go about this a way that may generate you some respect rather than some foes. From ietf-ppp-request@ucdavis.ucdavis.edu Thu Dec 19 11:04:47 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA22593; Thu, 19 Dec 91 10:47:17 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from europa.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA22372; Thu, 19 Dec 91 10:38:12 -0800 Received: by europa.clearpoint.com (4.1/1.34) id AA01647; Thu, 19 Dec 91 13:31:04 EST Date: Thu, 19 Dec 91 13:31:04 EST From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9112191831.AA01647@europa.clearpoint.com> To: brian@lloyd.com, kasten@europa.clearpoint.com Subject: ppp not being perfect Cc: ietf-ppp@ucdavis.edu > From brian@lloyd.com Thu Dec 19 01:17:11 1991 > > No, PPP is not perfect nor does it solve all the problems. In > the mean time we will continue to try to make it work in as many > point-to-point environments as possible. > and you thought i was going to rant and rave..... :-) i would be very careful in this. we must not try to force ppp into environments where it does not fit. we would end up with a protocol that is a) really bad in those environments and b) massively twisted for the environments where it would otherwise be ok. two protocols, each designed for their own set of assumptions, environments, etc, is better than one protocol that does everything poorly. frank kastenholz From ietf-ppp-request@ucdavis.ucdavis.edu Thu Dec 19 12:35:03 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA23881; Thu, 19 Dec 91 12:09:50 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SGI.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA23443; Thu, 19 Dec 91 11:44:39 -0800 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (911016.SGI/910110.SGI) for ietf-ppp@ucdavis.edu id AA19989; Thu, 19 Dec 91 11:43:05 -0800 Received: by rhyolite.wpd.sgi.com (911016.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@ucdavis.edu id AA10032; Thu, 19 Dec 91 11:43:03 -0800 Date: Thu, 19 Dec 91 11:43:03 -0800 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9112191943.AA10032@rhyolite.wpd.sgi.com> To: ietf-ppp@ucdavis.edu Subject: Re: SLIP throughput on T2500 > from me: > Most or all of those companies [FDDI] are switching to "translating bridges". > From martillo@azea.clearpoint.com > ... > I have seen some announcements of such intent but such translating > bridges are still mostly vaporware (for good reasons) as far as I can > tell. My understanding is otherwise. I'm not of the bridging faith, but I have spent more than a couple hours locked up with most of the rest of the FDDI vendors doing interoperability tests. An encapsulating FDDI bridge is useless in a non-trival network, given RFC-1103 and replacement RFC-1188 which require the equivalent of RFC-1042 encapsulation for IP. If you transparently bridge IP/ethernet packets to FDDI, no conformant FDDI host or router will understand. If you transparently bridge FDDI to ethernet, most ethernet hosts will not understand the RFC-1042 encapsulation. (Yes, I read H.R.) > > > .... > > > If the ability to send and receive complete MAC frames is made > > > obligatory at the request of either end point, I will go away. > > This facility is now and always has been present. > > Almost, the facility is not obligatory, ... "OBLIGATORY"? Nothing is obligatory around here. This is not ANSI, IEEE, ISO or CCITT. We don't have a GOSIP to direct our efforts. We are free to do buy, sell, and implement whatever we want. I think "obligatory" encapsulates most of the tension here. Clearpoint has some ideas of how to link networks and/or hosts (both? just one?). Other vendors have not rushed to implement these ideas, which makes more difficult for a company with little current market share to sell the idea to paying customers. An obvious tactic is to convince a standards organization to adopt the idea. I have seen this tactic used with some success in the ANSI X3T9.5 committee. It has not been a complete win, because ideas (imperfect ideas according most experts; idiotic if you ask me) have been made only "optional," and because the use of the tactic has ensured that the start-up company that used it will never get any business from several other corporate members of X3T9.5. This tactic is useliess in this particular standards subculture. There are too many independent and in some cases, contrary people (e.g. me) here. A better tactic would be to simply publish an RFC, deploy it, prove in practice the advantages of the idea, and wait for the inevitable stampede of the rest of us to follow Clearpoint. Vernon Schryver, vjs@sgi.com From ietf-ppp-request@ucdavis.ucdavis.edu Thu Dec 19 12:48:43 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA24267; Thu, 19 Dec 91 12:30:25 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from sonny.proteon.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA24042; Thu, 19 Dec 91 12:18:21 -0800 Received: by sonny.proteon.com (5.59/1.6) id AA13552; Thu, 19 Dec 91 15:18:23 EST Date: Thu, 19 Dec 91 15:18:23 EST From: jas@proteon.com (John A. Shriver) Message-Id: <9112192018.AA13552@sonny.proteon.com> To: martillo@azea.clearpoint.com Cc: ietf-ppp@ucdavis.edu In-Reply-To: martillo@azea.clearpoint.com (Joachim Martillo's message of Thu, 19 Dec 91 12:23:21 EST <9112191723.AA01961@azea.clearpoint.com> Subject: SLIP throughput on T2500 [...] Most or all of those companies are switching to "translating bridges". I have seen some announcements of such intent but such translating bridges are still mostly vaporware (for good reasons) as far as I can tell. Gee, you wouldn't think that translating bridges are "vaporware" if you went to the last InterOp. The backbone was almost entirely translating FDDI-Ethernet bridges (with parallel IP and CLNS routing). DEC has been shipping their DECbridge 500 and 600 for much of this year, Proteon has been shipping with transparent bridging for months. (There are other players as well.) Some vendors of FDDI may be constrained from doing transparent/translation briding on FDDI due to their chipset -- they may the the "vaporware" you refer to. There is even an IEEE 802 working group focusing on writing a standard that covers the existing folklore of what an Ethernet to IEEE 802.[345]/FDDI translating bridge should do. This is certainly a needed project, it's all just consensus now. I'd also note that there certainly is a real market for parallel bridge routers, even if Joachim considers them "wrong". I was just out at a customer site with a huge bridged local and wide-area Ethernet backbone. The bridged LAN was mostly DECnet, but DEC LAT, LAVC, and LAST were absolutely critical. They have reached the point where there is several hundred packets/second of multicast routing traffic (DECnet hellos) on the whole backbone. Clearly, they really want to be routing that DECnet traffic, since a sizeable percentage of their expensive T1 lines are carrying broadcast nonsense. However, they can't punt LAT, LAVC, and LAST to go pure bridging, so they need parallel bridging to support those protocols. I used to be a purist, and try and tell people to run CTERM instead of LAT. That got me noplace. They want and need these non-layered DEC protocols. What the market wants, the market gets, whether it be right or wrong from an architectural point of view. (Even a "MAC router" bridge can't solve the multicast traffic problem inherent in huge bridged networks, nor will IEEE 802.1G.) Of course, SLITHERNET is not a great way to bridge FDDI packets, since you have to convert to and from IEEE 802.3 format (losing some information and any possiblity of FCS preservation), and have some serious maximum frame size problems. At least PPP lets you preserve the entire MAC layer FDDI frame, and tag it as such. The problem with demanding a MAC layer for serial line operations is the follow-on question of "which MAC layer". The whole universality falls apart. None of the three popular LANs (Ethernet, 802.5, FDDI) is a perfect superset of the others. From ietf-ppp-request@ucdavis.ucdavis.edu Thu Dec 19 13:16:39 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA24766; Thu, 19 Dec 91 13:05:12 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from azea.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA24579; Thu, 19 Dec 91 12:53:35 -0800 Received: by azea.clearpoint.com (4.1/1.34) id AA02081; Thu, 19 Dec 91 15:47:06 EST Date: Thu, 19 Dec 91 15:47:06 EST From: martillo@azea.clearpoint.com (Joachim Martillo @ azea) Message-Id: <9112192047.AA02081@azea.clearpoint.com> To: jas@proteon.com Cc: ietf-ppp@ucdavis.edu, martillo@azea.clearpoint.com In-Reply-To: John A. Shriver's message of Thu, 19 Dec 91 15:18:23 EST <9112192018.AA13552@sonny.proteon.com> Subject: SLIP throughput on T2500 Date: Thu, 19 Dec 91 15:18:23 EST From: jas@proteon.com (John A. Shriver) [...] Most or all of those companies are switching to "translating bridges". I have seen some announcements of such intent but such translating bridges are still mostly vaporware (for good reasons) as far as I can tell. Gee, you wouldn't think that translating bridges are "vaporware" if you went to the last InterOp. The backbone was almost entirely translating FDDI-Ethernet bridges (with parallel IP and CLNS routing). I did go and I was under the impression that packets were being routed (which I guess is translation in a sense) on to the backbone. I know our subnet was distinct from the backbone subnet. I also remember a lot of intervendor interoperability problems on the FDDI side (not precisely the same problem I know -- but I will feel more comfortable about FDDI when I know these problems have gone away -- most sites which support FDDI seem to restrict themselves to only one vendor because of these problems). Anyway, I understand tunneling of ethernet packets over FDDI and I know what translating means in the ethernet-to-token-ring (802.5) case, but I guess I should ask what precisely you mean by translating in the ethernet-FDDI case because you and I might mean different concepts. DEC has been shipping their DECbridge 500 and 600 for much of this year, Proteon has been shipping with transparent bridging for months. (There are other players as well.) I assume this is not equivalent to translation bridging. Some vendors of FDDI may be constrained from doing transparent/translation briding on FDDI due to their chipset -- they may the the "vaporware" you refer to. You are probably more up on this issue than I am, and I appreciate the information. There is even an IEEE 802 working group focusing on writing a standard that covers the existing folklore of what an Ethernet to IEEE 802.[345]/FDDI translating bridge should do. This is certainly a needed project, it's all just consensus now. I agree. I'd also note that there certainly is a real market for parallel bridge routers, even if Joachim considers them "wrong". I was just out at a customer site with a huge bridged local and wide-area Ethernet backbone. The bridged LAN was mostly DECnet, but DEC LAT, LAVC, and LAST were absolutely critical. They have reached the point where there is several hundred packets/second of multicast routing traffic (DECnet hellos) on the whole backbone. Clearly, they really want to be routing that DECnet traffic, since a sizeable percentage of their expensive T1 lines are carrying broadcast nonsense. However, they can't punt LAT, LAVC, and LAST to go pure bridging, so they need parallel bridging to support those protocols. I agree with the need for parallel router filtering bridges and we support them. But I also worry about potential routing/path-selection anomalies associated with them and the lack of firewalls between routed segments which they imply by forwarding non-IP traffic. Should a crazed LAT concentrator, crazed bridge (transmitting bogus BPDUs perhaps) or hostile user simulating a crazed LAT concentrator or crazed bridge really be able to take down a whole routed network? I contend that there is a real need for both parallel router filtering bridges and logical subbridge routers, and that IETF working groups should avoid if possible defining protocols which hinder the operation of either sort of hybrid bridge router. Routing between separate communications subnets composed of bridged LANs which each have their own separate spanning trees is a way to provide much needed fire walls in those cases where bridging and routing in parallel is to be avoided. Of course within one of these bridged networks you could use parallel router filtering bridges instead of simple bridges if you have to route between contained subnetworks and support LAT. I just want to make sure that the flexibility exists to do real-world required parallel routering filtering bridging and also more architecturally correct firewall providing logical subbridge routing. PPP as currently defined gets in the way. The suggestions which I have made about MAC encapsulation fix the problem if they are accepted and work equally well for both hybrid bridge router architectures. I used to be a purist, and try and tell people to run CTERM instead of LAT. That got me noplace. They want and need these non-layered DEC protocols. What the market wants, the market gets, whether it be right or wrong from an architectural point of view. I could not agree more. (Even a "MAC router" bridge can't solve the multicast traffic problem inherent in huge bridged networks, nor will IEEE 802.1G.) Of course, SLITHERNET is not a great way to bridge FDDI packets, since you have to convert to and from IEEE 802.3 format (losing some information and any possiblity of FCS preservation), and have some serious maximum frame size problems. At least PPP lets you preserve the entire MAC layer FDDI frame, and tag it as such. I agree here to with respect to translation but there is a very real possibility of routing anomalies using PPP in complex topologies. The problem with demanding a MAC layer for serial line operations is the follow-on question of "which MAC layer". The whole universality falls apart. None of the three popular LANs (Ethernet, 802.5, FDDI) is a perfect superset of the others. Again, I agree, and for this reason Kastenholz was right on the mark by pointing out that striving for complete universality in the serial encapsulation arena may be problematic. Joachim Carlo Santos Martillo Ajami From ietf-ppp-request@ucdavis.ucdavis.edu Thu Dec 19 16:27:23 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA27099; Thu, 19 Dec 91 15:32:54 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SGI.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA26432; Thu, 19 Dec 91 14:52:55 -0800 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (911016.SGI/910110.SGI) for ietf-ppp@ucdavis.edu id AA02724; Thu, 19 Dec 91 14:51:18 -0800 Received: by rhyolite.wpd.sgi.com (911016.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@ucdavis.edu id AA10703; Thu, 19 Dec 91 14:51:16 -0800 Date: Thu, 19 Dec 91 14:51:16 -0800 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9112192251.AA10703@rhyolite.wpd.sgi.com> To: ietf-ppp@ucdavis.edu Subject: Re: SLIP throughput on T2500 > ... the last InterOp. The backbone was almost entirely > translating FDDI-Ethernet bridges (with parallel IP and CLNS routing). > > I did go and I was under the impression that packets were being routed Isn't this what he wrote? IP and CLNS routed, but other stuff bridged? In any case, the backbone was rather homogeneous. The demo rings were where the many different kinds of equipement lived. > lot of intervendor interoperability problems on the FDDI side Be careful. A vendor which said little more was excluded from Interop91 demos by Interop, Inc. I spent some little time inside the FDDI demos. This year I don't think there were any significant interoperability problems on the show ring. In fact, I understand there were no significant problems on the show ring at all. Perhaps Stev or others will say something. There were few if any interoparability problems on the demo rings, tho there were some system crashes. The distinction is meaningful. > -- but I will feel more comfortable > about FDDI when I know these problems have gone away -- most sites > which support FDDI seem to restrict themselves to only one vendor > because of these problems). This differs from my experience with customers rings. Many are homogeneous, but many are very heterogenous. (FDDI is among the things I'm officially paid to worry about.) > DEC has been shipping their DECbridge 500 and 600 for much of this > year, Proteon has been shipping with transparent bridging for months. > (There are other players as well.) > > I assume this is not equivalent to translation bridging. No, there was a typo. I think the DEC products are what Paul Koning of DEC called "translucent" at the 1989 Interop FDDI BOF, when he was trying to sell other FDDI-IP bridge guys on the notion. I think there were: 1) FDDI bridges such as those I saw demo'ed years ago at a San Diego X3T9.5 which "encapsulate" ethernet packets in FDDI frames and send them to boxes of the same vendor to be decoded and forwarded 2) FDDI bridges which translate the first 14 bytes of an ethernet packet into 21 bytes of FDDI FC, DA, SA, and SAPs, except for ethernet packets already 802.3 encapsulated, where the first 12 bytes of ethernet packet are converted to 13 bytes of FDDI FC, DA, and, SA, except for certain wrongly 802.3 encapsulated ethernet packets whose handling I don't understand. (Appletalk?) 3) other schemes, variously called "transparent". I think #1 is "encapsulating." I think #2 is "translating" or "translucent". vjs From ietf-ppp-request@ucdavis.ucdavis.edu Thu Dec 19 17:03:30 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA28151; Thu, 19 Dec 91 16:45:49 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SGI.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA28007; Thu, 19 Dec 91 16:37:40 -0800 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (911016.SGI/910110.SGI) for ietf-ppp@ucdavis.edu id AA10687; Thu, 19 Dec 91 16:36:07 -0800 Received: by rhyolite.wpd.sgi.com (911016.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@ucdavis.edu id AA10937; Thu, 19 Dec 91 16:36:06 -0800 Date: Thu, 19 Dec 91 16:36:06 -0800 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9112200036.AA10937@rhyolite.wpd.sgi.com> To: ietf-ppp@ucdavis.edu Subject: Re: SLIP throughput on T2500 > My understanding is otherwise. I'm not of the bridging faith, > > I don't understand the reference to faith. Some people believe or have professed to believe that "routers" are a generally infer way to connect networks and that "bridges" are better. I hold the contrary position, that routers are superior, except for certain non-routable protocols which I label braindead and next to useless. Some discussions of technical issues among otherwise apparently reasonable people degenerate into more or less polite agreements to disagree. The bridge-vs.-router debate of many years standing is one such. These issues are commonly and jocularly called "religious" issues. Thus, I am properly labeled "of the router faith." Does this idea of "religious" issues ring a bell with readers of this mailing list? Vernon Schryver, vjs@sgi.com From ietf-ppp-request@ucdavis.ucdavis.edu Thu Dec 19 17:58:23 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA28892; Thu, 19 Dec 91 17:35:23 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from azea.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA28594; Thu, 19 Dec 91 17:15:42 -0800 Received: by azea.clearpoint.com (4.1/1.34) id AA02265; Thu, 19 Dec 91 20:09:16 EST Date: Thu, 19 Dec 91 20:09:16 EST From: martillo@azea.clearpoint.com (Joachim Martillo @ azea) Message-Id: <9112200109.AA02265@azea.clearpoint.com> To: vjs@rhyolite.wpd.sgi.com Cc: ietf-ppp@ucdavis.edu In-Reply-To: Vernon Schryver's message of Thu, 19 Dec 91 14:51:16 -0800 <9112192251.AA10703@rhyolite.wpd.sgi.com> Subject: SLIP throughput on T2500 Sender: ietf-ppp-request@ucdavis.edu Date: Thu, 19 Dec 91 14:51:16 -0800 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) > ... the last InterOp. The backbone was almost entirely > translating FDDI-Ethernet bridges (with parallel IP and CLNS routing). > > I did go and I was under the impression that packets were being routed Isn't this what he wrote? IP and CLNS routed, but other stuff bridged? I thought he was referring to their architecture in contradistinction to what they were actually doing. To tell the truth I was unaware that traffic other than IP-related traffic was being carried by the backbone. But then I was very busy at the time. By the way, who would have been doing CLNS? > -- but I will feel more comfortable > about FDDI when I know these problems have gone away -- most sites > which support FDDI seem to restrict themselves to only one vendor > because of these problems). This differs from my experience with customers rings. Many are homogeneous, but many are very heterogenous. (FDDI is among the things I'm officially paid to worry about.) Actually, I would be very interested in any information about a very heterogeneous FDDI site. > DEC has been shipping their DECbridge 500 and 600 for much of this > year, Proteon has been shipping with transparent bridging for months. > (There are other players as well.) > I assume this is not equivalent to translation bridging. No, there was a typo. I think the DEC products are what Paul Koning of DEC called "translucent" at the 1989 Interop FDDI BOF, when he was trying to sell other FDDI-IP bridge guys on the notion. I think there were: 1) FDDI bridges such as those I saw demo'ed years ago at a San Diego X3T9.5 which "encapsulate" ethernet packets in FDDI frames and send them to boxes of the same vendor to be decoded and forwarded 2) FDDI bridges which translate the first 14 bytes of an ethernet packet into 21 bytes of FDDI FC, DA, SA, and SAPs, except for ethernet packets already 802.3 encapsulated, where the first 12 bytes of ethernet packet are converted to 13 bytes of FDDI FC, DA, and, SA, except for certain wrongly 802.3 encapsulated ethernet packets whose handling I don't understand. (Appletalk?) 3) other schemes, variously called "transparent". I think #1 is "encapsulating." I think #2 is "translating" or "translucent". I appreciate the information. Thanks. vjs Joachim Carlo Santos Martillo Ajami From ietf-ppp-request@ucdavis.ucdavis.edu Thu Dec 19 18:04:12 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA29054; Thu, 19 Dec 91 17:46:47 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from babyoil.ftp.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA28856; Thu, 19 Dec 91 17:31:08 -0800 Received: from stev.d-cell.ftp.com by ftp.com via PCMAIL with DMSP id AA21884; Thu, 19 Dec 91 20:32:46 -0500 Date: Thu, 19 Dec 91 20:32:46 -0500 Message-Id: <9112200132.AA21884@ftp.com> To: jas@proteon.com Subject: Re: SLIP throughput on T2500 From: stev@ftp.com (stev knowles) Cc: ietf-ppp@ucdavis.edu Repository: babyoil.ftp.com Originating-Client: d-cell.ftp.com Gee, you wouldn't think that translating bridges are "vaporware" if you went to the last InterOp. The backbone was almost entirely translating FDDI-Ethernet bridges (with parallel IP and CLNS routing). DEC has been shipping their DECbridge 500 and 600 for much of this year, Proteon has been shipping with transparent bridging for months. (There are other players as well.) Some vendors of FDDI may be constrained from doing transparent/translation briding on FDDI due to their chipset -- they may the the "vaporware" you refer to. err, sorry about that, but the above statement is *wrong*. there was no bridging going on at interop. *espically* not from FDDI to ethernet. what you saw were DEC and ATT FDDI concentrators. the *only* way to get FDDI running. it is *completely* unreliable in a "daisy chain". From ietf-ppp-request@ucdavis.ucdavis.edu Thu Dec 19 18:47:13 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA29644; Thu, 19 Dec 91 18:30:19 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Mordor.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA29445; Thu, 19 Dec 91 18:15:56 -0800 Received: from macii-morgan.Stanford.EDU by Mordor.Stanford.EDU (5.59/inc-1.0) id AA23912; Thu, 19 Dec 91 18:14:23 PDT Date: Thu, 19 Dec 1991 18:14:28 PST From: RL "Bob" Morgan Subject: IETF-PPP (was: SLIP throughput on T2500) To: ietf-ppp@ucdavis.edu Cc: vjs@rhyolite.wpd.sgi.com, martillo@azea.clearpoint.com In-Reply-To: Your message of Thu, 19 Dec 91 20:09:16 EST Message-Id: I don't mean to shout, but: PLEASE, FOLKS: THIS LIST IS FOR DISCUSSING THE WORK OF THE IETF-PPP WORKING GROUP. If you want to talk about multi-media bridges, there's a whole nother IETF working group devoted to this. If you want to talk FDDI, try comp.dcom.lans. If you want to flame each other, try alt.flame. Please try to respect the time and intelligence of the other readers of this list. - RL "Bob" Morgan Networking Systems Stanford ------- From ietf-ppp-request@ucdavis.ucdavis.edu Thu Dec 19 19:03:13 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA29666; Thu, 19 Dec 91 18:33:50 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from babyoil.ftp.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA29463; Thu, 19 Dec 91 18:18:50 -0800 Received: from stev.d-cell.ftp.com by ftp.com via PCMAIL with DMSP id AA22334; Thu, 19 Dec 91 21:20:33 -0500 Date: Thu, 19 Dec 91 21:20:33 -0500 Message-Id: <9112200220.AA22334@ftp.com> To: vjs@rhyolite.wpd.sgi.com Subject: Re: SLIP throughput on T2500 From: stev@ftp.com (stev knowles) Cc: ietf-ppp@ucdavis.edu Repository: babyoil.ftp.com Originating-Client: d-cell.ftp.com Isn't this what he wrote? IP and CLNS routed, but other stuff bridged? there *was* no other stuff. nothing bridged. In any case, the backbone was rather homogeneous. The demo rings were where the many different kinds of equipement lived. i beg your pardon.:) the backbone had routers from cisco, proteon, and wellfleet. there were concentrators from david, synoptics, and cabletron (ethernet), att and dec (fddi) and startek, synoptics, and cabletron (IBMTR). we used as much different stuff as people would give us:) > lot of intervendor interoperability problems on the FDDI side Be careful. A vendor which said little more was excluded from Interop91 demos by Interop, Inc. this is a bit harsh, but basically true. they take those NDA's *very* seriously. I spent some little time inside the FDDI demos. This year I don't think there were any significant interoperability problems on the show ring. In fact, I understand there were no significant problems on the show ring at all. Perhaps Stev or others will say something. the only problem attributable to the fddi was a stuck bit on one board, which we swapped before the show began. other problems, while sometimes blamed on the FDDI before we understood what wwas going on, turned out not to be the FDDI's fault. There were few if any interoparability problems on the demo rings, tho there were some system crashes. The distinction is meaningful. i aviod demos, so i have nothing to tell you about here. . . . > -- but I will feel more comfortable > about FDDI when I know these problems have gone away -- most sites > which support FDDI seem to restrict themselves to only one vendor > because of these problems). This differs from my experience with customers rings. Many are homogeneous, but many are very heterogenous. (FDDI is among the things I'm officially paid to worry about.) as long as one stays with concentrators, one can win with a mix of stuff. No, there was a typo. I think the DEC products are what Paul Koning of DEC called "translucent" at the 1989 Interop FDDI BOF, when he was trying to sell other FDDI-IP bridge guys on the notion. some of us refer to these as "extruders", since they extrude large FDDI packets onto the ethernets. . . From ietf-ppp-request@ucdavis.ucdavis.edu Thu Dec 19 22:16:31 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02228; Thu, 19 Dec 91 22:00:48 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02046; Thu, 19 Dec 91 21:45:42 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA08050; Thu, 19 Dec 91 21:43:38 PST Date: Thu, 19 Dec 91 21:43:38 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9112200543.AA08050@ray.lloyd.com> To: ietf-ppp@ucdavis.edu Subject: fun, games, and work The discussion with, for, and about Mr. Martillo is nice but it is beginning to get in the way of work. Bill Simpson recently posted an updated version of the LCP document. Could you (all) read and comment, please? 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 Dec 19 22:34:42 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02237; Thu, 19 Dec 91 22:04:24 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02101; Thu, 19 Dec 91 21:53:37 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA08053; Thu, 19 Dec 91 21:50:06 PST Date: Thu, 19 Dec 91 21:50:06 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9112200550.AA08053@ray.lloyd.com> To: martillo@azea.clearpoint.com Cc: vjs@rhyolite.wpd.sgi.com, ietf-ppp@ucdavis.edu In-Reply-To: martillo@azea.clearpoint.com (Joachim Martillo's message of Thu, 19 Dec 91 20:09:16 EST <9112200109.AA02265@azea.clearpoint.com> Subject: SLIP throughput on T2500 IP was routed on the routers in the Interop backbone. CLNP ran on a subset of the backbone and sort-of worked some of the time. As far as I know, no other packets flowed over the backbone. The bridging in the routers was disabled. Can we get back to PPP work please. 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 Dec 23 11:32:36 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA13808; Mon, 23 Dec 91 11:16:39 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA13494; Mon, 23 Dec 91 11:07:51 -0800 Received: by saffron.acc.com (4.1/SMI-4.1) id AA01298; Mon, 23 Dec 91 11:04:47 PST Date: Mon, 23 Dec 91 11:04:47 PST From: fbaker@acc.com (Fred Baker) Message-Id: <9112231904.AA01298@saffron.acc.com> To: brian@lloyd.com Subject: Re: Joachim etc. Martillo Cc: ietf-ppp@ucdavis.edu My opinion: Filtering of Sr. Martillo's mail is first the responsibility of Clearpoint Research. I would prefer that they take this matter in hand. Sr. Martillo carries this conversation on in more environments than the PPP mailing list, he uses the TCP/IP mailing list (via network news) and the IPLPDN mailing list as well. Therefore, I presume that filtering the PPP mailing list would be only partially effective. However, I am considering writing a program that could kill any incoming mail having a word found in a word list file anywhere in it. The first word to go into the word list would be "Martillo". I believe that network news has a similar capability based on the mail source; folks using news could simply choose to not accept mail from him (but would have to identify and step past the rebuttals). Fred From ietf-ppp-request@ucdavis.ucdavis.edu Wed Dec 25 17:15:36 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA06161; Wed, 25 Dec 91 17:00:10 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA06076; Wed, 25 Dec 91 16:53:37 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA29669; Wed, 25 Dec 91 19:52:11 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9112260052.AA29669@vela.acs.oakland.edu> Subject: LCP draft To: ietf-ppp@ucdavis.edu Date: Wed, 25 Dec 91 19:52:10 EST Cc: internet-drafts@nri.reston.va.us X-Mailer: ELM [version 2.3 PL11] Since the internet-drafts folks haven't managed to post the draft I mailed them 6 days ago, please find the version available by anonymous FTP from angband.stanford.edu, in pub/ppp/ppp-lcp.txt. This version has several typos fixed from the version I sent them, which I found while obsessively re-reading it while waiting for them. This version has the FSA I posted awhile back to the list, with changes suggested by Mark Moraes from Toronto. He was the only person to review the FSA, while the rest of you were engaged in pointless exchanges with Adjani. It also has my condensation of the PPP versus SLIP discussion, combined with material from the "unpublished" PPP Requirements doc that Drew did at the outset of this group. Please, please, read this new draft. Post your ideas to the list. Happy Holidays, Bill Simpson From ietf-ppp-request@ucdavis.ucdavis.edu Thu Dec 26 17:37:51 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA28851; Thu, 26 Dec 91 17:15:24 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA28699; Thu, 26 Dec 91 17:07:15 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA25418; Thu, 26 Dec 91 20:04:53 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9112270104.AA25418@vela.acs.oakland.edu> Subject: Re: can't get LCP draft To: bob@morningstar.com, karl@morningstar.com Date: Thu, 26 Dec 91 20:04:52 EST Cc: ietf-ppp@ucdavis.edu In-Reply-To: <9112260217.AA05734@roughy.morningstar.com>; from "Bob Sutterfield" at Dec 25, 91 9:17 pm X-Mailer: ELM [version 2.3 PL11] Sorry about that. All of the files in my personal directories have read others set, but when I copied into the ftp heirarchy, the file lost it. Mysterious. The file is now fixed. Thanks also to Greg Christy, Mark Moraes, Bill Miskovetz, Ian Duncan, and raman for reporting this. It's nice to know that folks really do want to read the text. On Christmas day! Bill Simpson From ietf-ppp-request@ucdavis.ucdavis.edu Thu Dec 26 17:46:27 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA29163; Thu, 26 Dec 91 17:30:27 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA28890; Thu, 26 Dec 91 17:17:32 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA25546; Thu, 26 Dec 91 20:16:09 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9112270116.AA25546@vela.acs.oakland.edu> Subject: LQM draft To: ietf-ppp@ucdavis.edu Date: Thu, 26 Dec 91 20:16:08 EST Cc: internet-drafts@nri.reston.va.us X-Mailer: ELM [version 2.3 PL11] Today's installment is the Link Quality Monitoring draft. I split this out as the group requested at IETF. You can find the file at angband.stanford.edu in pub/ppp/ppp-lqm.txt. The only differences are that the Identifier field became the Sequence field and widened to 16 bits (because we no longer needed the space for the LCP code field). This will reduce the frequency of sequence roll-over on higher speed links. I shuffled the LQRs and V bit fields. There is space to make LQRs wider, too. Should we do this? (If we miss 255 LQRs, we're probably in pretty bad shape.) Happy Holidays, Bill Simpson From ietf-ppp-request@ucdavis.ucdavis.edu Fri Dec 27 06:46:29 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10936; Fri, 27 Dec 91 06:30:44 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from europa.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10698; Fri, 27 Dec 91 06:21:05 -0800 Received: by europa.clearpoint.com (4.1/1.34) id AA02147; Fri, 27 Dec 91 09:14:14 EST Date: Fri, 27 Dec 91 09:14:14 EST From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9112271414.AA02147@europa.clearpoint.com> To: bsimpson@vela.acs.oakland.edu, ietf-ppp@ucdavis.edu Subject: Re: LQM draft Cc: internet-drafts@nri.reston.va.us > > I shuffled the LQRs and V bit fields. There is space to make LQRs > wider, too. Should we do this? (If we miss 255 LQRs, we're > probably in pretty bad shape.) Bill, Assuming that missing 255 LQRs is a "bad thing" :-) the document should say what to do when it happens -- e.g. terminate the link. If we don't, each vendor will do something different and it will all have to be fixed in a future version of requirements. My suggestion would be to insert a paragraph someplace that goes like: If LQRs are enabled and you do not receive at least one LQR in a time period in which you would expect to receive LQRs then you should assume that the link has gone to Disneyworld for a vacation and you should bring it down. The LQR seq num (all seq. nums) should be made as wide as is possible. A long time ago, the designers of TCP said "We'll never need more than 32 bits for sequence numbers" and today we are coming up with all kinds of options and hacks to expand the TCP seq num space. Frank Kastenholz Clearpoint Research Corp. From ietf-ppp-request@ucdavis.ucdavis.edu Fri Dec 27 08:42:04 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA12767; Fri, 27 Dec 91 08:15:14 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA12607; Fri, 27 Dec 91 08:08:51 -0800 Received: by volitans.morningstar.com (5.65a/91111501) id AA12797; Fri, 27 Dec 91 11:05:42 -0500 Date: Fri, 27 Dec 91 11:05:42 -0500 From: Bob Sutterfield Message-Id: <9112271605.AA12797@volitans.morningstar.com> To: kasten@europa.clearpoint.com Cc: bsimpson@vela.acs.oakland.edu, ietf-ppp@ucdavis.edu In-Reply-To: Frank Kastenholz's message of Fri, 27 Dec 91 09:14:14 EST <9112271414.AA02147@europa.clearpoint.com> Subject: LQM draft Date: Fri, 27 Dec 91 09:14:14 EST From: kasten@europa.clearpoint.com (Frank Kastenholz) "If LQRs are enabled and you do not receive at least one LQR ...at least the required number of LQRs... in a time period in which you would expect to receive LQRs then you should assume that the link has gone to Disneyworld for a vacation and you should bring it down." Be more specific with your articles. "...assume that the peer has gone to Disneyworld, and you should bring down the link." The LQR seq num (all seq. nums) should be made as wide as is possible. This is a good general principle, but remember that its purpose is to tell when the lights are on and nobody's home. If you're expecting LQRs so frequently that a 32-bit sequence number would wrap within (say) the window of a higher-level protocol timeout, then you're spending an inordinate amount of your link's bandwidth on monitoring the link. From ietf-ppp-request@ucdavis.ucdavis.edu Fri Dec 27 20:15:20 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA26426; Fri, 27 Dec 91 20:00:08 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA26390; Fri, 27 Dec 91 19:59:34 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA05088; Fri, 27 Dec 91 22:58:08 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9112280358.AA05088@vela.acs.oakland.edu> Subject: AP draft To: ietf-ppp@ucdavis.edu Date: Fri, 27 Dec 91 22:58:07 EST Cc: internet-drafts@nri.reston.va.us X-Mailer: ELM [version 2.3 PL11] The (hopefully final) installment is today's Authentication Protocols draft. It may be found at angband.stanford.edu in pub/ppp/ppp-ap.txt. The three documents found there form the core of PPP, and together with the IPCP document already posted in Internet-Drafts, completely supercede RFCs 1171 and 1172. Please foward these to the IESG at your earliest convenience. Bill Simpson From ietf-ppp-request@ucdavis.ucdavis.edu Sun Dec 29 02:15:06 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA23555; Sun, 29 Dec 91 02:00:15 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA23471; Sun, 29 Dec 91 01:55:36 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA05142; Sun, 29 Dec 91 04:54:07 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9112290954.AA05142@vela.acs.oakland.edu> Subject: Re: LQM draft To: bsimpson@vela.acs.oakland.edu (Bill Simpson) Date: Sun, 29 Dec 91 4:54:06 EST Cc: ietf-ppp@ucdavis.edu, internet-drafts@nri.reston.va.us In-Reply-To: <9112270116.AA25546@vela.acs.oakland.edu>; from "Bill Simpson" at Dec 26, 91 8:16 pm X-Mailer: ELM [version 2.3 PL11] I got a call from Craig Fox, at 6pm Saturday. He's trying to implement LQM. He found a major logic flaw in the old design. So, I burned the midnight oil, and editted his suggestions into the draft. It's a page shorter, even though I doubled the examples. It's still in angband.stanford.edu:pub/ppp/ppp-lqm.txt In brief, the statistics are now always passed in "relative" form. The numbers sent by one end are simply passed back unmodified in the next LQR. Each end calculates their own absolutes. This means that: 1) the absolutes can be calculated after only one round trip, instead of the two of the old design. 2) the absolutes can never be lost. 3) a higher speed LQR time will not generate zero absolutes to the slower one. I also changed a fair number of the field names, since half the packet was defined with names from the transmitting point of view, and half with the receiving point of view. Now they are all from the receiving point of view. Please look at this new design. It's a major change, but should be alright, as we're changing the protocol number anyway. Bill Simpson From ietf-ppp-request@ucdavis.ucdavis.edu Tue Dec 31 08:30:53 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA22262; Tue, 31 Dec 91 08:15:39 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from nsco.network.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA21875; Tue, 31 Dec 91 08:00:06 -0800 Received: from anubis.network.com by nsco.network.com (5.61/1.34) id AA14566; Tue, 31 Dec 91 09:59:54 -0600 Received: from psyche.network.com by anubis.network.com (4.0/SMI-4.0) id AA07591; Tue, 31 Dec 91 09:57:59 CST Date: Tue, 31 Dec 91 09:57:59 CST From: foxcj@anubis.network.com (Craig Fox) Message-Id: <9112311557.AA07591@anubis.network.com> To: ietf-ppp@ucdavis.edu Subject: test Please ignore this message. Mailing list messages have ceased arriving at my site. Craig Fox foxcj@network.com From ietf-ppp-request@ucdavis.ucdavis.edu Tue Dec 31 09:00:23 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA22871; Tue, 31 Dec 91 08:45:34 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA22744; Tue, 31 Dec 91 08:43:04 -0800 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA08947; Tue, 31 Dec 91 11:41:33 -0500 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9112311641.AA08947@vela.acs.oakland.edu> Subject: Re: LQM draft To: misko@cisco.com (Bill Miskovetz) Date: Mon, 30 Dec 91 18:15:13 EST Cc: brian@lloyd.com, forster@cisco.com, misko@cisco.com In-Reply-To: <9112301804.AA14707@lager.cisco.com>; from "Bill Miskovetz" at Dec 30, 91 10:04 am X-Mailer: ELM [version 2.3 PL11] There has been some private discussion going on about the revised LQM. I hope to bring the discussion back to the group: Lloyd wrote: > > As per the normal process Bill Simpson wrote up a draft for the > > modified LQM and posted it to the working group. Craig Fox of NSC > > attemted an implementation based on the draft and discovered a > > problem. Bill and Craig discussed the problem and posted Craig's > > findings to the WG. Bill then made a change to the document and > > posted it to the WG again. I suspect that Craig will implement and > > the process will go forward. All of this is in accord with the > > standard procedures of the IETF, IESG, and IAB. > Moskowitz writes: > I don't consider this to be "posting Craig's findings..." > Where is the description of this "major logic flaw"? > There was no discussion with the people who have current implementations > of LQM as to how they got around this "major logic flaw" nor was there > any description of it at all. They just changed the draft based on Craig's > implementation attempt. I'm not claiming there isn't a "major logic flaw", > but without seeing a description of it, I can't comment. Our LQM > implementation based on the "old design" interoperates with Morningstar's > (after fixing a bug on our part), so whatever the logic flaw is, it can't > be so major as to not allow interoperatibility. > First, let's be clear: I have never implemented LQM, nor tested it. I posted that to the group long ago (last May?), and asked that people with implementation experience review the spec. Until Craig did, nobody had. I really valued his insight. Second, the LQM parts of PPP were probably the worst written before I got involved. I had to fix *dozens* of spelling errors and typos. (Go back and look at RFC 1172.) Even the packet field names didn't match the text. Very few implementors bothered with the old design. I believe that is because it was hard to understand, and didn't meet the needs of the development community. According to the postings to this group, only 2 vendors have attempted LQM by last IETF: Morningstar and Brixton. Neither was represented at IETF. Other implementors at the IETF weren't happy with the negotiation and required escaping aspects of the design, and voted to change that. (Karl Fox at Morningstar had already raised one problem with the negotiation on the list, which is that it is unidirectional). Changing to a separate protocol fixed those problems. In my message Sunday morning, I listed the three problems that Craig had pointed out. I was too tired to give deep explanation, but was sufficiently sure that these were significant enough for me to spend *all* night working on them so the process didn't slow down. Let me explain further (probably not in order of precedence): 1) As noted above, the negotiation is uni-directional. By moving to a separate protocol, we can negotiate for the peer to send to us, and can send LQRs *to* the peer without asking! If the peer doesn't understand it, we get a protocol-reject (just like a NCP). Now, even when the peer doesn't ask for LQRs, we get a full loop of information, and can manage the link from one side. 2) As noted above, the negotiation mechanism wasn't the same form as other protocol negotiations, which meant that new LQM protocols couldn't be automatically negotiated as research continues. This violated the general design of PPP. Solved by moving to a separate protocol. 3) As noted above, when part of LCP, the LQR packets needed to be fully escaped. Since the LQR is mostly numbers, it was decided that this posed too much overhead. Again, solved by moving to a separate protocol. 4) The old Design Motivation section stated that LQRs "measured data loss in units of packets, octets, and LQRs". By some oversight, there was no LQR loss counter. Now that there is space (because we don't need the LCP code field), I added such a counter, and expanded the sequence space. (I saved a bit by specifying that a zero Last_Sequence indicates no LQRs received -- hopefully we can live with that once each 64K LQRs). 5) The Motivation section also said, "All measurements are communicated to both ends of the link...." This was not true! Only the incoming side was sent as relative numbers. The others were calculated. Somewhere in the mists of time, the document became internally inconsistent. This had to be fixed for one-sided operation (#1 above), as well. 6) [fatal flaw #1] Because the numbers about the outgoing side (as seen by the receiver of the LQR, the side that asked for LQRs and therefore is making decisions based on the information) are calculated, the loss of a single LQR means permanent loss of information. Moreover, there was no feedback mechanism to indicate that the sent LQR had been lost. So the sender blithly wiped out the old information with the next incoming LQR. This is solved by passing only relative numbers. No information is lost. 7) [fatal flaw #2] If one side is sending faster than the other, no LQR is received before the next LQR is generated. The new LQR will be filled with zeroes. Whenever one of the information bearing LQRs is lost (see #6 above), the problem is compounded. This plays havoc with a K of N algorithm. (Craig suggests that a K of N algorithm is a bad choice. I didn't choose it. If someone could come up with a list of algorithms and cross-references, I'd really appreciate it.) 8) [fatal flaw #3] The old design takes 2.5 round trips before useful information about the outgoing side of the link becomes available. When trying to come up, this is rather a long delay. The revised design takes only *one* round trip. 9) The old design relied on the peer to do most of the calculations. The new design merely echoes the information back so that it can be digested by the implementation which requested the option. This makes it simpler to implement a dumb LQR generator, and involves less trust between implementations. PPP has been unstable for a long time. It had serious flaws and implementation problems. As editor, I have been trying to get changes published as fast as the group finds problems. The time to make changes is *now*! Let's get this done, and make sure it works! Bill Simpson