Re: Cost of fiber run between neighbouring office buildings

[Walter Keen]

Where I work for a local telecommunications provider, we will not run any fiber 
smaller than 24 strand, and these days that is a drop into a building. 

When talking about single mode fiber, the cost per foot difference in 2, 8, or 
even 24 strand is typically a matter of less than $1 per foot. 
Some of the prices I've seen lately on google indicate about $.4/ft for 
2-strand, $.5/ft for 6-strand, and $1.8/ft for 24-strand 

It's all about the cost of getting it run by a contractor (which is typical if 
you have to get conduit installed, or run along telephone/power poles aerial) , 
unless you're in a position to do it yourself. 

You'd likely have to pay someone to terminate it into a patch panel for you, 
but it may be cheaper for them to do all strands at once as opposed to having 
them come back later. 




- Original Message -

From: "Robert E. Seastrom"  
To: "Nick Hilliard"  
Cc: "NANOG"  
Sent: Tuesday, October 2, 2012 9:48:33 AM 
Subject: Re: Cost of fiber run between neighbouring office buildings 


Second what Nick said. Also, get quotes for double, quadruple, and 
more of the number of fibers you think you need today. If it makes 
economic sense to leave strands unterminated (coil neatly in the 
splice tray and have someone term later) by all means do it. Extra 
strands in the cable are almost free compared to the labor to pull it 
in. 

-r 

Nick Hilliard  writes: 

> On 02/10/2012 13:35, Hank Disuko wrote: 
>> - 2 x 6-Strand 50/125u multimode, Tight Buffered, Armoured, Laser Ultra-Fox 
>> Fiber cables 
>> - Distance of run is approx 520 meters 
> 
> For that length, go with single-mode. 10G-LR will happily run on 10km of 
> SMF, but 10G-SR flakes out at ~300m even on OM3. Laying outdoor MMF plant 
> like this is totally pointless. Using MMF for anything outside your 
> cabinet / small cage is creating a legacy deployment on day 1 which will 
> bite you in future years. 
> 
> To answer the question you asked: if the ducts are already in place and 
> you're just pulling fibre through, you should have a breakdown in terms of 
> # of terminations + the manpower required to handle the pull + cable 
> finishing. I.e. it shouldn't be very much. If you need ducting laid or if 
> your existing ducting is in poor shape, that's a different issue. 
> 
> Nick 

Re: names are not numbers, was IPv4 address length technical design

[Joe Hamelin]

On Sat, Oct 6, 2012 at 6:14 PM, John Levine  wrote:
>
>
> Hey, I've got a great idea.  Let's lose this silly phone number
> portability nonsense and use phone numbers as routes.
>

You do not want to go down the hell hole that is SS7.

--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474

Re: ESR muses on, among other things, the early IETF

[bmanning]

On Sat, Oct 06, 2012 at 06:12:08PM -0400, Frank Kastenholz wrote:
> 
> On Oct 6, 2012, at 6:39 AM, bmann...@vacation.karoshi.com wrote:
> 
> > On Sat, Oct 06, 2012 at 10:14:41AM +0100, Nick Hilliard wrote:
> >> On 06/10/2012 03:20, Jay Ashworth wrote:
> >>> Those who know Fred and knew Jon personally might want to throw an oar in 
> >>> the
> >>> water on this blog posting from last month..
> ...
> 
> >I -think- Jon and Fred were not contemporaries.  Fred is
> >closer to my age than Jon.
> 
> While I don't know how old either is/would be, Fred was active in the IETF 
> before
> I joined the IESG, I appointed him chair of the pppwg in 95 or 96 or so
> (I think?) and he became IETF chair in 96 or so --- the last year I was on 
> the IESG.
> And was at the nerds on the beach IETF in Hawaii in89 or 90 iirc
> --Jon. Passed away in 98. 
> 
> They certainly overlapped in their i* lives
> 
> Frank Kastenholz 
> 

going back another decade,  Fred and I both worked on/with bridging 
technologies,
before routing was popular.  Jon had us beat by at least a decade - 
early 1970s.
We cme to the party in the late 70's early 80s.

