Re: Last Week's Canadian Fiber Cut

[David Charlebois]

Just read this on http://www.ctvnews.ca/business/bell-aliant-says-
double-cable-cut-that-led-to-cell-outages-was-perfect-storm-1.3547018

"Bell spokesman Nathan Gibson says the first cut was by a highway
construction crew near Drummondville, Que.

He says service wasn't impacted in any significant way because of
redundancy in the network until a second major cut near Richibucto, N.B.,
by a logging company in a densely forested location.

He says the second cut was difficult to access and took some time to locate
precisely, and the site's inaccessibility slowed the arrival of heavy
equipment and repair crews."

On Tue, Aug 15, 2017 at 6:04 PM, JASON BOTHE  wrote:

> Interesting enough, we did not lose connectivity to our offices in PEI, so
> I assume there is some diversity from that point in the Bell network.
>
> J~
>
> > On 15, Aug 2017, at 3:37 PM, Rod Beck 
> wrote:
> >
> > Well Hibernia had those routes. I thought it would have been the 360
> terrestrial cable and Hibernia's underwater cable from Halifax to their
> Boston landing station.
> >
> >
> > 
> > From: NANOG  on behalf of Clinton Work <
> clin...@scripty.com>
> > Sent: Tuesday, August 15, 2017 10:07 PM
> > To: nanog@nanog.org
> > Subject: Re: Last Week's Canadian Fiber Cut
> >
> > I can't speak for the Bell Aliant network, but I'm only aware of two
> > diverse fiber routes out of Halifax, Nova Scotia.   Halifax -> New
> > Brunswick -> Quebec City is the Canadian route and Halifax -> Boston is
> > the diverse route.
> >
> > On Tue, Aug 15, 2017, at 01:52 PM, Jared Mauch wrote:
> >> Perhaps some transatlantic fallback?  It looks like the only cable out
> >> there is the Greenland one.. guessing that’s not very competitive?  It
> >> only gets you to Iceland it seems.
> >>
> >
>
>

Re: Last Week's Canadian Fiber Cut

[JASON BOTHE]

Interesting enough, we did not lose connectivity to our offices in PEI, so I 
assume there is some diversity from that point in the Bell network.

J~

> On 15, Aug 2017, at 3:37 PM, Rod Beck  wrote:
> 
> Well Hibernia had those routes. I thought it would have been the 360 
> terrestrial cable and Hibernia's underwater cable from Halifax to their 
> Boston landing station.
> 
> 
> 
> From: NANOG  on behalf of Clinton Work 
> 
> Sent: Tuesday, August 15, 2017 10:07 PM
> To: nanog@nanog.org
> Subject: Re: Last Week's Canadian Fiber Cut
> 
> I can't speak for the Bell Aliant network, but I'm only aware of two
> diverse fiber routes out of Halifax, Nova Scotia.   Halifax -> New
> Brunswick -> Quebec City is the Canadian route and Halifax -> Boston is
> the diverse route.
> 
> On Tue, Aug 15, 2017, at 01:52 PM, Jared Mauch wrote:
>> Perhaps some transatlantic fallback?  It looks like the only cable out
>> there is the Greenland one.. guessing that’s not very competitive?  It
>> only gets you to Iceland it seems.
>> 
> 

Re: Last Week's Canadian Fiber Cut

[Rod Beck]

Well Hibernia had those routes. I thought it would have been the 360 
terrestrial cable and Hibernia's underwater cable from Halifax to their Boston 
landing station.



From: NANOG  on behalf of Clinton Work 

Sent: Tuesday, August 15, 2017 10:07 PM
To: nanog@nanog.org
Subject: Re: Last Week's Canadian Fiber Cut

I can't speak for the Bell Aliant network, but I'm only aware of two
diverse fiber routes out of Halifax, Nova Scotia.   Halifax -> New
Brunswick -> Quebec City is the Canadian route and Halifax -> Boston is
the diverse route.

On Tue, Aug 15, 2017, at 01:52 PM, Jared Mauch wrote:
> Perhaps some transatlantic fallback?  It looks like the only cable out
> there is the Greenland one.. guessing that’s not very competitive?  It
> only gets you to Iceland it seems.
>

