(Network Orchestrators evaluation) : tail-f vs Anuta vs UBIqube vs OpenDaylight

[Kasper Adel]

Hi,

This is not a vendor bashing thread.

We are a group of networking engineers  less experience with software) in
the middle of the process of procuring a network automation/orchestration
controller, if that is even a good definition and we are clueless on how to
evaluate them.

Other than the obvious, which is to try them out, i wonder what else is
important to consider/watch out for.

We are presented with 3 different vendors and even OpenDayLight was
considered as the open source alternative.

My humble thoughts are given below and i would appreciate getting
'schooled' on what i need to ask the vendors:

1) Are they Model driven : But i still don't know how to evaluate that.
2) Do they parse Cisco/Juniper CLI or they are limited to SNMP and YANG.
3) If they do parse, we want to check if they'll hold us by the balls if
the current parsers need to be updated, i.e: can we change the code
ourselves and add new features to be parsed.
4) Can they work/orchestrate between CLI devices and Non CLI devices (SNMP)
5) How flexible are they to support different Vendors (Cisco, Juniper,
some-weird-firewall...etc)

thanks,
Kim

DevOps workflow for networking

[Kasper Adel]

We are pretty new to those new-age network orchestrators and automation,

I am curious to ask what everyone is the community is doing? sorry for such
a long and broad question.

What is your workflow? What tools are your teams using? What is working
what is not? What do you really like and what do you need to improve? How
mature do you think your process is? etc etc

Wanted to ask and see what approaches the many different teams here are
taking!

We are going to start working from a GitLab based workflow.

Projects are created, issues entered and developed with a gitflow branching
strategy.

GitLab CI pipelines run package loadings and run tests inside a lab.

Tests are usually python unit tests that are run to do both functional and
service creation, modification and removal tests.

For unit testing we typically use python libraries to open transactions to
do the service modifications (along with functional tests) against physical
lab devices.

For our prod deployment we leverage 'push on green' and gating to push
package changes to prod devices.

Thanks

Re: US/Canada International border concerns for routing

[Dave Cohen]

Sorta, kinda. The various ASs operated by Zayo are more interconnected than 
that description would imply. The traditional mode of operation on an "acquired 
AS" has been to turn down any upstream transit as quickly as contractually 
possible and upgrade NNI capacity between that AS and 6461 to compensate. Over 
time, legacy devices are overbuilt or replaced with ones directly on 6461. The 
net-net of it is that most traffic will end up egressing to other providers via 
6461's peering after a fairly short period, although this isn't universally 
true, especially for "local" traffic (e.g. traffic originating on the Neo AS 
staying in France, etc.). 

Dave Cohen
craetd...@gmail.com

> On Aug 8, 2017, at 10:13 PM, Eric Kuhnke  wrote:
> 
> It is worth noting, however, that the former AllStream ASN (formerly AT
> Canada) AS15290 is a completely different thing, and has distinct
> infrastructure and routing from the AboveNet ASN which is operated by Zayo.
> Although they are probably using "Free" Zayo transport by now.
> 
> If I am grossly wrong and anybody from layer 3 network operations at Zayo
> wants to chime in and tell us about the 40,000 ft view of their plans to
> combine AS15290 and AS6461, I am sure the community would be very
> interested.
> 
>> On Tue, Aug 8, 2017 at 5:31 PM, Stephen Fulton  
>> wrote:
>> 
>> TR,
>> 
>> MTS Allstream is no longer a combined entity.  MTS was purchased by Bell
>> Canada and Allstream was purchased by Zayo.
>> 
>> -- Stephen
>> 
>> 
>>> On 2017-08-08 8:19 PM, TR Shaw wrote:
>>> 
>>> Bill,
>>> 
>>> What does Bell buying MTS do? Does it change your statement or will the
>>> MTS portion of Bell still peer locally?
>>> 
>>> Tom
>>> 
 On Aug 8, 2017, at 8:10 PM, Bill Woodcock  wrote:
 
 