/bill

Re: names are not numbers, was IPv4 address length technical design

[John Levine]

In article <20592.28334.622769.539...@world.std.com> you write:
>It's occured to you that FQDNs contain some structured information,
>no?

Hey, I've got a great idea.  Let's lose this silly phone number
portability nonsense and use phone numbers as routes.

I mean, anyone who moves and takes his cell phone with him has
only himself to blame, right?

R's,
John

Re: 100.100.0.0/24

[Randy Bush]

 http://www.team-cymru.org/Services/Bogons/bgp.html
>>> Please tell me how I can configure my router to use that feed to
>>> automatically reject any bogon advertisements I receive from other BGP
>>> neigbhors.
>> 
>> you actually have to look at that web page
> 
> If you're seeing the same page, the configs and explanations there show
> how to drop packets destined to bogons, not routes.
> 
> (I also want to know the answer to that question)

then read the frelling page!!!

http://www.team-cymru.org/Services/Bogons/bgp-examples.html#cisco-full-v4trans

router bgp 
 ! Session 1
 neighbor A.B.C.D remote-as 65332
 neighbor A.B.C.D description 
 neighbor A.B.C.D ebgp-multihop 255
 neighbor A.B.C.D password 
 ! Session 2
 neighbor E.F.G.H remote-as 65332
 neighbor E.F.G.H description 
 neighbor E.F.G.H ebgp-multihop 255
 neighbor E.F.G.H password 
!
 address-family ipv4
  ! Session 1
  neighbor A.B.C.D activate
  neighbor A.B.C.D soft-reconfiguration inbound
  neighbor A.B.C.D prefix-list cymru-out-v4 out
  neighbor A.B.C.D route-map CYMRUBOGONS-V4 in
  ! Session 2
  neighbor E.F.G.H activate
  neighbor E.F.G.H soft-reconfiguration inbound
  neighbor E.F.G.H prefix-list cymru-out-v4 out
  neighbor E.F.G.H route-map CYMRUBOGONS-V4 in
!
 address-family ipv6
  ! Session 1
  neighbor A.B.C.D activate
  neighbor A.B.C.D soft-reconfiguration inbound
  neighbor A.B.C.D prefix-list cymru-out-v6 out
  neighbor A.B.C.D route-map CYMRUBOGONS-V6 in
  ! Session 2
  neighbor E.F.G.H activate
  neighbor E.F.G.H soft-reconfiguration inbound
  neighbor E.F.G.H prefix-list cymru-out-v6 out
  neighbor E.F.G.H route-map CYMRUBOGONS-V6 in
!
! Depending on IOS version, you may need to configure your router
! for new-style community syntax.
ip bgp-community new-format
!
ip community-list 100 permit 65332:888
!
ip route 192.0.2.1 255.255.255.255 Null0
!
ip prefix-list cymru-out-v4 seq 5 deny 0.0.0.0/0 le 32
!
ipv6 route 2001:DB8:0:DEAD:BEEF::1/128 Null0
!
ipv6 prefix-list cymru-out-v6 seq 5 deny ::/0 le 128
!
route-map CYMRUBOGONS-V6 permit 10
description IPv6 Filter bogons learned from cymru.com bogon route-servers
match community 100
set ipv6 next-hop 2001:DB8:0:DEAD:BEEF::1
!
route-map CYMRUBOGONS-V4 permit 10
description IPv4 Filter bogons learned from cymru.com bogon route-servers
match community 100
set ip next-hop 192.0.2.1

Re: 100.100.0.0/24

[Vasil Kolev]

В 16:22 -0700 на 06.10.2012 (сб), Randy Bush написа:
> >> http://www.team-cymru.org/Services/Bogons/bgp.html
> > Please tell me how I can configure my router to use that feed to
> > automatically reject any bogon advertisements I receive from other BGP
> > neigbhors.
> 
> you actually have to look at that web page
> 

If you're seeing the same page, the configs and explanations there show
how to drop packets destined to bogons, not routes.

(I also want to know the answer to that question)

