Re: Devil's Advocate - Segment Routing, Why?

[Dorian Kim]

> On Jun 19, 2020, at 11:34 AM, Randy Bush  wrote:
> 
> 
>> 
>> MPLS was since day one proposed as enabler for services originally
>> L3VPNs and RSVP-TE.
> 
> MPLS day one was mike o'dell wanting to move his city/city traffic
> matrix from ATM to tag switching and open cascade's hold on tags.

And IIRC, Tag switching day one was Cisco overreacting to Ipsilon.

-dorian 

Re: ROV Deployment (was LDPv6 Census Check)

[Dorian Kim]

> On Jun 16, 2020, at 7:53 AM, John Kristoff  wrote:
> when Google got people worried about dropping routes.
> 

That may have an impact down the road, but I doubt that really had that much 
impact on current deployments.

-dorian

Re: NTT/AS2914 enabled RPKI OV 'invalid = reject' EBGP policies

[Dorian Kim]

> On Mar 31, 2020, at 7:19 AM, Mark Tinka  wrote:
> 
> 
> 
>> On 26/Mar/20 02:50, Job Snijders wrote:
>> Dear group,
>> 
>> Exciting news! Today NTT's Global IP Network (AS 2914) enabled RPKI
>> based BGP Origin Validation on virtually all EBGP sessions, both
>> customer and peering edge. This change positively impacts the Internet
>> routing system.
> 
> Good man. The club is growing :-).
> 
> Quick one - do you have ROV on any IOS or IOS XE-based boxes? We've had
> to walk back the few we did in recent weeks; the thing is just totally
> broken there.

Mark,

Unfortunately we don’t have any testing done or experience with RPKI on XE or 
Classic boxes as we don’t have any deployed outside of OOB infrastructure.

-dorian

Re: NTT Charles

[Dorian Kim]

AS2914 has a tradition of bidding farewell to technical team members who
move on via router dns record . Charles was one of our NOC engineers.

IIRC, we stole this idea from the vBNS team back in the 90s.

-dorian


> On Feb 13, 2016, at 3:12 PM, Jared Geiger  wrote:
> 
> So who is this Charles fellow in the NTT reverse DNS?
> 
> ge-102-0-0-0.happy-trails-Charles.r05.asbnva02.us.bb.gin.ntt.net
> 
> ae-10.happy-trails-Charles.r22.asbnva02.us.bb.gin.ntt.net
> 
> ae-5.happy-trails-Charles.r25.nycmny01.us.bb.gin.ntt.net
> 
> ae-2.happy-trails-Charles.r08.nycmny01.us.bb.gin.ntt.net
> 
> ae-7.happy-trails-Charles.r00.lsanca07.us.bb.gin.ntt.net



smime.p7s
Description: S/MIME cryptographic signature

Re: eBay is looking for network heavies...

[Dorian Kim]

"Those who cannot remember the past are condemned to repeat it”


-Santayana

Quite relevant in our industry that seems be more hell bent on rehashing ideas
and plot lines than Hollywood.

-dorian


> On Jun 6, 2015, at 6:43 AM, shawn wilson  wrote:
> 
> My first thought on reading that was "who the hell cares if a person
> knows about internet culture". But than I had to reconsider - it's a
> very apt way of telling if someone read the right books :)
> 
> I would also add Ritchie, Thompson, and Diffie to that list (since you
> ask about Larry, it's only appropriate).
> 
> On Sat, Jun 6, 2015 at 6:32 AM, jim deleskie  wrote:
>> I remember you asking me who Jon was :)  I have since added to my list of
>> interview questions... sad but the number of people with clue is declining
>> not increasing.
>> 
>> 
>> On Sat, Jun 6, 2015 at 3:13 AM, Joe Hamelin  wrote:
>> 
>>> Back in 2000 at Amazon, HR somehow decided to have me do the phone
>>> interviews for neteng.  I'd go through questions on routing and what not,
>>> then at the end I would ask questions like, "Who was Jon Postel?  Who is
>>> Larry Wall?  Who is Paul Vixie? What are layers 8 & 9? Explain the RTFM
>>> protocol.  What is NANOG?"  Those answers (or long silences) told me more
>>> about the candidate than most of the technical questions.
>>> 
>>> --
>>> Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474
>>> 

