Re: ICYMI: FBI looking into LA fiber cuts, Super Bowl

[Owen DeLong]

Drones could do unauthorized streaming just as well as unauthorized recording.

Also, the Santa Clara stadium is not enclosed.

Owen

> On Jan 20, 2016, at 15:56 , Matthew Black  wrote:
> 
> Enclosed stadiums won't have to worry about remote drones until they get 
> smart enough to open doors on their own. Not sure why the NFL gets uptight 
> about unauthorized recording. Most sporting events have little value once the 
> event is over.
> 
> matthew black
> 
> 
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Paul Ferguson
> Sent: Tuesday, January 19, 2016 4:42 PM
> To: nanog@nanog.org
> Subject: Re: ICYMI: FBI looking into LA fiber cuts, Super Bowl
> 
> 
> While I agree that the broadcast networks are concerned about
> unauthorized recording and/or rebroadcasting of the event, there's
> also a precedent on a drone crashing during a high-profile sporting
> event in the U.S.:
> 
> http://www.cnn.com/2015/09/04/us/us-open-tennis-drone-arrest/index.html
> 
> $.02,
> 
> - - ferg

Re: IPv6 traffic percentages?

[Job Snijders]

On Thu, Jan 21, 2016 at 11:44:34PM +0900, Randy Bush wrote:
> > You can configure pmacct to specify on which properties of the received
> > flow data it should aggregate its output data, one could configure
> > pmacct to store data using the following primitives:
> > 
> > ($timeperiod, $entrypoint_router_id, $bgp_nexthop, $packet_count)
> > 
> > Where $timeperiod is something like 5 minute ranges, and the post
> > processing software calculates the distance between the entrypoint
> > router and where the flow would leave the network ($bgp_nexthop).
> > 
> > See 'aggregate' on http://wiki.pmacct.net/OfficialConfigKeys
> > 
> > In short: you configure pmacct to throw away everything you don't need
> > (maybe after some light pre-processing), and hope that what remains is
> > small enough to fit in your cluster and at the same time offers enough
> > insight to answer the question you set out to resolve.
> 
> but could you explain in detail how this tests the hypothesis?
> 
> even of all your traffic entered on a bgp hop and exited on a bgp hop,
> and all bgp entries set next_hop (which i think you do), you would be
> ignoring the 'distance' the packet traveled from source to get to your
> entry and traveled from your exit to get to the final destination.

Yes, correct. This is why I mentioned before: "However, this would be
just one network's (biased) view on things."

With this I meant that I can measure something, but only within a subset
of the entire path a packet might traverse. (just that one routing
domain), so not end-to-end. And what might be true for us might not be
true for others.

Happy Squirrel Appreciation Day!

[Jay R. Ashworth]

I've just learned that this holiday is today, and I can't think of any
holiday NANOGers would appreciate more...

unless it was National Backhoe Day.

Cheers,
-- jra

-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Matthew D. Hardeman]

Hi everyone,

I know the long and storied history of Cogent and HE failing to peer for IPv6 
and failing to provide (from either side) for IPv6 transit between their two 
networks has been mentioned and covered on this list before, but I am rather 
surprised it has not garnered much attention.

Until recently, that is.  I notice an increasing number of people tweeting at 
both HE and Cogent about the problem.

From HE’s public statements on the matter, it’s pretty clear that they would 
gladly peer with Cogent for IPv6 but that Cogent declines to do this.  I simply 
cannot understand Cogent’s logic on this.  Cogent is the one loosing out here, 
to my way of thinking.  They have far less IPv6 coverage than HE.

I myself, on behalf of my employers, am a direct customer of IP transit 
services from both Cogent and HE.

I don’t know about others similarly positioned, but my Cogent rep tries to call 
me at least twice a month.  I’m going to start taking (more of) his calls and 
letting him know his account with us is in jeopardy come renewal time if Cogent 
can’t get a full IPv6 route table to happen.

Today, with Cogent & HE as peers, I am world reachable via IPv6.  If either 
peer went down however, part of the internet couldn’t reach me via IPv6 because 
either HE wouldn’t have a route or Cogent wouldn’t have a route.  That’s 
ridiculous.

Since Cogent is clearly the bad actor here (the burden being Cogent's to prove 
otherwise because HE is publicly on record as saying that they’d love to peer 
with Cogent), I’m giving serious consideration to dropping Cogent come renewal 
time and utilizing NTT or Zayo instead.

While that would not immediately solve the problem that if the NTT or Zayo link 
went down, single-homed Cogent customers would loose access to me via IPv6, I’m 
actually ok with that.  It at least lets ensures that when there is a problem, 
the problem affects only single-home Cogent clients.  Thus, the problem is 
borne exclusively by the people who pay the bad actor who is causing this 
problem.  That tends to get uncomfortable for the payee (i.e. Cogent).

I intend to email my Cogent sales guy regarding this matter and make this a 
sticking point in every phone conversation I have with him.  I call on others 
similarly situated to consider whether you may like to follow suit in this 
approach.  I’ve come to believe that it’s best for my interests and I also 
believe that it’s best for the internet community at large, as ubiquitous 
worldwide routing of IPv6 becomes more essential with each passing day.

In closing, I further add that it’s a mystery to me why Cogent wouldn’t desire 
an IPv6 peering with HE.  Let’s face it, if any of us had to choose a 
single-home IPv6 internet experience, between HE or Cogent, we’d all choose HE. 
 If those were the two options, HE is the “real” IPv6 internet and Cogent is a 
tiny sliver of the IPv6 internet.  I have actually wondered if HE is holding 
IPv6 peering with Cogent hostage, contingent on peering all protocols (IPv4 and 
IPv6) with Cogent.  There, I could see why Cogent might hesitate.  To my 
knowledge, however, this is not the case and I have heard no public accusation 
that HE is imposing such a constraint.  I would love to hear anyone from HE 
tell as much of the story as they are able.

PS - As an aside, has anyone noticed HE’s been growing their network by leaps 
and bounds this past year?  Direct peerings with AT and CenturyLink, more 
domestic US and Canadian POPs, and I believe the number of pathways across the 
North American continent has been improved substantially, too.

Thanks,

Matt Hardeman
IPiFony Systems, Inc.
AS6082

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Matthew D. Hardeman]

I’m inclined to agree with you, subject to some caveats:

1.  I think more Cogent customers need to be more vocal about it.  There hasn’t 
been an impetus to do so until recently.  Now real people (not network engineer 
sorts) are starting to use IPv6 for real.

