From ietf-ppp-request@ucdavis.ucdavis.edu Wed Apr 1 06:15:59 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21264; Wed, 1 Apr 92 06:03:18 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01449; Wed, 1 Apr 92 05:30:03 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19895; Wed, 1 Apr 92 05:15:19 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from europa.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19692; Wed, 1 Apr 92 05:06:33 -0800 Received: by europa.clearpoint.com (4.1/1.34) id AA11428; Wed, 1 Apr 92 07:59:27 EST Date: Wed, 1 Apr 92 07:59:27 EST From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9204011259.AA11428@europa.clearpoint.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: ID ACTION:draft-ietf-pppext-pppmib-02.txt Forwarding: Mail from 'Internet-Drafts@nri.reston.va.us' dated: Tue, 31 Mar 92 11:09:09 -0500 Get it, Read it, Comment on it.......... Don't wait for the movie to come out....... ---------- Begin Forwarded Message ---------- Message 42: >From owner-ietf@isi.edu Wed Apr 1 00:44:15 1992 To: IETF From: Internet-Drafts@nri.reston.va.us Reply-To: Internet-Drafts@nri.reston.va.us Subject: ID ACTION:draft-ietf-pppext-pppmib-02.txt Sender: cclark@nri.reston.va.us A Revised Internet Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Definitions of Managed Objects for the Point-to-Point Protocol Author(s) : Frank Kastenholz Filename : draft-ietf-pppext-pppmib-02.txt Pages : 74 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing subnetworks using the family of Point-to-Point Protocols. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-pppmib-02.txt". Internet-Drafts directories are located at: o East Coast (US) Address: nnsc.nsf.net (128.89.1.178) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND internet-drafts/draft-ietf-pppext-pppmib-02.txt". For questions, please mail to internet-drafts@nri.reston.va.us. ----------- End Forwarded Message ----------- From ietf-ppp-request@ucdavis.ucdavis.edu Mon Apr 6 07:31:07 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06443; Mon, 6 Apr 92 07:23:23 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04893; Mon, 6 Apr 92 06:59:33 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05519; Mon, 6 Apr 92 06:45:56 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.73.212.9] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05348; Mon, 6 Apr 92 06:40:19 -0700 Received: by wnyosi9.nctsw.navy.mil (5.59/25-eef) id AA09609; Mon, 6 Apr 92 08:51:37 EDT Date: Mon, 6 Apr 92 08:51:37 EDT From: rjacob@wnyosi9.nctsw.navy.mil Message-Id: <9204061251.AA09609@wnyosi9.nctsw.navy.mil> To: backman@ftp.com, brian@lloyd.com, bsimpson@vela.acs.oakland.edu, cranch@novell.com, dgotelli@novell.com, dyates@wellfleet.com, fgs@shiva.com, forster@cisco.com, foxcj@network.com, ghm@merit.com, gordon@ftp.com, jas@proteon.com, jthomas@novell.com, karl@morningstar.com, kasten@clearpoint.com, lotti@brixton.com, marty@shiva.com, muchow@anubis.network.com, root@wnyosi9.nctsw.navy.mil, sauerbac@novell.com, sjs@network.com, steve@livingston.com, suresh@3com.com, veizades@apple.com, vsp@3com.com Subject: Re: "PPP-Athon" Invitation Cc: dwa@Telebit.COM, ietf-ppp@ucdavis.ucdavis.edu, ms@Telebit.COM, rjacob@wnyosi9.nctsw.navy.mil IS ANYONE DOING OSI OVER PPP, BESIDES CISCO. I know Novell and TCP/IP pay the bills. OSI works!! It is no silver bullet, not yet. OSI is coming and is needed. please forward any comments or plans that you have to support TP4,TP2, and CLNS or CONS, with PPP as the DATA-Link service provider, on a router or bridging device of some kind. thank you raymond jacob nctsw, bldg 196-2 code n531 washington navy yard washington,dc 20374-5069 voice 202-433-2753 fax 202-433-5786 From ietf-ppp-request@ucdavis.ucdavis.edu Mon Apr 6 14:19:13 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20126; Mon, 6 Apr 92 14:04:06 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09038; Mon, 6 Apr 92 13:44:52 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19006; Mon, 6 Apr 92 13:31:50 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from GINGER.LCS.MIT.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17978; Mon, 6 Apr 92 13:02:59 -0700 Received: by ginger.lcs.mit.edu id AA27654; Mon, 6 Apr 92 16:02:10 -0400 Date: Mon, 6 Apr 92 16:02:10 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9204062002.AA27654@ginger.lcs.mit.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Questions from an IAB member Cc: jnc@ginger.lcs.mit.edu Could someone please answer these? Remember, Vint wasn't there for the WG debates, and isn't on the mailing list, so he can't know what you've already said! I know the first was discussed, but I'm not sure about the second. Send a CC: to "iab@isi.edu" and "iesg@nri.resston.va.us". Noel -------------------------------- Vint Cerf asks: Basically, I don't have any disagreement with the proposal. However, there are a set of 32 bit counters which may ultimately wrap. there is language regarding the situation at "wrap time" referring to the care which must be taken when calculating deltas after a wrap. I just wanted to make sure that the WG feels that all cases in which a counter might wrap have been dealt with. Second, the document is clear that while it specifies mechanism for collecting data about link quality, it does not specify the POLICY which determines whether a link is suitable for operation or not. That's fine. I goes on to say, however, that the policies may differ on each end of the link. I would like to ask whether the routing Area people have considered that. The reason I am asking is that the link up/down decision apparatus is one of the critical factors in the stability of some routing algorithms. A half-open link can lead to some strange black holes and loops. Would it make sense in this document to point out that the link up/down policy may not be totally open-ended if the determination of link up or down state has a profound impact on the way in which a routing algorithm performs? Vint Cerf From ietf-ppp-request@ucdavis.ucdavis.edu Mon Apr 6 16:05:26 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24125; Mon, 6 Apr 92 15:57:38 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09948; Mon, 6 Apr 92 15:15:02 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22246; Mon, 6 Apr 92 15:04:59 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21942; Mon, 6 Apr 92 14:57:12 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA04760; Mon, 6 Apr 92 14:55:32 PDT Date: Mon, 6 Apr 92 14:55:32 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9204062155.AA04760@saffron.acc.com> To: jnc@ginger.lcs.mit.edu Subject: Re: Questions from an IAB member re PPP Cc: iab@isi.edu, iesg@nri.reston.va.us, ietf-ppp@ucdavis.ucdavis.edu >> I goes on to say, however, that the policies may differ on each end of >> the link. Vint: What we have felt all along is that an implementation using LQM should provide controls allowing the network administrator to set the policy - take the link down (or don't allow it to fully come up) if its error rate exceeds . Something else that's implicit here, though perhaps understated, is that the system is using some form of traffic as a static analysis tool (perhaps echo requests) *before* the link becomes fully operational. It *should* be possible for folks who can agree to have a link to agree on its quality policy, and to configure it. But, given cases where the policy does in fact differ, I think the effect should be that the intersection of the policies applies. This, I conjecture, is the direct implication of the state machine events when the link "goes out of service." Going "out of service" means "send an LCP TERMINATE, go into a state where you will periodically send LCP CONFIGURE-REQUEST, and do nothing else until your neighbor demonstrates agreement with your state". If the peer receives the TERMINATE, the link is fully down and won't come up until you let it. If he misses the TERMINATE, the link will stay half open until either he receives your CONFIGURE-REQUEST (which will force him into a corresponding state) or until he determines that the link quality is truly bad, by whatever algorithm. If the link quality is so bad he can't receive your CONFIGURE-REQUEST and he doesn't notice, I would describe his implementation as *truly*broken*. So it takes two to keep the link up, only one to take it down. Does that help? Fred From ietf-ppp-request@ucdavis.ucdavis.edu Mon Apr 6 17:12:31 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26277; Mon, 6 Apr 92 16:55:52 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA10768; Mon, 6 Apr 92 16:29:41 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24949; Mon, 6 Apr 92 16:19:09 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from NRI.RESTON.VA.US by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24530; Mon, 6 Apr 92 16:08:48 -0700 Received: from NRI.NRI.Reston.Va.US by NRI.Reston.VA.US id aa00606; 6 Apr 92 18:53 EDT To: Fred Baker Cc: jnc@ginger.lcs.mit.edu, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: Questions from an IAB member re PPP In-Reply-To: Your message of "Mon, 06 Apr 92 14:55:32 PDT." <9204062155.AA04760@saffron.acc.com> Date: Mon, 06 Apr 92 18:53:24 -0400 From: vcerf@NRI.Reston.VA.US Message-Id: <9204061853.aa00606@NRI.Reston.VA.US> Fred, thanks. So the basic model is that if one guy declares the link down, the other guy will eventually do the same because the first guy won't be responding to anything. The only obvious problem with this is how long the second guy is willing to stay in the half-open state. If it is long enough, it can cause a lot of trouble (queues filling up, congestion, you feel dull, depressed, nerves on edge -- oops, sorry, wrong commercial). Perhaps I am being a nervous nelly but it still seems to me that we ought to warn people that inhomogeneous link up/down can lead to some serious problems. Vint From ietf-ppp-request@ucdavis.ucdavis.edu Mon Apr 6 17:33:25 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27113; Mon, 6 Apr 92 17:19:42 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA10838; Mon, 6 Apr 92 16:36:55 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25040; Mon, 6 Apr 92 16:21:25 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24755; Mon, 6 Apr 92 16:14:44 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA04866; Mon, 6 Apr 92 16:13:13 PDT Date: Mon, 6 Apr 92 16:13:13 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9204062313.AA04866@saffron.acc.com> To: vcerf@NRI.Reston.VA.US Subject: Re: Questions from an IAB member re PPP Cc: iab@isi.edu, iesg@NRI.Reston.VA.US, ietf-ppp@ucdavis.ucdavis.edu, jnc@ginger.lcs.mit.edu >> Perhaps I am being a nervous nelly but it still seems to me that >> we ought to warn people that inhomogeneous link up/down can lead >> to some serious problems. I'm not going to argue against a warning! Fred From ietf-ppp-request@ucdavis.ucdavis.edu Mon Apr 6 23:24:40 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02962; Mon, 6 Apr 92 23:02:26 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA13121; Mon, 6 Apr 92 21:16:15 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00624; Mon, 6 Apr 92 21:03:52 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [137.175.2.11] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00226; Mon, 6 Apr 92 20:53:04 -0700 Received: from crappie.morningstar.com by volitans.morningstar.com (5.65a/92021701) id AA08384; Mon, 6 Apr 92 21:56:41 -0400 Received: by crappie.morningstar.com (5.65a/910712902) id AA02206; Mon, 6 Apr 92 21:56:24 -0400 Date: Mon, 6 Apr 92 21:56:24 -0400 From: Karl Fox Message-Id: <9204070156.AA02206@crappie.morningstar.com> To: vcerf@NRI.Reston.VA.US Cc: ietf-ppp@ucdavis.ucdavis.edu, iesg@NRI.Reston.VA.US, iab@isi.edu, jnc@ginger.lcs.mit.edu, Fred Baker Subject: Re: Questions from an IAB member re PPP References: <9204062155.AA04760@saffron.acc.com> <9204061853.aa00606@NRI.Reston.VA.US> Organization: Morning Star Technologies, Inc. vcerf@NRI.Reston.VA.US writes: > Fred, > > thanks. So the basic model is that if one guy declares the link > down, the other guy will eventually do the same because the first > guy won't be responding to anything. The only obvious problem > with this is how long the second guy is willing to stay in the > half-open state. If it is long enough, it can cause a lot of > trouble (queues filling up, congestion, you feel dull, depressed, > nerves on edge -- oops, sorry, wrong commercial). Shutting down a link synchronously is always a problem on any sort of serial link where packets can be lost. PPP's Link Control Protocol (LCP) attempts to bring down both sides of the link when administratively given a `Down' event, which can come from a human administrator, from LQM, or from some other automated system (such as an idle timer on a dial-up circuit). LCP handles errors using timeouts and retransmission, while PPP's Link Quality Monitoring (LQM) can be used to automatically decide when to generate the Down event. The original question was whether two peers with different LQM policies could lead to a half-open link, and the answer to that is yes, but no more so than if they had identical LQM policies, or even no LQM at all. > Perhaps I am being a nervous nelly but it still seems to me that > we ought to warn people that inhomogeneous link up/down can lead > to some serious problems. > > Vint I don't think such a warning is needed, because LCP is supposed to mediate between the up/down desires of the administrator (LQM, in this case) and the remote peer. Any failure to synchronize is a failure on the part of LCP, not LQM. From ietf-ppp-request@ucdavis.ucdavis.edu Mon Apr 6 23:36:38 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03603; Mon, 6 Apr 92 23:22:25 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA13695; Mon, 6 Apr 92 22:56:02 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01427; Mon, 6 Apr 92 21:24:16 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from GINGER.LCS.MIT.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00696; Mon, 6 Apr 92 21:05:18 -0700 Received: by ginger.lcs.mit.edu id AA29660; Mon, 6 Apr 92 22:40:12 -0400 Date: Mon, 6 Apr 92 22:40:12 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9204070240.AA29660@ginger.lcs.mit.edu> To: fbaker@acc.com, vcerf@nri.reston.va.us Subject: Re: Questions from an IAB member re PPP Cc: iab@isi.edu, iesg@nri.reston.va.us, ietf-ppp@ucdavis.ucdavis.edu, jnc@ginger.lcs.mit.edu Vint: If I understand Fred's explanation, I think the model is that if one guy declares the link down, he sends a message to the other guy telling him the link is going down. The other guy has no decision to make; he just follows along. Only if that (and subsequent) messages gets lost do you fall back into the mode where the other guy has to decide on his own that the link is down. As was pointed out, any time you have a flaky link you have to expect momentary differences of opinion as to state which is agreed upon by communication between the parties. I think this is some variant of the 'Two Generals' problem... Noel From ietf-ppp-request@ucdavis.ucdavis.edu Tue Apr 7 08:33:06 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21397; Tue, 7 Apr 92 08:29:37 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01230; Tue, 7 Apr 92 08:00:09 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19945; Tue, 7 Apr 92 07:47:22 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from NRI.RESTON.VA.US by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19751; Tue, 7 Apr 92 07:42:26 -0700 Received: from NRI.NRI.Reston.Va.US by NRI.Reston.VA.US id aa11587; 7 Apr 92 10:33 EDT To: brian@lloyd.com Cc: fbaker@acc.com, jnc@ginger.lcs.mit.edu, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: Questions from an IAB member re PPP In-Reply-To: Your message of "Mon, 06 Apr 92 21:35:32 PDT." <9204070435.AA01915@ray.lloyd.com> Date: Tue, 07 Apr 92 10:32:48 -0400 From: vcerf@NRI.Reston.VA.US Message-Id: <9204071033.aa11587@NRI.Reston.VA.US> Lloyd, it helps - the delicate points seem to be cases in which the link has not "hard failed" (those are easy) but, rather, is flapping in one way or another. Route flapping as a result of link up/down flapping is a well-known phenomenon, and one to be guarded against. People use hold-down and other hysteresis methods (but generally, both ends need to be more or less cooperating for these to work well). My concern lies only in what I interpreted to be a rather "wide open" invitation in the LQM specification to allow two ends of a link to implement uncoordinated policies. I thought it might be worthwhile to point out that this is a potential source of "chaos" in the mathematical sense since small changes in the views of link status can lead to some rather widespread routing phenomena, depending on the actual topology of the network. I am by no means an expert in this area and am raising the issue purely to make sure that more knowledgable parties give us the benefit of their thoughts on this point before we put the document to bed. I hope this isn't misunderstood by anyone as nit-picking or second-guessing. Vint From ietf-ppp-request@ucdavis.ucdavis.edu Tue Apr 7 10:33:27 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25246; Tue, 7 Apr 92 10:26:42 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA02685; Tue, 7 Apr 92 10:00:23 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24020; Tue, 7 Apr 92 09:47:48 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from nsco.network.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23799; Tue, 7 Apr 92 09:42:24 -0700 Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA12973; Tue, 7 Apr 92 11:44:50 -0500 Received: from psyche.network.com by anubis.network.com (4.0/SMI-4.0) id AA19472; Tue, 7 Apr 92 11:42:08 CDT Date: Tue, 7 Apr 92 11:42:08 CDT From: foxcj@anubis.network.com (Craig Fox) Message-Id: <9204071642.AA19472@anubis.network.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: Questions from an IAB member re PPP Why should LQM bring the 'link' down. My implementation assumes that since the link was up to begin with then the user/network-mgr wanted it to be up as long as LQM said the line quality was not acceptable (a user selectable threshold). If the line quality is detected to be bad (below threshold), the NCPs (IP, Decnet, Bridging, etc) are taken down (not closed) and a 'fill line with random test data' process is initiated. LCP is still 'up' but its phase is set to 'LQD or Link Quality Determination'. LQM continues to monitor the line quality. When LQM determines that the line quality is again good, the NCPs are brought up (if they were previously open) and the 'fill line .." process is stopped. One difference I have seen between my PPP and others is that I do not test the line when it first comes up. I assumed that bad quality lines would occur less often that lines being brought into service. And the user would probably not appreciate the initial delay. Craig Fox Network Systems Corp. foxcj@network.com From ietf-ppp-request@ucdavis.ucdavis.edu Tue Apr 7 12:12:59 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28287; Tue, 7 Apr 92 11:46:06 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA03321; Tue, 7 Apr 92 11:16:11 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26645; Tue, 7 Apr 92 11:05:36 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26385; Tue, 7 Apr 92 10:57:05 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA05395; Tue, 7 Apr 92 10:56:14 PDT Date: Tue, 7 Apr 92 10:56:14 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9204071756.AA05395@saffron.acc.com> To: foxcj@anubis.network.com Subject: Re: Questions from an IAB member re PPP Cc: ietf-ppp@ucdavis.ucdavis.edu >> Why should LQM bring the 'link' down? My implementation assumes that >> since the link was up to begin with then the user/network-mgr wanted >> it to be up as long as LQM said the line quality was not acceptable >> (a user selectable threshold). If the line quality is detected to be >> bad (below threshold), the NCPs (IP, Decnet, Bridging, etc) are taken >> down (not closed) and a 'fill line with random test data' process is >> initiated. LCP is still 'up' but its phase is set to 'LQD or Link >> Quality Determination'. LQM continues to monitor the line quality. >> When LQM determines that the line quality is again good, the NCPs >> are brought up (if they were previously open) and the 'fill line .." >> process is stopped. One difference I have seen between my PPP >> and others is that I do not test the line when it first comes up. >> I assumed that bad quality lines would occur less often that lines >> being brought into service. And the user would probably not appreciate >> the initial delay. I haven't checked the state machine; My recollection was that, yes, it brought the LCP down and then left it in the link quality determination phase of *coming up* - the reason being to be very sure the link didn't stay half-open. This actually seems like a pretty good implementation approach, though. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Tue Apr 7 12:23:15 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28797; Tue, 7 Apr 92 12:00:07 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA03476; Tue, 7 Apr 92 11:31:20 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27352; Tue, 7 Apr 92 11:23:46 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26734; Tue, 7 Apr 92 11:08:31 -0700 Received: from remora.morningstar.com by volitans.morningstar.com (5.65a/92021701) id AA00638; Tue, 7 Apr 92 14:08:12 -0400 Received: by remora.morningstar.com (5.65a/91072901) id AA00524; Tue, 7 Apr 92 14:08:10 -0400 Date: Tue, 7 Apr 92 14:08:10 -0400 From: Karl Fox Message-Id: <9204071808.AA00524@remora.morningstar.com> To: Craig Fox Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: Questions from an IAB member re PPP References: <9204071642.AA19472@anubis.network.com> Organization: Morning Star Technologies, Inc. Craig Fox writes: > Why should LQM bring the 'link' down. Because disconnecting from a dial-up connection and placing a new call frequently corrects line problems. Because you may be able to fall back from a dedicated circuit to dial-up modems when the dedicated line fails or becomes too poor to use. > If the line quality is detected to be bad (below threshold), the NCPs > (IP, Decnet, Bridging, etc) are taken down (not closed) and a 'fill > line with random test data' process is initiated. LCP is still 'up' > but its phase is set to 'LQD or Link Quality Determination'. LQM > continues to monitor the line quality. When LQM determines that the > line quality is again good, the NCPs are brought up (if they were > previously open) and the 'fill line .." process is stopped. This is a very reasonable way to use LQM, but it is certainly not the only possibility. From ietf-ppp-request@ucdavis.ucdavis.edu Tue Apr 7 13:13:27 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00958; Tue, 7 Apr 92 12:55:14 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA03755; Tue, 7 Apr 92 12:01:16 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28561; Tue, 7 Apr 92 11:54:12 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28041; Tue, 7 Apr 92 11:41:52 -0700 Received: by volitans.morningstar.com (5.65a/92021701) id AA00801; Tue, 7 Apr 92 14:40:02 -0400 Date: Tue, 7 Apr 92 14:40:02 -0400 From: Bob Sutterfield Message-Id: <9204071840.AA00801@volitans.morningstar.com> To: fbaker@acc.com Cc: jnc@ginger.lcs.mit.edu, iab@isi.edu, iesg@nri.reston.va.us, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Fred Baker's message of Mon, 6 Apr 92 14:55:32 PDT <9204062155.AA04760@saffron.acc.com> Subject: asymmetrical link policies (was: Questions from an IAB member re PPP) Date: Mon, 6 Apr 92 14:55:32 PDT From: fbaker@acc.com (Fred Baker) >> I goes on to say, however, that the policies may differ on each >> end of the link. But, given cases where the policy does in fact differ, I think the effect should be that the intersection of the policies applies. Things are much easier to decide in the dial-up world: The end with more at stake (providing the scarce resource) sets the pickier policy. If I'm dialing 1-900-PPP-ATME, I'll want a good line because it's my nickel and I want to ship as much data as possible during my connection time. The answering peer won't specify a minimum line quality nor even an idle-line shutdown timer, because they make money for every minute I'm connected to their modems, of which they should have plenty. From ietf-ppp-request@ucdavis.ucdavis.edu Tue Apr 7 13:20:12 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01261; Tue, 7 Apr 92 13:03:14 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA03919; Tue, 7 Apr 92 12:15:39 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29134; Tue, 7 Apr 92 12:07:53 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [158.222.1.2] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28278; Tue, 7 Apr 92 11:45:56 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA02274; Tue, 7 Apr 92 11:44:56 PDT Date: Tue, 7 Apr 92 11:44:56 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9204071844.AA02274@ray.lloyd.com> To: vcerf@NRI.Reston.VA.US Cc: fbaker@acc.com, jnc@ginger.lcs.mit.edu, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: vcerf@NRI.Reston.VA.US's message of Tue, 07 Apr 92 10:32:48 -0400 <9204071033.aa11587@NRI.Reston.VA.US> Subject: Questions from an IAB member re PPP I agree Vint. There are situations that can occur where a link will oscillate. Cisco's HDLC protocol has the same problem in the presence of a flakey link. On the other hand, there is no ambiguity when the two ends have different views of the quality of the link. Whichever end has the more rigid quality requirement will control whether the link is up or down. 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 Apr 7 16:05:57 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06938; Tue, 7 Apr 92 15:48:03 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06370; Tue, 7 Apr 92 15:15:27 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05443; Tue, 7 Apr 92 15:02:17 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05071; Tue, 7 Apr 92 14:52:31 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA28125; Tue, 7 Apr 92 17:52:12 -0400 Date: Mon, 6 Apr 92 15:20:09 EST From: "William Allen Simpson" Message-Id: <237.bsimpson@vela.acs.oakland.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: "PPP-Athon" Invitation I'm confused over the Subject. I didn't see this "invitation" on the ietf-ppp list. Did it merely get lost on the way to me? And why the huge CC list? > Cc: backman@ftp.com, bsimpson@vela.acs.oakland.edu, cranch@novell.com, > dgotelli@novell.com, dyates@wellfleet.com, fgs@shiva.com, > forster@cisco.com, foxcj@network.com, ghm@merit.com, gordon@ftp.com, > jas@proteon.com, jthomas@novell.com, karl@morningstar.com, > kasten@clearpoint.com, lotti@brixton.com, marty@shiva.com, > muchow@anubis.network.com, root@wnyosi9.nctsw.navy.mil, > sauerbac@novell.com, sjs@network.com, steve@livingston.com, > suresh@3com.com, veizades@apple.com, vsp@3com.com, dwa@telebit.com, > ietf-ppp@ucdavis.edu, ms@telebit.com, rjacob@wnyosi9.nctsw.navy.mil Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu From ietf-ppp-request@ucdavis.ucdavis.edu Tue Apr 7 19:02:31 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12976; Tue, 7 Apr 92 18:46:44 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07835; Tue, 7 Apr 92 18:15:16 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11384; Tue, 7 Apr 92 18:01:03 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11183; Tue, 7 Apr 92 17:57:03 -0700 Received: from napa.TELEBIT.COM by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-Brent-910926) id AA07382 to ietf-ppp@ucdavis.edu; Tue, 7 Apr 92 17:56:57 PDT Received: from yoyo.telebit.com by napa.TELEBIT.COM (4.1/napa.telebit.com-DBC-910507) id AA25224 to ietf-ppp@ucdavis.edu; Tue, 7 Apr 92 17:56:40 PDT Date: Tue, 7 Apr 92 17:56:40 PDT From: mlewis@napa.Telebit.COM (Mark S. Lewis) Message-Id: <9204080056.AA25224@napa.TELEBIT.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA01970; Tue, 7 Apr 92 17:57:16 PDT To: ietf-ppp@ucdavis.ucdavis.edu Subject: PPP-Athon date change I would like to follow-up on the PPP-Athon. Here is the updated information. Note that the suggested date is now June 1-5. I have also added information on the location (probably useful information I forgot the first time :-). ... Mark "PPP-Athon" Invitation Customers want reliable networking software that interoperates with as wide a group of equipment as possible. They are looking for PPP to provide link and network control protocols for serial communications. Vendors want to provide such equipment. To that end, Telebit would like to invite all PPP vendors to participate in a working session. This will be strictly a technical effort to make sure participating PPP implementations interoperate well. GOALS: 1) Test interoperability in a spirit of cooperation to identify problems and limitations. 2) Resolve interoperability problems during the session or later. 3) Identify areas for improvement in our implementation. INVITEES: Everyone is invited. We have included specific people on the address list because they are actively involved with some facet of PPP. ALL others with PPP implementations, or just an interest to see how things work, are invited to come. This is not intended to exclude anyone who would like to participate or observe. SCHEDULE: Schedule a maximum of 5 days for fun and progress. The suggested week is: ** June 1 - 5, 1992 **Note the date change. This a week after InterOp East and a week before Usenix. Let me know if this a bad date for some reason. LOCATION: Telebit is located in Sunnyvale California. It is about half way between San Francisco and San Jose, in the heart of "Silicon Valley." The San Jose Airport is slight closer and is generally easier to get through. However, San Francisco will be fine if there aren't convenient flights in and out of San Jose. SPECIFIC AREAS OF TESTING: 1) Test interoperability of IP, AppleTalk, IPX and bridging over sync PPP connections 2) Test interoperability of IP, AppleTalk, IPX and bridging over direct async PPP connections 3) Test interoperability of IP, AppleTalk, IPX and bridging over dial-up async PPP connections ATTENDEE REQUIREMENTS: Router/host to run PPP implementation Serial hardware adapters (async and sync) CSU/DSU for sync (faster than 56Kbps) Trace/debugging hardware (eg. line monitors) Toolkit to put-up and break-down setups Reference Manuals TELEBIT SUPPLIES: Large room for setup Power connections - 24 110v. outlets Phone switch - 64 ports Phone cables CSU/DSUs (to 56Kbps) - 12 pair Sync cables - 12 V.35 cables Thinnet hardware - 12 cables, Ts, terminators Unix (Sparc) providing bootp & tftp service ACCOMMODATIONS: The Wyndham Garden Hotel (Next Door) To make reservations call 408/747-099 Rates Mon-Fri $86, Sat-Sun $39 Lunch provided every day by Telebit Telebit will plan an evening or two's fun RSVP: Please let me know your level of interest. It would also be helpful to have your phone number. Hope you can make it. ... Mark =====----- Mark S. Lewis, Telebit Corporation -----====== inet: mlewis@telebit.com Telebit (408) 745-3232 uucp: uunet!telebit!mlewis Fax (408) 745-3810 From ietf-ppp-request@ucdavis.ucdavis.edu Tue Apr 7 19:02:51 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13309; Tue, 7 Apr 92 18:57:31 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07935; Tue, 7 Apr 92 18:30:20 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12143; Tue, 7 Apr 92 18:24:08 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11452; Tue, 7 Apr 92 18:03:22 -0700 Received: from napa.TELEBIT.COM by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-Brent-910926) id AA07415 to ietf-ppp@ucdavis.edu; Tue, 7 Apr 92 18:03:15 PDT Received: from yoyo.telebit.com by napa.TELEBIT.COM (4.1/napa.telebit.com-DBC-910507) id AA25303 to ietf-ppp@ucdavis.edu; Tue, 7 Apr 92 18:02:59 PDT Date: Tue, 7 Apr 92 18:02:59 PDT From: mlewis@napa.Telebit.COM (Mark S. Lewis) Message-Id: <9204080102.AA25303@napa.TELEBIT.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA01971; Tue, 7 Apr 92 18:03:35 PDT To: bsimpson@vela.acs.oakland.edu Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <237.bsimpson@vela.acs.oakland.edu> Subject: "PPP-Athon" Invitation > I'm confused over the Subject. I didn't see this "invitation" on the > ietf-ppp list. Did it merely get lost on the way to me? > And why the huge CC list? > Bill_Simpson@um.cc.umich.edu > bsimpson@vela.acs.oakland.edu Yes Bill you should have seen the original invitation. I mailed it to the list. Plus I sent you a specific invitation. I checked your address and it was correct. Guess it got dropped somehow. I addressed the invitation to specific individuals so as to make the invitation more personal. They all have been contributors to PPP in one way or another, and so I wanted to make sure they were invited. All others not specifically addressed are just as welcome. ... Mark =====----- Mark S. Lewis, Telebit Corporation -----====== inet: mlewis@telebit.com Telebit (408) 745-3232 uucp: uunet!telebit!mlewis Fax (408) 745-3810 From ietf-ppp-request@ucdavis.ucdavis.edu Tue Apr 7 21:47:38 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18940; Tue, 7 Apr 92 21:42:15 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08886; Tue, 7 Apr 92 21:00:26 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17069; Tue, 7 Apr 92 20:46:53 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [158.222.1.2] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16922; Tue, 7 Apr 92 20:44:13 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA02795; Tue, 7 Apr 92 20:43:11 PDT Date: Tue, 7 Apr 92 20:43:11 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9204080343.AA02795@ray.lloyd.com> To: vsp@NSD.3Com.COM Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Venkat Prasad's message of Tue, 07 Apr 92 18:40:03 -0700 <199204080140.AA02214@himagiri.NSD.3Com.COM> Subject: LCP options extentions Organization: 3Com, 5400 Bayfront Plaza, Santa Clara, CA 95052-8145 Phone.......: (408) 764-5226 (Office) (408) 764-5000 (General Office) Date: Tue, 07 Apr 92 18:40:03 -0700 From: Venkat Prasad Brian, 3Com would like to do data compression over PPP links. I am not completely aware of all previous PPP deliberations either at IETF or on the PPP mailing group. I would like to know if data compression as an LCP option was ever considered and what was the outcome. There was mention of an encryption option but, to my knowledge, there was no attempt to set a compression option. We have discussed it but the consensus was that modems already do adequate link-level compression and at speeds above that encountered in modems compression could prove too expensive (cpu intensive) unless one had dedicated hardware to do the compression. If it was never considered in the past, I would like to propose that the PPP working group take it up. I am sure other vendors might be interested as well. I am willing to do some work in arriving at some frame work for doing this. My thoughts are that the compression algorithm itself should not be part of this effort. Instead PPP should define the options negotiation phase and just identify different compression algorithms, standard and proprietary, by a single byte code ( 256 varities ). This will allow accommadating everyone's favourite algorithms. It is worth a shot. Let's get discussion going on this. Comments everyone? 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 Apr 8 07:32:38 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06066; Wed, 8 Apr 92 07:25:19 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11470; Wed, 8 Apr 92 07:00:08 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04995; Wed, 8 Apr 92 06:45:22 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from hobbit.gandalf.ca by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04696; Wed, 8 Apr 92 06:33:23 -0700 Received: by hobbit.gandalf.ca (4.1/SMI-4.1) id AA23312; Wed, 8 Apr 92 09:33:15 EDT Date: Wed, 8 Apr 92 09:33:15 EDT From: mm@hobbit.gandalf.ca (Mississippi Mud) Message-Id: <9204081333.AA23312@hobbit.gandalf.ca> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: LCP options extentions >If it was never considered in the past, I would like to propose >that the PPP working group take it up. I am sure other vendors >might be interested as well. I am willing to do some work in >arriving at some frame work for doing this. My thoughts are >that the compression algorithm itself should not be part of >this effort. Instead PPP should define the options negotiation >phase and just identify different compression algorithms, standard >and proprietary, by a single byte code ( 256 varieties ). This will >allow accommodating everyone's favourite algorithms. I agree with this wholeheartedly. I think compression is a common feature of proprietary encapsulations (it is a selling feature of ours), and should be available as an LCP option. I was all set to grab an NCP ID to use for this, and if it there is a hook for it in the LCP I won't have to. (This coming from 3-Com: will it have any bearing on the upcoming IPX document, and its compression negotiation?) This may open up a can of worms though: error-free compression requiring error correction capability: i.e., nak and retransmit. Any "standard" algorithm specification might require complicating the line protocol a bit, to the point where you might as well call it LAPB. I am in favour also of putting in encryption options in a similar fashion. If PPP is to be a standard for heterogeneous router connections on general- purpose serial interfaces, in the same way that RFC1294 is intended to be for Frame Relay, it should support the more popular add-ons used in single-vendor solutions, at least by option negotiation. -Chris Sullivan Gandalf Data Limited chris@gandalf.ca From ietf-ppp-request@ucdavis.ucdavis.edu Wed Apr 8 08:36:36 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07743; Wed, 8 Apr 92 08:27:14 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11860; Wed, 8 Apr 92 08:00:15 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06754; Wed, 8 Apr 92 07:46:25 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06565; Wed, 8 Apr 92 07:40:35 -0700 Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA15892; Wed, 8 Apr 92 07:40:20 -0700 Date: Wed, 8 Apr 92 08:27:31 EST From: "William Allen Simpson" Message-Id: <240.bsimpson@vela.acs.oakland.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Link layer compression (was: LCP options extentions) > It is worth a shot. Let's get discussion going on this. Comments > everyone? > We discussed this in the past. It's not a good idea. According to Van Jacobson's analysis, data compression is best done at the TCP layer, not the link layer. Where we have modems doing link-layer compression, there is no need for a software version. I cannot see any use for link-layer compression at T1 speeds. We have enough on our plates without regurgitating old discussions. Where are the critiques of the newly announced AppleTalk document? Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu From ietf-ppp-request@ucdavis.ucdavis.edu Wed Apr 8 08:56:18 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08242; Wed, 8 Apr 92 08:39:16 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11929; Wed, 8 Apr 92 08:08:11 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06757; Wed, 8 Apr 92 07:46:29 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06575; Wed, 8 Apr 92 07:41:00 -0700 Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA15898; Wed, 8 Apr 92 07:40:46 -0700 Date: Wed, 8 Apr 92 08:42:44 EST From: "William Allen Simpson" Message-Id: <242.bsimpson@vela.acs.oakland.edu> To: vcerf@nri.reston.va.us Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: In-Reply-To: Re: SNMP Agent-Console Interoperability Testing > From: vcerf@nri.reston.va.us > I see no reason why the Internet Society could not sponsor > bakeoffs (no reporters allowed). > Ahem. Reporters should always be allowed at public functions. But if real work is being done (unlike current InterOps), with no publicity hoopla, none are likely to spend a week hanging out for results. On the other hand, any bakeoffs sponsored by the Internet Society should come with the *explicit* statement that "winning" does not constitute an endorsement by the Society, and cannot be referenced in marketing material -- as is done with Consumers Reports. Recently, Telebit invited the PPP WG to come and test the various PPP implementations. Similar focused bakeoffs for other working groups might be a good idea. Could Telebit get Postel to "officiate"? Maybe this could be a regular part of IETF weeks! 'Twould enliven the time between endless meetings! Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu From ietf-ppp-request@ucdavis.ucdavis.edu Wed Apr 8 09:18:03 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09367; Wed, 8 Apr 92 09:12:24 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA12259; Wed, 8 Apr 92 08:45:27 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07971; Wed, 8 Apr 92 08:31:11 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07543; Wed, 8 Apr 92 08:19:32 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA00492; Wed, 8 Apr 92 08:18:59 PDT Date: Wed, 8 Apr 92 08:18:59 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9204081518.AA00492@saffron.acc.com> To: vsp@NSD.3Com.COM Subject: Re: LCP options extentions Cc: ietf-ppp@ucdavis.ucdavis.edu Software Compression is worthwhile at certain line speeds. But the algorithms we've looked at require a reliable link. Is 3COM proposing sliding LAPB under PPP? Fred From ietf-ppp-request@ucdavis.ucdavis.edu Wed Apr 8 09:34:18 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09966; Wed, 8 Apr 92 09:28:59 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA12411; Wed, 8 Apr 92 09:00:24 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08711; Wed, 8 Apr 92 08:53:06 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08017; Wed, 8 Apr 92 08:33:03 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA00499; Wed, 8 Apr 92 08:32:09 PDT Date: Wed, 8 Apr 92 08:32:09 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9204081532.AA00499@saffron.acc.com> To: bsimpson@vela.acs.oakland.edu Subject: Re: Questions from an IAB member Cc: ietf-ppp@ucdavis.ucdavis.edu >> The packet counters are >> unlikely to wrap, (since they are the MIB-II variables), but it is >> possible, particularly if used at T3 rates. The octet counters will >> probably wrap at some time on any link. The group decided to stick with >> the MIB-II decision in favor of 32-bit octet counters. Bill: Pardon my ignorance, but I'm not sure why the packet counters are so unlikely to wrap. Assuming T1 (1.536 MBPS payload rate) and 512 octet packets, packets to wrap = 2^32 = 4294967296 packets/second = 1536000/(512*8) = 375 seconds to wrap = 2^32/375 = 11453246 hours to wrap = 11453246/3600 = 3181 days to wrap = 3181/24 = 132 = about 4 months The argument used to support 32 bit counters in SNMP is that the wrap rate is low enough that the value can be polled in the interval (in LQM, every few seconds), not that the counters will never wrap. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Wed Apr 8 10:51:27 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12167; Wed, 8 Apr 92 10:32:58 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA13337; Wed, 8 Apr 92 10:00:26 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10681; Wed, 8 Apr 92 09:50:02 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10469; Wed, 8 Apr 92 09:43:00 -0700 Received: from na.novell.com by newsun.novell.com (4.1/smi4.1.1.v91190) id AA04698; Wed, 8 Apr 92 09:42:46 PDT Received: by na.novell.com (4.1/SMI-4.1) id AA00724; Wed, 8 Apr 92 09:43:48 PDT Date: Wed, 8 Apr 92 09:43:48 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9204081643.AA00724@na.novell.com> To: ietf-ppp@ucdavis.ucdavis.edu, mm@hobbit.gandalf.ca Subject: Re: LCP options extentions Hi Y'all, > >If it was never considered in the past, I would like to propose > >that the PPP working group take it up. I am sure other vendors > >might be interested as well. I am willing to do some work in > >arriving at some frame work for doing this. My thoughts are > >that the compression algorithm itself should not be part of > >this effort. Instead PPP should define the options negotiation > >phase and just identify different compression algorithms, standard > >and proprietary, by a single byte code ( 256 varieties ). This will > >allow accommodating everyone's favourite algorithms. > > I agree with this wholeheartedly. I think compression is a common feature > of proprietary encapsulations (it is a selling feature of ours), and should > be available as an LCP option. I was all set to grab an NCP ID to use > for this, and if it there is a hook for it in the LCP I won't have to. > > (This coming from 3-Com: will it have any bearing on the upcoming IPX > document, and its compression negotiation?) > solutions, at least by option negotiation. > > -Chris Sullivan > Gandalf Data Limited > chris@gandalf.ca Yes, it does have bearing. It also has bearing on the AppleTalk NCP (ATCP), right Brad? If we collectively decide to add this to LCP, it should propagate to the NCPs. I'm all for it. As we are currently deliberating and reviewing the draft internally, the time to decide this is now. Chris --- Chris Ranch Internetworking Products Division Novell, Inc. San Jose, CA (408)473-8667 cranch@novell.com From ietf-ppp-request@aggie.ucdavis.edu Wed Apr 8 13:06:08 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17118; Wed, 8 Apr 92 12:52:17 -0700 Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA15504; Wed, 8 Apr 92 12:20:57 -0700 Sender: ietf-ppp-request@aggie.ucdavis.edu Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA15362; Wed, 8 Apr 92 12:06:50 -0700 From: ccskiz@aggie.ucdavis.edu (Elizabeth St. Goar) Date: Wed, 8 Apr 92 12:06:50 -0700 Message-Id: <9204081906.AA15362@aggie.ucdavis.edu> To: ietf-ppp@aggie.ucdavis.edu Subject: ---------------------- Forwarded Message Follows ---------------------- Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA13938; Wed, 8 Apr 92 10:27:47 -0700 Received: from relay.hp.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10987; Wed, 8 Apr 92 10:00:12 -0700 Received: from hprdash.rose.hp.com by relay.hp.com with SMTP (16.6/15.5+IOS 3.13) id AA00521; Wed, 8 Apr 92 10:00:01 -0700 Received: from by hprdash.rose.hp.com with SMTP (16.6/15.5+IOS 3.21+OM) id AA07262; Wed, 8 Apr 92 09:58:27 -0700 Date: Wed, 8 Apr 92 09:58:27 -0700 From: CONGDON_PAUL/HP5200_15@hprdash.rose.hp.com Message-Id: <9204081658.AA07262@hprdash.rose.hp.com> Subject: LCP options extentions X-Openmail-Hops: 1 To: ietf-ppp-request@ucdavis.ucdavis.edu Item Subject: Reply: LCP options extentions We, at HP, have looked at data compression for LAN traffic over serial links. Here are a few comments: 1. To do 'continous' LZH type of compression you need a reliable link. PPP doesn't offer it, so you need to build your dictionary on a per-packet basis. 2. Some small packets may actually expand! The use of compression should be optional, on a per-packet basis. The protocol field could be used to identify packets that have been compressed and those that haven't 3. The compression software code needs to operate out of interrupt context (unless you have a screaming processor). Otherwise you may drop characters. 4. If you use software compression, you probably want to turn off all the modem stuff to get bytes through the modem as fast as possible. Modem latency is a killer on small packets. While I agree that we should all be able to add our own proprietary compression algorithms, it would be nice to have a few that we could interoperate with... Paul Congdon +----------------------------------+-------------------------------+ + Paul Congdon + Member of Technical Staff + + Hewlett Packard Company + Mail Stop: R3NF2 + + Roseville Networks Division + Email: ptc@hprnd.rose.hp.com + + 8000 Foothills Blvd + Phone: (916) 785-5753 + + Roseville, CA 95678 + Fax: (916) 786-9185 + +----------------------------------+-------------------------------+ From ietf-ppp-request@ucdavis.ucdavis.edu Wed Apr 8 23:31:48 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10132; Wed, 8 Apr 92 23:27:22 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01373; Wed, 8 Apr 92 23:00:05 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08670; Wed, 8 Apr 92 22:45:46 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08514; Wed, 8 Apr 92 22:42:27 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA04458; Thu, 9 Apr 92 01:42:12 -0400 Date: Wed, 8 Apr 92 23:54:06 EST From: "William Allen Simpson" Message-Id: <243.bsimpson@vela.acs.oakland.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: In-Reply-To: "PPP-Athon" Invitation > Yes Bill you should have seen the original invitation. I mailed it to > the list. Plus I sent you a specific invitation. I checked your > address and it was correct. Guess it got dropped somehow. > Thanks for the update. I didn't get it, and it didn't make it into the automatic official archive at ucdavis, so I suspect the list didn't either. Must have run into a mailer limit on that huge To/CC, or something. I have suggested that the date be combined with the IETF in Boston, using the terminal room already provided. We could all wear our Shownet fanny packs and pretend it's a mini-interop. Other than that, I think it's a smashing idea. Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu From ietf-ppp-request@ucdavis.ucdavis.edu Thu Apr 9 17:38:16 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11265; Thu, 9 Apr 92 17:22:30 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08914; Thu, 9 Apr 92 16:18:25 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06964; Thu, 9 Apr 92 14:52:56 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06666; Thu, 9 Apr 92 14:41:29 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA25496; Thu, 9 Apr 92 17:40:40 -0400 Date: Thu, 9 Apr 92 12:06:09 EST From: "William Allen Simpson" Message-Id: <246.bsimpson@vela.acs.oakland.edu> To: ietf-ppp@ucdavis.ucdavis.edu Cc: iab@isi.edu, iesg@nri.reston.va.us Subject: Re: Questions from an IAB member > From: fbaker@acc.com (Fred Baker) > Pardon my ignorance, but I'm not sure why the packet counters are so > unlikely to wrap. Assuming T1 (1.536 MBPS payload rate) and 512 octet > packets, > > packets to wrap = 2^32 = 4294967296 > packets/second = 1536000/(512*8) = 375 > seconds to wrap = 2^32/375 = 11453246 > hours to wrap = 11453246/3600 = 3181 > days to wrap = 3181/24 = 132 = about 4 months > Perhaps I should have said "infrequently" rather than "unlikely". I can't remember ever having a dial-up link stay up for 4 months. Come to think of it, I can't remember a router that stayed up that long either! > The argument used to support 32 bit counters in SNMP is that the wrap > rate is low enough that the value can be polled in the interval (in LQM, > every few seconds), not that the counters will never wrap. > Thank you. Your explanation will also hold for the octet counters, octets/second = 1536000/8 = 292000 seconds to wrap = 2^32/292000 = ~14709 hours to wrap = 14709/3600 = ~4 And of course, at gigabit rates the model continues to hold, if we poll at least every 14 seconds. Hopefully, this answers Vint's question. Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu From ietf-ppp-request@ucdavis.ucdavis.edu Thu Apr 9 17:38:21 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11267; Thu, 9 Apr 92 17:22:33 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09109; Thu, 9 Apr 92 16:25:12 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07820; Thu, 9 Apr 92 15:30:00 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from NRI.RESTON.VA.US by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07307; Thu, 9 Apr 92 15:08:28 -0700 Received: from NRI.NRI.Reston.Va.US by NRI.Reston.VA.US id aa02255; 9 Apr 92 18:00 EDT To: bsimpson@rigel.acs.oakland.edu Cc: ietf-ppp@ucdavis.ucdavis.edu, iab@isi.edu, iesg@NRI.Reston.VA.US Subject: Re: Questions from an IAB member In-Reply-To: Your message of "Thu, 09 Apr 92 12:06:09 EST." <246.bsimpson@vela.acs.oakland.edu> Date: Thu, 09 Apr 92 18:00:06 -0400 From: vcerf@NRI.Reston.VA.US Message-Id: <9204091800.aa02255@NRI.Reston.VA.US> Hi, Vint's question seems to have been well-answered (says Vint), so he reports to the IAB that the discussion on the 32 bit counters has been satisfactorily concluded. Vint From ietf-ppp-request@aggie.ucdavis.edu Thu Apr 9 18:32:47 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13346; Thu, 9 Apr 92 18:26:56 -0700 Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA09582; Thu, 9 Apr 92 17:31:44 -0700 Sender: ietf-ppp-request@aggie.ucdavis.edu Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA09546; Thu, 9 Apr 92 17:28:06 -0700 From: ccskiz@aggie.ucdavis.edu (Elizabeth St. Goar) Date: Thu, 9 Apr 92 17:28:06 -0700 Message-Id: <9204100028.AA09546@aggie.ucdavis.edu> To: ietf-ppp@aggie.ucdavis.edu Subject: Forwarded Message ---------------Forwarded Message Follows-------------- > From: "William Allen Simpson" > Message-Id: <246.bsimpson@vela.acs.oakland.edu> > To: ietf-ppp@ucdavis.edu > Cc: iab@isi.edu, iesg@nri.reston.va.us > Subject: Re: Questions from an IAB member > > > From: fbaker@acc.com (Fred Baker) > > Pardon my ignorance, but I'm not sure why the packet counters are so > > unlikely to wrap. Assuming T1 (1.536 MBPS payload rate) and 512 octet > > packets, > > > > packets to wrap = 2^32 = 4294967296 > > packets/second = 1536000/(512*8) = 375 > > seconds to wrap = 2^32/375 = 11453246 > > hours to wrap = 11453246/3600 = 3181 > > days to wrap = 3181/24 = 132 = about 4 months > > > Perhaps I should have said "infrequently" rather than "unlikely". I > can't remember ever having a dial-up link stay up for 4 months. Come to > think of it, I can't remember a router that stayed up that long either! > > > The argument used to support 32 bit counters in SNMP is that the wrap > > rate is low enough that the value can be polled in the interval (in LQM, > > every few seconds), not that the counters will never wrap. > > > Thank you. Your explanation will also hold for the octet counters, > octets/second = 1536000/8 = 292000 > seconds to wrap = 2^32/292000 = ~14709 > hours to wrap = 14709/3600 = ~4 > > And of course, at gigabit rates the model continues to hold, if we poll > at least every 14 seconds. > > Hopefully, this answers Vint's question. > > Bill_Simpson@um.cc.umich.edu > bsimpson@vela.acs.oakland.edu > From ietf-ppp-request@aggie.ucdavis.edu Thu Apr 9 18:32:50 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13384; Thu, 9 Apr 92 18:28:17 -0700 Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA09984; Thu, 9 Apr 92 17:48:10 -0700 Sender: ietf-ppp-request@aggie.ucdavis.edu Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA09602; Thu, 9 Apr 92 17:34:26 -0700 From: ccskiz@aggie.ucdavis.edu (Elizabeth St. Goar) Date: Thu, 9 Apr 92 17:34:26 -0700 Message-Id: <9204100034.AA09602@aggie.ucdavis.edu> To: ietf-ppp@aggie.ucdavis.edu Subject: Forwarded Message Comments: estgoar@ucdavis.edu INTERNET estgoar@ucdavis BITNET ucdavis!estgoar UUCP ---------------Forwarded Message Follows--------------- > To: bsimpson@rigel.acs.oakland.edu > Cc: ietf-ppp@ucdavis.edu, iab@isi.edu, iesg@NRI.Reston.VA.US > Subject: Re: Questions from an IAB member > In-Reply-To: Your message of "Thu, 09 Apr 92 12:06:09 EST." > <246.bsimpson@vela.acs.oakland.edu> > Date: Thu, 09 Apr 92 18:00:06 -0400 > From: vcerf@NRI.Reston.VA.US > Message-Id: <9204091800.aa02255@NRI.Reston.VA.US> > > Hi, > > Vint's question seems to have been well-answered (says Vint), > so he reports to the IAB that the discussion on the 32 bit > counters has been satisfactorily concluded. > > > Vint > From ietf-ppp-request@ucdavis.ucdavis.edu Fri Apr 10 18:37:09 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00677; Fri, 10 Apr 92 18:23:05 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA18665; Fri, 10 Apr 92 18:02:17 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29614; Fri, 10 Apr 92 17:52:09 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from bridge2.NSD.3Com.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29322; Fri, 10 Apr 92 17:43:08 -0700 Received: from himagiri.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA08386 (5.65c/IDA-1.4.4nsd for ); Fri, 10 Apr 1992 17:42:58 -0700 Received: from localhost.NSD.3Com.COM by himagiri.NSD.3Com.COM with SMTP id AA05322 (5.65c/IDA-1.4.4-910725 for ); Fri, 10 Apr 1992 17:42:56 -0700 Message-Id: <199204110042.AA05322@himagiri.NSD.3Com.COM> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Test Organization: 3Com, 5400 Bayfront Plaza, Santa Clara, CA 95052-8145 Phone.......: (408) 764-5226 (Office) (408) 764-5000 (General Office) Date: Fri, 10 Apr 92 17:42:55 -0700 From: Venkat Prasad This is a Test. Please ignore From ietf-ppp-request@ucdavis.ucdavis.edu Tue Apr 14 11:03:58 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02778; Tue, 14 Apr 92 10:42:38 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA10740; Tue, 14 Apr 92 10:03:22 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01084; Tue, 14 Apr 92 09:52:00 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00222; Tue, 14 Apr 92 09:31:43 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA00190; Tue, 14 Apr 92 09:30:57 PDT Date: Tue, 14 Apr 92 09:30:57 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9204141630.AA00190@saffron.acc.com> To: vsp@NSD.3Com.COM Subject: Re: [Venkat Prasad: Re: LCP options extentions] Cc: ietf-ppp@ucdavis.ucdavis.edu >> Did you receive this response. Some how I think it never made it >> to the group or may be they all ignored it! I received it. A collegue's opinion here is "if it's got LAPB, why call it PPP any more?" which I think is unfair and/or incorrect; the original specifications had an option for LAPB cut-in. That was never completed because of lack of uproar in support of it and because there are a few implementation issues. I have a concern with respect to the correctness of LQM over a LAPB link; do re-transmissions count towards stuff sent? But maybe LQM doesn't make sense over LAPB; use RR/P polling and be done with it. I don't see any major problem sliding LAPB under PPP, any more than I see a problem with making PPP run on an asynchronous link. I WOULD recommend we use the LAPB MIB rather than augmenting the PPP MIB to support the link. It seems, though, that we want to add an LCP negotiation OR use the 8885 XID negotiation to signal numbered mode. in the former case, there comes a step between LCP configuration and LQD where a SABM exchange occurs. I know the Mostek 5025, and I believe your chip (68601, right?), will go through a rather lengthy diagnostic cycle at that point; switchover could take up to a second. That's acceptable to me if it's acceptable to you. The XID negotiation heavily favors numbered mode; in fact, I don't recall an obvious way for it to say otherwise. Seems like you could get into some deadlock situations where one system wants an XID response or SABM, and the other is trying desperately to send LCP configures, and neither will back off. That needs to be thought through. The third approach, to have a LAPB "NCP", would work as well or better than the LCP/XID approach, but places the chip re-initializtion *very* late in the game. That I find a bit worrisome. How do you want to proceed? Fred From ietf-ppp-request@ucdavis.ucdavis.edu Wed Apr 15 08:33:25 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27870; Wed, 15 Apr 92 08:29:15 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA19561; Wed, 15 Apr 92 08:00:06 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26044; Wed, 15 Apr 92 07:46:21 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from CAYMAN.CAYMAN.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25536; Wed, 15 Apr 92 07:36:36 -0700 Received: from moon-patrol.Cayman.COM by cayman.Cayman.COM (4.1/SMI-4.0) id AA14834; Wed, 15 Apr 92 10:35:43 EDT Received: from localhost by moon-patrol.Cayman.COM (4.1/SMI-4.1) id AA08159; Wed, 15 Apr 92 10:39:07 EDT Message-Id: <9204151439.AA08159@moon-patrol.Cayman.COM> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: LCP options extentions In-Reply-To: Mail from Venkat Prasad dated Thu, 09 Apr 92 11:01:51 PDT <199204091801.AA03072@himagiri.NSD.3Com.COM> Date: Wed, 15 Apr 92 10:39:06 -0400 From: brad@Cayman.COM Humm... The Appletalk NCP folks have certainly been here before ;-) I have some ideas, probably not well thought out, but here goes... What we (probably all agree on) 1. Any sort of compression requires synchronized databases which require a reliable link. 2. Modems are cheap and have LZ built in. They compress data relatively well. 3. It somewhat helpful to differentiate between hdr compression (redundant info) and data compression (where it helps). I know, these degenerate into the same thing, but the issue is relevant in layering. If the upper layer protocol does header compression, which practically speaking it's in the best position to do, then all that is left is data which the modem can compress reasonably well. When we tried to fold the ARAP protocol from apple into PPP, we had found resistance, because their proprietary compress scheme required a reliable link, which PPP did not provide. PPP provides datagram service. It seems weird to try to provide a reliable link to transport an unreliable datagram protocol which had a reliable protocol on top of it (at least *I* thought it was a bit weird), ESPECIALLY since I tend to run PPP on a v.32bis/v.42bis modem which inturn runs a reliable protocol. whew. too many cycles to push too many bits. At one point we tried to give the client protocols of PPP some notion that the underlying link was reliable, but this broken because you can drop PPP datagrams if the link goes from open to any other state. So, we were force (right so IMHO) to simply assume that PPP was an unreliable datagram protocol (which in fact, it is). Today we simply let the modems what they are good at. I personally think there is value in header compression (ala. Van's work) but don't take to the notion of building a reliable link in PPP which can support V.42 or something similar. Not when I can buy fast modems (which change speed and features every 6 months). Note that all of this focuses on low-speed async. While I not count my self in the "gosh, doesn't everyone know sync is HDLC? what, NRZ?" club ;-) I don't have enough real world experience to talk about compression at 56k and above except to say that I doubt anything less than a 10-15 mips do v.42 at those speeds. I would use a hardware chip at T1 speeds, as a few bridge vendors seems to be doing. >> >We discussed this in the past. It's not a good idea. According to Van >> >Jacobson's analysis, data compression is best done at the TCP layer, not >> >the link layer. Where we have modems doing link-layer compression, >> >there is no need for a software version. I cannot see any use for >> >link-layer compression at T1 speeds. I agree. >> Definitely there should not be more than one device doing link >> compression on a given link. If user chooses to use modems to provide >> the compression that is fine. But if the modem does not then providing >> it in PPP would be good. The PPP option negotiation can be made >> configurable. I guess I agree with this, but personally I think it's more work than it's worth since every modem I use does compression and I don't need compress at 56k and T1 (personally, that is). >> > Yes, it does have bearing. It also has bearing on the AppleTalk NCP >> > (ATCP), right Brad? If we collectively decide to add this to LCP, >> > it should propagate to the NCPs. As I said before, I think we should negotiate header compression at the NCP level. Data compress would make sense at the LCP level, but ugg. Don't make me do v.42. blech. Ok, I guess if the word proprietary comes in here, why not. >> >While I agree that we should all be able to add our own >> >proprietary compression algorithms, it would be nice to >> >have a few that we could interoperate with... help! I'm drowning in a sea of LZ algorithms, all alike and defined by obtuse CCITT docs! -brad ps: these comments are meant in no way to detract from those of the other people in this group. I think the signal to noise ration is high on this debate. thanks. From ietf-ppp-request@aggie.ucdavis.edu Wed Apr 15 09:35:23 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00323; Wed, 15 Apr 92 09:28:21 -0700 Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA20314; Wed, 15 Apr 92 09:04:48 -0700 Sender: ietf-ppp-request@aggie.ucdavis.edu Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA20246; Wed, 15 Apr 92 08:56:46 -0700 From: ccskiz@aggie.ucdavis.edu (Elizabeth St. Goar) Date: Wed, 15 Apr 92 08:56:46 -0700 Message-Id: <9204151556.AA20246@aggie.ucdavis.edu> To: ietf-ppp@aggie.ucdavis.edu Subject: ---------------------- Forwarded Message Follows ---------------------- Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA19747; Wed, 15 Apr 92 08:08:05 -0700 Received: from gateway.bnr.ca by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26483; Wed, 15 Apr 92 07:58:43 -0700 Received: from BNRECADA.BNR.CA by gateway.bnr.ca (5.61/1.34) id AA28740; Wed, 15 Apr 92 10:58:01 -0400 Message-Id: <9204151458.AA28740@gateway.bnr.ca> Received: from BNRECADA.BNR.CA by BNRECADA.BNR.CA (IBM VM SMTP R1.2.1) with BSMTP id 4272; Wed, 15 Apr 92 10:57:50 EDT Date: 15 Apr 92 10:57:00 EDT To: From: Gary (G.P.) Mussar Subject: re:Fast FCS Lookup Sender: Gary (G.P.) Mussar In message "Fast FCS Lookup", you write: >I am having difficulty with the fast fcs algorithm from RFC 1171, the old >PPP spec. My implementation doesn't work, so I tried to compute the >FCS of a frame with a known frame. The frame I chose is from CCITT X.25 1984 >Appendix I, example 2, which is a UA response frame. > >The data (in hex) is 80 ce , and the fcs is c1 ea . This might be part of your problem. The example in the Appendix of X.25 shows the bits in the order that they are transmitted on the serial line. Bits are sent least significant bit first. Unfortunately, most people are used to seeing and understanding numbers in hex with least significant digits on the right and most significant digits on the left. In other words the data is not 80 ce but rather 01 73 and the fcs is not c1 ea but rather 83 57. So, fcs ^ b => 0xffff ^ 0x01 => 0xfffe 0xfffe & 0xff => 0xfe fcstab[fe] => 0x1ef1 from the table in RFC 1171, page 44. (fcs >> 8) ^ 0x1ef1 => 0xff ^ 0x1ef1 => 0x1e0e on to the next byte which is 0x73 and the current fcs is 0x1e0e fcs = (0x1e0e >> 8) ^ fcstab[(0x1e0e ^ 0x73) & 0xff] fcs = 0x1e ^ fcstab[0x7d] fcs = 0x1e ^ 0xa862 fcs = 0xa87c taking the one's complement of 0xa87c, I get 0x5783 >So what's the problem? I'm sure I'm making a bad assumption some where along >the way, but I'm getting bald scratching my head. Any help will be >greatly appreciated Yup. I hope this helps. Gary ------------------------------------------------------------------------------- Gary Mussar |Internet: mussar@bnr.ca | Phone: (613) 763-4937 BNR Ltd. | | FAX: (613) 763-2626 From ietf-ppp-request@ucdavis.ucdavis.edu Wed Apr 15 20:03:07 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27240; Wed, 15 Apr 92 19:52:12 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27634; Wed, 15 Apr 92 19:32:25 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26072; Wed, 15 Apr 92 19:16:13 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from hobbit.gandalf.ca by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25775; Wed, 15 Apr 92 19:10:08 -0700 Received: by hobbit.gandalf.ca (4.1/SMI-4.1) id AA10055; Wed, 15 Apr 92 22:09:37 EDT Date: Wed, 15 Apr 92 22:09:37 EDT From: mm@hobbit.gandalf.ca (Mississippi Mud) Message-Id: <9204160209.AA10055@hobbit.gandalf.ca> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: LCP options extentions Cc: mm@hobbit.gandalf.ca Mail vermin; apologies if you got two copies of this... Brad: >I guess I agree with this, but personally I think it's more work than >it's worth since every modem I use does compression and I don't need >compress at 56k and T1 (personally, that is). You might be mixing up the inconvenience of having to use wee pipes with the inconvenience of having to pay for big ones. The benefits of compression scale with speed as long as the cost of the compressor can be repaid by line cost savings over a reasonable time. >As I said before, I think we should negotiate header compression at the >NCP level. Data compress would make sense at the LCP level, but ugg. >Don't make me do v.42. blech. Ok, I guess if the word proprietary comes >in here, why not. No one has to implement an option. Those who need it buy from someone who has it. Me: (my emphasis) >If PPP is to be a standard for heterogeneous **router** connections on >general- >purpose serial interfaces, in the same way that RFC1294 is intended to be for >Frame Relay, it should support the more popular add-ons used in single-vendor >solutions, at least by **option** negotiation. I'm not talking about IP telecommuting here. I'm talking about routers - and remote bridges, since they can use RFC1220, and are likely to use sync and higher speeds also. Your own logic about reliable links (if there are such beasts) fails because you feel the need for compressing modems, and are therefore running a reliable transport protocol over an unreliable link protocol with quality monitoring over a modem which makes the monitoring somewhat redundant and the link reliable again. And who knows what end-to-end error crunching is going on above that (FTP is a probable one, and if the file is compressed...:-) Anybody use correction on their disk sectors? Memory?). So why does PPP have to be optionless in this regard? My point being that the circumstances and availability of appropriate technology will always dictate where and how much error detection and correction are needed (see J.H. Saltzer, D.P. Reed, D.D. Clarke, _End-To-End_Arguments_in_System_Design_). If it's not optional it will inevitably be redundant with something going on (perhaps intermittently) at a higher level, and the vendor may be cursed at. But if it's optional it's a tool which can be used if needed. Just like IP security. Anyway this does bring up the issue of finger problems, since adding options gives users a better chance of doing silly things. But after all we do have nice friendly manuals, don't we :-) ? If you want to force me to take out an NCP number and do some proprietary thing that's one way to go. I think the LCP is less messy, is all, and multivendor is a differentiator. -Chris Sullivan Gandalf Data Limited From ietf-ppp-request@ucdavis.ucdavis.edu Thu Apr 16 13:08:37 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10946; Thu, 16 Apr 92 12:36:50 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA02894; Thu, 16 Apr 92 12:00:30 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08792; Thu, 16 Apr 92 11:49:09 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08376; Thu, 16 Apr 92 11:39:52 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA05691; Thu, 16 Apr 92 10:27:02 PDT Date: Thu, 16 Apr 92 10:27:02 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9204161727.AA05691@ray.lloyd.com> To: mm@hobbit.gandalf.ca Cc: ietf-ppp@ucdavis.ucdavis.edu, mm@hobbit.gandalf.ca In-Reply-To: Mississippi Mud's message of Wed, 15 Apr 92 22:09:37 EDT <9204160209.AA10055@hobbit.gandalf.ca> Subject: LCP options extentions One comment on link-level compression: most schemes work by replacing redundant information with special symbols. To make this work you need homogeneity in the data stream. With low speed connections this tends to be the case because there is usually only one or two sessions on the link. As the speed of the link increases there are usually many more sessions and the data in the stream become hetrogeneous greatly reducing or even eliminating the benefits of link-level compression. Personally I think that it is unlikely to be of much benefit, especially if we are talking about a software solution. There are vendors of compression hardware that is transparent and may be used on point-to-point links. Perhaps that is a better solution. 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 Apr 16 18:07:30 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24754; Thu, 16 Apr 92 17:56:36 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06692; Thu, 16 Apr 92 17:30:14 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23172; Thu, 16 Apr 92 17:17:18 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22724; Thu, 16 Apr 92 17:07:34 -0700 Received: from na.novell.com by newsun.novell.com (4.1/smi4.1.1.v91190) id AA06465; Thu, 16 Apr 92 17:07:16 PDT Received: by na.novell.com (4.1/SMI-4.1) id AA19140; Thu, 16 Apr 92 17:08:24 PDT Date: Thu, 16 Apr 92 17:08:24 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9204170008.AA19140@na.novell.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Novell IPX NCP status Hello Y'all, This is just a quick note to let you know where Novell stands with IPX over PPP, and the IPXCP draft(s). First, we are supportive of the standards process. Our #1 concern is 3rd parties being able to interoperate with Novell equipment. We currently have a product that routes IPX/SPX over wan links. It's been announced, but not shipping (RSN). It has a new protocol that exchanges information over any generic wan media, like PPP and X.25. We hoped that it would solve the wan media dependence issue of having to add media specific code, then re-release our stack everytime we or some well-meaning 3rd party added a new media. Having this generic solution negates the need for PPP negotiation (today). We WILL ship the current implementation. Those who wish to interoperate will want to develop a compatible product. 3rd party developers will be able to obtain a developer's kit (SDK) that describes it and other stuff. Our plans fall under two categories: 1) right now, and 2) in the future. 1) right now, we will keep our current architecture. Michael Allen's March, 1992 IPXCP draft will add a reference to an informational draft that documents Novell's IPX WAN exchange protocol [IWXP?]. The IWXP informational draft will document the protocol enough to implement it. Both drafts will be published at the same time. 2) we're undecided as to what we want and/or will do. We'd like a way to do this stuff in a link independent manner. I've heard talk of the iplpdn group considering lifting the NCP state machine, and putting it on top of other stuff, like X.25, FR, etc. We also want some experience with our current implementation. Some comments: You will not interoperate with us unless you also perform our new IWXP. Until we decide what we're going to do next, I don't think trying to standardize what we cannot endorse makes sense. Please wait for us to do it. You can count on the aforementioned drafts being published in a timely manner. We promise. In so far as compression is concerned, we're open to collaboration with 3rd parties. Zipping up the ol' flame suit, Chris --- Chris Ranch Internetworking Products Division Novell, Inc. San Jose, CA (408)473-8667 cranch@novell.com From ietf-ppp-request@ucdavis.ucdavis.edu Thu Apr 16 18:31:45 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26066; Thu, 16 Apr 92 18:28:20 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06959; Thu, 16 Apr 92 18:02:13 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24540; Thu, 16 Apr 92 17:50:54 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23898; Thu, 16 Apr 92 17:34:57 -0700 Received: from manta.morningstar.com by volitans.morningstar.com (5.65a/92021701) id AA07159; Thu, 16 Apr 92 20:34:17 -0400 Received: by manta.morningstar.com (5.65a/91072902) id AA06639; Thu, 16 Apr 92 20:34:14 -0400 Date: Thu, 16 Apr 92 20:34:14 -0400 From: kim@MorningStar.Com (Kim Toms) Message-Id: <9204170034.AA06639@manta.morningstar.com> To: brian@lloyd.com (Brian Lloyd) Cc: mm@hobbit.gandalf.ca, ietf-ppp@ucdavis.ucdavis.edu Subject: LCP options extentions References: <9204160209.AA10055@hobbit.gandalf.ca> <9204161727.AA05691@ray.lloyd.com> Brian Lloyd writes: > One comment on link-level compression: most schemes work by replacing > redundant information with special symbols. To make this work you > need homogeneity in the data stream. With low speed connections this > tends to be the case because there is usually only one or two sessions > on the link. As the speed of the link increases there are usually > many more sessions and the data in the stream become hetrogeneous > greatly reducing or even eliminating the benefits of link-level > compression. You must balance the use of compute cycles to compress the information against the time to send the redundancy. On a fast link, perhaps even as slow as 56K (depending on your CPU), there won't be much point to compressing, because the link would send it that fast anyhow (or almost). Indeed, we recommend against VJ on a T1 link, because the CPU cycles to do VJ take longer than to transmit the extra 36 bytes. From ietf-ppp-request@ucdavis.ucdavis.edu Fri Apr 17 09:49:03 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06843; Fri, 17 Apr 92 09:43:58 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA12185; Fri, 17 Apr 92 09:15:31 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05357; Fri, 17 Apr 92 09:03:58 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04995; Fri, 17 Apr 92 08:54:11 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA06622; Fri, 17 Apr 92 08:53:45 PDT Date: Fri, 17 Apr 92 08:53:45 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9204171553.AA06622@ray.lloyd.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: minutes of the SD IETF meeting 18 March 1992 Point-to-Point Protocol Extensions (pppext) Chair: Brian Lloyd, brian@lloyd.com Mailing Lists: General Discussion: ietf-ppp@ucdavis.edu To Subscribe: ietf-ppp-request@ucdavis.edu Archive: ucdavis.edu:archive/ppp-archive IETF PPP *Appletalk *LQM *MIB *IPX *Decnet *CLNP *Physical Layer Brian Lloyd distributed a memo titled "The PPP Internetwork Packet Exchange (IPX) Control Protocol" submitted by Novell. Karl Fox distrubited a PPP Pocket Reference card from Morningstar Technologies. There will be a delay in the issuance of an RFC for LCP, IPCP, and Authentication due to an oversite within the IAB. However, there are not going to be any changes to the drafts prior to becoming RFCs. So it is safe to implement, and still be in compliance. Questions re: IP Address Negotiation. The implementor needs to support old format until PPP becomes a full standard. First check to see if the peer is using the old format. If so, negotiate IP addressing using the old algorithm. This procedure applies until PPP is a full standard. After that, support will not be provided for old algorithm for IP address negotiation. If you do IP you need to go ahead and do the new IP address negotiation scheme. Each of LCP, IP Control, LQM, and Authentication have their own document. Brian asked, "how many here are actively working to implement PPP?" Approximately 12 hands went up. As for penetration in the market it was noted that BARRNet now runs PPP on links to member sites. APPLETALK Brad Parker of Cayman presented an updated draft of his Appletalk over PPP document. Feedback from Bill Simpson and Chris Ranch of Novell. The document was forwarded to the IETF drafts mailing list. Good review from Appletalk communtity, supports ARAP. Will support router to router half routing. Doc will be placed on Merit.edu and Angband.stanford.edu in addition to usual places. LINK QUALITY MONITORING (LQM) The previous version of LQM was not widely implemented so major changes were deemed acceptable (this choice was made at the Santa Fe IETF meeting). As a result the general mechanism was redefined. should be able to determine if a synchronous link is up. Flow control monitoring not recommend for async. LQM is useful for high speed point to point between router vendors. LQM will give continuous state of the link info. This is good for OSPF type link state relative protocols. PPP MIB Frank Kastenholz of Clearpoint (kasten@clearpoint.com) updated MIB for PPP. Discussion has been open on the mailing list. Frank presented an update. PPP is a complex protocol so the MIB grew to almost 200 variables. Frank says this MIB has to be trimmed down, but others are asking for more. This MIB doesn't even address Appletalk, Decnet, CLNP. Should this MIB cover NCPs? was asked. Frank drew on the overhead. There were four columns: Protocol, Mandatory, Conditional Mandatory (if you are trying to control PPP instead of just monitor), and Optional. This graph allowed the members of the WG to assign each variable to a catagory. One reason to have lots of MIB variables is the need to configure PPP in routers via SNMP (the router from NAT was used as an example since it is only managable via SNMP). It was suggested that all configuration variables be in the optional column and get rid of the Conditional Mandatory column. Discussion continued as to how necessary it might be to trim down the variables. It was determined that MIB variables present for debugging purposes be discarded. Brian requested that Frank Kastenholz, Bill Simpson, and Glenn McGregor meet to pare down the MIB prior to the next day's WG meeting. IPX Christopher Ranch of Novell took the floor to lead the discussion of IPX over PPP. The Novell NCP has no options and this is in conflict with what Shiva has proposed. Brian recommended that Novell and Shiva hammer out the differences and produce a single unifying document. The working group indicated that they wanted to see an address negotiation and a compression option added to Novell's proposal. Brian also asked Chris to conider adding negotiation of a routing protocol IF he thinks it would be useful. DECNET There appeared to be no progress in the area of DECNet over PPP. Further work on this subject is awaiting an implementation and/or a new draft document. OSI/CLNP Bill opened discussion with the remark that there is a well-written document for which there are no implementations. This is a no-option document that differentiated between the three different kinds of CLNP. This will be re-addressed when there is an implementation. Christopher Ranch will forward requests on this to the correct person at Novell who is beginning an implementation. BRIDGING Fred Baker is looking for implemetation experiences to document. 3-COM has done bridging over PPP. Currently the document needs to 1) clarify the concept of a virtual ring, and 2) tighten up the language. 19 March 1992 09:00 32-BIT FCS Bill Simpson stated the issues with 32-bit FCS. These being that DEC owns patents on a procedure of combining the 32bit and 16bit FCS into a 48bit FCS to be used while 32bit FCS is being negotiated. Noel Chiappa said that DEC will make a license to their process freely available. DEC will provide a general grant of right to use the technology and will provide a letter to the IETF stating so. Action item: Karl Fox of Morningstar Technologies, being a vendor of a company with an implementation, is going to take the task of getting the letter from DEC releasing the rights to the process to the world. PHYSICAL LAYER Where/how to handle the physical layer information. The PPP mailing list concluded that the LCP layer is not the place. Bill Simpson stated that PPP is supposed to run over anything; in other words if you have two wires you should be able to run PPP. Brian Lloyd suggested the need for an implementation reference. There was agreement to this. Someone said this should be an informational RFC. Items to be covered included: PPP SYNC interface with an eye towards RS232, V35, V36, RS422/RS449; async implementations; switched circuits, i.e. Hayes compatible, X21, V25bis dialing; and definition of physical layer up/down determination; etc. Questions presented: How are we going to deal with ISDN? This is a topic of future discussion and work with the IPLPDN WG. Chat scripts and dealing with a login sequence on an async link. What is the other end going to send? MIB Revisited Frank took the floor to revisit the issue of MIB variables. Together with Bill Simpson, Glenn McGregor, and some input from Jeff Case they got the number of variables to just over a hundred. This is down from 196. They did not deal with every section, and some still need to be added for Appletalk, and IPX. It will be necessary to know if and what will be monitored in IPX over PPP. Changes: link extensions table is gone, FSM table(s) are gone, these were deemed to be debugging information. It was decided that it made more sense to return the link quality reports as a single aggregate MIB variable instead of permitting each field withing the LQR to be queried separately. Individual variables in the LQR are not very useful by themselves plus in order to make sense of the timely information it is necessary to see a complete "snapshot" in one operation. On the philosophy of configurable parameters: the choice seems to be, a rich set of "knobs" or allowing the vendor to completely control the initial and desired state of the implementation. There was no hard-and-fast decision so it was left up to Frank to clean up what was decided and to post all changes to the MIBs to the mailing list in a few weeks where discussion will begin anew. From ietf-ppp-request@ucdavis.ucdavis.edu Fri Apr 17 10:59:20 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09282; Fri, 17 Apr 92 10:43:52 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA12782; Fri, 17 Apr 92 10:15:19 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07620; Fri, 17 Apr 92 10:02:48 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from europa.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07379; Fri, 17 Apr 92 09:57:23 -0700 Received: by europa.clearpoint.com (4.1/1.34) id AA29713; Fri, 17 Apr 92 12:50:18 EDT Date: Fri, 17 Apr 92 12:50:18 EDT From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9204171650.AA29713@europa.clearpoint.com> To: brian@lloyd.com, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: minutes of the SD IETF meeting In-Reply-To: Mail from 'brian@lloyd.com (Brian Lloyd)' dated: Fri, 17 Apr 92 08:53:45 PDT > > MIB Revisited ... > On the philosophy of configurable parameters: the choice seems to be, > a rich set of "knobs" or allowing the vendor to completely control the > initial and desired state of the implementation. There was no > hard-and-fast decision so it was left up to Frank to clean up what was > decided and to post all changes to the MIBs to the mailing list in a > few weeks where discussion will begin anew. the mib is at your favorite internet-draft repository. get it and read it now -- don't wait for the movie version frank From ietf-ppp-request@ucdavis.ucdavis.edu Fri Apr 17 11:47:56 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11477; Fri, 17 Apr 92 11:37:31 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA13386; Fri, 17 Apr 92 11:15:27 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10109; Fri, 17 Apr 92 11:05:06 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from inet-gw-1.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09737; Fri, 17 Apr 92 10:55:24 -0700 Received: by inet-gw-1.pa.dec.com; id AA06416; Fri, 17 Apr 92 10:54:59 -0700 Received: by us1rmc.mso.dec.com; id AA03660; Fri, 17 Apr 92 13:54:27 -0400 Message-Id: <9204171754.AA03660@us1rmc.mso.dec.com> Received: from bigfut.enet; by us1rmc.enet; Fri, 17 Apr 92 13:54:28 EDT Date: Fri, 17 Apr 92 13:54:28 EDT From: Ross Callon To: brian@lloyd.com Cc: ietf-ppp@ucdavis.ucdavis.edu, callon@bigfut.enet.dec.com Apparently-To: brian@lloyd.com, ietf-ppp@ucdavis.edu Subject: re: minutes of the SD IETF meeting > > OSI/CLNP > > Bill opened discussion with the remark that there is a well-written > document for which there are no implementations. This is a no-option > document that differentiated between the three different kinds of > CLNP. This will be re-addressed when there is an implementation. > Christopher Ranch will forward requests on this to the correct person > at Novell who is beginning an implementation. > I have begun to look at this, and am interested in being involved with a re-write or update to the CLNP over PPP document. One issue that has been brought up (by 3Com) is the possible need for an optional odd-length padding to maintain 16-bit word alignment of the beginning of the CLNP header following the PPP header. There probably also should be some minor editorial updates (for example, for text that discusses the status of various documents in ANSI/ISO, which have made progress over the last year). Finally, there might want to be a short annex to discuss issues of running IS-IS over PPP, although I think that this is very simple. Who should I contact at Novell to discuss this?? I assume that Dave Katz (at cisco) and someone from 3Com would also be interested (3Com has a slightly non-conformant CLNP over PPP implementation). One small nit: It is not clear what is meant above by the phrase "...three different kinds of CLNP". Perhaps this should say "...four different OSI connectionless network layer protocols (CLNP, ES-IS, IS-IS, and IDRP)". Ross From ietf-ppp-request@ucdavis.ucdavis.edu Fri Apr 17 12:04:01 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12350; Fri, 17 Apr 92 11:58:23 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA13566; Fri, 17 Apr 92 11:30:39 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10811; Fri, 17 Apr 92 11:23:29 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10159; Fri, 17 Apr 92 11:06:40 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA06793; Fri, 17 Apr 92 11:03:28 PDT Date: Fri, 17 Apr 92 11:03:28 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9204171803.AA06793@ray.lloyd.com> To: callon@bigfut.enet.dec.com Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Ross Callon's message of Fri, 17 Apr 92 13:54:28 EDT <9204171754.AA03660@us1rmc.mso.dec.com> Subject: minutes of the SD IETF meeting Date: Fri, 17 Apr 92 13:54:28 EDT From: Ross Callon Apparently-To: brian@lloyd.com, ietf-ppp@ucdavis.edu > > OSI/CLNP > > Bill opened discussion with the remark that there is a well-written > document for which there are no implementations. This is a no-option > document that differentiated between the three different kinds of > CLNP. This will be re-addressed when there is an implementation. > Christopher Ranch will forward requests on this to the correct person > at Novell who is beginning an implementation. > I have begun to look at this, and am interested in being involved with a re-write or update to the CLNP over PPP document. One issue that has been brought up (by 3Com) is the possible need for an optional odd-length padding to maintain 16-bit word alignment of the beginning of the CLNP header following the PPP header. There probably also should be some minor editorial updates (for example, for text that discusses the status of various documents in ANSI/ISO, which have made progress over the last year). Finally, there might want to be a short annex to discuss issues of running IS-IS over PPP, although I think that this is very simple. You can maintain 16bit alignment by requiring the full PPP header (4 octets) or turning off the address and control fields and keeping the full protocol field (2 octets). Since you can control this through the LCP options there is no reason to add additional options. Who should I contact at Novell to discuss this?? I assume that Dave Katz (at cisco) and someone from 3Com would also be interested (3Com has a slightly non-conformant CLNP over PPP implementation). Contact Chris Ranch (cranch@novell.com). One small nit: It is not clear what is meant above by the phrase "...three different kinds of CLNP". Perhaps this should say "...four different OSI connectionless network layer protocols (CLNP, ES-IS, IS-IS, and IDRP)". It was not clear from the notes on the meeting what the meaning of "... three different kinds of CLNP ..." was so I just left that in. I suspect that you are correct now that I think about it. 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 Apr 17 13:38:19 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14774; Fri, 17 Apr 92 13:01:10 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA14087; Fri, 17 Apr 92 12:30:39 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13114; Fri, 17 Apr 92 12:17:32 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from sonny.proteon.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12883; Fri, 17 Apr 92 12:11:10 -0700 Received: by sonny.proteon.com (5.59/1.6) id AA29682; Fri, 17 Apr 92 15:08:52 EDT Date: Fri, 17 Apr 92 15:08:52 EDT From: jas@proteon.com (John A. Shriver) Message-Id: <9204171908.AA29682@sonny.proteon.com> To: callon@bigfut.enet.dec.com Cc: brian@lloyd.com, ietf-ppp@ucdavis.ucdavis.edu, callon@bigfut.enet.dec.com In-Reply-To: Ross Callon's message of Fri, 17 Apr 92 13:54:28 EDT <9204171754.AA03660@us1rmc.mso.dec.com> Subject: minutes of the SD IETF meeting Sender: ietf-ppp-request@ucdavis.edu Date: Fri, 17 Apr 92 13:54:28 EDT From: Ross Callon [...] One issue that has been brought up (by 3Com) is the possible need for an optional odd-length padding to maintain 16-bit word alignment of the beginning of the CLNP header following the PPP header. [...] Actually, some of us quite prefer to have the CNLP header start at an odd address. That's probably why it is that way. Unless CNLP is the only protocol you're handling, if you put the rest of the protocols at an even address, CNLP is the only one at an odd address. That's becuase it's almost the only protocol that uses the 3 byte 802.2 UI header, rather than 8 bytes of 802.2+802/SNAP. Certainly be sure any padding is optional. From ietf-ppp-request@ucdavis.ucdavis.edu Fri Apr 17 13:47:45 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16285; Fri, 17 Apr 92 13:40:03 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA14523; Fri, 17 Apr 92 13:16:23 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15074; Fri, 17 Apr 92 13:09:36 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from inet-gw-1.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14607; Fri, 17 Apr 92 12:58:21 -0700 Received: by inet-gw-1.pa.dec.com; id AA12681; Fri, 17 Apr 92 12:57:49 -0700 Received: by us1rmc.mso.dec.com; id AA06414; Fri, 17 Apr 92 15:57:14 -0400 Message-Id: <9204171957.AA06414@us1rmc.mso.dec.com> Received: from bigfut.enet; by us1rmc.enet; Fri, 17 Apr 92 15:57:16 EDT Date: Fri, 17 Apr 92 15:57:16 EDT From: Ross Callon To: brian@lloyd.com Cc: ietf-ppp@ucdavis.ucdavis.edu, callon@bigfut.enet.dec.com Apparently-To: brian@lloyd.com, ietf-ppp@ucdavis.edu Subject: re: minutes of the SD IETF meeting (16 bit alignment) > > You can maintain 16bit alignment by requiring the full PPP header (4 > octets) or turning off the address and control fields and keeping the > full protocol field (2 octets). Since you can control this through > the LCP options there is no reason to add additional options. > Someone from 3Com might be more able to comment on this than I, however: The way that they have implemented things this does not line up correctly. Thus, what they really want is the ability to be flexible by one byte. I am not sure whether they need to include "Flag, Address, Control, and Protocol" (total 5 bytes) in their call, or if the thing that they started with (the CLNP header) started out on an odd boundary because of coming in with an 802.2 header. In either case, the notion was that it would be valuable to provide a one byte flexibility. One possibility is to allow the encapsulated OSI network header to either start with the CLNP header, or start with an "inactive network protocol" header (one byte of zeroes) followed by the CLNP header. Note that all of CLNP, ES-IS, IS-IS, and IDRP start with a "network layer protocol ID" (NLPID), which identifies the network layer protocol. A one byte NLPID of all zero has been reserved to mean "a one octet null protocol, look at the next byte for the next protocol". Thus, sticking one byte extra in the PPP information field would be in keeping with normal OSI network layer operation. Thus it would probably be best to think of the one byte of zeroes as being pre-pended to the OSI network layer (implying that it is part of the OSI stuff contained in the PPP Information field), rather than being part of the PPP header. Ross From ietf-ppp-request@ucdavis.ucdavis.edu Fri Apr 17 15:37:35 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20006; Fri, 17 Apr 92 15:23:00 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA15522; Fri, 17 Apr 92 15:00:26 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18703; Fri, 17 Apr 92 14:46:48 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18295; Fri, 17 Apr 92 14:35:21 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA07009; Fri, 17 Apr 92 14:32:13 PDT Date: Fri, 17 Apr 92 14:32:13 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9204172132.AA07009@ray.lloyd.com> To: callon@bigfut.enet.dec.com Cc: ietf-ppp@ucdavis.ucdavis.edu, callon@bigfut.enet.dec.com In-Reply-To: Ross Callon's message of Fri, 17 Apr 92 15:57:16 EDT <9204171957.AA06414@us1rmc.mso.dec.com> Subject: minutes of the SD IETF meeting (16 bit alignment) Date: Fri, 17 Apr 92 15:57:16 EDT From: Ross Callon Apparently-To: brian@lloyd.com, ietf-ppp@ucdavis.edu . . . Thus, what they really want is the ability to be flexible by one byte. I am not sure whether they need to include "Flag, Address, Control, and Protocol" (total 5 bytes) in their call, or if the thing that they started with (the CLNP header) started out on an odd boundary because of coming in with an 802.2 header. On sync links the flag is usually eaten by the hardware so the link protocol doesn't see it. This makes the PPP header four octets (full header), two octets (compress away the address and control fields), or one octet (compress protocol field down to one octet). In either case, the notion was that it would be valuable to provide a one byte flexibility. One possibility is to allow the encapsulated OSI network header to either start with the CLNP header, or start with an "inactive network protocol" header (one byte of zeroes) followed by the CLNP header. Note that all of CLNP, ES-IS, IS-IS, and IDRP start with a "network layer protocol ID" (NLPID), which identifies the network layer protocol. A one byte NLPID of all zero has been reserved to mean "a one octet null protocol, look at the next byte for the next protocol". Thus, sticking one byte extra in the PPP information field would be in keeping with normal OSI network layer operation. Thus it would probably be best to think of the one byte of zeroes as being pre-pended to the OSI network layer (implying that it is part of the OSI stuff contained in the PPP Information field), rather than being part of the PPP header. Sounds like a non-issue. If the OSI protocols are happy with an octet of zeros appended to the front of the packet, who are we to argue? Does this need to be negotiated? 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 Apr 17 15:55:39 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20624; Fri, 17 Apr 92 15:40:33 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA15712; Fri, 17 Apr 92 15:27:16 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19433; Fri, 17 Apr 92 15:05:57 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from bridge2.NSD.3Com.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18712; Fri, 17 Apr 92 14:47:07 -0700 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA27929 (5.65c/IDA-1.4.4nsd for ); Fri, 17 Apr 1992 14:46:45 -0700 Received: by jaspar.NSD.3Com.COM id AA15331 (5.65c/IDA-1.4.4-910730); Fri, 17 Apr 1992 14:46:43 -0700 Date: Fri, 17 Apr 1992 14:46:43 -0700 From: "Cyndi M. Jung" Message-Id: <199204172146.AA15331@jaspar.NSD.3Com.COM> To: callon@bigfut.enet.dec.com Subject: re: minutes of the SD IETF meeting Cc: ietf-ppp@ucdavis.ucdavis.edu > One issue that >has been brought up (by 3Com) is the possible need for an optional >odd-length padding to maintain 16-bit word alignment of the beginning >of the CLNP header following the PPP header. >(3Com has a slightly non-conformant CLNP over PPP implementation). Just to put this in context, when we (3Com) first implemented CLNP (and IS-IS) over PPP, we wanted the above mentioned pad option so the alignment of the CLNP header would be the same as it is when received from a LAN port - this was much preferrable to copying the entire packet to align it. We did give input to Dave Katz about such an option, and, well, nothing happened beyond some e-mail. We have indeed shipped our CLNP over PPP with the LLC1 header on it so we could maintain alignment in memory the same as the LAN interface. It seemed harmless at the time since we could find nobody else implementing anything over PPP beyond IP. However, we do believe in interoperability, and have mended our ways, and the software releases this summer will have the "standard" PPP encapsulation (though it will perform our performance-oriented hack if it talks to one of our previous "slightly non-conformant" products). We would really like to run as fast as possible, so it would really be nice if the insertion of optional pads between the PPP header and the CLNP header could be allowed without creating interoperability problems. Cyndi Jung From ietf-ppp-request@ucdavis.ucdavis.edu Fri Apr 17 16:40:29 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22080; Fri, 17 Apr 92 16:23:22 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA15888; Fri, 17 Apr 92 15:49:18 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20471; Fri, 17 Apr 92 15:34:56 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19745; Fri, 17 Apr 92 15:15:16 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA07085; Fri, 17 Apr 92 15:14:43 PDT Date: Fri, 17 Apr 92 15:14:43 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9204172214.AA07085@ray.lloyd.com> To: cmj@NSD.3Com.COM Cc: callon@bigfut.enet.dec.com, dhg@NSD.3Com.COM, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: "Cyndi M. Jung"'s message of Fri, 17 Apr 1992 15:02:09 -0700 <199204172202.AA15382@jaspar.NSD.3Com.COM> Subject: more regarding OSI over PPP (note from Brian and my response). Thanks for the comments Cyndi. As I said to Ross, it appears to be a non-PPP issue that is easily solved by the OSI interface to PPP. Is there a problem? As for OSI being slow, heck even elephants move fairly quickly when properly motivated. ;-) 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 Apr 17 17:06:12 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23412; Fri, 17 Apr 92 16:58:03 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA16199; Fri, 17 Apr 92 16:30:22 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21877; Fri, 17 Apr 92 16:16:15 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21233; Fri, 17 Apr 92 15:59:57 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA07143; Fri, 17 Apr 92 15:59:25 PDT Date: Fri, 17 Apr 92 15:59:25 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9204172259.AA07143@ray.lloyd.com> To: cmj@NSD.3Com.COM Cc: callon@bigfut.enet.dec.com, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: "Cyndi M. Jung"'s message of Fri, 17 Apr 1992 14:46:43 -0700 <199204172146.AA15331@jaspar.NSD.3Com.COM> Subject: minutes of the SD IETF meeting Ross suggested that a single null octet appended to the front of the CLNP packet will have the desired effect. Is this true? 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 Apr 17 17:16:32 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23773; Fri, 17 Apr 92 17:08:10 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA16314; Fri, 17 Apr 92 16:45:30 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22753; Fri, 17 Apr 92 16:40:11 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from bridge2.NSD.3Com.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22125; Fri, 17 Apr 92 16:24:52 -0700 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA01776 (5.65c/IDA-1.4.4nsd for ); Fri, 17 Apr 1992 16:24:34 -0700 Received: by jaspar.NSD.3Com.COM id AA15627 (5.65c/IDA-1.4.4-910730); Fri, 17 Apr 1992 16:24:33 -0700 Date: Fri, 17 Apr 1992 16:24:33 -0700 From: "Cyndi M. Jung" Message-Id: <199204172324.AA15627@jaspar.NSD.3Com.COM> To: brian@lloyd.com Subject: PPP and OSI Cc: callon@bigfut.enet.dec.com, ietf-ppp@ucdavis.ucdavis.edu Yes ----- Begin Included Message ----- From brian@lloyd.com Fri Apr 17 15:59:42 1992 From: brian@lloyd.com (Brian Lloyd) To: cmj@nsd.3com.com Cc: callon@bigfut.enet.dec.com, ietf-ppp@ucdavis.edu Subject: minutes of the SD IETF meeting Reply-To: brian@lloyd.com Ross suggested that a single null octet appended to the front of the CLNP packet will have the desired effect. Is this true? 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 ----- End Included Message ----- From ietf-ppp-request@ucdavis.ucdavis.edu Fri Apr 17 20:45:38 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02521; Fri, 17 Apr 92 20:34:51 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17163; Fri, 17 Apr 92 20:15:04 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01131; Fri, 17 Apr 92 20:00:36 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00762; Fri, 17 Apr 92 19:51:02 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA07650; Fri, 17 Apr 92 19:50:39 PDT Date: Fri, 17 Apr 92 19:50:39 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9204180250.AA07650@ray.lloyd.com> To: cmj@NSD.3Com.COM Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: "Cyndi M. Jung"'s message of Fri, 17 Apr 1992 18:58:48 -0700 <199204180158.AA16014@jaspar.NSD.3Com.COM> Subject: PPP and OSI Date: Fri, 17 Apr 1992 18:58:48 -0700 From: "Cyndi M. Jung" Well, we've already taken out the LLC header so that we can interoperate with the Novell implementation, which includes IS-IS on the PPP link, so I guess that's two implementations. Do we have to ship it before it counts? No. We just need interoperable implementations that are documented. Do your implementations match the draft docs? 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 Sat Apr 18 14:00:36 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07024; Sat, 18 Apr 92 13:53:12 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA19961; Sat, 18 Apr 92 13:30:13 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06228; Sat, 18 Apr 92 13:16:21 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06019; Sat, 18 Apr 92 13:08:45 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA28318; Sat, 18 Apr 92 16:08:14 -0400 Date: Sat, 18 Apr 92 15:36:18 EDT From: "William Allen Simpson" Message-Id: <271.bsimpson@vela.acs.oakland.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: PPP and OSI > Who should I contact at Novell to discuss this?? I assume that > Dave Katz (at cisco) and someone from 3Com would also be interested > (3Com has a slightly non-conformant CLNP over PPP implementation). > Dave Katz wrote this while at Merit. I nroff'd it (since he used WordPerfect, or some such), and submitted it to internet-drafts. I left his name on it, because he's the original author, so he deserves the credit. I'm just the editor. We have been waiting for implementation experience. Now that we have some, I will add the necessary changes to the document, and re-post to internet-drafts. Since the philosophy of configuration options is to inform the peer of the receiver's capabilities, I think we should add the option to request the leading zero octet, when the receiver needs to save CPU time. The peer can ACK, NAK, or Reject as usual. On the other hand, since it's already part of the CLNP, the sender can legally add the zero octet even if the peer hasn't requested it. This wastes bandwidth for less CPU effort. A properly functioning implementation will always receive either version. Thanks to Ross for raising the issue. Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu From ietf-ppp-request@ucdavis.ucdavis.edu Sat Apr 18 16:15:42 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10142; Sat, 18 Apr 92 16:06:07 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA20479; Sat, 18 Apr 92 15:30:08 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08893; Sat, 18 Apr 92 15:15:36 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08692; Sat, 18 Apr 92 15:09:42 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA02485; Sat, 18 Apr 92 18:09:05 -0400 Date: Sat, 18 Apr 92 18:05:25 EDT From: "William Allen Simpson" Message-Id: <274.bsimpson@vela.acs.oakland.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: ppp-osi.txt There is a new draft for OSI over PPP. It may be found at angband.stanford.edu:pub/ppp/ppp-osi.txt Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu From ietf-ppp-request@ucdavis.ucdavis.edu Sat Apr 18 16:30:50 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10460; Sat, 18 Apr 92 16:20:56 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA20537; Sat, 18 Apr 92 15:45:56 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09490; Sat, 18 Apr 92 15:35:29 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from MrBill.CAnet.CA by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09075; Sat, 18 Apr 92 15:23:22 -0700 Received: by MrBill.CAnet.CA id <105489>; Sat, 18 Apr 1992 18:22:46 +0100 From: Dennis Ferguson To: brian@lloyd.com Subject: Re: LCP options extentions Cc: ietf-ppp@ucdavis.ucdavis.edu Message-Id: <92Apr18.182246bst.105489@MrBill.CAnet.CA> Date: Sat, 18 Apr 1992 18:22:43 +0100 Brian Lloyd writes: > Adding LAPB makes no sense to me at all. PPP is intended to be a > mechanism for the delivery of unreliable datagrams. In this fashion > it meets the needs of IP, IPX, Appletalk, DECnet, CLNP, and others. > Why in the world would you want to bog it down with LAPB? I can answer that, I think. If you look at TCP in particular, its end-to-end retransmissions are meant to allow more than datagram loss due to line errors, in fact this is the lesser of their functions. TCP's end-to-end reliability also allows us to build routers which drop packets when they are congested, and to dynamically reroute around downed circuits without regard for the connections which might have been using the link. Now if you consider what the proper response should be to the loss of a packet due to a line error compared to that when a packet is dropped by a congested router, you'll see that they are different. If a packet is dropped due to a line error the best thing to do is send the packet again right away, since the probability of the retransmitted packet being dropped as well is the same whether you send it now or later and resending immediately will minimize the delay suffered by the packet crossing the circuit. If the packet is dropped by a router due to congestion, however, the proper response is to stop sending for a while to allow the congestion to clear, as this increases the probability that the next retransmission will find the problem which caused the previous packet to be dropped will have cleared. Unfortunately, TCP can't tell whether a packet was dropped due to line errors or congestion problems, all it sees is a missing packet. TCP hence can't vary its response to the loss of a packet, it has to make a one-response-fits-all decision. In this case the conservative thing to do is assume the loss was due to congestion and stop sending. The implication is that you really don't want to run TCP, or any other datagram transport, over a circuit which is dropping more than a very occasional frame to line errors since TCP won't be able to make good use of that circuit. You can see this in practice, if you look at a circuit which is dropping a few percent of the frames to line errors you'll probably find that the performance impact on TCP is much, much greater than a few percent of the bandwidth. Add a link-level retransmission protocol to the circuit, however, and you'll find things immediately improve to the point where dropping a few percent of the frames consumes not much more than a few percent of the bandwidth. Now adding LAPB over your typical synchronous phone circuit, or to run through a modern error-correcting dialup modem, does indeed not make much sense since these types of circuits generally don't drop many packets. Here the overhead of a reliable link-level protocol is certainly a waste, since link level retransmissions will hardly ever be necessary and since TCP, which is going to running end-to-end in any case, can quite handily recover from an occasional drop. If the medium you are running over is inherently more lossy, however, say a piece of copper running three miles down the road to the location of your experimental apparatus in the field, or a packet radio link, or even a circuit where compression is advantageous, you may very well need a reliable link-level protocol to maintain the usability of the circuit. In this case the question becomes, why in the world would you want to design a new protocol for link and network protocol parameter negotiation, and protocol (de)multiplexing, just because the physical characteristics of the p2p circuit are such that you need a link-level retransmission protocol or non-HDLC framing? The fact that PPP carries datagrams shouldn't mean that you can't run it over a circuit running a retransmission procedure, just that you don't always need to. I personally think the proper way to do this is (was?) to avoid restricting PPP to any particular physical medium and associated link-level procedures. If you step back and look at PPP apart from the physical layers it likes, I think you'll see a protocol which can be used advantageously over any framed or unframed point-to-point access procedures. Indeed, sync circuits using raw HDLC framing, and async circuits, are simply special cases of the two more general classes of situations where PPP could be useful. It really shouldn't matter whether PPP packets are framed by raw HDLC, or by LAPB, or by LAPB following a compressor, or by the proprietary framing protocol running over a point-to-point packet radio circuit. In the latter two cases you might want to negotiate PPP's CRC off, but you'll still want the bytes up front for protocol demultiplexing and that's all the overhead PPP imposes. I think the real problem here is not so much whether PPP should support LAPB or not, but rather that the spec is unfortunately incautious about mixing in issues of flags, and bit stuffing, and start and stop bits, and NRZ vs. NRZI, and other things related to specific physical media and link access procedures, with issues of more generic applicability. With a cleaner separation, so that PPP wasn't so inextricably tied to the two physical layers in the spec, one could have responded to a request for PPP-over-LAPB, or PPP-over-software-compression-over-whatever, or PPP-over-proprietary-packet-radio-link-access, with a request that those interested write a document describing how to do this so we all could benefit. The way it is now, however, we seem to be reduced to either incorporating these procedures into the base PPP document, or arguing why one shouldn't want to do these things with PPP. This is unfortunate. Dennis Ferguson University of Toronto From ietf-ppp-request@ucdavis.ucdavis.edu Sat Apr 18 19:30:31 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14013; Sat, 18 Apr 92 19:15:19 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA20964; Sat, 18 Apr 92 19:00:00 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13415; Sat, 18 Apr 92 18:45:30 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13288; Sat, 18 Apr 92 18:42:59 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA00247; Sat, 18 Apr 92 18:42:29 PDT Date: Sat, 18 Apr 92 18:42:29 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9204190142.AA00247@ray.lloyd.com> To: dennis@MrBill.CAnet.CA Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Dennis Ferguson's message of Sat, 18 Apr 1992 18:22:43 +0100 <92Apr18.182246bst.105489@MrBill.CAnet.CA> Subject: LCP options extentions Actually, my question was rhetorical. I know when you would want error correction on a link and when you wouldn't. I have a great deal of experience with lossy links from amateur packet radio. Amateur packet radio uses a variation of LAPB as its link protocol. If the link gets really lossy, an ARQ protocol on the link can help. BUT, here we are talking about PPP over wire links (for the most part). Even though the link can lose packets, it does so very infrequently. In the case of async lines, most modems already have error-correcting ARQ protocols built in. Their apparent BER is extremely low. 56K and T1 links, while they don't have error correction, are also very reliable (they tend to either work or not work with very little middle ground). The overhead of additional encapsulation and sending link-layer ACKs back over the link greatly outweighs the need to occasionally do retransmission with TCP. I think that your point about running PPP over LAPB or HDLC is interesting. There is no reason why it can't be done when you consider that PPP is just data encapsulated in UI frames. Perhaps it would be worthwhile to talk about doing LAPB or HDLC. As you say, there are reasons where it might be useful. As for your comments about the physical layer stuff in the LCP document: the information needed to go somewhere. I have been hoping that someone would write an informational document describing accepted practice in implementation so that there was a greater likelyhood of interoperability. Until then there is information somewhere. 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 Apr 19 01:16:51 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20961; Sun, 19 Apr 92 01:04:28 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA21773; Sun, 19 Apr 92 00:45:12 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20411; Sun, 19 Apr 92 00:30:28 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from cregrd.creighton.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20049; Sun, 19 Apr 92 00:17:06 -0700 Received: by cregrd.creighton.edu (/\==/\ Smail3.1.22.1 #22.10) id ; Sun, 19 Apr 92 02:16 CDT Message-Id: Subject: Question for vendors... To: ietf-ppp@ucdavis.ucdavis.edu Date: Sun, 19 Apr 92 2:16:16 CDT From: Chris Swanson X-Mailer: ELM [version 2.3 PL11] Greetings, I know that this is probably not the best place for this request, but I wanted to get in touch with vendors with PPP implimentations avail. or in development. We are looking for multi-port terminal servers, etc. that will allow dial-in users to make a PPP connection to the net like SLIP terminal servers do now. It would be nice to have dynamic address assignment but not necessary. I already know about the Netblazer. Sorry for the bandwidth. Regards, -=Chris From ietf-ppp-request@ucdavis.ucdavis.edu Sun Apr 19 11:30:42 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02651; Sun, 19 Apr 92 11:18:45 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA23007; Sun, 19 Apr 92 11:00:11 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01816; Sun, 19 Apr 92 10:45:29 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from regal.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01551; Sun, 19 Apr 92 10:37:52 -0700 Received: by regal.cisco.com; Sun, 19 Apr 92 10:36:13 -0700 Date: Sun, 19 Apr 92 10:36:13 -0700 From: Dave Katz Message-Id: <9204191736.AA23878@regal.cisco.com> To: callon@bigfut.enet.dec.com Cc: brian@lloyd.com, ietf-ppp@ucdavis.ucdavis.edu, callon@bigfut.enet.dec.com In-Reply-To: Ross Callon's message of Fri, 17 Apr 92 15:57:16 EDT <9204171957.AA06414@us1rmc.mso.dec.com> Subject: minutes of the SD IETF meeting (16 bit alignment) This is mostly true, although it means that the keepers of ISO 9577 must ensure that NLPIDs and SPIs don't collide. It's also an awful hack, even by OSI standards. (We're trying to kill the Inactive NL Subset, no?) My memory is fuzzy, but isn't it the case that the long/short version of the PPP protocol ID gives the 1 byte "option" wanted? I'd just as soon keep this silliness in the PPP headers rather than in the OSI NL payload. Sender: ietf-ppp-request@ucdavis.edu Date: Fri, 17 Apr 92 15:57:16 EDT From: Ross Callon Apparently-To: brian@lloyd.com, ietf-ppp@ucdavis.edu > > You can maintain 16bit alignment by requiring the full PPP header (4 > octets) or turning off the address and control fields and keeping the > full protocol field (2 octets). Since you can control this through > the LCP options there is no reason to add additional options. > Someone from 3Com might be more able to comment on this than I, however: The way that they have implemented things this does not line up correctly. Thus, what they really want is the ability to be flexible by one byte. I am not sure whether they need to include "Flag, Address, Control, and Protocol" (total 5 bytes) in their call, or if the thing that they started with (the CLNP header) started out on an odd boundary because of coming in with an 802.2 header. In either case, the notion was that it would be valuable to provide a one byte flexibility. One possibility is to allow the encapsulated OSI network header to either start with the CLNP header, or start with an "inactive network protocol" header (one byte of zeroes) followed by the CLNP header. Note that all of CLNP, ES-IS, IS-IS, and IDRP start with a "network layer protocol ID" (NLPID), which identifies the network layer protocol. A one byte NLPID of all zero has been reserved to mean "a one octet null protocol, look at the next byte for the next protocol". Thus, sticking one byte extra in the PPP information field would be in keeping with normal OSI network layer operation. Thus it would probably be best to think of the one byte of zeroes as being pre-pended to the OSI network layer (implying that it is part of the OSI stuff contained in the PPP Information field), rather than being part of the PPP header. Ross From ietf-ppp-request@ucdavis.ucdavis.edu Sun Apr 19 12:30:29 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04310; Sun, 19 Apr 92 12:18:55 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA23135; Sun, 19 Apr 92 12:00:05 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03476; Sun, 19 Apr 92 11:45:43 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03209; Sun, 19 Apr 92 11:35:49 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA00505; Sun, 19 Apr 92 11:34:07 PDT Date: Sun, 19 Apr 92 11:34:07 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9204191834.AA00505@ray.lloyd.com> To: dkatz@cisco.com Cc: callon@bigfut.enet.dec.com, ietf-ppp@ucdavis.ucdavis.edu, callon@bigfut.enet.dec.com In-Reply-To: Dave Katz's message of Sun, 19 Apr 92 10:36:13 -0700 <9204191736.AA23878@regal.cisco.com> Subject: minutes of the SD IETF meeting (16 bit alignment) Date: Sun, 19 Apr 92 10:36:13 -0700 From: Dave Katz My memory is fuzzy, but isn't it the case that the long/short version of the PPP protocol ID gives the 1 byte "option" wanted? I'd just as soon keep this silliness in the PPP headers rather than in the OSI NL payload. Sorry, you can't count on that. There is no guarantee that the sender will always send a compressed (1 octet) protocol field. If the receiver says that it will accept a compressed protocol field that means that the send has the -option- of compression the protocol field or not, at its choice. You can force the other end to always send a 2-octet protocol field but not the other way around. Seems to me that the sender is going to have to control alignment, not the receiver, IF your receiver is going to run fast and not have to make any decisions while receiving frames. 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 Apr 19 14:01:05 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06411; Sun, 19 Apr 92 13:33:53 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA23358; Sun, 19 Apr 92 13:15:01 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05516; Sun, 19 Apr 92 13:00:58 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from regal.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05385; Sun, 19 Apr 92 12:56:28 -0700 Received: by regal.cisco.com; Sun, 19 Apr 92 12:56:03 -0700 Date: Sun, 19 Apr 92 12:56:03 -0700 From: Dave Katz Message-Id: <9204191956.AA24172@regal.cisco.com> To: cmj@NSD.3Com.COM Cc: brian@lloyd.com, callon@bigfut.enet.dec.com, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: "Cyndi M. Jung"'s message of Fri, 17 Apr 1992 16:24:33 -0700 <199204172324.AA15627@jaspar.NSD.3Com.COM> Subject: PPP and OSI Because of changes made to TP in edition 2, this kludge is not guaranteed to work in all cases. Basically you can't really tell the difference between a NUL followed by a CLNP header and a NUL followed by a TP header with a length of 129. Now you may tell me that 129 is not a reasonable size for a TP header (I don't know this for sure) and you may tell me that nobody *really* runs TP over the inactive NL subset (I sure hope it's true), but it is simply not the case that sticking a NUL in front of any arbitrary NL packet is something that will work deterministically in all cases. *Please* find a different kludge and put it in PPP where it belongs (I'm sure I'll get differing opinions on that last phrase...). Phlame oph. Sender: ietf-ppp-request@ucdavis.edu Date: Fri, 17 Apr 1992 16:24:33 -0700 From: "Cyndi M. Jung" Yes ----- Begin Included Message ----- >From brian@lloyd.com Fri Apr 17 15:59:42 1992 From: brian@lloyd.com (Brian Lloyd) To: cmj@nsd.3com.com Cc: callon@bigfut.enet.dec.com, ietf-ppp@ucdavis.edu Subject: minutes of the SD IETF meeting Reply-To: brian@lloyd.com Ross suggested that a single null octet appended to the front of the CLNP packet will have the desired effect. Is this true? 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 ----- End Included Message ----- From ietf-ppp-request@ucdavis.ucdavis.edu Mon Apr 20 08:50:00 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13493; Mon, 20 Apr 92 08:37:57 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA26948; Mon, 20 Apr 92 08:15:08 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12456; Mon, 20 Apr 92 08:02:34 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from relay.hp.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12098; Mon, 20 Apr 92 07:47:38 -0700 Received: from hprdash.rose.hp.com by relay.hp.com with SMTP (16.6/15.5+IOS 3.13) id AA08259; Mon, 20 Apr 92 07:47:16 -0700 Received: from by hprdash.rose.hp.com with SMTP (16.6/15.5+IOS 3.21+OM) id AA24959; Mon, 20 Apr 92 07:45:36 -0700 Date: Mon, 20 Apr 92 07:45:36 -0700 From: CONGDON_PAUL/HP5200_15@hprdash.rose.hp.com Message-Id: <9204201445.AA24959@hprdash.rose.hp.com> Subject: LCP options extentions X-Openmail-Hops: 1 To: ietf-ppp@ucdavis.ucdavis.edu, ietf-ppp-request@ucdavis.ucdavis.edu Item Subject: Reply: LCP options extentions The one thing everyone seems to be missing on this compression issue is latency. Modem latency is significant! It could be reduced by doing compression in software. Let's look at a worst case transmission; an application to application request-reply protocol (which seem to be popular these days): 1. a buffer is copied from the application to the kernel 2. the transport (e.g. TCP) does a checksum 3. the buffer is copied out the UART to the modem 4. the modem waits for enough data to form its own buffer, hopefully compressing the data on the fly. 5. the modem buffer is copied through the PSTN 6. the other modem waits for the entire buffer to be received 7. the other modem decompresses the buffer, and hopefully starts moving the data out the UART. 8. the other host waits for the entire packet from its modem 9. the transport is called, another checksum performed 10. the buffer is copied to the application Now start over and do it again! I'm sure some have figured out ways to condense these steps. One way might be to forget the reliable modem link and modem compression, and do compression in software when moving it from the user's buffer or while doing a TCP checksum. Just use a raw carrier and start moving bytes through the slowest part of the path ASAP. If messing with the APIs or protocols is too yucky, then maybe software compression could be done while moving data to the UART. If you do it at the UART then you aren't doing a synchronous dictionary compression scheme requiring a reliable link. These schemes probably (maybe, but I'm not sure) do a better job of compressing data, but they don't help latency. There is still the question of their effectiveness when multiple connections are involved. I just hate to see the small packet being ignored in these compression talks... Latency is a problem, but it is rarely used in benchmarks. Especially the benchmarks marketing types like to talk about Paul Congdon +----------------------------------+-------------------------------+ + Paul Congdon + Member of Technical Staff + + Hewlett Packard Company + Mail Stop: R3NF2 + + Roseville Networks Division + Email: ptc@hprnd.rose.hp.com + + 8000 Foothills Blvd + Phone: (916) 785-5753 + + Roseville, CA 95678 + Fax: (916) 786-9185 + +----------------------------------+-------------------------------+ From ietf-ppp-request@ucdavis.ucdavis.edu Mon Apr 20 12:47:06 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21318; Mon, 20 Apr 92 12:25:47 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA00479; Mon, 20 Apr 92 12:00:09 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20117; Mon, 20 Apr 92 11:47:49 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19603; Mon, 20 Apr 92 11:32:25 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA01217; Mon, 20 Apr 92 11:32:03 PDT Date: Mon, 20 Apr 92 11:32:03 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9204201832.AA01217@ray.lloyd.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Compression I think that this discussion of compression has been beaten to death. Compression at the link layer is not efficient. In the case where it really buys you something, e.g., at very low speeds, the modems already do compression. We do have some other pressing issues to deal with here, namely Appletalk, OSI/CLNP, and IPX. Let's work on those and get back to compression later. 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 Apr 20 16:49:11 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29435; Mon, 20 Apr 92 16:41:04 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA03707; Mon, 20 Apr 92 16:15:11 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28217; Mon, 20 Apr 92 16:02:55 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27707; Mon, 20 Apr 92 15:46:46 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA11418; Mon, 20 Apr 92 18:46:17 -0400 Date: Mon, 20 Apr 92 17:35:05 EDT From: "William Allen Simpson" Message-Id: <278.bsimpson@vela.acs.oakland.edu> To: internet-drafts@nri.reston.va.us Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: ppp-ap.txt There is a new PPP Authentication Protocols draft (with more comments from the Security-o-philes) at: angband.stanford.edu:pub/ppp/ppp-ap.txt Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu From ietf-ppp-request@ucdavis.ucdavis.edu Mon Apr 20 18:19:54 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02749; Mon, 20 Apr 92 18:08:12 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04568; Mon, 20 Apr 92 17:45:33 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01642; Mon, 20 Apr 92 17:36:52 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from omnigate.clarkson.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00987; Mon, 20 Apr 92 17:20:13 -0700 Message-Id: <9204210020.AA00987@ucdavis.ucdavis.edu> Date: Mon, 20 Apr 92 20:15:43 EDT From: Brad Clements To: Kim Toms Cc: Bob Sutterfield , ietf-ppp@ucdavis.ucdavis.edu Subject: Re: PPP and Compression (was [brad@Cayman.COM: Re: LCP options extensions ]) This might not be relavent to the current subject, however someone mentioned the use of splay trees and data compression. Several years ago when I first put together the Sun OS streams PPP driver, I did have a mode that performed VJ compression on the TCP headers and Splay Compression on the data portion. Performance was quite reasonable. Essentially splay compression uses one or more trees per data stream. My implementation dynamically allocated trees to whichever virtual connection could make the `best' use of them. Each tree was about 1K octects in size. Trees could be added and removed from a virtual session without reinitializing the remaining trees. When adding a tree, a zero-initialized tree was used. On 3278 datastreams, 25 trees was sufficient to nearly equal the compression performance of LZW. Of course, only 25K vis 400+K was needed. The splay code was inserted in the datastream after VJ compression took place, and the data packet was uncompressed before VJ decompression. The same basic routines as the VJ code was used: when VJ retransmitted a packet (thereby sending an uncompressed TCP header with a slot id), we transmitted an uncompressed data portion and reset the splay trees to zero. -- The only difficulty I ran into was that since the allocation of trees was dynamically determined by the data flow, each end of the link wanted to allocate trees differently. A single pool was used for both send and receive. Two pools, one for send and one for receive, would have been best, and would have eliminated the 'bouncing tree allocation' which I observed on occasion. -- But then compressing modems became relatively cheap and I dropped the idea. I have not done anything with it since, but the idea is still sound, and it is simple and doesn't require much memory, ideal for portable PCs. | Brad Clements bkc@omnigate.clarkson.edu bkc@clutx.bitnet | Sr. Network Engineer Clarkson University (315)268-2292 From ietf-ppp-request@ucdavis.ucdavis.edu Mon Apr 20 19:21:12 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04667; Mon, 20 Apr 92 19:05:27 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04916; Mon, 20 Apr 92 18:46:32 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03853; Mon, 20 Apr 92 18:40:21 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03465; Mon, 20 Apr 92 18:30:09 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA01589; Mon, 20 Apr 92 18:29:40 PDT Date: Mon, 20 Apr 92 18:29:40 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9204210129.AA01589@ray.lloyd.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: old business We currently have a MIB document pending comments. I will wait about one more week before recommending it to the IESG for a last-call. Please read the MIB document and make your comments here. Speak now or forever hold your peace. 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 Apr 20 19:31:49 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05161; Mon, 20 Apr 92 19:20:53 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04997; Mon, 20 Apr 92 19:00:08 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04189; Mon, 20 Apr 92 18:50:03 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03717; Mon, 20 Apr 92 18:35:39 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA01593; Mon, 20 Apr 92 18:35:08 PDT Date: Mon, 20 Apr 92 18:35:08 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9204210135.AA01593@ray.lloyd.com> To: mm@hobbit.gandalf.ca Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Mississippi Mud's message of Mon, 20 Apr 92 18:19:44 EDT <9204202219.AA10609@hobbit.gandalf.ca> Subject: bring out yer dead... Sender: ietf-ppp-request@ucdavis.edu Date: Mon, 20 Apr 92 18:19:44 EDT From: mm@hobbit.gandalf.ca (Mississippi Mud) I would not want to see a bunch of different NCP compression negotiations added at random, if anyone seriously thinks an LCP mechanism will eventually be added. I believe very strongly that compression at the link layer is not a win unless the link is carrying homogenious data. This tends to happen in slow links (modems) but the modems already offer link compression. Anyway, I have stated my position. >We do have some other pressing issues to deal with here, namely >Appletalk, OSI/CLNP, and IPX. Let's work on those and get back to >compression later. But, but, Appletalk and IPX are... oh, never mind. Right, they are. I hope that Novell proceeds quickly toward getting their informational RFC that describes how the Netware protocols make use of PPP. Are XNS and Vines IP back-burner then too? I personally have no great interest in XNS or Vines therefore am unlikely to write an NCP for these protocols myself. Until someone else writes appropriate documents nothing is likely to happen. Chris Sullivan (mm@gandalf.ca) "but I'm not *dead* yet..." But I feel like I should be. :-) 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 Apr 20 20:02:20 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06171; Mon, 20 Apr 92 19:50:14 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05052; Mon, 20 Apr 92 19:15:05 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04570; Mon, 20 Apr 92 19:02:36 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from relay1.UU.NET by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04049; Mon, 20 Apr 92 18:45:31 -0700 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA06575; Mon, 20 Apr 92 21:45:08 -0400 Received: from neda.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 214444.28004; Mon, 20 Apr 1992 21:44:44 EDT Received: by rostam.NEDA.COM (4.1/smail2.5/04-11-92) id AA02495; Mon, 20 Apr 92 18:11:23 PDT Message-Id: <9204210111.AA02495@rostam.NEDA.COM> To: Bob Stewart Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: Reliable Transport over Reliable Physical/Data Link In-Reply-To: Your message of "Sat, 18 Apr 92 19:45:34 CDT." <9204190045.AA19247@xap.xyplex.com> Date: Mon, 20 Apr 92 18:11:20 -0700 From: Mohsen Banan >>>>> "Bob" == Bob Stewart writes: Bob> For a long time I've wondered if we could do a better job of Bob> deciding how to run the lower levels if both the higher and Bob> lower levels could be a bit more specific about what they Bob> expect. Wouldn't it be nice if TCP had some numbers, at least Bob> ranges, of packet loss where it expects to run acceptably, and Bob> the Data Links said how many frames they expected to lose and Bob> with what latency and you could just calculate whether to turn Bob> on LAPB. Of course you'd have a problem of cumulative effect Bob> over many links, but at least we could be wrong based on some Bob> mathematics instead of speculation. I wonder if this is not a set up so that people on the ISO camp may take up the opportunity and point out that for the very same reason that you have mentioned, 5 classes in Transport Protocol have been defined to compensate for unreliable nature of the underlying network and only to the extent that is necessary. The idea is that eventually we end up with implementations that really use the QOS -- Quality of Service -- parameters. I am not a serious participant in this group. However, the set up was so nice that I just couldn't resist putting on the idealist hat on for a few moments. Back to reality now. -- Mohsen Banan Tele-Voice tel: +1-206-644-8026 17005 S.E. 31st Place fax: +1-206-562-9591 Bellevue, Wa 98008 E-Mail: mohsen@neda.com U.S.A. uunet!neda!mohsen From ietf-ppp-request@ucdavis.ucdavis.edu Mon Apr 20 21:01:20 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08190; Mon, 20 Apr 92 20:55:51 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05320; Mon, 20 Apr 92 20:30:06 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07010; Mon, 20 Apr 92 20:15:46 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from regal.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06728; Mon, 20 Apr 92 20:08:29 -0700 Received: by regal.cisco.com; Mon, 20 Apr 92 20:08:04 -0700 Date: Mon, 20 Apr 92 20:08:04 -0700 From: Dave Katz Message-Id: <9204210308.AA17769@regal.cisco.com> To: mohsen%rostam@uunet.UU.NET Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Mohsen Banan's message of Mon, 20 Apr 92 18:11:20 -0700 <9204210111.AA02495@rostam.NEDA.COM> Subject: Reliable Transport over Reliable Physical/Data Link As a sometimes member of the "ISO camp" (oh dear, there goes my credibility), I'll offer the observation that having five classes of transport is incredibly stupid, and that everybody should just run TP4 and be done with it. The problem with trying to make the transport layer "smart" about the media is that only the first hop is understood a priori, and the path out in the middle can change over time, so unless the adaptation is very dynamic (and/or very general), it's difficult to do very much of this sort of thing. About the only thing that's really done along this line is the signalling of the "congestion experienced" bit to the receiver's transport layer, which can then try to do something smart with window size adjustments and the like. Sender: ietf-ppp-request@ucdavis.edu Date: Mon, 20 Apr 92 18:11:20 -0700 From: Mohsen Banan >>>>> "Bob" == Bob Stewart writes: Bob> For a long time I've wondered if we could do a better job of Bob> deciding how to run the lower levels if both the higher and Bob> lower levels could be a bit more specific about what they Bob> expect. Wouldn't it be nice if TCP had some numbers, at least Bob> ranges, of packet loss where it expects to run acceptably, and Bob> the Data Links said how many frames they expected to lose and Bob> with what latency and you could just calculate whether to turn Bob> on LAPB. Of course you'd have a problem of cumulative effect Bob> over many links, but at least we could be wrong based on some Bob> mathematics instead of speculation. I wonder if this is not a set up so that people on the ISO camp may take up the opportunity and point out that for the very same reason that you have mentioned, 5 classes in Transport Protocol have been defined to compensate for unreliable nature of the underlying network and only to the extent that is necessary. The idea is that eventually we end up with implementations that really use the QOS -- Quality of Service -- parameters. I am not a serious participant in this group. However, the set up was so nice that I just couldn't resist putting on the idealist hat on for a few moments. Back to reality now. -- Mohsen Banan Tele-Voice tel: +1-206-644-8026 17005 S.E. 31st Place fax: +1-206-562-9591 Bellevue, Wa 98008 E-Mail: mohsen@neda.com U.S.A. uunet!neda!mohsen From ietf-ppp-request@ucdavis.ucdavis.edu Mon Apr 20 21:46:34 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09783; Mon, 20 Apr 92 21:43:27 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05493; Mon, 20 Apr 92 21:15:11 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08384; Mon, 20 Apr 92 21:00:56 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08025; Mon, 20 Apr 92 20:49:14 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA01107; Mon, 20 Apr 92 23:48:41 -0400 Date: Mon, 20 Apr 92 20:04:01 EDT From: "William Allen Simpson" Message-Id: <280.bsimpson@vela.acs.oakland.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: In-Reply-To: bring out yer dead... > I would not want to see a bunch of different NCP compression negotiations > added at random, if anyone seriously thinks an LCP mechanism will eventually > be added. > There is no possibility that they will be added at random. Anyone who wants a PPP protocol number has to ask the IANA -- which is not allowed to assign one without the approval of the working group chair -- who will not grant approval until an internet-draft has been written -- which means the group will be notified and have an opportunity for revise it. Try reading the Standards Procedures RFC. In fact, try reading the historical archive for PPP at ucdavis.edu; then, actually finish your PPP implementation; then, come back and talk about extensions. I really get annoyed with folks who bring up arguments that we finished years ago. And folks who don't actually implement wanting more features, just 'cause it seems like a good idea. And it ain't just you.... > Are XNS and Vines IP back-burner then too? > Have you seen an internet-draft for them? Are you writing one? Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu From ietf-ppp-request@ucdavis.ucdavis.edu Tue Apr 21 00:31:06 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15228; Tue, 21 Apr 92 00:21:22 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06143; Tue, 21 Apr 92 00:00:08 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13970; Mon, 20 Apr 92 23:45:36 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from regal.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13810; Mon, 20 Apr 92 23:42:40 -0700 Received: by regal.cisco.com; Mon, 20 Apr 92 23:41:41 -0700 Date: Mon, 20 Apr 92 23:41:40 PDT From: William "Chops" Westfield To: Brad Clements Cc: Kim Toms , Bob Sutterfield , ietf-ppp@ucdavis.ucdavis.edu Subject: Re: PPP and Compression (was [brad@Cayman.COM: Re: LCP options extensions ]) In-Reply-To: Your message of Mon, 20 Apr 92 20:15:43 EDT Message-Id: far more useful than compression itself would be a standard way for PPP to signal the modem to dispatch data (eg because of end-of-packet). In theory, all this requires is that modems recognize the PPP end-of-packet character - I thought that at least telebit had indicated that they would do this sort of thing back in the early days of PPP... Then link-level compression would stay a link level where it belonged! BillW From ietf-ppp-request@ucdavis.ucdavis.edu Tue Apr 21 03:00:49 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20070; Tue, 21 Apr 92 02:53:08 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06646; Tue, 21 Apr 92 02:30:05 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18887; Tue, 21 Apr 92 02:15:18 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from relay2.UU.NET by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18794; Tue, 21 Apr 92 02:13:43 -0700 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA20347; Tue, 21 Apr 92 05:13:21 -0400 Received: from neda.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 051204.13465; Tue, 21 Apr 1992 05:12:04 EDT Received: by rostam.NEDA.COM (4.1/smail2.5/04-11-92) id AA03374; Tue, 21 Apr 92 01:51:05 PDT Message-Id: <9204210851.AA03374@rostam.NEDA.COM> To: Dave Katz Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: Reliable Transport over Reliable Physical/Data Link In-Reply-To: Your message of "Mon, 20 Apr 92 20:08:04 PDT." <9204210308.AA17769@regal.cisco.com> Date: Tue, 21 Apr 92 01:51:02 -0700 From: Mohsen Banan >>>>> "Dave" == Dave Katz writes: Dave> As a sometimes member of the "ISO camp" (oh dear, there goes Dave> my credibility), I'll offer the observation that having five Dave> classes of transport is incredibly stupid, and that everybody Dave> should just run TP4 and be done with it. I agree with that completely, IF the scope of the discussion is limited to CLNS -- Connection Less Network Service. In that case, the only legitimate profile is TP4 anyways and the other classes are not an option. Dave> The problem with trying to make the transport layer "smart" Dave> about the media is that only the first hop is understood a Dave> priori, and the path out in the middle can change over time, Dave> so unless the adaptation is very dynamic (and/or very Dave> general), it's difficult to do very much of this sort of Dave> thing. However, if you are dealing with CONS, then there really is some value to having options in your choice of the transport protocol. In a connection oriented network, it may well be that more than the first hop is understood a priori. In fact the QOS over that network connection may well be quite static. Dave> About the only thing that's really done along this line is the Dave> signalling of the "congestion experienced" bit to the Dave> receiver's transport layer, which can then try to do something Dave> smart with window size adjustments and the like. The world is mostly going CLNS (hope there are not many Europeans on this mailing list), so again my observations are mostly academic and I am not disagreeing with Dave's comments. -- Mohsen Banan Tele-Voice tel: +1-206-644-8026 17005 S.E. 31st Place fax: +1-206-562-9591 Bellevue, Wa 98008 E-Mail: mohsen@neda.com U.S.A. uunet!neda!mohsen From ietf-ppp-request@aggie.ucdavis.edu Tue Apr 21 08:46:35 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00773; Tue, 21 Apr 92 08:39:34 -0700 Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA07861; Tue, 21 Apr 92 08:20:04 -0700 Sender: ietf-ppp-request@aggie.ucdavis.edu Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA07812; Tue, 21 Apr 92 08:13:04 -0700 From: ccskiz@aggie.ucdavis.edu (Elizabeth St. Goar) Date: Tue, 21 Apr 92 08:13:04 -0700 Message-Id: <9204211513.AA07812@aggie.ucdavis.edu> To: ietf-ppp@aggie.ucdavis.edu Subject: ---------------------- Forwarded Message Follows ---------------------- Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06235; Tue, 21 Apr 92 00:03:50 -0700 Received: from elroy.jpl.nasa.gov by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14004; Mon, 20 Apr 92 23:46:31 -0700 Received: from avatar.com by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA15804; Mon, 20 Apr 92 23:46:01 PDT In-Reply-To: brian@lloyd.com (Brian Lloyd) "old business" (Apr 20, 21:24) X-Mailer: Mail User's Shell (7.0.0 12/10/89) To: Brian Lloyd Subject: Re: old business Date: Mon, 20 Apr 92 21:35:17 PDT From: Kory Hamzeh Message-Id: <9204202135.aa00818@avatar.com> In "old business", Brian Lloyd says: > We currently have a MIB document pending comments. I will wait about > one more week before recommending it to the IESG for a last-call. > Please read the MIB document and make your comments here. Speak now > or forever hold your peace. > > 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 My only comment would be to see if we can take out anything that is not really required for a production (non-development) oriented PPP installation. Frank has done an excellent job with the MIB, but its massive. Is all of the objects really required? It seems are code spends a lot of time updating counters rather than moving packets. :-) No flames please, I just like to keep it simple. Thanks, Kory -- ------------------------------------------------------------------------------- Kory Hamzeh UUCP: avatar!kory or ..!uunet!avatar!kory INTERNET: kory@avatar.com From ietf-ppp-request@ucdavis.ucdavis.edu Tue Apr 21 09:33:48 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02289; Tue, 21 Apr 92 09:21:58 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08274; Tue, 21 Apr 92 09:02:35 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01050; Tue, 21 Apr 92 08:46:27 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00778; Tue, 21 Apr 92 08:39:54 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA05886; Tue, 21 Apr 92 08:38:59 PDT Date: Tue, 21 Apr 92 08:38:59 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9204211538.AA05886@saffron.acc.com> To: brian@lloyd.com Subject: Re: bring out yer dead... Cc: ietf-ppp@ucdavis.ucdavis.edu Brian: With all due respect, if the only marketplace for software compression is already handled by (asynchronous) modems, how come every customer I take a 56 KBPS synchronous product to expects that *of course* I will do it on synchronous links, *just like everybody else*? Fred From ietf-ppp-request@ucdavis.ucdavis.edu Tue Apr 21 10:38:05 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04738; Tue, 21 Apr 92 10:28:27 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08921; Tue, 21 Apr 92 10:01:07 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03324; Tue, 21 Apr 92 09:47:29 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from regal.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02966; Tue, 21 Apr 92 09:38:23 -0700 Received: by regal.cisco.com; Tue, 21 Apr 92 09:37:46 -0700 Date: Tue, 21 Apr 92 09:37:46 -0700 From: Dave Katz Message-Id: <9204211637.AA21933@regal.cisco.com> To: mohsen%rostam@uunet.UU.NET Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Mohsen Banan's message of Tue, 21 Apr 92 01:51:02 -0700 <9204210851.AA03374@rostam.NEDA.COM> Subject: Reliable Transport over Reliable Physical/Data Link Actually, I was referring to both CONS and CLNS. International X.25 calls are quite dubious in their quality, and all bets are off on the service level delivered by several concatenated VCs. (Having seen more than my share of X.25 Resets in my day, I'm a firm believer in putting error control end-to-end.) Plus, running TP4 over CONS alleviates part of the CO/CL interworking problem (but I'll stay out of that rathole). Europeans are running lots of CLNS these days. But enough of this, and back to the previously scheduled blather, which is already in progress. From ietf-ppp-request@ucdavis.ucdavis.edu Tue Apr 21 10:54:30 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05213; Tue, 21 Apr 92 10:40:37 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09136; Tue, 21 Apr 92 10:16:15 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04176; Tue, 21 Apr 92 10:11:50 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from wolf.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03651; Tue, 21 Apr 92 09:57:11 -0700 Received: from lager.cisco.com by wolf.cisco.com with TCP; Tue, 21 Apr 92 09:56:37 -0700 Message-Id: <9204211656.AA05108@wolf.cisco.com> To: fbaker@acc.com (Fred Baker) Cc: brian@lloyd.com, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: bring out yer dead... In-Reply-To: Your message of "Tue, 21 Apr 92 08:38:59 PDT." <9204211538.AA05886@saffron.acc.com> Date: Tue, 21 Apr 92 09:56:36 PDT From: Jim Forster >> With all due respect, if the only marketplace for software compression >> is already handled by (asynchronous) modems, how come every customer I >> take a 56 KBPS synchronous product to expects that *of course* I will >> do it on synchronous links, *just like everybody else*? I agree with Fred -- we're constantly getting besieged with requests to do compression over 56k lines, and there's no particular reason, other than lack of software, why this can't be done. -- Jim From ietf-ppp-request@ucdavis.ucdavis.edu Tue Apr 21 11:24:28 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06155; Tue, 21 Apr 92 11:09:53 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09273; Tue, 21 Apr 92 10:45:57 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05097; Tue, 21 Apr 92 10:36:40 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from europa.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04515; Tue, 21 Apr 92 10:20:40 -0700 Received: by europa.clearpoint.com (4.1/1.34) id AA00230; Tue, 21 Apr 92 13:13:29 EDT Date: Tue, 21 Apr 92 13:13:29 EDT From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9204211713.AA00230@europa.clearpoint.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: kory do you have the latest internet draft, dated 30 March 1992? the previous one was very big. this one is medium big. frank > From ietf-ppp-request@ucdavis.edu Tue Apr 21 11:31:20 1992 > Sender: ietf-ppp-request@ucdavis.edu > From: estgoar@ucdavis.edu (Elizabeth St. Goar) > To: ietf-ppp@ucdavis.edu > Subject: > > ---------------------- Forwarded Message Follows ---------------------- > Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) > id AA06235; Tue, 21 Apr 92 00:03:50 -0700 > Received: from elroy.jpl.nasa.gov by ucdavis.ucdavis.edu (5.61/UCD2.04) > id AA14004; Mon, 20 Apr 92 23:46:31 -0700 > Received: from avatar.com by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) > id AA15804; Mon, 20 Apr 92 23:46:01 PDT > In-Reply-To: brian@lloyd.com (Brian Lloyd) > "old business" (Apr 20, 21:24) > X-Mailer: Mail User's Shell (7.0.0 12/10/89) > To: Brian Lloyd > Subject: Re: old business > Date: Mon, 20 Apr 92 21:35:17 PDT > From: Kory Hamzeh > Message-Id: <9204202135.aa00818@avatar.com> > > > In "old business", Brian Lloyd says: > > We currently have a MIB document pending comments. I will wait about > > one more week before recommending it to the IESG for a last-call. > > Please read the MIB document and make your comments here. Speak now > > or forever hold your peace. > > > > 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 > > My only comment would be to see if we can take out anything that is not > really required for a production (non-development) oriented PPP installation. > Frank has done an excellent job with the MIB, but its massive. > > Is all of the objects really required? It seems are code spends a lot of > time updating counters rather than moving packets. :-) > > No flames please, I just like to keep it simple. > > Thanks, > Kory > > > -- > ------------------------------------------------------------------------------- > Kory Hamzeh UUCP: avatar!kory or ..!uunet!avatar!kory > INTERNET: kory@avatar.com > > From ietf-ppp-request@ucdavis.ucdavis.edu Tue Apr 21 12:38:34 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08421; Tue, 21 Apr 92 12:10:15 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09403; Tue, 21 Apr 92 11:07:49 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05645; Tue, 21 Apr 92 10:53:47 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from hobbit.gandalf.ca by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05207; Tue, 21 Apr 92 10:40:19 -0700 Received: by hobbit.gandalf.ca (4.1/SMI-4.1) id AA10314; Tue, 21 Apr 92 13:39:52 EDT Date: Tue, 21 Apr 92 13:39:52 EDT From: mm@hobbit.gandalf.ca (Mississippi Mud) Message-Id: <9204211739.AA10314@hobbit.gandalf.ca> To: ietf-ppp@ucdavis.ucdavis.edu Subject: In-Reply-To: bring out yer dead... In a private exchange with Brian Lloyd I brought up the topic, and on his advice refrained from carrying it to the mailing list. Not much later, and completely by coincidence, Venkat Prasad, another recent subscriber, took the same step, and you know the rest. Since Brian had opened the public discussion I felt justified in participating (and I also think he was right to do so). The company I work for has a particular interest in this matter, and in ppp as a routing/bridging technology. I was referring to the following, which I got out of the ppp archive not long after subscribing to the mailing list. > The most up-to-date values of the IPX Compression Protocol field are > specified in the most recent "Assigned Numbers" RFC [??]. Current > values are assigned as follows: > Value (in hex) Protocol > 0235 Shiva Compressed NCP I took this to imply that the number had been assigned by the IANA. I apologise to anyone who was insulted by my use of the word random. I feel that starting this discussion of the LCP was timely, but it is inconsistent with the subject having been closed years ago, and with the apparent direction taken by at least one vendor, perhaps more. Bill Simpson: >> Are XNS and Vines IP back-burner then too? >> >Have you seen an internet-draft for them? No, that's why I asked. >Are you writing one? Not at the moment. Are you? -Chris Sullivan (mm@gandalf.ca) "The process works because the IETF Working Groups display a spirit of cooperation as well as a high degree of technical maturity; most IETF members agree that the greatest benefit for all members of the Internet community results from cooperative development of technically superior protocols and services." - RFC1310 From ietf-ppp-request@ucdavis.ucdavis.edu Tue Apr 21 12:41:30 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08733; Tue, 21 Apr 92 12:17:29 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09664; Tue, 21 Apr 92 11:30:16 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06405; Tue, 21 Apr 92 11:15:38 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05494; Tue, 21 Apr 92 10:48:10 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA01952; Tue, 21 Apr 92 10:47:41 PDT Date: Tue, 21 Apr 92 10:47:41 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9204211747.AA01952@ray.lloyd.com> To: mohsen%rostam@uunet.UU.NET Cc: uunet!eng.xyplex.com!rlstewart@uunet.UU.NET, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Mohsen Banan's message of Mon, 20 Apr 92 18:11:20 -0700 <9204210111.AA02495@rostam.NEDA.COM> Subject: Reliable Transport over Reliable Physical/Data Link Sender: ietf-ppp-request@ucdavis.edu Date: Mon, 20 Apr 92 18:11:20 -0700 From: Mohsen Banan >>>>> "Bob" == Bob Stewart writes: Bob> For a long time I've wondered if we could do a better job of Bob> deciding how to run the lower levels if both the higher and Bob> lower levels could be a bit more specific about what they Bob> expect. Wouldn't it be nice if TCP had some numbers, at least Bob> ranges, of packet loss where it expects to run acceptably, and Bob> the Data Links said how many frames they expected to lose and Bob> with what latency and you could just calculate whether to turn Bob> on LAPB. Of course you'd have a problem of cumulative effect Bob> over many links, but at least we could be wrong based on some Bob> mathematics instead of speculation. I wonder if this is not a set up so that people on the ISO camp may take up the opportunity and point out that for the very same reason that you have mentioned, 5 classes in Transport Protocol have been defined to compensate for unreliable nature of the underlying network and only to the extent that is necessary. The idea is that eventually we end up with implementations that really use the QOS -- Quality of Service -- parameters. I am not a serious participant in this group. However, the set up was so nice that I just couldn't resist putting on the idealist hat on for a few moments. Back to reality now. -- Mohsen Banan Tele-Voice tel: +1-206-644-8026 17005 S.E. 31st Place fax: +1-206-562-9591 Bellevue, Wa 98008 E-Mail: mohsen@neda.com U.S.A. uunet!neda!mohsen "Acceptable performance" is not easily definable. I wouldn't really want to try to hack TCP to make decisions like that. Addressing the issue of TCP vs. TPx you must remember that there is no such thing as a reliable network. Unreliable datagram networks sometimes drop packets and "reliable" VC networks periodically generate resets (hi, I just dropped your connection but I have no idea what actually got delivered). Therefore only TCP and TP4 are sufficient as transport protocols. TP0 through TP3 are superfluous. Now as to the discussion of LAPB improving the apparent BER of the link, that is a local optimization for that particular link and has nothing at all to do with the transport service. You might want to enable LAPB in order to decrease the apparent BER to the point that you can use compression or you just might want to reduce the number of end-to-end retransmissions that must traverse the entire path. BTW, all of this discussion has implementation experience behind it. I recommend that you look at Phil Karn's KA9Q package, specifically at his implementation of AX.25. AX.25 is an adaptation of LAPB for radio links (they added addresses to LAPB in order to support the multi-drop broadcast nature of radio links). In Phil's implementation he usually encapsulates IP in UI frames (just like PPP) but he turns on full LAPB if the operator requests it or if the high-reliability bit is set in the IP TOS field. I suspect that it would be VERY straight forward to run LAPB under PPP. This is probably worth discussion -*AFTER*- we finish up the MIB. I suspect that it can go on in parallel with the Appletalk, CLNP, and IPX discussions. 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 Apr 21 12:42:03 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08961; Tue, 21 Apr 92 12:24:17 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09715; Tue, 21 Apr 92 11:37:16 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06501; Tue, 21 Apr 92 11:18:27 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05741; Tue, 21 Apr 92 10:57:48 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA05211; Tue, 21 Apr 92 13:57:16 -0400 Date: Tue, 21 Apr 92 10:42:29 EDT From: "William Allen Simpson" Message-Id: <283.bsimpson@vela.acs.oakland.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: old business > We currently have a MIB document pending comments. I will wait about > one more week before recommending it to the IESG for a last-call. Actually, I would like to hold the MIB a bit until the ISO, Appletalk, and IPX documents are done, so that they can be included. Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu From ietf-ppp-request@ucdavis.ucdavis.edu Tue Apr 21 13:37:42 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10522; Tue, 21 Apr 92 13:04:58 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09765; Tue, 21 Apr 92 11:45:31 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06655; Tue, 21 Apr 92 11:23:09 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06221; Tue, 21 Apr 92 11:11:36 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA01973; Tue, 21 Apr 92 11:11:09 PDT Date: Tue, 21 Apr 92 11:11:09 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9204211811.AA01973@ray.lloyd.com> To: billw@regal.cisco.com Cc: bkc@omnigate.clarkson.edu, kim@morningstar.com, bob@morningstar.com, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: William "Chops" Westfield's message of Mon, 20 Apr 92 23:41:40 PDT Subject: PPP and Compression (was [brad@Cayman.COM: Re: LCP options extensions ]) Sender: ietf-ppp-request@ucdavis.edu Date: Mon, 20 Apr 92 23:41:40 PDT From: William "Chops" Westfield far more useful than compression itself would be a standard way for PPP to signal the modem to dispatch data (eg because of end-of-packet). In theory, all this requires is that modems recognize the PPP end-of-packet character - I thought that at least telebit had indicated that they would do this sort of thing back in the early days of PPP... Then link-level compression would stay a link level where it belonged! BillW HA! While I was working at Telebit I -*TRIED*- to get such a feature added to the modems. Marketing was unconvinced of the need and engineering was unwilling to put forth any effort. If Telebit is unwilling, I imagine the rest of the mfgrs are likely to be even more so. 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 Apr 21 15:03:21 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14792; Tue, 21 Apr 92 14:51:07 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09909; Tue, 21 Apr 92 12:00:06 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07688; Tue, 21 Apr 92 11:49:45 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06580; Tue, 21 Apr 92 11:20:36 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA01986; Tue, 21 Apr 92 11:20:09 PDT Date: Tue, 21 Apr 92 11:20:09 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9204211820.AA01986@ray.lloyd.com> To: fbaker@acc.com Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Fred Baker's message of Tue, 21 Apr 92 08:38:59 PDT <9204211538.AA05886@saffron.acc.com> Subject: bring out yer dead... Date: Tue, 21 Apr 92 08:38:59 PDT From: fbaker@acc.com (Fred Baker) Brian: With all due respect, if the only marketplace for software compression is already handled by (asynchronous) modems, how come every customer I take a 56 KBPS synchronous product to expects that *of course* I will do it on synchronous links, *just like everybody else*? Fred If you want to do compression on your 56K link, you can purchase hardware compression devices that go between your DTE and your DCE. I believe that we need to deal with other problems first -- like the MIB. Let's come back to this later. 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 Apr 21 15:03:26 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14896; Tue, 21 Apr 92 14:54:16 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA10285; Tue, 21 Apr 92 12:15:29 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08064; Tue, 21 Apr 92 12:00:15 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07249; Tue, 21 Apr 92 11:37:39 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA02038; Tue, 21 Apr 92 11:37:13 PDT Date: Tue, 21 Apr 92 11:37:13 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9204211837.AA02038@ray.lloyd.com> To: forster@cisco.com Cc: fbaker@acc.com, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Jim Forster's message of Tue, 21 Apr 92 09:56:36 PDT <9204211656.AA05108@wolf.cisco.com> Subject: bring out yer dead... Date: Tue, 21 Apr 92 09:56:36 PDT From: Jim Forster >> With all due respect, if the only marketplace for software compression >> is already handled by (asynchronous) modems, how come every customer I >> take a 56 KBPS synchronous product to expects that *of course* I will >> do it on synchronous links, *just like everybody else*? I agree with Fred -- we're constantly getting besieged with requests to do compression over 56k lines, and there's no particular reason, other than lack of software, why this can't be done. -- Jim OK, ok. Jim, Fred, go off and work on a LAPB extension to PPP. After you get that then we can talk about compression. Be sure that you make it backward compatible to our current use of UI frames for PPP encapsulation. As an option it must be mutually exclusive with the LCP address/control field compression option. Gawd, I had hoped to avoid changing or extending the LCP document. PPP is going to become so big that it will start looking like an OSI protocol. Do we need a separate mailing list to deal with LAPB and compression in addition to ietf-ppp@ucdavis.edu? Not everybody is going to want to be involved in that discussion. Comments from the gallery? 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 Apr 21 15:03:36 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14900; Tue, 21 Apr 92 14:54:37 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA10615; Tue, 21 Apr 92 12:24:17 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08157; Tue, 21 Apr 92 12:02:21 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06808; Tue, 21 Apr 92 11:28:07 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA02016; Tue, 21 Apr 92 11:27:42 PDT Date: Tue, 21 Apr 92 11:27:42 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9204211827.AA02016@ray.lloyd.com> To: estgoar@ucdavis.ucdavis.edu Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Elizabeth St. Goar's message of Tue, 21 Apr 92 08:13:04 -0700 <9204211513.AA07812@aggie.ucdavis.edu> Subject: In-Reply-To: brian@lloyd.com (Brian Lloyd) "old business" (Apr 20, 21:24) To: Brian Lloyd Subject: Re: old business Date: Mon, 20 Apr 92 21:35:17 PDT From: Kory Hamzeh My only comment would be to see if we can take out anything that is not really required for a production (non-development) oriented PPP installation. Frank has done an excellent job with the MIB, but its massive. Is all of the objects really required? It seems are code spends a lot of time updating counters rather than moving packets. :-) No flames please, I just like to keep it simple. Thanks, Kory I agree. That is why I was hoping that people would look at the document and make comments so that we can make changes. Frank, Bill, and Glenn made significant progress at the IETF meeting. Frank made more changes later but noone has responded to his recent changes. OK everybody, time for a subliminal message: GO READ THE MIB DOCUMENT AND COMMENT ON IT HERE. LOOK FOR THINGS WE CAN LIVE WITHOUT. BE MERCILESS! I now return you to your regularly scheduled mail ramblings. 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 Apr 21 15:03:48 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14930; Tue, 21 Apr 92 14:55:53 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11502; Tue, 21 Apr 92 12:47:48 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09470; Tue, 21 Apr 92 12:36:04 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08197; Tue, 21 Apr 92 12:03:27 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA08856; Tue, 21 Apr 92 15:02:49 -0400 Date: Tue, 21 Apr 92 14:32:26 EDT From: "William Allen Simpson" Message-Id: <290.bsimpson@vela.acs.oakland.edu> To: lauck@tl.enet.dec.com Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: 16/32 bit CRC > From: lauck@tl.enet.dec.com > Date: Tue, 21 Apr 92 10:43:23 EDT > > I have drafted a letter and reviewed this with our intellectual property > manager and our patent attorney. They have suggested minor revisions > which I have made and am now awaiting their approval. Assuming I get this, > I will forward it to my vice-president for approval and signature. I > antcipate his approval. > > I will send you a copy of the letter electronically when it has been signed > and sent off. > > The patent is still pending, therefore it isn't possible to give you a > copy. The information in the Internet Draft is very similar to the disclosure > section of the patent application. > > Tony > I am confused. The internet-draft copy that I have mentions no patents and (as far as I can tell) has nothing patentable in it. Unless, unbenownst to the world, DEC has a patent on the polynomial for the 32-bit FCS. In which case, I don't understand why CCITT would adopt it. Besides, I understood that mathematical derivations aren't patentable. We rejected the draft because there were no easy-to-implement tables like the 16-bit FCS. Arthur Harvey never got back to us, and we later learned that he is no longer with DEC. I announced last summer that whoever provided me with a table driven 32-bit and 48-bit FCS algorithm would be made 1st author for the draft. We've had a couple of implementations, completely independent of DEC. We're ready to go, except that someone raised the patent issue at the San Diego IETF. I assumed that DEC had some patented 16/32/48 *hardware* implementation that was at issue. What *exactly* are we waiting for? Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu From ietf-ppp-request@ucdavis.ucdavis.edu Tue Apr 21 15:03:53 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14932; Tue, 21 Apr 92 14:55:55 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11706; Tue, 21 Apr 92 13:02:54 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10187; Tue, 21 Apr 92 12:54:49 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from europa.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09293; Tue, 21 Apr 92 12:31:11 -0700 Received: by europa.clearpoint.com (4.1/1.34) id AA00721; Tue, 21 Apr 92 15:23:46 EDT Date: Tue, 21 Apr 92 15:23:46 EDT From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9204211923.AA00721@europa.clearpoint.com> To: bsimpson@vela.acs.oakland.edu, ietf-ppp@ucdavis.ucdavis.edu Subject: MIBs In-Reply-To: Mail from '"William Allen Simpson" ' dated: Tue, 21 Apr 92 10:42:29 EDT bill, these documents represent protocols which i am not familiar with and do not feel that i can adequately understand the technology that is behind the "foo-over-ppp" protocol. i can provide the mib-writing ability but a volunteer who understands the underlying protocols is also needed (anyone interested?). also, the base ppp stuff, ip, and bridging, are on their way to being a real standard now and they, presumably, have a need to be managed. thus, getting the mib out for what is already a standard would be a "good thing." i would suggest that the base mib be put forward (assuming there are no problems with it) and additional mibs go forward when the various foo-over-ppp protocols are finalized. i will, however, leave OIDs in the mib as "place-holders" from which to hang the various additional mibs. frank > From ietf-ppp-request@ucdavis.edu Tue Apr 21 15:16:48 1992 > Sender: ietf-ppp-request@ucdavis.edu > From: "William Allen Simpson" > To: ietf-ppp@ucdavis.edu > Subject: old business > > > We currently have a MIB document pending comments. I will wait about > > one more week before recommending it to the IESG for a last-call. > > Actually, I would like to hold the MIB a bit until the ISO, Appletalk, > and IPX documents are done, so that they can be included. > > Bill_Simpson@um.cc.umich.edu > bsimpson@vela.acs.oakland.edu From ietf-ppp-request@ucdavis.ucdavis.edu Tue Apr 21 15:20:41 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15174; Tue, 21 Apr 92 15:01:29 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11814; Tue, 21 Apr 92 13:15:14 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10611; Tue, 21 Apr 92 13:07:44 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from inet-gw-2.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09890; Tue, 21 Apr 92 12:46:03 -0700 Received: by inet-gw-2.pa.dec.com; id AA28006; Tue, 21 Apr 92 12:45:21 -0700 Received: by us1rmc.mso.dec.com; id AA17363; Tue, 21 Apr 92 15:44:47 -0400 From: lauck@tl.enet.dec.com Message-Id: <9204211944.AA17363@us1rmc.mso.dec.com> Received: from tl.enet; by us1rmc.enet; Tue, 21 Apr 92 15:44:52 EDT Date: Tue, 21 Apr 92 15:44:52 EDT To: bsimpson@rigel.acs.oakland.edu Cc: lauck@tl.enet.dec.com, ietf-ppp@ucdavis.ucdavis.edu Apparently-To: ietf-ppp@ucdavis.edu, bsimpson@rigel.acs.oakland.edu Subject: Re: 16/32 bit CRC The patent filing is on the 48 bit CRC and its use for negotiating between 16 and 32 bit quantities. In this negotiation it is necessary to send a packet which will be received correctly by the other party, which may be using the different CRC size. The 48 bit polynomial and the techniques for initializing and terminating the calculation provide this capability. The patent filing covers both hardware and software implmentations of the technique, although the more likely implementation would be software, since the performance of CRC calculation during option negotiation hardly matters and no 48 bit CRC hardware already exists. The patent filing does not go into the actual techniques for calculating the 48 bit CRC via shift registers, code, etc. since these can be easily figured out from someone already familiar with the hardware or software calculation of 16 or 32 bit CRC's. Table lookup techniques have been well known for over 20 years and have appeared in the litterature on numerous occasions. Hardware techniques have been described in texbooks since at least the 1960's. In writing up patents, the idea is to describe only the new material, in this case the particular polynomials, system application, etc. It doesn't particularly matter to me who the author on the internet draft is, if you have a new draft, although I would like to review it for technical accuracy. Could you give me a file pointer? The last time I looked the only draft was Art Harvey's. There is no point in debating whether or not the idea is patentable. The release letter from Digital will close this issue as far as the IESG/IAB standards process is concerned. I'm not an attorney in any case. I know of no patent on the 32 bit CRC which has been used since the 1970's. It was originally developed under contract by the Rome Air Defense Center for the abortive Autonet II system for use in the ADCCP (HDLC) protocol. Subsequently, Digital/Intel/Xerox picket up this polynomial for use in Ethernet and other LAN groups (IEEE802 and ANSI FDDI) have adopted this polynomial. The technique whereby CRC's are initialized to all 1's and complemented on transmission was originally invented by Bob Donnen of IBM for use in SDLC, to detect picking up or dropping bits off the end of a packet. This was subsequently added to all of the above protocols. Coming up with a technique which would work for both 16 and 32 bit polynomials in a single message was the hardest part of our invention. The values required to do so are described in Art Harvey's internet draft, together with the equations which they must solve to meet the requirements. I hope to have the letter by week after next. I would suggest going ahead with the proposal with or without the letter, as it should be in hand by the time the IAB will act on it. (As an IAB member, I will look foolish if I don't make this happen!) Tony From ietf-ppp-request@ucdavis.ucdavis.edu Tue Apr 21 16:21:47 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17228; Tue, 21 Apr 92 15:58:49 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA13132; Tue, 21 Apr 92 15:30:26 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15860; Tue, 21 Apr 92 15:19:15 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from europa.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15370; Tue, 21 Apr 92 15:06:44 -0700 Received: by europa.clearpoint.com (4.1/1.34) id AA02318; Tue, 21 Apr 92 17:58:51 EDT Date: Tue, 21 Apr 92 17:58:51 EDT From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9204212158.AA02318@europa.clearpoint.com> To: brian@lloyd.com, forster@cisco.com Subject: Re: bring out yer dead... In-Reply-To: Mail from 'brian@lloyd.com (Brian Lloyd)' dated: Tue, 21 Apr 92 11:37:13 PDT Cc: fbaker@acc.com, ietf-ppp@ucdavis.ucdavis.edu brian this all is a part of the ppp. it belongs on the ppp mailing list. if people are uninterested they can delete the email -- just like i do when i see topics that do not interest me. frank > Message 31: > From ietf-ppp-request@ucdavis.edu Tue Apr 21 17:46:02 1992 > Sender: ietf-ppp-request@ucdavis.edu > From: brian@lloyd.com (Brian Lloyd) > To: forster@cisco.com > Cc: fbaker@acc.com, ietf-ppp@ucdavis.edu > Subject: bring out yer dead... > > Date: Tue, 21 Apr 92 09:56:36 PDT > From: Jim Forster > > >> With all due respect, if the only marketplace for software compression > >> is already handled by (asynchronous) modems, how come every customer I > >> take a 56 KBPS synchronous product to expects that *of course* I will > >> do it on synchronous links, *just like everybody else*? > > I agree with Fred -- we're constantly getting besieged with requests to > do compression over 56k lines, and there's no particular reason, other > than lack of software, why this can't be done. > > -- Jim > > OK, ok. Jim, Fred, go off and work on a LAPB extension to PPP. After > you get that then we can talk about compression. Be sure that you > make it backward compatible to our current use of UI frames for PPP > encapsulation. As an option it must be mutually exclusive with the > LCP address/control field compression option. Gawd, I had hoped to > avoid changing or extending the LCP document. PPP is going to become > so big that it will start looking like an OSI protocol. > > Do we need a separate mailing list to deal with LAPB and compression > in addition to ietf-ppp@ucdavis.edu? Not everybody is going to want > to be involved in that discussion. Comments from the gallery? > > > 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 Apr 21 16:31:24 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17683; Tue, 21 Apr 92 16:11:07 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA13176; Tue, 21 Apr 92 15:33:44 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15877; Tue, 21 Apr 92 15:19:59 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from europa.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15645; Tue, 21 Apr 92 15:13:34 -0700 Received: by europa.clearpoint.com (4.1/1.34) id AA02350; Tue, 21 Apr 92 18:06:26 EDT Date: Tue, 21 Apr 92 18:06:26 EDT From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9204212206.AA02350@europa.clearpoint.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: ppp mib implementation brian, et al this week i will be trying to implement the ppp mib, as it lives in its current internet draft form. the implementation will cover the sync and bridging stuff. i will not be able to do any of the security stuff or the ip encapsulation stuff. if there are any volunteers to try implementing those parts of the mib in order to make sure that it is implementable i would be most greatful. while this level of implementation is not required by the iesg and iab for advancing to proposed standard, it is a tradition in the snmp area to have some elementary implementation experience in order to show that the mib spec is readable and that the mib is more or less implementable. frank From ietf-ppp-request@ucdavis.ucdavis.edu Tue Apr 21 17:48:56 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20960; Tue, 21 Apr 92 17:36:52 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA14187; Tue, 21 Apr 92 17:00:12 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19137; Tue, 21 Apr 92 16:48:54 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18647; Tue, 21 Apr 92 16:36:16 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA02288; Tue, 21 Apr 92 16:35:43 PDT Date: Tue, 21 Apr 92 16:35:43 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9204212335.AA02288@ray.lloyd.com> To: bsimpson@vela.acs.oakland.edu Cc: lauck@tl.enet.dec.com, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: "William Allen Simpson"'s message of Tue, 21 Apr 92 14:32:26 EDT <290.bsimpson@vela.acs.oakland.edu> Subject: 16/32 bit CRC What *exactly* are we waiting for? DEC holds the patent on the *process* of combining 16bit and 32bit FCS into a 48bit FCS. They can patent the *process*. They have also made it clear that we may use this patented process freely without paying royalties BUT noone has yet seen paper signed by an official of DEC saying that this is so. It is this paper that we are waiting for. Now don't joggle Karl's elbow. I trust Karl to do a good job and squeeze the necessary paper out of the appropriate people at DEC. 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 Apr 21 17:49:02 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21058; Tue, 21 Apr 92 17:39:20 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA14221; Tue, 21 Apr 92 17:04:20 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19143; Tue, 21 Apr 92 16:49:04 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18722; Tue, 21 Apr 92 16:38:32 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA02292; Tue, 21 Apr 92 16:38:03 PDT Date: Tue, 21 Apr 92 16:38:03 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9204212338.AA02292@ray.lloyd.com> To: kasten@europa.clearpoint.com Cc: bsimpson@vela.acs.oakland.edu, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Frank Kastenholz's message of Tue, 21 Apr 92 15:23:46 EDT <9204211923.AA00721@europa.clearpoint.com> Subject: MIBs Sender: ietf-ppp-request@ucdavis.edu Date: Tue, 21 Apr 92 15:23:46 EDT From: kasten@europa.clearpoint.com (Frank Kastenholz) . . . also, the base ppp stuff, ip, and bridging, are on their way to being a real standard now and they, presumably, have a need to be managed. thus, getting the mib out for what is already a standard would be a "good thing." i would suggest that the base mib be put forward (assuming there are no problems with it) and additional mibs go forward when the various foo-over-ppp protocols are finalized. Yes. You are right Frank. Let's get the LCP, IPCP, LQM, and authentication MIB stuff done and published. 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 Apr 22 04:30:19 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15757; Wed, 22 Apr 92 04:19:15 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA14221; Tue, 21 Apr 92 17:04:20 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19143; Tue, 21 Apr 92 16:49:04 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18722; Tue, 21 Apr 92 16:38:32 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA02292; Tue, 21 Apr 92 16:38:03 PDT Date: Tue, 21 Apr 92 16:38:03 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9204212338.AA02292@ray.lloyd.com> To: kasten@europa.clearpoint.com Cc: bsimpson@vela.acs.oakland.edu, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Frank Kastenholz's message of Tue, 21 Apr 92 15:23:46 EDT <9204211923.AA00721@europa.clearpoint.com> Subject: MIBs Sender: ietf-ppp-request@ucdavis.edu Date: Tue, 21 Apr 92 15:23:46 EDT From: kasten@europa.clearpoint.com (Frank Kastenholz) . . . also, the base ppp stuff, ip, and bridging, are on their way to being a real standard now and they, presumably, have a need to be managed. thus, getting the mib out for what is already a standard would be a "good thing." i would suggest that the base mib be put forward (assuming there are no problems with it) and additional mibs go forward when the various foo-over-ppp protocols are finalized. Yes. You are right Frank. Let's get the LCP, IPCP, LQM, and authentication MIB stuff done and published. 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 Apr 22 07:54:39 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24135; Wed, 22 Apr 92 07:34:35 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17618; Wed, 22 Apr 92 06:45:33 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21900; Wed, 22 Apr 92 06:30:46 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from XAP.XYPLEX.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21625; Wed, 22 Apr 92 06:26:09 -0700 Received: by xap.xyplex.com id ; Wed, 22 Apr 92 11:25:09 -0500 Date: Wed, 22 Apr 92 11:25:09 -0500 Message-Id: <9204221625.AA15330@xap.xyplex.com> From: Bob Stewart To: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Frank Kastenholz's message of Tue, 21 Apr 92 15:23:46 EDT <9204211923.AA00721@europa.clearpoint.com> Subject: Re: MIBs Given that PPP is extensible in separate documents, it seems to me that it's MIB should be extensible likewise, in separate documents. The current document could shrink by anything that's specific to the PPP clients, have appropriate objects to find your way to the right PPP extension, and specify the expected form of an extension. Then the base PPP MIB could be settled and foo MIBs finished along with their foo over documents. How's that for a way to "remove" some objects? Bob From ietf-ppp-request@ucdavis.ucdavis.edu Wed Apr 22 08:32:55 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25689; Wed, 22 Apr 92 08:16:54 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17939; Wed, 22 Apr 92 07:30:14 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23377; Wed, 22 Apr 92 07:15:17 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from babyoil.ftp.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22915; Wed, 22 Apr 92 07:01:49 -0700 Received: from gordon.merde.ftp.com by ftp.com via PCMAIL with DMSP id AA14161; Wed, 22 Apr 92 10:03:22 -0400 Date: Wed, 22 Apr 92 10:03:22 -0400 Message-Id: <9204221403.AA14161@ftp.com> To: brian@lloyd.com Subject: Re: bring out yer dead... From: gordon@ftp.com (Gordon Lee) Cc: ietf-ppp@ucdavis.ucdavis.edu Repository: babyoil.ftp.com Originating-Client: merde.ftp.com > From: brian@lloyd.com (Brian Lloyd) > > Do we need a separate mailing list to deal with LAPB and compression > in addition to ietf-ppp@ucdavis.edu? Not everybody is going to want > to be involved in that discussion. Comments from the gallery? I plan on listening in on the discussion. It is easier for me to hear about it on ietf-ppp. - GL == Gordon Lee == voice: (617) 246-0900 == fax: (617) 245-7943 == FTP Software Inc. == 26 Princess St == Wakefield, MA 01880-3004 From ietf-ppp-request@aggie.ucdavis.edu Wed Apr 22 09:40:43 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28360; Wed, 22 Apr 92 09:20:01 -0700 Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA18660; Wed, 22 Apr 92 08:46:39 -0700 Sender: ietf-ppp-request@aggie.ucdavis.edu Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA18625; Wed, 22 Apr 92 08:43:15 -0700 From: ccskiz@aggie.ucdavis.edu (Elizabeth St. Goar) Date: Wed, 22 Apr 92 08:43:15 -0700 Message-Id: <9204221543.AA18625@aggie.ucdavis.edu> To: ietf-ppp@aggie.ucdavis.edu Subject: ---------------------- Forwarded Message Follows ---------------------- Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA15666; Tue, 21 Apr 92 21:17:15 -0700 Received: from elroy.jpl.nasa.gov by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29453; Tue, 21 Apr 92 21:14:57 -0700 Received: from avatar.com by elroy.Jpl.Nasa.Gov (4.1/SMI-4.1+DXR) id AA06369; Tue, 21 Apr 92 21:14:25 PDT In-Reply-To: kasten@europa.clearpoint.com (Frank Kastenholz) "ppp mib implementation" (Apr 21, 18:22) X-Mailer: Mail User's Shell (7.0.0 12/10/89) To: Frank Kastenholz Subject: Re: ppp mib implementation Date: Tue, 21 Apr 92 18:31:05 PDT From: Kory Hamzeh Message-Id: <9204211831.aa00459@avatar.com> In "ppp mib implementation", Frank Kastenholz says: > brian, et al > > this week i will be trying to implement the ppp mib, as it lives > in its current internet draft form. the implementation will cover > the sync and bridging stuff. i will not be able to do any of the > security stuff or the ip encapsulation stuff. if there are any > volunteers to try implementing those parts of the mib in > order to make sure that it is implementable i would be most > greatful. > > while this level of implementation is not required by the iesg > and iab for advancing to proposed standard, it is a tradition > in the snmp area to have some elementary implementation > experience in order to show that the mib spec is readable and > that the mib is more or less implementable. > > frank > We will be implementing the a lot of the MIB (ip, security, bridging, and sync). If you would like, I will let you know how it goes. My problem is that it currently is not a very high priority, so I'm not sure if I can get back to you in time. What kind of a deadline are we looking at? Thanks, Kory -- ------------------------------------------------------------------------------- Kory Hamzeh UUCP: avatar!kory or ..!uunet!avatar!kory INTERNET: kory@avatar.com From ietf-ppp-request@ucdavis.ucdavis.edu Wed Apr 22 11:50:37 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03140; Wed, 22 Apr 92 11:24:33 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA19846; Wed, 22 Apr 92 10:46:30 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01286; Wed, 22 Apr 92 10:33:14 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from europa.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00944; Wed, 22 Apr 92 10:26:15 -0700 Received: by europa.clearpoint.com (4.1/1.34) id AA04127; Wed, 22 Apr 92 13:19:05 EDT Date: Wed, 22 Apr 92 13:19:05 EDT From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9204221719.AA04127@europa.clearpoint.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: mib implementation In-Reply-To: Mail from 'estgoar@ucdavis.edu (Elizabeth St. Goar)' dated: Wed, 22 Apr 92 08:43:15 -0700 kory, i was kind of hoping to get a feel for the implementability of the mib before we submitted it to the iesg, etc. if i remember right, brian indicated that he wanted to close out the mib sometime this week. this means this week or next for some basic level of implementation. if you can not do this then do not worry about it -- i will get some amount of our implementation done... thanks frank > From: Kory Hamzeh > Message-Id: <9204211831.aa00459@avatar.com> > > > In "ppp mib implementation", Frank Kastenholz says: > > brian, et al > > > > this week i will be trying to implement the ppp mib, as it lives > > in its current internet draft form. the implementation will cover > > the sync and bridging stuff. i will not be able to do any of the > > security stuff or the ip encapsulation stuff. if there are any > > volunteers to try implementing those parts of the mib in > > order to make sure that it is implementable i would be most > > greatful. > > > > while this level of implementation is not required by the iesg > > and iab for advancing to proposed standard, it is a tradition > > in the snmp area to have some elementary implementation > > experience in order to show that the mib spec is readable and > > that the mib is more or less implementable. > > > > frank > > > > We will be implementing the a lot of the MIB (ip, security, bridging, and > sync). If you would like, I will let you know how it goes. My problem > is that it currently is not a very high priority, so I'm not sure if I > can get back to you in time. What kind of a deadline are we looking > at? > > Thanks, > Kory > > > > -- > ------------------------------------------------------------------------------- > Kory Hamzeh UUCP: avatar!kory or ..!uunet!avatar!kory > INTERNET: kory@avatar.com > From ietf-ppp-request@ucdavis.ucdavis.edu Wed Apr 22 12:19:15 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04868; Wed, 22 Apr 92 12:05:46 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA20462; Wed, 22 Apr 92 11:31:23 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02986; Wed, 22 Apr 92 11:20:09 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02778; Wed, 22 Apr 92 11:14:24 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA13266; Wed, 22 Apr 92 14:13:49 -0400 Date: Wed, 22 Apr 92 13:01:12 EDT From: "William Allen Simpson" Message-Id: <294.bsimpson@vela.acs.oakland.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: MIBs > From: kasten@europa.clearpoint.com (Frank Kastenholz) > > i will, however, leave OIDs in the mib as "place-holders" from > which to hang the various additional mibs. > An excellent idea. So we might end up with a series of MIB documents, with different sets of protocols in them. Has this been done in the past for other protocols? I have kept quiet waiting for other comments, since I already had an opportunity to comment at San Diego. I think the draft is excellent, and meets every need I can conceive of today. I appreciate all the trouble you made in identifying changes to previous drafts, and the clearer presentation how everything fits together. There are a few typos (Brodge), but in the main, it's ready to go. Could you add the place-holders, and publish again as an internet-draft? Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu From ietf-ppp-request@ucdavis.ucdavis.edu Wed Apr 22 12:19:31 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05137; Wed, 22 Apr 92 12:13:12 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA20665; Wed, 22 Apr 92 11:37:58 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02997; Wed, 22 Apr 92 11:20:15 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02784; Wed, 22 Apr 92 11:14:31 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA13272; Wed, 22 Apr 92 14:13:59 -0400 Date: Wed, 22 Apr 92 13:11:16 EDT From: "William Allen Simpson" Message-Id: <295.bsimpson@vela.acs.oakland.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: MIBs > From: Bob Stewart > the expected form of an extension. Then the base PPP MIB could be settled and > foo MIBs finished along with their foo over documents. > I suggested this at the IETF, but was told that this was not historical practice. I advocated the main PPP MIB should stay in its own document, with IPCP et alia included as an appendix to their separate documents. Should we do this now, or only for future documents? Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu From ietf-ppp-request@ucdavis.ucdavis.edu Wed Apr 22 12:34:04 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05655; Wed, 22 Apr 92 12:29:54 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA20717; Wed, 22 Apr 92 11:42:02 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03002; Wed, 22 Apr 92 11:20:23 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02797; Wed, 22 Apr 92 11:14:49 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA13288; Wed, 22 Apr 92 14:14:17 -0400 Date: Wed, 22 Apr 92 13:22:28 EDT From: "William Allen Simpson" Message-Id: <297.bsimpson@vela.acs.oakland.edu> To: lauck@tl.enet.dec.com Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: 16/32 bit CRC > I hope to have the letter by week after next. I would suggest going ahead > with the proposal with or without the letter, as it should be in hand by > the time the IAB will act on it. (As an IAB member, I will look foolish > if I don't make this happen!) > Good. Thank you for the overview. This is much more history than I knew. I have cobbled together a FCS extensions draft, and was told to wait for the letter before posting. I'd do it now, except that I'm about to leave on vacation and haven't the time. But I will post to the group late next week for sure. Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu From ietf-ppp-request@ucdavis.ucdavis.edu Wed Apr 22 13:03:12 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06233; Wed, 22 Apr 92 12:45:38 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA20915; Wed, 22 Apr 92 12:00:12 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04215; Wed, 22 Apr 92 11:47:25 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02809; Wed, 22 Apr 92 11:15:05 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA13296; Wed, 22 Apr 92 14:14:26 -0400 Date: Wed, 22 Apr 92 13:39:47 EDT From: "William Allen Simpson" Message-Id: <298.bsimpson@vela.acs.oakland.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: bring out yer dead... > From: Jim Forster > > >> With all due respect, if the only marketplace for software compression > >> is already handled by (asynchronous) modems, how come every customer I > >> take a 56 KBPS synchronous product to expects that *of course* I will > >> do it on synchronous links, *just like everybody else*? > > I agree with Fred -- we're constantly getting besieged with requests to > do compression over 56k lines, and there's no particular reason, other > than lack of software, why this can't be done. > Yes, Fred isn't known to bring up frivolous issues. First, let's make a list of all the vendors doing compression on sync links to determine if this is a PPP issue, or a hardware issue, or a marketing issue. Please send the known vendors to me privately, and I will summarize for the list on May 1. Second, there is already text in the LCP document regarding co-existence of LAPB with PPP, you just can't see it. It was commented out before my time. I will send the text to the list in a separate message at a later date (after May 1). Third, if we could come up with some rules for coexisting PPP with LAPB *and* LAPD, the IPLPDN folks would probably be ecstatic. Fourth, the Cayman & MorningStar proposal sounds good, too. They should get together and write a draft. Finally, put it in the back of your minds while we get some more immediate issues settled, like: MIB, ISO, AppleTalk, IPX Those documents are already written, let's get some comments, NOW! Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu From ietf-ppp-request@ucdavis.ucdavis.edu Wed Apr 22 14:49:45 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09733; Wed, 22 Apr 92 14:30:07 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA22322; Wed, 22 Apr 92 14:00:50 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08343; Wed, 22 Apr 92 13:47:37 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from regal.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07795; Wed, 22 Apr 92 13:31:01 -0700 Received: by regal.cisco.com; Wed, 22 Apr 92 13:30:35 -0700 Date: Wed, 22 Apr 92 13:30:35 -0700 From: Dave Katz Message-Id: <9204222030.AA25143@regal.cisco.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: OSI, padding, etc. After discussing the issue with Ross, we came to the following compromise with regard to the padding issue: One (or more; it should work recursively) octets of zero may be prepended to the OSI network layer packet by the transmitter. All implementations must strip leading zero octets on receipt until the first non-zero octet is found (which should be the NLPID). In order to make the process deterministic, the use of the Inactive Network Layer Subset of ISO 8473 is specifically disallowed over PPP (If anybody *really* wants to use it, there are a number of approaches possible, none of which we will elaborate upon, since we would just as soon kill it). If Bill Simpson sends me the current nroff text, I'll be happy to hack in appropriate wording for the above. --Dave From ietf-ppp-request@ucdavis.ucdavis.edu Wed Apr 22 17:04:30 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14759; Wed, 22 Apr 92 16:57:28 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA23712; Wed, 22 Apr 92 16:30:39 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13555; Wed, 22 Apr 92 16:20:34 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from europa.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13105; Wed, 22 Apr 92 16:08:09 -0700 Received: by europa.clearpoint.com (4.1/1.34) id AA04448; Wed, 22 Apr 92 19:00:53 EDT Date: Wed, 22 Apr 92 19:00:53 EDT From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9204222300.AA04448@europa.clearpoint.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: mib text question hi the description text for the pppLinkPacketTooLongs object in the mib says that it is the count of packets DISCARDED because their length exceeded the MRU. however, one may choose to be liberal upon receipt and properly receive a packet, even if it is longer than the MRU. in fact, i seem to recall some discussion of this on the list in the past. should i change the text to say packets received that were longer than the MRU, regardless of whether they were discarded or properly received, or should the count be strictly limited to discarded packets? from a network management and snmp framework point of view, i would suggest keeping the text limited to discarded packets, since packets being discarded means that some communication is not happening -- a real problem. if we count all "too long" packets then we are counting both "error" and "non-error" conditions and the counter would seem to be less useful. frank From ietf-ppp-request@ucdavis.ucdavis.edu Wed Apr 22 17:17:01 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15124; Wed, 22 Apr 92 17:06:41 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA23879; Wed, 22 Apr 92 16:46:06 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14170; Wed, 22 Apr 92 16:37:38 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from UTKVX3.UTK.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13410; Wed, 22 Apr 92 16:15:47 -0700 Received: from utkvx.utk.edu by utkvx.utk.edu (PMDF #12093) id <01GJ5Q2X5RHC9JDX7W@utkvx.utk.edu>; Wed, 22 Apr 1992 19:07 EST Date: Wed, 22 Apr 1992 19:07 EST From: CASE@utkvx.utk.edu Subject: Re: old business To: brian@lloyd.com Cc: ietf-ppp@ucdavis.ucdavis.edu Message-Id: <01GJ5Q2X5RHC9JDX7W@utkvx.utk.edu> X-Envelope-To: ietf-ppp@ucdavis.edu X-Vms-To: IN%"brian@lloyd.com" X-Vms-Cc: IN%"ietf-ppp@ucdavis.edu",CASE >We currently have a MIB document pending comments. I will wait about >one more week before recommending it to the IESG for a last-call. >Please read the MIB document and make your comments here. Speak now >or forever hold your peace. gee, that seems kinda fast, doesn't it? has the implementation experience gone that well? are we SURE we know what we are doing, or is this viewgraph engineering? jdc From ietf-ppp-request@ucdavis.ucdavis.edu Wed Apr 22 18:17:27 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17265; Wed, 22 Apr 92 18:11:33 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA24326; Wed, 22 Apr 92 17:45:59 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16045; Wed, 22 Apr 92 17:35:02 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15754; Wed, 22 Apr 92 17:26:52 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA19138; Wed, 22 Apr 92 17:25:59 PDT Date: Wed, 22 Apr 92 17:25:59 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9204230025.AA19138@saffron.acc.com> To: kasten@europa.clearpoint.com Subject: Re: mib text question Cc: ietf-ppp@ucdavis.ucdavis.edu Frank: My inclination would be to include pppLinkPacketTooLongs in ifInErrors if it is discarded, and not worry about it if it's not. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Wed Apr 22 20:31:44 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22051; Wed, 22 Apr 92 20:26:39 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA25129; Wed, 22 Apr 92 19:50:48 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20332; Wed, 22 Apr 92 19:33:27 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20022; Wed, 22 Apr 92 19:26:35 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA02881; Wed, 22 Apr 92 19:26:05 PDT Date: Wed, 22 Apr 92 19:26:05 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9204230226.AA02881@ray.lloyd.com> To: kasten@europa.clearpoint.com Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Frank Kastenholz's message of Wed, 22 Apr 92 19:00:53 EDT <9204222300.AA04448@europa.clearpoint.com> Subject: mib text question You have two situations here: you have a packet that is longer than the MRU but that was received and processed correctly (presumably because your receive code is liberal). You also have packets that are tossed because they were too long to process. The former is likely an implementation error on the part of the sender and the latter is a communication problem. I would want a counter for packets that were "too long" and one for "packets discarded." 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 Apr 23 06:47:38 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14931; Thu, 23 Apr 92 06:39:06 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27661; Thu, 23 Apr 92 06:15:09 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13589; Thu, 23 Apr 92 06:01:05 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from europa.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13466; Thu, 23 Apr 92 05:59:32 -0700 Received: by europa.clearpoint.com (4.1/1.34) id AA04777; Thu, 23 Apr 92 08:51:25 EDT Date: Thu, 23 Apr 92 08:51:25 EDT From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9204231251.AA04777@europa.clearpoint.com> To: CASE@utkvx.utk.edu, brian@lloyd.com Subject: mib implementation In-Reply-To: Mail from 'CASE@utkvx.utk.edu' dated: Wed, 22 Apr 1992 19:07 EST Cc: ietf-ppp@ucdavis.ucdavis.edu Jeff, to date there has been no implementation experience known to me. i have begun implementing the mib on our system and, in fact, have found one or two problems (e.g. the question that i asked with respect to the "too-long" counter). however, i can only A) do the portions of the mib that apply to the synchronous communications. i can not, for instance, do the acc map. and B) the bridging encapsulation. we do not yet support ip over ppp. i also can not do the security related stuff and i am somewhat concerned as to whether i have covered all of the bases with it. thus, i will repeat the call: volunteers are needed to implement the mib and make reports on the implementability of it. this is not a formal requirement of the iab/iesg to go to proposed standard, however, the snmp network management directorate, who will review the mib and who's approval is usually sought by the iesg, really really really really really like to see working implementations. these implementations do not need to be "final released products." i would also point out that implementation experience is required by the iab/iesg to proceed from proposed standard to draft. frank > Message 35: > From ietf-ppp-request@ucdavis.edu Wed Apr 22 19:59:34 1992 > Sender: ietf-ppp-request@ucdavis.edu > From: CASE@utkvx.utk.edu > Subject: Re: old business > To: brian@lloyd.com > Cc: ietf-ppp@ucdavis.edu > X-Envelope-To: ietf-ppp@ucdavis.edu > X-Vms-To: IN%"brian@lloyd.com" > X-Vms-Cc: IN%"ietf-ppp@ucdavis.edu",CASE > > > >We currently have a MIB document pending comments. I will wait about > >one more week before recommending it to the IESG for a last-call. > >Please read the MIB document and make your comments here. Speak now > >or forever hold your peace. > > gee, that seems kinda fast, doesn't it? > has the implementation experience gone that well? > are we SURE we know what we are doing, or is this viewgraph engineering? > > > jdc From ietf-ppp-request@ucdavis.ucdavis.edu Thu Apr 23 07:02:39 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15356; Thu, 23 Apr 92 06:54:13 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27768; Thu, 23 Apr 92 06:30:30 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14283; Thu, 23 Apr 92 06:21:49 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.73.212.9] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13902; Thu, 23 Apr 92 06:12:31 -0700 Received: by wnyosi9.nctsw.navy.mil (5.59/25-eef) id AA17870; Thu, 23 Apr 92 08:55:24 EDT Date: Thu, 23 Apr 92 08:55:24 EDT From: rjacob@wnyosi9.nctsw.navy.mil Message-Id: <9204231255.AA17870@wnyosi9.nctsw.navy.mil> To: callon@bigfut.enet.dec.com, root@wnyosi9.nctsw.navy.mil Subject: Re: more regarding OSI over PPP (note from Brian and my response). Cc: brian@lloyd.com, dhg@NSD.3Com.COM, ietf-ppp@ucdavis.ucdavis.edu, rjacob@wnyosi9.nctsw.navy.mil From rjacob Wed Apr 22 17:01 EDT 1992 Subject: RE: 3COM,Novell,Cisco SUPPORTS CLNS over PPP Cc: cmj@NSD.3Com.COM, dhg@NSD.3Com.COM Status: RO I apologize for my ignorance of PPP and OSI in advance, and since the domain name server in my network can't seem to reach the outside world I have no choice but to use the mail list . I called a local 3com representative and explained that I wanted 1. A 3Com router to dial a number based on the NSAP of the end system I am trying to reach. 2. Make a connection and establish a PPP link to another 3Com router acting as an IS. 3. Forward my packets on to an end system on that network. They said that I could establish a connection manually dialling the number with one modem and answering the phone and hanging up the phone, and that I might be able to program the modems to dialout when dtr is raised and autoanswer when a call comes in. The problem with this solution is that I may to contact anywhere from 10-30 different locations that don't have access to a wide area network to exchange x.400 mail. I won't even mention ftam. I am not sure what the underlying assumptions about the environment ppp will work in are? Not everyone needs a connection to leased lines or a PDN. Is anyone in the OSI-PPP side of the mailing list addressing this question of on demand establishing of links and some kind of routing(dialing of a number) and probably a long time out so the line won't be dropped prematurely(time out). PS: I know that there is probably nothing in the standard that precludes the above scenario. I just want to know : to know is anyone working on providing a commercial off the shelf(COTS) product that does this? I don't want OSI over TCP/IP and then a Telebit or Netblazer PPP solution I believe they have the ability to dial and establish a connection I am not sure if they route(i.e. match an ip network or host address with a number of another router and establish a connection). PS: I have no money for development costs that is why I want a COTS product. thank you for your patience raymond jacob nctsw code n531 bldg. 196-2 wny,wash.dc 20374 From ietf-ppp-request@ucdavis.ucdavis.edu Thu Apr 23 08:34:15 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18816; Thu, 23 Apr 92 08:26:36 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA28578; Thu, 23 Apr 92 08:00:11 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17542; Thu, 23 Apr 92 07:48:00 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from tymix.Tymnet.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17129; Thu, 23 Apr 92 07:34:38 -0700 Received: from spiff.Tymnet.COM by tymix.Tymnet.COM (4.1/SMI-4.1) id AA28027; Thu, 23 Apr 92 07:33:51 PDT Received: from sagehen.Tymnet.COM by spiff.Tymnet.COM (4.1/SMI-4.1) id AA19537; Thu, 23 Apr 92 07:33:49 PDT Date: Thu, 23 Apr 92 07:33:49 PDT From: drawson@Tymnet.COM (Dick Rawson) Message-Id: <9204231433.AA19537@spiff.Tymnet.COM> To: kasten@europa.clearpoint.com Subject: Re: mib text question Cc: ietf-ppp@ucdavis.ucdavis.edu Re: Whether pppLinkPacketTooLongs should count "too long" packets that the receiver liberally accepted. I suggest counting "too long" packets whether or not they are dropped. They are errors in either case; reporting them helps the network operator discover and fix configuration errors. Of course, you reasonably say that a "too long" packet that is accepted as valid is a less serious error than one that is dropped. Maybe the mib should have separate counters for (a) packets dropped after passing the FCS check, and (b) packets violating a protocol or configuration check. Dick From ietf-ppp-request@ucdavis.ucdavis.edu Thu Apr 23 11:34:35 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25551; Thu, 23 Apr 92 11:21:38 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA00354; Thu, 23 Apr 92 10:15:36 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22684; Thu, 23 Apr 92 10:04:30 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22174; Thu, 23 Apr 92 09:51:43 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA03194; Thu, 23 Apr 92 09:49:51 PDT Date: Thu, 23 Apr 92 09:49:51 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9204231649.AA03194@ray.lloyd.com> To: rjacob@wnyosi9.nctsw.navy.mil Cc: callon@bigfut.enet.dec.com, root@wnyosi9.nctsw.navy.mil, dhg@NSD.3Com.COM, ietf-ppp@ucdavis.ucdavis.edu, rjacob@wnyosi9.nctsw.navy.mil In-Reply-To: rjacob@wnyosi9.nctsw.navy.mil's message of Thu, 23 Apr 92 08:55:24 EDT <9204231255.AA17870@wnyosi9.nctsw.navy.mil> Subject: more regarding OSI over PPP (note from Brian and my response). Sender: ietf-ppp-request@ucdavis.edu Date: Thu, 23 Apr 92 08:55:24 EDT From: rjacob@wnyosi9.nctsw.navy.mil 1. A 3Com router to dial a number based on the NSAP of the end system I am trying to reach. 2. Make a connection and establish a PPP link to another 3Com router acting as an IS. 3. Forward my packets on to an end system on that network. . . . PS: I have no money for development costs that is why I want a COTS product. What you seek, does not, as far as I know, exist for the OSI world. There are several sources for such devices in the IP/TCP world. I recommend that you contact Livingston (1-800-458-9966), Morningstar Technologies (1-800-558-7827), and Telebit (1-800-TELEBIT). These companies all have COTS products that will do what you ask IF you can accept an IP/TCP solution. Since IP/TCP is considered part of an acceptable GOSIP solution you should be covered in that area. 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 Apr 23 11:48:26 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26283; Thu, 23 Apr 92 11:37:24 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01016; Thu, 23 Apr 92 11:04:33 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24497; Thu, 23 Apr 92 10:56:58 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from mts-gw.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23879; Thu, 23 Apr 92 10:38:00 -0700 Received: by mts-gw.pa.dec.com; id AA16413; Thu, 23 Apr 92 10:36:16 -0700 Message-Id: <9204231736.AA16413@mts-gw.pa.dec.com> Received: from eider.enet; by decpa.enet; Thu, 23 Apr 92 10:36:16 PDT Date: Thu, 23 Apr 92 10:36:16 PDT From: Jesse Walker To: ietf-ppp@ucdavis.ucdavis.edu Apparently-To: ietf-ppp@ucdavis.edu Subject: More PPP MIB Comments Well, prodded by all the e-mail about it over the last few days, this morning I finally found time to review the new draft of the MIB. Everyone who worked on it deserve kudos and our utmost appreciation, as it demonstrates a lot of hard work and discriminating thought. It's really coming along nicely. With that said, it's time to rejoin the fray. > 5.3. Structure of the PPP MIB > > The multiplicity of protocols internal to the PPP, along with > the need for the PPP to be layered above some physical > interface (such as a synchronous line) poses an interesting > problem to the MIB developer: How should the MIB be structured > in order to reflect the richness of PPP implementations. > > In order to properly represent the layering and dependencies > of all of the components of a PPP entity, a multi-layered > interface model is adopted. In this model, each of the PPP > Network Protocols and Network Control protocols of the PPP > "interface" will be represented as a separate interface as > defined in MIB-II[2]. Thus, each component of the PPP > "interface" will have its own entry in the MIB-II interface > table (ifTable) and the interface extensions table > (ifExtnsTable). > > For the purposes of network management, a PPP Link Layer is > also defined. This layer contains the Link Control Protocol, > as well as the ancilliary control protocols (for > authentication and link quality monitoring). This layer is an > "interface", as defined in the previous paragraph, and > therefore has its own entry in the ifTable and the > ifExtnsTable. The Link Layer is logically placed beneath the > Network and Network Control protocols. This placement is > necessary in order to provide the proper MIB hooks for showing > the relationship between the several Network and Network > Control protocols, and the lower layer MIBs (e.g., LAP-B). > > The MIB objects defined in this document reside in the media- > specific portion of the mib (i.e. in the transmission sub-tree > of MIB-2). > > The relationship between the PPP MIB objects of a particular > sub-layer and the interface table entry for that same sub- > layer is established by two MIB objects: 1) the ifSpecific > object in the interface table entry, which identifies the > appropriate subtree in the PPP MIB and 2) the ifIndex object > in the interface table entry, which identifies which instance > of a PPP MIB table pertains to the interface table entry. > > Thus, a PPP implementation's MIBs might have the following > rough structure: > +------------+---------+ +--------------+---------+ > | PPP-IP MIB | ifEntry | | PPP-IPCP MIB | ifEntry | > +------------+---------+ +--------------+---------+ > +--------------+---------+ > | PPP Link MIB | ifEntry | > +--------------+---------+ > +------------+---------+ > | LAP-B MIB | ifEntry | > +------------+---------+ > +------------+---------+ > | RS-232 MIB | ifEntry | > +------------+---------+ This is wonderfully elegant and intellectually pleasing; I find it exactly what I'd really like to do with SNMP in a host of areas. With all due respect, however, I objected to this organization before, and was promised a discussion explaining why it was absolutely and positively required. I agreed to withhold further objections to it until seeing this explanation. To date no has explained the rationale for this model, at least on this mail list, so I still concerned about its technical merit. Can someone please alleviate my concerns? Let me reiterate them: a. It does not scale. There are many ways to illustrate this; I will point our several scaling problems below and limit myself here to the use of the MIB-II ifTable here. Let's look at the impact of this on a terminal server as a typical worst case example, terminal servers being low end (no much memory) commodity (more memory cannot be competatively added) products with lots of potential point-to-point interfaces. If someone tries to implement this model on a terminal server, and also needs to support several network protocols over PPP, ifTable entries will rapidly consume a lot of memory. Some objects in this table make sense only at one layer (e.g., ifInUnknownProtos), or might be implemented in other ways than could be represented conveniently in this way (e.g., ifQlen; some implementations might, for example, use the same queue for all NCPs). The model also introduces whole constellations of pointers just to allow users to navigate from one non-interface to another to another. Thus, the existing organization seems to needlessly consume a lot of memory with redundant variables that add no intrinsic value. The organization presents an implementor with the delimma of burning memory by writing special case code to avoid implementing variables irrelevant to a layer, or instead burning memory by implementing a bunch of variables that are never used. Maybe I'm wrong, but it seems like implementations could save 20 to 50 bytes of ifTable counters and parameters PER PROTOCOL PER PORT if they did not have to support all these ifEntries. Memory is NOT yet free in all systems. If some systems need all this extra stuff, let them implement MIB extensions. b. It does not model the user's perception of the real configuration. In particular, a platform implementing PPP will have a number of hardware ports. For better or for worse, the users (and most implementors!) I've talked with identify an interface with each of these physical ports. They associate each protocol using that interface with the physical port, not with another virtual something or other that uses the port's interface. They tend to view all such intermediate constructs as fluff that they don't want to have to worry about. They just want to know what their protocols are doing over the real (i.e., physical) interfaces. To press this point further, given users' perceptions, this organization will require a special purpose application at the network management system to reassemble and present the information the way users perceive it. That is, it will be utterly unintelligible from random network management station X. It seems certain this will undermine acceptance of the MIB in the user community. c. It violates the entire spirit of SNMP, in that it shifts organization of the data from the management station to the managed system. SNMP, again for better or worse, uses a flat data model. The proposed model is something we'd expect from the OSI community: an elegant, nicely layered hierarchical model. Why should we impose the cost of supporting this conceptual layering in the SNMP agent on the managed systems? According to SNMP folklore, all we really have to do is return the minimum information that is needed by the network management station to deduce whatever presentation of the data that it wants. d. I believe (maybe no one else does; no one is requried to) that it will require a revision of MIB-II, as it imposes new semantics on the ifTable. For instance, users are going to have to learn and remember all the different semantics associated with the ifAdminStatus of each non-interface entry the MIB requires in the ifTable. At this stage it would be unfair to throw any more rocks at the basic organization without offering at least one alternative organization to replace it. Why not instead use an organization something like, for example, one giant PPP table "hung off" the ifTable: pppTable OBJECT-TYPE SYNTAX SEQUENCE OF pppEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The characteristics, status, and counters common to each protocol provided by every PPP interface." ::= { ppp 1 } pppEntry OBJECT-TYPE SYNTAX pppEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The characteristics, status, and counters associated with a particular protocol over a PPP interface. An entry exists in this table only if its protocol can execute over an interface." INDEX { pppIfNumber, pppProtocol } ::= { pppTable 1 } where pppIfNumber and pppProtocol are something like pppIfNumber OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The interface number of the PPP entity. The value of this object equals that of the ifNumber for the interface with which this entry is associated." ::= { pppEntry 1 } pppProtocol OBJECT-TYPE SYNTAX OBJECT IDENTIFER -- one of the pppProtocols ACCESS read-only STATUS mandatory DESCRIPTION "The PPP protocol type for this entry." ::= { pppEntry 2 } pppLcpProtocol OBJECT IDENTIFIER ::= { pppProtocols 1 } pppIpcpProtocol OBJECT IDENTIFIER ::= { pppProtocols 2 } etc. I believe something along these lines addresses my concerns (although I've been wrong before). Granted, this would introduce its own problems, but I believe these could be fixed. For example, any protocol specific information could be put in a parallel table indexed by ifNumber only. How would we know such a table existed? Because the protocol has corresponding entries indicated by the correct pppProtocol value in the pppTable. To summarize this tirade, I am concerned that the current organization will force many implementors to choose between conforming to the `standard' PPP MIB and other organizations that are more efficient and better map onto user expectations. Please try to alleviate my fears. > PppLinkEntry ::= SEQUENCE { > pppLinkIndex > INTEGER, > pppLinkPhysicalIndex > INTEGER, > pppLinkBadAddresses > Counter, > pppLinkBadControls > Counter, > pppLinkPacketTooLongs > Counter, > pppLinkBadFCSs > Counter, > pppLinkIpcpIndex > INTEGER, > pppLinkIpIndex > INTEGER, > pppLinkBncpIndex > INTEGER, > pppLinkBridgeIndex > INTEGER > } Here is another exhibit in the case against the proposed organization. Why should a workstation, host, PC, router, or terminal server have to implement the pppLinkBncpIndex and pppLinkBridgeIndex? They are not bridges. Conformance to the spirit of the rules for MIB writing expressed in SNMP RFCs would dictate that these be excised, as they are inapplicable to the majority of systems implementing the MIB. But that is really impossible given the existing organization. This raise a question of why these indices are needed at all. Merely because, given the current organization, there is no other way to glue the various peices together: no natural algorithm exists (that we could get everyone to agree to) to map an IPCP non-interface onto an LCP non-interface onto a real physical interface, so managers can trace perceived problems through the system. The scaling problems are also evident here. If we continue with the existing organization, this table will grow. There will be two new indices for Appletalk (let's call them pppLinkAtcpIndex and pppLinkAtIndex), two more for OSI (pppLinkOsicpIndex and pppLinkOsiIndex), two more for IPX, two for--well, you get the idea. All of these new indices must go in this table, and then ALL SNMP manageable PPP implementations will have to support these new variables, because a group is the unit of implementation within SNMP. This is not absolutely horrible, just two null indices per unsupported protocol, but this sort of indirection is going to start to accumulate into an onerous burden on small, single protocol suppliers, and on diskless systems that support lots of links. Remember, each one of these null indices will HAVE to be implemented for EVERY hardware port which can run PPP, which will become an exhorbitant cost on many low end systems like terminal servers. > PppLcpStatusEntry ::= SEQUENCE { > pppLcpStatusIndex > INTEGER, > pppLcpLinkIndex > INTEGER, > pppLcpStatusLocalMRU > INTEGER, > pppLcpStatusRemoteMRU > INTEGER, > pppLcpStatusLocalToPeerACCMap > OCTET STRING, > pppLcpStatusPeerToLocalACCMap > OCTET STRING, > pppLcpStatusLocalToRemoteProtocolCompression > INTEGER, > pppLcpStatusRemoteToLocalProtocolCompression > INTEGER, > pppLcpStatusLocalToRemoteACCompression > INTEGER, > pppLcpStatusRemoteToLocalACCompression > INTEGER > } This table is looking very good. Since FCS is configurable (negotiable), it might be useful to include fields indicating the FSC in use. I again object to the pppLcpLinkIndex, as being extra artifact imposed by what I consider to be a suboptimal albeit elegant organization. Now you can acuse me of talking out of both sides of my mouth, as I am asking for more features in one breath and criticizing the amount of memory being used in the next ;-) > pppLcpStatusLocalMRU OBJECT-TYPE > SYNTAX INTEGER > ACCESS read-only > STATUS mandatory > DESCRIPTION > "The final negotiated MRU value for the local > PPP Entity. This value is the MRU that the > remote entity has accepted for the local PPP > entity." > ::= { pppLcpStatusEntry 3 } It would be more accurate to use a DESCRIPTION clause saying something like "The MRU value for the local PPP Entity." The value in use may have nothing to do with negotiation, as there is no guarantee the peer has implemented the option. The values might have been manually configured by some kind of network management channel outside of SNMP, or they might even be entirely unconfigurable. The same remark applies to the other status objects in this group that mention negotiation. > PppLcpConfigEntry ::= SEQUENCE { > pppLcpConfigIndex > INTEGER, > pppLcpConfigInitialMRU > INTEGER, > pppLcpConfigACCMap > OCTET STRING, > pppLcpConfigMagicNumber > INTEGER, > pppLcpConfig32BitFCS > INTEGER > } This also is a very nice improvement over the original. I am still concerned, however, that the MIB does not include language allowing each of the options to be optional. That is, the way I read current language in the MIB, anyone who implements the MIB and one of the options MUST also implement ALL the other options in the table. This clearly will require the LCP specification to be revised to move the MRU, ACC, magic number, and FCS option from OPTIONAL to MANDATORY :-) The DESCRIPTION clause must accordingly be changed to indicate what is returned when the managed system does not implement the option a variable pertains to, even if to say this is implementation specific. Presumably, this can differ between implementations that make some parameter configurable and those that do not. I'm a little puzzled that there is no option to enable/disable LQM. Users simply wouldn't want to bother with it on a lot of links (e.g., PCs directly attached to a host or terminal server via an asynch line). Is the intention to control it from its ifEntry's ifAdminStatus? I believe most users will find such a division confusing. > pppLcpConfigReceiveACCMap OBJECT-TYPE > SYNTAX OCTET STRING (SIZE (4)) > ACCESS read-write > STATUS mandatory > DESCRIPTION > "The Asynchronous-Control-Character-Map (ACC) > that the local PPP entity requires for use on > its receive side. In effect, this is the ACC > Map that is required in order to ensure that > the local modem will successfully receive all > characters. The actual ACC map used on the > receive side of the link will be a combination > of the local node's pppLcpConfigReceiveACCMap > and the remote node's pppLcpConfigXmitACCMap. > Changing this object will have effect when the > link is next restarted." > REFERENCE > "Section 7.3, page 4, Async-Control-Character- > Map of [8]." > DEFVAL { 'ffffffff'h } > ::= { pppLcpConfigEntry 3 } > > > pppLcpConfigXmitACCMap OBJECT-TYPE > SYNTAX OCTET STRING (SIZE (4)) > ACCESS read-write > STATUS mandatory > DESCRIPTION > "The Asynchronous-Control-Character-Map (ACC) > that the local PPP entity requires for use on > its transmit side. In effect, this is the ACC > Map that is required in order to ensure that > all characters can be successfully transmitted > through the local modem. The actual ACC map > used on the transmit side of the link will be a > combination of the local node's > pppLcpConfigXmitACCMap and the remote node's > pppLcpConfigReceiveACCMap. Changing this object > will have effect when the link is next > restarted." > REFERENCE > "Section 7.3, page 4, Async-Control-Character- > Map of [8]." > DEFVAL { 'ffffffff'h } > ::= { pppLcpConfigEntry 4 } Are both of these actually necessary? Why not only the receive map? Is is really true there are characters we know we can receive in the clear but can't send from our end? Why can't the mask we use for transmission be a bit-wise OR of our receive mask with the mask the peer wants to use? > pppLcpConfigMagicNumber OBJECT-TYPE > SYNTAX INTEGER {false (1), true (2)} > ACCESS read-write > STATUS mandatory > DESCRIPTION > "If true(2) then the local node will attempt to > perform Magic Number negotiation with the > remote node. If false(1) then this negotiation > is not performed. In any event, the local node > will comply with any magic number negotiations > attempted by the remote node, per the PPP > specification. Changing this object will have > effect when the link is next restarted." > REFERENCE > "Section 7.6, Magic Number, of [8]." > DEFVAL { false } > ::= { pppLcpConfigEntry 5 } I'm a bit perplexed by this. What harm does it do to always negotiate the magic number option? The space is allocated for it in every maintance packet anyway. > PppIpcpEntry ::= SEQUENCE { > pppIpcpIndex > INTEGER, > pppIpcpLinkIndex > INTEGER, > pppIpcpLocalToRemoteCompressionProtocol > INTEGER, > pppIpcpRemoteToLocalCompressionProtocol > INTEGER, > pppIpcpRemoteMaxSlotId > INTEGER, > pppIpcpLocalMaxSlotId > INTEGER > } You know, the usual gripe about pppIpcpLinkIndex being required only as a side effect of the existing organization; it has no intrinsic value in itself. > pppIpcpLocalToRemoteCompressionProtocol OBJECT-TYPE > SYNTAX INTEGER { > none(1), > vj-tcp(2) > } > ACCESS read-only > STATUS mandatory > DESCRIPTION > "The IP compression protocol that the local > PPP-IP entity uses when sending packets to the > remote PPP-IP entity." > ::= { pppIpcpEntry 3 } > > > pppIpcpRemoteToLocalCompressionProtocol OBJECT-TYPE > SYNTAX INTEGER { > none(1), > vj-tcp(2) > } > ACCESS read-only > STATUS mandatory > DESCRIPTION > "The IP compression protocol that the remote > PPP-IP entity uses when sending packets to the > local PPP-IP entity." > ::= { pppIpcpEntry 4 } > > > pppIpcpRemoteMaxSlotId OBJECT-TYPE > SYNTAX INTEGER(0..255) > ACCESS read-only > STATUS mandatory > DESCRIPTION > "The Max-Slot-Id parameter that the remote node > has advertised and that is in use on the link." > ::= { pppIpcpEntry 5 } > > > pppIpcpLocalMaxSlotId OBJECT-TYPE > SYNTAX INTEGER(0..255) > ACCESS read-only > STATUS mandatory > DESCRIPTION > "The Max-Slot-Id parameter that the local node > has advertised and that is in use on the link." > ::= { pppIpcpEntry 6 } Is it the intent that the SNMP agent at the managed system should return 0 for the value of the ppp...MaxSlotId objects when vj-tcp(2) has not been negotiated? > PppIpcpConfigEntry ::= SEQUENCE { > pppIpcpConfigIndex > INTEGER, > pppIpcpConfigCompression > INTEGER, > pppIpcpConfigStatus > INTEGER > } As with the LCP configuration table, it seems as though it would be wise to include language in the DESCRIPTION clause for these objects which says what value an implementation returns if it does not implement an option controlled by the object. > ppIpcpConfigStatus OBJECT-TYPE > SYNTAX INTEGER { > disabled(1), > enabled(2) > } > ACCESS read-write > STATUS mandatory > DESCRIPTION > "If enabled(2) then the local node will allow > IP traffic to flow across the link. If > disabled(1) then IP traffic will not be allowed > to flow across the link. Setting this object > to the value disabled(1) has the effect of > invalidating the corresponding entry in the > pppIpcpConfigTable object. It is an > implementation-specific matter as to whether > the agent removes an invalidated entry from the > table. Accordingly, management stations must be > prepared to receive tabular information from > agents that corresponds to entries not > currently in use." > ::= { pppIpcpConfigEntry 3 } Ok, so now we have three ways to enable or disable IP over PPP: (a) ifAdminStatus in IPCP's ifTable entry (cf. Section 5.4.5.1 of the MIB) (b) ifAdminStatus in IP's ifTable entry (cf. Section 5.4.6 of the MIB; well, this is really only supposed to cause a renegotiation, but I doubt that semantics can be made to stick) (c) this new object This is yet another sign that the MIB organization is not yet right. Part of SNMP folklore is that we should never introduce objects which permit the same thing to be done in more than one way. True, the rule is frequently violated, but if we are already concerned with the size of the MIB, can't we pare this down? Not if we use the current organization (we can, though, eliminate the ppIpcpConfigStatus (sic) from the MIB, but this would probably appear confusing to users, since all the other option parameters are found here). If we changed the basic organization to eliminate the ifEntries for all the non-interfaces, then pppIpcpConfigStatus would be just fine. In closing, I'd like to reiterate my admiration to the people working on the MIB regarding all they have accomplished. I feel the MIB is heading in the right direction. Jesse Walker Digital Equipment Corporation Telecommunications and Networking From ietf-ppp-request@ucdavis.ucdavis.edu Thu Apr 23 12:53:00 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28096; Thu, 23 Apr 92 12:24:13 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01630; Thu, 23 Apr 92 12:01:54 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26674; Thu, 23 Apr 92 11:46:24 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from bridge2.NSD.3Com.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25847; Thu, 23 Apr 92 11:29:18 -0700 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA01284 (5.65c/IDA-1.4.4nsd for ); Thu, 23 Apr 1992 11:20:01 -0700 Received: by jaspar.NSD.3Com.COM id AA05612 (5.65c/IDA-1.4.4-910730); Thu, 23 Apr 1992 11:19:35 -0700 Date: Thu, 23 Apr 1992 11:19:35 -0700 From: "Cyndi M. Jung" Message-Id: <199204231819.AA05612@jaspar.NSD.3Com.COM> To: rjacob@wnyosi9.nctsw.navy.mil Subject: Re: more regarding OSI over PPP Cc: ietf-ppp@ucdavis.ucdavis.edu Hi, I just got onto this mailing list yesterday - a real quick response, actually. Too many people were forwarding these messages to me - thanks, but you can rest now, I'm getting it directly. 3Com does have OSI over PPP, but unfortunately we don't have dial-up support just yet. When we have the dial-up, then it will behave exactly as you describe, with the connection made when the traffic requires it, and maintained until the traffic subsides. We currently do this for routing over X.25 networks, and it is *essentially* the same algorithm, except that only one destination will be actively reachable at a time on the phone line, whereas with X.25 there may be multiple destinations reachable at the same time over the same physical line. Don't misinterpret this as a recommendation to use an X.25 network - it's just a statement. Cyndi From ietf-ppp-request@ucdavis.ucdavis.edu Thu Apr 23 12:54:30 1992 Received: from [128.120.2.9] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28760; Thu, 23 Apr 92 12:41:44 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01788; Thu, 23 Apr 92 12:19:14 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27569; Thu, 23 Apr 92 12:10:24 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from bridge2.NSD.3Com.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27084; Thu, 23 Apr 92 11:57:20 -0700 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA02299 (5.65c/IDA-1.4.4nsd for ); Thu, 23 Apr 1992 11:56:53 -0700 Received: by jaspar.NSD.3Com.COM id AA05766 (5.65c/IDA-1.4.4-910730); Thu, 23 Apr 1992 11:56:52 -0700 Date: Thu, 23 Apr 1992 11:56:52 -0700 From: "Cyndi M. Jung" Message-Id: <199204231856.AA05766@jaspar.NSD.3Com.COM> To: brian@lloyd.com Subject: Re: more regarding OSI over PPP (note from Brian and my response). Cc: ietf-ppp@ucdavis.ucdavis.edu > Since IP/TCP is considered part of an > acceptable GOSIP solution you should be covered in that area. I think this still has the status of *rumor*. From ietf-ppp-request@ucdavis.ucdavis.edu Thu Apr 23 19:18:43 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13549; Thu, 23 Apr 92 18:55:19 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05102; Thu, 23 Apr 92 18:12:34 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10336; Thu, 23 Apr 92 17:32:43 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07182; Thu, 23 Apr 92 16:13:28 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA03579; Thu, 23 Apr 92 16:12:57 PDT Date: Thu, 23 Apr 92 16:12:57 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9204232312.AA03579@ray.lloyd.com> To: cmj@NSD.3Com.COM Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: "Cyndi M. Jung"'s message of Thu, 23 Apr 1992 11:56:52 -0700 <199204231856.AA05766@jaspar.NSD.3Com.COM> Subject: more regarding OSI over PPP (note from Brian and my response). Date: Thu, 23 Apr 1992 11:56:52 -0700 From: "Cyndi M. Jung" > Since IP/TCP is considered part of an > acceptable GOSIP solution you should be covered in that area. I think this still has the status of *rumor*. Maybe it is. That is not how I remember it, having been involved in a number of sales of IP-based products to the government since the requirement for GOSIP compliance came out. Anyway, what do you want me to say to the poor guy? Wait a couple of years; maybe somone will do what you want? Heck, he can buy what he wants today if he goes IP instead if OSI. It's a fact of life, Cyndi. You can beat the OSI drum until you are blue in the face but people who have work to do NOW do it with the Internet Protocol Suite. 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 Apr 23 19:37:04 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14938; Thu, 23 Apr 92 19:36:14 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05773; Thu, 23 Apr 92 19:22:06 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14513; Thu, 23 Apr 92 19:21:33 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from bridge2.NSD.3Com.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14459; Thu, 23 Apr 92 19:20:26 -0700 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA11608 (5.65c/IDA-1.4.4nsd for ); Thu, 23 Apr 1992 19:19:54 -0700 Received: by jaspar.NSD.3Com.COM id AA06940 (5.65c/IDA-1.4.4-910730); Thu, 23 Apr 1992 19:19:50 -0700 Date: Thu, 23 Apr 1992 19:19:50 -0700 From: "Cyndi M. Jung" Message-Id: <199204240219.AA06940@jaspar.NSD.3Com.COM> To: brian@lloyd.com Subject: OSI over PPP Cc: ietf-ppp@ucdavis.ucdavis.edu Well, this is a very friendly mailing list. I think the fellow can buy whatever solves his problem - that's what a free market economy provides. My remark about TCP/IP not being part of GOSIP is just what it says - I'm not giving advice on purchasing equipment. I've seen the rumor about GOSIP embracing TCP/IP grow from a seemingly innocent question to a statement of fact provided by you, and I think that is simply misleading. Many people don't bother to read the primary literature, and they rely on information they get in mailing lists like, and that can be a problem if people nurture and propogate rumors as though they were statement of fact. I wouldn't give up my network for a minute, and it is certainly based on TCP/IP, to be sure. But if someone is putting together an X.400 mail system involving 10-30 locations, it isn't very helpful to tell him to hang it up and use TCP/IP. If cisco implemented OSI over PPP in conjunction with their new dial-up support, he would have his sought-for solution TODAY - and if 3Com had the dial-up support TODAY in conjunction with the OSI over PPP, he would have the solution to his problem (and we could sell him some hardware). Clearly, he is looking for a clue as to when he can get that solution - he's the one beating on the OSI drum, I'm just trying to answer some of his questions. If you really want to continue this dialogue, perhaps we can take it off the mailing list so the others don't get bored. Cyndi ----- Begin Included Message ----- From brian@lloyd.com Thu Apr 23 16:13:04 1992 From: brian@lloyd.com (Brian Lloyd) To: cmj@nsd.3com.com Cc: ietf-ppp@ucdavis.edu Subject: more regarding OSI over PPP (note from Brian and my response). Reply-To: brian@lloyd.com Date: Thu, 23 Apr 1992 11:56:52 -0700 From: "Cyndi M. Jung" > Since IP/TCP is considered part of an > acceptable GOSIP solution you should be covered in that area. I think this still has the status of *rumor*. Maybe it is. That is not how I remember it, having been involved in a number of sales of IP-based products to the government since the requirement for GOSIP compliance came out. Anyway, what do you want me to say to the poor guy? Wait a couple of years; maybe somone will do what you want? Heck, he can buy what he wants today if he goes IP instead if OSI. It's a fact of life, Cyndi. You can beat the OSI drum until you are blue in the face but people who have work to do NOW do it with the Internet Protocol Suite. 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 ----- End Included Message ----- From ietf-ppp-request@ucdavis.ucdavis.edu Fri Apr 24 09:20:53 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15000; Fri, 24 Apr 92 09:06:32 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09514; Fri, 24 Apr 92 08:30:46 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13016; Fri, 24 Apr 92 08:15:59 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from mts-gw.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12641; Fri, 24 Apr 92 08:05:30 -0700 Received: by mts-gw.pa.dec.com; id AA16878; Fri, 24 Apr 92 08:04:21 -0700 Message-Id: <9204241504.AA16878@mts-gw.pa.dec.com> Received: from eider.enet; by decpa.enet; Fri, 24 Apr 92 08:04:30 PDT Date: Fri, 24 Apr 92 08:04:30 PDT From: Jesse Walker To: kasten@europa.clearpoint.com Cc: ietf-ppp@ucdavis.ucdavis.edu Apparently-To: kasten@europa.clearpoint.com, ietf-ppp@ucdavis.edu Subject: Re: re: More PPP MIB Comments Frank: > when i started revising the ppp mib a couple of months ago, i > realized that, by and large, most of these counters were > available (in the sense of the OBJECT-TYPE definitions) in the > interface group. so it seemed that, if i could leverage off of the > interface table's counters i would get a win -- i'd get the > desired counts and i would reduce the number of object-types > that needed to be defined. (independent of the counters and > code to increment them, there is a cost of implementing each > OBJECT-TYPE. in my implementation each OBJECT-TYPE requires > about 48 bytes of data). The strategy to reuse existing counters whenever possible is a goal I applaud, and I feel you should be commended for thinking of something so lovely and powerful. However, we need to evaluate whether the PPP MIB is a case where this is the right strategy. My problem is the costs here are not just per port; they are per protocol per port. Let me go through a back of the envelope calculation to demonstrate my concerns; maybe you can point out a flaw in my reasoning and thereby put my qualms to rest. I will use your quoted basic OBJECT-TYPE overhead of 48 bytes as a baseline in my computation. In my comments I suggested a different organization which I thought might scale better. Both the draft MIB and the organizational change I suggested would have to convey the same "real" information. So I want to estimate the memory costs of representing this same information in the two appraoches. The fundamental difference between them is how they convey the information the draft MIB derives from ifEntries and which I would place in one giant pppTable, indexed by interface and protocol. So in my calculation I am only going to account for the different ways in which the two approaches represent this information. For the purposes of this exercise, I will estimate memory costs thusly: Memory cost = (OBJECT-TYPE Cost) + (per port cost) * (number ports) OBJECT-TYPE Cost = (Cost for one OBJECT-TYPE) * (number objects) per port cost = (per protocol costs) * (number protocols) Here "number ports" refers only to the number of ports that implement PPP. The per port cost equation assumes that every PPP port will run the same set of protocols, which may be wrong, but then you can reinterpret "number protocols" to mean average number of protocols per port. As I said, for this exercise we will assume the cost of a new OBJECT-TYPE will be about 50 bytes. So for my allegedly scalable proposal, we have to determine the number of new OBJECT-TYPEs; for the approach followed in the draft MIB, this cost is 0, since, for the purposes of our estimate, we are assuming all the non-ifTable variables have to be represented in both MIBs anyway. If we were to use the giant table approach, we would have to define new pppTable counterparts for 11 existing OBJECT-TYPEs: ifAdminStatus ifOperStatus ifLastChange ifInOctets ifInNUcastPkts ifInDiscards ifInErrors ifOutOctets ifOutNUcastPkts ifOutDiscards ifOutErrors So the giant table approach starts out by increasing the size of every managed system implementing PPP by about 550 bytes, above the costs to simply save this data and implement all the MIBs. This is horrible enough for someone who counts bytes instead of kilo- or mega-bytes, but let's go on to estimate the costs of the draft MIB. The storage costs for the actual information these variables consume is the same in either case, so can be omitted from the computation, as it does not affect the difference in costs between the two approaches. For the appraoch the draft MIB uses, we have to find per protocol storage for the following on each hardware port: ifDescr ifType ifMtu ifSpeed ifPhysAddress ifInUcastPkts ifOutUcastPkts ifOutQLen ifSpecific which the giant table approach does not use. This assumption may be wrong, but I'm willing to bet that we'll be hard pressed to find a consensus that we should move very many (if any) of these into any sort of PPP MIB, if the physical port already has an ifTable entry to accomodate them. We could also argue that it really is not true that there is a per protocol per port cost for all of these, that implementations can optimize away some of these fields by using the same value for each protocol, but that would imply a lot of special case ifTable code whose cost I really don't know how to estimate. My suspicion is such a strategy would probably help the scaling somewhat, but that these "extra" variables still have to be paid for somehow. I will make the following assumptions about the memory required to store each one of these variables: ifDescr - 3 bytes of text to identify the protocol; I will assume the implementation will concatenate this with a port identifier of some ilk to make it intelligible to humans; in practice, I expect most vendors would opt for much more ifType - 1 byte ifMtu - 2 bytes ifSpeed - 4 bytes ifPhysAddress - 1 byte ifInUcastPkts - 4 bytes ifOutUcastPkts - 4 bytes ifOutQLen - 1 byte ifSpecific - 0 bytes; we'll pretend its free This is a total of 20 bytes. Again, this number may be wrong, but I expect it is the right order of magnitude. Let p be the number of ports and n the number of protocols. Notice n is greater than or equal to 3 in all implementations of the draft as everyone must implement LCP, one NCP, and one NP to have a usable implementation. This means that the incremental per port costs of the draft's approach are 20*p*n, with n >= 3. There are no additional per port costs apparent in my allegedly scalable approach, as there are no additional variables we need to keep track of. Remember, we don't need to account for the cost of the variables we maintain under both schemes, as we are trying to estimate only the incremental cost of the data representation, not the data storage costs of variables that would be kept under either proposal. So, the giant table appraoch uses about 550 bytes to implement OBJECT-TYPEs for the ifTable stuff that is not "extra", while the draft uses 20*p*n bytes. This number is the heart of my criticism. A box servicing 16 lines already pays more (960 bytes) under the draft approach than with the giant table approach with just 3 protocols, say LCP, IPCP, and IP. And the situation gets progressively worse--the draft requires that we increment n by 2 for each additional network protocol is supported. Now this estimate could be misleading in one of several ways: (a) it could over-estimate the costs of implementing the "extra" fields in the ifTable. Maybe the real cost is 5 bytes, not 20. But I believe it is just as likely that I've graciously underestimated the memory usage of the draft approach, so the real costs of the draft may be even worse. In any case, the number strikes me as the right order of magnitude. (b) My assumptions could classify too many ifTable variables as "extra". Correcting this would raise the cost of the giant table approach and lower the constant 20 estimated for the draft MIB. This still would not help in the long run, as platforms implement more protocols, or more hardware ports, or both. The fact is, the one approach has a constant differential cost based sheerly on the MIB, while the other grows as O(p*n), which will always lose in the long run. (c) There might be costs in the giant table approach that I haven't properly accounted for. These would be very difficult to identify at this level of design, as every variable it uses has a counterpart in the drafts' approach but not vice versa. (d) My basic assumptions about the equations governing memory usage may be flawed. Again, it is hard to see what else to take into account at this level of analysis. Admittedly, this estimate is not detailed enough to give us any idea of the real costs of the two approaches. I do believe, however, it is conclusive enough to support my concerns regarding scaling. It would make me very happy if someone found a flaw that invalidates this basic conclusion, as then we could immediately agree on the basic MIB organization and avoid altogether any changes to it. > there is also a certain advantage to using a common mib > structure to instrument the layers of something like i do. > a management station can look at all of the basic > information (packets in/out, bytes in/out, total errors, > up/down status, etc) of all elements of a stack regardless > of what that element is. it seems to me that this is a very > big win for the manager at, what i perceive to be little or no > cost to the agent. This is a very good point in favor of the draft, and I believe it should be weighed in the final decision. > > > pppLcpStatusLocalMRU OBJECT-TYPE > > > SYNTAX INTEGER > > > ACCESS read-only > > > STATUS mandatory > > > DESCRIPTION > > > "The final negotiated MRU value for the local > > > PPP Entity. This value is the MRU that the > > > remote entity has accepted for the local PPP > > > entity." > > > ::= { pppLcpStatusEntry 3 } > > > > It would be more accurate to use a DESCRIPTION clause saying something > > like > > > > "The MRU value for the local PPP Entity." > > > > The value in use may have nothing to do with negotiation, as there is > > no guarantee the peer has implemented the option. The values might > > have been manually configured by some kind of network management > > channel outside of SNMP, or they might even be entirely > > unconfigurable. > > this sort of thing is more of an implementation-specific feature that > might be added by vendor X and, therefore, belongs in that vendor's > private mib. > > if i read the ppp protocol spec right, everyone must do mru negotiation. > though an implementation may only support the default (1500 byte) mru. The MRU option is **MANDATORY**!!?! Where does it say that in the LCP spec? It's not even one of the ones recommended to be implemented by every system! While I am certain almost every implementation will support this option, the language in the MIB does not allow for the possibility that some might not. As this language is stronger than any I can remember from the LCP spec, the choices seems to be to strengthen the language in the LCP spec or to water it down in the MIB. > > > PppLcpConfigEntry ::= SEQUENCE { > > > pppLcpConfigIndex > > > INTEGER, > > > pppLcpConfigInitialMRU > > > INTEGER, > > > pppLcpConfigACCMap > > > OCTET STRING, > > > pppLcpConfigMagicNumber > > > INTEGER, > > > pppLcpConfig32BitFCS > > > INTEGER > > > } > > > > This also is a very nice improvement over the original. > > > > I am still concerned, however, that the MIB does not include language > > allowing each of the options to be optional. That is, the way I read > > current language in the MIB, anyone who implements the MIB and one of > > the options MUST also implement ALL the other options in the table. > > This clearly will require the LCP specification to be revised to move > > the MRU, ACC, magic number, and FCS option from OPTIONAL to > > MANDATORY :-) The DESCRIPTION clause must accordingly be changed to > > indicate what is returned when the managed system does not implement > > the option a variable pertains to, even if to say this is implementation > > specific. Presumably, this can differ between implementations that > > make some parameter configurable and those that do not. > > implementation of a mib object-type does not mandate the implementation of > the underlying functions (e.g. ifPhysAddress for interface types which do > not have addresses such as SLIP). implementing, e.g., pppLcpConfig32BitFCS, > does not force one to implement the 32 bit checksum capability. if an > implementation does not do 32 bit checksums, that implementation would > always return false when the object is read and the snmp badValue error > when attempting to set the object to true. this is common snmp practice. The point you make is absolutely correct. What I have in mind is that perhaps we can add some text that would allow us to side-step a lot of the silliness surrounding MIB-I and MIB-II implementations. If you'll recall, a lot of people implemented by the book. The result was their systems were unmanageable. On the other hand systems that did not implement a feature but included the MIB object for it anyway were lying but caused absolutely no interoperability problems with anyone. All I'm asking for is a sentence like "The behavior of implementations which do not implement the feature controlled by this MIB object is implementation specific." or something like that. > > > pppLcpConfigMagicNumber OBJECT-TYPE > > > SYNTAX INTEGER {false (1), true (2)} > > > ACCESS read-write > > > STATUS mandatory > > > DESCRIPTION > > > "If true(2) then the local node will attempt to > > > perform Magic Number negotiation with the > > > remote node. If false(1) then this negotiation > > > is not performed. In any event, the local node > > > will comply with any magic number negotiations > > > attempted by the remote node, per the PPP > > > specification. Changing this object will have > > > effect when the link is next restarted." > > > REFERENCE > > > "Section 7.6, Magic Number, of [8]." > > > DEFVAL { false } > > > ::= { pppLcpConfigEntry 5 } > > > > I'm a bit perplexed by this. What harm does it do to always negotiate > > the magic number option? The space is allocated for it in every > > maintance packet anyway. > > this sort of thing is a ppp protocol issue. if the ppp is changed to > always do magic number negotiation then this variable would go away. > it is not a function of the mib to define the protocol. I still don't understand. Where does the LCP spec give any sort of policy about when to negotiate this option? It seems to have pretty much a free market attitude regarding all options to me. Jesse From ietf-ppp-request@ucdavis.ucdavis.edu Fri Apr 24 13:20:24 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24561; Fri, 24 Apr 92 13:14:09 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA12537; Fri, 24 Apr 92 12:46:34 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22911; Fri, 24 Apr 92 12:32:33 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from eco.twg.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21528; Fri, 24 Apr 92 11:57:54 -0700 Received: from LOCAL.eco.twg.com by eco.twg.com (5.65/ECO.m-$Revision: 2.15 $) id AA23053; Fri, 24 Apr 92 14:56:32 -0400 Message-Id: <9204241856.AA23053@eco.twg.com> Organization: The Wollongong Group, Inc., East Coast Operations Address: 2010 Corporate Ridge Drive, Suite 550, McLean, VA 22102 Phone: 703-847-4500 (Voice); 703-847-4520 (Fax) Received: from navajo.twg.com by apache.twg.com id <20165-0@apache.twg.com>; Fri, 24 Apr 1992 11:57:24 -0700 From: "David Herron" Subject: Re: OSI over PPP To: IETF-PPP Discussion Date: Fri, 24 Apr 92 12:03:29 PDT In-Reply-To: Your message of Thu, 23 Apr 1992 19:19:50 -0700.<199204240219.AA06940@jaspar.NSD.3Com.COM> Importance: Low Sensitivity: Personal Conversion: Prohibited Conversion-With-Loss: Prohibited Encoding: 20 TEXT > Well, this is a very friendly mailing list. Yes, and I hope that it remains so. ... > I wouldn't give up my network for a minute, and it is certainly based > on TCP/IP, to be sure. But if someone is putting together an X.400 > mail system involving 10-30 locations, it isn't very helpful to tell > him to hang it up and use TCP/IP. Hey.. it ain't even necessary to have TPn (that is, OSI lower layers) in order to run X.400 exchanges. We have been doing that for over a year with our MTA and exchanging mail with UCL through our MILNET connection for at least that long. On the other hand I'd like to see OSI over PPP happen. PPP's a Good Thing and it supports lots of other protocols Right Now. (At least, there are RFC's talking about how to do it.. I dunno how many of these are available in Products.) David From ietf-ppp-request@ucdavis.ucdavis.edu Fri Apr 24 15:10:59 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29156; Fri, 24 Apr 92 14:58:12 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA13977; Fri, 24 Apr 92 14:30:40 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27164; Fri, 24 Apr 92 14:17:26 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26778; Fri, 24 Apr 92 14:09:45 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA04238; Fri, 24 Apr 92 14:09:01 PDT Date: Fri, 24 Apr 92 14:09:01 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9204242109.AA04238@ray.lloyd.com> To: david@twg.com Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: "David Herron"'s message of Fri, 24 Apr 92 12:03:29 PDT <9204241856.AA23053@eco.twg.com> Subject: OSI over PPP Thanks, I got the Internet_Tour.sit.bin file. I appreciate you making it available to me. 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 Apr 27 08:33:03 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18172; Mon, 27 Apr 92 08:26:18 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA26839; Mon, 27 Apr 92 08:00:06 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16930; Mon, 27 Apr 92 07:46:02 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from europa.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16502; Mon, 27 Apr 92 07:35:31 -0700 Received: by europa.clearpoint.com (4.1/1.34) id AA08639; Mon, 27 Apr 92 10:21:35 EDT Date: Mon, 27 Apr 92 10:21:35 EDT From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9204271421.AA08639@europa.clearpoint.com> To: CASE@utkvx.utk.edu, walker@eider.enet.dec.com Subject: Re: re: More PPP MIB Comments In-Reply-To: Mail from 'CASE@utkvx.utk.edu' dated: Sun, 26 Apr 1992 16:03 EST Cc: ietf-ppp@ucdavis.ucdavis.edu jeff, sorry i did not give complete data. per object type, there are 48 bytes of data for the snmp protocol processing itself. the code for each object type consists of a) a case entry in a switch statement (which seems to require about 4 bytes of data in the compiler-built jump table) abd b) whatever code it takes to get the desired data from where the main bridging/routing code wants to use it and into the data structure used by the snmp module. on my system it takes 24 bytes of code (6 instructions) to retrieve a counter (btw, this is a 29000 processor). independent of the per-object-type cost, is "overhead" which does the "instance" parsing. each set of variables which are indexed the same use a common routine to locate the necessary internal data structure(s) out of which the raw data are extracted. for example, all of the "ifIndex" indexed tables (such as ifTable, dot3Table, dot3StatsTable, dot1dBasePortTable and so on) all use a single routine which takes as its input data like the index number, whether we are doing a get or powerful-getnext, etc, etc, and returns a pointer to the right data structure. these costs are all independent of the number of instances of a variable. each instance does require the 4 bytes for the actual counter's unsigned long hope this helps frank > Message 32: > From ietf-ppp-request@ucdavis.edu Sun Apr 26 16:47:06 1992 > Sender: ietf-ppp-request@ucdavis.edu > From: CASE@utkvx.utk.edu > Subject: Re: re: More PPP MIB Comments > To: walker@eider.ENET.dec.com > Cc: ietf-ppp@ucdavis.edu > X-Envelope-To: ietf-ppp@ucdavis.edu > X-Vms-To: IN%"walker@eider.ENET.dec.com" > X-Vms-Cc: IN%"ietf-ppp@ucdavis.edu",CASE > > >> when i started revising the ppp mib a couple of months ago, i > >> realized that, by and large, most of these counters were > >> available (in the sense of the OBJECT-TYPE definitions) in the > >> interface group. so it seemed that, if i could leverage off of the > >> interface table's counters i would get a win -- i'd get the > >> desired counts and i would reduce the number of object-types > >> that needed to be defined. (independent of the counters and > >> code to increment them, there is a cost of implementing each > >> OBJECT-TYPE. in my implementation each OBJECT-TYPE requires > >> about 48 bytes of data). > > >Let me go through a back of the envelope calculation to demonstrate my > >concerns; maybe you can point out a flaw in my reasoning and thereby > >put my qualms to rest. I will use your quoted basic OBJECT-TYPE overhead > >of 48 bytes as a baseline in my computation. > > i was afraid this would happen when i first saw frank's message ... perhaps > i should have asked my question then > > ok frank, you said 48 bytes per object type ... of *DATA* ... how many bytes > of *CODE*? furthermore, is it true in your implementation, as it is in most > others, that this data, and code, areshared by all instances, i.e., all > protocols and all ports within a given OBJECT-TYPE? (excepting of course the > storage for the data themselves in the instrumentation ... here we are speaking > only of the data and code necessary to make these data accessible remotely > via the SNMP) > > it makes a difference in the analysis but may or may not result in a different > conclusion > > jdc From ietf-ppp-request@ucdavis.ucdavis.edu Mon Apr 27 15:48:15 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03476; Mon, 27 Apr 92 15:18:32 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA00969; Mon, 27 Apr 92 13:31:35 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28763; Mon, 27 Apr 92 13:17:24 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from XAP.XYPLEX.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28501; Mon, 27 Apr 92 13:11:20 -0700 Received: by xap.xyplex.com id ; Mon, 27 Apr 92 16:11:54 -0500 Date: Mon, 27 Apr 92 16:11:54 -0500 Message-Id: <9204272111.AA19818@xap.xyplex.com> From: Bob Stewart To: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Frank Kastenholz's message of Thu, 23 Apr 92 16:57:01 EDT <9204232057.AA05189@europa.clearpoint.com> Subject: Re: More PPP MIB Comments I've considered and reconsidered Jesse's objections and Frank's answers, and I have to come down on the side unhappy with the PPP MIB organization. In fact, the more I thought about it, the unhappier I got. With that, I'll address my comments to Frank's answers. By the way, the draft says it's to be submitted as a "Draft Standard". Don't you mean "Proposed Standard"? That's what comes first. > the general structure of the MIB (layers of ifEntrys) was derived > from the originally proposed MIB. the working group's original > direction to me on the MIB (at the Pittsburgh IETF meeting, just 2 > years ago now) was, simply put, "count everything". over time > i verified that the w.g. did, in fact, want to count bytes/packets > in and out for each of the different encapsulations, for the > network control protocols, etc, etc, etc. "Count everything" as a network management principle is one of the reasons network management remains in such a sorry state. The protocol designers couldn't figure out what was important, so the left it up to the network manager. Just because you CAN count bytes/packets in and out for each subprotocol or layer of encapsulation doesn't mean that's useful. Trimming the MIB of the objects that were there for debugging was a good start. Now it's time to trim it of the objects that can't be justified by a trouble-shooting or performance model that is of direct relevance to a network manager. The question to apply to every counter and status is, "So what?" How many is too many, or not enough? What do I fix when the counter is out of range? Which configuration parameter do I change, and in what way? If you can't answer those questions what at least some decent, coherent handwaving, the counter can't be understood and therefore can't be used, so toss it. > when i started revising the ppp mib a couple of months ago, i > realized that, by and large, most of these counters were > available (in the sense of the OBJECT-TYPE definitions) in the > interface group. so it seemed that, if i could leverage off of the > interface table's counters i would get a win -- i'd get the > desired counts and i would reduce the number of object-types > that needed to be defined. (independent of the counters and > code to increment them, there is a cost of implementing each > OBJECT-TYPE. in my implementation each OBJECT-TYPE requires > about 48 bytes of data). I see a conflicting goal here, between fewer objects for the PPP MIB and network management that a network manager can understand and use. The huge explosion of ifEntrys, representing INTERNAL PPP structures and protocols probably makes the ifTable unusable without network management systems far more intelligent than what's available today. If something must be complicated, it should be the MIB for the individual facility, not the MIB for everything else. > at the same time i also started grappling with the general problem > of dealing with multi-layer interfaces. there are several > interface types which are really layers of interfaces and the > problem is how to adequately represent these multiple layers > in the mib. eventually, the notion of viewing an interface as > an object which, in itself, is composed of multiple layers > came into being. I agree that we have a problem with multilayer interfaces, and I may agree that layers of ifEntrys is the solution, but that doesn't necessarily mean that those ifEntrys should represent INTERNAL layering. It's complex enough to have it represent EXTERNAL layering, such as X.25 hooked up to LAPB. At least in that case you can argue that LAPB could support something else. All these PPP "interfaces" are artifacts of its internal design, which I suspect is generally of little to no interest to the overworked, undertrained network manager. > it is true that applying some of the variables in the interface > table to all of the layers is a bit non-sensical. however, there > is some precedent. e.g. if one has an interface that is > running slip, there is no notion of a physical address, > so why have ifPhysAddress? there is no concept of unicast and > non-unicast packets at the interface level, so why have both > types of packets counted? if a counter (or whatever) makes > no sense for the protocol, return a null value (not the > NULL asn.1 syntax -- an "empty" value). in the case of slip, > i would return a 0 length octet string for ifPhysAddress. I agree with the nonsensical part. If we are to use the ifTable in this way at all, it needs some serious reconsideration. Exploding the nonsense across PPP only makes the problem uglier. Perhaps instead the PPP MIB should become a model for proper organization of the ifTable. Which is not to say that PPP's internals should make it into even a restructured ifTable. > there is also a certain advantage to using a common mib > structure to instrument the layers of something like i do. > a management station can look at all of the basic > information (packets in/out, bytes in/out, total errors, > up/down status, etc) of all elements of a stack regardless > of what that element is. it seems to me that this is a very > big win for the manager at, what i perceive to be little or no > cost to the agent. The cost of vastly increased data, for undecypherable information is not a win for the manager. As a manager, presented with hundreds of irrelevant or repetitive instances of constant values, I might ask why they are there, unimpressed by the purported architectural elegance. Jesse's argument about the object instance explosion applied to a multiprotocol, PPP-capable terminal server hit real close to home. > a mib need not map onto the user's perception of reality. mapping what > a mib provides with reality (any reality) is a function of the network > management station. if my management station provides a better reality > to customers than yours does then, everything else being equal, mine > will be a commercial success and yours won't. Although I have to agree on architectural grounds, I believe there are and should be limits to how far we carry this. The closer to reality we can make the MIB, the easier it will be to use, and the sooner it will be proven useful. > implementors always have to make the choice of doing the standard, > which may be suboptimal for their own implementation, and doing their > own thing, which is optimal for doing what they want done in their > implementation but is not standard. True, but when the standard becomes so complex, with little other than a combination of inertia and architecture as reasons, it encourages invention. > the implementation rules for mibs is that if you implement one of the > objects in a group then you must implement all of the objects in that > group. a group must be implemented if the conditions specified for > that group's implementation are met. True, and given this it is important to minimize the amount of a MIB that must be carried by implementations where it is irrelevant. The PPP MIB tables that contain objects related to optional parts of the protocol come to mind. It would be cleaner if each optional part came and went as a whole. If a device does not implement bridging, it should not carry ANY of the bridging-related PPP objects. Bridging, IP, IPX, AppleTalk, and so on should be separate groups. In fact, to ease adding each new protocol, they should be separate documents. I didn't try to be nice, like Jesse was. I know Frank can take it. :-)} Basically, what I'm suggesting is somewhat of a wholesale reorganization and more trimming of the PPP MIB. I'll offer to help as much as I can, given that I don't actually know that much about PPP itself. In any case, I'll hang around to take potshots at the results. Bob