Re: trout views

[John Kemp]

That's the normal Monday morning maint window
for UO, when they all too frequently make us
disappear... :(

/jgk


On 4/25/16 5:03 AM, Randy Bush wrote:
> nfs0.dfw.rg.net:/root# ping 128.223.51.20
> PING 128.223.51.20 (128.223.51.20) 56(84) bytes of data.
> From 4.69.145.11 icmp_seq=1 Time to live exceeded
> From 4.69.145.11 icmp_seq=2 Time to live exceeded
> ^C
> --- 128.223.51.20 ping statistics ---
> 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1001ms
>
> nfs0.dfw.rg.net:/root# traceroute 128.223.51.20
> traceroute to 128.223.51.20 (128.223.51.20), 30 hops max, 60 byte packets
>  1  r0.dfw.rg.net (198.180.152.3)  1.571 ms  1.559 ms  1.597 ms
>  2  r1.dfw.rg.net (198.180.152.2)  0.558 ms  0.551 ms  0.640 ms
>  3  ge-102-0-0-29-53.r08.dllstx09.us.bb.gin.ntt.net (157.238.224.205)  1.562 
> ms  1.598 ms  1.716 ms
>  4  ae-12.r07.dllstx09.us.bb.gin.ntt.net (129.250.3.107)  0.488 ms  0.538 ms  
> 0.582 ms
>  5  * * *
>  6  * * *
>  7  ae-65-65.csw1.Dallas1.Level3.net (4.69.206.133)  0.514 ms  0.555 ms 
> ae-95-95.csw4.Dallas1.Level3.net (4.69.206.145)  0.525 ms
>  8  ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139)  0.627 ms  0.769 ms 
> ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11)  0.633 ms
>  9  vlan90.csw4.Dallas1.Level3.net (4.69.145.254)  0.517 ms 
> vlan80.csw3.Dallas1.Level3.net (4.69.145.190)  0.589 ms  0.676 ms
> 10  ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11)  0.519 ms 
> ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139)  0.632 ms 
> ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203)  13.412 ms
> 11  vlan60.csw1.Dallas1.Level3.net (4.69.145.62)  13.264 ms  0.604 ms 
> vlan80.csw3.Dallas1.Level3.net (4.69.145.190)  0.530 ms
> 12  ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11)  0.633 ms  0.519 ms  0.513 
> ms
> 13  vlan80.csw3.Dallas1.Level3.net (4.69.145.190)  0.540 ms 
> vlan60.csw1.Dallas1.Level3.net (4.69.145.62)  13.318 ms 
> vlan90.csw4.Dallas1.Level3.net (4.69.145.254)  0.554 ms
> 14  ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139)  0.723 ms 
> ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203)  12.793 ms 
> ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11)  0.494 ms
> 15  vlan80.csw3.Dallas1.Level3.net (4.69.145.190)  0.554 ms 
> vlan90.csw4.Dallas1.Level3.net (4.69.145.254)  0.541 ms 
> vlan80.csw3.Dallas1.Level3.net (4.69.145.190)  2.040 ms
> 16  ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203)  12.294 ms 
> ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139)  0.896 ms  0.790 ms
> 17  vlan80.csw3.Dallas1.Level3.net (4.69.145.190)  0.590 ms 
> vlan60.csw1.Dallas1.Level3.net (4.69.145.62)  0.610 ms 
> vlan80.csw3.Dallas1.Level3.net (4.69.145.190)  0.932 ms
> 18  ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11)  0.522 ms 
> ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203)  11.423 ms 
> ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139)  0.747 ms
> 19  vlan90.csw4.Dallas1.Level3.net (4.69.145.254)  0.673 ms 
> vlan80.csw3.Dallas1.Level3.net (4.69.145.190)  0.803 ms 
> vlan60.csw1.Dallas1.Level3.net (4.69.145.62)  0.638 ms
> 20  ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11)  0.525 ms 
> ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139)  0.826 ms  0.876 ms
> 21  vlan60.csw1.Dallas1.Level3.net (4.69.145.62)  0.635 ms  9.840 ms  9.404 ms
> 22  ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11)  0.622 ms  0.604 ms 
> ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203)  8.751 ms
> 23  vlan80.csw3.Dallas1.Level3.net (4.69.145.190)  0.671 ms  0.817 ms  0.687 
> ms
> 24  ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139)  0.785 ms  0.754 ms 
> ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203)  4.774 ms
> 25  vlan90.csw4.Dallas1.Level3.net (4.69.145.254)  0.633 ms  0.683 ms  0.795 
> ms
> 26  ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11)  0.659 ms 
> ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139)  0.758 ms  0.907 ms
> 27  vlan60.csw1.Dallas1.Level3.net (4.69.145.62)  0.776 ms 
> vlan90.csw4.Dallas1.Level3.net (4.69.145.254)  0.721 ms 
> vlan60.csw1.Dallas1.Level3.net (4.69.145.62)  0.705 ms
> 28  ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203)  15.057 ms  14.660 ms 
> ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139)  0.871 ms
> 29  vlan80.csw3.Dallas1.Level3.net (4.69.145.190)  0.864 ms 
> vlan60.csw1.Dallas1.Level3.net (4.69.145.62)  0.752 ms  0.747 ms
> 30  ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139)  0.877 ms 
> ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11)  0.721 ms 
> ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203)  14.302 ms
>
> and, of course, email does not work