Re: From Europe to Australia via right way

[Dorian Kim]

I don’t believe anyone has significant IP network capacity going EU -> 
Australia in that direction, esp. since once you get to Singapore, the options 
to get to Australia are limited.

Even for networks that do have EU to Asia connectivity via Indian Ocean or land 
route to north Asia, the preferred path would be via US and transpac.

-dorian


> On Apr 1, 2015, at 5:51 PM, joel jaeggli  wrote:
> 
> On 4/1/15 3:14 AM, Piotr wrote:
>> Hello,
>> 
>> There is some telecom, isp which have route from EU to AU via east or
>> south east (via Russia, Red sea or  other ways) ? Now i have path via US
>> and looking something in opposite direction.
> 
> telstra ntt reliance retn all have eastbound paths from europe.
> 
>> thanks for some info, contact.
>> Piotr
>> 
> 
> 

Re: Cogent admits to QoSing down streaming

[Dorian Kim]

Personally I hope that such an environment never happens. Fast/slow lanes are 
pretty meaningless. Such service differentiation only has meaning when there’s 
persistent congestion and I’d rather that networks work out ways to scale past 
demand rather than throttle them.

-dorian


> On Nov 6, 2014, at 1:12 PM, Blake Hudson  wrote:
> 
> If I were a Cogent customer I would like to have seen more transparency (an 
> announcement at least). However, I don't see anything wrong with their 
> practice of giving some customers "Silver" service and others "Bronze" 
> service while reserving "Gold" for themselves. Even if applications like VoIP 
> do not function well with a Bronze service level.
> 
> Now, a customer that was under the impression they were receiving equal 
> treatment with other customers may not be happy to know they were receiving a 
> lower class of service than expected. This is not a net neutrality matter, 
> it's a matter of expectations and possibly false or deceptive advertising.
> 
> I would much rather see an environment where the customer gets to choose 
> Gold, Silver, and Bronze levels of service for his or her traffic as opposed 
> to an environment where the provider chooses fast/slow lane applications at 
> their own discretion.
> 
> --Blake
> 
> Patrick W. Gilmore wrote on 11/6/2014 10:12 AM:
>> 
>> 
>> This is interesting. And it will be detrimental to network neutrality 
>> supporters. Cogent admits that while they were publicly complaining about 
>> other networks congesting links, they were using QoS to make the problem 
>> look worse.
>> 
>> One of the problems in "tech" is most people do not realize tone is 
>> important, not just substance. There was - still is! - congestion in many 
>> places where consumers have one or at most two choice of providers. Even in 
>> places where there are two providers, both are frequently congested. Instead 
>> of discussing the fact there is no functioning market, no choice for the 
>> average end user, and how to fix it, we will now spend a ton of time arguing 
>> whether anything is wrong at all because Cogent did this.
>> 
>> Wouldn't you rather be discussing whether 4 Mbps is really broadband? 
>> (Anyone else have flashbacks to "640K is enough for anyone!"?) Or how many 
>> people have more than one choice at 25 Mbps? Or whether a company with a 
>> terminating access monopoly can intentionally congest its edge to charge 
>> monopoly rents on the content providers their paying customers are trying to 
>> access? I know I would.
>> 
>> Instead, we'll be talking about how things are not really bad, Cogent just 
>> made it look bad on purpose. The subtlety of "it _IS_ bad, Cogent just 
>> shifted some of the burden from VoIP to streaming" is not something that 
>> plays well in a 30 second sound bite, or at congressional hearings.
>> 
>> It's enough to make one consider giving up the idea of having a functioning, 
>> useful Internet.
>> 

