[146490] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

RE: Cable standards question

daemon@ATHENA.MIT.EDU (Sam (Walter) Gailey)
Mon Nov 14 17:08:28 2011

From: "Sam (Walter) Gailey" <gaileywg@MANSFIELDCT.ORG>
To: "nanog@nanog.org" <nanog@nanog.org>
Date: Mon, 14 Nov 2011 22:07:17 +0000
In-Reply-To: <9A40A794-56FE-4773-B6A8-7BAD9EDF77FE@humancapitaldev.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

First off, thanks to everyone who has replied, both on and off list, I've g=
otten some very good information on this, raising things I hadn't considere=
d, particularly involving testing and warranties.

Daniel Seagraves wrote:
<Is it appropriate to just say "When installing fiber-optic cable the vendo=
r will ensure the resulting installation does not suck."?>

Getting an installation that doesn't suck is indeed the core of the matter.=
 However, "doesn't suck" is a rather vague concept as a point of law in cas=
e you have to sue your vendor for having installed something that sucks. Th=
at's why I was looking for a set of standards that I can point to and say (=
as an example)  "your installation sucks, and it sucks because you didn't f=
ollow X standard, and ran unshielded fiber at a 90 degree angle over a knif=
e edge."

< Maybe there should be a legal definition of the concept of suck, so that =
suckage could be contractually minimized.>

Unfortunately vendors install suckage all the time. Our own particular horr=
or story was one of our schools where half the school was experiencing inte=
rmittent issues of crosstalk, lag, unexplained packet loss, etc. Some days =
it was fine, others it wasn't and it took us some time to find out that the=
 cabling vendor had connected the two network closets via plain old cat 5 c=
able, a run that was considerably longer than 300 feet. You wouldn't normal=
ly expect to have to specify to telecommunications vendors that you don't e=
xceed the maximum cable length, but there it was. We replaced that link wit=
h multimode, and the problems immediately vanished. I'm sure others have si=
milar stories.=20

A number of people have asked for more details on the project and I deliber=
ately didn't put those in because I was looking more for a standard that, i=
f followed, produces acceptable link no matter what the project details are=
. For the curious, it's a simple point-to-point link involving an existing =
building and new construction that are about a mile apart . It will be sing=
lemode, we will provide the racks on both ends, and we're specifying SC ter=
minations. Whether we own or lease the fiber, lit or dark, depends on the e=
conomics of the quotes that come back to us. It's not a complicated project=
, but I shouldn't have to re-write a cabling spec as part of the RFP just t=
o keep the vendors honest. A number of good references have been sent to me=
 so I think I'm all set. Thanks, NANOG! :)

---Sam=20



-----Original Message-----
From: Daniel Seagraves [mailto:dseagrav@humancapitaldev.com]=20
Sent: Monday, November 14, 2011 9:58 AM
To: nanog@nanog.org
Subject: Re: Cable standards question


On Nov 14, 2011, at 8:42 AM, Sam (Walter) Gailey wrote:

> "The vendor will provide fiber connectivity between (building A) and (bui=
lding B). Vendor will be responsible for all building penetrations and term=
inations. When  installing the fiber-optic cable the vendor will follow the=
 appropriate TIA/EIA 568 standards for fiber-optic cabling."
>=20
> Any suggestions or examples of language would be very appreciated. Offlis=
t contact is probably best.

Is it appropriate to just say "When installing fiber-optic cable the vendor=
 will ensure the resulting installation does not suck."?
That would seem to me to be the most direct solution to the problem. I mean=
, standards are all well and good, but what if the standard sucks?
Then you'd be up a creek.

Maybe there should be a legal definition of the concept of suck, so that su=
ckage could be contractually minimized.




home help back first fref pref prev next nref lref last post