Re: phone fun, was GeoIP database issues and the real world consequences

[Blair Trosper]

I would imagine for VOIP that's because all three are country code 1 :)

On Tue, Apr 26, 2016 at 7:50 PM, Ray Orsini  wrote:

> On our VOIP service we include US, Canada and Puerto Rico as "local"
> calling.
>
> Regards,
>
> Ray Orsini – CEO
> Orsini IT, LLC – Technology Consultants
> VOICE DATA  BANDWIDTH  SECURITY  SUPPORT
> P: 305.967.6756 x1009   E: r...@orsiniit.com   TF: 844.OIT.VOIP
> 7900 NW 155th Street, Suite 103, Miami Lakes, FL 33016
> http://www.orsiniit.com | View My Calendar | View/Pay Your Invoices | View
> Your Tickets
>
>
>
> -Original Message-
> From: NANOG [mailto:nanog-bounces+ray=orsiniit@nanog.org] On Behalf Of
> Larry Sheldon
> Sent: Tuesday, April 26, 2016 3:11 PM
> To: nanog@nanog.org
> Subject: Re: phone fun, was GeoIP database issues and the real world
> consequences
>
>
>
> On 4/20/2016 10:15, Owen DeLong wrote:
> >
> >> On Apr 20, 2016, at 7:59 AM, Jean-Francois Mezei
> >>  wrote:
> >>
> >> On 2016-04-20 10:52, Owen DeLong wrote:
> >>
> >>> For the most part, “long distance” calls within the US are a thing
> >>> of the past and at least one mobile carrier now treats US/CA/MX as a
> >>> single local calling area
> >>
> >>
> >> Is this a case of telcos having switched to IP trunks and can reach
> >> other carriers for "free"
> >>
> >> Or are wholesale long distance still billed between carriers but at
> >> prices so low that they can afford to offer "free" long distance at
> >> retail level ?
> >
> > I think it boiled down to a recognition that the costs of billing were
> > beginning to account for something like $0.99 of every $1 billed.
>
> I wonder if the costs of avoiding-preventing-investigating toll fraud final
> grow to consume the profit in the product.
>
> I know that long ago there were things that I thought were insanely silly.
> A few examples:
>
> As an ordinary citizen I was amused and annoyed, in the case where a toll
> charge had been contested (and perforce refunded) there would often be
> several non-revenue calls to the protesting number asking whoever answered
> if they knew anybody in the called city, or if they knew who
> the called number belonged to.   (Proper answer in any case:  Who or
> what I know is none of your business.)  Often there would calls to the
> called number (super irritating because the error was in the
> recording--later learned to be poor handwriting) asking the reciprocal
> questions except that often they had no idea that a call had been made.
>
> I  was a Toll Transmissionman for a number or years back in the last iceage
> and one of the onerous tasks the supervisor had was "verifying the phone
> bill" which might be a stack as much as six inches tall.  The evening shift
> supervisor (or one of them in a large office, like Los Angeles 1 Telegraph,
> where I worked for a while) would go through the bill, line by line, page
> by
> page, looking at the called number an d if he recognized it and placing a
> check mark next to it,  If he did not recognize it, he would search the
> many
> lists in the office to see it was shown, and adding a check mark if a list
> showed it for a likely sounding legal call.  If that didn't work he would
> probably have to call the number to see who answered (adding a wasted
> revenue-call path to the wreckage).  Most often it would turn out to be the
> home telephone number of a repair supervisor in West Sweatsock, Montana,
> who
> had been called because a somebody who protested the policy that the
> repairman going fishing meant some problem would not be addressed for
> several days.  So he put a check mark next to the number and moved on.
>
> Which meant the number would show up on the next month's bill.  And it
> would
> again not be recognized from memory.  And so forth and so on.
> Until eventually, after several months, the number would be recognized,
> check-marked without drama, and disappear forever from the bill.
>
> Lastly, in later years I was assigned to the the Revenue Accounting
> organization (to write programs for printing telephone books) and came to
> realize that there were a LOT of people in RA working with a LOT of people
> in the Chief Special Agents organization using a LOT of computer time to
> analyze Toll records for fraud patterns.
>
> Oops, not quite lastly  Looking back at my Toll Plant days in the
> heyday
> of Captain Crunch--there were a lot engineering hours redesigning Toll
> equipment, and plant hours modifying or replacing equipment do defeat the
> engineering efforts of the Blue Box Boys.
>
> --
> "Everybody is a genius.  But if you judge a fish by its ability to climb a
> tree, it will live its whole life believing that it is stupid."
>
> --Albert Einstein
>

