U0A61@WVNVM.BITNET (Bryan, Jerry) (02/04/90)
>To the best of my knowledge BITNET has NOT yet changed its membership >rules to allow the use of BITNET II links in place of 9600 baud leased >lines and until we are informed of such a change in policy we will not >consider moving to BITNET II. Hmm, this came up a few months ago, and I think that BITNIC's interpretation of the requirement is entirely wrong. My recollection is that BITNIC took an absolutely "letter of the law" approach, saying only 9600 baud connections were allowed. Someone please correct me if I am representing BITNIC's views incorrectly. Anyway, I have read the requirement several times, and probably if you take an absolute "letter of the law" interpretation, anybody who is running anything other than 9600 baud is in violation and should be kicked out of BITNET. This would include not only VMNET sites, but anybody who is running traditional connections, but running them at a speed different from 9600 baud. Under this "letter of the law" interpretation, the whole state of West Virginia would be in violation because our sites are connected to each other via 56KB Ethernet bridges running JNET (among many other things) over DECNET. We are also running VMNET between VAX's and IBM machines, rather than using a 9600 baud connection. As I recall, the state of Texas chimed in with a similar story, and I am sure that there are numerous similar situations. Repeating myself, I suggest that any statement that you have to run at 9600 baud is just plain wrong. I would suggest that this is true even if the statement is made by BITNIC or by the Board. If they say so, they just haven't thought the requirement through. The "spirit of the law", and the clear intent, is that if you want to join BITNET at 9600 baud with a traditional synchronous line, you can. The intent was to provide a low cost, simple connection, using standard vanilla vendor hardware and software. For example, a VM site cannot be forced to run MAILER or LISTSERV or RICEMAIL or any such thing. A VM site can use NOTE and RDRLIST etc. and be a member in good standing. I tried for years to get a friend at another site to run MAILER, but he did not want to, and he replied (correctly) that BITNET did not require MAILER, only RSCS. However, I don't see anything in the requirements that *prevents* anybody from exceeding the requirements, either hardware or software. The only catch on the hardware end is that one site cannot force another site to go above 9600 baud if they don't want to. At least that's the way I read the requirements, and that is the way most of us have interpreted them. Otherwise, most of us would have to be considered in technical violation one way or the other. It seems to me that the Princeton proposal maintains this "least common denominator" spirit. As I read the proposal, anybody that wanted to connect in at 9600 baud could still do so. Despite my (perhaps) somewhat radical opinion on this, it has to be observed that VMNET in and of itself does offer a considerable potential for routing table chaos, and therefore its implementation will require considerable care rather than taking a laissez-faire approach. There is no problem if anybody replacing a 9600 baud link with VMNET connects to exactly the same node or nodes. However, if 9600 baud links are converted to VMNET links to different and/or additional nodes, the network could easily become full of loops. It seems to me that the Princeton proposal addresses this problem in a very sensible and workable fashion. I am cross-posting this to POLICY-L. I am not sure which list is the best for continuing the discussion of 9600 baud vs. VMNET.
LONG@YALEVM.BITNET (Philip Long) (02/05/90)
REPLY TO 02/03/90 21:25 FROM U0A61@WVNVM.BITNET "Bryan, Jerry": BITNET Restructuring Proposal In a message dated 90/2/3, Jerry Bryan included the following excerpt from a previous message (presumably on the BITNET-2 list since I didn't see a copy on POLICY-L): >To the best of my knowledge BITNET has NOT yet changed its membership >rules to allow the use of BITNET II links in place of 9600 baud leased >lines and until we are informed of such a change in policy we will not >consider moving to BITNET II. Jerry continues with a discussion of these issues. At its January 21-22 meeting, the CREN Board did officially change its membership rules to to allow suitably capable BITNET II and other lines in place of a 9600 baud RSCS line. The Board Technical committee also discussed the roll out of BITNET II. I am not a member of the Technical Committee and am not currently particularly familiar with the BITNET II discussion, but you will find details on both these issues in the Board Minutes. The Board has reviewed the first draft of the minutes and just this evening I circulated the second draft. Pending discovery of new errors, the minutes will be posted at the BITNIC and CSNET CIC sometime during the week of 2/12 (announcement will be made on BITNEWS). I hope you will find these actions both relevant and positive. - Philip Long, Secretary
LVARIAN@PUCC.BITNET (Lee C. Varian) (02/07/90)
Dear BITNET/CREN colleague,
A proposal for a restructuring of the BITNET network was presented to
the CREN Technical Committee in early December, 1989. At the most
recent CREN Board meeting, the Committee recommended that the proposal
be more widely circulated within the BITNET/CREN community. This
mailing is an attempt to comply with that recommendation which was
accepted by the Board. Please accept our apology if you receive more
than one copy of this note, as we are posting to several lists.
As you probably already know, several of us at Princeton have been
working on the VMNET programs which allow RSCS NJE traffic to use IP
networks. One of the motivations for this work was to have BITNET
connections over IP networks. Once the technical aspects of RSCS NJE
over IP were resolved, the questions of how to best use, deploy, and
manage this new type of BITNET connection were raised.
In an attempt to address some of these questions, we are submitting
for discussion a proposal which would reorganize the structure of the
BITNET network. A number of core sites are proposed which would play
key roles in the restructured BITNET network.
It is important to point out that this recommendation does not itself
propose the creation of new IP network connectivity, but rather suggests
how BITNET NJE traffic might be organized to utilize existing IP
connectivity. The proposal is compatible with and could utilize
any further growth of the NSFNET and regional IP networks, as well as
any CREN IP network.
If you are interested in the topic, we hope you will carefully consider
the proposal and provide your input on its possible implementation.
A copy of the proposal may be gotten from the LISTSERV at PUCC. To get a
copy of the proposal:
TELL LISTSERV AT PUCC GET BIT2PLAN PROPOSAL
Or, send mail to LISTSERV@PUCC on Bitnet with the body / text of the
mail containing the command:
GET BIT2PLAN PROPOSAL
A file of the discussions which have taken place thus far on this
proposal may be gotten from the LISTSERV at PUCC. To get a copy of
the file:
TELL LISTSERV AT PUCC GET BIT2PLAN COMMENTS
Or, send mail to LISTSERV@PUCC on Bitnet with the body / text of the
mail containing the command:
GET BIT2PLAN COMMENTS
We would suggest that discussion of this proposal be carried out on the
NODMGT-L list. To become a subscriber on this list:
TELL LISTSERV AT BITNIC SUBSCRIBE NODMGT-L Firstname Lastname
Or, send mail to LISTSERV@BITNIC on Bitnet with the body / text of the
mail containing the command:
SUB NODMGT-L firstname lastname
Lee Varian (LVARIAN@PUCC)
Peter Olenick (Q0239@PUCC)
Michael Gettes (GETTES@PUCC)ACC00RRB@UNCCVM.BITNET (Robert R. Blackmun) (02/07/90)
On Tue, 6 Feb 90 11:04:58 EST Lee C. Varian said: > >We would suggest that discussion of this proposal be carried out on the >NODMGT-L list. > Although it is certainly appropriate for the technical details of the proposed restructuring to be discussed on the NODMGT-L list, I think there are related issues that are appropriate for POLICY-L and/or FUTURE-L: 1. Given that one of Bitnet's objectives is to remain independent of "external" control, funding, etc., is it appropriate to adopt a hierarchical network strategy when the strategy is based on using a national backbone provide by someone else (NSFNet)? 2. Since it's generally understood that NSFNet/NREN will eventually become "self supporting" (as the mid-level regional networks sponsored by NSF are expected to do shortly), how do the economics of Bitnet II appear (and compare to NSFNet and mid-levels)? 3. Since some people believe very strongly that one of the distinct advantages of Bitnet has been the absence of traffic-based charges (which are widely recognized as barriers to development of use of the network for scholarly activities), how will the restructuring affect costs and charges in the future (when use of the IP backbone is no longer "free" and may be subject to traffic-based charges).
LONG@YALEVM.BITNET (Philip Long) (02/07/90)
REPLY TO 02/07/90 09:46 FROM ACC00RRB@UNCCVM.BITNET "Robert R. Blackmun": Re: BITNET Restructuring Proposal Bob, you raise excellent questions. While there are no certain answers, the CREN Board has wrestled with these questions and is currently exploring the following basic idea: 1. Folks who have high-speed IP links (regionals or whatever) do not want to spend a fair amount of money maintaining a low-speed RSCS link. As you know, we have resisted dropping this link requirement for sometime for the very reasons you raise, however, while NSFNET and regional access is here now and not charging for traffic, members rightly complain about having to pay significant dollars for what amounts to insurance. Of course, giving up the private lines could give up some of CREN's independence on usage policy - more on this later. At the last meeting (1/21-22) the Board modified the membership rules to allow substitution of equivalent (and free to CREN traffic) bandwidth for the former dedicated 9600 baud RSCS line. 2. Recognizing the various risks sharing bandwidth on a government network (which is consciously planned to become a commercial network), CREN must plan to provide alternate bandwidth if and when it may be required: The technical committee is actively studying what it would cost to create a private backbone and what lead time would be required. CREN does have a modest financial reserve, and recreating a private backbone in the case of an emergency would be one of the appropriate uses of this reserve in my view. Of course, if such an emergency arose, many schools who find the need to drop their private lines today would have to again pick up the costs of a private line again, but would probably be happy to have the opportunity to do so under the circumstances. (At such a future time, probably at least 56Kb, but because ordered and centrally, probably at the average cost of most 9600 baud lines today.) The strategy then is to use the bandwidth legimately available to us as a designated NSF midlevel network to avoid current costs, but to have a funded and viable plan to recreate a private back bone if and when it might be needed. As stated, this option is currently under investigation, it has not been adopted by the Board. I favor the strategy. - Philip Long, member CREN Board of Trustees
OPSRJH@UCCVMA.BITNET (Richard Hintz) (02/08/90)
On Wed, 7 Feb 90 10:33:14 EST Philip Long said: (things omitted) >2. Recognizing the various risks sharing bandwidth on a government network >(which is consciously planned to become a commercial network), CREN must plan >to provide alternate bandwidth if and when it may be required: > >The technical committee is actively studying what it would cost to create a >private backbone and what lead time would be required. CREN does have a modest >financial reserve, and recreating a private backbone in the case of an >emergency would be one of the appropriate uses of this reserve in my view. Of Two points about Mr Long's note. First, this is the first that I've heard that NREN planners are consciously expecting that NREN will become a commercial network. I'm not disputing this, it's just that it's a surprise. Second, I'm concerned at what I perceive to be the start of factionalism between CREN management and NREN management. This is a bit of a surprise, too, although perhaps it shouldn't be. Am I seeing problems where there aren't any or can we expect to see NREN vs. CREN wars in the future? Rich Hintz University of California
IMHW400@INDYVAX.BITNET (Mark H. Wood) (02/08/90)
Is NSFNET aware that CREN is making contingency plans to secede if NSFNET adopts usage-sensitive pricing? Given the potential amount of business that BITNET represents, that knowledge might influence the debate over such pricing. Let's not wait for our suppliers to make us mad; let's tell them right now what we want and what we might do if we don't get it! ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Mark H. Wood (317)274-0749 III U U PPPP U U III Indiana University - Purdue University at Indianapolis I U U P P U U I IMHW400@INDYVAX.IUPUI.EDU I U U PPPP U U I IMHW400@INDYVAX.BITNET I U U P U U I [@disclaimer@] III UUU P UUU III
LVARIAN@PUCC.BITNET (Lee C. Varian) (02/08/90)
Mark, I think your point about CREN having early input to the NSFnet is a good one (and I think it will happen almost automatically since several of the CREN Board members are also on various advisory panels of the NSF involved with networking). Also, there are options other than secession which might be available even if the NSFnet went to usage-sensitive pricing (such as CREN buying some bandwidth-limited or packet-limited service from the NSFnet), so as to continue the BITNET tradition of usage-INsensitive fees to its member institutions. In effect, BITNET's original 9600 baud network was exactly such a bandwidth-limited service with usage-insensitive fees. Lee Varian, lvarian@pucc.princeton.edu Princeton University