2.  I agree with you in principle.  In an idea world, take HE and two others.  
I would however still say that if you could only take two, take HE and take 
something other than Cogent.  It’s a win-win if the experience of single-home 
Cogent customers gets to be worse as a result.  Perhaps having things 
occasionally break — only for single-home Cogent customers — is a benefit.


> On Jan 21, 2016, at 12:40 PM, Daniel Corbe  wrote:
> 
> 
>> On Jan 21, 2016, at 1:07 PM, Matthew D. Hardeman  
>> wrote:
>> 
>> Since Cogent is clearly the bad actor here (the burden being Cogent's to 
>> prove otherwise because HE is publicly on record as saying that they’d love 
>> to peer with Cogent), I’m giving serious consideration to dropping Cogent 
>> come renewal time and utilizing NTT or Zayo instead.
>> 
>> While that would not immediately solve the problem that if the NTT or Zayo 
>> link went down, single-homed Cogent customers would loose access to me via 
>> IPv6, I’m actually ok with that.  It at least lets ensures that when there 
>> is a problem, the problem affects only single-home Cogent clients.  Thus, 
>> the problem is borne exclusively by the people who pay the bad actor who is 
>> causing this problem.  That tends to get uncomfortable for the payee (i.e. 
>> Cogent).
>> 
>> 
> 
> Take two transit providers that aren’t in the group of (HE, Cogent).  Cogent 
> is probably banking on this being the response; figuring that they have the 
> financial resources to outlast HE if they’re both shedding customers.  
> 
> If you really wanted to stick it to Cogent, take 3 transit providers: HE and 
> two of any other providers besides Cogent.  
> 
> Cogent clearly aren’t going to cave to their own customers asking them to 
> peer with HE.  Otherwise it would have happened by now.  
> 
> Cogent sucks for lots of reasons and this one isn’t even in the top 5 IMHO.
> 
> 

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Daniel Corbe]

> On Jan 21, 2016, at 1:07 PM, Matthew D. Hardeman  
> wrote:
> 
> Since Cogent is clearly the bad actor here (the burden being Cogent's to 
> prove otherwise because HE is publicly on record as saying that they’d love 
> to peer with Cogent), I’m giving serious consideration to dropping Cogent 
> come renewal time and utilizing NTT or Zayo instead.
> 
> While that would not immediately solve the problem that if the NTT or Zayo 
> link went down, single-homed Cogent customers would loose access to me via 
> IPv6, I’m actually ok with that.  It at least lets ensures that when there is 
> a problem, the problem affects only single-home Cogent clients.  Thus, the 
> problem is borne exclusively by the people who pay the bad actor who is 
> causing this problem.  That tends to get uncomfortable for the payee (i.e. 
> Cogent).
> 
> 

Take two transit providers that aren’t in the group of (HE, Cogent).  Cogent is 
probably banking on this being the response; figuring that they have the 
financial resources to outlast HE if they’re both shedding customers.  

If you really wanted to stick it to Cogent, take 3 transit providers: HE and 
two of any other providers besides Cogent.  

Cogent clearly aren’t going to cave to their own customers asking them to peer 
with HE.  Otherwise it would have happened by now.  

Cogent sucks for lots of reasons and this one isn’t even in the top 5 IMHO.

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Brandon Butterworth]

> > On Jan 21, 2016, at 1:07 PM, Matthew D. Hardeman  
> > wrote:
> > Since Cogent is clearly the bad actor here (the burden being
> > Cogent's to prove otherwise because HE is publicly on record as saying
> > that theyd love to peer with Cogent)

I'd like to peer with all tier 1's, they are thus all bad as
they won't.

HE decided they want to be transit free for v6 and set out on
a campaign of providing free tunnels/transit/peering to establish
this. Cogent, for all their faults, are free to not accept the
offer.

Can the Cogent bashing stop now, save it for when they do something
properly bad.

brandon

New peerings between Hurricane Electric and Level3?

[Matthew D. Hardeman]

Yesterday I was looking at some of the IPv4 and IPv6 session summaries on 
http://lg.he.net and saw that both the Equinix Los Angeles and Equinix Ashburn 
site routers have new IPv4 and IPv6 sessions (not yet running, but 
administratively up for about 6 days now) configured for AS3356.

I know they already peer IPv6, though not at those sites.  Is this the first 
hint that HE and Level3 are coming around on an IPv4 and IPv6 peering agreement?

RE: ICYMI: FBI looking into LA fiber cuts, Super Bowl

[bzs]

On January 20, 2016 at 23:56 matthew.bl...@csulb.edu (Matthew Black) wrote:
 > Enclosed stadiums won't have to worry about remote drones until they get 
 > smart enough to open doors on their own. Not sure why the NFL gets uptight 
 > about unauthorized recording. Most sporting events have little value once 
 > the event is over.

Control. Which might include contractual obligations like against
showing some big-shot coach or player picking his nose or crying or
whatever (tho spitting seems ok even on artificial turf yuck!),
upskirts, whatever. Maybe certain people in attendance particularly in
the expensive boxes don't want to be shown (e.g., with their, um,
girlfriends), etc etc etc.

At least some money would be in bloopers or scandals.

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Robert Glover]

On 1/21/2016 10:40 AM, Daniel Corbe wrote:

On Jan 21, 2016, at 1:07 PM, Matthew D. Hardeman  wrote:

Since Cogent is clearly the bad actor here (the burden being Cogent's to prove 
otherwise because HE is publicly on record as saying that they’d love to peer 
with Cogent), I’m giving serious consideration to dropping Cogent come renewal 
time and utilizing NTT or Zayo instead.

While that would not immediately solve the problem that if the NTT or Zayo link 
went down, single-homed Cogent customers would loose access to me via IPv6, I’m 
actually ok with that.  It at least lets ensures that when there is a problem, 
the problem affects only single-home Cogent clients.  Thus, the problem is 
borne exclusively by the people who pay the bad actor who is causing this 
problem.  That tends to get uncomfortable for the payee (i.e. Cogent).



Take two transit providers that aren’t in the group of (HE, Cogent).  Cogent is 
probably banking on this being the response; figuring that they have the 
financial resources to outlast HE if they’re both shedding customers.

If you really wanted to stick it to Cogent, take 3 transit providers: HE and 
two of any other providers besides Cogent.

Cogent clearly aren’t going to cave to their own customers asking them to peer 
with HE.  Otherwise it would have happened by now.