-- 
Regards,
Vasil Kolev


signature.asc
Description: This is a digitally signed message part

Re: 100.100.0.0/24

[Randy Bush]

>> http://www.team-cymru.org/Services/Bogons/bgp.html
> Please tell me how I can configure my router to use that feed to
> automatically reject any bogon advertisements I receive from other BGP
> neigbhors.

you actually have to look at that web page

Re: 100.100.0.0/24

[Brett Frankenberger]

On Fri, Oct 05, 2012 at 10:24:18AM -0500, Ben Bartsch wrote:
> use this:
> 
> http://www.team-cymru.org/Services/Bogons/bgp.html

Please tell me how I can configure my router to use that feed to
automatically reject any bogon advertisements I receive from other BGP
neigbhors.

> On Fri, Oct 5, 2012 at 10:18 AM, Jared Mauch  wrote:
> >
> > I suspect not everyone has updated their 'bogon' filters.  I found a very
> > minor gap in our filters, we are working on correcting it.

 -- Brett

Re: IPv4 address length technical design

[Cutler James R]

On Oct 6, 2012, at 2:35 PM, Barry Shein  wrote, in part:
> 
> We can map from host names to ip addresses to routing actions, right?
> 
> So clearly they're not unrelated or independent variables. There's a
> smooth function from hostname->ipaddr->routing.

I would suggest that this is a bit optimistic and oversimplified.  

The mapping between DNS names and IP addresses is not necessarily unique or 
commutative. One may change either arbitrarily, as long some "directory 
service" exists which contains the current mapping.  In addition, multiple DNS 
names may map to one or more IP addresses and IP addresses do not necessarily 
map to unique routes or DNS names. These are not smooth functions.

If names and addresses are not independent, then any change in either would 
predicate a change in the another.  That is apparently not the experience of 
most network providers.  The only action required for a change in network name 
or address is to update the "directory service" used to map between name and 
address.

> Is this a good use of DNS computrons? Answering DNS inquiries for
> every new connection for every single-routed host on the internet?

Yes, it is.  Most "new" connections are repeats of previous connections (I 
request mail from my IMAP servers several times each day) and the preponderance 
of caching resolvers make the effort and traffic trivial. Even in the absence 
of cached final DNS reply, putting the lookup burden on the end system rather 
than the "routing engines" should be a no-brainer.

In particular, adding caching of connection destinations within routing 
components would not only seriously burden (read, slow down) routing engines 
but is also a violation of the Stupid Network.  David S Isenberg said, "In a 
Stupid Network, control passes from the center to the edge".  See 
http://www.isen.com/papers/Dawnstupid.html, originally published as the cover 
story of ACM Networker 2.1, February/March 1998, pp. 24-31. 

Re: max-prefix and platform tcam limits: they are things

[Hank Nussbacher]

On Fri, 5 Oct 2012, jim deleskie wrote:

Just ask yourself how many times you have seen a Godaddy IP/NOC person 
post anything to NANOG or to any other technical forum?


-Hank


Yes that math would work, but if your device can't handle 1x Internet
routing and your running without some serious max-prefix/filters it
says even more about your IP eng team then I'd be willing to comment
on.

-jim

On Fri, Oct 5, 2012 at 9:17 PM,   wrote:

On Fri, 05 Oct 2012 21:05:07 -0300, jim deleskie said:


But here goes, 210x the size of normal really?  210% I'd have a hard
time believing. Did anyone else anywhere see a route leak equal to
larger then the entire Internet that day, anywhere else that could of
caused this?


If the device was only expecting 2K or so internal routes, getting hit with
the 440K routes in the DFZ would be 210x

RE: IPv4 address length technical design

[nanog]

My money is on an epic troll. Four out of five network engineers surveyed
agree their individual IP headers are best served without condiments.

-Original Message-
From: Jay Ashworth [mailto:j...@baylink.com] 
Sent: Friday, October 05, 2012 2:06 PM
To: NANOG
Subject: Re: IPv4 address length technical design

- Original Message -
> From: "Barry Shein" 

> Don't change anything! That would...change things!