Re: Industry standard bandwidth guarantee?

[Dorian Kim]

> On Oct 30, 2014, at 8:23 AM, Jimmy Hess  wrote:
> 
> On Wed, Oct 29, 2014 at 7:04 PM, Ben Sjoberg  wrote:
> 
>> That 3Mb difference is probably just packet overhead + congestion
> 
> Yes...  however, that's actually an industry standard of implying
> higher performance than reality,  because end users don't care about
> the datagram overhead which their applications do not see they just
> want X  megabits of  real-world performance, and this industry would
> perhaps be better off if we called a link that can deliver at best 17
> Megabits of Goodput reliably a  "15 Megabit goodput +5 service"
> instead of calling it a "20 Megabit service"
> 
> Or at least appended a disclaimer   *"Real-world best case download
> performance: approximately  1.8 Megabytes per second"
> 
> 
> Subtracting overhead and quoting that instead of raw link speeds.
> But that's not the industry standard. I believe the industry standard
> is to provide the numerically highest performance number as is
> possible through best-case theoretical testing;   let the end user
> experience disappointment and explain the misunderstanding later.
> 
> End users also more concerned about their individual download rate on
> actual file transfers  and not  the total averaged aggregate
> throughput of the network of 10 users  or 10 streams downloading data
> simultaneously,or characteristics transport protocols are
> concerned about such as fairness.

Not it’s not. All the link speeds are products of standards, be it SDH/SONET,
PDH, or various flavors of ethernet. They are objective numbers. What you are
advocating, given that much of the overhead is per packet/frame overhead
and will vary based on the application and packet size distribution, will create
more confusion than what we have today.

-dorian

Re: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today

[Dorian Kim]