Cogent sucks for lots of reasons and this one isn’t even in the top 5 IMHO.



Let's hear the top 5.   Peering disputes are up there, but what else?

We've had them as one of our providers going on 8 years, and we can only 
complain about the occasional peering disputes.


-Robert

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Ca By]

On Thu, Jan 21, 2016 at 10:52 AM, Brandon Butterworth 
wrote:

> > > On Jan 21, 2016, at 1:07 PM, Matthew D. Hardeman <
> mharde...@ipifony.com> wrote:
> > > Since Cogent is clearly the bad actor here (the burden being
> > > Cogent's to prove otherwise because HE is publicly on record as saying
> > > that theyd love to peer with Cogent)
>
> I'd like to peer with all tier 1's, they are thus all bad as
> they won't.
>
> HE decided they want to be transit free for v6 and set out on
> a campaign of providing free tunnels/transit/peering to establish
> this. Cogent, for all their faults, are free to not accept the
> offer.
>
> Can the Cogent bashing stop now, save it for when they do something
> properly bad.
>
> brandon
>

Selling a service that is considered internet but does not deliver full
internet access is generally considered properly bad.

I would not do business with either company, since neither of them provide
a full view.

CB

Re: New peerings between Hurricane Electric and Level3?

[Patrick W. Gilmore]

Make the AS path longer, losing traffic, and therefore revenue?

Why would they do that?

The twtelecom customers cannot multi-home (most of them anyway). Most of 3549’s 
traffic has other paths to the Internet.

-- 
TTFN,
patrick

> On Jan 21, 2016, at 2:22 PM, Matthew D. Hardeman  
> wrote:
> 
> I was actually surprised they didn’t just leave GBLX customers on AS3549, 
> kill all external AS3549 peerings, and treat AS3549 downline as a Level3 
> customer, accepting L3 and GBLX communities from GBLX customers.
> 
> That seems more along the lines of what they’re doing with the AS4323 TW 
> Telecom customers.  (Though, in fairness, AS3356 has always carried AS4323 as 
> a customer as far as I recall.)  It will be interesting to see if whether 
> they kill off AS4323 peerings.
> 
>> On Jan 21, 2016, at 1:13 PM, Marty Strong  wrote:
>> 
>> Depends on the market and how far along their migration is going. In 
>> experience with GTT (AS4436) they’re still not finished migrating everything 
>> to AS3257.
>> 
>> Regards,
>> Marty Strong
>> --
>> CloudFlare - AS13335
>> Network Engineer
>> ma...@cloudflare.com
>> +44 7584 906 055
>> smartflare (Skype)
>> 
>> http://www.peeringdb.com/view.php?asn=13335
>> 
>>> On 21 Jan 2016, at 19:12, Matthew D. Hardeman  wrote:
>>> 
>>> Intriguing.  If it were only that though, wouldn’t they just still pick it 
>>> up via TeliaSonera IC?
>>> 
>>> I did notice that in the past few months, TeliaSonera has been dropping 
>>> AS3549 from spots where they had session with both AS3549 and with AS3356 
>>> and now reaches AS3549 via AS3356.
>>> 
>>> 
 On Jan 21, 2016, at 1:08 PM, Marty Strong  wrote:
 
 I’ve heard from the grape vine that this is due to the GBLX to Level3 
 transition, and it’s in fact paid IP transit.
 
 Regards,
 Marty Strong
 --
 CloudFlare - AS13335
 Network Engineer
 ma...@cloudflare.com
 +44 7584 906 055
 smartflare (Skype)
 
 http://www.peeringdb.com/view.php?asn=13335
 
> On 21 Jan 2016, at 18:37, Matthew D. Hardeman  
> wrote:
> 
> Yesterday I was looking at some of the IPv4 and IPv6 session summaries on 
> http://lg.he.net and saw that both the Equinix Los Angeles and Equinix 
> Ashburn site routers have new IPv4 and IPv6 sessions (not yet running, 
> but administratively up for about 6 days now) configured for AS3356.
> 
> I know they already peer IPv6, though not at those sites.  Is this the 
> first hint that HE and Level3 are coming around on an IPv4 and IPv6 
> peering agreement?
 
>>> 
>> 

Forecasted: Ongoing Severe Weather - Winter Storm Jonas East Coast IDCs

[Keith Kouzmanoff]

Heads up.

 Forwarded Message 
Subject:  Forecasted: Ongoing Severe Weather - Winter Storm Jonas East 
Coast IDCs

Date: Thu, 21 Jan 2016 13:37:35 -0600
From: donotre...@gcs.att-mail.com


AT is on high alert as we closely monitor the path of Winter Storm 
Jonas, which is tracking up the Ashburn,VA, Annapolis, MD, Piscataway, 
NJ, Secaucus, NJ, 8/11 10th Ave. (NYC), and Watertown, MA, IDC areas.


AT has activated our emergency preparedness process and we are 
carefully following our checklist to help keep our customers and 
employees safe, our facilities protected, and our communications 
consistent. All facilities and IDCs in the Winter Storm's projected path 
have completed their pre-planned checklist. We have staffing plans in 
place to address weather contingencies. Generator fuel tanks and make-up 
water tanks (HVAC) have been topped off and each center has multiple 
days of fuel on site. If the building goes to emergency generators, 
provisions for the delivery of additional fuel have been made.


Additionally, our Client management teams are actively responding to 
customer questions and alert notifications. AT’s main concern is for 
the safety of our customers and our employees. Please do not take 
chances with the safety of your employees.


The IDC will remain open to customers unless weather conditions occur 
that requires the building to be locked down. We will send out periodic 
updates as the storm progresses.


--
Keith

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Jack Bates]

On 1/21/2016 12:44 PM, Matthew D. Hardeman wrote:

I’m inclined to agree with you, subject to some caveats:

1.  I think more Cogent customers need to be more vocal about it.  There hasn’t 
been an impetus to do so until recently.  Now real people (not network engineer 
sorts) are starting to use IPv6 for real.

2.  I agree with you in principle.  In an idea world, take HE and two others.  
I would however still say that if you could only take two, take HE and take 
something other than Cogent.  It’s a win-win if the experience of single-home 
Cogent customers gets to be worse as a result.  Perhaps having things 
occasionally break — only for single-home Cogent customers — is a benefit.

Honestly, don't take HE or Cogent if you can help it. Neither deserves 
to be rewarded in this dispute. That being said, there are plenty of 
small customers that are single homed to both. Unfortunately, I doubt 
their voices matter.