> On Jul 20, 2017, at 7:01 AM, Hiers, David  wrote:
> For traffic routing, is anyone constraining cross-border routing
> between Canada and the US?  IOW, if you are routing from Toronto to
> Montreal, do you have to guarantee that the path cannot go through, say,
> Syracuse, New York?
> 
 
 No.  In fact, Bell Canada / Bell Aliant and Telus guarantee that you
 _will_ go through Chicago, Seattle, New York, or Ashburn, since none of
 them peer anywhere in Canada at all.
 
 Last I checked (November of last year) the best-connected commercial
 networks (i.e. not CANARIE) in Canada were Hurricane Electric, MTS
 Allstream, Primus, and Zip Telecom, all of which peer at three or more
 Canadian IXes.  So, they’re capable of keeping traffic in Canada so long as
 the other end isn’t on Bell or Telus, which only sell U.S. bandwidth to
 Canadians.
 
 In November, only 27% of intra-Canadian routes stayed within Canada; 64%
 went through the U.S.  That’s way worse than five years ago, when 60%
 stayed within Canada, and 38% went through the U.S.
 
 As has been pointed out, Canada has been building IXPs…  Just not as
 fast as the rest of the world has.  They’re behind the global average
 growth rate, and behind the U.S. growth rate, which is why the problem is
 getting worse.  Bandwidth costs are falling faster elsewhere, so they’re
 importing more foreign bandwidth.
 
-Bill
 
 
 
 
 
>>> 

Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"?

[Jeff Waddell]

When I lasted checked in with Ubiquiti on these issues for that and the
ER-Pros - they told me that everything was to be resolved in 2.0

We shall see...

On Tue, Aug 8, 2017 at 9:20 PM, Mike Hammett  wrote:

> Ah, okay. I haven't used one yet.
>
> Also, I don't talk about beta outside of beta. ;-)
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> - Original Message -
>
> From: "Josh Reynolds" 
> To: "Mike Hammett" 
> Cc: "NANOG" 
> Sent: Tuesday, August 8, 2017 8:07:36 PM
> Subject: Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"?
>
>
> Forgot reply all...
>
>
> That does not apply to the infinity. Those shipped with 1.9.8dev.
>
>
>
>
>
> On Aug 8, 2017 8:03 PM, "Mike Hammett" < na...@ics-il.net > wrote:
>
>
> 1.9.7+hotfix.1 is the currently available stable. 1.9.1.1 was released on
> May 1st.
>
> https://community.ubnt.com/t5/EdgeMAX-Updates-Blog/EdgeMAX-
> EdgeRouter-software-security-release-v1-9-7-hotfix-1/ba-p/2019161
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> - Original Message -
>
> From: "Nick W" < nickdwh...@gmail.com >
> To: nanog@nanog.org
> Sent: Thursday, July 20, 2017 10:55:28 PM
> Subject: Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"?
>
> Tried the Infinity, unsuccessfully. Several of them. Ended up pulling them
> all, sitting in my homelab for now. Multiple full tables, nothing fancy for
> firewall or QOS, but ran into issues with random ribd/bgpd crashes and
> kernel panics. I've submitted a lot of logs and core dumps to UBNT. I would
> personally stay away from them until they are out of beta, and possibly
> even another 6-12 months after that.
>
> The current stable EdgeMax version (1.9.1.1) is relatively stable, but
> using an outdated ZebOS (1.2.0?) with a number of issues (MPLS, OSPF, BGP)
> - nothing too major, but can be annoying. Probably okay for what you
> described. Depending on how much throughput you need, an ERPro, or Mikrotik
> would probably be fine. If you need 10G, load up VyOS on some cheap servers
> with an Intel or Solarflare card... probably cheaper than a beta Infinity
> or Mikrotik.
>
> On Mon, Jul 3, 2017 at 3:07 PM, Job Snijders < j...@instituut.net > wrote:
>
> > Dear NANOG,
> >
> > Some friends of mine are operating a nonprofit (on shoe string) and
> looking
> > to connect some CDN caches to an IX fabric. A BGP speaking device is
> needed
> > between the caches and the BGP peers connected to the fabric. The BGP
> > speaker is needed to present the peers on the IX with a unified view of
> the
> > assemblage of CDN nodes.
> >
> > I was wondering whether anyone was experience with the "EdgeRouter
> Infinity
> > XG" device, specifically in the role of a simple peering router for a
> > couple of tens of thousands of routes. (I'd point default to the left and
> > take just the on-net routes on the right to reduce the table size
> > requirement).
> >
> > I hope the device can do at least 2xLACP trunks, has a sizable FIB, is
> > automatable (supports idempotency), can forward IMIX at line-rate, *flow,
> > and exposes some telemetry via SNMP.
> >
> > Any note sharing would be appreciated!
> >
> > Kind regards,
> >
> > Job
> >
>
>
>
>
>