On Thu, Aug 14, 2014 at 01:47:20AM -0400, Dorian Kim wrote:
> On Thu, Aug 14, 2014 at 12:15:36AM -0400, Patrick W. Gilmore wrote:
> > Composed on a virtual keyboard, please forgive typos. 
> > 
> > > On Aug 13, 2014, at 22:59, Suresh Ramasubramanian  
> > > wrote:
> > > 
> > > Swisscom or some other European SP has / used to have a limit where they 
> > > would not accept more specific routes than say a /22 from provider x, so 
> > > if you wanted to take a /24 and announce it you were SOL sending packets 
> > > to them from that /24 over provider y.
> > > 
> > > Still, for elderly and capacity limited routers, that might work.
> > 
> > And Sprint used to filter on /19s outside swamp space. (See NANOG 1999 
> > archives for my [wrong then corrected] interpretation of ACL112.) Etc., 
> > etc. 
> > 
> > For stub networks, especially ones who are not as performance sensitive, 
> > this can help extend the life of their routers. But not everyone can make 
> > AGS+s work for years past their useful life or get "-doran" IOS builds. The 
> > 6500 was first sold in 1999. I'm impressed it has lasted this long, even 
> > with new sups. Time to start thinking about upgrading. 
> 
> Just as a historical note, Sprint didn't have AGS+ or such equipment that 
> were being propped up by the /19 filters (at least for the vast majority 
> of the filter's existence). Neither did Verio. Those filters were primarily 
> an attempt to enforce a certain behavior. 

It was kindly pointed out to me in private that my phrasing could be misleading 
here.

When ACL112 came into being, there were old equipment that were being protected 
by the /19 filters. However, the filters
were in place long after those equipment were replaced.


-dorian

Re: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today

[Dorian Kim]

On Thu, Aug 14, 2014 at 12:15:36AM -0400, Patrick W. Gilmore wrote:
> Composed on a virtual keyboard, please forgive typos. 
> 
> > On Aug 13, 2014, at 22:59, Suresh Ramasubramanian  
> > wrote:
> > 
> > Swisscom or some other European SP has / used to have a limit where they 
> > would not accept more specific routes than say a /22 from provider x, so if 
> > you wanted to take a /24 and announce it you were SOL sending packets to 
> > them from that /24 over provider y.
> > 
> > Still, for elderly and capacity limited routers, that might work.
> 
> And Sprint used to filter on /19s outside swamp space. (See NANOG 1999 
> archives for my [wrong then corrected] interpretation of ACL112.) Etc., etc. 
> 
> For stub networks, especially ones who are not as performance sensitive, this 
> can help extend the life of their routers. But not everyone can make AGS+s 
> work for years past their useful life or get "-doran" IOS builds. The 6500 
> was first sold in 1999. I'm impressed it has lasted this long, even with new 
> sups. Time to start thinking about upgrading. 

Just as a historical note, Sprint didn't have AGS+ or such equipment that were 
being propped up by the /19 filters (at least for the vast majority 
of the filter's existence). Neither did Verio. Those filters were primarily an 
attempt to enforce a certain behavior. 

Also, my recollection is that during that era "named" builds were typically 
named via receipient's well known email id, e.g."-smd" or first name 
"-sean" and I don't think I've ever seen it named after the last name unless it 
was their email id as well.

-dorian

Re: Richard Bennett, NANOG posting, and Integrity

[Dorian Kim]

On Jul 28, 2014, at 12:36 PM, Bill Woodcock  wrote:

> 
> On Jul 28, 2014, at 9:28 AM, William Herrin  wrote:
>> The data set suffers three flaws:
> 
> Depending on your point of view, a lot more than three, undoubtedly.
> 
>> 1. It is not representative of the actual traffic flows on the Internet.
> 
> There are an infinite number of things it’s not representative of, but it 
> also doesn’t claim to be representative of them.  Traffic flows on the 
> Internet is a different survey of a different thing, but if someone can 
> figure out how to do it well, I would be very supportive of their effort.  
> It's a _much_ more difficult survey to do, since it requires getting people 
> to pony up their unanonymized netflow data, which they’re a lot less likely 
> to do, en masse, than their peering data.  We’ve been trying to figure out a 
> way to do it on a large and representative enough scale to matter for twenty 
> years, without too much headway.  The larger the Internet gets, the more 
> difficult it is to survey well, so the problem gets harder with time, rather 
> than easier.

This most likely won’t happen unless it becomes some sort of an international 
treaty obligation and even then it would end up in courts for a long time. 
Leaving aside data privacy requirements many carriers have, most companies 
guard their traffic information rather zealously for some reason.

-dorian

Re: [OPINION] Best place in the US for NetAdmins

[Dorian Kim]

On Jul 27, 2014, at 1:41 PM, Matthew Petach  wrote:

> Telecommuting can work out amazingly well,
> for the right people.  But it takes dedication
> and focus, and a relentless willingness to
> be accessible to your coworkers.

It also takes an organization committed to it as well.

-dorian

Re: Connectivity issue between Verizon and Amazon EC2 (NTT issue?)

[Dorian Kim]

On Jul 23, 2014, at 3:23 AM, Matthew Petach  wrote:

>> We don't have a direct customer relationship with NTT so am hoping
>> someone on this list may be able to pass this information along or
>> investigate on our behalf.
>> 
>> Ray
>> 
>> 
> I'm sure there's NTT folks watching the thread go
> past, but it's unlikely they'd be in a position to
> say anything in a public forum like this one way
> or the other.  ^_^;

Is there anything to be said that adds anything to what is already a well
established situation regarding Verizon vs. much of the Internet?

-dorian

Re: iOS 7 update traffic

[Dorian Kim]

On Thu, Sep 19, 2013 at 06:52:51PM +, Warren Bailey wrote:
> My.. Our..  Users expect one thing..
> 
> Internet.

Isn't the ability to download something that they want part of the Internet 
thing that users expect from their service providers?

-dorian

Re: net neutrality and peering wars continue

[Dorian Kim]

On Wed, Jun 19, 2013 at 06:39:48PM -0500, Leo Bicknell wrote:
> 
> On Jun 19, 2013, at 6:03 PM, Randy Bush  wrote:
> 
> > as someone who does not really buy the balanced traffic story, some are
> > eyeballs and some are eye candy and that's just life, seems like a lot
> > of words to justify various attempts at control, higgenbottom's point.
> 
> I agree with Randy, but will go one further.
> 
> Requiring a balanced ratio is extremely bad business because it incentivizes 
> your competitors to compete in your home market.
> 
> You're a content provider who can't meet ratio requirements?  You go into the 
> eyeball space, perhaps by purchasing an eyeball provider, or creating one.
> 
> Google Fiber, anyone?
> 
> Having a requirement that's basically "you must compete with me on all the 
> products I sell" is a really dumb peering policy, but that's how the big guys 
> use ratio.

At the end of the day though, this comes down to a clash of business models and 
the
reason why it's a public spectacle, and of public policy interest is due to the 
wide spread legacy of monopoly driven public investment in the last mile 
infrastructure. 

-dorian

Re: Level3 worldwide emergency upgrade?

[Dorian Kim]

No one had hit the ISIS bug before the IETF enforced maintenance freeze because 
no one in their right mind would be running three week old code back then. I 
don't think things have changed that much. ;)

-dorian

On Feb 7, 2013, at 4:19 PM, Siegel, David wrote:

> I remember being glued to my workstation for 10 straight hours due to an OSPF 
> bug that took down the whole of net99's network.
> 
> I was pretty proud of our size at the time...about 30Mbps at peak.  Times are 
> different and so are expectations.  :-)
> 
> Dave
> 
> 
> -Original Message-
> From: Brett Watson [mailto:br...@the-watsons.org] 
> Sent: Wednesday, February 06, 2013 6:07 PM
> To: nanog@nanog.org
> Subject: Re: Level3 worldwide emergency upgrade?
> 
> Hell, we used to not have to bother notifying customers of anything, we just 
> fixed the problem. Reminds me a of a story I've probably shared on the past. 
> 
> 1995, IETF in Dallas. The "big ISP" I worked for at the time got tripped up 
> on a 24-day IS-IS timer bug (maybe all of them at the time did, I don't 
> recall)  where all adjacencies reset at once. That's like, entire network 
> down. Working with our engineering team in the *terminal* lab mind you, and 
> Ravi Chandra (then at Cisco) we reloaded the entire network of routers with 
> new code from Cisco once they'd fixed the bug. I seem to remember this being 
> my first exposure to Tony Li's infamous line, "... Confidence Level: boots in 
> the lab."
> 
> Good times.
> 
> -b
> 
> 
> On Feb 6, 2013, at 5:41 PM, Brandt, Ralph wrote:
> 
>> David. I am on an evening shift and am just now reading this thread.   
>> 
>> I was almost tempted to write an explanation that would have had 
>> identical content with yours based simply on Level3 doing something 
>> and keeping the information close.
>> 
>> Responsible Vendors do not try to hide what is being done unless it is 
>> an Op Sec issue and I have never seen Level3 act with less than 
>> responsibility so it had to be Op Sec.
>> 
>> When it is that, it is best if the remainder of us sit quietly on the 
>> sidelines.
>> 
>> Ralph Brandt
>> 
>> 
>> -Original Message-
>> From: Siegel, David [mailto:david.sie...@level3.com]
>> Sent: Wednesday, February 06, 2013 12:01 PM
>> To: 'Ray Wong'; nanog@nanog.org
>> Subject: RE: Level3 worldwide emergency upgrade?
>> 
>> Hi Ray,
>> 
>> This topic reminds me of yesterday's discussion in the conference 
>> around getting some BCOP's drafted.  it would be useful to confirm my 
>> own view of the BCOP around communicating security issues.  My 
>> understanding for the best practice is to limit knowledge distribution 
>> of security related problems both before and after the patches are 
>> deployed.  You limit knowledge before the patch is deployed to prevent 
>> yourself from being exploited, but you also limit knowledge afterwards 
>> in order to limit potential damage to others (customers, 
>> competitors...the Internet at large).  You also do not want to 
>> announce that you will be deploying a security patch until you have a 
>> fix in hand and know when you will deploy it (typically, next 
>> available maintenance window unless the cat is out of the bag and danger is 
>> real and imminent).
>> 
>> As a service provider, you should stay on top of security alerts from 
>> your vendors so that you can make your own decision about what action 
>> is required.  I would not recommend relying on service provider 
>> maintenance bulletins or public operations mailing lists for obtaining 
>> this type of information.  There is some information that can cause 
>> more harm than good if it is distributed in the wrong way and 
>> information relating to security vulnerabilities definitely falls into that 
>> category.
>> 
>> Dave
>> 
>> -Original Message-
>> From: Ray Wong [mailto:r...@rayw.net]
>> Sent: Wednesday, February 06, 2013 9:16 AM
>> To: nanog@nanog.org
>> Subject: Re: Level3 worldwide emergency upgrade?
>> 
>>> 
>> 
>> OK, having had that first cup of coffee, I can say perhaps the main 
>> reason I was wondering is I've gotten used to Level3 always being on 
>> top of things (and admittedly, rarely communicating). They've reached 
>> the top by often being a black box of reliability, so it's (perhaps
>> unrealistically) surprising to see them caught by surprise. Anything 
>> that pushes them into scramble mode causes me to lose a little sleep 
>> anyway. The alternative to what they did seems likely for at least a 
>> few providers who'll NOT manage to fix things in time, so I may well 
>> be looking at longer outages from other providers, and need to issue 
>> guidance to others on what to do if/when other links go down for 
>> periods long enough that all the cost-bounding monitoring alarms start 
>> to scream even louder.
>> 
>> I was also grumpy at myself for having not noticed advance 
>> communication, which I still don't seem to have, though since I 
>> outsourced my email to bigG, I've noticed I'm more li