Jack

RE: Is it normal for your provider to withhold BGP peering info until the night of the cut?

[Ian Mock]

Sounds like you need a little posturing with your sales team and account 
manager on the phone. Threaten to cancel the contract and site their lack of 
support and willingness to help you be successful. Say they're interfering with 
your company's ability to do business. If their sales team is worth anything 
they'll jump all over trying to fix the problem. If not, cancel the contract 
and move on. Do you and your company's mgmt want to deal with someone that 
unhelpful? Imagine what happens when you have a problem..

Ian Mock

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of c b
Sent: Thursday, January 21, 2016 3:27 PM
To: nanog@nanog.org
Subject: Is it normal for your provider to withhold BGP peering info until the 
night of the cut?

We have 4 full-peering providers between two data centers. Our accounting 
people did some shopping and found that there was a competitor who came in 
substantially lower this year and leadership decided to swap our most expensive 
circuit to the new carrier. 
(I don't know what etiquette is, so I won't name the carrier... but it's a 
well-known name) Anyways, we were preparing for the circuit cutover and asked 
for the BGP peering info up front like we normally do. This carrier said that 
they don't provide this until the night of the cut. Now, we've done this 5 or 6 
times over the years with all of our other carriers and this is the first one 
to ever do this. We even escalated to our account manager and they still won't 
provide it.
I know it's not a huge deal, but life is so much easier when you can prestage 
your cut and rollback commands. In fact, our internal Change Management process 
mandates peer review all proposed config changes and now we have to explain why 
some lines say TBD!
Is this a common SOP nowadays? Anyone care to explain why they wouldn't just 
provide it ahead of time?
Thanks in advance.
CWB   

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Daniel Corbe]

> On Jan 21, 2016, at 1:47 PM, Robert Glover  wrote:
> 
> On 1/21/2016 10:40 AM, Daniel Corbe wrote:
>>> On Jan 21, 2016, at 1:07 PM, Matthew D. Hardeman  
>>> wrote:
>>> 
>>> Since Cogent is clearly the bad actor here (the burden being Cogent's to 
>>> prove otherwise because HE is publicly on record as saying that they’d love 
>>> to peer with Cogent), I’m giving serious consideration to dropping Cogent 
>>> come renewal time and utilizing NTT or Zayo instead.
>>> 
>>> While that would not immediately solve the problem that if the NTT or Zayo 
>>> link went down, single-homed Cogent customers would loose access to me via 
>>> IPv6, I’m actually ok with that.  It at least lets ensures that when there 
>>> is a problem, the problem affects only single-home Cogent clients.  Thus, 
>>> the problem is borne exclusively by the people who pay the bad actor who is 
>>> causing this problem.  That tends to get uncomfortable for the payee (i.e. 
>>> Cogent).
>>> 
>>> 
>> Take two transit providers that aren’t in the group of (HE, Cogent).  Cogent 
>> is probably banking on this being the response; figuring that they have the 
>> financial resources to outlast HE if they’re both shedding customers.
>> 
>> If you really wanted to stick it to Cogent, take 3 transit providers: HE and 
>> two of any other providers besides Cogent.
>> 
>> Cogent clearly aren’t going to cave to their own customers asking them to 
>> peer with HE.  Otherwise it would have happened by now.
>> 
>> Cogent sucks for lots of reasons and this one isn’t even in the top 5 IMHO.
>> 
>> 
> Let's hear the top 5.   Peering disputes are up there, but what else?
> 
> We've had them as one of our providers going on 8 years, and we can only 
> complain about the occasional peering disputes.
> 
> -Robert
> 

I don’t really have 5 reasons to hate cogent but I’ve got 3 big ones.  If 
you’ve had static transit with Cogent for 8 years at one or just a handful of 
locations, none of these will apply.  But..

1) They charge per IPv4 BGP session per month
2) They constantly screw up our orders.  
3) It then takes days for them to fix their own screw ups in their order 
system. 
 

Re: Is it normal for your provider to withhold BGP peering info until the night of the cut?

[Bob Evans]

I agree with Sean. Poor planning always leads to poor service.
It sure makes for a fast clumsy cut over.  But, you now know that you the
customer are not a priority or better planning steps would have been taken
for your consideration in advance.

Thank You
Bob Evans
CTO




> On Thu, 21 Jan 2016, c b wrote:
>> Is this a common SOP nowadays? Anyone care to explain why they wouldn't
>> just provide it ahead of time?
>
> Carrier saves costs by not having a clue, and has no idea which router
> will have an open port until they try to plug you in.
>
> Hope its not a long contract, because customer service never gets better
> ... only worse.
>
>
>

Re: Is it normal for your provider to withhold BGP peering info until the night of the cut?

[Florian Weimer]

* William Herrin:

> On Thu, Jan 21, 2016 at 4:26 PM, c b  wrote:
>> We have 4 full-peering providers between two data centers. Our
>> accounting people did some shopping and found that there was
>> a competitor who came in substantially lower this year and
>> leadership decided to swap our most expensive circuit to the new carrier.
>
> That's the first mistake. Internet w/ BGP is not a mass-market
> service. Accounting people have no business searching out highly
> technical custom products and services.

I guess that's why so many customers keep paying for circuits that
have long been shut down. :)

Re: Is it normal for your provider to withhold BGP peering info until the night of the cut?

[Dovid Bender]

I was wondering the same. Most likely because it's accounting that's making the 
decision and they don't want to spend a penny more than they have to$

Regards,

Dovid

-Original Message-
From: Daniel Corbe 
Sender: "NANOG" Date: Thu, 21 Jan 2016 18:35:05 
To: Ian Mock
Cc: nanog@nanog.org
Subject: Re: Is it normal for your provider to withhold BGP peering info until
 the night of the cut?

> We have 4 full-peering providers between two data centers. Our accounting 
> people did some shopping and found that there was a competitor who came in 
> substantially lower this year and leadership decided to swap our most 
> expensive circuit to the new carrier. 
> (I don't know what etiquette is, so I won't name the carrier... but it's a 
> well-known name) Anyways, we were preparing for the circuit cutover and asked 
> for the BGP peering info up front like we normally do. This carrier said that 
> they don't provide this until the night of the cut. Now, we've done this 5 or 
> 6 times over the years with all of our other carriers and this is the first 
> one to ever do this. We even escalated to our account manager and they still 
> won't provide it.
> I know it's not a huge deal, but life is so much easier when you can prestage 
> your cut and rollback commands. In fact, our internal Change Management 
> process mandates peer review all proposed config changes and now we have to 
> explain why some lines say TBD!
> Is this a common SOP nowadays? Anyone care to explain why they wouldn't just 
> provide it ahead of time?
> Thanks in advance.
> CWB 
> 