RE: phone fun, was GeoIP database issues and the real world consequences

[Ray Orsini]

On our VOIP service we include US, Canada and Puerto Rico as "local"
calling.

Regards,

Ray Orsini – CEO
Orsini IT, LLC – Technology Consultants
VOICE DATA  BANDWIDTH  SECURITY  SUPPORT
P: 305.967.6756 x1009   E: r...@orsiniit.com   TF: 844.OIT.VOIP
7900 NW 155th Street, Suite 103, Miami Lakes, FL 33016
http://www.orsiniit.com | View My Calendar | View/Pay Your Invoices | View
Your Tickets



-Original Message-
From: NANOG [mailto:nanog-bounces+ray=orsiniit@nanog.org] On Behalf Of
Larry Sheldon
Sent: Tuesday, April 26, 2016 3:11 PM
To: nanog@nanog.org
Subject: Re: phone fun, was GeoIP database issues and the real world
consequences



On 4/20/2016 10:15, Owen DeLong wrote:
>
>> On Apr 20, 2016, at 7:59 AM, Jean-Francois Mezei
>>  wrote:
>>
>> On 2016-04-20 10:52, Owen DeLong wrote:
>>
>>> For the most part, “long distance” calls within the US are a thing
>>> of the past and at least one mobile carrier now treats US/CA/MX as a
>>> single local calling area
>>
>>
>> Is this a case of telcos having switched to IP trunks and can reach
>> other carriers for "free"
>>
>> Or are wholesale long distance still billed between carriers but at
>> prices so low that they can afford to offer "free" long distance at
>> retail level ?
>
> I think it boiled down to a recognition that the costs of billing were
> beginning to account for something like $0.99 of every $1 billed.

I wonder if the costs of avoiding-preventing-investigating toll fraud final
grow to consume the profit in the product.

I know that long ago there were things that I thought were insanely silly.
A few examples:

As an ordinary citizen I was amused and annoyed, in the case where a toll
charge had been contested (and perforce refunded) there would often be
several non-revenue calls to the protesting number asking whoever answered
if they knew anybody in the called city, or if they knew who
the called number belonged to.   (Proper answer in any case:  Who or
what I know is none of your business.)  Often there would calls to the
called number (super irritating because the error was in the
recording--later learned to be poor handwriting) asking the reciprocal
questions except that often they had no idea that a call had been made.

I  was a Toll Transmissionman for a number or years back in the last iceage
and one of the onerous tasks the supervisor had was "verifying the phone
bill" which might be a stack as much as six inches tall.  The evening shift
supervisor (or one of them in a large office, like Los Angeles 1 Telegraph,
where I worked for a while) would go through the bill, line by line, page by
page, looking at the called number an d if he recognized it and placing a
check mark next to it,  If he did not recognize it, he would search the many
lists in the office to see it was shown, and adding a check mark if a list
showed it for a likely sounding legal call.  If that didn't work he would
probably have to call the number to see who answered (adding a wasted
revenue-call path to the wreckage).  Most often it would turn out to be the
home telephone number of a repair supervisor in West Sweatsock, Montana, who
had been called because a somebody who protested the policy that the
repairman going fishing meant some problem would not be addressed for
several days.  So he put a check mark next to the number and moved on.

Which meant the number would show up on the next month's bill.  And it would
again not be recognized from memory.  And so forth and so on.
Until eventually, after several months, the number would be recognized,
check-marked without drama, and disappear forever from the bill.

Lastly, in later years I was assigned to the the Revenue Accounting
organization (to write programs for printing telephone books) and came to
realize that there were a LOT of people in RA working with a LOT of people
in the Chief Special Agents organization using a LOT of computer time to
analyze Toll records for fraud patterns.

Oops, not quite lastly  Looking back at my Toll Plant days in the heyday
of Captain Crunch--there were a lot engineering hours redesigning Toll
equipment, and plant hours modifying or replacing equipment do defeat the
engineering efforts of the Blue Box Boys.