Re: Writable SNMP

[Dorian Kim]

On Tue, Dec 06, 2011 at 12:15:35PM -0500, Mauch, Jared wrote:
> > Also, who tests snmp WRITE in their code? at scale? for daily
> > operations tasks? ... (didn't the snmp incident in 2002 teach us
> > something?)
> 
> There's no reason one can't program a device with SNMP, the main issue IMHO

There is one good reason. Every vendor seem to assign a junior intern to
maintanining SNMP code, so you are interfacing with your router via a very 
suspect interface. 

-dorian

Re: coprorations using BGP for advertising prefixes in mid-1990s

[Dorian Kim]

On Thu, May 12, 2011 at 04:21:59PM -0400, valdis.kletni...@vt.edu wrote:
> On Thu, 12 May 2011 14:53:53 CDT, Michael Sabino said:
> > If you are a big corporation, and it is 1995, how likely is it that you'll
> > utilize bgp for advertising your address space to the internet?
> 
> Well, we got AS1312 sometime before 1996 (the *last changed* timestamp is
> 19960207), that sort of implies that 1311 other organizations were grabbing AS
> numbers before that.  And since an AS number has no real use for anything 
> other
> than BGP, that implies some 1,300 organizations doing BGP in the 1995
> timeframe.

The actual number would be considerably smaller as there were large
(for some definition of large) block assignments of ASNs <~1000 or so 
to various academic networking entities such as NSFNet and regional 
networks as well as other Federal/Military networking organisations.