My question to the OP would be why didn’t you schedule the turndown of the old 
circuit to overlap with the turnup of the new circuit?  That way you could 
perform your cut independently of turn-up testing with your new provider.  Why 
is it that you MUST perform both activities on the same night?  You can always 
turn up a circuit, make sure it works and then turn it back down on your end 
until you’re actually ready to use it.  

Re: Is it normal for your provider to withhold BGP peering info until the night of the cut?

[William Herrin]

On Thu, Jan 21, 2016 at 4:26 PM, c b  wrote:
> We have 4 full-peering providers between two data centers. Our
> accounting people did some shopping and found that there was
> a competitor who came in substantially lower this year and
> leadership decided to swap our most expensive circuit to the new carrier.

That's the first mistake. Internet w/ BGP is not a mass-market
service. Accounting people have no business searching out highly
technical custom products and services. Custom services are highly
variable in terms of what the service actually delivers. Accounting
people are not at all equipped to evaluate them.


> Anyways, we were preparing for the circuit cutover and asked
> for the BGP peering info up front like we normally do. This carrier
> said that they don't provide this until the night of the cut.

It's not unusual for smaller providers who do less BGP to have the
engineer work with the customer on the phone to turn up the session
without collecting or preparing a bunch of documentation ahead of
time. This can be a good thing or a bad thing. They'll have more
outages but if they're willing to reprogram routers on the fly they
may also be more responsive when you have a problem. And they mayy be
more willing to customize your configuration.

Regards,
Bill Herrin



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

Re: Is it normal for your provider to withhold BGP peering info until the night of the cut?

[Bryan Socha via NANOG]

I know of 2 larger providers that have strange provisioning processes.
Both of them do layer 0/line testing and then their bgp group gets the
order to finish the routing.It's not that they are withholding the
info, they haven't done the bgp policy yet and it happens during turnup
testing.

But the data is fairly standard, what were you missing that wasn't on the
tech/bgp form you fill out at the start of setup?



Bryan Socha
Network Engineer
DigitalOcean


On Thu, Jan 21, 2016 at 4:26 PM, c b  wrote:

> We have 4 full-peering providers between two data centers. Our accounting
> people did some shopping and found that there was a competitor who came in
> substantially lower this year and leadership decided to swap our most
> expensive circuit to the new carrier.
> (I don't know what etiquette is, so I won't name the carrier... but it's a
> well-known name)
> Anyways, we were preparing for the circuit cutover and asked for the BGP
> peering info up front like we normally do. This carrier said that they
> don't provide this until the night of the cut. Now, we've done this 5 or 6
> times over the years with all of our other carriers and this is the first
> one to ever do this. We even escalated to our account manager and they
> still won't provide it.
> I know it's not a huge deal, but life is so much easier when you can
> prestage your cut and rollback commands. In fact, our internal Change
> Management process mandates peer review all proposed config changes and now
> we have to explain why some lines say TBD!
> Is this a common SOP nowadays? Anyone care to explain why they wouldn't
> just provide it ahead of time?
> Thanks in advance.
> CWB

Re: New peerings between Hurricane Electric and Level3?

[Marty Strong via NANOG]

Turns out my information from the grape vine was wrong *bows head in shame*.

Regards,
Marty Strong
--
CloudFlare - AS13335
Network Engineer
ma...@cloudflare.com
+44 7584 906 055
smartflare (Skype)

http://www.peeringdb.com/view.php?asn=13335

> On 21 Jan 2016, at 19:48, Matthew D. Hardeman  wrote:
> 
> That’s an excellent point, actually.
> 
>> On Jan 21, 2016, at 1:45 PM, Patrick W. Gilmore  wrote:
>> 
>> Make the AS path longer, losing traffic, and therefore revenue?
>> 
>> Why would they do that?
>> 
>> The twtelecom customers cannot multi-home (most of them anyway). Most of 
>> 3549’s traffic has other paths to the Internet.
>> 
>> -- 
>> TTFN,
>> patrick
>> 
>>> On Jan 21, 2016, at 2:22 PM, Matthew D. Hardeman  
>>> wrote:
>>> 
>>> I was actually surprised they didn’t just leave GBLX customers on AS3549, 
>>> kill all external AS3549 peerings, and treat AS3549 downline as a Level3 
>>> customer, accepting L3 and GBLX communities from GBLX customers.
>>> 
>>> That seems more along the lines of what they’re doing with the AS4323 TW 
>>> Telecom customers.  (Though, in fairness, AS3356 has always carried AS4323 
>>> as a customer as far as I recall.)  It will be interesting to see if 
>>> whether they kill off AS4323 peerings.
>>> 
 On Jan 21, 2016, at 1:13 PM, Marty Strong  wrote:
 
 Depends on the market and how far along their migration is going. In 
 experience with GTT (AS4436) they’re still not finished migrating 
 everything to AS3257.
 
 Regards,
 Marty Strong
 --
 CloudFlare - AS13335
 Network Engineer
 ma...@cloudflare.com
 +44 7584 906 055
 smartflare (Skype)
 
 http://www.peeringdb.com/view.php?asn=13335
 
> On 21 Jan 2016, at 19:12, Matthew D. Hardeman  
> wrote:
> 
> Intriguing.  If it were only that though, wouldn’t they just still pick 
> it up via TeliaSonera IC?
> 
> I did notice that in the past few months, TeliaSonera has been dropping 
> AS3549 from spots where they had session with both AS3549 and with AS3356 
> and now reaches AS3549 via AS3356.
> 
> 
>> On Jan 21, 2016, at 1:08 PM, Marty Strong  wrote:
>> 
>> I’ve heard from the grape vine that this is due to the GBLX to Level3 
>> transition, and it’s in fact paid IP transit.
>> 
>> Regards,
>> Marty Strong
>> --
>> CloudFlare - AS13335
>> Network Engineer
>> ma...@cloudflare.com
>> +44 7584 906 055
>> smartflare (Skype)
>> 
>> http://www.peeringdb.com/view.php?asn=13335
>> 
>>> On 21 Jan 2016, at 18:37, Matthew D. Hardeman  
>>> wrote:
>>> 
>>> Yesterday I was looking at some of the IPv4 and IPv6 session summaries 
>>> on http://lg.he.net and saw that both the Equinix Los Angeles and 
>>> Equinix Ashburn site routers have new IPv4 and IPv6 sessions (not yet 
>>> running, but administratively up for about 6 days now) configured for 
>>> AS3356.
>>> 
>>> I know they already peer IPv6, though not at those sites.  Is this the 
>>> first hint that HE and Level3 are coming around on an IPv4 and IPv6 
>>> peering agreement?
>> 
> 
 