Your man; he is made of straw.  :-)

> Obviously my idea to use the host name directly as a src/dest address 
> rather than convert it to an integer is not a small, incremental 
> change. It's more in the realm of a speculative proposal.

Speculative is orthogonal to small or incremental; they are different
measurement axes.

This is also true of the difference between addresses and names.  Addresses
are an engineering artifact; names are a business/administrative artifact.

*The entire point* of DNS vs IP is to uncouple those; necessary changes in
the engineering artifact *MUST not* cause changes in the business artifact.

> But I'm not sure that arguing that our string of bits (e.g., ipv6) is 
> inherently superior to your proposed string of bits (a host name) is 
> an immediately compelling objection.

And, unsurprisingly, no one made an argument that trivial.  To the extent
you think we did, I think we were merely giving you the benefit of the doubt
of already understanding this dichotomy, which is pretty much Networking
201, and taken as read on NANOG.

Extraordinary changes require extraordinary justification.

> The objection which puzzles me the most is the implication that a 
> numeric address locates a host or network directly or geographically 
> rather than, as I understood it, by the tuple (address,route).

I didn't see anyone make that implication.  Could you quote?

> "First they ignore you, then they ridicule you, then they fight you, 
> then you win" -- Mahatma Gandhi

Yeah; that approach didn't work out well for Jim Fleming.  :-)

Seriously, Barry; my appraisal of this after three decades is that this is
first year stuff, and you are not a first year guy, by any stretch.

So, is this just the epic troll of the year?  Or is there something we're
missing?

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink
j...@baylink.com
Designer The Things I Think   RFC
2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover
DII
St Petersburg FL USA   #natog  +1 727 647
1274

Re: IPv4 address length technical design

[Barry Shein]

Well, George, you can take a new idea and run with it a bit, or just
resist it right from the start.

We can map from host names to ip addresses to routing actions, right?

So clearly they're not unrelated or independent variables. There's a
smooth function from hostname->ipaddr->routing.

Take an extreme but extremely common case, the home or small office
end user.

Those packets only have exactly one place to go, right? One default
route.

So why do they need to turn a host name into an IP address at all to
ship a packet? The first-hop route is always exactly the same for
every single packet.

Is this a good use of DNS computrons? Answering DNS inquiries for
every new connection for every single-routed host on the internet?

Van Jacobson had a similar observation vis a vis TCP and PPP header
compression, why keep sending the same bits back and forth over a PPP
link for example? Why not just an encapsulation which says "same as
previous"?

Now, how can that be generalized?

   -b

On October 6, 2012 at 11:06 george.herb...@gmail.com (George Herbert) wrote:
 > As I said earlier, names' structure does not map to network or physical 
 > location structure.
 > 
 > DNS is who; IP is where.  Both are reasonably efficient now as separate 
 > entities.  Combining them will wreck one.  You're choosing to wreck routing 
 > (where), which to backbone people sounds frankly stark raving mad.
 > 
 > If you aren't willing to consider where / routing as a problem of equal 
 > importance ( not as end-user visible perhaps, but ultimately as important ), 
 > then you're just pissing around and not being serious about exploring future 
 > options.
 > 
 > 
 > 
 > George William Herbert
 > Sent from my iPhone
 > 
 > On Oct 6, 2012, at 10:47 AM, Barry Shein  wrote:
 > 
 > > 
 > > It's occured to you that FQDNs contain some structured information,
 > > no?
 > > 
 > >   -b
 > > 
 > > On October 5, 2012 at 21:47 b...@herrin.us (William Herrin) wrote:
 > >> On Fri, Oct 5, 2012 at 8:25 PM, Barry Shein  wrote:
 > >>> 5. Bits is bits.
 > >>> I don't know how to say that more clearly.
 > >> 
 > >> Hi Barry,
 > >> 
 > >> Bits is bits and atoms is atoms so lets swap all the iron for helium
 > >> and see how that works out for us.
 > >> 
 > >> You can say "bits as bits" as clearly as you like but however you say
 > >> it you'll be wrong. Bits are defined by the semantics of their use.
 > >> Any equality or inequality between one bit and another, and in fact
 > >> whether they can be meaningfully compared at all, is found in those
 > >> semantics.
 > >> 
 > >> Bits ain't just bits. Bits are information *in context.* Change the
 > >> context, change the bits.
 > >> 
 > >> Regards,
 > >> Bill Herrin
 > >> 
 > >> 
 > >> -- 
 > >> William D. Herrin  her...@dirtside.com  b...@herrin.us
 > >> 3005 Crane Dr. .. Web: 
 > >> Falls Church, VA 22042-3004
 > > 