-dorian

Re: so big earthquake in JP

[Dorian Kim]

On Fri, Mar 11, 2011 at 07:29:29AM -0700, Garret Picchioni wrote:
> Does anyone have any stats on route updates that might suggest the
> possibility of fiber on the ocean floor being damaged?

There are some submarine cable outages but I don't believe exact
locations of damage has been isolated. I suspect that this may take 
some time.

-dorian

Re: so big earthquake in JP

[Dorian Kim]

I think it's probably more useful for people to follow this instead
of media reports:

http://earthquake.usgs.gov/earthquakes/recenteqsww/Quakes/quakes_big.php

-dorian

Re: [apops] so big earthquake in JP

[Dorian Kim]

On Thu, Mar 10, 2011 at 10:39:31PM -0800, George Bonser wrote:
> Upgraded to M8.8 24km deep.  This is a big one.

M8.8 at 05:46:23 UTC and M6.4 at 06:06:11 UTC so far according to USGS.

-dorian

Re: Only 5x IPv4 /8 remaining at IANA

[Dorian Kim]

Wouldn't it be better to leave such labels and judgements to future 
generations? I'm sure they'll be the best judge of who led them to paradise 
/ruin.

-dorian

Re: Cost of transit and options in APAC

[Dorian Kim]

On Wed, Aug 11, 2010 at 05:41:16PM -0500, Benson Schliesser wrote:
> 
> On 11 Aug 10, at 5:15 PM, Joel Jaeggli wrote:
> 
> >> Obviously I can't speak for the providers in question, but I'd guess
> >> that the cost for transit in AP is strongly related to the cost of
> >> long-haul transport.
> > 
> > Start with something that can be effectively isolated from the
> > transpacific path.
> > 
> > Gotten a quote for a 1Gbe or 10Gbe between two cities in India recently?
> 
> That could be useful.  Sadly, I have no first-hand knowledge of these costs.  
> How does in-country transport compare to trans-Pacific transport cost? (i.e. 
> on a per Mbps per kilometer or similar metric)  I assume it's cheaper 
> in-country / in-region compared to trans-oceanic.  Is this true?