>> 
> 

Re: Is it normal for your provider to withhold BGP peering info until the night of the cut?

[Daniel Corbe]

> We have 4 full-peering providers between two data centers. Our accounting 
> people did some shopping and found that there was a competitor who came in 
> substantially lower this year and leadership decided to swap our most 
> expensive circuit to the new carrier. 
> (I don't know what etiquette is, so I won't name the carrier... but it's a 
> well-known name) Anyways, we were preparing for the circuit cutover and asked 
> for the BGP peering info up front like we normally do. This carrier said that 
> they don't provide this until the night of the cut. Now, we've done this 5 or 
> 6 times over the years with all of our other carriers and this is the first 
> one to ever do this. We even escalated to our account manager and they still 
> won't provide it.
> I know it's not a huge deal, but life is so much easier when you can prestage 
> your cut and rollback commands. In fact, our internal Change Management 
> process mandates peer review all proposed config changes and now we have to 
> explain why some lines say TBD!
> Is this a common SOP nowadays? Anyone care to explain why they wouldn't just 
> provide it ahead of time?
> Thanks in advance.
> CWB 
> 

My question to the OP would be why didn’t you schedule the turndown of the old 
circuit to overlap with the turnup of the new circuit?  That way you could 
perform your cut independently of turn-up testing with your new provider.  Why 
is it that you MUST perform both activities on the same night?  You can always 
turn up a circuit, make sure it works and then turn it back down on your end 
until you’re actually ready to use it.  

Re: Is it normal for your provider to withhold BGP peering info until the night of the cut?

[Sean]

I’d be concerned. IMHO, it’s not normal to withhold such information. Doing so 
suggests that they are disorganized at best.

When we sign a BGP customer, we collect their ASN and the networks they want to 
advertise up front. With that information, we complete a network setup document 
that is forwarded to the customer. The document contains all of the information 
they provided, the transit network(s) we’ve assigned, and port info. This is 
done weeks/months before turn-up.


On 1/21/16, 2:26 PM, "NANOG on behalf of c b"  wrote:

>We have 4 full-peering providers between two data centers. Our accounting 
>people did some shopping and found that there was a competitor who came in 
>substantially lower this year and leadership decided to swap our most 
>expensive circuit to the new carrier. 
>(I don't know what etiquette is, so I won't name the carrier... but it's a 
>well-known name)
>Anyways, we were preparing for the circuit cutover and asked for the BGP 
>peering info up front like we normally do. This carrier said that they don't 
>provide this until the night of the cut. Now, we've done this 5 or 6 times 
>over the years with all of our other carriers and this is the first one to 
>ever do this. We even escalated to our account manager and they still won't 
>provide it.
>I know it's not a huge deal, but life is so much easier when you can prestage 
>your cut and rollback commands. In fact, our internal Change Management 
>process mandates peer review all proposed config changes and now we have to 
>explain why some lines say TBD!
>Is this a common SOP nowadays? Anyone care to explain why they wouldn't just 
>provide it ahead of time?
>Thanks in advance.
>CWB

Re: IPv6 traffic percentages?

[Randy Bush]

> With this I meant that I can measure something, but only within a subset
> of the entire path a packet might traverse.

considering your original hypothesis was about length of paths, this
seems a kind of dead end.  you might get a modest improvement by turning
off hot potato :)

> so not end-to-end

which is the problem

> And what might be true for us might not be true for others.

yes.  but if it actually measured what we wanted, it would be a useful
measurement.  but it doesn't.

randy

Netgear AC340U (AT Beam) for sms messages

[Matthew Huff]

We purchased the AT Beam and I've configured smstools under linux and 
everything looks okay (no error messages). Although text messages are accepted 
by the modem, no texts show up. I've learned that some carrier's mobile data 
sim don't support text. We have the sim that came with the box we ordered from 
AT AT is clueless and transferred me to netgear support. 

Does anyone have a suggestion where I can get a carrier/plan/sim that will work 
with the AC340U and text messages? I would prefer a plan rather than a pre-paid 
card that I have to re-fill. If you suggest a carrier, what magic words do I 
need to speak to have them order the right thing?




Matthew Huff | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC   | Phone: 914-460-4039
aim: matthewbhuff    | Fax:   914-694-5669

Re: Arista optics

[Fearghas Mckay]

> On 20 Jan 2016, at 16:56, Jeroen Wunnink 
>  wrote:
> 
> We have good experience with Flexoptix. You can brand them yourself
> using their (free?) USB box to any vendor you want, including Arista.
> Not sure if they have QSFP's yet, but we have CFP-LR4's running
> successfully on multiple paths of our backbone.

Wearing my Flexoptix hat I can confirm that we do QSFP & QSFP28 available. 

f

Re: Is it normal for your provider to withhold BGP peering info until the night of the cut?

[Larry Sheldon]

On 1/21/2016 15:33, Kraig Beahn wrote:

"This carrier said that they don't provide this until the night of the
cut." / "Is this a common SOP nowadays?" - Not in our experience.

On Thu, Jan 21, 2016 at 4:26 PM, c b  wrote:


We have 4 full-peering providers between two data centers. Our accounting
people did some shopping and found that there was a competitor who came in
substantially lower this year and leadership decided to swap our most
expensive circuit to the new carrier.
(I don't know what etiquette is, so I won't name the carrier... but it's a
well-known name)
Anyways, we were preparing for the circuit cutover and asked for the BGP
peering info up front like we normally do. This carrier said that they
don't provide this until the night of the cut. Now, we've done this 5 or 6
times over the years with all of our other carriers and this is the first
one to ever do this. We even escalated to our account manager and they
still won't provide it.
I know it's not a huge deal, but life is so much easier when you can
prestage your cut and rollback commands. In fact, our internal Change
Management process mandates peer review all proposed config changes and now
we have to explain why some lines say TBD!
Is this a common SOP nowadays? Anyone care to explain why they wouldn't
just provide it ahead of time?
Thanks in advance.
CWB