Re: US/Canada International border concerns for routing

[Rod Beck]

I am not sure that this answers your question, but carriers are looking for 
more diversity on cross border traffic. Right now virtually all Toronto/NYC 
runs through Buffalo and 350 Main, Buffalo. May be Montreal/NYC has more 
options.


There have been huge network builds in the US Northeast by Unite and 
Firstlight, which are providing optical backhaul from cell towers. So more 
routing options may be available than in the past.


An issue that no one discussed in the age of the fiber. The big carriers and 
the Web Giants do not want to 1998 manufactured fiber. And some of the Web 
Giants are only putting 4x 100 gig waves per fiber pair. So the incentive to 
create new diverse routes with new large fiber builds is growing.


- R.



From: NANOG  on behalf of Constantine A. Murenin 

Sent: Wednesday, August 9, 2017 1:54 AM
To: Hiers, David
Cc: nanog@nanog.org
Subject: Re: US/Canada International border concerns for routing

On 20/07/2017, Hiers, David  wrote:
> Hi,
> We're looking to extend some services into Canada.  While our lawyers dig
> into it, I thought that I'd ask the hive mind about border restrictions.
>
> For traffic routing, is anyone constraining cross-border routing between
> Canada and the US?  IOW, if you are routing from Toronto to Montreal, do you
> have to guarantee that the path cannot go through, say, Syracuse, New York?

Guarantee to whom?

Back a few years ago when I looked into it, most of the traffic within
Canada went through the US, e.g., since Bell didn't want to peer with
anyone in Canada, you'd go something like YYZ - ORD - YYZ, clearly
visible through the traceroute.

Possibly somewhat better nowadays — there's been quite a few new IX
POPs that popped up — but I doubt the scenario is a thing of the past.

P.S.  Just for the giggles — checked http://lg.he.net/ routing from
Looking Glass - Hurricane Electric (AS6939)
lg.he.net
Hurricane Electric (AS6939) Network Looking Glass