This is not an assumption you can make safely depending on the country and 
specific
sub-region you are talking about.

If you go back to mid 90s, the situation was much the same in Europe, which was 
why
US East coast was the default location for IP traffic exchange for Europe until 
the
costs started to change.

-dorian

Re: off-topic: historical query concerning the Internet bubble

[Dorian Kim]

On Thu, Aug 05, 2010 at 01:38:38PM -0500, Andrew Odlyzko wrote:
> Apologies for intruding with this question, but I can't think
> of any group that might have more concrete information relevant
> to my current research.
> 
> 
> 
> Enclosed below is an announcement of a paper on technology bubbles.
> It is based largely on the Internet bubble of a decade ago, and
> concentrates on the "Internet traffic doubling every 100 days" tale.
> As the paper shows, this myth was perceived in very different ways
> by different people, and this by itself helps undermine the foundations
> of much of modern economics and economic policy making.
> 
> To get a better understanding of the dynamics of that bubble, to assist
> in the preparation of a book about that incident, I am soliciting 
> information from anyone who was active in telecom during that period. I 
> would particularly like to know what you and your colleagues estimated 
> Internet traffic growth to be, and what your reaction was to the 
> O'Dell/Sidgmore/WorldCom/UUNet myth.  If you were involved in the industry,
> and never heard of it, that would be extremely useful to know, too.
> 
> Ideally, I would like concrete information, backed up by dates, and 
> possibly
> even emails, and a permission to quote this information.  However, I will
> settle for more informal comments, and promise confidentiality to anyone
> who requests it.

The doubling rate from various parts of the tier 1 world I've seen
since mid 90s until now has been pretty consistent. It's been
ranging around 9-14 months or so with the shorter end of the
doubling number coming mostly during the 1996-2000 years, modulo 
specific fortunes of the tier 1 in question.

Was Mike O'Dell's famous doubling every 100 days just a myth?
Like any good tale, there most likely was an element of truth 
behind it.