Re: Last Week's Canadian Fiber Cut

[Clinton Work]

I can't speak for the Bell Aliant network, but I'm only aware of two
diverse fiber routes out of Halifax, Nova Scotia.   Halifax -> New
Brunswick -> Quebec City is the Canadian route and Halifax -> Boston is
the diverse route.  

On Tue, Aug 15, 2017, at 01:52 PM, Jared Mauch wrote:
> Perhaps some transatlantic fallback?  It looks like the only cable out
> there is the Greenland one.. guessing that’s not very competitive?  It
> only gets you to Iceland it seems.
> 

Re: Last Week's Canadian Fiber Cut

[Jared Mauch]

> On Aug 15, 2017, at 1:22 PM, Rod Beck  wrote:
> 
> Did we ever get any resolution on why this was such a big outage? Appears 
> there were two fiber cuts. Were the fibers damaged in the same conduit? Is 
> this a collapsed ring scenario?
> 
> 
> http://www.cbc.ca/news/canada/newfoundland-labrador/concerns-about-backup-bell-outage-1.4239064

Perhaps some transatlantic fallback?  It looks like the only cable out there is 
the Greenland one.. guessing that’s not very competitive?  It only gets you to 
Iceland it seems.

- Jared

Re: Last Week's Canadian Fiber Cut

[Rod Beck]

In other words, bad luck. Probability dictates if enough time transpires, every 
bad thing will happen. 😝



From: NANOG  on behalf of Clinton Work 

Sent: Tuesday, August 15, 2017 8:59 PM
To: nanog@nanog.org
Subject: Re: Last Week's Canadian Fiber Cut

My understanding is that the Bell Aliant outage was a double fault
situation.   Bell Aliant had a fiber cut on one of their fiber routes
early in the morning and then they had a fault on the diverse fiber
route before the first trouble could be repaired.

On Tue, Aug 15, 2017, at 11:22 AM, Rod Beck wrote:
> Did we ever get any resolution on why this was such a big outage? Appears
> there were two fiber cuts. Were the fibers damaged in the same conduit?
> Is this a collapsed ring scenario?
>

Re: Last Week's Canadian Fiber Cut

[Clinton Work]

My understanding is that the Bell Aliant outage was a double fault
situation.   Bell Aliant had a fiber cut on one of their fiber routes
early in the morning and then they had a fault on the diverse fiber
route before the first trouble could be repaired.  

On Tue, Aug 15, 2017, at 11:22 AM, Rod Beck wrote:
> Did we ever get any resolution on why this was such a big outage? Appears
> there were two fiber cuts. Were the fibers damaged in the same conduit?
> Is this a collapsed ring scenario?
> 

Last Week's Canadian Fiber Cut

[Rod Beck]

Did we ever get any resolution on why this was such a big outage? Appears there 
were two fiber cuts. Were the fibers damaged in the same conduit? Is this a 
collapsed ring scenario?


http://www.cbc.ca/news/canada/newfoundland-labrador/concerns-about-backup-bell-outage-1.4239064


Roderick Beck

Director of Global Sales

United Cable Company

DRG Undersea Consulting

Affiliate Member

www.unitedcablecompany.com

85 Király utca, 1077 Budapest

rod.b...@unitedcablecompany.com

36-30-859-5144


[1467221477350_image005.png]

Re: Virtual or Remote Peering

[Fredrik Korsbäck]

How well does this service work? I understand it usually involves 
point-to-multipoint Switched Ethernet with VLANs and resold IX ports. Sounds 
like a service for ISP that would like to peer, but have relatively small 
volumes for peering purposes or lopsided volumes.


Roderick Beck

Director of Global Sales

United Cable Company

DRG Undersea Consulting

Affiliate Member

www.unitedcablecompany.com

85 Király utca, 1077 Budapest

rod.b...@unitedcablecompany.com

36-30-859-5144


[1467221477350_image005.png]



Its like buying regular ip-transit, but worse.




--
hugge

Virtual or Remote Peering

[Rod Beck]