--
"Everybody is a genius.  But if you judge a fish by its ability to climb a
tree, it will live its whole life believing that it is stupid."

--Albert Einstein

Re: NCS5K?

[Tom Hill]

On 26/04/16 14:27, Chris Welti wrote:
> Judging from the NCS 5001 configuration guides they (NCS5K) don't support
> any VPLS, is that correct? Just EoMPLS?

It's not targeted as a full-feature box AFAIK. You've got the ASR9k and
ASR9xx series for this sort of thing.

I do recall some mention of NCS5k supporting Segment Routing though -
that seemed quite handy for future MPLS P requirements.

>> Some might be thinking "9001 upgrade!" but it's more likely direct
>> competition to Arista's recent moves. That and I still hope there will
>> be a MOD200-ish 9001 replacement to come at some point.
> 
> I had hoped for MOD400-ish 9001 replacement for a while,
> however, I was told an ASR9001 successor is highly unlikely
> in the next few years unless a very large customer asks for it.

I've heard some rumours to the contrary - presumably it could still be
canned. Tomahawk is still quite new, and the 9001 still sells well, so
perhaps the market just isn't ready yet. I guarantee Cisco's sales of
any given product proceed along these lines:

 1. Product sales for flagship $model are good
 2. Announce flagship $model+1 to public
 3. Product sales for $model plummet, whilst everyone waits for $model+1

Sometimes that's good, sometimes that's really bad. :)

>> Oh - and it's NCS 55k, not NCS 5k. The NCS 5508 is already a product,
>> noted for its better buffers than the NCS 5001 & 5002 (which also
>> already exist).
>  
> Does the NCS 5508 support VPLS?

I don't recall looking closely, but I very much doubt it due to the
reasons mentioned above.

-- 
Tom

Re: NCS5K?

[Tom Hill]

On 26/04/16 15:02, Colton Conor wrote:
> Do you actually think that Cisco would sell at NCS 5501 at the price
> point that Arista is going to sell a 7280R for? Spec wise they are very
> similar (except Arista has 8 more SFP+ ports and two more 100G ports).
> Arista is pricing the 7280R inline with Ciscos ASR9001. I doubt Cisco
> will offer a NCS 5501 for the same price as an ASR9001. 

In addition to Saku's comments - I've only really been hypothesising by
looking at the features available on the platforms, and comparing it to
the current list prices that we already have. I've no other insider
knowledge.

Take the line cards in ASR 9000 chassis, vs. NCS 5500 chassis:

 A9K-8X100GE-TR,  8x100G   = $ 1,000,000
 A9K-36X10GE-TR,  36x10G   = $   375,000
 NC55-36X100G-BA, 36x100G  = $   360,000

The list price for a 36x10G line card for the ASR 9000 is *cheaper than*
the 36x100G card for the NCS 5500. There are massive gains in Gbits/$ by
having fewer features in your device. (And the SE scale A9k cards are
priced even higher than these TR models...)

More to the second half of your question though, and probably the most
pertinent; the NCS 5001 & 5002 pricing is already out, and they are
smack-back either side of the ASR 9001:

 NCS-5001, 40x10G + 4x100G  = $ 40,000
 ASR-9001, 4x10G + nothing  = $ 53,600
 NCS-5002, 80x10G + 4x100G  = $ 60,000

So, personally, I'm not ruling out the NCS 5501 landing on or around the
9001's price point - particularly if that's Arista's game.

The NCS 55k is obviously being targeted at dense MPLS P roles, and/or
simple BGP edge routers, which may be of enough use to you, in your
environment - it may not.

-- 
Tom

Re: phone fun, was GeoIP database issues and the real world consequences

[Owen DeLong]

> On Apr 26, 2016, at 12:10 , Larry Sheldon  wrote:
> 
> 
> 
> On 4/20/2016 10:15, Owen DeLong wrote:
>> 
>>> On Apr 20, 2016, at 7:59 AM, Jean-Francois Mezei 
>>>  wrote:
>>> 
>>> On 2016-04-20 10:52, Owen DeLong wrote:
>>> 
 For the most part, “long distance” calls within the US are a thing of the
 past and at least one mobile carrier now treats US/CA/MX as a single
 local calling area
>>> 
>>> 
>>> Is this a case of telcos having switched to IP trunks and can reach
>>> other carriers for "free"
>>> 
>>> Or are wholesale long distance still billed between carriers but at
>>> prices so low that they can afford to offer "free" long distance at
>>> retail level ?
>> 
>> I think it boiled down to a recognition that the costs of billing were 
>> beginning to account for something like $0.99 of every $1 billed.
> 
> I wonder if the costs of avoiding-preventing-investigating toll fraud final 
> grow to consume the profit in the product.