It wouldn't surprise me if there was a 6-12 month span during 96-98
when the Internet traffic as a whole did grow by ~10x especially
as backbones made the painful and much delayed leap past DS3 and the 
back pressure was finally relieved. The problem is, the relevant
data are spread out all over and probably not obtainable.

I seem to remember thinking that those numbers seemed a bit high,
but mostly shrugging at it at the time I heard Mike and other UUNet
folks say it since it wasn't off by more than an order of magnitude 
and back then we tended to ignore things that were that close, and
UUNet was well known for their "forward looking statements" anyway.

Btw, just so we can at least put some real world scale to these traffic 
doubling rates tales, a non-descript tier 1 network that's not 
particularly any more or less successful than others have had an average 
doubling rate of roughly 13.1 months from 2000 to 2010 for their 
transpacific traffic.

-dorian

Re: Surcharge for providing Internet routes?

[Dorian Kim]

On Sun, May 02, 2010 at 08:27:56PM -0700, Matthew Petach wrote:
> In Asia, there is a popular, but incorrectly named product offering
> that many ISPs sell called "domestic transit" which they sell
> for price $X; for "full routes" you often pay $2X-$3X.  I grind my
> teeth every time I hear it, since "transit" doesn't mean "to select
> parts of the internet" in most people's eyes.  It's really a paid
> peering offering, but no matter how much I try to correct people,
> the habit of calling it "domestic transit" still persists.  :(

I don't think there is a universally agreed upon definition of what 
transit means other than it involves someone paying someone else.

Just to clarify, there are both domestic transit and country specific 
paid peering products out there in Asia/Pacific region.

I have no idea what the sales people call each in different
countries, but domestic transit is not a misnomer as the ISP
selling you this will be providing reacheability to their 
country specific customer base AND reacheability to their
country specific peers.

-dorian

Re: Upstream BGP community support

[Dorian Kim]

On Sat, Oct 31, 2009 at 06:49:03PM -0500, Richard A Steenbergen wrote:
> > I'm curious, since when did respecting bounds of contracts and agreements 
> > one has signed become "stodgy"?
> 
> There is no excuse for not being able to tell people where you learned a
> route from (continent, region, city, country, etc). I'm personally of
> the opinion that this is a good thing to share with the entire Internet,
> as it lets people make intelligent TE decisions for your routes even if
> they don't have a direct relationship with your network. You should also
> be able to at a minimum allow no-export or prepend to specific ASNs, and
> not being able to provide these to customers is absolutely grounds for
> "should never ever buy from" status.
> 
> The "we aren't allowed to say we're a peer" argument seems easily
> defeatable, realistically if you're a stodgy tier 1 all you need is
> "this is a customer" tag and you can figure out the rest with "not a
> customer" logic without explicitly violating any NDAs. The "alter export
> attributes within a specific region" argument is a somewhat legitimate
> one due to requirements for consistent announcements, but I prefer to
> enable it by default and deal with unhappy peers on a case by case
> basis.

This is a strawman argument. I never said that any of the above was
a bad thing, nor that transit providers shouldn't support them. They 
should. 

Only point I was addressing was your characterisation that networks
who do support various communities but do not publish those supported
communities were "stodgy" becuase they were doing so due to "silly NDA 
concerns or the like".

Fact is, regardless of whether you or I think it makes any sense or 
not is that some peering agreements preclude disclosure of the locations 
of peering, and in some extreme cases even the disclosure of the 
existance of said peering.

So if you were a party to such an agreement, you can not disclose things
you are bound from doing without breeching the agreement. 

Apologies to the list for the derail,

-dorian

Re: Upstream BGP community support

[Dorian Kim]

On Sat, Oct 31, 2009 at 06:27:38PM -0500, Richard A Steenbergen wrote:
> 1) Old stodgy tier 1's who have communities but don't want to share them
> with the world, because of silly NDA concerns or the like. This covers a

I'm curious, since when did respecting bounds of contracts and agreements 
one has signed become "stodgy"?

-dorian