I have not been following this thread closely, but I'll bet I klnow why 
the new vendor is cheaper.


I have this theory that says accounting may not be the best place for 
technical OR engineering decision making (it destroyed the company I 
worked for for many years).


My theory (see the scientific usage of the word) is that "cheapest" is 
rarely "best" in any dimension INCLUDING "total cost".



--
sed quis custodiet ipsos custodes? (Juvenal)

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Matthew Kaufman]

> On Jan 21, 2016, at 1:05 PM, Ca By  wrote:
> 
> On Thu, Jan 21, 2016 at 10:52 AM, Brandon Butterworth 
> wrote:
> 
 On Jan 21, 2016, at 1:07 PM, Matthew D. Hardeman <
>> mharde...@ipifony.com> wrote:
 Since Cogent is clearly the bad actor here (the burden being
 Cogent's to prove otherwise because HE is publicly on record as saying
 that theyd love to peer with Cogent)
>> 
>> I'd like to peer with all tier 1's, they are thus all bad as
>> they won't.
>> 
>> HE decided they want to be transit free for v6 and set out on
>> a campaign of providing free tunnels/transit/peering to establish
>> this. Cogent, for all their faults, are free to not accept the
>> offer.
>> 
>> Can the Cogent bashing stop now, save it for when they do something
>> properly bad.
>> 
>> brandon
> 
> Selling a service that is considered internet but does not deliver full
> internet access is generally considered properly bad.
> 
> I would not do business with either company, since neither of them provide
> a full view.
> 
> CB

I note that if IPv6 was actually important, neither one could have gotten away 
with it for so long.

Matthew Kaufman

(Sent from my iPhone)

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Randy Bush]

welcome to the commercial internet.  get over it.

randy

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Matthew D. Hardeman]

An excellent point.  Nobody would tolerate this in IPv4 land.  Those disputes 
tended to end in days and weeks (sometimes months), but not years.

That said, as IPv6 is finally gaining traction, I suspect we’ll be seeing less 
tolerance for this behavior.


> On Jan 21, 2016, at 8:30 PM, Matthew Kaufman  wrote:
> 
> 
> 
>> On Jan 21, 2016, at 1:05 PM, Ca By  wrote:
>> 
>> On Thu, Jan 21, 2016 at 10:52 AM, Brandon Butterworth 
>> wrote:
>> 
> On Jan 21, 2016, at 1:07 PM, Matthew D. Hardeman <
>>> mharde...@ipifony.com> wrote:
> Since Cogent is clearly the bad actor here (the burden being
> Cogent's to prove otherwise because HE is publicly on record as saying
> that theyd love to peer with Cogent)
>>> 
>>> I'd like to peer with all tier 1's, they are thus all bad as
>>> they won't.
>>> 
>>> HE decided they want to be transit free for v6 and set out on
>>> a campaign of providing free tunnels/transit/peering to establish
>>> this. Cogent, for all their faults, are free to not accept the
>>> offer.
>>> 
>>> Can the Cogent bashing stop now, save it for when they do something
>>> properly bad.
>>> 
>>> brandon
>> 
>> Selling a service that is considered internet but does not deliver full
>> internet access is generally considered properly bad.
>> 
>> I would not do business with either company, since neither of them provide
>> a full view.
>> 
>> CB
> 
> I note that if IPv6 was actually important, neither one could have gotten 
> away with it for so long.
> 
> Matthew Kaufman
> 
> (Sent from my iPhone)



smime.p7s
Description: S/MIME cryptographic signature

Re: Is it normal for your provider to withhold BGP peering info until the night of the cut?

[Kraig Beahn]

"This carrier said that they don't provide this until the night of the
cut." / "Is this a common SOP nowadays?" - Not in our experience.

On Thu, Jan 21, 2016 at 4:26 PM, c b  wrote:

> We have 4 full-peering providers between two data centers. Our accounting
> people did some shopping and found that there was a competitor who came in
> substantially lower this year and leadership decided to swap our most
> expensive circuit to the new carrier.
> (I don't know what etiquette is, so I won't name the carrier... but it's a
> well-known name)
> Anyways, we were preparing for the circuit cutover and asked for the BGP
> peering info up front like we normally do. This carrier said that they
> don't provide this until the night of the cut. Now, we've done this 5 or 6
> times over the years with all of our other carriers and this is the first
> one to ever do this. We even escalated to our account manager and they
> still won't provide it.
> I know it's not a huge deal, but life is so much easier when you can
> prestage your cut and rollback commands. In fact, our internal Change
> Management process mandates peer review all proposed config changes and now
> we have to explain why some lines say TBD!
> Is this a common SOP nowadays? Anyone care to explain why they wouldn't
> just provide it ahead of time?
> Thanks in advance.
> CWB

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Tore Anderson]

* Ca By 

> Selling a service that is considered internet but does not deliver
> full internet access is generally considered properly bad.
> 
> I would not do business with either company, since neither of them
> provide a full view.

+1

Both networks are in a position to easily remedy the situation if they
were pragmatically inclined. For example, Cogent could simply accept
HE's offer to peer; HE could simply pick up Cogent's IPv6 routes from
their existing transit provider TSIC.

Instead they both choose to continue their game of chicken to the
detriment of both of their customer bases.

Fortunately there's no shortage of competitors to HE and Cogent who
prioritise providing connectivity higher than engaging in such
nonsense. Vote with your wallets, folks.

Tore

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it

[Matthew D. Hardeman]

I hear you.

Taken to extremes, I can see how the argument sounds like that.

However…  I have some thoughts on what you’ve said.

Most of us would never get peerings to all the Tier 1s.

But…

Hurricane Electric already has IPv6 peering to every network that matters, save 
for Cogent’s.  Every other accepted Tier 1 peers with HE on IPv6.  Even SPRINT. 
 If we got back historically, they (Sprint) were among the most coveted and 
hardest to get IP peerings.  Even they recognized HE’s dominance of the IPv6 
space early on.

I’m not bashing Cogent.  I’m a customer of theirs and they’ve generally served 
me well.  The trouble I have in accepting Cogent’s behavior in this matter is 
that it just seems irrational.  If a typical, public forum peering dispute 
arose between HE & Cogent regarding IPv6, frankly and pretty objectively, you’d 
expect it to be Hurricane Electric questioning the value of peering Cogent IPv6 
rather than Cogent questioning HE.

I don’t question these parties’ rights not to peer, but I do question the logic 
behind it.  I think Cogent is hurting themselves on this more than HE is 
getting hurt by it.