IIRC, mostly it boiled down to the maintenance of the antiquated SMDR equipment 
and its interface to the even more antiquated billing systems was getting 
expensive to keep running and that there was no perceived potential whatsoever 
for ROI on building a new billing system or new SMDR capabilities.

> I know that long ago there were things that I thought were insanely silly.  A 
> few examples:
> 
> As an ordinary citizen I was amused and annoyed, in the case where a toll 
> charge had been contested (and perforce refunded) there would often be 
> several non-revenue calls to the protesting number asking whoever answered if 
> they knew anybody in the called city, or if they knew who the called number 
> belonged to.   (Proper answer in any case:  Who or what I know is none of 
> your business.)  Often there would calls to the called number (super 
> irritating because the error was in the recording--later learned to be poor 
> handwriting) asking the reciprocal questions except that often they had no 
> idea that a call had been made.

ROFLMAO… Yeah. Next time we’re in the same locale, ask me about my 2.5 year 
argument with Pacific Bell about direct dial calls to Vietnam and the 
Philippines from my apartment in Richmond. There should be alcohol involved.

> I  was a Toll Transmissionman for a number or years back in the last iceage 
> and one of the onerous tasks the supervisor had was "verifying the phone 
> bill" which might be a stack as much as six inches tall.  The evening shift 
> supervisor (or one of them in a large office, like Los Angeles 1 Telegraph, 
> where I worked for a while) would go through the bill, line by line, page by 
> page, looking at the called number an d if he recognized it and placing a 
> check mark next to it,  If he did not recognize it, he would search the many 
> lists in the office to see it was shown, and adding a check mark if a list 
> showed it for a likely sounding legal call.  If that didn't work he would 
> probably have to call the number to see who answered (adding a wasted 
> revenue-call path to the wreckage).  Most often it would turn out to be the 
> home telephone number of a repair supervisor in West Sweatsock, Montana, who 
> had been called because a somebody who protested the policy that the 
> repairman going fishing meant some problem would not be addressed for several 
> days.  So he put a check mark next to the number and moved on.
> 
> Which meant the number would show up on the next month's bill.  And it would 
> again not be recognized from memory.  And so forth and so on. Until 
> eventually, after several months, the number would be recognized, 
> check-marked without drama, and disappear forever from the bill.
> 
> Lastly, in later years I was assigned to the the Revenue Accounting 
> organization (to write programs for printing telephone books) and came to 
> realize that there were a LOT of people in RA working with a LOT of people in 
> the Chief Special Agents organization using a LOT of computer time to analyze 
> Toll records for fraud patterns.
> 
> Oops, not quite lastly  Looking back at my Toll Plant days in the heyday 
> of Captain Crunch--there were a lot engineering hours redesigning Toll 
> equipment, and plant hours modifying or replacing equipment do defeat the 
> engineering efforts of the Blue Box Boys.

I really liked it while my Blue Box still worked. lol

For a while, SS7 was the bane of my existence.

Fun times!!

When a minute of long distance from California to New York was $0.35+, there 
was enough money in the billing process to cover the costs of tracking the 
minute. Once it got down to $0.03 and then $0.01, that really took a lot of the 
margin away.

One thing I always found particularly amusing was that it used to be a toll 
call to call from San Jose East (408238) to Sunnyvale (I forget the NPA/NXX), 
but that there were several prefixes in San Jose West (e.g. 408360 IIRC) where 
it was free to call from San 

Re: phone fun, was GeoIP database issues and the real world consequences

[Larry Sheldon]

On 4/20/2016 10:15, Owen DeLong wrote:



On Apr 20, 2016, at 7:59 AM, Jean-Francois Mezei  
wrote:

On 2016-04-20 10:52, Owen DeLong wrote:


For the most part, “long distance” calls within the US are a thing of the
past and at least one mobile carrier now treats US/CA/MX as a single
local calling area



Is this a case of telcos having switched to IP trunks and can reach
other carriers for "free"

Or are wholesale long distance still billed between carriers but at
prices so low that they can afford to offer "free" long distance at
retail level ?


I think it boiled down to a recognition that the costs of billing were 
beginning to account for something like $0.99 of every $1 billed.


I wonder if the costs of avoiding-preventing-investigating toll fraud 
final grow to consume the profit in the product.


I know that long ago there were things that I thought were insanely 
silly.  A few examples:


As an ordinary citizen I was amused and annoyed, in the case where a 
toll charge had been contested (and perforce refunded) there would often 
be several non-revenue calls to the protesting number asking whoever 
answered if they knew anybody in the called city, or if they knew who 
the called number belonged to.   (Proper answer in any case:  Who or 
what I know is none of your business.)  Often there would calls to the 
called number (super irritating because the error was in the 
recording--later learned to be poor handwriting) asking the reciprocal 
questions except that often they had no idea that a call had been made.


I  was a Toll Transmissionman for a number or years back in the last 
iceage and one of the onerous tasks the supervisor had was "verifying 
the phone bill" which might be a stack as much as six inches tall.  The 
evening shift supervisor (or one of them in a large office, like Los 
Angeles 1 Telegraph, where I worked for a while) would go through the 
bill, line by line, page by page, looking at the called number an d if 
he recognized it and placing a check mark next to it,  If he did not 
recognize it, he would search the many lists in the office to see it was 
shown, and adding a check mark if a list showed it for a likely sounding 
legal call.  If that didn't work he would probably have to call the 
number to see who answered (adding a wasted revenue-call path to the 
wreckage).  Most often it would turn out to be the home telephone number 
of a repair supervisor in West Sweatsock, Montana, who had been called 
because a somebody who protested the policy that the repairman going 
fishing meant some problem would not be addressed for several days.  So 
he put a check mark next to the number and moved on.


Which meant the number would show up on the next month's bill.  And it 
would again not be recognized from memory.  And so forth and so on. 
Until eventually, after several months, the number would be recognized, 
check-marked without drama, and disappear forever from the bill.


Lastly, in later years I was assigned to the the Revenue Accounting 
organization (to write programs for printing telephone books) and came 
to realize that there were a LOT of people in RA working with a LOT of 
people in the Chief Special Agents organization using a LOT of computer 
time to analyze Toll records for fraud patterns.


Oops, not quite lastly  Looking back at my Toll Plant days in the 
heyday of Captain Crunch--there were a lot engineering hours redesigning 
Toll equipment, and plant hours modifying or replacing equipment do 
defeat the engineering efforts of the Blue Box Boys.


--
"Everybody is a genius.  But if you judge a fish by
its ability to climb a tree, it will live its whole
life believing that it is stupid."

--Albert Einstein

Re: NCS5K?

[Saku Ytti]

On 26 April 2016 at 07:02, Colton Conor  wrote:
> Do you actually think that Cisco would sell at NCS 5501 at the price point
> that Arista is going to sell a 7280R for? Spec wise they are very similar
> (except Arista has 8 more SFP+ ports and two more 100G ports). Arista is
> pricing the 7280R inline with Ciscos ASR9001. I doubt Cisco will offer a
> NCS 5501 for the same price as an ASR9001.

This seems more question to economists than network engineers. But the
rudimentary understanding I have of free market it means that
competitors cannot sell products competing for same customers at
significantly different price point. On micro-level this may not be
true, we can find anecdotal examples of vastly differences prices for
similar products but on macro-level I'm sure Cisco, Arista, Alu,
Huawei, Juniper etc are all competitive, I base this solely on the
fact that they do exist (albeit Huawei may get unfair tax kick-backs
to enhance its competitiveness).

-- 
  ++ytti

Re: Arista Routing Solutions

[Paras Jha]

Just wanted to interject, the port density of the Arista switches is quite
impressive, especially considering the price point they're at.

On Tue, Apr 26, 2016 at 12:46 PM, Ryan Woolley 
wrote:

> While the QFX in general is similar to Jericho-based platforms, I think the
> QFX10002 is perhaps not an ideal comparison.  At 100G, there is a
> significant density penalty on that platform, as you can use all 36 ports
> at 40G, but only 12 ports at 100G.
>
> BGP convergence in the newer EOS releases is indeed very, very fast.
>
> On Sun, Apr 24, 2016 at 12:08 PM, Colton Conor 
> wrote:
>
> > Saku,
> >
> > I guess you are right the QFX10002-36Q is probably a better comparison.
> But
> > let's be honest, Juniper is not going to sell a QFX10002-36Q for less
> than
> > $20k like Arista will do for a semi- similar box. Even with a high
> discount
> > (like 90 percent off list), the Juniper QFX10002-36Q at $360k list price
> > comes nowhere close on the price point. Cisco, Juniper, ALU, etc are all
> > not going to see a low cost high density fixed switch because that would
> > cannibalize on their sales on the larger platforms. I really think Arista
> > is kind of unique here as they don't have another routing platform to
> > cannibalize, so they are competitively pricing their platform.
> >
> > So I guess the question becomes, what features are missing that Arista
> does
> > not currently have? They seems to be adding more and more features, and
> > taking more market share. Here is a list of features supported:
> >
> https://www.arista.com/en/support/product-documentation/supported-features
> > I have not personally used Arista myself, but I like what I am seeing as
> > far as price point, company culture, and repruatation in the market
> place.
> > I know their switching is solid, but I am not sure about their routing.
> >
> > Arista claims to have much, much faster BGP convergence time than all the
> > other vendors.
> >
> >
> >
> >
> >
> > On Sat, Apr 23, 2016 at 1:20 PM, Saku Ytti  wrote:
> >
> > > On 23 April 2016 at 10:52, Tom Hill  wrote:
> > > > In broad strokes: for your money you're either getting port density,
> or
> > > > more features per port. The only difference here is that there's
> > > > suddenly more TCAM on the device, and I still don't see the above
> > > > changing too drastically.
> > >
> > > Yeah OP is comparing high touch chip (MX104) to low touch chip
> > > (Jericho) that is not fair comparison. And cost is what customer is
> > > willing to pay, regardless of sticker on the box. No one will pay
> > > significant mark-up for another sticker, I've never seen in RFP
> > > significant differences in comparable products.
> > >
> > > Fairer comparison would be QFX10k, instead of MX104. QFX10k is AFAIK
> > > only product in this segment which is not using Jericho. If this is
> > > competitive advantage or risk, jury is still out, I lean towards
> > > competitive advantage, mainly due to its memory design.
> > >
> > > --
> > >   ++ytti
> > >
> >
>



-- 
Regards,
Paras

President
ProTraf Solutions, LLC
Enterprise DDoS Mitigation

Re: Arista Routing Solutions

[Ryan Woolley]

While the QFX in general is similar to Jericho-based platforms, I think the
QFX10002 is perhaps not an ideal comparison.  At 100G, there is a
significant density penalty on that platform, as you can use all 36 ports
at 40G, but only 12 ports at 100G.

BGP convergence in the newer EOS releases is indeed very, very fast.

On Sun, Apr 24, 2016 at 12:08 PM, Colton Conor 
wrote:

> Saku,
>
> I guess you are right the QFX10002-36Q is probably a better comparison. But
> let's be honest, Juniper is not going to sell a QFX10002-36Q for less than
> $20k like Arista will do for a semi- similar box. Even with a high discount
> (like 90 percent off list), the Juniper QFX10002-36Q at $360k list price
> comes nowhere close on the price point. Cisco, Juniper, ALU, etc are all
> not going to see a low cost high density fixed switch because that would
> cannibalize on their sales on the larger platforms. I really think Arista
> is kind of unique here as they don't have another routing platform to
> cannibalize, so they are competitively pricing their platform.
>
> So I guess the question becomes, what features are missing that Arista does
> not currently have? They seems to be adding more and more features, and
> taking more market share. Here is a list of features supported:
> https://www.arista.com/en/support/product-documentation/supported-features
> I have not personally used Arista myself, but I like what I am seeing as
> far as price point, company culture, and repruatation in the market place.
> I know their switching is solid, but I am not sure about their routing.
>
> Arista claims to have much, much faster BGP convergence time than all the
> other vendors.
>
>
>
>
>
> On Sat, Apr 23, 2016 at 1:20 PM, Saku Ytti  wrote:
>
> > On 23 April 2016 at 10:52, Tom Hill  wrote:
> > > In broad strokes: for your money you're either getting port density, or
> > > more features per port. The only difference here is that there's
> > > suddenly more TCAM on the device, and I still don't see the above
> > > changing too drastically.
> >
> > Yeah OP is comparing high touch chip (MX104) to low touch chip
> > (Jericho) that is not fair comparison. And cost is what customer is
> > willing to pay, regardless of sticker on the box. No one will pay
> > significant mark-up for another sticker, I've never seen in RFP
> > significant differences in comparable products.
> >
> > Fairer comparison would be QFX10k, instead of MX104. QFX10k is AFAIK
> > only product in this segment which is not using Jericho. If this is
> > competitive advantage or risk, jury is still out, I lean towards
> > competitive advantage, mainly due to its memory design.
> >
> > --
> >   ++ytti
> >
>

Re: Arista Routing Solutions

[Ryan Woolley]

IOS-XR on ASR 9k and Junos on MX.

For our use case, there's no longer anything limiting as compared to those
platforms.  BGP policy is perhaps not as rich as you might be used to if
your experience is with the sort of routers traditionally marketed to
service providers, but I'm sure that will get better, and it's probably
irrelevant if your policy is fairly static.

You are correct that we do collect a lot of flow data, both via sflow and
Netflow.  We've been able to do everything we need with Arista's sflow
implementation.