-- 
-Barry Shein

The World  | b...@theworld.com   | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada
Software Tool & Die| Public Access Internet | SINCE 1989 *oo*

Re: IPv4 address length technical design

[George Herbert]

As I said earlier, names' structure does not map to network or physical 
location structure.

DNS is who; IP is where.  Both are reasonably efficient now as separate 
entities.  Combining them will wreck one.  You're choosing to wreck routing 
(where), which to backbone people sounds frankly stark raving mad.

If you aren't willing to consider where / routing as a problem of equal 
importance ( not as end-user visible perhaps, but ultimately as important ), 
then you're just pissing around and not being serious about exploring future 
options.



George William Herbert
Sent from my iPhone

On Oct 6, 2012, at 10:47 AM, Barry Shein  wrote:

> 
> It's occured to you that FQDNs contain some structured information,
> no?
> 
>   -b
> 
> On October 5, 2012 at 21:47 b...@herrin.us (William Herrin) wrote:
>> On Fri, Oct 5, 2012 at 8:25 PM, Barry Shein  wrote:
>>> 5. Bits is bits.
>>> I don't know how to say that more clearly.
>> 
>> Hi Barry,
>> 
>> Bits is bits and atoms is atoms so lets swap all the iron for helium
>> and see how that works out for us.
>> 
>> You can say "bits as bits" as clearly as you like but however you say
>> it you'll be wrong. Bits are defined by the semantics of their use.
>> Any equality or inequality between one bit and another, and in fact
>> whether they can be meaningfully compared at all, is found in those
>> semantics.
>> 
>> Bits ain't just bits. Bits are information *in context.* Change the
>> context, change the bits.
>> 
>> Regards,
>> Bill Herrin
>> 
>> 
>> -- 
>> William D. Herrin  her...@dirtside.com  b...@herrin.us
>> 3005 Crane Dr. .. Web: 
>> Falls Church, VA 22042-3004
> 

Re: IPv4 address length technical design

[Barry Shein]

It's occured to you that FQDNs contain some structured information,
no?

   -b

On October 5, 2012 at 21:47 b...@herrin.us (William Herrin) wrote:
 > On Fri, Oct 5, 2012 at 8:25 PM, Barry Shein  wrote:
 > > 5. Bits is bits.
 > > I don't know how to say that more clearly.
 > 
 > Hi Barry,
 > 
 > Bits is bits and atoms is atoms so lets swap all the iron for helium
 > and see how that works out for us.
 > 
 > You can say "bits as bits" as clearly as you like but however you say
 > it you'll be wrong. Bits are defined by the semantics of their use.
 > Any equality or inequality between one bit and another, and in fact
 > whether they can be meaningfully compared at all, is found in those
 > semantics.
 > 
 > Bits ain't just bits. Bits are information *in context.* Change the
 > context, change the bits.
 > 
 > Regards,
 > Bill Herrin
 > 
 > 
 > -- 
 > William D. Herrin  her...@dirtside.com  b...@herrin.us
 > 3005 Crane Dr. .. Web: 
 > Falls Church, VA 22042-3004

Re: news.google.com (and others)?

[Christopher Morrow]

On Sat, Oct 6, 2012 at 12:25 PM, Barry Shein  wrote:
>
> This has been going on for days.
>
> We couldn't get thru to news.google.com but most everything else
> works. Once in a while it works.
>
> Connection is through towerstream.com. Traceroute usually seems to go
> through, sometimes dies somewhere out there past their network
> (72.14...? maybe abovenet?), no consistent result.