How well does this service work? I understand it usually involves 
point-to-multipoint Switched Ethernet with VLANs and resold IX ports. Sounds 
like a service for ISP that would like to peer, but have relatively small 
volumes for peering purposes or lopsided volumes.


Roderick Beck

Director of Global Sales

United Cable Company

DRG Undersea Consulting

Affiliate Member

www.unitedcablecompany.com

85 Király utca, 1077 Budapest

rod.b...@unitedcablecompany.com

36-30-859-5144


[1467221477350_image005.png]

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

[James Bensley]

On 10 August 2017 at 02:01, Kasper Adel  wrote:
> Hi,

Hi Kim,

> 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.

If you don't have much in house software expertise buying an off the
shelf solution with support could be the best bet for you. ODL is
aimed more at somebody who wants to "roll their own" solution as it's
really giving you a unified southbound API to your devices but you
still need to connect with the ODL via its northbound API in order to
orchestrate your tin really fluently. This will require a lot of in
house development work (probably more than you want). Also this is
“just” (albiet a powerful one) an API to your network. It won’t act as
a single source of truth, it’s not a data store, or an IPAM, or an NMS
etc.

Anuta seems quite good, of all the ones you listed in the subject line
I'd recommend that one. We had a demo of Anuta NCX and I was pretty
happy with it, it's vendor neutral with support for the big names
already built it an you can write Python plugins to extending support
to any weird vendor kit you might have lurking in a remote dusty PoP,
they also take feature request if enough customers have vendor X
they’ll add support for it. It is also semi-service orchestrated, you
can define “services” yourself and config templates and push them out
to devices. I quite liked it, I'd recommend you get a demo if you want
an off the self-product that is vendor neutral with support. It ticks
those basic boxes (probably more but I can’t remember as we didn’t
choose it – not because it was flawed, it just wasn’t what we needed
for the project we had in mind). Like ODL it is just for mass
configuration and essentially and zero touch provisioning. You need to
glue it to the rest of your OSS stack probably via the API.

Tail-f - seeing as they were gobbled up by Cisco, do you mean whatever
the Cisco product is called now, NSO I believe (Network Services
Orchestrator). We had a meeting with Cisco a while back to arrange a
demo, at the time it was very Cisco focused however I think it has
become more open (in that it is still a closed source product but more
network device vendor agnostic).

Don’t know UBiqube – I’ll have a read up on it, thanks!

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

As mentioned above, get something with an API, if you have multiple
systems internally for BSS and OSS, try to move towards only having
systems with APIs so that in the long term when say the BSS system
accepts an order it can push an update to your OSS stack which
configure a port on an edge router ready for that customer to connect
to, and connects to your NMS API and pre-emptively starts to graph the
port; all that jazz. Service orchestration is more than just
automating config deployment which some people seem to forgot, or
focus too much on, the service wrap is also very important (after
accepting an order for a new CPE from a customer, and having fired the
order over your suppliers API, in the response from the supplier with
the new CPEs serial number, that needs to go into your asset database
and be marked against that customer and the end site it’s being
shipped to etc). Flexible products with a standardised API.


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

NAPALM was already mentioned as an open source alternative. If you
want to get your hands a bit more dirty consider Ansible or SaltStack
(both of which can be used with and without NAPALM but generally you
want to use them with NAPALM) as they are both open source and free to
use but you can pay for support.

We also looked at Blue Planet from Ciena, it’s an impressive product
with some big name customers. It also has a big price tag as it’s
really for large deployments. We didn’t go with it because we wanted
to start (very) small trials and build up.


> 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.

By model driven do you mean like YANG models to infer the
configuration state, or model driven from a service perspective? Anuta
NCX, Blue Planet, Tail-F/NSO, ODL all have support for YANG models if
you meant YANG. Anuta and NSO will let you create “services” which can
be config templates that are deployed as a whole and verified, if you
mean “service” model driven.

> 2) Do they parse Cisco/Juniper CLI or they are limited to SNMP and YANG.

If you have IOS devices you NEED a product that supports IOS CLI. IOS
is a pain in the backside to automate and the CLI is the only really
way of doing it sadly.

> 3) If they do parse, we want to che