From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 2 07:00:33 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05013; Mon, 2 Nov 92 06:50:16 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07221; Mon, 2 Nov 92 06:30:38 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04059; Mon, 2 Nov 92 06:26:51 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from LOBSTER.WELLFLEET.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03491; Mon, 2 Nov 92 06:11:46 -0800 Received: from ginzo.wellfleet ([192.32.1.233]) by lobster.wellfleet.com (4.1/SMI-4.1) id AA05255; Mon, 2 Nov 92 09:07:32 EST Received: by ginzo.wellfleet (4.1/SMI-4.1) id AA14610; Mon, 2 Nov 92 09:15:50 EST From: ginsburg@wellfleet.com (Scott Ginsburg) Message-Id: <9211021415.AA14610@ginzo.wellfleet> Subject: Re: Vines CP To: brian@lloyd.com Date: Mon, 2 Nov 92 9:15:48 EST Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <9211010355.AA09957@ray.lloyd.com>; from "Brian Lloyd" at Oct 31, 92 7:55 pm X-Mailer: ELM [version 2.3 PL11] > Is anyone out there working on a Control Protocol for Vines? > > -- > Scott Ginsburg Voice: 617-280-2336 > Wellfleet Communications Internet: ginsburg@wellfleet.com > 15 Crosby Drive Amateur Radio: WA2CJT > Bedford, MA 01730 > > Why, you are! I am looking forward to seeing your draft. ;^) > > Brian Lloyd, President B.P. Lloyd & Associates, Inc. > brian@lloyd.com 3420 Sudbury Road > (916) 676-1147 - voice Cameron Park, CA 95682 > (916) 676-3442 - fax Gee, I guess I could give that a whack. -- Scott Ginsburg Voice: 617-280-2336 Wellfleet Communications Internet: ginsburg@wellfleet.com 15 Crosby Drive Amateur Radio: WA2CJT Bedford, MA 01730 From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 2 09:22:36 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10314; Mon, 2 Nov 92 09:12:49 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08540; Mon, 2 Nov 92 08:41:37 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08862; Mon, 2 Nov 92 08:34:03 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [130.57.4.1] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08625; Mon, 2 Nov 92 08:28:59 -0800 Received: from la.SJF.Novell.COM by newsun.Novell.COM (4.1/SMI-4.1) id AA02077; Mon, 2 Nov 92 08:28:20 PST Received: by la.SJF.Novell.COM (4.1/SMI-4.1) id AA01048; Mon, 2 Nov 92 08:27:54 PST From: Neal_Castagnoli@Novell.COM (Neal Castagnoli) Message-Id: <9211021627.AA01048@la.SJF.Novell.COM> Subject: Re: ipxcp beneficial? To: bert@Shiva.COM (Robert D. Vincent) Date: Mon, 2 Nov 92 8:27:53 PDT Cc: cast@Novell.COM, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <9210242051.AA25527@Shiva.COM>; from "Robert D. Vincent" at Oct 24, 92 4:51 pm X-Mailer: Elm [version 2.1 alpha-test] > > Regarding your two points: > 1) IPXWAN is an entirely new, unproven protocol to us, whereas the > PPP framework is extensible and proven. In a well designed PPP > implementation a new NCP can be created in just a few lines of code. > Since all of the options in the NCP are exactly that (optional!), > there is no increased burden to developers such as Novell which do not > want to interoperate with PPP-only devices. IPXWAN is a released product, though as I stated before, I am not familiar with the IETF's requirements for proving a protocol (how can one prove something like this anyway?). > > There's so much redundancy in the information negotiated by the two > protocols that end-user configuration is a non-issue. OK. > > The IPXWAN document does not describe how IPXWAN is to be used over > all WAN media - so the claim that it will work over all of them, > unlike PPP, seems unnecessarily optimistic with respect to IPXWAN and > pessimistic with respect to PPP. I am pessimistic because standards organizations are notoriously slow to create standards. I would like to point out one thing here. Novell approached the IETF some time ago requesting that PPP operate over all WAN media. We were strongly rebuffed then when we suggested operating PPP over X.25. Hence, IPXWAN. > > 2) One-time link delay measurement is of dubious value, even with IPX, > since congestion and packet loss may affect round trip time > tremendously over the lifetime of a link. See Van Jacobsen's work on > TCP. I am familiar with Van Jacobsen's work. However, I disagree that delay is of dubious value when it's a one time measurement only. First of all, it is my understanding that some IPX applications use this value for retransmission. I think that older shells use this. Note, this is only my understanding and reality me differ (it is hard to get a definitive answer on these kinds of things). So, getting close to the real delay is valuable. I am sure, however, that delay is a metric used by IPX RIP. You may draw your own conlusions as to why distinguishing between a 9600 Baud link, a 56KB X.25 link and a T1 link is important. While imperfect, the one time timer request/response protocol has a very good chance of being able to distinguish between these three links. In this case you wouldn't want the metric to change anyway. > > In addition, IPXCP handles end-node-to-router links, something near > and dear to my heart. IPXWAN doesn't have what we need for this. This is something that needs to be put into IPXWAN. > > IPXCP is beneficial. Let's stop bickering and work with Bill's proposal. Let's examine the issues and quit bickering. > -bert I have yet to see any definitive proof that IPXCP is beneficial. There was one post from Bill I think indicating that PPP's CP is more robust with respect to dropped packets. This is the only indication that IPXCP is better in some way. I need to investigate whether this is a significant advantage. There are disadvantages to IPXCP as pointed out before. The other argument is that Novell owns IPXWAN. Now, I put it to you that it isn't clear that Novell will respond less quickly to changes requested by third parties. No one has asked Novell to add the Node ID negotiation or worstation routing type to IPXWAN, for example. Let's put it to the test. Does anyone want something like this in IPXWAN? Let's compare this to requesting the following. Can we get PPP to operate over X.25? (Illustrative only). --Neal From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 2 09:44:14 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11159; Mon, 2 Nov 92 09:33:11 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08763; Mon, 2 Nov 92 09:00:26 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09460; Mon, 2 Nov 92 08:51:28 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09079; Mon, 2 Nov 92 08:41:08 -0800 Received: from la.SJF.Novell.COM by newsun.Novell.COM (4.1/SMI-4.1) id AA02200; Mon, 2 Nov 92 08:40:26 PST Received: by la.SJF.Novell.COM (4.1/SMI-4.1) id AA01257; Mon, 2 Nov 92 08:40:01 PST From: Neal_Castagnoli@Novell.COM (Neal Castagnoli) Message-Id: <9211021640.AA01257@la.SJF.Novell.COM> Subject: Re: ipxcp beneficial? (fwd) To: ietf-ppp@ucdavis.ucdavis.edu Date: Mon, 2 Nov 92 8:40:00 PDT X-Mailer: Elm [version 2.1 alpha-test] Forwarded message: Date: Mon, 26 Oct 92 11:30:16 PDT To: bsimpson@angband.stanford.edu Subject: Re: ipxcp beneficial? In-Reply-To: <852.bill.simpson@um.cc.umich.edu>; from "William Allen Simpson" at Oct 24, 92 2:45 pm > > > From: Neal_Castagnoli@Novell.COM (Neal Castagnoli) > > Before we create a new method in which IPX can operate over wide area links > > with PPP, I would like to suggest that we consider the following. > > > These are very important questions, which is why we have already > considered them. The consensus of the group was to continue IPXcp > development. In fact, it was six or seven vendors to 1 (including > some private email of un-announced products.) Does Novell get more votes since it's IPX? :) > > When IPXcp started, there was no announced IPX-WAN. The Shiva folks > started the effort, and have a test implementation in the field. This > is considered very positive in the "Internet Way". IPXWAN is a released product, though I don't know if this qualifies for field tested. What are the requirements? Is field tested a formal definition? > > When IPX-WAN was announced, it was missing many of the features of > IPXcp. Through the efforts of the Chair, Brian Lloyd, and the > co-operation of your engineers with this working group, the IPX-WAN and > IPXcp efforts have largely converged. Again, this is the "Internet Way". I think that this also points to a larger effort underway at Novell, to open up the IPX specification. > > It is hoped that both will compete for their niches in the marketplace, > and the result will be a stronger evolution. It is the "Internet Way" > to encourage such alternatives and experimentation. I think that the result will be the following. Some vendors will implement IPXWAN. Others will implement IPXcp. These implementations won't interoperate. The result? Market confusion. I maintain that this is a direct result of the IETF's creating another way of doing things, and frankly think that this is very bad. > > > > Is the new way (IPXcp) technically superior to IPXWAN? That is, does it add > > functionality that may not reside in IPXWAN. > > > First, IPXcp is not a "new" way. From the point of view of the user > community, it is older than IPX-WAN. It is merely that the publication > of Internet Standards requires field experience, while "informational" > RFCs about proprietary products do not. So does this mean that we can make IPXWAN a formal specification? (This concerns me since we will be modifying IPXWAN [in a backwards compatible way). Can Novell then make the modifications to the specification that it will require? Novell is very interested in working with standards communities in such a way that it can open up its specifications, and meet third party requirements. However, I will point out (to the dismay of some, I am sure), that it does need some control over its protocol. > > Second, here are some things that IPXcp still does that IPX-WAN does not: > > - The periodic routing packets may be negotiated away (no routing > protocol). This is considered very useful for end-systems > (workstations), since this frees up bandwidth. Let's put the option into IPXWAN. > > - More than one header compression protocol may be fielded and tested, > since PPP allows each to have a different protocol number. In fact, > there is already one compression protocol available (Shiva again). > However, the recent cooperation between Novell and Telebit, together > with the Shiva field experience, has resulted in a much better design > (which I hope to see published soon). IPXWAN can do this. Call up Michael Allen and get a compression option number. Here is his number: (408) - 473 - 8412. That really wasn't the question, though. The question was "are there things that IPXCP may do that IPXWAN may not." I propose that the addition to include stopping the routing protocol is trivial to add to IPXWAN. > > Third, IPXcp is more robust than IPX-WAN, since: > > - The state machine ensures cleaner configuration and termination. > > - User self-configuration and overrides are better handled. > > - The peer-peer negotiation (as opposed to master-slave) allows > misconfiguration to be automatically corrected in both directions. I don't understand this, and will attempt to follow up on these issues. This by the way is the first list of any real issues that I have seen. I would like to know, though, whether or not these are substantial problems. > > > Is the new way superior in some other way to IPXWAN? > > > - It is easier to implement, since the state machine is the same for > all of the NCPs, and must be implemented in any case. I could argue also that IPXWAN needs to be implemented at least for X.25, and therefore any additional work such as IPXcp is more work. > > - It does not have a built-in WAN/LAN dichotomy, so it may be used > transparently in more situations. This is news to me. I was under the impression that PPP operated only over WANs. Or are you perhaps refering to the new Frame Relay as a LAN model? > > - It may be used with older Novell products, which do not yet have > IPX-WAN implemented, in a completely out-of-band fashion. Do you mean to say that Novell has released a PPP product before? This is news to me, and I would like to hear more about it. If you are refering to the current release of our product, then you must have IPXWAN to interoperate anyway. > > - It is the result of a wider participation of sources, who have brought > insight and implementation experience. This is not to fault your > engineers, who (IMHO) have shown themselves competent, and have added > greatly to the improvement of IPXcp through their helpful comments. I personally believe that cooperation and sharing of experiences is a great thing, though I thought that was the ISO way, and that the IETF way was more dictatorial. At least that is the way one IP "guru" explained it to me. > > > > I would also propose that IPXcp has the following problems that make it > > inferior to IPXWAN. First, IPXWAN may operate over many WAN media, including > > frame relay, ISDN, X.25, and PPP, whereas IPXcp may only operate in > > conjunction with PPP. > > Actually PPP operates over ISDN, too, and the Frame Relay folks have > come to the realization that they may need some of PPP functionality. What about X.25? When will PPP operate over Frame Relay? > > Also, there has been some feedback from the PPP WG to the IPX-WAN folks > about possible problems over partially connected meshes. I hope your > engineers have benefited from this synergy. It may be that IPX-WAN > really only operates over point-to-point links, at which time you might > as well use PPP. Partially connected meshes are simply madness. I am unaware of any protocol family that operates well over them. IP doesn't. OSI doesn't. IPX doesn't. Appletalk doesn't. In order to get partial meshes to work well, there needs to be fundamental changes to routing protocols. Partially connected meshes may be OK for protocols like IP which intrinsically have static routing requirements. They are not OK for protocols like IPX which have no static routing. Partially connected meshes for IPX are better implemented as a series of point to point connections. (And for IP too, if it weren't for the addressing requirements.) > > > Secondly, IPXWAN has functionality in it that make it > > conducive to use with IPX, in that it calculates link delay. > > We had a link delay, but folks said it wasn't needed. Perhaps there is > now sentiment to put it back in? Link delay is an intrinsic part of IPX RIP. It is IPX's routing metric. > > For example, if one of the directions in the link has a lower bandwidth, > IPXcp is capable of negotiating to the average, or to any value > acceptable to both implementations. > IPXWAN as a protocol detects slow speed in one direction and high speed in the other direction. IPXWAN doesn't currently have an override. Is one needed? > > Thirdly, IPXWAN > > operates uniformly over all WAN media types. > > > > I think that this is a generalization of your first point. You are correct. The generalization was made to point out that there are end-user considerations rather than just engineering considerations. For example, since there is only one way of doing things, end-users can trouble-shoot problems more easily. PPP doesn't operate over all WAN media types (if it did, we wouldn't have IPXWAN, but it's too late now). > > > > I would suggest that adding a second means by which wide area IPX > > connectivity may be achieved has the following disadvantages: > > > > 1) Even if two implementations can interoperate, it increases the > > chance that interoperability will not be achieved. > > > Which is why I have been adding all of those interoperability sections. > And the new Configuration-Complete option. > > As noted above, IPXcp must be implemented in any case. It is only the > Options that are optional. It still doesn't help. IPXcp competes with IPXWAN. See my comments above. Also, there is a hint here that there is additional work since IPXcp must be implemented. In our PPP implementation, at least, this wasn't the case. IPXcp came for free, since we had to implement the IP state machine. > > > 2) The amount of end-user configuration increases. > > > Since both protocols are supposed to be automatically detected, I do not > believe this to be true. > > However, as noted above, IPXcp is more sensitive to end-user > configuration than IPX-WAN. The current Novell implementation > *requires* that IPX-WAN run, even when the user has completely > hand-configured. This makes it *impossible* for Novell's product to > talk to other vendor's equipment, or even older Novell products, which > I would not list as an advantage. IPX is not IP. IP requires all kinds of hand-holding by the end-user. It is Novell's goal to eliminate this everywhere. IPXWAN removes the need to have end-user hand holding. To do this, it must run. > > > P.S. I am not on the mailing list, so please direct your comments, > > additionally, to cast@novell.com. > > > Hopefully this answers your very important questions, and your engineers > who have participated can get you the relevant archives. > > Bill.Simpson@um.cc.umich.edu > From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 2 15:35:11 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23214; Mon, 2 Nov 92 15:13:47 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11578; Mon, 2 Nov 92 12:31:36 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17251; Mon, 2 Nov 92 12:26:31 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from regal.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16512; Mon, 2 Nov 92 12:00:52 -0800 Received: by regal.cisco.com; Mon, 2 Nov 92 11:59:43 -0800 Date: Mon, 2 Nov 92 11:59:42 PST From: William "Chops" Westfield To: brian@lloyd.com (Brian Lloyd) Cc: irfan@pluto.dss.com, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: IP subnet mask along with IP address In-Reply-To: Your message of Sat, 31 Oct 92 20:17:21 PST Message-Id: While trying to create network routes automatically to the peer's network, I feel a need for the peer's subnet mask. Is anyone already working on having it as an IPCP option assoicated with or without the IP address ? There is already a fine ICMP option for getting the network data mask. BillW From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 2 18:02:28 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28643; Mon, 2 Nov 92 17:53:15 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA12662; Mon, 2 Nov 92 14:11:46 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20607; Mon, 2 Nov 92 14:02:44 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19910; Mon, 2 Nov 92 13:43:28 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA10655; Mon, 2 Nov 92 13:42:45 PST Date: Mon, 2 Nov 92 13:42:45 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9211022142.AA10655@ray.lloyd.com> To: Neal_Castagnoli@Novell.COM Cc: bert@Shiva.COM, cast@Novell.COM, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Neal Castagnoli's message of Mon, 2 Nov 92 8:27:53 PDT <9211021627.AA01048@la.SJF.Novell.COM> Subject: ipxcp beneficial? Sender: ietf-ppp-request@ucdavis.edu From: Neal_Castagnoli@Novell.COM (Neal Castagnoli) Date: Mon, 2 Nov 92 8:27:53 PDT X-Mailer: Elm [version 2.1 alpha-test] IPXWAN is a released product, though as I stated before, I am not familiar with the IETF's requirements for proving a protocol (how can one prove something like this anyway?). Rough consensus and working code. You have a big leg up on the working code part but, as far as I know, there is only one implementation: Novell's. Add that to Novell's unwillingness to propose IPXWAN as a standard and you can see why people are dragging their feet. So IPXWAN is at a disadvantage in the "rough consensus" area. I am pessimistic because standards organizations are notoriously slow to create standards. The IETF can move pretty quickly when it wants to. We can have a protocol as a proposed standard within 1-2 months of having a draft and working implementations IF (big if) there is consensus within the working group and neither the IESG nor IAB see any glaring technical errors. We can turn that into a standard in another six months after we gain experience with multiple implementations. I would like to point out one thing here. Novell approached the IETF some time ago requesting that PPP operate over all WAN media. We were strongly rebuffed then when we suggested operating PPP over X.25. Hence, IPXWAN. This is news to me. I suspect that you went to the IPLPDN WG about a year ago. They were unaware of the current work on PPP and were attempting to make decisions on the basis of essentially obsolete documents (RFC 1171 and 1172). Based on information gleaned from those documents they rejected PPP over X.25 (as would I had I had only that information). I have spoken with them since and explained the recent work (last year) on the LCP and on IPCP. There is now great interest in using the various NCPs over different WAN media including X.25 and frame relay. I recommend that you become more active in both the PPP and IPLPDN WGs. Remember that the IETF is a great vehicle for bouncing ideas off of other very knowledgeable and experienced people. I am familiar with Van Jacobsen's work. However, I disagree that delay is of dubious value when it's a one time measurement only. First of all, it is my understanding that some IPX applications use this value for retransmission. I think that older shells use this. Note, this is only my understanding and reality me differ (it is hard to get a definitive answer on these kinds of things). So, getting close to the real delay is valuable. I am sure, however, that delay is a metric used by IPX RIP. You may draw your own conlusions as to why distinguishing between a 9600 Baud link, a 56KB X.25 link and a T1 link is important. While imperfect, the one time timer request/response protocol has a very good chance of being able to distinguish between these three links. In this case you wouldn't want the metric to change anyway. Knowing the speed of the link and basing your latency estimates on that is probably going to yield better results than a one-time RTT probe. On the other hand, using link speed to estimate an initial RTT and then maintaining a running average of RTT is liable to produce significantly better results. This is how TCP works. > > IPXCP is beneficial. Let's stop bickering and work with Bill's proposal. Let's examine the issues and quit bickering. What is at issue here is the ability of people and/or companies to add functionallity to IPXCP and/or IPXWAN. With IPXCP there is a clear and well-defined mechanism for adding features and/or making changes: the IETF PPP WG. With IPXWAN the users and/or implementors perceive that they are at the whim of Novell and therefore have no direct input. Novell may or may not be responsive. The IETF is definitely responsive. > -bert I have yet to see any definitive proof that IPXCP is beneficial. There was one post from Bill I think indicating that PPP's CP is more robust with respect to dropped packets. This is the only indication that IPXCP is better in some way. I need to investigate whether this is a significant advantage. There are disadvantages to IPXCP as pointed out before. To quote Benjamin Franklin, "Of what use is a newborn baby?" Perhaps IPXWAN provides equivalent features to IPXCP. We know that IPXCP can be extended to cover new issues when they arise. The other argument is that Novell owns IPXWAN. Now, I put it to you that it isn't clear that Novell will respond less quickly to changes requested by third parties. No one has asked Novell to add the Node ID negotiation or worstation routing type to IPXWAN, for example. Let's put it to the test. Does anyone want something like this in IPXWAN? Let's compare this to requesting the following. Can we get PPP to operate over X.25? (Illustrative only). I reitterate my comment above. Come to the IETF and work with us. We welcome your participation. Brian Lloyd, President B.P. Lloyd & Associates, Inc. brian@lloyd.com 3420 Sudbury Road (916) 676-1147 - voice Cameron Park, CA 95682 (916) 676-3442 - fax From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 2 18:02:32 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28646; Mon, 2 Nov 92 17:53:22 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA12729; Mon, 2 Nov 92 14:20:31 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20757; Mon, 2 Nov 92 14:08:28 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20390; Mon, 2 Nov 92 13:57:34 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA10672; Mon, 2 Nov 92 13:54:16 PST Date: Mon, 2 Nov 92 13:54:16 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9211022154.AA10672@ray.lloyd.com> To: billw@regal.cisco.com Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: William "Chops" Westfield's message of Mon, 2 Nov 92 11:59:42 PST Subject: IP subnet mask along with IP address Date: Mon, 2 Nov 92 11:59:42 PST From: William "Chops" Westfield While trying to create network routes automatically to the peer's network, I feel a need for the peer's subnet mask. Is anyone already working on having it as an IPCP option assoicated with or without the IP address ? There is already a fine ICMP option for getting the network data mask. BillW I am aware of the ICMP subnet mask request but it does not seem to be universally implemented. I suppose that, since there is already one mechanism we probably shouldn't try to duplicate that functionallity. Good point Bill. Now how do we get the rest of the router vendors to implement it? ;^) Brian Lloyd, President B.P. Lloyd & Associates, Inc. brian@lloyd.com 3420 Sudbury Road (916) 676-1147 - voice Cameron Park, CA 95682 (916) 676-3442 - fax From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 2 18:20:56 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29214; Mon, 2 Nov 92 18:12:05 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA15321; Mon, 2 Nov 92 17:32:12 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27579; Mon, 2 Nov 92 17:23:26 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26997; Mon, 2 Nov 92 17:06:50 -0800 Received: from la.SJF.Novell.COM by newsun.Novell.COM (4.1/SMI-4.1) id AA10184; Mon, 2 Nov 92 17:06:13 PST Received: by la.SJF.Novell.COM (4.1/SMI-4.1) id AA10236; Mon, 2 Nov 92 17:05:48 PST From: Neal_Castagnoli@Novell.COM (Neal Castagnoli) Message-Id: <9211030105.AA10236@la.SJF.Novell.COM> Subject: Re: ipxcp beneficial? To: brian@lloyd.com Date: Mon, 2 Nov 92 17:05:47 PDT Cc: Neal_Castagnoli@Novell.COM, bert@Shiva.COM, cast@Novell.COM, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <9211022142.AA10655@ray.lloyd.com>; from "Brian Lloyd" at Nov 2, 92 1:42 pm X-Mailer: Elm [version 2.1 alpha-test] > Rough consensus and working code. You have a big leg up on the > working code part but, as far as I know, there is only one > implementation: Novell's. Add that to Novell's unwillingness to > propose IPXWAN as a standard and you can see why people are dragging > their feet. So IPXWAN is at a disadvantage in the "rough consensus" > area. Well, I wouldn't call it unwillingness. We do have the problem that we are doing significant research and enhancements to IPXWAN. How can we cooperate with the IETF so that third parties have the comfort that they will get what they need, and so that we can enhance the protocol as we need? > > I am pessimistic because standards organizations are notoriously slow to > create standards. > > The IETF can move pretty quickly when it wants to. We can have a > protocol as a proposed standard within 1-2 months of having a draft > and working implementations IF (big if) there is consensus within the > working group and neither the IESG nor IAB see any glaring technical > errors. We can turn that into a standard in another six months after > we gain experience with multiple implementations. That is certainly faster than some organizations. However, I still am skeptical about the IETF's ability to coordinate between multiple IETF groups. Ownership and all that. > > I would like to point out one thing here. Novell approached the IETF some > time ago requesting that PPP operate over all WAN media. We were strongly > rebuffed then when we suggested operating PPP over X.25. Hence, IPXWAN. > > This is news to me. I suspect that you went to the IPLPDN WG about a > year ago. They were unaware of the current work on PPP and were > attempting to make decisions on the basis of essentially obsolete > documents (RFC 1171 and 1172). Based on information gleaned from > those documents they rejected PPP over X.25 (as would I had I had only > that information). I have spoken with them since and explained the > recent work (last year) on the LCP and on IPCP. There is now great > interest in using the various NCPs over different WAN media including > X.25 and frame relay. That was last year, though. Now we are at least two years away from a solution; we were able to release IPXWAN this year. > > I recommend that you become more active in both the PPP and IPLPDN > WGs. Remember that the IETF is a great vehicle for bouncing ideas off > of other very knowledgeable and experienced people. Like I said, we did attempt to get PPP operative over X.25. I do appreciate your point about bouncing ideas off of knowledgeable people, though there is a risk there. > > Knowing the speed of the link and basing your latency estimates on > that is probably going to yield better results than a one-time RTT > probe. On the other hand, using link speed to estimate an initial RTT > and then maintaining a running average of RTT is liable to produce > significantly better results. This is how TCP works. For transport layers this is fine. It isn't fine for network layers to change routes based on fluctuating RTT. Now, you can't change IPX's use of delay as a metric. So, you need to have a value and stick with it. New IPX shells calculate RTT, which are the equivalent to a transport layer, so your point isn't really that important. What is important is the IPX shell's use of initial RTT values for timing out an unreachable connection. > > > > > IPXCP is beneficial. Let's stop bickering and work with Bill's proposal. > > Let's examine the issues and quit bickering. > > What is at issue here is the ability of people and/or companies to add > functionallity to IPXCP and/or IPXWAN. With IPXCP there is a clear > and well-defined mechanism for adding features and/or making changes: > the IETF PPP WG. With IPXWAN the users and/or implementors perceive > that they are at the whim of Novell and therefore have no direct > input. Novell may or may not be responsive. The IETF is definitely > responsive. From what you have said, the IETF will be responsive provided that there is a consensus. If you operate only with Novell, the need for consensus is reduced, though this does have its own peril. I do understand though the inherent problem you are suggesting. Any ideas as to how to fix it? > > > -bert > > I have yet to see any definitive proof that IPXCP is beneficial. There was > one post from Bill I think indicating that PPP's CP is more robust with > respect to dropped packets. This is the only indication that IPXCP is > better in some way. I need to investigate whether this is a significant > advantage. There are disadvantages to IPXCP as pointed out before. > > To quote Benjamin Franklin, "Of what use is a newborn baby?" Perhaps > IPXWAN provides equivalent features to IPXCP. We know that IPXCP can > be extended to cover new issues when they arise. I still don't think that this has been demonstrated. I don't think that IPXCP has been shown to operate over *any* WAN media. In fact, I am unaware of PPP operating over any media other than unsequenced HDLC. IPXWAN at least has operated over unsequenced HDLC alla PPP, and also over X.25 and . . . > > The other argument is that Novell owns IPXWAN. Now, I put it to you that it > isn't clear that Novell will respond less quickly to changes requested by > third parties. No one has asked Novell to add the Node ID negotiation or > worstation routing type to IPXWAN, for example. Let's put it to the test. > Does anyone want something like this in IPXWAN? Let's compare this to > requesting the following. Can we get PPP to operate over X.25? > (Illustrative only). > > I reitterate my comment above. > > Come to the IETF and work with us. We welcome your participation. If only there were time enough. Thanks for the suggestion, maybe I will take you up on it. > Brian Lloyd, President B.P. Lloyd & Associates, Inc. > brian@lloyd.com 3420 Sudbury Road > (916) 676-1147 - voice Cameron Park, CA 95682 > (916) 676-3442 - fax > --Neal From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 2 21:30:47 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05932; Mon, 2 Nov 92 21:25:11 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA16972; Mon, 2 Nov 92 21:00:17 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04913; Mon, 2 Nov 92 20:51:35 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from CAYMAN.CAYMAN.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04768; Mon, 2 Nov 92 20:45:34 -0800 Received: by cayman.Cayman.COM (4.1/SMI-4.0) id AA20512; Mon, 2 Nov 92 23:45:23 EST Received: from stemwinder by stemwinder.fcr.com (4.1/SMI-4.1) id AA20422; Mon, 2 Nov 92 23:36:40 EST Message-Id: <9211030436.AA20422@stemwinder.fcr.com> To: sgw@sgw.xyplex.com (Scott Wasson) Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: ATCP In-Reply-To: Mail from sgw@sgw.xyplex.com (Scott Wasson) dated Thu, 29 Oct 92 16:03:24 EST <9210292103.AA02559@sgw.xyplex.com> Date: Mon, 02 Nov 92 23:36:40 EST From: Brad Parker >> >From talking with a few of our Appletalk engineers, we thought it would be >> very useful to have a 'router type' option in ATCP, with the values: >> >> 0: half router, default (most people seem to be doing half routing) >> 1: seed full router >> 2: non-seed full router >> >> This would enable implementations to negotiate what kind of router they intend >> to be, and help prevent two problems: >> 1) a non-seed router can't talk with another non-seed router unless address >> negotiation is done, because rtmp won't be any help. yes, well. if you're a good non-seed port, you won't send an rtmp until you seed (perhaps that's what you ment). Well, you should nak the ppp config request if it has no address info in it and supply one in the nak, even if it's wrong/bogus, thereby prompting the other side to give you one that it likes (if it can). If the other side is in the same state that you are in, the link will not come up, since neither side will ever see a config request that is acceptable. >> 2) A half-router can't talk with a full router. Perhaps the half-router >> could be smart enough to become a full-router, or visa-versa. well, if you're a half router you would reject (Configure-Reject) any config request *with* an address. You would also send a config request *without* an address. A good implementation would notice that you rejected the address and (if configured to allow this) switch to be a half router. An obstinant implementation (by design or configuration) would just continue to reject and the link would not come up. Neither of these conditions seem hard to detect, so you should be able to leave a coherent log message for the admin which explains why the link would not come up. (which is one of the things I like best about PPP!) To quote: (if this does not make sense, please send more mail) ... A network or node number specified as zero in a Configure-Request shall be interpreted as requesting the remote end to specify a value via a Configure-Nak. A network or node number specified as zero in a Configure-Ack shall be interpreted as agreement that no value exists. An implementation which requires that no AppleTalk addresses be assigned (such as a intermediate system to intermediate system "half-routing") MUST Configure-Reject all AppleTalk-Address Configuration Options. An implementation which requires that AppleTalk addresses be assigned to it (such as a end system) MUST fail configuration if the remote side Configure-Rejects all AppleTalk-Address requests, or fails to provide a valid value. -brad From ietf-ppp-request@ucdavis.ucdavis.edu Tue Nov 3 10:35:44 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20764; Tue, 3 Nov 92 10:19:11 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA21383; Tue, 3 Nov 92 08:45:23 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18452; Tue, 3 Nov 92 08:38:14 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18157; Tue, 3 Nov 92 08:25:43 -0800 Received: by volitans.morningstar.com (5.65a/92042102) id AA23972; Tue, 3 Nov 92 11:24:59 -0500 Date: Tue, 3 Nov 92 11:24:59 -0500 From: Bob Sutterfield Message-Id: <9211031624.AA23972@volitans.morningstar.com> To: brian@lloyd.com (Brian Lloyd), irfan@pluto.dss.com, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: brian@lloyd.com's message of Sat, 31 Oct 92 20:17:21 PST Subject: IP subnet mask along with IP address Date: Sat, 31 Oct 92 20:17:21 PST From: brian@lloyd.com (Brian Lloyd) Date: Fri, 30 Oct 92 15:47:13 EST From: irfan@pluto.dss.com (Syed Mohammad Irfan Ashraf) While trying to create network routes automatically to the peer's network, I feel a need for the peer's subnet mask. Is anyone already working on having it as an IPCP option assoicated with or without the IP address ? If you have a network on the other side of a router at the remote end of the link your routing protocol should pass you that information rather than PPP. (What? You aren't running OSPF, RIP-II, or BGP?) Some PPP-speakers are built on systems where where one can't count on the user having access to *any* routing topology distribution protocol, let alone one of the useful ones you describe. And (hard as it may be to believe :-) some systems even still ship with broken implementations of RIP Classic. BSD (at least 4.3BSD) IP interfaces contain only one network mask field. With our PPP software, it defaults to a value appropriate for the class of the address of the local end of the PPP link. In a discussion with the author of a very capable UNIX-based routing topology distribution protocol daemon (gated), it turned out that he was indifferent as to whether it should be defaulted according to the class of the local end or the class or the remote end. The counter to this argument is that some routers do not support host routes and that a subnet mask may be required (seems to me that the router should be fixed to support host routes). We with host-based (not standalone router-based) PPP implementations are saddled with the limitations of the host's IP. The host may not even support the ICMP subnet mask request. That overlying host software is not fixable by the PPP implementation. I am personally uneasy about changing IPCP yet again. Comments on how to do this without breaking existing implemntations? Other comments pro or con? Adding an IPCP Configuration Option 4 (IP-Network-Mask) wouldn't break anything except the layout of our Quick Reference Card, and it might help a few users. It would look like this: A summary of the IP-Network-Mask Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | IP-Network-Mask +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP-Network-Mask (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 4 Length 6 IP-Network-Mask The four octet IP-Network-Mask is the desired local network mask of the sender of a Configure-Request. If all four octets are set to zero, it indicates a request that the peer provide the IP-Network-Mask information. Default The IP Network Mask should be set to a default value appropriate for the class of the corresponding IP Address. A Class-A address should default to a Network Mask of 0xff000000, a Class-B address should default to a Network Mask of 0xffff0000, and a Class-C address should default to a Network Mask of 0xffffff00. Note: A peer's network mask should be considered informative, and an implementation can do anything it likes with it, including silently discarding it. From ietf-ppp-request@ucdavis.ucdavis.edu Tue Nov 3 11:02:53 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21595; Tue, 3 Nov 92 10:51:09 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA21931; Tue, 3 Nov 92 09:20:30 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19109; Tue, 3 Nov 92 09:11:02 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from FENNEL.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18981; Tue, 3 Nov 92 09:03:33 -0800 Received: by fennel.acc.com (4.1/SMI-4.1) id AA01165; Tue, 3 Nov 92 09:00:31 PST Date: Tue, 3 Nov 92 09:00:31 PST From: fbaker@acc.com (Fred Baker) Message-Id: <9211031700.AA01165@fennel.acc.com> To: brian@lloyd.com Subject: Re: IP subnet mask along with IP address Cc: billw@regal.cisco.com, ietf-ppp@ucdavis.ucdavis.edu >> I am aware of the ICMP subnet mask request but it does not seem to be >> universally implemented. I suppose that, since there is already one >> mechanism we probably shouldn't try to duplicate that functionallity. >> Good point Bill. >> Now how do we get the rest of the router vendors to implement it? ;^) Seems like the simplest way is to point out to your favorite vendor that RFC 1360 (IAB official protocol standards) lists RFC 950 (Internet standard subnetting procedure, of which this is Appendices I and IV) implementation as 'required'. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Tue Nov 3 15:51:36 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03249; Tue, 3 Nov 92 15:23:08 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA25688; Tue, 3 Nov 92 14:32:30 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01021; Tue, 3 Nov 92 14:29:37 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from xap.xyplex.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00234; Tue, 3 Nov 92 14:10:25 -0800 Received: from sgw.xyplex.com by xap.xyplex.com id ; Tue, 3 Nov 92 18:07:06 -0500 Received: by sgw.xyplex.com (4.1/SMI-4.1) id AA08133; Tue, 3 Nov 92 17:12:10 EST Date: Tue, 3 Nov 92 17:12:10 EST From: sgw@sgw.xyplex.com (Scott Wasson) Message-Id: <9211032212.AA08133@sgw.xyplex.com> To: brad@fcr.com Subject: Re: ATCP Cc: ietf-ppp@ucdavis.ucdavis.edu I think we should make it clear in the spec that half-routers MUST NOT have address negotiation in Config Requests, and MUST Config-Reject the option as well. Furthermore, seed/non-seed routers MUST have address negotiation. This functionality is REQUIRED in order for the cases I have outlined below to work. Here are all the cases I think we need to address: 1) seed to seed Seed routers MUST negotiate a valid non-zero address, which will be either Ack'ed if it's in the partner's range, or Nak'ed. If Ack'ed, we're done. If Nak'ed, then we may get into the situation where the address ranges are incompatible. Then an ATCP Config-Nak will be sent N times (default 10) before the Nak turns into a Config-Reject. At this point both routers could/should become half-routers since a Config-Reject can be interpreted as an indication that our partner is a half-router. 2) seed to non-seed Seed routers MUST negotiate a valid non-zero address, which will be Ack'ed by the non-seed. 3) non-seed to seed Non-seed routers MUST negotiate a zero address, which will be Nak'ed with an appropriate value by the seed router. 4) non-seed to non-seed Non-seed routers MUST negotiate a zero address, which will be Ack'ed by the other non-seed router. At this point both routers could/should become half-routers. 5) seed to half Seed routers MUST negotiate a valid non-zero address, which will be Config-Rejected by the half-router. At this point the seed router could/should become a half-router. 6) non-seed to half Seed routers MUST negotiate a zero address, which will be Config-Rejected by the half-router. At this point the non-seed router could/should become a half-router. 7) half to seed A Half router MUST NOT negotiate an address in the Config-Request. Furthermore the seed router could/should become a half-router when the address option in its Config-Request is Config-Rejected. 8) half to non-seed A Half router MUST NOT negotiate an address in the Config-Request. Furthermore the non-seed router could/should become a half-router when the address option in its Config-Request is Config-Rejected. 9) half to half A Half router MUST NOT negotiate an address in the Config-Request. The other half-router will Ack the Config-Request. -----Scott Wasson------ Internetworking & Media Xyplex Boxborough, MA (508) 264-9901 x369 sgwasson@eng.xyplex.com ----------------------- From ietf-ppp-request@ucdavis.ucdavis.edu Tue Nov 3 16:05:22 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04125; Tue, 3 Nov 92 15:45:05 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA26334; Tue, 3 Nov 92 15:21:19 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02821; Tue, 3 Nov 92 15:13:28 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from hp.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02384; Tue, 3 Nov 92 15:02:51 -0800 Received: from hprdash.rose.hp.com by hp.com with SMTP (16.8/15.5+IOS 3.13) id AA14365; Tue, 3 Nov 92 15:02:13 -0800 Received: from by hprdash.rose.hp.com with SMTP (16.6/15.5+IOS 3.21+OM) id AA16825; Tue, 3 Nov 92 15:02:10 -0800 Date: Tue, 3 Nov 92 15:02:10 -0800 From: CONGDON_PAUL/HP5200_15@hprdash.rose.hp.com Message-Id: <9211032302.AA16825@hprdash.rose.hp.com> Subject: PPP Async Controller X-Openmail-Hops: 1 To: ietf-ppp@ucdavis.ucdavis.edu Dear Developers, I apologize for posting this request to your working group reflector. I realize that you are doing real work here and that this is not the place to post this type of request, BUT, I posted this to comp.protocols.ppp over 2 weeks ago without a single response. I'm sure some of you know something about this or would like to... Thanks in advance, Paul ....................................................................... Item Subject: Async PPP Controller / hprnd:comp.protocols.ppp / ptc@hprnd.rose.hp.com (Paul Congdon) / 12:34 pm O ct 21, 1992 / Is anyone looking at building an async PPP controller. Similar to the sync HDLC controllers (e.g. SCC, DUSC, etc.). Something that would perform the byte level framing and transparency. As it stands today, you have to look at every character as it comes off the UART to determine start and end of packet... Paul ---------- +--------------------------------------+--------------------------------+ + Paul Congdon + Member of Technical Staff + + Hewlett Packard Company + Mail Stop: R3NF2 + + Personal Information Products Group + 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 Nov 4 20:40:58 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14649; Wed, 4 Nov 92 20:36:28 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11356; Wed, 4 Nov 92 20:10:57 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13855; Wed, 4 Nov 92 20:03:13 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from CAYMAN.CAYMAN.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13587; Wed, 4 Nov 92 19:45:19 -0800 Received: by cayman.Cayman.COM (4.1/SMI-4.0) id AA23075; Wed, 4 Nov 92 22:45:14 EST Received: from stemwinder by stemwinder.fcr.com (4.1/SMI-4.1) id AA26644; Wed, 4 Nov 92 22:13:00 EST Message-Id: <9211050313.AA26644@stemwinder.fcr.com> To: irfan@pluto.dss.com (Syed Mohammad Irfan Ashraf) Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: IP subnet mask along with IP address In-Reply-To: Mail from irfan@pluto.dss.com (Syed Mohammad Irfan Ashraf) dated Fri, 30 Oct 92 18:38:18 EST <9210302338.AA00403@pluto.dss.com> Date: Wed, 04 Nov 92 22:12:59 EST From: Brad Parker >> >> let's see what others have to add to it. >> This is why God invented OSPF. (well, maybe he invented John Moy first ;-) (you asked!) Personally, I'd do RIP V2 or OSPF over the link before I "fixed" PPP. But then, I'm a link state kind-a-guy. -brad From ietf-ppp-request@ucdavis.ucdavis.edu Thu Nov 5 06:14:38 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06042; Thu, 5 Nov 92 06:02:19 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA13507; Thu, 5 Nov 92 05:40:14 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04526; Thu, 5 Nov 92 05:30:57 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Sun.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04377; Thu, 5 Nov 92 05:29:39 -0800 Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA15154; Thu, 5 Nov 92 05:26:15 PST Received: from East.Sun.COM by snail.Sun.COM (4.1/SMI-4.1) id AA27863; Thu, 5 Nov 92 05:26:11 PST Received: from suneast.East.Sun.COM (suneast-gw) by East.Sun.COM (4.1/SMI-4.1) id AA16099; Thu, 5 Nov 92 08:26:09 EST Received: from tyger.East.Sun.COM by suneast.East.Sun.COM (4.1/SMI-4.1) id AA01950; Thu, 5 Nov 92 08:25:53 EST Received: by tyger.East.Sun.COM (4.1/SMI-4.1) id AA01491; Thu, 5 Nov 92 08:25:33 EST Date: Thu, 5 Nov 92 08:25:33 EST From: Geoff.Arnold@East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) Message-Id: <9211051325.AA01491@tyger.East.Sun.COM> To: irfan@pluto.dss.com, brad@fcr.com Subject: Re: IP subnet mask along with IP address Cc: ietf-ppp@ucdavis.ucdavis.edu >> From ietf-ppp-request@ucdavis.edu Thu Nov 5 00:03:06 1992 >> To: irfan@pluto.dss.com (Syed Mohammad Irfan Ashraf) >> Cc: ietf-ppp@ucdavis.edu >> Subject: Re: IP subnet mask along with IP address >> Date: Wed, 04 Nov 92 22:12:59 EST >> From: Brad Parker >> >> >> >> >> let's see what others have to add to it. >> >> >> >> This is why God invented OSPF. (well, maybe he invented John Moy first ;-) >> >> (you asked!) >> >> Personally, I'd do RIP V2 or OSPF over the link before I "fixed" PPP. Or DHCP....? From ietf-ppp-request@ucdavis.ucdavis.edu Fri Nov 6 18:02:52 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29628; Fri, 6 Nov 92 17:58:44 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11031; Fri, 6 Nov 92 17:10:47 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27430; Fri, 6 Nov 92 16:55:38 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27192; Fri, 6 Nov 92 16:47:08 -0800 Received: from napa.TELEBIT.COM by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-Brent-920708) id AA16514 to ietf-ppp@ucdavis.edu; Fri, 6 Nov 92 16:46:03 PST Received: from yoyo.telebit.com by napa.TELEBIT.COM (4.1/napa.telebit.com-Brent-920717) id AA20789 to ietf-ppp@ucdavis.edu; Fri, 6 Nov 92 17:46:01 PPE Date: Fri, 6 Nov 92 17:46:01 PPE From: mlewis@napa.Telebit.COM (Mark S. Lewis) Message-Id: <9211070046.AA20789@napa.TELEBIT.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA25998; Fri, 6 Nov 92 16:46:40 PST To: bill.simpson@um.cc.umich.edu Cc: ietf-ppp@ucdavis.ucdavis.edu, mathur@napa.Telebit.COM In-Reply-To: <792.bill.simpson@um.cc.umich.edu> Subject: IPXCP & Telebit Compression For the IPXCP draft, this looks pretty ok. However, we have decided to drop the length option. Please remove option bit 2 below. The length field will be supported on a packet by packet basis, indicated by a bit in the compressed packet option octet. That leaves only the option to compress the slot identifier. ... Mark =========----------- Mark S. Lewis -----------========== inet: mlewis@telebit.com Telebit Corp. Telebit (408) 745-3232 uucp: uunet!telebit!mlewis Fax (408) 745-3810 --------------------------- Reference Inclusion --------------------- 4.1. Configuration Option Format A summary of the IPX-Compression-Protocol Configuration Option format to negotiate Telebit IPX header compression is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | IPX-Compression-Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max-Slot-Id | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 3 Length 6 IPX-Compression-Protocol 0002 (hex) for Telebit Compressed IPX headers. Max-Slot-Id The Max-Slot-Id field is one octet and indicates the maximum slot identifier. This is one less than the actual number of slots; the slot identifier has values from zero to Max-Slot-Id. Simpson expires in six months [Page 16] DRAFT PPP IPXCP October 1992 Options The Options field is one octet, and is comprised of the "logical or" of the following values: 0 No options. 1 The slot identifer may be compressed. The slot identifier must not be compressed if there is no ability for the PPP link level to indicate an error in reception to the decompression module. Synchronization after errors depends on receiving a packet with the slot identifier. 2 A length field must be included. The length field MUST be included if there is no ability for the PPP link level to determine the amount of padding. It SHOULD NOT be included when there is no padding on the link, or the Self-Describing-Pad Configuration Option has been negotiated. From ietf-ppp-request@ucdavis.ucdavis.edu Fri Nov 6 18:24:38 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00403; Fri, 6 Nov 92 18:15:46 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11739; Fri, 6 Nov 92 17:50:24 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29054; Fri, 6 Nov 92 17:41:05 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28921; Fri, 6 Nov 92 17:35:42 -0800 Received: from napa.TELEBIT.COM by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-Brent-920708) id AA17535 to ietf-ppp@ucdavis.edu; Fri, 6 Nov 92 17:34:59 PST Received: from yoyo.telebit.com by napa.TELEBIT.COM (4.1/napa.telebit.com-Brent-920717) id AA22392 to ietf-ppp@ucdavis.edu; Fri, 6 Nov 92 18:34:56 PPE Date: Fri, 6 Nov 92 18:34:56 PPE From: mlewis@napa.Telebit.COM (Mark S. Lewis) Message-Id: <9211070134.AA22392@napa.TELEBIT.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA26071; Fri, 6 Nov 92 17:35:35 PST To: bill.simpson@um.cc.umich.edu Cc: ietf-ppp@ucdavis.ucdavis.edu, mathur@napa.Telebit.COM, ms@napa.Telebit.COM In-Reply-To: <792.bill.simpson@um.cc.umich.edu> Subject: IPXCP-Configuration-Complete We have implemented this option for testing. We have implemented both IPXCP and IPXWAN. In addition to the config complete option, we provide a manual control which enables and disables IPXWAN. Taking the point of view of an IPXCP and IPXWAN capable peer, there are a number of cases to consider. Since you cannot rely on everyone implenting this option, there are the complications of IPXCP with and without the config complete option. (Assume we always try IPXCP first with the option specified.) 1. IPXCP only (without IPXCP-Configuration-Complete) This option doesn't help here. The option get rejected and we haven't learned anything about the other end. We try IPXCP first then IPXWAN, if it is enabled. 2. IPXCP only (with IPXCP-Configuration-Complete) This option helps here. When we have successfully negotiated this option, we know we are done. No need to do any IPXWAN, regardless of its manual configuration. This way we avoid the timeouts associated with IPXWAN and we can bring the link up earlier. 3. IPXWAN only This option doesn't help here. We try IPXCP first, but everything but a null request get rejected. We then do IPXWAN, if it is enabled. 4. IPXWAN and IPXCP (without IPXCP-Configuration-Complete) The option doesn't help here, since it gets rejected. 5. IPXWAN and IPXCP (with IPXCP-Configuration-Complete) The option helps here. Once the complete option is negotiated, we can ignore IPXWAN. Again the link is brought up faster. THE BOTTOM LINE This option helps in a couple of cases. In cases 2 & 5, the line is brought up faster. In case 5, the user will have added flexibility to configure the peer with the optimal mechanism. Given that we cannot rely on the implementation of this option, we decided to provide a manual control. This let's us avoid the timeouts of IPXWAN talking to IPXCP only implementations without the option. In our implementation, we do IPXWAN only if we didn't successfully negotiate the config complete options AND we manually enabled IPXWAN for the interface. ... Mark =========----------- Mark S. Lewis -----------========== inet: mlewis@telebit.com Telebit Corp. Telebit (408) 745-3232 uucp: uunet!telebit!mlewis Fax (408) 745-3810 From ietf-ppp-request@ucdavis.ucdavis.edu Sun Nov 8 15:41:02 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24347; Sun, 8 Nov 92 15:36:33 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA20947; Sun, 8 Nov 92 15:20:11 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23436; Sun, 8 Nov 92 15:10:49 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23297; Sun, 8 Nov 92 15:06:21 -0800 Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA22812; Sun, 8 Nov 92 15:00:31 -0800 Date: Sat, 7 Nov 92 19:11:27 EDT From: "William Allen Simpson" Message-Id: <881.bill.simpson@um.cc.umich.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: IPXCP-Configuration-Complete > We have implemented this option for testing. We have implemented both > IPXCP and IPXWAN. In addition to the config complete option, we > provide a manual control which enables and disables IPXWAN. > Thanks Mark for the report. I will edit the results into some implementation notes in the spec. How did you handle the link delay that the Novell folks have been talking about? - Do we need another option to dynamically negotiate it? - Or do we just determine it from the link speed? - Does it have to be symmetric? Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 9 12:11:29 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03747; Mon, 9 Nov 92 11:51:18 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27235; Mon, 9 Nov 92 11:24:57 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02971; Mon, 9 Nov 92 11:12:56 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ns.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01678; Mon, 9 Nov 92 10:13:13 -0800 Received: by ns.Novell.COM (4.1/SMI-4.1) id AA00690; Mon, 9 Nov 92 11:12:10 MST Received: by MHS.Novell.COM id B99EFE2A81F901D0; Mon, 09 Nov 92 11:12:09 MST Return-Path: Precedence: first-class X-Date-Posted: 9-Nov-92 9:21:43 X-Smf-Version: 70 To: ietf-ppp@ucdavis.ucdavis.edu Message-Id: Subject: Re: IPXCP & link delay From: Michael_Allen@Novell.COM (Allen, Michael) Date: Mon, 09 Nov 92 09:19:51 MST X-In-Reply-To: 3345FD2A81F401D0 X-Conversation-Id: 3345FD2A02F401D0 Total-To: ietf-ppp@ucdavis.edu X-Original-To: sjf-smtp"ietf-ppp@ucdavis.edu":x O-Dvs-Trailtype: 0,1 O-Dvs-Trailaddr: billsimp @ INETGATE ("William Allen Simpson") {bill.simpson@um.cc.umich.edu},MALLEN O-Dvs-Traildate: 7-Nov-92 23:11:00, 9-Nov-92 09:19:51 O-Dvs-Wrapinfo: 06,07,4A,5A,95,C9,EB,EC,0118,0119,0163,01AA,01DF,01E0,0227,026C,02B0,02EF,02F0,0333,0360,0361,03A8,03EA,03F4,03F5,0404 X-Via-Host: ETEMP.novell Bill, >How did you handle the link delay that the Novell folks have been >talking about? > - Do we need another option to dynamically negotiate it? > - Or do we just determine it from the link speed? > - Does it have to be symmetric? If you do add the option - a few notes..... Link speed is not enough. The delay calculated needs to take into account possible satellite delays as well as the bits/sec speed. This is what IPXWAN achieves - albeit on a possibly unladen link. The delays at each end need to be symmetric otherwise the link is seen differently at each end. This was the reasoning behind IPXWAN having ONE end of the link calculate the delay and inform the other end in the information packets following the Timer Request/Reponses. When parallel links occur in a topology, different delays in each direction can cause unpredictable behaviour. Note: The IPXWAN algorithm also multiplies the measured delay by 6 to reduce the number of workstation Abort/Retries with several laden sessions. Michael Allen, Novell Inc. (mallen@novell.com) From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 9 14:36:40 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07477; Mon, 9 Nov 92 14:22:14 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA28767; Mon, 9 Nov 92 13:50:44 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06638; Mon, 9 Nov 92 13:43:33 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ns.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06485; Mon, 9 Nov 92 13:33:42 -0800 Received: by ns.Novell.COM (4.1/SMI-4.1) id AA06660; Mon, 9 Nov 92 14:32:57 MST Received: by MHS.Novell.COM id 79C6FE2A81F901D0; Mon, 09 Nov 92 14:32:56 MST Return-Path: Precedence: first-class X-Date-Posted: 9-Nov-92 12:24:54 X-Smf-Version: 70 To: ietf-ppp@ucdavis.ucdavis.edu Message-Id: <80C6FE2A01F901D0@MHS.Novell.COM> Subject: IPXCP Unbalanced RIP Metrics From: Michael_Allen@Novell.COM (Allen, Michael) Date: Mon, 09 Nov 92 12:22:36 MST X-Conversation-Id: 80C6FE2A02F901D0 Total-To: ietf-ppp@ucdavis.edu X-Original-To: sjf-smtp"ietf-ppp@ucdavis.edu":x O-Dvs-Trailtype: 0 O-Dvs-Trailaddr: MALLEN O-Dvs-Traildate: 9-Nov-92 12:22:35 O-Dvs-Wrapinfo: 2D,2E,2F,63,97,CB,F9,0127,0168,01A9,01EA,0218,0246,027A,02AE,02E2,02E3,030D,030E,034C,038D,03CB,0409,0416,0417,045B,049F,04E2,0526,056A,058E,058F,05D0,05D1,0613,0657,0661,0662,0671 X-Via-Host: ETEMP.novell A reason why unbalanced link delays are bad: +----------+ <- Cost=12 +----------+ | System A |----------/_________| System B | +----------+ ->Cost=6 +----------+ | | | | LAN | | LAN +-------+ | +----------| W/S 1 | Cost=1 | | Cost=1 +-------+ | | | | +----------+ ->Cost=12 +----------+ | System C |----------/_________| System D | +----------+ <-Cost=6 +----------+ Systems A->D are NetWare servers/routers. Consider a Workstation (W/S 1) talking to the file system on System A. To get to System A, the packet will traverse Systems D and C as a GetRouteRequest would find that path faster - even though there is an extra "hop" and the lines are actually the same speed. NetWare assumes that if a packet arrives from a router from an end node, the return path should be through the same router. This will cause the response packet from System B to be sent back to System C to be routed. System C will do a route lookup & send it straight back to A. System A will then route the packet directly to B before the packet reaches the workstation. The packet has now taken 2 extra hops for its return journey!!! If this was a larger topology with WAN connections between A & C, this could be an expensive method of sending data on packet charged networks. Michael Allen, Novell Inc. (mallen@novell.com) From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 9 15:41:29 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08848; Mon, 9 Nov 92 15:30:25 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA29983; Mon, 9 Nov 92 15:10:29 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08388; Mon, 9 Nov 92 15:03:22 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08244; Mon, 9 Nov 92 14:59:18 -0800 Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA24519; Mon, 9 Nov 92 14:58:12 -0800 Date: Mon, 9 Nov 92 15:47:28 EDT From: "William Allen Simpson" Message-Id: <890.bill.simpson@um.cc.umich.edu> To: ietf-ppp@ucdavis.ucdavis.edu Cc: internet-drafts@nri.reston.va.us Subject: pppext-lcpext He looks up -- gasps -- "IETF is next week?" Please take a look at the latest lcpext draft, at: angband.stanford.edu:pub/ppp/nr/lcpext.txt (It's in the nroff directory because Brian broke my access to the ppp directory sometime in the past couple of weeks.) Differences from what I posted to the list (over 2 months ago, how time flies): - Connect-Time was moved from a Configuration Option to a LCP packet in its own right. This avoids reconfiguration in the middle of sessions. - the various comments/requests are included, or explained away in implementation notes. - all of the elements are there for different FCS or pads for different packets. I think I covered all of the bases, but its more difficult than any other kind of negotiation. - FCS-32 table was supplied by Karl Fox (BIG ROUND OF APPLAUSE). Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 9 18:52:42 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16388; Mon, 9 Nov 92 18:49:13 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA02382; Mon, 9 Nov 92 18:31:13 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15584; Mon, 9 Nov 92 18:24:20 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14919; Mon, 9 Nov 92 18:02:21 -0800 Received: from crappie.morningstar.com by volitans.morningstar.com (5.65a/92042102) id AA17395; Mon, 9 Nov 92 21:01:24 -0500 From: Karl Fox Received: by crappie.morningstar.com (5.65a/910712902) id AA02481; Mon, 9 Nov 92 21:00:53 -0500 Date: Mon, 9 Nov 92 21:00:53 -0500 Message-Id: <9211100200.AA02481@crappie.morningstar.com> To: Michael_Allen@Novell.COM (Allen, Michael) Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: IPXCP Unbalanced RIP Metrics References: <80C6FE2A01F901D0@MHS.Novell.COM> Organization: Morning Star Technologies, Inc. Allen, Michael writes: > A reason why unbalanced link delays are bad: > > > +----------+ <- Cost=12 +----------+ > | System A |----------/_________| System B | > +----------+ ->Cost=6 +----------+ > | | > | | > LAN | | LAN +-------+ > | +----------| W/S 1 | > Cost=1 | | Cost=1 +-------+ > | | > | | > +----------+ ->Cost=12 +----------+ > | System C |----------/_________| System D | > +----------+ <-Cost=6 +----------+ > > Systems A->D are NetWare servers/routers. > > Consider a Workstation (W/S 1) talking to the file system on > System A. To get to System A, the packet will traverse Systems D > and C as a GetRouteRequest would find that path faster - even > though there is an extra "hop" and the lines are actually the > same speed. And this is as it should be. The hop costs indicate that it is better (cheaper, faster, or whatever) to go W/S 1 -> D -> C -> A than W/S 1 -> B -> A. > NetWare assumes that if a packet arrives from a router from an end > node, the return path should be through the same router. Ah, now I understand your complaint. Although most will surely consider such a policy a shortcoming, it shouldn't hurt that much in practice. And it doesn't matter much which choice you make, as your traffic will always be suboptimal in at least one direction when the costs are as in the above diagram. > This will cause the response packet from System B to be sent back to > System C to be routed. System C will do a route lookup & send it > straight back to A. System A will then route the packet directly to B > before the packet reaches the workstation. > > The packet has now taken 2 extra hops for its return journey!!! I don't understand the above explanation. If the original packet went *to* System A, wouldn't the response packet then come *from* System A? If System A then sends it back the way it came, then it will send it to C, then D, then to W/S 1. If it instead sends it back the shortest way, it will go to B, then to W/S 1. Wouldn't the worst case be when it follows the return path rather than the shortest path? > If this was a larger topology with WAN connections between A & C, > this could be an expensive method of sending data on packet charged > networks. If your routing technology looked like OSPF, then you would send the request from W/S 1 to D to C to A, and the response would go from A to B to W/S 1. You'd always use the best possible path, regardless of the topology. Shortest path *is* the best way, even if it means you take more hops. If the costs are based on delay, then it will even get there quicker. Two hops over dedicated 38400 bps lines will usually be quicker than a single hop over a compressing V.32bis/V.42/V.42bis 38400 bps link, because the dedicated lines will have about 25ms delay each and the V.42bis line will have about 90ms delay all by itself. The number of hops is only relevant if all the links are *identical*. Being the same speed is only part of it. From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 9 20:01:32 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18478; Mon, 9 Nov 92 19:55:16 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA02855; Mon, 9 Nov 92 19:41:00 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17720; Mon, 9 Nov 92 19:32:04 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17524; Mon, 9 Nov 92 19:27:35 -0800 Received: from va.SJF.Novell.COM by newsun.Novell.COM (4.1/SMI-4.1) id AA10966; Mon, 9 Nov 92 19:26:33 PST Received: by va.SJF.Novell.COM (4.1/SMI-4.1) id AA26417; Mon, 9 Nov 92 19:26:41 PST From: Neal_Castagnoli@Novell.COM (Neal Castagnoli) Message-Id: <9211100326.AA26417@va.SJF.Novell.COM> Subject: Re: IPXCP Unbalanced RIP Metrics To: karl@MorningStar.Com (Karl Fox) Date: Mon, 9 Nov 92 19:26:40 PDT Cc: Michael_Allen@Novell.COM.ietf-ppp@ucdavis.ucdavis.edu (Allen Michael) In-Reply-To: <9211100200.AA02481@crappie.morningstar.com>; from "Karl Fox" at Nov 9, 92 9:00 pm X-Mailer: Elm [version 2.1 alpha-test] > > Allen, Michael writes: > > A reason why unbalanced link delays are bad: > > > > > > +----------+ <- Cost=12 +----------+ > > | System A |----------/_________| System B | > > +----------+ ->Cost=6 +----------+ > > | | > > | | > > LAN | | LAN +-------+ > > | +----------| W/S 1 | > > Cost=1 | | Cost=1 +-------+ > > | | > > | | > > +----------+ ->Cost=12 +----------+ > > | System C |----------/_________| System D | > > +----------+ <-Cost=6 +----------+ > > > > Systems A->D are NetWare servers/routers. > > > > Consider a Workstation (W/S 1) talking to the file system on > > System A. To get to System A, the packet will traverse Systems D > > and C as a GetRouteRequest would find that path faster - even > > though there is an extra "hop" and the lines are actually the > > same speed. > > > The packet has now taken 2 extra hops for its return journey!!! > > I don't understand the above explanation. If the original packet went > *to* System A, wouldn't the response packet then come *from* System A? > If System A then sends it back the way it came, then it will send it to > C, then D, then to W/S 1. If it instead sends it back the shortest way, > it will go to B, then to W/S 1. Wouldn't the worst case be when it > follows the return path rather than the shortest path? There is no source route option within IPX. What Michael is pointing out is that servers don't look up roots when returning packets to their destination. However, when routers root, they do look up the return path. If the packet goes from A to C, then C looks up the cost and finds that the cost to reach the workstation through A is 8, whereas the cost through D is 13. C will make the correct choice to send the packet to A, at which point the packet goes through A's routing code which decides to go through B since the cost is 7. The key is that servers use reverse path forwarding. Routers of course can't do this, since they don't have a path. > > > If this was a larger topology with WAN connections between A & C, > > this could be an expensive method of sending data on packet charged > > networks. > > If your routing technology looked like OSPF, then you would send the > request from W/S 1 to D to C to A, and the response would go from A to B > to W/S 1. You'd always use the best possible path, regardless of the > topology. > > Shortest path *is* the best way, even if it means you take more hops. > If the costs are based on delay, then it will even get there quicker. > Two hops over dedicated 38400 bps lines will usually be quicker than a > single hop over a compressing V.32bis/V.42/V.42bis 38400 bps link, > because the dedicated lines will have about 25ms delay each and the > V.42bis line will have about 90ms delay all by itself. The number of > hops is only relevant if all the links are *identical*. Being the same > speed is only part of it. > This has nothing to do with shortest paths at all. The question was about assymetric routes. How many WAN protocols have a throughput in one direction of X, and in another direction Y, where X != Y? The discussion at hand is whether both sides of a link ought to agree on the throughput characteristics of a line. The current thought is to base the IPX delay metric on the local throughput characteristic. However, this has the problem over media like X.25 in which there may be unequal access rates into the network on each side of the link. This of course doesn't mean that when you are sending in one direction that the actual throughput of the link goes up. --Neal From ietf-ppp-request@ucdavis.ucdavis.edu Tue Nov 10 06:15:45 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10738; Tue, 10 Nov 92 06:08:39 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05802; Tue, 10 Nov 92 05:50:26 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09693; Tue, 10 Nov 92 05:43:58 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09360; Tue, 10 Nov 92 05:39:31 -0800 Received: from crappie.morningstar.com by volitans.morningstar.com (5.65a/92042102) id AA18874; Tue, 10 Nov 92 08:38:34 -0500 From: Karl Fox Received: by crappie.morningstar.com (5.65a/910712902) id AA00419; Tue, 10 Nov 92 08:38:00 -0500 Date: Tue, 10 Nov 92 08:38:00 -0500 Message-Id: <9211101338.AA00419@crappie.morningstar.com> To: Neal_Castagnoli@Novell.COM Cc: ietf-ppp@ucdavis.ucdavis.edu, Michael_Allen@Novell.COM In-Reply-To: Neal_Castagnoli@Novell.COM's message of Mon, 9 Nov 92 19:26:40 PDT Subject: Re: IPXCP Unbalanced RIP Metrics Organization: Morning Star Technologies, Inc. For reference: :-) A - B | +-W/S 1 C - D Neal Castagnoli writes: > There is no source route option within IPX. What Michael is pointing out is > that servers don't look up roots when returning packets to their destination. > However, when routers root, they do look up the return path. If the packet > goes from A to C, then C looks up the cost and finds that the cost to reach > the workstation through A is 8, whereas the cost through D is 13. C will > make the correct choice to send the packet to A, at which point the packet > goes through A's routing code which decides to go through B since the cost is > 7. > > The key is that servers use reverse path forwarding. Routers of course can't > do this, since they don't have a path. This is what I didn't understand, that System A would route a packet one way when sending its reply and then route a different way when moving (routing) the same packet from one interface to another. Anyone who grew up with IP would understand why this would not occur to me. :-) > > Shortest path *is* the best way, even if it means you take more hops. ... > This has nothing to do with shortest paths at all. The question was > about assymetric routes. But it has everything to do with shortest paths. Your routers route using shortest path, if I understand your response. It's just the end systems that don't -- they instead just send the response back the way the request came. > How many WAN protocols have a throughput in one direction of X, and in > another direction Y, where X != Y? Any WAN protocol, except in an idle network consisting only of leased lines or LAN connections. Once you introduce traffic of any kind, or carrier technologies such as X.25, ATM, or frame relay (where there is traffic otherwise invisible to you), you frequently end up with asymmetrical throughput and delay characteristics. Oh, or dialup connections using half-duplex modem carrier technology such as PEP. > The discussion at hand is whether both sides of a link ought to agree on the > throughput characteristics of a line. The current thought is to base the IPX > delay metric on the local throughput characteristic. However, this has the > problem over media like X.25 in which there may be unequal access rates into > the network on each side of the link. This of course doesn't mean that when > you are sending in one direction that the actual throughput of the link goes > up. Right. This is why, in shortest path routing technologies, the administrator can choose the basis for the path costs. He or she may want to route based on throughput, or response time, or actual dollar cost. Or, the choice may be based on political or policy reasons, or to move traffic, or to experiment, or to test. If your end systems know how to route, then why don't they just use the routing code when sending replies? You must have to go out of your way to do otherwise. From ietf-ppp-request@ucdavis.ucdavis.edu Tue Nov 10 06:32:05 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11450; Tue, 10 Nov 92 06:28:29 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05935; Tue, 10 Nov 92 06:10:13 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10508; Tue, 10 Nov 92 06:01:19 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10386; Tue, 10 Nov 92 05:59:08 -0800 Received: by volitans.morningstar.com (5.65a/92042102) id AA18928; Tue, 10 Nov 92 08:57:38 -0500 Date: Tue, 10 Nov 92 08:57:38 -0500 From: Bob Sutterfield Message-Id: <9211101357.AA18928@volitans.morningstar.com> To: Neal_Castagnoli@Novell.COM (Neal Castagnoli) Cc: ietf-ppp@ucdavis.ucdavis.edu, Mike.Blackwell@cs.cmu.edu (Mike Blackwell), pk16@frc2.frc.ri.cmu.edu (Paul Keller), skb@frc2.frc.ri.cmu.edu (Scott K Boehmke), karl@MorningStar.Com (Karl Fox) In-Reply-To: Neal_Castagnoli@Novell.COM's message of Mon, 9 Nov 92 19:26:40 PDT Subject: Re: IPXCP Unbalanced RIP Metrics From: Neal_Castagnoli@Novell.COM (Neal Castagnoli) Date: Mon, 9 Nov 92 19:26:40 PDT How many WAN protocols have a throughput in one direction of X, and in another direction Y, where X != Y? This month, a robot is being prepared to crawl around inside an active volcano crater somewhere in Antarctica. It's connected with its Stateside researchers via IP over synchronous PPP, running on its on-board SPARC UNIX system. It has a T1 satellite link to carry real-time vision system output, and other telemetry data, from Antarctica to North America. The return channel carries TCP ACKs, command-and-control, etc., and it's clocked at 9600. That wide-area IP-over-PPP link is highly asymmetrical, whether measured in throughput or latency. The remarkable thing is that it actually works, and apparently fairly well! (I've Cc:d the robot's handlers on this note, hoping they'll gently clear up any inaccuracies I've inadvertently introduced to the story.) From ietf-ppp-request@ucdavis.ucdavis.edu Tue Nov 10 08:02:56 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14616; Tue, 10 Nov 92 07:58:51 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06785; Tue, 10 Nov 92 07:40:44 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13802; Tue, 10 Nov 92 07:31:19 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13479; Tue, 10 Nov 92 07:22:50 -0800 Received: from va.SJF.Novell.COM by newsun.Novell.COM (4.1/SMI-4.1) id AA17049; Tue, 10 Nov 92 07:22:01 PST Received: by va.SJF.Novell.COM (4.1/SMI-4.1) id AA01294; Tue, 10 Nov 92 07:22:08 PST From: Neal_Castagnoli@Novell.COM (Neal Castagnoli) Message-Id: <9211101522.AA01294@va.SJF.Novell.COM> Subject: Re: IPXCP Unbalanced RIP Metrics To: karl@MorningStar.Com (Karl Fox) Date: Tue, 10 Nov 92 7:22:08 PDT Cc: Neal_Castagnoli@Novell.COM, ietf-ppp@ucdavis.ucdavis.edu, Michael_Allen@Novell.COM In-Reply-To: <9211101338.AA00419@crappie.morningstar.com>; from "Karl Fox" at Nov 10, 92 8:38 am X-Mailer: Elm [version 2.1 alpha-test] > > But it has everything to do with shortest paths. Your routers route > using shortest path, if I understand your response. It's just the end > systems that don't -- they instead just send the response back the way > the request came. No. Every NetWare server is also a router. I suppose you could state that the end system portion of the server doesn't route. The server is sending the packet back the way it came. > > > How many WAN protocols have a throughput in one direction of X, and in > > another direction Y, where X != Y? > > Any WAN protocol, except in an idle network consisting only of leased > lines or LAN connections. Once you introduce traffic of any kind, or > carrier technologies such as X.25, ATM, or frame relay (where there is > traffic otherwise invisible to you), you frequently end up with > asymmetrical throughput and delay characteristics. Oh, or dialup > connections using half-duplex modem carrier technology such as PEP. Of course. I think that I need to do a little education here. The RIP delay metric is a composit metric which includes delay and throughput characteristics. It does not adjust (thank goodness) to changes in RTT or throughput, both of which may change during the lifetime of a connection. If one has a half duplex modem, X.25 or even Frame Relay, the possible throughput doesn't change depending on direction, if the network is otherwise free of congestion. This observation relies on the notion that the bottlenecks are usually at the local attachment. This is a pretty safe bet, since a carrier would be pretty slimy to sell say a T1 attachment to their network when internally they can carry only 56KB of traffic. > > > The discussion at hand is whether both sides of a link ought to agree on the > > throughput characteristics of a line. The current thought is to base the IPX > > delay metric on the local throughput characteristic. However, this has the > > problem over media like X.25 in which there may be unequal access rates into > > the network on each side of the link. This of course doesn't mean that when > > you are sending in one direction that the actual throughput of the link goes > > up. > > Right. This is why, in shortest path routing technologies, the > administrator can choose the basis for the path costs. He or she may > want to route based on throughput, or response time, or actual dollar > cost. Or, the choice may be based on political or policy reasons, or to > move traffic, or to experiment, or to test. There are many good reasons to allow administrators to set costs. We don't allow it in the current RIP implementations. > > If your end systems know how to route, then why don't they just use the > routing code when sending replies? You must have to go out of your way > to do otherwise. Would you believe that not routing a packet can actually increase your file serving performance? I would. You don't have to look up the route. Consider that NCP is a request/response protocol, with workstations requesting transactions from servers. Servers can route. In fact, all NetWare servers are routers. However, there is a cost to the network layer processing, which can be cut out if you don't route the packet. This is a fine assumption provided that there aren't assymetric routes in the network. It works everytime, provided that the network isn't in a state of transition, and I would suggest that the CPU cycle savings as a percentage are extremely high. --Neal From ietf-ppp-request@ucdavis.ucdavis.edu Tue Nov 10 11:36:16 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21764; Tue, 10 Nov 92 11:12:49 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09850; Tue, 10 Nov 92 10:52:25 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20738; Tue, 10 Nov 92 10:45:40 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20339; Tue, 10 Nov 92 10:35:58 -0800 Received: from remora.morningstar.com by volitans.morningstar.com (5.65a/92042102) id AA21323; Tue, 10 Nov 92 13:34:47 -0500 Received: by remora.morningstar.com (5.65a/91072901) id AA09690; Tue, 10 Nov 92 13:34:45 -0500 Date: Tue, 10 Nov 92 13:34:45 -0500 From: Karl Fox Message-Id: <9211101834.AA09690@remora.morningstar.com> To: Neal_Castagnoli@Novell.COM (Neal Castagnoli) Cc: Michael_Allen@Novell.COM, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: IPXCP Unbalanced RIP Metrics References: <9211101338.AA00419@crappie.morningstar.com> <9211101522.AA01294@va.SJF.Novell.COM> Organization: Morning Star Technologies, Inc. I said: > > If your end systems know how to route, then why don't they just use the > > routing code when sending replies? You must have to go out of your way > > to do otherwise. Neal Castagnoli replied: > Would you believe that not routing a packet can actually increase your > file serving performance? I would. You don't have to look up the > route. Consider that NCP is a request/response protocol, with > workstations requesting transactions from servers. Servers can route. > In fact, all NetWare servers are routers. However, there is a cost to > the network layer processing, which can be cut out if you don't route > the packet. > > This is a fine assumption provided that there aren't assymetric routes > in the network. It works everytime, provided that the network isn't > in a state of transition, and I would suggest that the CPU cycle > savings as a percentage are extremely high. So why not do what the router manufacturers do and cache your routes? It saves us one to four orders of magnitude in CPU use, depending on how many routes we have. It will probably cost you *less* CPU than keeping around the information about where the request packet came in. From ietf-ppp-request@ucdavis.ucdavis.edu Tue Nov 10 16:32:18 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02489; Tue, 10 Nov 92 16:05:43 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA13105; Tue, 10 Nov 92 14:11:36 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28041; Tue, 10 Nov 92 14:06:29 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27203; Tue, 10 Nov 92 13:44:59 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA02437; Tue, 10 Nov 92 13:44:11 PST Date: Tue, 10 Nov 92 13:44:11 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9211102144.AA02437@ray.lloyd.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Agenda for next week We have another week of fun, games, lunches, and dinners coming up. The PPPEXT WG will be meeting Wednesday morning and Thursday afternoon. I would like to put forth a "straw man" agenda for comments. There is one "hard" time in the agenda: a joint meeting with the IPLPDN WG on Wednesday from about 1030 to noon to discuss what IPLPDN is doing with PPP (or something very PPP-like) running over other PDN services like FR and SMDS. On Wednesday: 1. Administriva -- where we stand with all the docs including those in progress. 2. Try to determine what off-line sessions we need between Wed and Thur (coming to resolution for IPXCP immediately jumps to mind here). 3. Meet with IPLPDN. Arrange for common points-of-contact so that the work of the two WGs don't conflict. Probably arrange some off-line discussion. On Thursday: 1. Report back on what the off-line discussions produced 2. HDLC (error correction) 3. Compression Optional: 4. Persecution of the innocent Brian Lloyd, President B.P. Lloyd & Associates, Inc. brian@lloyd.com 3420 Sudbury Road (916) 676-1147 - voice Cameron Park, CA 95682 (916) 676-3442 - fax From ietf-ppp-request@ucdavis.ucdavis.edu Tue Nov 10 19:03:10 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08809; Tue, 10 Nov 92 18:55:12 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA13210; Tue, 10 Nov 92 14:20:11 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28055; Tue, 10 Nov 92 14:06:45 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27297; Tue, 10 Nov 92 13:45:40 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA02441; Tue, 10 Nov 92 13:44:54 PST Date: Tue, 10 Nov 92 13:44:54 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9211102144.AA02441@ray.lloyd.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Agenda for next week We have another week of fun, games, lunches, and dinners coming up. The PPPEXT WG will be meeting Wednesday morning and Thursday afternoon. I would like to put forth a "straw man" agenda for comments. There is one "hard" time in the agenda: a joint meeting with the IPLPDN WG on Wednesday from about 1030 to noon to discuss what IPLPDN is doing with PPP (or something very PPP-like) running over other PDN services like FR and SMDS. On Wednesday: 1. Administriva -- where we stand with all the docs including those in progress. 2. Try to determine what off-line sessions we need between Wed and Thur (coming to resolution for IPXCP immediately jumps to mind here). 3. Meet with IPLPDN. Arrange for common points-of-contact so that the work of the two WGs don't conflict. Probably arrange some off-line discussion. On Thursday: 1. Report back on what the off-line discussions produced 2. HDLC (error correction) 3. Compression Optional: 4. Persecution of the innocent Brian Lloyd, President B.P. Lloyd & Associates, Inc. brian@lloyd.com 3420 Sudbury Road (916) 676-1147 - voice Cameron Park, CA 95682 (916) 676-3442 - fax P.S. Rumor has it that Bill Simpson, Vint Cerf, Marshall Rose, and Daniel Bernstein will do exhibition tag-team wrestling for our enjoyment. Joachim Carlos Santos Martillo Ajami has been chosen to referee. :^) From ietf-ppp-request@ucdavis.ucdavis.edu Tue Nov 10 19:12:12 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09273; Tue, 10 Nov 92 19:08:23 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA13354; Tue, 10 Nov 92 14:31:07 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28698; Tue, 10 Nov 92 14:25:19 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27940; Tue, 10 Nov 92 14:04:10 -0800 Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA26155; Tue, 10 Nov 92 14:03:11 -0800 Date: Tue, 10 Nov 92 15:50:17 EDT From: "William Allen Simpson" Message-Id: <905.bill.simpson@um.cc.umich.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: IPXCP Unbalanced RIP Metrics We are learning a great deal about the trade-offs that have gone into the design of Novell's IPX servers and routers. We have learned about some of the deficiencies in design that haven't kept up with research in the Internet world (but remember, these problems were only solved in the past few years). We now know one thing that IPXCP won't do that IPX-WAN is designed to do; that is, time the RTT on the link. However, this group is about what to do with PPP. Could the vendors let me know whether they need an option to negotiate, balance, or otherwise configure the RTT time, please. Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 11 13:06:18 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10339; Wed, 11 Nov 92 10:10:10 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA21533; Wed, 11 Nov 92 09:40:50 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08730; Wed, 11 Nov 92 09:26:30 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06471; Wed, 11 Nov 92 08:21:13 -0800 Received: by saffron.acc.com (4.1/SMI-4.1) id AA00317; Wed, 11 Nov 92 08:20:10 PST Date: Wed, 11 Nov 92 08:20:10 PST From: fbaker@acc.com (Fred Baker) Message-Id: <9211111620.AA00317@saffron.acc.com> To: bill.simpson@um.cc.umich.edu Subject: Re: IPXCP Unbalanced RIP Metrics Cc: ietf-ppp@ucdavis.ucdavis.edu >> However, this group is about what to do with PPP. Could the vendors >> let me know whether they need an option to negotiate, balance, or >> otherwise configure the RTT time, please. If you're going to measure it, there is a better way and procedure for measurement. I think virtually all PPP vendors implement either LQM or a "ping your neighbor" procedure. If the number of responses falls below some threshold - n out of m - a TERMINATE event is recognized due to link quality. The simplest way to calculate RTT, I think, is to note the time one sends the LQM or Echo Request, and average the RTTs of these (it would presumably divide the delay in two to get one-way delay). In an Echo Request, the time noted could be stored in the message itself. Delay on the link becomes ROUND_UP (18.21 * ((576 * 8)/ifSpeed + mean propagation [ping/2] delay)) When delays change due to link utilization, lo and behold, the RTT advertised will change with it. But then, I'm a TroubleMaker. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 11 13:14:10 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10889; Wed, 11 Nov 92 10:25:51 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA21649; Wed, 11 Nov 92 09:46:30 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09053; Wed, 11 Nov 92 09:35:12 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07556; Wed, 11 Nov 92 08:52:56 -0800 Received: from na.SJF.Novell.COM by newsun.Novell.COM (4.1/SMI-4.1) id AA07107; Wed, 11 Nov 92 08:52:03 PST Received: by na.SJF.Novell.COM (4.1/SMI-4.1) id AA19972; Wed, 11 Nov 92 08:51:29 PST Date: Wed, 11 Nov 92 08:51:29 PST From: Christopher_Ranch@Novell.COM (Christopher Ranch) Message-Id: <9211111651.AA19972@na.SJF.Novell.COM> To: brian@lloyd.com, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: Agenda for next week Hi Y'all, > From: brian@lloyd.com (Brian Lloyd) > > There is one "hard" time in the agenda: a joint meeting with the > IPLPDN WG on Wednesday from about 1030 to noon to discuss what IPLPDN > is doing with PPP (or something very PPP-like) running over other PDN > services like FR and SMDS. Attached is a rough I-D just distributed to the IPLPDN WG. I think they're going down a decent path, albeit a potenitally more dangerous one (multiple data paths). Nothing we can't deal with, though. > Optional: > > 4. Persecution of the innocent I don't know why, but I flinched as I read this ;). > ps: I wouldn't thouch that one with a 10 mile pole...P-). Chris From iplpdn-request@ietf.nri.reston.va.us Tue Nov 10 18:29:30 1992 Return-Path: Received: from ns.Novell.COM by na.SJF.Novell.COM (4.1/SMI-4.1) id AA15663; Tue, 10 Nov 92 18:29:28 PST Received: from IETF.nri.reston.VA.US by ns.Novell.COM (4.1/SMI-4.1) id AA14820; Tue, 10 Nov 92 19:29:56 MST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22965; 10 Nov 92 20:25 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22961; 10 Nov 92 20:22 EST Received: from vangogh.CS.Berkeley.EDU by CNRI.Reston.VA.US id aa26170; 10 Nov 92 20:23 EST Received: by vangogh.CS.Berkeley.EDU (5.113/2.7) id AA04966; Tue, 10 Nov 92 17:22:59 -0800 Date: Tue, 10 Nov 92 17:22:59 -0800 Sender: iplpdn-request@IETF.CNRI.Reston.VA.US From: Keith Sklower Message-Id: <9211110122.AA04966@vangogh.CS.Berkeley.EDU> To: iplpdn@CNRI.Reston.VA.US Subject: Parameter negotiations for Frame Relay and X.25 Status: R At the last IETF, I agreed to write up a proposal for negotiating parameters for RFC1294 situations. This is a very rough and incomplete draft, but it seemed like it would be useful to have people time to digest something, even if it were only somewhat skeletal. -------------------------------------------------------------------------------- Parameter Negotiation for the Multiprotocol Interconnect Keith Sklower Computer Science Department University of California, Berkeley Clifford Frost Information Systems & Technology University of California, Berkeley 1. Status of This Memo This memo is intended as a basis for discussion at the November 16th, 1992 IETF, proposes an eventual IAB standards track protocol, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. 2. Abstract This document describes mechanisms for negotiating opera- tional parameters wherever SNAP encapsulation of Internet Protocols is available. It is suitable for use in conjunc- tion with RFC 1294 (Multiprotocol Over Frame Relay) and RFC 1356 (Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode) [1,2]. The mechanisms described here are intended as optional extensions, intended to facilitate interoperation in public networks were preconfiguration may not have been done symmetrically by all parties who wish to exchange information. 3. Acknowledgements The authors wish to thank Brian Lloyd of Lloyd & Associates for extensive discussion of the PPP protocol, Brad Steinke of Microcom, and Joel Halpern of Network Systems for useful suggestions, and especially Chris Ranch of Novell for details about the protocol itself. 4. Conventions The following language conventions are used in the items of specification in this document: Draft Parameter Negotiation Nov. 1992 o Must, Shall or Mandatory -- the item is an absolute requirement of the specification. o Should or Recommended -- the item should generally be followed for all but exceptional circumstances. o May or Optional -- the item is truly optional and may be followed or ignored according to the needs of the implementor. 5. Introduction When parties wish to exchange information over a public data network, it may be useful to perform sanity checks, such as verifying that buffer sizes are sufficient to receive data being transmitted, or that there is agreement as to which protocols will be routed or bridged. As another example, there may be circumstance in which the identity of a calling party may not be readily available; thus some form of authentication may be desired. The Point-to-Point Protocol (RFC 1331 and 1332) provides a means of achieving these goals [3,4]. It is very general and can be adapted to any situation where there is a virtual point-to-point connection between parties wishing to exchange information. Since both RFCs 1294 and 1331 specify details of framing and encapsulation in incompatible ways, there is a minor modification to PPP's encapsulation which is required for this context. (N.B. -- The following paragraph is going to provoke a great deal of controversy, and is actively opposed by some of the people I acknowledged above.) However, there are some philosophical and semantic changes that we would like made to PPP as well for use in this context. Principally, we would like parameter negotiation as a whole to be made optional, and we would also like to change the requirement that a network-protocol specific negotiation be conducted after a network-layer negotiation has been concluded and before packets in a particular protocol be exchanged. We would also like to be able to renegotiate parameters at any time during the course of an association, and it has been proposed (even for PPP) that there be an alternative summary negotiation for all Protocols to be routed or bridged without incurring a separate negotiation for each protocol. 6. Frame Format Sklower & Frost [Page 1] Draft Parameter Negotiation Nov. 1992 6.1. Basic Format In this document, we propose prepending a SNAP header to otherwise unchanged PPP (data and control) packets [5]. The SNAP header MUST specify an OUI of 0 (Xerox Ethernet Encap- sulation). The protocol ID field MUST be (0xZZZZ - to be obtained). A system SHOULD recognize incoming PPP data packets; however, we RECOMMEND that only control or negotia- tion type PPP packets be transmitted in this fashion, since RFCs 1294 and 1356 already specify a means of encapsulating data packets. {The following rationale should probably be expunged from a formal draft: People have proposed using the OUI for 802.1 (which is used in RFC1294 for bridging), and obtaining a Protocol Identifier from that space, or obtaining and entirely separate OUI for this purpose. I suggest that obtaining an Ethernet Type would be more appropriate as: (1) The negotiated parameters affect more than just bridging. (2) It may be useful to inject PPP packets into a (possi- bly switched and bridged) ethernet enviroments, e.g. authentication requests (3) It may be easier to do a two-byte (aligned) compari- son than a 3 byte comparison, and (4) It costs a lot more to obtain an OUI from IEEE than an ethertype from Xerox.} Since we are proposing using this in conjunction with both RFC1294 and RFC1356, we give an example in each packet for- mat: Sample Frame Relay PPP LCP packet +-----------------------------+ | flag (7E hexadecimal) | +-----------------------------+ | Q.922 Address | +-- --+ | | +-----------------------------+ | Control (UI = 0x03) | +-----------------------------+ | Optional Pad(s) (0x00) | +-----------------------------+ | NLPID 0x80 | +-----------------------------+ | OUI 0x00 | +-- . --+ Sklower & Frost [Page 2] Draft Parameter Negotiation Nov. 1992 | OUI 0x00 | +-- . --+ | OUI 0x00 | | (three octets) | +-----------------------------+ | ETHERTYPE (to be .. | +-- . --+ | ETHERTYPE obtained) | | (two octets) | +-----------------------------+ | PPP Protocol (e.g. 0x0c) | +-- . --+ | PPP Protocol (0x21 for LCP)| | (two octets) | +-----------------------------+ | Data | | (e.g LCP Code ) | +-----------------------------+ | (e.g LCP Identifier) | +-----------------------------+ | (e.g. LCP Option Length)| +-- . --+ | (two octets) | +-----------------------------+ | (e.g. LCP Option) | | . | | . | | . | | . | +-----------------------------+ | Frame Check Sequence | +-- . --+ | (two octets) | +-----------------------------+ | flag (7E hexadecimal) | +-----------------------------+ Sample X.25 PPP LCP packet +-----------------------------+ | flag (7E hexadecimal) | +-----------------------------+ | Address A or B 0x1 or 0x3 | +-- --+ | LAPB Control | +-----------------------------+ | D,Q bits | SVC# high order | +-----------------------------+ | SVC low order | +-----------------------------+ | p(r) | m_bit | p(s) | 0 | +-----------------------------+ | NLPID 0x80 | Sklower & Frost [Page 3] Draft Parameter Negotiation Nov. 1992 +-----------------------------+ | OUI 0x00 | +-- . --+ | OUI 0x00 | +-- . --+ | OUI 0x00 | | (three octets) | +-----------------------------+ | ETHERTYPE (to be .. | +-- . --+ | ETHERTYPE obtained) | | (two octets) | +-----------------------------+ | PPP Protocol (e.g. 0x0c) | +-- . --+ | PPP Protocol (0x21 for LCP)| | (two octets) | +-----------------------------+ | Data | | (e.g LCP Code ) | +-----------------------------+ | (e.g LCP Identifier) | +-----------------------------+ | (e.g. LCP Option Length)| +-- . --+ | (two octets) | +-----------------------------+ | (e.g. LCP Option) | | . | | . | | . | | . | +-----------------------------+ | Frame Check Sequence | +-- . --+ | (two octets) | +-----------------------------+ | flag (7E hexadecimal) | +-----------------------------+ 6.2. Supported Types The PPP protocol is a rich language and allows many options to be negotiated. An implementation MAY request any option specified by PPP, but MAY decline to support any option. Because PPP and Frame Relay encapsulations evolved indepen- dently, there are duplicate ways to obtain configuration information such as the IP address of the other end of the PVC - by inverse arp, or determine the transmit and receive buffer sizes - by XID negotiation. Where there are such choices, it is RECOMMENDED that an implementation adhere to practice specified in the Frame Relay and X.25 RFCs. Manual configuration also implicitly provides information that may Sklower & Frost [Page 4] Draft Parameter Negotiation Nov. 1992 otherwise have been explicitly negotiated. 7. Changes to PPP semantics 7.1. Optionality and Separability of Negotiations As noted above, people have expressed the desire not to be required to conduct any negotiations before transmitting data packets in a public data network environment. Thus, an implementation MAY silently ignore any SNAP encapsulated PPP packet. If an implementation responds to LCP packets, it MUST traverse the LCP state diagram according to RFC1331. However, if the state diagram converges, an implementation MAY immediately begin transmission of any data packet for any protocol it chooses. We note that this proposed change to the PPP protocol is vigorously opposed by the chairman of the PPP working group. If an implementation responds to NCP packets for any partic- ular protocol, it MUST otherwise obey the rules of the RFC for that corresponding NCP. One reason for making negotiations optional is cost; there are environments which charge by the packet and there are applications such as mail hubs which generally exchange only a few data packets with a given remote host and then will not exchange any other packets for relatively long periods of time. Another reason is simplicity of implementation. For use of small computers at home, people may wish to be able to only support the required packet framing. Or, for routers at campus or business hubs, this could reduce memory require- ments from having to maintain state information for hundreds of vitual point-to-point connections. Another reason is reduction of latency. 8. Other Extensions to PPP 8.1. Protocol Summaries in NCP [This section is also likely to be contentious]. It has been suggested that there should be a PPP LCP option to pre- emptively announce which protocols will be routed or bridged, in lieu of conducting independent negotiations for each protocol via their separate NCPs, The rationale for having this option is that it gives what may be for simple situations the single most important benefit of having an NCP at all (i.e. a sanity check that data packets will not be black holed) without having the complexity or latency requirements of a full blown NCP. Sklower & Frost [Page 5] Draft Parameter Negotiation Nov. 1992 8.2. Agglutination of PPP packets If it is desired to conduct several independent NCPs at the same time, and since there are per-packet charges, it may be useful to bundle up several logical PPP packets into the same physical packet and thus reduce packet charges. 9. References [1] Bradley, T., Brown, C., and Malis, A., "Multiprotocol Interconnect over Frame Relay", Network Working Group, RFC-1294, January 1992. [2] Malis, A., Robinson, D., Ullman R., "Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode", Net- work Working Group, RFC-1356, August 1992. [3] Simpson, W., "The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to- Point Links", Network Working Group, RFC-1331, May 1992. [4] McGregor, G., "The PPP Internet Protocol Control Proto- col (IPCP)" Network Working Group, RFC-1332, May 1992. [5] Postel, J. and Reynolds, J., "A Standard for the Trans- mission of IP Datagrams over IEEE 802 Networks", ISI, RFC-1042, February 1988. 10. Authors' Addresses Keith Sklower Computer Science Department 570 Evans Hall University of California Berkeley, CA 94720 Phone: (510) 642-9587 Email: sklower@cs.Berkeley.EDU Clifford Frost Information Systems & Technology 275 Evans Hall University of California Berkeley, CA 94720 Phone: (510) 642-5360 Email: cliff@cmsa.Berkeley.EDU Sklower & Frost [Page 6] From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 11 13:54:11 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16624; Wed, 11 Nov 92 13:28:15 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA23696; Wed, 11 Nov 92 12:55:33 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14774; Wed, 11 Nov 92 12:28:37 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from nsco.network.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13611; Wed, 11 Nov 92 11:49:28 -0800 Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA27443; Wed, 11 Nov 92 13:53:19 -0600 Received: from scow.network.com by anubis.network.com (4.1/SMI-4.1) id AA21182; Wed, 11 Nov 92 13:48:22 CST Date: Wed, 11 Nov 92 13:48:22 CST From: foxcj@anubis.network.com (Craig Fox) Message-Id: <9211111948.AA21182@anubis.network.com> To: bill.simpson@um.cc.umich.edu, fbaker@acc.com Subject: Re: IPXCP Unbalanced RIP Metrics Cc: ietf-ppp@ucdavis.ucdavis.edu From: fbaker@acc.com (Fred Baker) Message-Id: <9211111620.AA00317@saffron.acc.com> To: bill.simpson@um.cc.umich.edu Subject: Re: IPXCP Unbalanced RIP Metrics Cc: ietf-ppp@ucdavis.edu Status: R >> However, this group is about what to do with PPP. Could the vendors >> let me know whether they need an option to negotiate, balance, or >> otherwise configure the RTT time, please. If you're going to measure it, there is a better way and procedure for measurement. I think virtually all PPP vendors implement either LQM or a "ping your neighbor" procedure. If the number of responses falls below some threshold - n out of m - a TERMINATE event is recognized due to link quality. The simplest way to calculate RTT, I think, is to note the time one sends the LQM or Echo Request, and average the RTTs of these (it would presumably divide the delay in two to get one-way delay). In an Echo Request, the time noted could be stored in the message itself. Delay Note however that a couple of vendors have been known to truncate or otherwise munge the echo packet. My current code passes the RTT start time in the echo packet along with other info, but I am now being forced to be more 'general' in what I accept. Thus I am pulling this info out of the echo packet. Oh for a PPP test suite. Before anyone mentions Morningstar PPP (the most widely respected PPP implementation), let me note that to achieve interoperability, Karl has had to become less specific in what he requires. Maybe MST PPP could be enhanced with a test suite mode that checked for full compliance. I imagine that customers as well as vendors would want to purchase at least one copy :-). on the link becomes ROUND_UP (18.21 * ((576 * 8)/ifSpeed + mean propagation [ping/2] delay)) When delays change due to link utilization, lo and behold, the RTT advertised will change with it. But then, I'm a TroubleMaker. Fred Craig From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 11 14:08:36 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17073; Wed, 11 Nov 92 13:42:25 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA23791; Wed, 11 Nov 92 13:03:51 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14901; Wed, 11 Nov 92 12:30:47 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from nsco.network.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13665; Wed, 11 Nov 92 11:52:40 -0800 Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA27463; Wed, 11 Nov 92 13:56:31 -0600 Received: from scow.network.com by anubis.network.com (4.1/SMI-4.1) id AA21201; Wed, 11 Nov 92 13:51:34 CST Date: Wed, 11 Nov 92 13:51:34 CST From: foxcj@anubis.network.com (Craig Fox) Message-Id: <9211111951.AA21201@anubis.network.com> To: Christopher_Ranch@Novell.COM, brian@lloyd.com Subject: Re: Agenda for next week Cc: ietf-ppp@ucdavis.ucdavis.edu In response to a number of you who expressed interest in the optional "persecution of the innocent" section, ask yourselves, "who is innocent?" I think it safe to assume that we are all safe from persecution if innocence is the criterion. :^) I look forward to seeing all of you next week. Brian Lloyd, President B.P. Lloyd & Associates, Inc. brian@lloyd.com 3420 Sudbury Road (916) 676-1147 - voice Cameron Park, CA 95682 (916) 676-3442 - fax Gee, I was under the impression that PPP itself was adequate persecution of the innocent. Hmmm... Or were you referring to your attempt to add PPP style negotiation to Frame Relay, etc? Craig From ietf-ppp-request@ucdavis.ucdavis.edu Thu Nov 12 05:30:25 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09189; Thu, 12 Nov 92 05:29:24 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA29798; Wed, 11 Nov 92 20:50:29 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29644; Wed, 11 Nov 92 20:41:57 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29520; Wed, 11 Nov 92 20:37:34 -0800 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA03563; Wed, 11 Nov 92 20:36:34 PST Date: Wed, 11 Nov 92 20:36:34 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9211120436.AA03563@ray.lloyd.com> To: foxcj@anubis.network.com Cc: bill.simpson@um.cc.umich.edu, fbaker@acc.com, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Craig Fox's message of Wed, 11 Nov 92 13:48:22 CST <9211111948.AA21182@anubis.network.com> Subject: IPXCP Unbalanced RIP Metrics I think that we need to be more specific about what may/should be in the LCP echo request/response. A topic for the WG on Wed or Thur? Brian Lloyd, President B.P. Lloyd & Associates, Inc. brian@lloyd.com 3420 Sudbury Road (916) 676-1147 - voice Cameron Park, CA 95682 (916) 676-3442 - fax From ietf-ppp-request@ucdavis.ucdavis.edu Thu Nov 12 07:20:16 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11293; Thu, 12 Nov 92 07:12:06 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA02651; Thu, 12 Nov 92 06:50:16 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10762; Thu, 12 Nov 92 06:40:40 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from nsco.network.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10679; Thu, 12 Nov 92 06:34:21 -0800 Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA01140; Thu, 12 Nov 92 08:38:17 -0600 Received: from scow.network.com by anubis.network.com (4.1/SMI-4.1) id AA02498; Thu, 12 Nov 92 08:32:59 CST Date: Thu, 12 Nov 92 08:32:58 CST From: foxcj@anubis.network.com (Craig Fox) Message-Id: <9211121432.AA02498@anubis.network.com> To: brian@lloyd.com, foxcj@anubis.network.com Subject: Re: IPXCP Unbalanced RIP Metrics Cc: bill.simpson@um.cc.umich.edu, fbaker@acc.com, ietf-ppp@ucdavis.ucdavis.edu From: brian@lloyd.com (Brian Lloyd) In-Reply-To: Craig Fox's message of Wed, 11 Nov 92 13:48:22 CST <9211111948.AA21182@anubis.network.com> Subject: IPXCP Unbalanced RIP Metrics Status: R I think that we need to be more specific about what may/should be in the LCP echo request/response. A topic for the WG on Wed or Thur? Brian Lloyd, President B.P. Lloyd & Associates, Inc. brian@lloyd.com 3420 Sudbury Road (916) 676-1147 - voice Cameron Park, CA 95682 (916) 676-3442 - fax Why? The PPP specification has always REQUIRED that the receiver echo the the packet modifying only the function (from echo request to echo response) and the magic number. The receiver was allowed to truncate the packet only to avoid exceeding the original sender's MRU. Since the information in the echo request is only of use to the original sender (on return of the packet) why should we attempt to define that information. My processor has an internal 25 Mhz counter that is easy to access. I slam the current value into the packet and fire it off. On return I expect that the difference between the value in the packet and the current timer value is the RTT (with excessive precision). If we mandate a particular format here, I will have additional work to do even though this timer value is irrelevant to anyone else. Unless you are suggesting merging NTP and PPP. I believe the best course of action is to suggest several approaches by which a RTT can be calculated. Please note that the problems I have had with echoes have been with some vendor's implementations that simply truncated the echo (or expanded it) to some arbitrary value. Since I error checked the size of the echo response, I was pitching these frames and not coming into service. These vendor's now know of their bugs (thank you PPP-athon) and will fix them. But I think I need to be more accepting in what I accept. Craig From ietf-ppp-request@ucdavis.ucdavis.edu Thu Nov 12 10:55:02 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16516; Thu, 12 Nov 92 10:46:33 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04444; Thu, 12 Nov 92 10:18:46 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15476; Thu, 12 Nov 92 10:05:10 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15287; Thu, 12 Nov 92 09:57:09 -0800 Received: by saffron.acc.com (4.1/SMI-4.1) id AA17560; Thu, 12 Nov 92 09:55:43 PST Date: Thu, 12 Nov 92 09:55:43 PST From: fbaker@acc.com (Fred Baker) Message-Id: <9211121755.AA17560@saffron.acc.com> To: brian@lloyd.com Subject: Re: IPXCP Unbalanced RIP Metrics Cc: bill.simpson@um.cc.umich.edu, foxcj@anubis.network.com, ietf-ppp@ucdavis.ucdavis.edu >> I think that we need to be more specific about what may/should be in >> the LCP echo request/response. A topic for the WG on Wed or Thur? I think it's already pretty clear: quoting from the good book: An Echo-Request sender transmits a LCP packet with the Code field set to 9 (Echo-Request), the Identifier field set, the local Magic-Number inserted, and the Data field filled with any desired data, up to but not exceeding the peer's established maximum Information field length minus eight. Upon reception of an Echo-Request, a LCP packet MUST be transmitted with the Code field set to 10 (Echo-Reply), the Identifier field copied from the received Echo-Request, the local Magic-Number inserted, and the Data field copied from the Echo- Request, truncating as necessary to avoid exceeding the peer's established maximum Information field length. In short, the data field is an octet string of the sender's choosing, faithfully replicated by the receiver within the limits of the MRU. Unfaithful receivers are to be shamed into submission! Obvious uses: time stamp BERT or other test pattern (generating data during the LQ test phase) same stuff that goes into a UNIX PING (count from here to there modulo 256) From ietf-ppp-request@ucdavis.ucdavis.edu Thu Nov 12 12:37:39 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19448; Thu, 12 Nov 92 12:24:44 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05112; Thu, 12 Nov 92 11:11:18 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16947; Thu, 12 Nov 92 11:04:45 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from OPAL.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16785; Thu, 12 Nov 92 10:58:34 -0800 Received: by opal.acc.com (4.1/SMI-4.0) id AA04350; Thu, 12 Nov 92 10:59:37 PST Date: Thu, 12 Nov 92 10:59:37 PST From: art@opal.acc.com (Art Berggreen) Message-Id: <9211121859.AA04350@opal.acc.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: IPLPDN PPP draft Cc: iplpdn@CNRI.Reston.VA.US > - PPP over X.25 is kind of silly, since PPP is meant to replace X.25 > with a datagram service. Actually, PPP was intended to be a standardized way of directly connecting a pair of routers as well as a SLIP replacement. In the real world, many places can only get X.25 service for WAN connections. Here it makes sense to use PPP frames over X.25 VCs to perform multiprotocol interconnection between routers. Art From ietf-ppp-request@ucdavis.ucdavis.edu Thu Nov 12 14:44:47 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23587; Thu, 12 Nov 92 14:35:49 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06849; Thu, 12 Nov 92 12:20:58 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19163; Thu, 12 Nov 92 12:16:13 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18634; Thu, 12 Nov 92 12:01:35 -0800 Received: by volitans.morningstar.com (5.65a/92042102) id AA05973; Thu, 12 Nov 92 15:00:13 -0500 Date: Thu, 12 Nov 92 15:00:13 -0500 From: Bob Sutterfield Message-Id: <9211122000.AA05973@volitans.morningstar.com> To: bsimpson@angband.stanford.edu Cc: ietf-ppp@ucdavis.ucdavis.edu, iplpdn@CNRI.Reston.VA.US In-Reply-To: William Allen Simpson's message of Thu, 12 Nov 92 11:29:23 EDT <913.bill.simpson@um.cc.umich.edu> Subject: IPLPDN PPP draft Date: Thu, 12 Nov 92 11:29:23 EDT From: William Allen Simpson The concept that we could send PPP packets over ethernet is novel, but kind of interesting. They mention authentication. I suspect link quality monitoring would be useful, too. Not too novel. See Steve Bellovin's paper "Pseudo-Network Drivers and Virtual Networks", from the January 1990 Washington Usenix. He talks about building "virtual" networks upon (among others) point-to-point links within the address spaces of other networks. Besides authentication, he suggests encryption, firewalls, firewall penetration, debugging, and snooping as useful applications. From ietf-ppp-request@ucdavis.ucdavis.edu Thu Nov 12 14:52:51 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24034; Thu, 12 Nov 92 14:45:34 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07212; Thu, 12 Nov 92 12:53:26 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19843; Thu, 12 Nov 92 12:38:52 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from OAKLAND.BBN.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19582; Thu, 12 Nov 92 12:30:08 -0800 Message-Id: <9211122030.AA19582@ucdavis.ucdavis.edu> To: bsimpson@angband.stanford.edu Cc: Christopher Ranch , ietf-ppp@ucdavis.ucdavis.edu, iplpdn@cnri.reston.va.us, malis@BBN.COM Subject: Re: IPLPDN PPP draft In-Reply-To: Your message of Thu, 12 Nov 92 11:29:23 -0400. <913.bill.simpson@um.cc.umich.edu> Date: Thu, 12 Nov 92 15:25:21 -0500 From: Andy Malis Bill, > Finally, over on big-internet, they worry about making the packet > headers as lean as possible. Now we have folks who think that LAPB > encapsulating SNAP encapsulating PPP is a viable idea? They must live > in a different world! Since this is only for parameter negotiation, and not for carrying real user data, a bit of overhead during FR or X.25 circuit startup is acceptable. User data stays with the headers formats in RFCs 1294 and 1356. Cheers, Andy From ietf-ppp-request@ucdavis.ucdavis.edu Thu Nov 12 15:16:16 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24680; Thu, 12 Nov 92 15:00:50 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07700; Thu, 12 Nov 92 13:34:50 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21104; Thu, 12 Nov 92 13:29:39 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from OAKLAND.BBN.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20156; Thu, 12 Nov 92 12:51:36 -0800 Message-Id: <9211122051.AA20156@ucdavis.ucdavis.edu> To: Art Berggreen Cc: ietf-ppp@ucdavis.ucdavis.edu, iplpdn@cnri.reston.va.us, malis@BBN.COM Subject: Re: IPLPDN PPP draft In-Reply-To: Your message of Thu, 12 Nov 92 10:59:37 -0800. <9211121859.AA04350@opal.acc.com> Date: Thu, 12 Nov 92 15:41:11 -0500 From: Andy Malis Art, > In the real world, many places can only get X.25 service for WAN connections. > Here it makes sense to use PPP frames over X.25 VCs to perform multiprotocol > interconnection between routers. That's why we wrote RFC 1356 in the first place - for multiprotocol interconnection over X.25. Andy From ietf-ppp-request@ucdavis.ucdavis.edu Thu Nov 12 15:48:37 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25815; Thu, 12 Nov 92 15:28:50 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08199; Thu, 12 Nov 92 14:11:30 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22473; Thu, 12 Nov 92 14:06:22 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22168; Thu, 12 Nov 92 13:58:06 -0800 Received: from remora.morningstar.com by volitans.morningstar.com (5.65a/92042102) id AA06608; Thu, 12 Nov 92 16:57:09 -0500 Received: by remora.morningstar.com (5.65a/91072901) id AA01667; Thu, 12 Nov 92 16:57:07 -0500 Date: Thu, 12 Nov 92 16:57:07 -0500 From: Karl Fox Message-Id: <9211122157.AA01667@remora.morningstar.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Confusion about CHAP Organization: Morning Star Technologies, Inc. At the recent PPP-athon hosted by Telebit (thanks, Mark!) some questions arose about how to implement CHAP. After talking to Bill Simpson and after reviewing RFCs 1334 and 1331, I would like to publicly voice my interpretation in order to force my opinions upon you all and crush any potential dissent. :-) The first question involved the use of the Name field in CHAP Challenge and Response packets. Although Bill and I implemented it correctly (:-), two other implementations present were sending empty Name fields in Challenge packets. Although I remember searching several times and had to rely on the weak `Well, Bill *intended* for it to work this way', I somehow managed to miss the shining sword contained in the following excerpt from 1334: 3.2.1. Challenge and Response ... A summary of the Challenge and Response packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value-Size | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Name The Name field is one or more octets representing the identification of the system transmitting the packet. There are no limitations on the content of this field. For example, it MAY contain ASCII character strings or globally unique identifiers in ASN.1 syntax. The Name should not be NUL or CR/LF terminated. The size is determined from the Length field. Since CHAP may be used to authenticate many different systems, the content of the name field(s) may be used as a key to locate the proper secret in a database of secrets. This also makes it possible to support more than one name/secret pair per system. Note that it says that the Name field identifies ``the system transmitting the packet.'' This means that a Challenge contains the name of the challenger, the system sending the Challenge packet, and the Response contains the name of the challenger's peer, the system sending the Response packet. Also notice that it says that the Name field contains ``one or more octets'', making an empty Name field illegal. We all ended up interoperating successfully by the end of the week, but since two others managed to incorrectly implement this in the same way, I wanted to prevent others from making the same mistake. The second question involved the transition from Link Establishment Phase to Authentication Phase to Network-Layer Protocol Phase. When one side includes the CHAP Authentication-Protocol in its LCP Configure-Request and the other does not, most implementations will wait until authentication is complete before sending NCP Configure-Requests, regardless of whether they requested CHAP or not. One person, however, showed me the following in RFC 1331: 4.5. Authentication Phase On some links it may be desirable to require a peer to authenticate itself before allowing network-layer protocol packets to be exchanged. By default, authentication is not necessary. If an implementation requires that the peer authenticate with some specific authentication protocol, then it MUST negotiate the use of that authentication protocol during Link Establishment phase. Authentication SHOULD take place as soon as possible after link establishment. However, link quality determination MAY occur concurrently. An implementation MUST NOT allow the exchange of link quality determination packets to delay authentication indefinitely. Advancement from the Authentication phase to the Network-Layer Protocol phase MUST NOT occur until the peer is successfully ^^^^^^^^^^^^^^ authenticated using the negotiated authentication protocol. In the event of failure to authenticate, PPP SHOULD proceed instead to the Link Termination phase. 4.6. Network-Layer Protocol Phase Once PPP has finished the previous phases, each network-layer protocol (such as IP) MUST be separately configured by the appropriate Network Control Protocol (NCP). This person claimed that, since the end that received the CHAP Authenticate-Request option was not going to authenticate *its* peer, that it was free to send NCP Configure-Requests immediately after bringing up LCP. Note that although this will usually cause no problems when using CHAP (since the authenticator will just discard the Configure-Requests), it doesn't even make sense with PAP, where the authenticated end must speak first. Since an argument can be made that the above RFC 1331 text can be interpreted to allow the offending behavior, Bill will make RFC 1331's successor say something like this: Advancement from the Authentication phase to the Network-Layer Protocol phase MUST NOT occur until authentication is completed using the negotiated authentication protocol. From ietf-ppp-request@aggie.ucdavis.edu Fri Nov 13 17:05:19 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22859; Fri, 13 Nov 92 16:57:39 -0800 Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA20820; Fri, 13 Nov 92 16:32:34 -0800 Sender: ietf-ppp-request@aggie.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07987; Fri, 13 Nov 92 10:10:53 -0800 Received: from harry.lloyd.com. by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA04583; Fri, 13 Nov 92 10:10:00 PST Date: Fri, 13 Nov 92 10:10:00 PST From: brian@lloyd.com (Brian Lloyd) Message-Id: <9211131810.AA04583@ray.lloyd.com> Received: by harry.lloyd.com. (4.1/SMI-4.1) id AA01308; Fri, 13 Nov 92 10:09:59 PST To: ietf-ppp@aggie.ucdavis.edu Subject: I can't attend Something has come up that will preclude my attendence at IETF next week. Since we need someone to moderate and since I will not be able to do so, I would like to request that Chris Ranch function as moderator of the working group in my absence. Could someone please take notes and keep me apraised of what transpires. One other item: we need a "subgroup" to work on a testing document, one that describes how to test a PPP implementation for "correctness". This would not be an attempt to circumvent bake-offs. We just need some way for implementors to pre-test their implementations before they go to a bake-off and to be able to quickly ascertain whether or not the impelemtnation has the more common errors. Brian Lloyd, President B.P. Lloyd & Associates, Inc. brian@lloyd.com 3420 Sudbury Road (916) 676-1147 - voice Cameron Park, CA 95682 (916) 676-3442 - fax From ietf-ppp-request@aggie.ucdavis.edu Fri Nov 13 18:08:29 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01620; Fri, 13 Nov 92 17:51:55 -0800 Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA21535; Fri, 13 Nov 92 17:29:19 -0800 Sender: ietf-ppp-request@aggie.ucdavis.edu Received: from bolero.rahul.net by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08421; Fri, 13 Nov 92 10:24:15 -0800 Received: by bolero.rahul.net id AA17234 (5.65c/IDA-1.4.4 for ietf-ppp@ucdavis.edu); Fri, 13 Nov 1992 10:22:52 -0800 Date: Fri, 13 Nov 1992 10:22:52 -0800 From: Timon Sloan Message-Id: <199211131822.AA17234@bolero.rahul.net> To: ietf-ppp@aggie.ucdavis.edu Subject: RFC 1331 zero-restart-counter action I have a question about the "Implementation Note" under the Zero-Restart-Counter (zrc) action in the RFC 1331, on page 25. The note states "This action enables the FSA to pause before proceeding to the desired final state. In addition to zeroing the Restart counter, the implementation MUST set the timeout period to an appropriate value." The question is, what is this timeout for? Is it to provide a pause for traffic to drain from the connection? Or is it a restart timer to wait for the return terminate-ack? In the note, what does "enables the FSA to pause before proceeding to the desired final state" mean? Is the pause during the course of the action action (ie, this action takes as long as the timeout), or is the pause in the FSA in general, until the purpose of the timeout is fulfilled? In other words, what is the result of the timeout? Thanks, Timon From ietf-ppp-request@aggie.ucdavis.edu Fri Nov 13 21:28:25 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01110; Fri, 13 Nov 92 21:20:05 -0800 Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA21741; Fri, 13 Nov 92 17:44:01 -0800 Sender: ietf-ppp-request@aggie.ucdavis.edu Received: from relay1.UU.NET by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11664; Fri, 13 Nov 92 11:51:48 -0800 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA16797; Fri, 13 Nov 92 14:47:26 -0500 Received: from lupine.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 144542.15516; Fri, 13 Nov 1992 14:45:42 EST Received: from verbosa.ncd.com by lupine.ncd.com (4.1/SMI-4.1) id AA24296; Fri, 13 Nov 92 09:29:32 PST Received: from [127.0.0.1] by verbosa.ncd.com (5.65/NCD-1.0c) id AA23592; Fri, 13 Nov 92 09:46:05 -0800 Message-Id: <9211131746.AA23592@verbosa.ncd.com> To: ietf-ppp@aggie.ucdavis.edu Cc: bob@morningstar.com Subject: Image Compression Formats, PPP, and Low Bandwidth X (LBX) Organization: Network Computing Devices, Mountain View, CA Date: Fri, 13 Nov 92 09:46:03 PST From: Jim Fulton Hello, Bob Sutterfield of Morningstar suggested that I contact this address and introduce myself. I am one of the co-architects of the X Consortium's effort to define a standard for running the X protocol over serial lines and other low-bandwidth channels. Our goal is to have LBX (Low Bandwidth X) in place by the end of 1993, when R6 will be released by the X Consortium. I can provide more details, if desired, but a very rough outline of the architecture is as follows: o LBX will be a virtual byte-stream protocol that will assume some sort of reliable transport. In TCP environments this will presumably be done over PPP or CSLIP. o Applications will connect to a "proxy" that pretends to be an X server; this proxy will act as an X <--> LBX protocol bridge. There will be a similar type of bridge at the other end (and may, in fact, be built directly into the X server). o The LBX protocol uses a variety of techniques to reduce the amount of data that has to be transmitted over the low-bandwidth line: caching of common data, deltas against preceeding packets, tighter encoding of the X protocol, compression of image data (e.g. CCITT Group 4), and negotiable stream compression of the whole protocol stream (e.g. LZW). Although LBX will not be specific to PPP, we certainly will want to take advantage of any special capabilities that it may provide (particularly the ability to dynamically advise the link level when not to bother trying to compress the data stream [typically because it has already been compressed, e.g. imbedded image data]). Feel free to contact me should you ever desire additional information, which to make suggestions, etc. Jim Fulton Network Computing Devices 350 N. Bernardo Ave. Mountain View, CA 94043 jim@ncd.com 415-691-2119 From ietf-ppp-request@ucdavis.ucdavis.edu Fri Nov 13 21:54:30 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02299; Fri, 13 Nov 92 21:49:37 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA22935; Fri, 13 Nov 92 21:31:21 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01184; Fri, 13 Nov 92 21:22:16 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from lager.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00691; Fri, 13 Nov 92 21:10:03 -0800 Received: by lager.cisco.com; Fri, 13 Nov 92 18:36:52 -0800 From: Sanjeev Newarikar Message-Id: <9211140236.AA04794@lager.cisco.com> Subject: parameter negotiation for FR To: sklower@cs.berkeley.edu Date: Fri, 13 Nov 92 18:36:51 PST Cc: iplpdn@cnri.reston.va.us, ietf-ppp@ucdavis.ucdavis.edu X-Mailer: ELM [version 2.3 PL11] --Hi Keith, Here are my comments on using PPP over FR for parameter negotiation. Running PPP "as is" over FR may not be a good idea because : 1) LCP : Most of the LCP options are not really applicable. So, it is more of an overhead compared to the net gain of using LCP options. a) MTU negotiation option may not be applicable because you are going thru a FR cloud and the cloud must support a large enough MTU for end-to-end MTU negotiation to be meaningful. It probably makes more sense to discover the MTU thru LMI ( lmi will have to be modified in this case though ) msg. instead from the switch rather than end-to-end. b) You can detect loops by seeing your own keepalives with the same seq. no. in it, so Magic no. option doesn't provide any greater benefit. c) You don't do async FR. d) Sensing the line condition based on lost keepalives may not be a very perfect mechanism, but is LQM really worth running over FR and is LCP negotiation just for negotiating LQM really worth it ? Is running LQM that important and necessary ? b) NCP's : Running seperate NCP's for each protocol is quite an ovcerhead especially when you have hundreds of PVC's, But, a few NCP's are NULL NCP's and don't really provide any great information that may be required for FR. 1) IPXCP would let only header compression to be negotiated since IP addresses would be found out using Inverse Arp. This doesn't stop a black hole where routing protocols could be misconfigured and can not be detected. But if you have an option to negotiate routing protocol, it would be useful for FR to group them for psuedo-mcast. avoiding unnecessary flooding. 2) OSI padding option is not of any use because FR provides a padding scheme which doesn't even have to ne negotiated. 3) DECCP is just a NULL NCP and XNS and VINES don't even have drafts. In essense running PPP "as is" doesn't seem very benificial except for the fact that you can have a NCP for bridging ( and currently there is no way for negotiating bridging over FR ) and few other negotiations which probably is more of an overhead considering the benefits obtained using it. Secondly, if you still want to figure out addresses using Inverse Arp then advantage of using NCP's is insignificant. ( I can also figure out which protocols are being routed on which PVC with InArp, that's is probably a plus when considering usage of NULL NCP's ) So, In my opinion PPP "as is" is out of question. What i would like to suggest... 1) Don't use LCP at all. ( Gee...asking for flames huh ? ) 2) Bundle all NCP's in just one NCP. And secondly PPP group should be flexible enough to add more parameters to the NCP's if required for FR. Or inventing a new protocol for FR parameter negotiation may be worth considering ??? Flames ? Comments ? --sanjeev +-------------------------------------------------------+ | "...The painted veil which those who live call Life." | +-------------------------------------------------------+ From ietf-ppp-request@ucdavis.ucdavis.edu Sat Nov 14 11:00:45 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12345; Sat, 14 Nov 92 10:56:43 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA25206; Sat, 14 Nov 92 10:42:29 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11262; Sat, 14 Nov 92 10:34:01 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10837; Sat, 14 Nov 92 10:25:04 -0800 Received: by saffron.acc.com (4.1/SMI-4.1) id AA03295; Sat, 14 Nov 92 10:24:27 PST Date: Sat, 14 Nov 92 10:24:27 PST From: fbaker@acc.com (Fred Baker) Message-Id: <9211141824.AA03295@saffron.acc.com> To: sanjeev@cisco.com Subject: Re: parameter negotiation for FR Cc: ietf-ppp@ucdavis.ucdavis.edu, iplpdn@CNRI.Reston.VA.US We have come full circle. When Microcom started trying to talk about FR negotiations, they were talking about a rather simplistic protocol which might be well described as >> 2) Bundle all NCP's in just one NCP. It also depended on LMI/Annex D to configure the link, which is another way of saying >> 1) Don't use LCP at all. Personally, I think that's an excellent approach. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 16 07:20:51 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20210; Mon, 16 Nov 92 07:19:42 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA03994; Mon, 16 Nov 92 06:50:35 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18544; Mon, 16 Nov 92 06:41:05 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from nero.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18363; Mon, 16 Nov 92 06:36:44 -0800 Received: by nero.clearpoint.com (4.1/1.34) id AA06868; Mon, 16 Nov 92 09:34:48 EST Date: Mon, 16 Nov 92 09:34:48 EST From: martillo@nero.clearpoint.com (Joachim Martillo) Message-Id: <9211161434.AA06868@nero.clearpoint.com> To: lupine!jim@uunet.uu.net Cc: ietf-ppp@ucdavis.ucdavis.edu, bob@morningstar.com In-Reply-To: Jim Fulton's message of Fri, 13 Nov 92 09:46:03 PST <9211131746.AA23592@verbosa.ncd.com> Subject: Image Compression Formats, PPP, and Low Bandwidth X (LBX) Are you the Jim Fulton who used to work at Project Athena. Joachim Martillo From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 16 08:57:46 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23457; Mon, 16 Nov 92 08:46:32 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04426; Mon, 16 Nov 92 08:00:36 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21484; Mon, 16 Nov 92 07:52:47 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from uu5.psi.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21284; Mon, 16 Nov 92 07:47:21 -0800 Received: by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA14589; Mon, 16 Nov 92 10:46:05 -0500 Date: Mon, 16 Nov 92 10:36:12 EST From: hhs@teleoscom.com (Chip Sharp 6424) Received: by teleoscom.com (4.1/3.2.083191-Teleos Communications Inc.) id AA17366; Mon, 16 Nov 92 10:36:12 EST Message-Id: <9211161536.AA17366@teleoscom.com> To: art@opal.acc.com Cc: ietf-ppp@ucdavis.ucdavis.edu, iplpdn@CNRI.Reston.VA.US In-Reply-To: Art Berggreen's message of Thu, 12 Nov 92 10:59:37 PST <9211121859.AA04350@opal.acc.com> Subject: IPLPDN PPP draft >In the real world, many places can only get X.25 service for WAN connections. >Here it makes sense to use PPP frames over X.25 VCs to perform multiprotocol >interconnection between routers. Correct me if I am wrong, but I thought that this is what the Multiprotocol over X.25 work in the IPLPDN was for. ======================================================================= Hascall H. Sharp Teleos Communications, Inc. System Engineering 2 Meridian Road Eatontown, NJ 07724 voice: +1 908 544 6424 fax: +1 908 544 9890 email: hhs@teleoscom.com ======================================================================== From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 16 17:58:25 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02002; Mon, 16 Nov 92 17:48:54 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07321; Mon, 16 Nov 92 11:52:31 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00631; Mon, 16 Nov 92 11:45:25 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from OPAL.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29865; Mon, 16 Nov 92 11:29:54 -0800 Received: by opal.acc.com (4.1/SMI-4.0) id AA09567; Mon, 16 Nov 92 11:30:55 PST Date: Mon, 16 Nov 92 11:30:55 PST From: art@opal.acc.com (Art Berggreen) Message-Id: <9211161930.AA09567@opal.acc.com> To: hhs@teleoscom.com Subject: Re: IPLPDN PPP draft Cc: ietf-ppp@ucdavis.ucdavis.edu, iplpdn@CNRI.Reston.VA.US > >>In the real world, many places can only get X.25 service for WAN connections. >>Here it makes sense to use PPP frames over X.25 VCs to perform multiprotocol >>interconnection between routers. > >Correct me if I am wrong, but I thought that this is what the >Multiprotocol over X.25 work in the IPLPDN was for. I was probably too brief in the noted message. RFC-1356 specifies a way of identifying which protocols are being used over VCs. Included is a way of specifying multiplexing of protocols over a single VC. In the multiplexed case, each packet (complete M-bit sequence) begins with another NLPID octet. The guidelines for using this mode are not very detailed, and there is no provision to negotiate which protocols can be run over the shared VC. There is also no provision to exchange protocol specific negoatiation information in either the shared VC or dedicated VC cases. The use of PPP frames for at least negotiation (PPP NCPs) might be useful. In the shared VC case, an argument could be made for sending all frames in PPP format (or at least a subset). Note, that I'm not neccessarily a proponent, just pointing out a possibility. In many situations, there is a cost benefit to reducing the total number of VCs needed for operation. Since it is common for X.25 carriers to charge on 64 byte "segments" (whether full or not), it may have little impact on the packet based costs to have slightly longer packets. It all depends on the nature of the carrier and the user's traffic. Art From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 16 21:11:35 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09197; Mon, 16 Nov 92 21:00:19 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA12750; Mon, 16 Nov 92 20:40:34 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08153; Mon, 16 Nov 92 20:30:37 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07904; Mon, 16 Nov 92 20:24:37 -0800 Received: from na.SJF.Novell.COM by newsun.Novell.COM (4.1/SMI-4.1) id AA04915; Mon, 16 Nov 92 20:23:54 PST Received: by na.SJF.Novell.COM (4.1/SMI-4.1) id AA06018; Mon, 16 Nov 92 20:23:24 PST Date: Mon, 16 Nov 92 20:23:24 PST From: Christopher_Ranch@Novell.COM (Christopher Ranch) Message-Id: <9211170423.AA06018@na.SJF.Novell.COM> To: brian@lloyd.com, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: I can't attend Hi Brian, > From: brian@lloyd.com (Brian Lloyd) > > Something has come up that will preclude my attendence at IETF next > week. Since we need someone to moderate and since I will not be able > to do so, I would like to request that Chris Ranch function as > moderator of the working group in my absence. Well, it's Monday night 11:20 pm, and I'm just now reading this. I'd be happy to for the first session, but will not be around for the second. However, after talking with Fred Baker this evening, he did not have anyting new for the compression stuff. > Could someone please take notes and keep me apraised of what > transpires. I'I'll volunteer someone. Mark?!? :) > One other item: we need a "subgroup" to work on a testing document, > one that describes how to test a PPP implementation for "correctness". > This would not be an attempt to circumvent bake-offs. We just need > some way for implementors to pre-test their implementations before > they go to a bake-off and to be able to quickly ascertain whether or > not the impelemtnation has the more common errors. I'll bring this up. Chris From ietf-ppp-request@ucdavis.ucdavis.edu Tue Nov 17 06:40:45 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01525; Tue, 17 Nov 92 06:30:15 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA14881; Tue, 17 Nov 92 05:50:35 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29450; Tue, 17 Nov 92 05:41:49 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29315; Tue, 17 Nov 92 05:38:09 -0800 Received: from remora.morningstar.com by volitans.morningstar.com (5.65a/92042102) id AA24147; Tue, 17 Nov 92 08:37:31 -0500 Received: by remora.morningstar.com (5.65a/91072901) id AA10037; Tue, 17 Nov 92 08:37:18 -0500 Date: Tue, 17 Nov 92 08:37:18 -0500 From: Karl Fox Message-Id: <9211171337.AA10037@remora.morningstar.com> To: Timon Sloan Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: RFC 1331 zero-restart-counter action References: <199211131822.AA17234@bolero.rahul.net> Organization: Morning Star Technologies, Inc. Timon Sloan writes: > > I have a question about the "Implementation Note" under the > Zero-Restart-Counter (zrc) action in the RFC 1331, on page 25. > > The note states > > "This action enables the FSA to pause before proceeding to the > desired final state. In addition to zeroing the Restart > counter, the implementation MUST set the timeout period to an > appropriate value." > > The question is, what is this timeout for? Is it to provide a pause for > traffic to drain from the connection? Yes. > Or is it a restart timer to wait for the return terminate-ack? There won't be a Terminate-Ack -- the local end just send a Terminate-Ack in response to a Terminate-Request. > In the note, what does "enables the FSA to pause before proceeding to > the desired final state" mean? Is the pause during the course > of the action action (ie, this action takes as long as the timeout), > or is the pause in the FSA in general, until the purpose of the timeout > is fulfilled? It means you sit in state 5 (Stopping) for one timeout period before moving on to state 3 (Stopped). > In other words, what is the result of the timeout? It does a tlf and shuts down the link. > Thanks, > Timon From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 18 16:18:08 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21354; Wed, 18 Nov 92 16:09:37 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA03499; Wed, 18 Nov 92 14:21:54 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16291; Wed, 18 Nov 92 14:11:22 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from inet-gw-1.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14538; Wed, 18 Nov 92 13:29:31 -0800 Received: by inet-gw-1.pa.dec.com; id AA06001; Wed, 18 Nov 92 13:28:24 -0800 Received: by tl.lkg.dec.com (5.57/cgg-100491); id AA11079; Wed, 18 Nov 92 16:28:18 -0500 Subject: Patent License Package for 48 bit CRC To: ietf-ppp@ucdavis.ucdavis.edu, iab@ISI.EDU X-Mailer: Poste 2.0 From: Tony Lauck Date: Wed, 18 Nov 92 16:28:07 -0500 Message-Id: <921118162807.11001@tl.lkg.dec.com> For your information, here is the package which Digital is providing for PPP licensing. This package is operative, effective immediately and may be given to any interested parties. For future reference, this file will be stored on-line in a public directory at Digital. I will be announcing the file name shortly. Tony Lauck From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 18 17:02:50 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22925; Wed, 18 Nov 92 16:54:12 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04047; Wed, 18 Nov 92 15:11:19 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18304; Wed, 18 Nov 92 14:58:01 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from LOBSTER.WELLFLEET.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16799; Wed, 18 Nov 92 14:23:03 -0800 Received: from ginzo.wellfleet ([192.32.1.233]) by lobster.wellfleet.com (4.1/SMI-4.1) id AA09728; Wed, 18 Nov 92 17:18:14 EST Received: by ginzo.wellfleet (4.1/SMI-4.1) id AA10922; Wed, 18 Nov 92 17:27:37 EST From: ginsburg@wellfleet.com (Scott Ginsburg) Message-Id: <9211182227.AA10922@ginzo.wellfleet> Subject: LQR Reporting Period To: ietf-ppp@ucdavis.ucdavis.edu Date: Wed, 18 Nov 92 17:27:35 EST X-Mailer: ELM [version 2.3 PL11] Is the LQR Reporting-Period that I include in my Configure-Request packet the value I want to use for my LQR transmission timer, or a suggestion for my peer's timer? Thanks, Scott -- Scott Ginsburg Voice: 617-280-2336 Wellfleet Communications Internet: ginsburg@wellfleet.com 15 Crosby Drive Amateur Radio: WA2CJT Bedford, MA 01730 From ietf-ppp-request@ucdavis.ucdavis.edu Thu Nov 19 17:20:36 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29725; Thu, 19 Nov 92 16:45:48 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA18066; Thu, 19 Nov 92 15:40:04 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25659; Thu, 19 Nov 92 15:23:45 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25176; Thu, 19 Nov 92 15:13:12 -0800 From: itdavid@ucdavis.ucdavis.edu (David Arredondo) Date: Thu, 19 Nov 92 15:13:12 -0800 Message-Id: <9211192313.AA25176@ucdavis.ucdavis.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: ---------------------- Forwarded Message Follows ---------------------- Received: from ns.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05567; Wed, 18 Nov 92 21:53:38 -0800 Received: by ns.Novell.COM (4.1/SMI-4.1) id AA20833; Wed, 18 Nov 92 22:52:58 MST Received: by MHS.Novell.COM id D7FF0A2B81FA0070; Wed, 18 Nov 92 22:52:58 MST Return-Path: <@> Precedence: first-class X-Date-Posted: 18-Nov-1992 21:45:41 -0500; at sjf-mail-engr.Novell X-Addresses-Referred-To: MALLEN@Novell X-Error-Report: 255 X-Smf-Version: 70 Date: To: ietf-ppp-request@ucdavis.edu From: @@Novell.COM Message-Id: X-Notification-Correlator: 279D0A2B81F401D0 X-Rejected-For: Michael Allen@Novell, origin NGM, event# 136, subevent#0, explanation unsupported application version Subject: Notification. X-Via-Host: sjf-engr.sjf-engr X-Re-Sent-By: -maiser-@Novell; on 18-Nov-1992 21:45:41 -0500 X-Date-Posted: 18-Nov-92 20:03:45 X-Date-Transferred: 18-Nov-1992 21:45:41 -0500; at sjf-mail-engr.Novell Return-Path: Precedence: first-class X-Received: by mhs.Novell.COM id Ux17453; Wed, 18 Nov 92 19:44:50 MST X-Received: from aggie.ucdavis.edu by ns.Novell.COM (4.1/SMI-4.1) id AA17450; Wed, 18 Nov 92 19:44:44 MST X-Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06377; Wed, 18 Nov 92 18:11:26 -0800 X-Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25709; Wed, 18 Nov 92 18:03:06 -0800 X-Sender: ietf-ppp-request@ucdavis.edu X-Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25366; Wed, 18 Nov 92 17:54:55 -0800 X-Received: from by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AB03336; Wed, 18 Nov 92 17:54:16 PST X-Message-Id: <9211190154.AB03336@ray.lloyd.com> Date: Wed, 18 Nov 92 18:54:06 MST To: ietf-ppp@ucdavis.edu From: brian@lloyd.com Subject: today's IETF PPP WG mtg Message-Id: <279D0A2B81F401D0@MHS.Novell.COM> X-Via-Host: nov-gate.novell Could someone please let me know what went down in the meeting today? If someone will give me a phone number, I will call on my nickel. Brian Lloyd, President B.P. Lloyd & Associates, Inc. brian@lloyd.com 3420 Sudbury Road (916) 676-1147 - voice Cameron Park, CA 95682 (916) 676-3442 - fax From ietf-ppp-request@ucdavis.ucdavis.edu Fri Nov 20 14:46:28 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08205; Fri, 20 Nov 92 14:25:03 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08480; Fri, 20 Nov 92 13:59:26 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06923; Fri, 20 Nov 92 13:42:56 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vnet.ibm.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06783; Fri, 20 Nov 92 13:33:12 -0800 Message-Id: <9211202133.AA06783@ucdavis.ucdavis.edu> Received: from RALVM11 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 6943; Fri, 20 Nov 92 16:28:12 EST Date: Fri, 20 Nov 92 14:24:29 EST From: "Rich Bowen" To: ietf-ppp@ucdavis.ucdavis.edu Subject: Protocol type for source-route bridge BPDUs RFC 1220 defines bridging over PPP basically via two mechanisms: 1. Bridged data frames are encapsulated in a header that contains the MAC type of the frame and protocol type 0x0031. 2. IEEE 802.1d spanning tree Bridge Protocol Data Units (BPDUs) are encapsulated in a frame with protocol type 0x0201. These mechanisms are adequate as long as one has implemented only a single bridge at each end of the link. We have found that many of our customers need Token-Ring to Token- Ring source-route bridges and many others need Ethernet to Ethernet transparent bridges. In addition, there are customers who need both types of bridges. As a result, we are implementing the following function in the IBM 6611. The customer may operate both the Token-Ring bridge and the Ethernet bridge simultaneously: --------------- -------------- | Token-Ring 1 | | Token-Ring 2 | --------------- \ / -------------- \ ---------------------/ | Token-Ring bridge | PPP link |---------------------| <----------------> | Ethernet bridge | /---------------------\ Ethernet 1 | / \ | Ethernet 2 -------------------- -------------------- | | | | Frames are not bridged from Token-Ring to Ethernet in this case. The PPP link in the figure is used by both bridges and connects to another IBM 6611 that is similarly configured. Traffic from both bridges is passed over a single PPP link since it would be inefficient for the customer to have to use two parallel PPP links. The problem in this case is that there is no way to distinguish the source-route bridge BPDUs from the transparent (IEEE) bridge BPDUs since RFC 1220 specifies only the IEEE BPDU protocol type. Distinguishing the bridged data traffic of the two bridges in this case is not a problem since one bridge is Ethernet only and the other is Token-Ring only. We would like to use a new protocol type for the source-route bridge spanning tree protocol (as opposed to the IEEE 802.1d spanning tree protocol). It was recently decided in the IEEE 802 committees that the source route spanning tree will remain a separate tree from the IEEE 802.1d spanning tree (there was initially work toward concatenating them), so it seems reasonable to have a separate protocol type. I would appreciate comments on this proposal. Regards, Rich (919) 543-9851 Network Bridge Development IBM Networking Systems Research Triangle Park, NC USA From ietf-ppp-request@ucdavis.ucdavis.edu Fri Nov 20 18:46:19 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01087; Fri, 20 Nov 92 18:05:17 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA10963; Fri, 20 Nov 92 16:48:08 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14501; Fri, 20 Nov 92 16:37:10 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13308; Fri, 20 Nov 92 16:01:14 -0800 From: itdavid@ucdavis.ucdavis.edu (David Arredondo) Date: Fri, 20 Nov 92 16:01:14 -0800 Message-Id: <9211210001.AA13308@ucdavis.ucdavis.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: ---------------------- Forwarded Message Follows ---------------------- Received: from ns.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26587; Thu, 19 Nov 92 15:42:20 -0800 Received: by ns.Novell.COM (4.1/SMI-4.1) id AA14572; Thu, 19 Nov 92 16:41:38 MST Received: by MHS.Novell.COM id 65F20B2B81FA0070; Thu, 19 Nov 92 16:41:37 MST Return-Path: <@> Precedence: first-class X-Date-Posted: 19-Nov-1992 15:37:03 -0500; at sjf-mail-engr.Novell X-Addresses-Referred-To: MALLEN@Novell X-Error-Report: 255 X-Smf-Version: 70 Date: To: ietf-ppp-request@ucdavis.edu From: @@Novell.COM Message-Id: <64F20B2B81FA0070@sjf-mail-engr.Novell@MHS.Novell.COM> X-Nvlipm-Report-Syntax: NGM X-Nvlipm-Report-Event: 280 X-Nvlipm-Report-Subevent: 11 X-Notification-Correlator: 43C20B2B81F401D0 Subject: Hop count excessive X-Rejected-For: Michael Allen@Novell X-Via-Host: sjf-engr.sjf-engr X-Re-Sent-By: -maiser-@Novell; on 19-Nov-1992 15:37:02 -0500 X-Date-Posted: 19-Nov-92 16:27:55 Return-Path: Precedence: first-class X-Received: by mhs.Novell.COM id Ux12364; Thu, 19 Nov 92 15:28:16 MST X-Received: from aggie.ucdavis.edu by ns.Novell.COM (4.1/SMI-4.1) id AA12360; Thu, 19 Nov 92 15:28:02 MST X-Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA16410; Thu, 19 Nov 92 13:53:56 -0800 X-Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20599; Thu, 19 Nov 92 13:43:53 -0800 X-Sender: ietf-ppp-request@ucdavis.edu X-Received: from LOBSTER.WELLFLEET.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19812; Thu, 19 Nov 92 13:23:50 -0800 X-Received: from ginzo.wellfleet ([192.32.1.233]) by lobster.wellfleet.com (4.1/SMI-4.1) id AA11784; Thu, 19 Nov 92 16:18:57 EST X-Received: by ginzo.wellfleet (4.1/SMI-4.1) id AA12985; Thu, 19 Nov 92 16:28:24 EST From: ginsburg@wellfleet.com (Scott Ginsburg) X-Message-Id: <9211192128.AA12985@ginzo.wellfleet> Subject: Re: LQR Reporting Period To: karl@MorningStar.Com Date: Thu, 19 Nov 92 14:28:22 MST Cc: ietf-ppp@ucdavis.edu X-In-Reply-To: <9211192116.AA05249@remora.morningstar.com>; from "Karl Fox" at Nov 19, 92 4:16 pm X-Mailer: ELM [version 2.3 PL11] Message-Id: <43C20B2B81F401D0@MHS.Novell.COM> X-Via-Host: nov-gate.novell > Scott Ginsburg writes: > > > > Is the LQR Reporting-Period that I include in my Configure-Request > > packet the value I want to use for my LQR transmission timer, or a suggestion > > for my peer's timer? > > It's the maximum time between LQRs transmitted by the peer. Whether it > is also the value you would like to use for your own timer is up to you > (that's how I do it). What is the general practice with regard to negotiating the value? For example, if peer A is configured with a 1 second period, and peer B a 2 second period, should B negotiate down to A, or vice versa, or is it better to require both sides to be configured with the same value from the start before converging? Thanks, Scott -- Scott Ginsburg Voice: 617-280-2336 Wellfleet Communications Internet: ginsburg@wellfleet.com 15 Crosby Drive Amateur Radio: WA2CJT Bedford, MA 01730 From ietf-ppp-request@ucdavis.ucdavis.edu Fri Nov 20 19:50:26 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02581; Fri, 20 Nov 92 18:45:04 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA00423; Fri, 20 Nov 92 18:10:20 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00599; Fri, 20 Nov 92 17:54:59 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13375; Fri, 20 Nov 92 16:03:00 -0800 From: itdavid@ucdavis.ucdavis.edu (David Arredondo) Date: Fri, 20 Nov 92 16:03:00 -0800 Message-Id: <9211210003.AA13375@ucdavis.ucdavis.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: ---------------------- Forwarded Message Follows ---------------------- Received: from ns.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26594; Thu, 19 Nov 92 15:42:24 -0800 Received: by ns.Novell.COM (4.1/SMI-4.1) id AA14606; Thu, 19 Nov 92 16:41:44 MST Received: by MHS.Novell.COM id 6BF20B2B81FA0070; Thu, 19 Nov 92 16:41:43 MST Return-Path: <@> Precedence: first-class X-Date-Posted: 19-Nov-1992 15:37:45 -0500; at sjf-mail-engr.Novell X-Addresses-Referred-To: MALLEN@Novell X-Error-Report: 255 X-Smf-Version: 70 Date: To: ietf-ppp-request@ucdavis.edu From: @@Novell.COM Message-Id: <6AF20B2B81FA0070@sjf-mail-engr.Novell@MHS.Novell.COM> X-Nvlipm-Report-Syntax: NGM X-Nvlipm-Report-Event: 280 X-Nvlipm-Report-Subevent: 11 X-Notification-Correlator: E1C20B2B81F401D0 Subject: Hop count excessive X-Rejected-For: Michael Allen@Novell X-Via-Host: sjf-engr.sjf-engr X-Re-Sent-By: -maiser-@Novell; on 19-Nov-1992 15:37:45 -0500 X-Date-Posted: 19-Nov-92 16:32:21 Return-Path: Precedence: first-class X-Received: by mhs.Novell.COM id Ux14214; Thu, 19 Nov 92 16:30:22 MST X-Received: from aggie.ucdavis.edu by ns.Novell.COM (4.1/SMI-4.1) id AA14211; Thu, 19 Nov 92 16:30:15 MST X-Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA16830; Thu, 19 Nov 92 14:12:58 -0800 X-Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21609; Thu, 19 Nov 92 14:06:34 -0800 X-Sender: ietf-ppp-request@ucdavis.edu X-Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20917; Thu, 19 Nov 92 13:49:55 -0800 X-Received: from remora.morningstar.com by volitans.morningstar.com (5.65a/92042102) id AA12856; Thu, 19 Nov 92 16:48:52 -0500 X-Received: by remora.morningstar.com (5.65a/91072901) id AA05404; Thu, 19 Nov 92 16:48:47 -0500 Date: Thu, 19 Nov 92 14:48:47 MST From: karl@MorningStar.Com (Karl Fox) X-Message-Id: <9211192148.AA05404@remora.morningstar.com> To: ginsburg@wellfleet.com (Scott Ginsburg) Cc: ietf-ppp@ucdavis.edu Subject: Re: LQR Reporting Period X-References: <9211192116.AA05249@remora.morningstar.com> <9211192128.AA12985@ginzo.wellfleet> X-Organization: Morning Star Technologies, Inc. Message-Id: X-Via-Host: nov-gate.novell Scott Ginsburg writes: > What is the general practice with regard to negotiating the value? For > example, if peer A is configured with a 1 second period, and peer B a > 2 second period, should B negotiate down to A, or vice versa, or is it > better to require both sides to be configured with the same value from > the start before converging? It doesn't really matter, because the two ends will tend to transmit at about the same rate regardless of what timer values are negotiated. >From RFC 1333, section 2.7: In addition, a LQR is generated whenever two successive LQRs are received which have the same PeerInLQRs value. This may indicate that a LQR has been missed, or that the implementation is sending at a significantly slower rate than the peer, or that the peer has accelerated LQR generation to better quantify errors on the link. Whenever a LQR is sent, the LQR timer MUST be restarted. From ietf-ppp-request@ucdavis.ucdavis.edu Fri Nov 20 20:20:29 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05221; Fri, 20 Nov 92 19:50:41 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01011; Fri, 20 Nov 92 19:08:03 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02960; Fri, 20 Nov 92 18:53:44 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02197; Fri, 20 Nov 92 18:33:51 -0800 From: itdavid@ucdavis.ucdavis.edu (David Arredondo) Date: Fri, 20 Nov 92 18:33:51 -0800 Message-Id: <9211210233.AA02197@ucdavis.ucdavis.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: ---------------------- Forwarded Message Follows ---------------------- Received: from netmail.microsoft.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00539; Mon, 16 Nov 92 11:44:06 -0800 Received: from ingate.microsoft.com by netmail.microsoft.com with SMTP (5.65/25-eef) id AA13710; Mon, 16 Nov 92 11:40:59 -0800 Received: from microsoft by ingate.microsoft.COM id aa26949; Mon, 16 Nov 92 11:45:26 PST X-Msmail-Message-Id: EABDEEAE X-Msmail-Conversation-Id: EABDEEAE X-Msmail-Wiseremark: Microsoft Mail -- 3.0.729 From: Thomas Dimitri To: ietf-ppp-request@ucdavis.edu Date: Mon, 29 Nov 92 10:11:07 PST Subject: RE: Image Compression Formats, PPP, and Low Bandwidth X (LBX) Message-Id: <9211161145.aa26949@ingate.microsoft.COM> Yes, I'm very interested in more information and may even make some suggestions. Feel free to send me more information. --Thomas ---------- |From: Jim Fulton |To: |Cc: |Subject: Image Compression Formats, PPP, and Low Bandwidth X (LBX) |Date: Fri, Nov 13, 1992 9:46AM | | |Hello, | |Bob Sutterfield of Morningstar suggested that I contact this address |and introduce myself. I am one of the co-architects of the X Consortium's |effort to define a standard for running the X protocol over serial lines |and other low-bandwidth channels. Our goal is to have LBX (Low Bandwidth X) |in place by the end of 1993, when R6 will be released by the X Consortium. | |I can provide more details, if desired, but a very rough outline of the |architecture is as follows: | | o LBX will be a virtual byte-stream protocol that will assume some | sort of reliable transport. In TCP environments this will presumably | be done over PPP or CSLIP. | | o Applications will connect to a "proxy" that pretends to be an | X server; this proxy will act as an X <--> LBX protocol bridge. | There will be a similar type of bridge at the other end (and | may, in fact, be built directly into the X server). | | o The LBX protocol uses a variety of techniques to reduce the amount | of data that has to be transmitted over the low-bandwidth line: | caching of common data, deltas against preceeding packets, | tighter encoding of the X protocol, compression of image data | (e.g. CCITT Group 4), and negotiable stream compression of the | whole protocol stream (e.g. LZW). | |Although LBX will not be specific to PPP, we certainly will want to take |advantage of any special capabilities that it may provide (particularly the |ability to dynamically advise the link level when not to bother trying to |compress the data stream [typically because it has already been compressed, |e.g. imbedded image data]). | |Feel free to contact me should you ever desire additional information, |which to make suggestions, etc. | | Jim Fulton | Network Computing Devices | 350 N. Bernardo Ave. | Mountain View, CA 94043 | | jim@ncd.com | 415-691-2119 | | From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 23 06:01:03 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02912; Mon, 23 Nov 92 05:59:32 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA03757; Mon, 23 Nov 92 05:39:39 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01980; Mon, 23 Nov 92 05:30:27 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from mts-gw.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01881; Mon, 23 Nov 92 05:28:07 -0800 Received: by mts-gw.pa.dec.com; id AA01477; Mon, 23 Nov 92 05:27:30 -0800 Message-Id: <9211231327.AA01477@mts-gw.pa.dec.com> Received: from eider.enet; by decpa.enet; Mon, 23 Nov 92 05:27:30 PST Date: Mon, 23 Nov 92 05:27:30 PST From: Jesse Walker To: ietf-ppp@ucdavis.ucdavis.edu Apparently-To: ietf-ppp@ucdavis.edu Subject: Do we want an IPCP Nameserver Option? Host systems attaching to a remote IP network via a router or network access server really need (at least) two pieces of information to allow their users' to participate effectively in the new network: a. an IP address b. the IP address of a name server IPCP allows PPP hosts to negotiate the former, but not the latter. I cannot recall any consideration being given to providing an IPCP option to negotiate name server addresses as well. Is there any interest in defining one? If so, I will write up a strawman proposal. Jesse Walker Digital Equipment Corporation Networks and Communication Littleton, MA (508) 486-7326 From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 23 08:20:39 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05182; Mon, 23 Nov 92 08:13:39 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AB04362; Mon, 23 Nov 92 07:49:41 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04626; Mon, 23 Nov 92 07:41:02 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from babyoil.ftp.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04570; Mon, 23 Nov 92 07:36:04 -0800 Received: by ftp.com id AA22959; Mon, 23 Nov 92 10:34:50 -0500 Date: Mon, 23 Nov 92 10:34:50 -0500 Message-Id: <9211231534.AA22959@ftp.com> To: walker@eider.ENET.dec.com Subject: Re: Do we want an IPCP Nameserver Option? From: kasten@ftp.com (Frank Kastenholz) Cc: ietf-ppp@ucdavis.ucdavis.edu Jesse, Interesting idea. The Dynamic Host Configuration and Service Location Protocol working groups _should_ be working on this. We do not need to re-invent the wheel. Go beat up on them. > Host systems attaching to a remote IP network via a router or network access > server really need (at least) two pieces of information to allow their > users' to participate effectively in the new network: > > a. an IP address > > b. the IP address of a name server > > IPCP allows PPP hosts to negotiate the former, but not the latter. I > cannot recall any consideration being given to providing an IPCP > option to negotiate name server addresses as well. Is there any > interest in defining one? If so, I will write up a strawman proposal. -- Frank Kastenholz From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 23 09:22:05 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06570; Mon, 23 Nov 92 09:12:31 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04935; Mon, 23 Nov 92 08:50:30 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06023; Mon, 23 Nov 92 08:48:42 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from fats.proteon.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05801; Mon, 23 Nov 92 08:38:17 -0800 Received: from mcgarret.proteon.com by fats.proteon.com (4.1/Proteon-1.5) id AA22504; Mon, 23 Nov 92 11:38:13 EST Date: Mon, 23 Nov 92 11:38:13 EST From: jas@proteon.com (John A. Shriver) Message-Id: <9211231638.AA22504@fats.proteon.com> Received: by mcgarret.proteon.com (4.1/SMI-4.1) id AA00488; Mon, 23 Nov 92 11:37:41 EST To: RKB@RALVM11.VNET.IBM.COM Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: "Rich Bowen"'s message of Fri, 20 Nov 92 14:24:29 EST <9211202133.AA06783@ucdavis.ucdavis.edu> Subject: Protocol type for source-route bridge BPDUs? Your message leaves me extremely confused. I've been following 802.5 bridging for years, and as last I saw it, it was converging on the SRT standard. The latest draft I have of this is 802.5M/D6, which is a very final draft in final format. That standard is for transparent bridging, with one spanning tree for all networks. It also allows source-routing in the 802.5 domain, with the STE spanning tree coming from the 802.1D spanning tree. Now, there is another spanning tree protocol in the 802.5 world. This is the PROPRIETARY one that IBM uses in their pure source-route bridge products. They happened to have the large ego to appropriate the 802.2 SAP 42 hex that is reserved for IEEE 802.1D, but unfortunately, neither the protocol nor the application of this spanning tree protocol conform to 802.1D. (They must have made some assumptions about future standardization that did not come true.) My understanding of what spanning tree protocols were seperated were the IBM proprietary one, and the 802.1D one. I believe that the only way to tell the two apart on 802.5 is by the destination address. The IBM proprietary one uses 03-00-00-00-80-00, where the 802.1D one uses 01-80-C2-00-00-00. The 03-00-00-00-80-00 is not bridged by 802.1D bridges, preventing short circuits. (The 802.2 SAPs, and almost all other aspects of the packet format look the same.) So, the question is, which protocol are you talking about supporting? Standard, or IBM Proprietary. The PPP bridging protocols are really intended to address the standards-conformant bridges. I don't see that we really ought to be struggling to catch up with the deprecated IBM Proprietary protocol when the IEEE SRT standard is nearly approved, and already seeing considerable implementation. Now, this also does bring up the real issue of multiple bridges in a box wishing to share one PPP link. This is a more general issue in WAN bridging, and I think I have seen some discussions of these issues on this list. (I don't keep an archive, and don't know where it is kept.) As I remember the discussion, the first bridge on a link would use the existing encapsulation, and then all the other ones would use a new encapsulation that had a "bridge number" field in it, to correlate which of the several bridge entities that is sharing the link. This number would apply to both data packets and BPDU's. The case you are presenting is a special purpose hack case of the PPP bridge sharing problem, one that happens to be soluble by a workaround. However, it is not (at all) a general solution. Suppose that the "Ethernet bridge" was an SRT bridge. What then? Of suppose that the "Token-Ring bridge" inlcuded an (ugh, shudder) FDDI-II with source routing, and the "Ethernet bridge" also supported FDDI? Then how do you know which bridge an FDDI packet is for? The problem should be generically solved for an arbitrary number of bridges sharing one PPP line, be they pure 802.1D, or with the SRT extensions. From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 23 12:26:27 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13566; Mon, 23 Nov 92 11:55:18 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06578; Mon, 23 Nov 92 11:20:03 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11574; Mon, 23 Nov 92 11:12:21 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from nero.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11142; Mon, 23 Nov 92 11:02:17 -0800 Received: by nero.clearpoint.com (4.1/1.34) id AA05918; Mon, 23 Nov 92 14:01:22 EST Date: Mon, 23 Nov 92 14:01:22 EST From: martillo@nero.clearpoint.com (Joachim Martillo) Message-Id: <9211231901.AA05918@nero.clearpoint.com> To: jas@proteon.com Cc: RKB@ralvm11.vnet.ibm.com, ietf-ppp@ucdavis.ucdavis.edu, martillo@nero.clearpoint.com In-Reply-To: John A. Shriver's message of Mon, 23 Nov 92 11:38:13 EST <9211231638.AA22504@fats.proteon.com> Subject: Protocol type for source-route bridge BPDUs? From: jas@proteon.com (John A. Shriver) To: RKB@RALVM11.VNET.IBM.COM My understanding of what spanning tree protocols were seperated were the IBM proprietary one, and the 802.1D one. I believe that the only way to tell the two apart on 802.5 is by the destination address. The IBM proprietary one uses 03-00-00-00-80-00, where the 802.1D one uses 01-80-C2-00-00-00. The 03-00-00-00-80-00 is not bridged by 802.1D bridges, preventing short circuits. (The 802.2 SAPs, and almost all other aspects of the packet format look the same.) So, the question is, which protocol are you talking about supporting? Standard, or IBM Proprietary. The PPP bridging protocols are really intended to address the standards-conformant bridges. I don't see that we really ought to be struggling to catch up with the deprecated IBM Proprietary protocol when the IEEE SRT standard is nearly approved, and already seeing considerable implementation. With respect to BPDUs, the use of IBM proprietary versus IEEE SRT protocols is almost inconsequential. A site might not want to run either protocol on his remote bridge, but might expect the remote bridge to forward such frames onto an attached ethernet or token ring, in which case the remote bridge really should receive the complete MAC header. Exactly why the complete MAC header is not sent is completely obscure. Perhaps there is an argument that bandwidth is saved, but these frames are not sent terribly frequently. Joachim Carlo Santos Martillo Ajami From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 23 16:16:58 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24067; Mon, 23 Nov 92 15:56:17 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11000; Mon, 23 Nov 92 15:05:58 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21441; Mon, 23 Nov 92 14:52:56 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from nsco.network.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20370; Mon, 23 Nov 92 14:27:33 -0800 Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA09669; Mon, 23 Nov 92 16:31:59 -0600 Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA01377; Mon, 23 Nov 92 16:26:39 CST Date: Mon, 23 Nov 92 16:26:39 CST From: sjs@anubis.network.com (Steve Senum) Message-Id: <9211232226.AA01377@anubis.network.com> To: RKB@RALVM11.VNET.IBM.COM Subject: Re: Protocol type for source-route bridge BPDUs Cc: ietf-ppp@ucdavis.ucdavis.edu I agree with most of John Shriver's comments. I will add that we solved this same problem by using the assigned protocol type for 801.1D/802.5M Spanning Tree BPDUs, and sending the IBM Token Ring Source Route Spanning Tree BPDUs as encapsulated MAC Frames, using the IBM Functional Address 03-00-00-00-80-00. By the way, there was an important change made from draft 6 to draft 7 of 802.5M, that is relevant to this issue: C3.8.5 Reserved Addresses. Frames containing the values of Functional Addresses specified in Table 3-6 of the main body of this standard with frame_type and mac_action parameter values of user_data_frame and request_with_no_response, respectively, shall be relayed from the token ring on which they are initially transmitted. "Table 3-6" contains the Functional Address listed above, and "the main body of this standard" refers to 802.1D. Steve Senum From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 23 16:57:48 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26235; Mon, 23 Nov 92 16:47:49 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07336; Mon, 23 Nov 92 12:36:14 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14751; Mon, 23 Nov 92 12:18:31 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from regal.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13356; Mon, 23 Nov 92 11:50:05 -0800 Received: by regal.cisco.com; Mon, 23 Nov 92 11:46:44 -0800 Date: Mon, 23 Nov 92 11:46:43 PST From: William "Chops" Westfield To: Jesse Walker Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: Do we want an IPCP Nameserver Option? In-Reply-To: Your message of Mon, 23 Nov 92 05:27:30 PST Message-Id: I REALLY REALLY REALLY don't want to have a PPP option for everything that the Dynamic Host Configuration Protocol working group is working on. Name server addresses can be gotten just fine with BOOTP. IPCP should only do things that BOOTP and other existing protocols can't. BillW From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 23 17:21:18 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27165; Mon, 23 Nov 92 17:10:05 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11962; Mon, 23 Nov 92 16:08:48 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24198; Mon, 23 Nov 92 15:59:45 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23508; Mon, 23 Nov 92 15:44:38 -0800 Received: from [36.98.0.31] (wb6rqn.Stanford.EDU) by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA05964; Mon, 23 Nov 92 15:42:19 PST Message-Id: <9211232342.AA05964@ray.lloyd.com> Date: Mon, 23 Nov 1992 15:42:09 -0800 To: walker@eider.ENET.dec.com, kasten@ftp.com (Frank Kastenholz) From: brian@lloyd.com Subject: Re: Do we want an IPCP Nameserver Option? Cc: ietf-ppp@ucdavis.ucdavis.edu In addition to DHCP you can consider that you do not need to know the address of the "nearest" nameserver, you only need the address of any nameserver that is reachable. Pretty easy to just configure your portable system with the address of your favorite nameserver. It really doesn't matter if the NS is on the other side of the Internet so long as it is reachable. Brian Lloyd, President B.P. Lloyd & Associates, Inc. brian@lloyd.com 3420 Sudbury Road (916) 676-1147 - voice Cameron Park, CA 95682 (916) 676-3442 - fax From ietf-ppp-request@ucdavis.ucdavis.edu Tue Nov 24 08:18:02 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08490; Tue, 24 Nov 92 08:05:50 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17522; Tue, 24 Nov 92 07:29:43 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06760; Tue, 24 Nov 92 07:21:11 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from CAYMAN.CAYMAN.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06625; Tue, 24 Nov 92 07:17:25 -0800 Received: by cayman.Cayman.COM (4.1/SMI-4.0) id AA23110; Tue, 24 Nov 92 10:17:43 EST Received: from stemwinder by stemwinder.fcr.com (4.1/SMI-4.1) id AA23805; Tue, 24 Nov 92 09:44:22 EST Message-Id: <9211241444.AA23805@stemwinder.fcr.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: Do we want an IPCP Nameserver Option? In-Reply-To: Mail from brian@lloyd.com dated Mon, 23 Nov 92 15:42:09 PST <9211232342.AA05964@ray.lloyd.com> Date: Tue, 24 Nov 92 09:44:21 EST From: Brad Parker >> In addition to DHCP you can consider that you do not need to know the >> address of the "nearest" nameserver, you only need the address of any >> nameserver that is reachable. Pretty easy to just configure your portable >> system with the address of your favorite nameserver. It really doesn't >> matter if the NS is on the other side of the Internet so long as it is >> reachable. In fairness, I think the idea is configuration-less dial-in, an idea I like a lot. I don't see any reason why having IPCP assign an address and using BOOTP (or the new DHCP BOOTP) to get more info, such as the domain name and DNS server address won't work. In fact, I think it works fine. I would claim you can do a whole lot of configuration with bootp. Like configure an entire router. -brad From ietf-ppp-request@ucdavis.ucdavis.edu Tue Nov 24 11:10:44 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15132; Tue, 24 Nov 92 11:02:16 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA18353; Tue, 24 Nov 92 08:29:04 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08982; Tue, 24 Nov 92 08:18:16 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08571; Tue, 24 Nov 92 08:08:29 -0800 Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA11867; Tue, 24 Nov 92 08:07:44 -0800 Date: Tue, 24 Nov 92 10:51:50 EDT From: "William Allen Simpson" Message-Id: <778.bill.simpson@um.cc.umich.edu> To: IESG Secretary Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: last call for pppext-ipxcp Greg, We looked over ipxcp at IETF-DC, and are ready for a last call whenever you are. Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Tue Nov 24 11:52:01 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16895; Tue, 24 Nov 92 11:44:19 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA18356; Tue, 24 Nov 92 08:29:53 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08988; Tue, 24 Nov 92 08:18:22 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08573; Tue, 24 Nov 92 08:08:31 -0800 Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA11864; Tue, 24 Nov 92 08:07:35 -0800 Date: Tue, 24 Nov 92 10:58:04 EDT From: "William Allen Simpson" Message-Id: <779.bill.simpson@um.cc.umich.edu> To: iana@isi.edu Cc: ietf-ppp@ucdavis.ucdavis.edu Cc: iplpdn@cnri.reston.va.us Subject: agglutinated PPP LCP option The IPLPDN folks requested another PPP LCP option, which they called "agglutinated". Please reserve the next LCP number, which is 15, right? The option is to allow more than one PPP packet inside an ISDN/X.25 frame. I was thinking "amalgamated" or just "multiple-packets-in-frame". If anybody has a better name, please let me know. Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Tue Nov 24 12:40:17 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18607; Tue, 24 Nov 92 12:24:29 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA18978; Tue, 24 Nov 92 09:09:57 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10632; Tue, 24 Nov 92 09:03:31 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from zephyr.isi.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10293; Tue, 24 Nov 92 08:55:10 -0800 Received: by zephyr.isi.edu (5.65c/5.61+local-9) id ; Tue, 24 Nov 1992 08:53:34 -0800 Date: Tue, 24 Nov 1992 08:53:34 -0800 From: postel@ISI.EDU (Jon Postel) Message-Id: <199211241653.AA11891@zephyr.isi.edu> To: bsimpson@angband.stanford.edu Subject: Re: agglutinated PPP LCP option Cc: ietf-ppp@ucdavis.ucdavis.edu, iplpdn@cnri.reston.va.us, iana@ISI.EDU Bill: We will assign the next available number when we see the spec, not before. --jon. From ietf-ppp-request@ucdavis.ucdavis.edu Tue Nov 24 13:52:24 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21766; Tue, 24 Nov 92 13:42:29 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA22784; Tue, 24 Nov 92 12:29:50 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18571; Tue, 24 Nov 92 12:23:09 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from research.att.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18227; Tue, 24 Nov 92 12:14:28 -0800 Message-Id: <9211242014.AA18227@ucdavis.ucdavis.edu> From: smb@research.att.com To: "William Allen Simpson" Cc: iana@isi.edu, ietf-ppp@ucdavis.ucdavis.edu, iplpdn@cnri.reston.va.us Subject: Re: agglutinated PPP LCP option Date: Tue, 24 Nov 92 15:07:45 EST The option is to allow more than one PPP packet inside an ISDN/X.25 frame. I was thinking "amalgamated" or just "multiple-packets-in- frame". If anybody has a better name, please let me know. Hmm -- to me, the word ``agglutinate'' carries the connotations of a gelatinous, gooey, mess. Some might think that appropriate... Me -- I'd probably call 'em ``compound frames''. --Steve Bellovin From ietf-ppp-request@ucdavis.ucdavis.edu Tue Nov 24 15:05:51 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24690; Tue, 24 Nov 92 14:50:54 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA23357; Tue, 24 Nov 92 13:10:37 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20125; Tue, 24 Nov 92 13:00:40 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ub-gate.UB.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19634; Tue, 24 Nov 92 12:49:48 -0800 Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA21848; Tue, 24 Nov 92 12:48:58 PST Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA12872; Tue, 24 Nov 92 15:48:57 EST Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA05292; Tue, 24 Nov 92 15:45:23 EST Date: Tue, 24 Nov 92 15:45:23 EST From: Frank T Solensky Message-Id: <9211242045.AA05292@fenway.andr.UB.com> To: bill.simpson@um.cc.umich.edu, iana@isi.edu Subject: Re: agglutinated PPP LCP option Cc: ietf-ppp@ucdavis.ucdavis.edu, iplpdn@cnri.reston.va.us >Date: Tue, 24 Nov 92 10:58:04 EDT >From: "William Allen Simpson" >To: iana@isi.edu >Cc: ietf-ppp@ucdavis.edu >Cc: iplpdn@cnri.reston.va.us >Subject: agglutinated PPP LCP option > >The [new PPP] option is to allow more than one PPP packet inside an ISDN/X.25 >frame. I was thinking "amalgamated" or just "multiple-packets-in-frame". >If anybody has a better name, please let me know. > "Amalgamated" [WebNW 2: "to join together into one; unite; combine"] seems to fit pretty well, actually (Would the resultant frame be an "amalgram"? :-). If you really think that's too obsure, though, how 'bout just "packed"? From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 25 14:52:25 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21174; Wed, 25 Nov 92 14:43:02 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06894; Wed, 25 Nov 92 14:00:15 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19188; Wed, 25 Nov 92 13:54:38 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18632; Wed, 25 Nov 92 13:41:43 -0800 From: itdavid@ucdavis.ucdavis.edu (David Arredondo) Date: Wed, 25 Nov 92 13:41:43 -0800 Message-Id: <9211252141.AA18632@ucdavis.ucdavis.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: ---------------------- Forwarded Message Follows ---------------------- Received: from ns.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13659; Mon, 23 Nov 92 11:57:14 -0800 Received: by ns.Novell.COM (4.1/SMI-4.1) id AA20713; Mon, 23 Nov 92 12:56:31 MST Received: by MHS.Novell.COM id AD0C112B81FA0070; Mon, 23 Nov 92 12:56:30 MST Return-Path: <@> Precedence: first-class X-Date-Posted: 23-Nov-1992 11:33:28 -0500; at sjf-mail-engr.Novell X-Addresses-Referred-To: MALLEN@Novell X-Error-Report: 255 X-Smf-Version: 70 Date: To: ietf-ppp-request@ucdavis.edu From: @@Novell.COM Message-Id: X-Nvlipm-Report-Syntax: NGM X-Nvlipm-Report-Event: 280 X-Nvlipm-Report-Subevent: 11 X-Notification-Correlator: CFC1102B81F401D0 Subject: Hop count excessive X-Rejected-For: Michael Allen@Novell X-Via-Host: sjf-engr.sjf-engr X-Re-Sent-By: -maiser-@Novell; on 23-Nov-1992 11:33:27 -0500 X-Date-Posted: 23-Nov-92 11:37:40 Return-Path: Precedence: first-class X-Received: by mhs.Novell.COM id Ux15469; Mon, 23 Nov 92 10:33:43 MST X-Received: from aggie.ucdavis.edu by ns.Novell.COM (4.1/SMI-4.1) id AA15456; Mon, 23 Nov 92 10:33:29 MST X-Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04935; Mon, 23 Nov 92 08:50:30 -0800 X-Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06023; Mon, 23 Nov 92 08:48:42 -0800 X-Sender: ietf-ppp-request@ucdavis.edu X-Received: from fats.proteon.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05801; Mon, 23 Nov 92 08:38:17 -0800 X-Received: from mcgarret.proteon.com by fats.proteon.com (4.1/Proteon-1.5) id AA22504; Mon, 23 Nov 92 11:38:13 EST Date: Mon, 23 Nov 92 09:38:13 MST From: jas@proteon.com (John A.Shriver) X-Message-Id: <9211231638.AA22504@fats.proteon.com> X-Received: by mcgarret.proteon.com (4.1/SMI-4.1) id AA00488; Mon, 23 Nov 92 11:37:41 EST To: RKB@RALVM11.VNET.IBM.COM Cc: ietf-ppp@ucdavis.edu X-In-Reply-To: "Rich Bowen"'s message of Fri, 20 Nov 92 14:24:29 EST <9211202133.AA06783@ucdavis.ucdavis.edu> Subject: Protocol type for source-route bridge BPDUs? Message-Id: X-Via-Host: nov-gate.novell Your message leaves me extremely confused. I've been following 802.5 bridging for years, and as last I saw it, it was converging on the SRT standard. The latest draft I have of this is 802.5M/D6, which is a very final draft in final format. That standard is for transparent bridging, with one spanning tree for all networks. It also allows source-routing in the 802.5 domain, with the STE spanning tree coming from the 802.1D spanning tree. Now, there is another spanning tree protocol in the 802.5 world. This is the PROPRIETARY one that IBM uses in their pure source-route bridge products. They happened to have the large ego to appropriate the 802.2 SAP 42 hex that is reserved for IEEE 802.1D, but unfortunately, neither the protocol nor the application of this spanning tree protocol conform to 802.1D. (They must have made some assumptions about future standardization that did not come true.) My understanding of what spanning tree protocols were seperated were the IBM proprietary one, and the 802.1D one. I believe that the only way to tell the two apart on 802.5 is by the destination address. The IBM proprietary one uses 03-00-00-00-80-00, where the 802.1D one uses 01-80-C2-00-00-00. The 03-00-00-00-80-00 is not bridged by 802.1D bridges, preventing short circuits. (The 802.2 SAPs, and almost all other aspects of the packet format look the same.) So, the question is, which protocol are you talking about supporting? Standard, or IBM Proprietary. The PPP bridging protocols are really intended to address the standards-conformant bridges. I don't see that we really ought to be struggling to catch up with the deprecated IBM Proprietary protocol when the IEEE SRT standard is nearly approved, and already seeing considerable implementation. Now, this also does bring up the real issue of multiple bridges in a box wishing to share one PPP link. This is a more general issue in WAN bridging, and I think I have seen some discussions of these issues on this list. (I don't keep an archive, and don't know where it is kept.) As I remember the discussion, the first bridge on a link would use the existing encapsulation, and then all the other ones would use a new encapsulation that had a "bridge number" field in it, to correlate which of the several bridge entities that is sharing the link. This number would apply to both data packets and BPDU's. The case you are presenting is a special purpose hack case of the PPP bridge sharing problem, one that happens to be soluble by a workaround. However, it is not (at all) a general solution. Suppose that the "Ethernet bridge" was an SRT bridge. What then? Of suppose that the "Token-Ring bridge" inlcuded an (ugh, shudder) FDDI-II with source routing, and the "Ethernet bridge" also supported FDDI? Then how do you know which bridge an FDDI packet is for? The problem should be generically solved for an arbitrary number of bridges sharing one PPP line, be they pure 802.1D, or with the SRT extensions. From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 25 15:12:14 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22162; Wed, 25 Nov 92 15:05:18 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07116; Wed, 25 Nov 92 14:21:13 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20179; Wed, 25 Nov 92 14:16:38 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19672; Wed, 25 Nov 92 14:05:45 -0800 From: itdavid@ucdavis.ucdavis.edu (David Arredondo) Date: Wed, 25 Nov 92 14:05:45 -0800 Message-Id: <9211252205.AA19672@ucdavis.ucdavis.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: ---------------------- Forwarded Message Follows ---------------------- Received: from ns.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27431; Mon, 23 Nov 92 17:15:51 -0800 Received: by ns.Novell.COM (4.1/SMI-4.1) id AA02296; Mon, 23 Nov 92 18:15:11 MST Received: by MHS.Novell.COM id 9E58112B81FA0070; Mon, 23 Nov 92 18:15:10 MST Return-Path: <@> Precedence: first-class X-Date-Posted: 23-Nov-1992 17:03:43 -0500; at sjf-mail-engr.Novell X-Addresses-Referred-To: MALLEN@Novell X-Error-Report: 255 X-Smf-Version: 70 Date: To: ietf-ppp-request@ucdavis.edu From: @@Novell.COM Message-Id: <9D58112B81FA0070@sjf-mail-engr.Novell@MHS.Novell.COM> X-Nvlipm-Report-Syntax: NGM X-Nvlipm-Report-Event: 280 X-Nvlipm-Report-Subevent: 11 X-Notification-Correlator: 6311112B81F401D0 Subject: Hop count excessive X-Rejected-For: Michael Allen@Novell X-Via-Host: sjf-engr.sjf-engr X-Re-Sent-By: -maiser-@Novell; on 23-Nov-1992 17:03:43 -0500 X-Date-Posted: 23-Nov-92 17:18:58 Return-Path: Precedence: first-class X-Received: by mhs.Novell.COM id Ux516; Mon, 23 Nov 92 17:12:25 MST X-Received: from aggie.ucdavis.edu by ns.Novell.COM (4.1/SMI-4.1) id AA00501; Mon, 23 Nov 92 17:12:10 MST X-Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11000; Mon, 23 Nov 92 15:05:58 -0800 X-Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21441; Mon, 23 Nov 92 14:52:56 -0800 X-Sender: ietf-ppp-request@ucdavis.edu X-Received: from nsco.network.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20370; Mon, 23 Nov 92 14:27:33 -0800 X-Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA09669; Mon, 23 Nov 92 16:31:59 -0600 X-Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA01377; Mon, 23 Nov 92 16:26:39 CST Date: Mon, 23 Nov 92 15:26:39 MST From: sjs@anubis.network.com (Steve Senum) X-Message-Id: <9211232226.AA01377@anubis.network.com> To: RKB@RALVM11.VNET.IBM.COM Subject: Re: Protocol type for source-route bridge BPDUs Cc: ietf-ppp@ucdavis.edu Message-Id: <6311112B81F401D0@MHS.Novell.COM> X-Via-Host: nov-gate.novell I agree with most of John Shriver's comments. I will add that we solved this same problem by using the assigned protocol type for 801.1D/802.5M Spanning Tree BPDUs, and sending the IBM Token Ring Source Route Spanning Tree BPDUs as encapsulated MAC Frames, using the IBM Functional Address 03-00-00-00-80-00. By the way, there was an important change made from draft 6 to draft 7 of 802.5M, that is relevant to this issue: C3.8.5 Reserved Addresses. Frames containing the values of Functional Addresses specified in Table 3-6 of the main body of this standard with frame_type and mac_action parameter values of user_data_frame and request_with_no_response, respectively, shall be relayed from the token ring on which they are initially transmitted. "Table 3-6" contains the Functional Address listed above, and "the main body of this standard" refers to 802.1D. Steve Senum From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 25 17:11:05 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26686; Wed, 25 Nov 92 16:52:11 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08267; Wed, 25 Nov 92 16:10:46 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24609; Wed, 25 Nov 92 16:02:03 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24228; Wed, 25 Nov 92 15:54:05 -0800 From: itdavid@ucdavis.ucdavis.edu (David Arredondo) Date: Wed, 25 Nov 92 15:54:05 -0800 Message-Id: <9211252354.AA24228@ucdavis.ucdavis.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: ---------------------- Forwarded Message Follows ---------------------- Received: from ns.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24132; Tue, 24 Nov 92 14:37:40 -0800 Received: by ns.Novell.COM (4.1/SMI-4.1) id AA01563; Tue, 24 Nov 92 15:36:59 MST Received: by MHS.Novell.COM id 2074122B81FA0070; Tue, 24 Nov 92 15:36:58 MST Return-Path: <@> Precedence: first-class X-Date-Posted: 24-Nov-1992 13:27:33 -0500; at sjf-mail-engr.Novell X-Addresses-Referred-To: MALLEN@Novell X-Error-Report: 255 X-Smf-Version: 70 Date: To: ietf-ppp-request@ucdavis.edu From: @@Novell.COM Message-Id: <1F6D122B81FA0070@sjf-mail-engr.Novell@MHS.Novell.COM> X-Nvlipm-Report-Syntax: NGM X-Nvlipm-Report-Event: 280 X-Nvlipm-Report-Subevent: 11 X-Notification-Correlator: CF20122B81F401D0 Subject: Hop count excessive X-Rejected-For: Michael Allen@Novell X-Via-Host: sjf-engr.sjf-engr X-Re-Sent-By: -maiser-@Novell; on 24-Nov-1992 13:27:33 -0500 X-Date-Posted: 24-Nov-92 12:41:05 Return-Path: Precedence: first-class X-Received: by mhs.Novell.COM id Ux25046; Tue, 24 Nov 92 12:33:49 MST X-Received: from aggie.ucdavis.edu by ns.Novell.COM (4.1/SMI-4.1) id AA25040; Tue, 24 Nov 92 12:33:42 MST X-Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17522; Tue, 24 Nov 92 07:29:43 -0800 X-Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06760; Tue, 24 Nov 92 07:21:11 -0800 X-Sender: ietf-ppp-request@ucdavis.edu X-Received: from CAYMAN.CAYMAN.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06625; Tue, 24 Nov 92 07:17:25 -0800 X-Received: by cayman.Cayman.COM (4.1/SMI-4.0) id AA23110; Tue, 24 Nov 92 10:17:43 EST X-Received: from stemwinder by stemwinder.fcr.com (4.1/SMI-4.1) id AA23805; Tue, 24 Nov 92 09:44:22 EST X-Message-Id: <9211241444.AA23805@stemwinder.fcr.com> To: ietf-ppp@ucdavis.edu Subject: Re: Do we want an IPCP Nameserver Option? X-In-Reply-To: Mail from brian@lloyd.com dated Mon, 23 Nov 92 15:42:09 PST <9211232342.AA05964@ray.lloyd.com> Date: Tue, 24 Nov 92 07:44:21 MST From: brad@fcr.com (Brad Parker) Message-Id: X-Via-Host: nov-gate.novell >> In addition to DHCP you can consider that you do not need to know the >> address of the "nearest" nameserver, you only need the address of any >> nameserver that is reachable. Pretty easy to just configure your portable >> system with the address of your favorite nameserver. It really doesn't >> matter if the NS is on the other side of the Internet so long as it is >> reachable. In fairness, I think the idea is configuration-less dial-in, an idea I like a lot. I don't see any reason why having IPCP assign an address and using BOOTP (or the new DHCP BOOTP) to get more info, such as the domain name and DNS server address won't work. In fact, I think it works fine. I would claim you can do a whole lot of configuration with bootp. Like configure an entire router. -brad From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 25 17:12:02 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26914; Wed, 25 Nov 92 16:58:28 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08429; Wed, 25 Nov 92 16:34:30 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25405; Wed, 25 Nov 92 16:19:54 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24729; Wed, 25 Nov 92 16:05:30 -0800 From: itdavid@ucdavis.ucdavis.edu (David Arredondo) Date: Wed, 25 Nov 92 16:05:30 -0800 Message-Id: <9211260005.AA24729@ucdavis.ucdavis.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: ---------------------- Forwarded Message Follows ---------------------- Received: from netmail.microsoft.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19554; Wed, 25 Nov 92 01:13:47 -0800 Received: by netmail.microsoft.com (5.65/25-eef) id AA07114; Wed, 25 Nov 92 01:10:57 -0800 Date: Wed, 25 Nov 92 01:10:57 -0800 From: uucp@microsoft.com Message-Id: <9211250910.AA07114@netmail.microsoft.com> Subject: Warning From uucp Apparently-To: ietf-ppp-request@ucdavis.edu We have been unable to contact machine 'omicrosoft' since you queued your job. omicrosoft!mail tommyd (Date 11/23) The job will be deleted in several days if the problem is not corrected. If you care to kill the job, execute the following command: uustat -kmicrosoCb496 Sincerely, netmail!uucp ############################################# ##### Data File: ############################ >From ietf-ppp-request@ucdavis.edu Mon Nov 23 06:37:28 1992 remote from netmail Received: from aggie.ucdavis.edu by netmail.microsoft.com with SMTP (5.65/25-eef) id AA00755; Mon, 23 Nov 92 06:37:28 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA03757; Mon, 23 Nov 92 05:39:39 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01980; Mon, 23 Nov 92 05:30:27 -0800 Sender: netmail!ietf-ppp-request@ucdavis.edu Received: from mts-gw.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01881; Mon, 23 Nov 92 05:28:07 -0800 Received: by mts-gw.pa.dec.com; id AA01477; Mon, 23 Nov 92 05:27:30 -0800 Message-Id: <9211231327.AA01477@mts-gw.pa.dec.com> Received: from eider.enet; by decpa.enet; Mon, 23 Nov 92 05:27:30 PST Date: Mon, 23 Nov 92 05:27:30 PST From: Jesse Walker To: ietf-ppp@ucdavis.edu Apparently-To: ietf-ppp@ucdavis.edu Subject: Do we want an IPCP Nameserver Option? Host systems attaching to a remote IP network via a router or network access server really need (at least) two pieces of information to allow their users' to participate effectively in the new network: a. an IP address b. the IP address of a name server IPCP allows PPP hosts to negotiate the former, but not the latter. I cannot recall any consideration being given to providing an IPCP option to negotiate name server addresses as well. Is there any interest in defining one? If so, I will write up a strawman proposal. Jesse Walker Digital Equipment Corporation Networks and Communication Littleton, MA (508) 486-7326 From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 25 17:41:44 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28367; Wed, 25 Nov 92 17:30:43 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08488; Wed, 25 Nov 92 16:40:32 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25426; Wed, 25 Nov 92 16:20:19 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24782; Wed, 25 Nov 92 16:06:55 -0800 From: itdavid@ucdavis.ucdavis.edu (David Arredondo) Date: Wed, 25 Nov 92 16:06:55 -0800 Message-Id: <9211260006.AA24782@ucdavis.ucdavis.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: ---------------------- Forwarded Message Follows ---------------------- Received: from netmail.microsoft.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22139; Wed, 25 Nov 92 02:31:48 -0800 Received: by netmail.microsoft.com (5.65/25-eef) id AA13611; Wed, 25 Nov 92 02:29:00 -0800 Date: Wed, 25 Nov 92 02:29:00 -0800 From: uucp@microsoft.com Message-Id: <9211251029.AA13611@netmail.microsoft.com> Subject: Warning From uucp Apparently-To: ietf-ppp-request@ucdavis.edu We have been unable to contact machine 'omicrosoft' since you queued your job. omicrosoft!mail tommyd (Date 11/23) The job will be deleted in several days if the problem is not corrected. If you care to kill the job, execute the following command: uustat -kmicrosoCba3e Sincerely, netmail!uucp ############################################# From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 25 17:42:42 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28710; Wed, 25 Nov 92 17:37:51 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08492; Wed, 25 Nov 92 16:40:52 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25438; Wed, 25 Nov 92 16:20:38 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24815; Wed, 25 Nov 92 16:07:41 -0800 From: itdavid@ucdavis.ucdavis.edu (David Arredondo) Date: Wed, 25 Nov 92 16:07:41 -0800 Message-Id: <9211260007.AA24815@ucdavis.ucdavis.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: ---------------------- Forwarded Message Follows ---------------------- Received: from netmail.microsoft.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24232; Wed, 25 Nov 92 03:32:27 -0800 Received: by netmail.microsoft.com (5.65/25-eef) id AA18308; Wed, 25 Nov 92 03:29:38 -0800 Date: Wed, 25 Nov 92 03:29:38 -0800 From: uucp@microsoft.com Message-Id: <9211251129.AA18308@netmail.microsoft.com> Subject: Warning From uucp Apparently-To: ietf-ppp-request@ucdavis.edu We have been unable to contact machine 'omicrosoft' since you queued your job. omicrosoft!mail tommyd (Date 11/23) The job will be deleted in several days if the problem is not corrected. If you care to kill the job, execute the following command: uustat -kmicrosoCbe59 Sincerely, netmail!uucp ############################################# From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 25 17:42:45 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28712; Wed, 25 Nov 92 17:37:51 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08558; Wed, 25 Nov 92 16:45:09 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25445; Wed, 25 Nov 92 16:20:53 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24827; Wed, 25 Nov 92 16:08:06 -0800 From: itdavid@ucdavis.ucdavis.edu (David Arredondo) Date: Wed, 25 Nov 92 16:08:06 -0800 Message-Id: <9211260008.AA24827@ucdavis.ucdavis.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: ---------------------- Forwarded Message Follows ---------------------- Received: from netmail.microsoft.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28768; Wed, 25 Nov 92 05:26:40 -0800 Received: by netmail.microsoft.com (5.65/25-eef) id AA26968; Wed, 25 Nov 92 05:23:52 -0800 Date: Wed, 25 Nov 92 05:23:52 -0800 From: uucp@microsoft.com Message-Id: <9211251323.AA26968@netmail.microsoft.com> Subject: Warning From uucp Apparently-To: ietf-ppp-request@ucdavis.edu We have been unable to contact machine 'omicrosoft' since you queued your job. omicrosoft!mail tommyd (Date 11/23) The job will be deleted in several days if the problem is not corrected. If you care to kill the job, execute the following command: uustat -kmicrosoCc5f2 Sincerely, netmail!uucp ############################################# From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 25 18:22:39 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00271; Wed, 25 Nov 92 18:14:35 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08402; Wed, 25 Nov 92 16:30:12 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25356; Wed, 25 Nov 92 16:18:57 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24578; Wed, 25 Nov 92 16:01:17 -0800 From: itdavid@ucdavis.ucdavis.edu (David Arredondo) Date: Wed, 25 Nov 92 16:01:17 -0800 Message-Id: <9211260001.AA24578@ucdavis.ucdavis.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: ---------------------- Forwarded Message Follows ---------------------- Received: from ns.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28636; Tue, 24 Nov 92 16:27:51 -0800 Received: by ns.Novell.COM (4.1/SMI-4.1) id AA05367; Tue, 24 Nov 92 17:27:11 MST Received: by MHS.Novell.COM id E1C4122B81FA0070; Tue, 24 Nov 92 17:27:10 MST Return-Path: <@> Precedence: first-class X-Date-Posted: 24-Nov-1992 16:19:44 -0500; at sjf-mail-engr.Novell X-Addresses-Referred-To: MALLEN@Novell X-Error-Report: 255 X-Smf-Version: 70 Date: To: ietf-ppp-request@ucdavis.edu From: @@Novell.COM Message-Id: X-Nvlipm-Report-Syntax: NGM X-Nvlipm-Report-Event: 280 X-Nvlipm-Report-Subevent: 12 X-Notification-Correlator: C95A122B81F401D0 Subject: Hop count excessive X-Rejected-For: Michael Allen@Novell X-Via-Host: sjf-engr.sjf-engr X-Re-Sent-By: -maiser-@Novell; on 24-Nov-1992 16:19:44 -0500 X-Date-Posted: 24-Nov-92 16:47:11 Return-Path: Precedence: first-class X-Received: by mhs.Novell.COM id Ux3343; Tue, 24 Nov 92 16:38:29 MST X-Received: from aggie.ucdavis.edu by ns.Novell.COM (4.1/SMI-4.1) id AA03340; Tue, 24 Nov 92 16:38:20 MST X-Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA23357; Tue, 24 Nov 92 13:10:37 -0800 X-Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20125; Tue, 24 Nov 92 13:00:40 -0800 X-Sender: ietf-ppp-request@ucdavis.edu X-Received: from ub-gate.UB.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19634; Tue, 24 Nov 92 12:49:48 -0800 X-Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA21848; Tue, 24 Nov 92 12:48:58 PST X-Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA12872; Tue, 24 Nov 92 15:48:57 EST X-Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA05292; Tue, 24 Nov 92 15:45:23 EST Date: Tue, 24 Nov 92 13:45:23 MST From: solensky@andr.UB.com (Frank T Solensky) X-Message-Id: <9211242045.AA05292@fenway.andr.UB.com> To: bill.simpson@um.cc.umich.edu, iana@isi.edu Subject: Re: agglutinated PPP LCP option Cc: ietf-ppp@ucdavis.edu, iplpdn@cnri.reston.va.us Message-Id: X-Via-Host: nov-gate.novell >Date: Tue, 24 Nov 92 10:58:04 EDT >From: "William Allen Simpson" >To: iana@isi.edu >Cc: ietf-ppp@ucdavis.edu >Cc: iplpdn@cnri.reston.va.us >Subject: agglutinated PPP LCP option > >The [new PPP] option is to allow more than one PPP packet inside an ISDN/X.25 >frame. I was thinking "amalgamated" or just "multiple-packets-in-frame". >If anybody has a better name, please let me know. > "Amalgamated" [WebNW 2: "to join together into one; unite; combine"] seems to fit pretty well, actually (Would the resultant frame be an "amalgram"? :-). If you really think that's too obsure, though, how 'bout just "packed"? From ietf-ppp-request@ucdavis.ucdavis.edu Wed Nov 25 22:01:00 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08045; Wed, 25 Nov 92 21:55:48 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA10118; Wed, 25 Nov 92 21:39:46 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07234; Wed, 25 Nov 92 21:30:55 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from NIC1.BARRNET.NET by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07037; Wed, 25 Nov 92 21:26:25 -0800 Received: from by nic1.barrnet.net (4.1/SMI-4.1/NIC1.BARRNET.NET-Brent-921125-01) id AB03713; Wed, 25 Nov 92 21:25:30 PST Message-Id: <9211260525.AB03713@nic1.barrnet.net> Date: Wed, 25 Nov 1992 21:25:19 -0800 To: bsimpson@angband.stanford.edu From: brian@lloyd.com Subject: Re: last call for pppext-ipxcp Cc: gvaudre@nri.reston.va.us, ietf-ppp@ucdavis.ucdavis.edu >> I might remind you that I am still the chaircritter for the PPP-EXT WG. I >> will be happy to issue the last-call for you. >> >I would like to remind you that you are an ass. Enough power/control >shit, already! Thank you for your kind words. Personally I am not on a power trip. I am merely trying to continue doing things the way that they have always been done. >You do not "issue" last calls. The secretary of the IETF/IESG does. I did not intend to indicate that the the WG chair actually issues the "last-call" but the chairperson does forward the request for last call as an indication of consensus. That is to prevent one person from pushing a document forward without the consensus of the entire WG. >Please stick to coordinating meetings, furthering discussion, and >smoothing ruffled feathers, which is the job of the chair. Thank you for your opinion. I believe that the function of chairperson is a little broader than that. >It was the consensus of the meeting that we are ready for last call. >Perhaps you disagree, on some technical basis? Bill, you do not represent the WG. Your pronouncement is somewhat questionable without confirmation from other quarters. IMHO, you tend to feel so strongly that you occasionally move forward without the consensus of others. You are probably right but I am trying to make sure that EVERYONE who is participating in this area concurs and is represented. >Novell wants some minor wording changes, which I already agreed to >on the list several weeks ago, but I will not bother adding them until >all other comments are in. Fine. Then it appears then that the document is NOT ready for last call. Rather than send out the document in a known unfinished state, could you please make the changes so that the rest of the IETF sees a document that is as finished as possible. Please let me know when you have the changes made. In the mean time I will check with some of the other people to ensure that there really is a consensus re the completeness of the document. I can then ask Greg to issue the last call. I want to thank you for your untiring efforts on behalf of the PPPEXT WG and on behalf of the IETF in general. Your efforts have materially improved PPP. I hope that you will continue your efforts on our behalf. >Bill.Simpson@um.cc.umich.edu Brian Lloyd 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 (916) 676-1147 - voice (916) 676-3442 - fax From ietf-ppp-request@ucdavis.ucdavis.edu Fri Nov 27 08:53:19 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13509; Fri, 27 Nov 92 08:48:25 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA14890; Fri, 27 Nov 92 08:29:47 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12624; Fri, 27 Nov 92 08:20:46 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from nsco.network.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12457; Fri, 27 Nov 92 08:15:27 -0800 Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA21040; Fri, 27 Nov 92 10:19:54 -0600 Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA20426; Fri, 27 Nov 92 10:14:25 CST Date: Fri, 27 Nov 92 10:14:25 CST From: sjs@anubis.network.com (Steve Senum) Message-Id: <9211271614.AA20426@anubis.network.com> To: martillo@nero.clearpoint.com Subject: Re: Protocol type for source-route bridge BPDUs Cc: RKB@ralvm11.vnet.ibm.com, ietf-ppp@ucdavis.ucdavis.edu Joachim Carlo Santos Martillo Ajami: > > I agree with most of John Shriver's comments. I will add that we solved this > same problem by using the assigned protocol type for 801.1D/802.5M > Spanning Tree BPDUs, and sending the IBM Token Ring Source Route Spanning > Tree BPDUs as encapsulated MAC Frames, using the IBM Functional Address > 03-00-00-00-80-00. > > This last statement suggests that using a separate BPDU encoding is > unnecessary especially when this BPDU encoding applies only two link > layer path selection protocols of the multitude of possible link layer > path selection protocols. Fred Baker will hopefully correct me if I am wrong, but I believe the only reason a seperate protocol type was assigned was merely for convenience in recognizing a BDPU. The encoding of the BPDU itself is unchanged. > > By the way, there was an important change made from draft 6 to draft 7 > of 802.5M, that is relevant to this issue: > > C3.8.5 Reserved Addresses. Frames containing the values of Functional > Addresses specified in Table 3-6 of the main body of this standard with > frame_type and mac_action parameter values of user_data_frame and > request_with_no_response, respectively, shall be relayed from the token > ring on which they are initially transmitted. > > Apparently, the IEEE standards committee realized that there actually > are reasons to relay a received BPDU from one interface to another -- > something which the separate BPDU encoding in the PPP bridging > extensions makes next to impossible in the case of IEEE STP and SR > BPDUs. Actually, the reason the IEEE 802.5 standards committee did this was to allow a greater level of compatibility with IBM Token Ring Source Route bridges. This way, if a group of SR bridges in surrounded by a group of SRT bridges, the SR bridge's Spanning Tree will (correctly) detect a loop in the topology, and put additional ports to blocking state. Section C3.8.5 was added to override the following section in 802.1D (page 46): "Table 3-6 records values of functional addresses . . ., but should not be relayed from the token ring on which they are initially transmitted." Nothing in either standards actually says that a message addressed to this functional address contains a BPDU. That is only specified in the IBM Token Ring Source Route spec. > something which the separate BPDU encoding in the PPP bridging > extensions makes next to impossible in the case of IEEE STP and SR > BPDUs. Again, the BPDU encoding is not changed in any way by the PPP Bridging spec., only the protocol type used in the PPP header. And, as I indicated before, handling this problem with the existing PPP Bridging standard is actually quite trival, though this does not address the additonal issue rasied by John Shriver. Steve Senum From ietf-ppp-request@ucdavis.ucdavis.edu Sat Nov 28 02:30:06 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17404; Sat, 28 Nov 92 02:27:16 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17502; Sat, 28 Nov 92 02:09:38 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16678; Sat, 28 Nov 92 02:00:12 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from nero.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16541; Sat, 28 Nov 92 01:56:41 -0800 Received: by nero.clearpoint.com (4.1/1.34) id AA26287; Sat, 28 Nov 92 04:55:28 EST Date: Sat, 28 Nov 92 04:55:28 EST From: martillo@nero.clearpoint.com (Joachim Martillo) Message-Id: <9211280955.AA26287@nero.clearpoint.com> To: sjs@anubis.network.com Cc: RKB@ralvm11.vnet.ibm.com, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Steve Senum's message of Fri, 27 Nov 92 10:14:25 CST <9211271614.AA20426@anubis.network.com> Subject: Protocol type for source-route bridge BPDUs Sender: ietf-ppp-request@ucdavis.edu Date: Fri, 27 Nov 92 10:14:25 CST From: sjs@anubis.network.com (Steve Senum) To: martillo@nero.clearpoint.com Subject: Re: Protocol type for source-route bridge BPDUs Cc: RKB@ralvm11.vnet.ibm.com, ietf-ppp@ucdavis.edu Joachim Carlo Santos Martillo Ajami: > > I agree with most of John Shriver's comments. I will add that we solved this > same problem by using the assigned protocol type for 801.1D/802.5M > Spanning Tree BPDUs, and sending the IBM Token Ring Source Route Spanning > Tree BPDUs as encapsulated MAC Frames, using the IBM Functional Address > 03-00-00-00-80-00. > > This last statement suggests that using a separate BPDU encoding is > unnecessary especially when this BPDU encoding applies only two link > layer path selection protocols of the multitude of possible link layer > path selection protocols. Fred Baker will hopefully correct me if I am wrong, but I believe the only reason a seperate protocol type was assigned was merely for convenience in recognizing a BDPU. Oh, and the STP and SR bridges, which my company and lots of others manufacture, are somehow having problems recognizing BPDUs via the mechanisms built into the IEEE specifications? The encoding of the BPDU itself is unchanged. Unfortunately, if the remote bridge using PPP does not support STP or SR, this bridge needs the complete DLSDU which contains the BPDU so that the bridge can relay the DLSDU onto the next LAN segment or WAN link. > By the way, there was an important change made from draft 6 to draft 7 > of 802.5M, that is relevant to this issue: > C3.8.5 Reserved Addresses. Frames containing the values of Functional > Addresses specified in Table 3-6 of the main body of this standard with > frame_type and mac_action parameter values of user_data_frame and > request_with_no_response, respectively, shall be relayed from the token > ring on which they are initially transmitted. > Apparently, the IEEE standards committee realized that there actually > are reasons to relay a received BPDU from one interface to another -- > something which the separate BPDU encoding in the PPP bridging > extensions makes next to impossible in the case of IEEE STP and SR > BPDUs. Actually, the reason the IEEE 802.5 standards committee did this was to allow a greater level of compatibility with IBM Token Ring Source Route bridges. This way, if a group of SR bridges in surrounded by a group of SRT bridges, the SR bridge's Spanning Tree will (correctly) detect a loop in the topology, and put additional ports to blocking state. Section C3.8.5 was added to override the following section in 802.1D (page 46): This statement is a special case of the one before it. "Table 3-6 records values of functional addresses . . ., but should not be relayed from the token ring on which they are initially transmitted." Nothing in either standards actually says that a message addressed to this functional address contains a BPDU. That is only specified in the IBM Token Ring Source Route spec. And obviously the converse is true from the standpoint of the IBM Token Ring spec. And that is the point. There are a multitude of possible bridge protocols. There is no reason for a special encapsulation to be assigned to a specific bridging protocol, and there are a lot of reasons not to make such an assignment. And by the way, if the stupidities of RFC-1220 really make sense, they would make sense at the IP layer as well. By the same (il)logic, there should be special RIP, EGP, BGP, HELLO, OSPF, IGRP and IGP encapsulations at the network layer. > something which the separate BPDU encoding in the PPP bridging > extensions makes next to impossible in the case of IEEE STP and SR > BPDUs. Again, the BPDU encoding is not changed in any way by the PPP Bridging spec., only the protocol type used in the PPP header. And, as I indicated before, handling this problem with the existing PPP Bridging standard is actually quite trival, though this does not address the additonal issue rasied by John Shriver. The problem is the absence of the complete DLSDU (MAC header + LLC header + BPDU). And since the absense can easily lead to path selection loops at the link layer, the problem is actually quite serious. Steve Senum Joachim Carlo Santos Martillo Ajami From ietf-ppp-request@ucdavis.ucdavis.edu Sun Nov 29 20:20:46 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20709; Sun, 29 Nov 92 20:16:52 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA02820; Sun, 29 Nov 92 20:00:24 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19697; Sun, 29 Nov 92 19:53:20 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from nero.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19432; Sun, 29 Nov 92 19:47:08 -0800 Received: by nero.clearpoint.com (4.1/1.34) id AA09963; Sun, 29 Nov 92 22:45:24 EST Date: Sun, 29 Nov 92 22:45:24 EST From: martillo@nero.clearpoint.com (Joachim Martillo) Message-Id: <9211300345.AA09963@nero.clearpoint.com> To: sgw@sgw.xyplex.com Cc: brad@fcr.com, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Scott Wasson's message of Tue, 3 Nov 92 17:12:10 EST <9211032212.AA08133@sgw.xyplex.com> Subject: ATCP (Actually Fractional Routers) Can the half-router formalism be generalized? ________ _________ --------| | | |----------- --------| ROUTER |-----------| ROUTER |----------- --------|________| |_________|----------- 3 SUBNETWORKS WAN LINK 3 SUBNETWORKS A given network interface can be given multiple IP addresses corresponding to multiple IP subnetworks. So one would think that it would be possible to route properly if each router thought it had 3 Network interfaces corresponding to the 3 subnetworks to which it connected directly and one network interface which had multiple IP addresses corresponding to the 3 subnetworks to which its peer connects directly. Unfortunately, I don't see a mechanism in the PPP IP address negotiation to actually negotiate this sort of set-up. Joachim Carlo Santos Martillo Ajami From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 30 07:50:40 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21405; Mon, 30 Nov 92 07:42:17 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04657; Mon, 30 Nov 92 07:19:30 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20480; Mon, 30 Nov 92 07:10:22 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from IETF.CNRI.RESTON.VA.US by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20231; Mon, 30 Nov 92 07:03:35 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02308; 30 Nov 92 10:00 EST To: brian@lloyd.com Cc: bsimpson@angband.stanford.edu, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: last call for pppext-ipxcp In-Reply-To: Your message of "Wed, 25 Nov 92 21:25:19 PST." <9211260525.AB03713@nic1.barrnet.net> Date: Mon, 30 Nov 92 10:00:39 -0500 From: Greg Vaudreuil Message-Id: <9211301000.aa02308@IETF.CNRI.Reston.VA.US> I received Bill Simpson's request for a last call for IPXCP but have been waiting for word from the chairman that the document is ready to go. It is the IESG Secretary, with the authorization of the Area Director, who sends a Last Call. The Area Director generally consults with the chairman of a Working Group to affirm that consensus within the Working Group has been reached. When a request for last call is sent to the IESG Secretary, please make every effort to reference an Internet Draft which is a final complete document. Only in response to unforseen comments or IESG objections is the document revised before RFC publication. Greg Vaudreuil IESG Secretary From ietf-ppp-request@ucdavis.ucdavis.edu Mon Nov 30 11:20:47 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28408; Mon, 30 Nov 92 11:10:17 -0800 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07375; Mon, 30 Nov 92 10:40:36 -0800 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27140; Mon, 30 Nov 92 10:32:52 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26777; Mon, 30 Nov 92 10:22:33 -0800 Received: by saffron.acc.com (4.1/SMI-4.1) id AA04112; Mon, 30 Nov 92 10:21:39 PST Date: Mon, 30 Nov 92 10:21:39 PST From: fbaker@acc.com (Fred Baker) Message-Id: <9211301821.AA04112@saffron.acc.com> To: martillo@nero.clearpoint.com Subject: Fractional Routers Cc: ietf-ppp@ucdavis.ucdavis.edu >> Can the half-router formalism be generalized? >> ________ _________ >> --------| | | |----------- >> --------| ROUTER |-----------| ROUTER |----------- >> --------|________| |_________|----------- >> >> 3 SUBNETWORKS WAN LINK 3 SUBNETWORKS >> A given network interface can be given multiple IP addresses >> corresponding to multiple IP subnetworks. So one would think that it >> would be possible to route properly if each router thought it had 3 >> Network interfaces corresponding to the 3 subnetworks to which it >> connected directly and one network interface which had multiple IP >> addresses corresponding to the 3 subnetworks to which its peer >> connects directly. Unfortunately, I don't see a mechanism in the PPP >> IP address negotiation to actually negotiate this sort of set-up. I'm not sure that PPP is the right place to formalize that. PPP provides a hook in that IP Address Negotiation is an optional facility; unnumbered links need not have an address negotiated. However, the "half router" concept is not really a link layer concept, it is a routing protocol concept. OSPF goes to great lengths to formalize it. PPP IP Address Negotiation is little more than "BOOTP for the line"; there is no reason to make it be more.