From tomj@fido.wps.com Mon Feb 21 12:10:19 1994
Received: from fido.wps.com by fnord.tlg.org (8.3/wps.com-hackery)
	id MAA05383; Mon, 21 Feb 1994 12:10:12 -0800
Received: by fido.wps.com (5.67/wps.com-hackery)
	id AA10828; Mon, 21 Feb 94 12:12:18 -0800
Received: from tlg.org by fido.wps.com (5.67/wps.com-hackery)
	id AA10716; Mon, 21 Feb 94 11:35:21 -0800
Received: from localhost by fnord.tlg.org (8.3/wps.com-hackery)
	id LAA05203; Mon, 21 Feb 1994 11:33:11 -0800
Received: from scruz.net by fnord.tlg.org (8.3/wps.com-hackery)
	id UAA04253; Sun, 20 Feb 1994 20:08:31 -0800
Received: from localhost by scruz.net (8.3/1.34)
	id UAA20288; Sun, 20 Feb 1994 20:07:02 -0800
Date: Sun, 20 Feb 1994 20:07:02 -0800
From: matthew@scruz.net (Matthew Kaufman)
Message-Id: <199402210407.UAA20288@scruz.net>
To: admin@tlg.org, gnu@toad.com, pozar@fnord.tlg.org
Subject: Re: scruznet upgrade
Cc: admin@scruz.net, matthew@nic.scruz.net
Sender: tomj@fido.wps.com
Status: OR


Several inter-exchange carriers offer frame relay with varying
rate structures (Sprint and MCI both have a pay-by-the-byte scheme,
plus a base rate, and Wiltel has a flat rate, distance-insensitive
scheme, but which is rather expensive for local things)
Furthermore, it isn't clear that connecting {San Francisco, Santa Cruz,
San Jose} is really something we could convince an IXC to do for us,
since all three are in the same LATA.

PacBell has a frame relay offering available in some LATAs now (including
ours, but not the next one south for a few more months)

Rates are as follows:
to connect into frame relay cloud at
56kbps:  local loop ($50/mo) + 56k FR access charge ($75/mo)
128kbps: local loop ($163/mo) + 384k FR access ($150/mo)
384kbps: local loop ($163/mo) + 384k FR access ($400/mo)
1.5Mbps: local loop ($163/mo) + 1.5M FR access ($500/mo)

1 free virtual circuit per node, additional circuits are $15/mo
(or lower, in quantity)

install charges are:
56kbps:  local loop ($620) + FR port ($375)
128kbps: local loop ($1324) + FR port ($375)
384kbps: local loop ($1324) + FR port ($375)
1.5Mbps: local loop ($1324) + FR port ($375)

Virtual circuits cannot cross LATA boundaries.
We believe, but aren't totally sure, that virtual circuits
can only be installed between nodes which are INCLUDED ON
THE SAME BILL / ACCOUNT.

The 56kb line to santa cruz is currently at well over 50% capacity
during EVERY minute of the day, as measured by SNMP counters.
So we MUST upgrade ASAP.

Our alternatives are: (assuming we wish to continue being a TLG customer,
  which we do)
 1. Increase the line to mountain view to fractional T-1, later to full T-1
 2. Use frame relay, and take advantage of its distance/price insensitivity
  to go direct to san francisco.

 #1 is simpler. #2 keeps santa cruz traffic from competing with cygnus +
   mtn view + palo alto traffic. #2 makes our pending expansion to san 
   jose easy, #1 would be wasted in the reconfiguration that would need to
   take place when we move into san jose.
 #2 is _slightly_ more expensive than #1 (because even though frame relay
 is expensive, so is the 30+ mile run from cygnus to santa cruz),
 but allows a lot more flexibility, and of course bypasses the mv-sf link
 traffic (and failure points)

note that the Livingston IRX routers understand frame relay INTERNALLY.
All you need is a CSU/DSU, and you then change the mode on the port,
and give it a list of DLCIs, which is currently limited to 16
virtual circuits per physical port, according to their tech support.

 we plan to move into san jose in the very near future, and offer SLIP/PPP
 as well as our ISDN Centrex offering, which we currently are quite successful
 with here in santa cruz.

 Another advantage of going direct to san francisco is that, in the event
 we need even more bandwidth, TLG and scruz-net could split the cost
 of going to TWO t-1 lines into sprint, rather than us being forced to
 stop being a TLG/RGnet customer (which has many advantages when it
 comes time to do things like deal with the politics which will happen in
 the future)

 We understand the sensibility of only running a single line into the
 frame relay cloud, but we have some concerns:
  We want the ability to add and delete virtual circuts at will, so
  that we can add POPs, and have them have direct virtual circuits to
  san francisco, as well as to santa cruz (where our news/ftp/etc server
  resides)
  We want the ability to add virtual circuits to the router in san
  francisco, so that we can route traffic efficiently to customers that
  we attach directly to the frame relay cloud... we also want
  technical control over the router/port that talks to the frame relay
  cloud in san francisco, so that we have SNMP access, ability to
  change virtual circuit paramaters, etc.
  We want to maintain a relatively clear demarcation between TLG and
  scruz-net, so that problem resolution and responsibility for technical
  support is clear. (You don't want our customers calling you when we
  change something, just because they think that they have a direct
  circuit to TLG, and so TLG is responsible.) (And we don't want to
  find that due to a mistake, some virtual circuits to our customers
  had been deleted from the router in san francisco)
  We want to not end up paying TLG extra money each and every time we
  add a virtual circuit (for instance, to hook up our san jose POP, or
  scruznet customers elsewhere within the LATA)
  We want to not additionally confuse PacBell billing issues...  IF
  virtual circuits can only be between nodes that belong to the same
  account, then our virtual circuit between san jose and santa cruz
  would be billed to TLG (or whoever was paying for the frame relay
  "cloud")

The best solution to this, in our opinion, is for us to install a
dedicated router, which we own, at 444 market and then to pay TLG
a rate which accounts for the rate at which we can move data into
and out of 444 market (limited to a 384kbps connection at first, and
upgrading to a full T-1 in the very near future)
(This is, in effect, the same as installing a 384kbps line from 444 market
to a building next door and having us put our frame relay router _there_)

We are willing to consider other alternatives, but we have an
EXTREME need to get the lines ordered EARLY this week. The 17+
day delay from pacbell on leased line installations is already PAST the
point at which our customers need us to have more than 56k to
the outside world.

In the meantime, we are going ahead with ordering equipment (but not
lines, until a decision has been reached), so if anyone has any 
recommendations for T-1 CSU/DSUs, we'd really like to hear them.
And we'll be hoping that if we go with frame relay, we don't experience
the same problems with getting everything to work together that
John Harkin up at NBN has been having.

-matthew kaufman
 matthew@scruz.net