72.14.? some of that is google network space:
NET-72-14-192-0-1 - for instance

> Tried downforeveryoneorjustme.com, it says it's up.

;; ANSWER SECTION:
www.downforeveryoneorjustme.com. 1568 IN CNAME  ghs.google.com.
ghs.google.com. 43199   IN  CNAME   ghs.l.google.com.
ghs.l.google.com.   299 IN  A   173.194.74.121

really: "Down for google or just me" would be a better name :(

>
> Called towerstream support, they couldn't get thru either.
>
> WAIT!
>
> The support guy had a tablet on Verizon 4G, he couldn't get thru to
> news.google.com using that either.
>
> He also said he couldn't get thru to google street maps, but google
> mail was ok (I can reload gplus.google.com no problem.)
>
> My iphone via AT&T has no problem, loads news.google.com immediately.
>
> Anyone else seeing this?
>

what sort of source address are you using?
perhaps also ipv4 vs ipv6? (the lte devices will default, I believe, to v6)

> I'm in Boston, Towerstream support is in Providence, RI.
>
> I'm thinking some sort of localized problem but trouble thru
> towerstream and verizon?
>
> It was passed to the engineer on duty at towerstream who will look
> into it and speak to google if necessary, not clear it's their problem
> though, not if Verizon is actually also having the same problem.

Connecting to news.google.com|2607:f8b0:4003:c02::8b|:80... connected.
HTTP request sent, awaiting response... 200 OK

from some network in the interwebs... so v6 to this works (v4 works as
well, based on telnet responses)

-chris

>
> --
> -Barry Shein
>
> The World  | b...@theworld.com   | http://www.TheWorld.com
> Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada
> Software Tool & Die| Public Access Internet | SINCE 1989 *oo*
>

news.google.com (and others)?

[Barry Shein]

This has been going on for days.

We couldn't get thru to news.google.com but most everything else
works. Once in a while it works.

Connection is through towerstream.com. Traceroute usually seems to go
through, sometimes dies somewhere out there past their network
(72.14...? maybe abovenet?), no consistent result.

Tried downforeveryoneorjustme.com, it says it's up.

Called towerstream support, they couldn't get thru either.

WAIT!

The support guy had a tablet on Verizon 4G, he couldn't get thru to
news.google.com using that either.

He also said he couldn't get thru to google street maps, but google
mail was ok (I can reload gplus.google.com no problem.)

My iphone via AT&T has no problem, loads news.google.com immediately.

Anyone else seeing this?

I'm in Boston, Towerstream support is in Providence, RI.

I'm thinking some sort of localized problem but trouble thru
towerstream and verizon?

It was passed to the engineer on duty at towerstream who will look
into it and speak to google if necessary, not clear it's their problem
though, not if Verizon is actually also having the same problem.


-- 
-Barry Shein

The World  | b...@theworld.com   | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada
Software Tool & Die| Public Access Internet | SINCE 1989 *oo*

Re: ESR muses on, among other things, the early IETF

[bmanning]

On Sat, Oct 06, 2012 at 10:14:41AM +0100, Nick Hilliard wrote:
> On 06/10/2012 03:20, Jay Ashworth wrote:
> > Those who know Fred and knew Jon personally might want to throw an oar in 
> > the
> > water on this blog posting from last month...
> > 
> >   http://esr.ibiblio.org/?p=4591
> 
> not sure if it's appropriate to associate some of the prime movers of the
> Internet with a cringingly self-aggrandising blog posting like that.
> 
> Nick

I -think- Jon and Fred were not contemporaries.  Fred is
closer to my age than Jon.

/bill

Re: ESR muses on, among other things, the early IETF

[Nick Hilliard]

On 06/10/2012 03:20, Jay Ashworth wrote:
> Those who know Fred and knew Jon personally might want to throw an oar in the
> water on this blog posting from last month...
> 
>   http://esr.ibiblio.org/?p=4591

not sure if it's appropriate to associate some of the prime movers of the
Internet with a cringingly self-aggrandising blog posting like that.

Nick