On Mon, Apr 25, 2016 at 6:41 PM, Colton Conor 
wrote:

> Ryan,
>
> What routing platform were you coming from before? What features does
> Arista not have that you find limiting that the old platform did have?
>
> How does Astira's Sflow only compare to having Cisco Netflow or Juniper
> JFlow for traffic monitoring which I assume Netflix does alot of?
>
> On Wed, Apr 20, 2016 at 3:48 PM, Ryan Woolley 
> wrote:
>
>> Colton Conor wrote:
>> > I know Arista is typically a switch manufacturer, but with their
>> recently
>> > announced Arista 7500R Series and soon to be announced but already
>> shipping
>> > 7280R Series Arista is officially getting into the routing game. The
>> fixed
>> > 1U 7280R Series looks quite impressive. The 7500R series is your
>> > traditional chassis and line card based solution.
>> >
>> > Both of these products have the ability to hold the full internet
>> routing
>> > table, and Arista is working on MPLS features. Both of these new
>> products
>> > use the latest Broadcom Jerico chipsets.
>>
>> We (Netflix) have been deploying the previous gen (7500E) as edge routers
>> for about two years in high traffic, low route count applications in our
>> CDN, and have been working with Arista for almost as long to improve route
>> scale so that we could turn off all our traditional routers.
>>
>> The features that enable full routes on Jericho are running in our
>> production network today and we also have the 7500R and 7280R working with
>> full tables.
>>
>> I can't speak to MPLS, but for our use case (all L3, very high-density
>> 10/40/100G, BGP, IS-IS and light QoS), it's working well.
>>
>> So, yes, I'd say those two products are quite viable and competitive
>> options in the edge router space.
>>
>
>

Re: NCS5K?

[Colton Conor]

Tom,

Do you actually think that Cisco would sell at NCS 5501 at the price point
that Arista is going to sell a 7280R for? Spec wise they are very similar
(except Arista has 8 more SFP+ ports and two more 100G ports). Arista is
pricing the 7280R inline with Ciscos ASR9001. I doubt Cisco will offer a
NCS 5501 for the same price as an ASR9001.

On Mon, Apr 25, 2016 at 7:03 PM, Tom Hill  wrote:

> On 19/04/16 14:46, Chris Welti wrote:
> > According to some slides from a russian cisco connect event, the
> > upcoming small-size NCS 5501 and NCS 5502 will support 1M+ FIB and
> > 50ms per port buffers. Seem to be killer boxes. 48x100GE in 2RU with
> > large FIB & buffers? Loving it already. I wonder what prices will
> > look like for those.
>
> I'd heard rumours... But those are interesting specifications. The
> NCS5501 isn't too far away from the Arista 7280R, and is probably
> Jericho underneath, too. But with a good MPLS stack, as is the case for
> the other NCS devices.
>
> Some might be thinking "9001 upgrade!" but it's more likely direct
> competition to Arista's recent moves. That and I still hope there will
> be a MOD200-ish 9001 replacement to come at some point.
>
> Oh - and it's NCS 55k, not NCS 5k. The NCS 5508 is already a product,
> noted for its better buffers than the NCS 5001 & 5002 (which also
> already exist).
>
> --
> Tom
>

Re: NCS5K?

[Chris Welti]

On 26/04/16 02:03, Tom Hill wrote:

On 19/04/16 14:46, Chris Welti wrote:

According to some slides from a russian cisco connect event, the
upcoming small-size NCS 5501 and NCS 5502 will support 1M+ FIB and
50ms per port buffers. Seem to be killer boxes. 48x100GE in 2RU with
large FIB & buffers? Loving it already. I wonder what prices will
look like for those.


I'd heard rumours... But those are interesting specifications. The
NCS5501 isn't too far away from the Arista 7280R, and is probably
Jericho underneath, too. But with a good MPLS stack, as is the case for
the other NCS devices.


Judging from the NCS 5001 configuration guides they (NCS5K) don't support
any VPLS, is that correct? Just EoMPLS?


Some might be thinking "9001 upgrade!" but it's more likely direct
competition to Arista's recent moves. That and I still hope there will
be a MOD200-ish 9001 replacement to come at some point.


I had hoped for MOD400-ish 9001 replacement for a while,
however, I was told an ASR9001 successor is highly unlikely
in the next few years unless a very large customer asks for it.
 

Oh - and it's NCS 55k, not NCS 5k. The NCS 5508 is already a product,
noted for its better buffers than the NCS 5001 & 5002 (which also
already exist).
 
Does the NCS 5508 support VPLS?


--
Chris