> On Jan 21, 2016, at 12:52 PM, Brandon Butterworth  
> wrote:
> 
>>> On Jan 21, 2016, at 1:07 PM, Matthew D. Hardeman  
>>> wrote:
>>> Since Cogent is clearly the bad actor here (the burden being
>>> Cogent's to prove otherwise because HE is publicly on record as saying
>>> that theyd love to peer with Cogent)
> 
> I'd like to peer with all tier 1's, they are thus all bad as
> they won't.
> 
> HE decided they want to be transit free for v6 and set out on
> a campaign of providing free tunnels/transit/peering to establish
> this. Cogent, for all their faults, are free to not accept the
> offer.
> 
> Can the Cogent bashing stop now, save it for when they do something
> properly bad.
> 
> brandon

Re: New peerings between Hurricane Electric and Level3?

[Matthew D. Hardeman]

Intriguing.  If it were only that though, wouldn’t they just still pick it up 
via TeliaSonera IC?

I did notice that in the past few months, TeliaSonera has been dropping AS3549 
from spots where they had session with both AS3549 and with AS3356 and now 
reaches AS3549 via AS3356.


> On Jan 21, 2016, at 1:08 PM, Marty Strong  wrote:
> 
> I’ve heard from the grape vine that this is due to the GBLX to Level3 
> transition, and it’s in fact paid IP transit.
> 
> Regards,
> Marty Strong
> --
> CloudFlare - AS13335
> Network Engineer
> ma...@cloudflare.com
> +44 7584 906 055
> smartflare (Skype)
> 
> http://www.peeringdb.com/view.php?asn=13335
> 
>> On 21 Jan 2016, at 18:37, Matthew D. Hardeman  wrote:
>> 
>> Yesterday I was looking at some of the IPv4 and IPv6 session summaries on 
>> http://lg.he.net and saw that both the Equinix Los Angeles and Equinix 
>> Ashburn site routers have new IPv4 and IPv6 sessions (not yet running, but 
>> administratively up for about 6 days now) configured for AS3356.
>> 
>> I know they already peer IPv6, though not at those sites.  Is this the first 
>> hint that HE and Level3 are coming around on an IPv4 and IPv6 peering 
>> agreement?
> 

Re: New peerings between Hurricane Electric and Level3?

[Marty Strong via NANOG]

I’ve heard from the grape vine that this is due to the GBLX to Level3 
transition, and it’s in fact paid IP transit.

Regards,
Marty Strong
--
CloudFlare - AS13335
Network Engineer
ma...@cloudflare.com
+44 7584 906 055
smartflare (Skype)

http://www.peeringdb.com/view.php?asn=13335

> On 21 Jan 2016, at 18:37, Matthew D. Hardeman  wrote:
> 
> Yesterday I was looking at some of the IPv4 and IPv6 session summaries on 
> http://lg.he.net and saw that both the Equinix Los Angeles and Equinix 
> Ashburn site routers have new IPv4 and IPv6 sessions (not yet running, but 
> administratively up for about 6 days now) configured for AS3356.
> 
> I know they already peer IPv6, though not at those sites.  Is this the first 
> hint that HE and Level3 are coming around on an IPv4 and IPv6 peering 
> agreement?

Re: New peerings between Hurricane Electric and Level3?

[Matthew D. Hardeman]

That’s an excellent point, actually.

> On Jan 21, 2016, at 1:45 PM, Patrick W. Gilmore  wrote:
> 
> Make the AS path longer, losing traffic, and therefore revenue?
> 
> Why would they do that?
> 
> The twtelecom customers cannot multi-home (most of them anyway). Most of 
> 3549’s traffic has other paths to the Internet.
> 
> -- 
> TTFN,
> patrick
> 
>> On Jan 21, 2016, at 2:22 PM, Matthew D. Hardeman  
>> wrote:
>> 
>> I was actually surprised they didn’t just leave GBLX customers on AS3549, 
>> kill all external AS3549 peerings, and treat AS3549 downline as a Level3 
>> customer, accepting L3 and GBLX communities from GBLX customers.
>> 
>> That seems more along the lines of what they’re doing with the AS4323 TW 
>> Telecom customers.  (Though, in fairness, AS3356 has always carried AS4323 
>> as a customer as far as I recall.)  It will be interesting to see if whether 
>> they kill off AS4323 peerings.
>> 
>>> On Jan 21, 2016, at 1:13 PM, Marty Strong  wrote:
>>> 
>>> Depends on the market and how far along their migration is going. In 
>>> experience with GTT (AS4436) they’re still not finished migrating 
>>> everything to AS3257.
>>> 
>>> Regards,
>>> Marty Strong
>>> --
>>> CloudFlare - AS13335
>>> Network Engineer
>>> ma...@cloudflare.com
>>> +44 7584 906 055
>>> smartflare (Skype)
>>> 
>>> http://www.peeringdb.com/view.php?asn=13335
>>> 
 On 21 Jan 2016, at 19:12, Matthew D. Hardeman  
 wrote:
 
 Intriguing.  If it were only that though, wouldn’t they just still pick it 
 up via TeliaSonera IC?
 
 I did notice that in the past few months, TeliaSonera has been dropping 
 AS3549 from spots where they had session with both AS3549 and with AS3356 
 and now reaches AS3549 via AS3356.
 
 
> On Jan 21, 2016, at 1:08 PM, Marty Strong  wrote:
> 
> I’ve heard from the grape vine that this is due to the GBLX to Level3 
> transition, and it’s in fact paid IP transit.
> 
> Regards,
> Marty Strong
> --
> CloudFlare - AS13335
> Network Engineer
> ma...@cloudflare.com
> +44 7584 906 055
> smartflare (Skype)
> 
> http://www.peeringdb.com/view.php?asn=13335
> 
>> On 21 Jan 2016, at 18:37, Matthew D. Hardeman  
>> wrote:
>> 
>> Yesterday I was looking at some of the IPv4 and IPv6 session summaries 
>> on http://lg.he.net and saw that both the Equinix Los Angeles and 
>> Equinix Ashburn site routers have new IPv4 and IPv6 sessions (not yet 
>> running, but administratively up for about 6 days now) configured for 
>> AS3356.
>> 
>> I know they already peer IPv6, though not at those sites.  Is this the 
>> first hint that HE and Level3 are coming around on an IPv4 and IPv6 
>> peering agreement?
> 
 
>>> 
> 



smime.p7s
Description: S/MIME cryptographic signature