core1.tor1.he.net to www.bell.ca — still goes through 
Chicago, to
[http://upload.wikimedia.org/wikipedia/commons/thumb/9/91/Bell_logo.svg/120px-Bell_logo.svg.png]

Bell Canada - Mobile phones, TV, Internet and Home phone 
...
www.bell.ca
Bell is Canada's largest telecommunications company, providing Mobile phone, 
TV, high speed and wireless Internet, and residential Home phone services.


Montreal, from Toronto. :-)  Going straight to Montreal,
core1.ymq1.he.net, will route you to www.bell.ca (still in 
Montreal)
[http://upload.wikimedia.org/wikipedia/commons/thumb/9/91/Bell_logo.svg/120px-Bell_logo.svg.png]

Bell Canada - Mobile phones, TV, Internet and Home phone 
...
www.bell.ca
Bell is Canada's largest telecommunications company, providing Mobile phone, 
TV, high speed and wireless Internet, and residential Home phone services.


through the peering at NYC.

P.P.S.  In other words — if someone wants guarantees, they better
explicitly ask you for it.

Cheers,
Constantine.
http://cm.su/
cm.su. — Constantine Murenin is Super User
cm.su
Constantine Murenin is Super User Yes, it's true! Constantine.SU; BXR.SU; 
mdoc.su; nginx.conf 2016; GitHub; StackOverflow © 2016 Constantine A. Murenin 
(cnst)

Re: US/Canada International border concerns for routing

[Rod Beck]

I would bet that most British Columbia traffic gets routed to 
Vancouver>Seattle. Just a hunch, but I suspect that connectivity capacity 
across Canada from British Columbia to the Eastern part of the country is 
pretty limited.


- R.



From: NANOG  on behalf of Keenan Tims 

Sent: Wednesday, August 9, 2017 2:48 AM
To: nanog@nanog.org
Subject: Re: US/Canada International border concerns for routing

On 2017-08-08 17:10, Bill Woodcock wrote:
> No.  In fact, Bell Canada / Bell Aliant and Telus guarantee that you_will_  
> go through Chicago, Seattle, New York, or Ashburn, since none of them peer 
> anywhere in Canada at all.

The major national networks (Bell, Rogers, Telus, Shaw, Zayo/Allstream)
do peer with each other and some other large / old Canadian networks
(e.g. MTS, SaskTel, Peer1) within Canada. While they do practice peering
protectionism and only purchase transit out of country, the situation is
not *quite* so bad that all traffic round-trips through the US.

Of course if neither side of the conversation has at least one of those
major networks as a transit upstream - which is most of the eyeballs and
most of the important Canadian content - you'll see that hop through
Chicago or Seattle (or worse). Which is exactly the way they like it.

Keenan

Re: Cisco Nexus 93180YC Switch Feedback

[Tim Stevenson]

At 03:48 PM 8/8/2017  Tuesday, Simon Lockhart opined:

On Tue Jul 25, 2017 at 08:31:54PM -0700, Tim Stevenson wrote:
> tstevens-92160yc-1# sh int cap | beg 1/49 | eg Eth|Speed
> Ethernet1/49 >   Speed: 4
> Ethernet1/50 >   Speed: 1000,1,25000,4,5,10
> Ethernet1/51 >   Speed: 4
> Ethernet1/52 >   Speed: 1000,1,25000,4,5,10
> Ethernet1/53 >   Speed: 4
> Ethernet1/54 >   Speed: 4

Are you sure?



I'll claim correctness on a technicality ;)

Since the original statement was: "Notably only four of the six 100G 
ports on the 92160YCX will run at 100G, leaving two at 40G."


In the default mode, you get 4 x 40G + 2 x 100G. Good point that 
there is an optional mode which is 4 x 100G - but there is no 40G in 
that mode, ports 53-54 are disabled in that mode.


Thanks,
Tim




xsw-01.ixn# show ver | incl Nexus9
  cisco Nexus9000 C92160YC-X chassis

xsw-01.ixn# sh int cap | beg 1/49 | eg Eth|Speed
Ethernet1/49
  Speed: 4,10
Ethernet1/50
  Speed: 1000,1,25000,4,5,10
Ethernet1/51
  Speed: 1000,1,25000,4,5,10
Ethernet1/52
  Speed: 1000,1,25000,4,5,10

xsw-01.ixn# show run | incl portmode
hardware profile portmode 48x25G+4x100G

xsw-01.ixn(config)# hardware profile portmode ?
  48x25g+2x100g+4x40g  48x25G+2x100G+4x40G port mode
  48x25g+4x100g48x25G+4x100G port mode

You can configure how the ports present themselves...

Simon






Tim Stevenson, tstev...@cisco.com
Routing & Switching CCIE #5561
Distinguished Engineer, Technical Marketing
Data Center Switching
Cisco - http://www.cisco.com
+1(408)526-6759

RE: US/Canada International border concerns for routing

[Hiers, David]

I can't thank everyone enough for their input and insight!

It sounds like my discovery didn't miss some glaringly obvious form, checkbox, 
agreement or community (NO-US-EH, for instance  ) to keep traffic from 
crossing the border.

Data *storage*, on the other hand, is a very different thing, and even a drunk 
intern can find the rules around that kind of thing.

Thanks again,

David
 

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Dave Cohen
Sent: Tuesday, August 08, 2017 5:53 PM
To: Bill Woodcock 
Cc: nanog@nanog.org
Subject: Re: US/Canada International border concerns for routing

It seems to me the original question was asking about it more from a legal 
perspective, in other words does Canadian traffic have to stay in Canada. IANAL 
(or a Canadian), but the answer is "mostly, no, especially as related to 
publicly routed traffic" as should be evidenced based on what's already been 
discussed here. In other words, there is restricted traffic but unless you're 
making a play for MAN/WAN type service on owned infrastructure, those 
requirements are unlikely to arise. 

To support the macro point, there is some big-boy level peering in Toronto but 
not really much else outside that, but there are plenty of routes that don't 
cross the border if you don't have to jump networks to your destination, for 
example going to an AWS on ramp in Canada using a native partner network, 
especially in the Toronto-Ottawa-Montreal. 

Dave Cohen
craetd...@gmail.com

> On Aug 8, 2017, at 8:41 PM, Bill Woodcock  wrote:
> 
> 
> --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E
> Content-Transfer-Encoding: quoted-printable
> Content-Type: text/plain;
>charset=us-ascii
> 
> 
>> On Aug 8, 2017, at 5:33 PM, Clayton Zekelman  wrote:
>> =20
>> =20
>> =20
>> With the peering policies of the major Canadian ISPs, you're 
>> virtually =
> guaranteed to hairpin through the US on most paths.
>> =20
>> Robellus (Rogers, Bell & Telus) will peer with you at any of their =
> major Canadian peering points, such as NYC, Chicago or LA.
> 
> To be fair, Rogers does peer in Toronto.  Along with New York, 
> Chicago, = Seattle, and Ashburn.
> 
>-Bill
> 
> 
> 
> 
> 
> --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E
> Content-Transfer-Encoding: 7bit
> Content-Disposition: attachment;
>filename=signature.asc
> Content-Type: application/pgp-signature;
>name=signature.asc
> Content-Description: Message signed with OpenPGP
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIcBAEBCAAGBQJZilooAAoJEG+kcEsoi3+HgNsQAIPkgL/lVL/j1sdPyiyQsepE
> TCyHm4bsAq6m085kXoRj/IWn+KsVwmAq8ZGKnKEAiozmrSeyxAa2vmw5Kfs57l1/
> crBima+EOOlPT4VcD7tv9e8yEiVdjDuMp5tnLI238qCfIlHeHRtuU7CClzWPv6uD
> 3jCNIBEcScrLWz37Ofm/D2AkYRAhhK5H8I417Y/39TH4MIoIKFsGbvWwpl30Fv8r
> 5phO0MrTP6mB8niHne6HTxyMED5TGQpVEL2Qgh6qgaI9vzAs5/47KwwY57tZpxaL
> v9GjkPJ4Ql7QVWbsSkXnFmHxXzqaHXAfg8SR+gsCN42Jyn99AIyAAwdALhqc4RuZ
> ydi+lOlEutAMndA01CnrI81Eu/RpWrN+q/vi37W2rb6EPTPcCz2196JDlpC6VVW6
> tJOMNuP6Pa/ee52Cxu6RWwA4QZ6QVIT9fbDcRFXTGNuohwP8XVpujcsPLChzsFXA
> Y2nt+TliL697lTZNbTZEzQ0f9w2rpCDpcLjTMCR8MNWZ4MjQHL3eDgO5ZIWHPTQf
> ggR1Dz2EhPSXXZdvN7KPh1q9rhRb2VUPSn3EeEDo2TjgUVeUlunsDg/ILpf8lxUY
> RTsXe5Nky7YqXKDG4HSlLF3R/RtfaVqKJfjljYg351cs40rzivzjD2TJ8r35RQeW
> btKUtEvrcU28g15nOhLG
> =MTUG
> -END PGP SIGNATURE-
> 
> --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E--
> 

--
This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, notify the sender immediately by return email and delete the message 
and any attachments from your system.

Re: Admiral Hosting in London

[Brock Tice]

On August 8, 2017 6:25:56 PM MDT, Mike Hammett  wrote:
>I've heard of some people that don't have the capital to purchase their
>own block yet, but want PI space so they can move away from whomever is
>providing their transit + IP space now. I'm sure the discussed reason
>is much more prevalent, though. 
>
>
>
>
>- 
>Mike Hammett 
>Intelligent Computing Solutions 
>http://www.ics-il.com 
>
>Midwest-IX 
>http://www.midwest-ix.com 
>
>- Original Message -
>
>From: "Chris Woodfield"  
>To: "Randy Bush" , "Michael Wayne"  
>Cc: "NANOG list"  
>Sent: Monday, July 31, 2017 11:31:47 AM 
>Subject: Re: Admiral Hosting in London 
>
>And I’d *love* to hear the story they come up with when you ask why
>they only want to rent space vs buy it… 
>
>-C 
>
>> On Jul 27, 2017, at 9:22 PM, Randy Bush  wrote: 
>> 
>>> We were contacted by Admiral Hosting in London to rent some our 
>>> unused IP space. 
>> 
>> anyone wanting to rent/lease space is 99% sure to be not nice folk. 
>> if you get your space back, it will be radioactive with an amazingly 
>> long half life. 
>> 
>> if you are willing to let go of the space, just tell them the price 
>> for which you are willing to sell it. 
>> 
>> randy 
>> 

We are renting space to supplement our ARIN IPv4 allocation until we get 
464xlat going. Some of the IPs had bad reputations but we sorted them out.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: US/Canada International border concerns for routing

[Ahad Aboss]

David

Generally speaking, when customers have concerns about their traffic
crossing borders, they do ask upfront.

As a multinational operator you can only guarantee traffic if customers
asks and offcours pays the fee for special class of service.

Ahad

On Wed, 9 Aug 2017 at 9:21 am, Hiers, David  wrote:

> Hi,
> We're looking to extend some services into Canada.  While our lawyers dig
> into it, I thought that I'd ask the hive mind about border restrictions.
>
> For traffic routing, is anyone constraining cross-border routing between
> Canada and the US?  IOW, if you are routing from Toronto to Montreal, do
> you have to guarantee that the path cannot go through, say, Syracuse, New
> York?
>
> I'm asking network operators about packet routing; data storage is a very
> different matter, of course.
>
> Thanks,
>
> David
>
> --
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, notify the sender immediately by
> return email and delete the message and any attachments from your system.
>

Re: US/Canada International border concerns for routing

[Andrew Kerr]

Canadian  here who's evaluated service providers and dealt with legal
requirements for our customers...

Generally we weren't worried about data travelling through the US based on
normal internet routes, as long as it was encrypted.   The thing we usually
specified in RFPs was that the data could never be stored in the US.

On Tue, 8 Aug 2017 at 17:52 Dave Cohen  wrote

> It seems to me the original question was asking about it more from a legal
> perspective, in other words does Canadian traffic have to stay in Canada.
> IANAL (or a Canadian), but the answer is "mostly, no, especially as related
> to publicly routed traffic" as should be evidenced based on what's already
> been discussed here. In other words, there is restricted traffic but unless
> you're making a play for MAN/WAN type service on owned infrastructure,
> those requirements are unlikely to arise.
>
> To support the macro point, there is some big-boy level peering in Toronto
> but not really much else outside that, but there are plenty of routes that
> don't cross the border if you don't have to jump networks to your
> destination, for example going to an AWS on ramp in Canada using a native
> partner network, especially in the Toronto-Ottawa-Montreal.
>
> Dave Cohen
> craetd...@gmail.com
>
> > On Aug 8, 2017, at 8:41 PM, Bill Woodcock  wrote:
> >
> >
> > --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E
> > Content-Transfer-Encoding: quoted-printable
> > Content-Type: text/plain;
> >charset=us-ascii
> >
> >
> >> On Aug 8, 2017, at 5:33 PM, Clayton Zekelman  wrote:
> >> =20
> >> =20
> >> =20
> >> With the peering policies of the major Canadian ISPs, you're virtually =
> > guaranteed to hairpin through the US on most paths.
> >> =20
> >> Robellus (Rogers, Bell & Telus) will peer with you at any of their =
> > major Canadian peering points, such as NYC, Chicago or LA.
> >
> > To be fair, Rogers does peer in Toronto.  Along with New York, Chicago, =
> > Seattle, and Ashburn.
> >
> >-Bill
> >
> >
> >
> >
> >
> > --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E
> > Content-Transfer-Encoding: 7bit
> > Content-Disposition: attachment;
> >filename=signature.asc
> > Content-Type: application/pgp-signature;
> >name=signature.asc
> > Content-Description: Message signed with OpenPGP
> >
> > -BEGIN PGP SIGNATURE-
> >
> > iQIcBAEBCAAGBQJZilooAAoJEG+kcEsoi3+HgNsQAIPkgL/lVL/j1sdPyiyQsepE
> > TCyHm4bsAq6m085kXoRj/IWn+KsVwmAq8ZGKnKEAiozmrSeyxAa2vmw5Kfs57l1/
> > crBima+EOOlPT4VcD7tv9e8yEiVdjDuMp5tnLI238qCfIlHeHRtuU7CClzWPv6uD
> > 3jCNIBEcScrLWz37Ofm/D2AkYRAhhK5H8I417Y/39TH4MIoIKFsGbvWwpl30Fv8r
> > 5phO0MrTP6mB8niHne6HTxyMED5TGQpVEL2Qgh6qgaI9vzAs5/47KwwY57tZpxaL
> > v9GjkPJ4Ql7QVWbsSkXnFmHxXzqaHXAfg8SR+gsCN42Jyn99AIyAAwdALhqc4RuZ
> > ydi+lOlEutAMndA01CnrI81Eu/RpWrN+q/vi37W2rb6EPTPcCz2196JDlpC6VVW6
> > tJOMNuP6Pa/ee52Cxu6RWwA4QZ6QVIT9fbDcRFXTGNuohwP8XVpujcsPLChzsFXA
> > Y2nt+TliL697lTZNbTZEzQ0f9w2rpCDpcLjTMCR8MNWZ4MjQHL3eDgO5ZIWHPTQf
> > ggR1Dz2EhPSXXZdvN7KPh1q9rhRb2VUPSn3EeEDo2TjgUVeUlunsDg/ILpf8lxUY
> > RTsXe5Nky7YqXKDG4HSlLF3R/RtfaVqKJfjljYg351cs40rzivzjD2TJ8r35RQeW
> > btKUtEvrcU28g15nOhLG
> > =MTUG
> > -END PGP SIGNATURE-
> >
> > --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E--
> >
>

Re: US/Canada International border concerns for routing

[Rod Beck]

Hi Eric,


Allstream fiber goes counterclockwise from Toronto to Buffalo along the lake. 
Just like the rest of them. And at several places all these sysgtems are 
probably in the same conduit.


Finally, all fiber is exhausted Toronto/Buffalo. Existing players could not 
sell if they wanted to and no one selling dark on this route today.


- R.




From: NANOG  on behalf of Eric Kuhnke 

Sent: Wednesday, August 9, 2017 4:13 AM
To: Stephen Fulton; nanog@nanog.org list
Subject: Re: US/Canada International border concerns for routing

It is worth noting, however, that the former AllStream ASN (formerly AT
Canada) AS15290 is a completely different thing, and has distinct
infrastructure and routing from the AboveNet ASN which is operated by Zayo.
Although they are probably using "Free" Zayo transport by now.

If I am grossly wrong and anybody from layer 3 network operations at Zayo
wants to chime in and tell us about the 40,000 ft view of their plans to
combine AS15290 and AS6461, I am sure the community would be very
interested.

On Tue, Aug 8, 2017 at 5:31 PM, Stephen Fulton  wrote:

> TR,
>
> MTS Allstream is no longer a combined entity.  MTS was purchased by Bell
> Canada and Allstream was purchased by Zayo.
>
> -- Stephen
>
>
> On 2017-08-08 8:19 PM, TR Shaw wrote:
>
>> Bill,
>>
>> What does Bell buying MTS do? Does it change your statement or will the
>> MTS portion of Bell still peer locally?
>>
>> Tom
>>
>> On Aug 8, 2017, at 8:10 PM, Bill Woodcock  wrote:
>>>
>>>
>>> On Jul 20, 2017, at 7:01 AM, Hiers, David  wrote:
 For traffic routing, is anyone constraining cross-border routing
 between Canada and the US?  IOW, if you are routing from Toronto to
 Montreal, do you have to guarantee that the path cannot go through, say,
 Syracuse, New York?

>>>
>>> No.  In fact, Bell Canada / Bell Aliant and Telus guarantee that you
>>> _will_ go through Chicago, Seattle, New York, or Ashburn, since none of
>>> them peer anywhere in Canada at all.
>>>
>>> Last I checked (November of last year) the best-connected commercial
>>> networks (i.e. not CANARIE) in Canada were Hurricane Electric, MTS
>>> Allstream, Primus, and Zip Telecom, all of which peer at three or more
>>> Canadian IXes.  So, they’re capable of keeping traffic in Canada so long as
>>> the other end isn’t on Bell or Telus, which only sell U.S. bandwidth to
>>> Canadians.
>>>
>>> In November, only 27% of intra-Canadian routes stayed within Canada; 64%
>>> went through the U.S.  That’s way worse than five years ago, when 60%
>>> stayed within Canada, and 38% went through the U.S.
>>>
>>> As has been pointed out, Canada has been building IXPs…  Just not as
>>> fast as the rest of the world has.  They’re behind the global average
>>> growth rate, and behind the U.S. growth rate, which is why the problem is
>>> getting worse.  Bandwidth costs are falling faster elsewhere, so they’re
>>> importing more foreign bandwidth.
>>>
>>> -Bill
>>>
>>>
>>>
>>>
>>>
>>

Re: AS202746 Hijacks: Is Telia (a) stupid, or (b) lazy, or (c) complicit?

[Rich Kulawiec]

On Wed, Aug 02, 2017 at 05:51:43PM +0200, Sebastian Wiesinger wrote:
> You know, people might be more willing to listen to you when you
> express your points in a less emotional and aggressive tone.

You know, lots of us tried that for the first ten or twenty years.

But snark aside, I care a lot more about the actionable intelligence
being provided than the manner of its presentation.  Ron has been doing
valuable, useful research for years and has been kind enough to share
the results with us.  For free.  I'm grateful for that.

---rsk