Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!caen!ox.com!ox.com!emv From: emv@ox.com (Ed Vielmetti) Newsgroups: comp.dcom.lans Subject: Re: WAN Bridge/Router over Fractional T1 (64K) Message-ID: Date: 16 Apr 91 19:25:50 GMT References: <1991Mar27.152925.8267@exloghou.portal.com> <1936@crackers.clearpoint.com> Sender: usenet@ox.com (Usenet News Administrator) Organization: OTA Limited Partnership, Ann Arbor MI. Lines: 122 In-Reply-To: martillo@crackers.clearpoint.com's message of 16 Apr 91 03:31:47 GMT In article <1936@crackers.clearpoint.com> martillo@crackers.clearpoint.com (Martillo) writes: I believe I have seen a draft of an RFC for using PPP as an encapsulation for transparent bridging over WAN links but this draft was in such a rough state that following it would not be appropriate to use as a specification. See nnsc.nsf.net:/internet-drafts/draft-ietf-pppext-bridging-01.txt; comments on that draft can go to fbaker@acc.com (F. Baker of Advanced Computer Communications). It does look rather rough. I'm sure he'd welcome your input. After seeing Vielmetti's comment, I reread RFCs 1171 and 1172. This rereading reinforced my conclusion PPP is rather inelegant, mostly harmless and not terribly relevant. Inelegant, perhaps. Irrelevant, not, not to my design criteria; everything has to speak PPP, everything has to work together, and proprietary serial protocols are out. ...Unless the US State Department takes interest (extremely unlikely), PPP will have no success whatsoever. PPP competes in a marketplace where protocols do not need to be blessed by government agencies. As such the US State Department doesn't need to care one way or another. And the marketplace has showed willingness to adopt PPP for sync and async applications -- in particular, cisco and Telebit are shipping products right now that interoperate well. (i'm working on a real list.) Interoperability, not blind conformance to standards documents, is the measure of utility in a large, diverse, potentially hostile environment. Both models have their domain of application, but even with the frills, ornamentation and its somewhat antique style, PPP belong more to the ARPA Internet model than to the ISO OSI model. III) IRRELEVANCE Since PPP is basically a link-level encapsulation with delusions of grandeur, this protocol is essentially irrelevant for any sort of sophisticated computer networking via serial links.... In order to address the question of architecting an IP network which uses multiple serial links, I have architected into the Little Dipper a high-performance intranetwork system similar to the Cypress Intranet Network architecture. Even if both Little Dippers and the boxes of other vendors both talk PPP, unless the boxes of the other vendors conform to the Little Dipper intranetwork architecture, the Little Dipper and these other boxes really will not interwork. I'm not entirely familiar with Cypress, though I understand that it has an innovative approach to wide-area networking. Have enough of the specifications been published so that a competitor of yours could could produce a product which would interoperate with yours? The Internet market shies away from proprietary solutions whenever possible. Until that point I must say again that for my application, a box without PPP is quite useless. Some other people might have applications which could deal with single-source, proprietary, or undocumented protocols; they could afford always to buy things in pairs and pay whatever price you were going to ask and deal with your level of support. I would think that they might be interested in your product if it were better/faster/cheaper than the rest as long as interoperability was not an issue. (just don't bother showing it at Interop.) IV) CONCLUSION I must wonder about this continual insistence on PPP, which is merely a link-level encapsulation and which does not address any of the real issues of using serial links as a medium for an IP network. PPP in the ordinary realm of interest addresses the two questions of "my cisco doesn't talk to my Proteon on a high speed wire" and "SLIP is just too horrible to use for real networking". PPP as a packet format for bridging is not yet standardized and has still a ways to go before the market proves its utility. Hard to say when or whether that will be. Read comp.dcom.sys.cisco in the last week or so and see what real people other than myself are haggling over. People who worked on PPP through the IETF might have a similar interest in demanding the use of PPP in bridges and routers because otherwise their managements might wonder why the companies spent money to send representatives to take part in the IETF deliberations on PPP. In the future, I would hope that people who discuss PPP issues would make clear whether they might be motivated by such an interest. I personally have no stake in PPP, and to tell the truth while PPP looks to me like another RDP or less, I am willing to be persuaded otherwise. I have attended two IETF meetings, one because it was in town and the other because I insisted. I have no financial stake in any particular implementation of the protocol, and I can't claim credit for writing any PPP code. Your assertion that PPP proponents are somehow justifying trips to Reno by flogging the utility of the protocol in public is disingenous. My interest in PPP is simple. UUCP is a dead protocol, and something needs to replace it. SLIP would have been the likely alternative except that it's too brittle, and PPP appears to have enough hooks in it to make it managable and workable. Similarly, proprietary high speed serial protocols make it uneconomical to mix and match routers of various vendors on a network. Joachim Carlo Santos Martillo Ajami The above comments represent my current thoughts as system architect. -- Msen Edward Vielmetti /|--- vice president for research, MSEN Inc. emv@msen.com "With all of the attention and publicity focused on gigabit networks, not much notice has been given to small and largely unfunded research efforts which are studying innovative approaches for dealing with technical issues within the constraints of economic science." RFC 1216