Re: XGS-PON & "Dedicated" Service

[Karsten Thomann via NANOG]

Hi,

It depends on the configuration of the bandwidth how dedicated it is, leaving 
the shared PON architecture aside.

There are three different types of bandwidth on a PON
Committed: always reserved, can't be used by other customers, like fixed TDM 
bandwidth
Assured: your bandwidth is still guaranteed, but can be used by others if not 
needed by your connection
Best-effort: you get what is left by the other two.

You should ask how much of your bandwidth is committed and or assured as it can 
be a combination of all three in the worst case.
Like 50% of your circuit speed is committed, the next 25% assured and the last 
25% best effort.

So the best would be to get an answer about what they are really delivering.

Karsten
⁣ ​

Am 25. Okt. 2023, 01:56, um 01:56, "Neader, Brent" 
 schrieb:
>Hello!
>
>Interested in getting the larger community's thought on this.
>
>The primary question being does XGS-PON have a place in providing a
>dedicated enterprise level service (at least sold as one) in the
>marketplace?  Delivered via a residential (per the data sheet
>description) CPE, Nokia XS-010X-Q for a 1gb/1gb dedicated symmetrical
>service.
>
>Background, ive dealt with 30+ providers over the last 18 years,
>primarily last mile based.  Typically we seek out an
>Enterprise/Dedicated service, with an SLA, typically delivered via
>DWDM, CWDM, or AE, or equivalent.  We have also had a site or two
>delivered via a PON variant, typically with less of an SLA, typically
>maybe half to quarter of the price of a dedicated service.  Price & SLA
>sets the expectation of the service, CPE provided, underlying
>technology, etc.
>
>Dealing with a large over-builder right now who has an "elite"
>enterprise product (highest of 3 tiers) advertised as the following.
>
>
>-100% dedicated bandwidth so you never have to compete for
>speed
>
>
>-Mission Critical Reliability with 99.999% guaranteed uptime
>
>
>-Financially backed SLA with the most stringent performance
>objectives
>
>
>-Enterprise-level customer service and technical support
>
>Now I understand with XGS, you can have various QOS in place (WRR/SP,
>etc), but inherently there are still shared splits involved, that just
>aren't a thing in other truly dedicated technologies.  Expectations
>were set with the provider's sales team around what was to be delivered
>and how it was to be delivered that seemingly haven't been met by the
>product and service team.
>
>That aside, from an SP perspective, is it capable to wrap enough layers
>around service to be "dedicated" even when delivered via a conflicting
>underlying technology?  Or could that be considered disingenuous for
>those that want to know and understand the difference?  Im hoping the
>service itself and support team make up for the difference, but
>obviously a little concerned.
>
>Thanks!

Re: XGS-PON & "Dedicated" Service

[Mark Tinka]

On 10/25/23 01:56, Neader, Brent wrote:


Hello!

Interested in getting the larger community’s thought on this.

The primary question being does XGS-PON have a place in providing a 
dedicated enterprise level service (at least sold as one) in the 
marketplace?  Delivered via a residential (per the data sheet 
description) CPE, Nokia XS-010X-Q for a 1gb/1gb dedicated symmetrical 
service.


Background, ive dealt with 30+ providers over the last 18 years, 
primarily last mile based.  Typically we seek out an 
Enterprise/Dedicated service, with an SLA, typically delivered via 
DWDM, CWDM, or AE, or equivalent.  We have also had a site or two 
delivered via a PON variant, typically with less of an SLA, typically 
maybe half to quarter of the price of a dedicated service.  Price & 
SLA sets the expectation of the service, CPE provided, underlying 
technology, etc.


Dealing with a large over-builder right now who has an “elite” 
enterprise product (highest of 3 tiers) advertised as the following.


-100% dedicated bandwidth so you never have to compete for speed

-Mission Critical Reliability with 99.999% guaranteed uptime

-Financially backed SLA with the most stringent performance objectives

-Enterprise-level customer service and technical support

Now I understand with XGS, you can have various QOS in place (WRR/SP, 
etc), but inherently there are still shared splits involved, that just 
aren’t a thing in other truly dedicated technologies.  Expectations 
were set with the provider’s sales team around what was to be 
delivered and how it was to be delivered that seemingly haven’t been 
met by the product and service team.


That aside, from an SP perspective, is it capable to wrap enough 
layers around service to be “dedicated” even when delivered via a 
conflicting underlying technology? Or could that be considered 
disingenuous for those that want to know and understand the 
difference?  Im hoping the service itself and support team make up for 
the difference, but obviously a little concerned.




Regular GPON is already being used to deliver Enterprise services, 
purely because it "passes by the office complex" on its way to the 
residential neighborhood. Even when the Sales team are told not to use 
GPON for Enterprise services, they end up doing so... first as a 
"temporary, we have told the customer all the pitfalls" solution, which 
eventually becomes permanent, and then it grows like wildfire.


You can expect that XG-PON will go the same way.

Mark.

Re: ESPN streaming issues

[Mike Lyon]

Check your blocks on the various databases here and see which ones are reporting as out of the country:IP Geolocation and VPN Resourcesthebrotherswisp.comThen follow-up with those individual DBs to get the locations corrected.You should be all set.-MikeOn Oct 24, 2023, at 20:32, Brad Bendy  wrote:Anyone have a contact for ESPN or can someone contact me off list?Have a good amount of IP space that just started reporting the IP isout of the country.Thanks

Re: RPKI unknown for superprefixes of existing ROA ?

[Randy Bush]

> Believe it or not, Job, there are parts of the internet that exchange
> traffic and move packets that are not IXPs.

in fact, measurements had shown that the majority of inter-domain
traffic is over pnis

randy

Re: RPKI unknown for superprefixes of existing ROA ?

[Job Snijders via NANOG]

On Tue, Oct 24, 2023 at 05:28:31PM -0700, Owen DeLong wrote:
> Yes, but we weren’t talking about an IXP here.
> We’re talking about an ISP.

Sure, perhaps you were

I intended to submit an example where a resource holder constructively
uses a ROA designating AS 0 as purported originator, actually helps the
overall ecosystem.

> Believe it or not, Job, there are parts of the internet that exchange
> traffic and move packets that are not IXPs.

¯\_(ツ)_/¯

Re: RPKI unknown for superprefixes of existing ROA ?

[Tom Beecher]

>
> He’s announcing all 4 /24s
>

That's not what was described as the original situation.

  Operator has prefix 1.2.4/22, but announce only 1.2.5/24 and 1.2.6/24,
> with appropriate ROAs. To avoid abuse of 1.2.4/24 and 1.2.7/24, they also
> make a ROA for 1.2.4/22 with AS 0. Attacker now announces 1.2.0/20, and
> uses IPs in 1.2.4/24 and 1.2.7/24 to send spam etc.




On Tue, Oct 24, 2023 at 8:27 PM Owen DeLong  wrote:

> The covering /20 isn’t his to announce… He has a /22. He’s announcing all
> 4 /24s, and may not have a legitimate place to announce the covering /22,
> which wouldn’t help in this case anyway.
>
> So I’m not sure why you think that’s a solution.
>
> Owen
>
>
> On Oct 22, 2023, at 10:45, Tom Beecher  wrote:
>
> Look again, Tom. This is an attack vector using a LESS specific route. The
>> /22 gets discarded, but a covering /0-/21 would not.
>>
>
> Yes. And reliant on the operator doing something exceptionally not smart
> to begin with.  Relying on an AS0 ROA alone and not actually announcing the
> covering prefix as well isn't a good thing to do.
>
> On Sun, Oct 22, 2023 at 1:39 PM Owen DeLong  wrote:
>
>> Look again, Tom. This is an attack vector using a LESS specific route.
>> The /22 gets discarded, but a covering /0-/21 would not.
>>
>> Owen
>>
>> On Oct 22, 2023, at 10:06, Tom Beecher  wrote:
>>
>> 
>>
>>> And is it your belief that this addresses the described attack vector?
>>> AFAICT, it does not.
>>>
>>
>> Quoting myself :
>>
>> WITH the assertion that all routers in the routing domain are RPKI
>>> enabled, and discarding RPKI INVALIDs.
>>>
>>
>>  In the mixed RPKI / non-RPKI environment of today's internet, no it
>> doesn't. This does not mean that RPKI is deficient, or the AS 0 ROA doesn't
>> work as intended, as was stated.
>>
>>
>>
>> On Sun, Oct 22, 2023 at 12:57 PM William Herrin  wrote:
>>
>>> On Sun, Oct 22, 2023 at 9:38 AM Tom Beecher  wrote:
>>> >> He's saying that someone could come along and advertise 0.0.0.0/1 and
>>> >> 128.0.0.0/1 and by doing so they'd hijack every unrouted address
>>> block
>>> >> regardless of the block's ROA.
>>> >>
>>> >> RPKI is unable to address this attack vector.
>>> >
>>> >
>>> > https://www.rfc-editor.org/rfc/rfc6483
>>> >
>>> > Section 4
>>> >>
>>> >>
>>> >> A ROA with a subject of AS 0 (AS 0 ROA) is an attestation by the
>>> >> holder of a prefix that the prefix described in the ROA, and any more
>>> >> specific prefix, should not be used in a routing context.
>>>
>>> And is it your belief that this addresses the described attack vector?
>>> AFAICT, it does not.
>>>
>>> Regards,
>>> Bill Herrin
>>>
>>>
>>> --
>>> William Herrin
>>> b...@herrin.us
>>> https://bill.herrin.us/
>>>
>>
>

Re: RPKI unknown for superprefixes of existing ROA ?

[Owen DeLong via NANOG]

Yes, but we weren’t talking about an IXP here.

We’re talking about an ISP.

Believe it or not, Job, there are parts of the internet that exchange traffic 
and move packets that are not IXPs.

Owen


> On Oct 22, 2023, at 11:48, Job Snijders via NANOG  wrote:
> 
> On Sun, 22 Oct 2023 at 20:33, Tom Beecher  > wrote:
>>> Basically, I guess, it means that the AS 0 solution shouldn't be used, at 
>>> least not usually.
>> 
>> It's like everything else. Understand what the tools do and what they don't 
>> do, and use them appropriately. 
> 
> 
> A primary risk for an IXP is the existence of a more-specific of the IX 
> peering LAN prefix, a less-specific wouldn’t matter or inflict damage.
> 
> So in the above context an AS 0 ROAs can be useful to improve protection of 
> IXP Peering LANs where the IX operator doesn’t want the fabric to be globally 
> reachable - and one of the IX participants failed to correctly EBGP in/out 
> policies.
> 
> Kind regards,
> 
> Job

Re: RPKI unknown for superprefixes of existing ROA ?

[Owen DeLong via NANOG]

The covering /20 isn’t his to announce… He has a /22. He’s announcing all 4 
/24s, and may not have a legitimate place to announce the covering /22, which 
wouldn’t help in this case anyway.

So I’m not sure why you think that’s a solution.

Owen


> On Oct 22, 2023, at 10:45, Tom Beecher  wrote:
> 
>> Look again, Tom. This is an attack vector using a LESS specific route. The 
>> /22 gets discarded, but a covering /0-/21 would not. 
> 
> Yes. And reliant on the operator doing something exceptionally not smart to 
> begin with.  Relying on an AS0 ROA alone and not actually announcing the 
> covering prefix as well isn't a good thing to do. 
> 
> On Sun, Oct 22, 2023 at 1:39 PM Owen DeLong  > wrote:
>> Look again, Tom. This is an attack vector using a LESS specific route. The 
>> /22 gets discarded, but a covering /0-/21 would not. 
>> 
>> Owen
>> 
>>> On Oct 22, 2023, at 10:06, Tom Beecher >> > wrote:
>>> 
>>> 
 And is it your belief that this addresses the described attack vector?
 AFAICT, it does not.
>>> 
>>> Quoting myself : 
>>> 
 WITH the assertion that all routers in the routing domain are RPKI 
 enabled, and discarding RPKI INVALIDs.
>>> 
>>>  In the mixed RPKI / non-RPKI environment of today's internet, no it 
>>> doesn't. This does not mean that RPKI is deficient, or the AS 0 ROA doesn't 
>>> work as intended, as was stated.
>>> 
>>>  
>>> 
>>> On Sun, Oct 22, 2023 at 12:57 PM William Herrin >> > wrote:
 On Sun, Oct 22, 2023 at 9:38 AM Tom Beecher >>> > wrote:
 >> He's saying that someone could come along and advertise 0.0.0.0/1 
 >>  and
 >> 128.0.0.0/1  and by doing so they'd hijack every 
 >> unrouted address block
 >> regardless of the block's ROA.
 >>
 >> RPKI is unable to address this attack vector.
 >
 >
 > https://www.rfc-editor.org/rfc/rfc6483
 >
 > Section 4
 >>
 >>
 >> A ROA with a subject of AS 0 (AS 0 ROA) is an attestation by the
 >> holder of a prefix that the prefix described in the ROA, and any more
 >> specific prefix, should not be used in a routing context.
 
 And is it your belief that this addresses the described attack vector?
 AFAICT, it does not.
 
 Regards,
 Bill Herrin
 
 
 -- 
 William Herrin
 b...@herrin.us 
 https://bill.herrin.us/

Re: [EXTERNAL] Re: Arelion/Telia AS1299 issues?

[Brendan Halley]

Cogent doesn’t have any peer specific action communities.

Brendan

On Wed, 25 Oct 2023 at 9:01 am, Eric C. Miller  wrote:

> It’s definitely been an annoying day. Cogent’s “don’t advertise to telia”
> BGP community doesn’t work, so we can’t route around this either. Then
> again, my bad for using the “Wal-mart” of the internet.
>
> Eric
>

XGS-PON & "Dedicated" Service

[Neader, Brent]

Hello!

Interested in getting the larger community's thought on this.

The primary question being does XGS-PON have a place in providing a dedicated 
enterprise level service (at least sold as one) in the marketplace?  Delivered 
via a residential (per the data sheet description) CPE, Nokia XS-010X-Q for a 
1gb/1gb dedicated symmetrical service.

Background, ive dealt with 30+ providers over the last 18 years, primarily last 
mile based.  Typically we seek out an Enterprise/Dedicated service, with an 
SLA, typically delivered via DWDM, CWDM, or AE, or equivalent.  We have also 
had a site or two delivered via a PON variant, typically with less of an SLA, 
typically maybe half to quarter of the price of a dedicated service.  Price & 
SLA sets the expectation of the service, CPE provided, underlying technology, 
etc.

Dealing with a large over-builder right now who has an "elite" enterprise 
product (highest of 3 tiers) advertised as the following.


-100% dedicated bandwidth so you never have to compete for speed


-Mission Critical Reliability with 99.999% guaranteed uptime


-Financially backed SLA with the most stringent performance objectives


-Enterprise-level customer service and technical support

Now I understand with XGS, you can have various QOS in place (WRR/SP, etc), but 
inherently there are still shared splits involved, that just aren't a thing in 
other truly dedicated technologies.  Expectations were set with the provider's 
sales team around what was to be delivered and how it was to be delivered that 
seemingly haven't been met by the product and service team.

That aside, from an SP perspective, is it capable to wrap enough layers around 
service to be "dedicated" even when delivered via a conflicting underlying 
technology?  Or could that be considered disingenuous for those that want to 
know and understand the difference?  Im hoping the service itself and support 
team make up for the difference, but obviously a little concerned.

Thanks!

RE: [EXTERNAL] Re: Arelion/Telia AS1299 issues?

[Eric C. Miller]

It’s definitely been an annoying day. Cogent’s “don’t advertise to telia” BGP 
community doesn’t work, so we can’t route around this either. Then again, my 
bad for using the “Wal-mart” of the internet.

Eric

ESPN streaming issues

[Brad Bendy]

Anyone have a contact for ESPN or can someone contact me off list?
Have a good amount of IP space that just started reporting the IP is
out of the country.

Thanks

RingCentral STUN Engineer?

[Stephen M]

Anyone with abilities to view traffic for the STUN servers able to message
me off list?

I have been going back and forth a couple of weeks now doing PCAPs with not
only RingCentral but with Palo Alto on the phone as well showing there is
no return traffic coming from the RC side on call initiations and reviewing
our configurations continually showing the traffic is allowed on our side.
We created explicit in and out rules to define all traffic and no change.

I'm stuck in tier 3 (they have been good though) and they are timid to
escalate up to the STUN engineers to verify but I can't keep doing the same
'its not us' test with them when it is work impacting.

Thanks in advance!

RE: [EXTERNAL] Re: Arelion/Telia AS1299 issues?

[Neader, Brent]

About as ugly as a graph as ive seen!  Reverse path for this site is cogent, 
mtr and forward ISP failing me a bit not returning the transition hop IP I need 
to verify, but im assuming its Arelion.  This site is in the southeast also.

[cid:image001.png@01DA0667.5563C150]

From: NANOG  On Behalf Of 
Steve Feldman
Sent: Tuesday, October 24, 2023 10:37 AM
To: Elmar K. Bins 
Cc: NANOG 
Subject: [EXTERNAL] Re: Arelion/Telia AS1299 issues?

$dayjob has transit from 1299 in Miami. We’ve been seeing packet loss nearby in 
their network since around 06: 00 UTC, still ongoing. Steve > On Oct 24, 2023, 
at 8: 20 AM, Elmar K. Bins  wrote: > > We also observed
ZjQcmQRYFpfptBannerStart
This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.
Report Suspicious  

   ‌
ZjQcmQRYFpfptBannerEnd

$dayjob has transit from 1299 in Miami.  We’ve been seeing packet loss nearby 
in their network since around 06:00 UTC, still ongoing.

 Steve



> On Oct 24, 2023, at 8:20 AM, Elmar K. Bins 
> mailto:e...@4ever.de>> wrote:

>

> We also observed this today, UTC morning, esp. across the pond, and our

> alternative paths from Europe to the US were suffering from the still unfixed

> fibre cut, so I was a bit unhappy with 200 extra ms, and 60% loss.

>

> 1299 seems to've found an alternative path in the meantime, looks good to us.

>

> Elmar.

>

>

> nanog@nanog.org (Andrian Visnevschi via NANOG) wrote:

>

>> We had the same issue with Arelion this morning, a huge increase in the

>> latency and jitter was happening across the US and of course for any

>> traffic sourced from the EU flowing to the US.

>> Within the US we noticed a latency spike from 20-50ms to ~200ms. From the

>> EU to our US facilities, we noticed a spike from  ~130ms to ~400ms.

>>

>>

>> We ended up shifting traffic from Arelion to a different carrier, and will

>> stay there until we are confident that they fixed any issue that they had

>> in their network. To be honest, we've been experiencing quite similar

>> issues with unstable latency on Arelion over the past couple of months, and

>> it's becoming quite frustrating

>>

>>

>>

>>

>> *Andrian Visnevschi*

>>

>> VP of Network & Security

>>

>> +373 68374133

>>

>> andr...@acreto.io | 
>> https://urldefense.com/v3/__https://acreto.io__;!!MQS9YPUatEJj!iZ7j3VWHoxkh3S3Y9nSVzutat2MUlem16ycD6ZkjZEKDIfzdtZuY1hZ8YlspD9zJ_9Go4lCTes737Rtqe1SEPX-_sA$

>>

>>

>>

>>

>> On Tue, Oct 24, 2023 at 6:03 PM David Hubbard 
>> mailto:dhubb...@dino.hostasaurus.com>>

>> wrote:

>>

>>> Hey all, anyone aware of issues with Arelion this morning?  We have a

>>> bunch of end users on at least Cox and Cogeco who are having serious issues

>>> with service access, and the problem appears to be on the return path where

>>> it traverses Arelion.  Source net is Lumen/L3 3356 but loss/latency doesn’t

>>> appear to creep up until already within Arelion’s network.

>>>

>>>

>>>

>>> Imperva mentioned outage/degradation due to a national ISP issue too, so I

>>> suspect it’s affecting more than just certain peerings.

>>>

>>>

>>>

>>> Thanks,

>>>

>>>

>>>

>>> David

>>>

Re: Arelion/Telia AS1299 issues?

[Matt Harris]

I've got a small single-homed site in Central Europe with an Arelion
transit circuit and it had some brief connectivity issues around 0830-0900
Central US time. Cleared up relatively quickly.
Also have connectivity with Arelion in NYC at 60 Hudson, but have not
experienced any issues related to that transit circuit which is part of a
significantly larger multi-homed network.

- mdh


On Tue, Oct 24, 2023 at 10:37 AM Steve Feldman 
wrote:

> $dayjob has transit from 1299 in Miami.  We’ve been seeing packet loss
> nearby in their network since around 06:00 UTC, still ongoing.
>  Steve
>
>
Matt Harris
VP OF INFRASTRUCTURE
Follow us on LinkedIn!
matt.har...@netfire.net
816-256-5446
www.netfire.com
> On Oct 24, 2023, at 8:20 AM, Elmar K. Bins  wrote:
> >
> > We also observed this today, UTC morning, esp. across the pond, and our
> > alternative paths from Europe to the US were suffering from the still
> unfixed
> > fibre cut, so I was a bit unhappy with 200 extra ms, and 60% loss.
> >
> > 1299 seems to've found an alternative path in the meantime, looks good
> to us.
> >
> > Elmar.
> >
> >
> > nanog@nanog.org (Andrian Visnevschi via NANOG) wrote:
> >
> >> We had the same issue with Arelion this morning, a huge increase in the
> >> latency and jitter was happening across the US and of course for any
> >> traffic sourced from the EU flowing to the US.
> >> Within the US we noticed a latency spike from 20-50ms to ~200ms. From
> the
> >> EU to our US facilities, we noticed a spike from  ~130ms to ~400ms.
> >>
> >>
> >> We ended up shifting traffic from Arelion to a different carrier, and
> will
> >> stay there until we are confident that they fixed any issue that they
> had
> >> in their network. To be honest, we've been experiencing quite similar
> >> issues with unstable latency on Arelion over the past couple of months,
> and
> >> it's becoming quite frustrating
> >>
> >>
> >>
> >>
> >> *Andrian Visnevschi*
> >>
> >> VP of Network & Security
> >>
> >> +373 68374133
> >>
> >> andr...@acreto.io | https://acreto.io
> >>
> >>
> >>
> >>
> >> On Tue, Oct 24, 2023 at 6:03 PM David Hubbard <
> dhubb...@dino.hostasaurus.com>
> >> wrote:
> >>
> >>> Hey all, anyone aware of issues with Arelion this morning?  We have a
> >>> bunch of end users on at least Cox and Cogeco who are having serious
> issues
> >>> with service access, and the problem appears to be on the return path
> where
> >>> it traverses Arelion.  Source net is Lumen/L3 3356 but loss/latency
> doesn’t
> >>> appear to creep up until already within Arelion’s network.
> >>>
> >>>
> >>>
> >>> Imperva mentioned outage/degradation due to a national ISP issue too,
> so I
> >>> suspect it’s affecting more than just certain peerings.
> >>>
> >>>
> >>>
> >>> Thanks,
> >>>
> >>>
> >>>
> >>> David
> >>>
>
>

Re: Arelion/Telia AS1299 issues?

[Steve Feldman]

$dayjob has transit from 1299 in Miami.  We’ve been seeing packet loss nearby 
in their network since around 06:00 UTC, still ongoing.
 Steve

> On Oct 24, 2023, at 8:20 AM, Elmar K. Bins  wrote:
> 
> We also observed this today, UTC morning, esp. across the pond, and our
> alternative paths from Europe to the US were suffering from the still unfixed
> fibre cut, so I was a bit unhappy with 200 extra ms, and 60% loss.
> 
> 1299 seems to've found an alternative path in the meantime, looks good to us.
> 
> Elmar.
> 
> 
> nanog@nanog.org (Andrian Visnevschi via NANOG) wrote:
> 
>> We had the same issue with Arelion this morning, a huge increase in the
>> latency and jitter was happening across the US and of course for any
>> traffic sourced from the EU flowing to the US.
>> Within the US we noticed a latency spike from 20-50ms to ~200ms. From the
>> EU to our US facilities, we noticed a spike from  ~130ms to ~400ms.
>> 
>> 
>> We ended up shifting traffic from Arelion to a different carrier, and will
>> stay there until we are confident that they fixed any issue that they had
>> in their network. To be honest, we've been experiencing quite similar
>> issues with unstable latency on Arelion over the past couple of months, and
>> it's becoming quite frustrating
>> 
>> 
>> 
>> 
>> *Andrian Visnevschi*
>> 
>> VP of Network & Security
>> 
>> +373 68374133
>> 
>> andr...@acreto.io | https://acreto.io
>> 
>> 
>> 
>> 
>> On Tue, Oct 24, 2023 at 6:03 PM David Hubbard 
>> wrote:
>> 
>>> Hey all, anyone aware of issues with Arelion this morning?  We have a
>>> bunch of end users on at least Cox and Cogeco who are having serious issues
>>> with service access, and the problem appears to be on the return path where
>>> it traverses Arelion.  Source net is Lumen/L3 3356 but loss/latency doesn’t
>>> appear to creep up until already within Arelion’s network.
>>> 
>>> 
>>> 
>>> Imperva mentioned outage/degradation due to a national ISP issue too, so I
>>> suspect it’s affecting more than just certain peerings.
>>> 
>>> 
>>> 
>>> Thanks,
>>> 
>>> 
>>> 
>>> David
>>> 

Re: Arelion/Telia AS1299 issues?

[Brandon Jackson]

I'm experiencing this in the southeast US region.

Unfortunately, return traffic from a data center that we have a VPN
connection to. Is routed first over Level 3 who is then handing it off to
Arelion in Miami where we then see the 200 to 300 millisecond latency and
50% plus packet loss.

On Tue, Oct 24, 2023, 11:22 Elmar K. Bins  wrote:

> We also observed this today, UTC morning, esp. across the pond, and our
> alternative paths from Europe to the US were suffering from the still
> unfixed
> fibre cut, so I was a bit unhappy with 200 extra ms, and 60% loss.
>
> 1299 seems to've found an alternative path in the meantime, looks good to
> us.
>
> Elmar.
>
>
> nanog@nanog.org (Andrian Visnevschi via NANOG) wrote:
>
> > We had the same issue with Arelion this morning, a huge increase in the
> > latency and jitter was happening across the US and of course for any
> > traffic sourced from the EU flowing to the US.
> > Within the US we noticed a latency spike from 20-50ms to ~200ms. From the
> > EU to our US facilities, we noticed a spike from  ~130ms to ~400ms.
> >
> >
> > We ended up shifting traffic from Arelion to a different carrier, and
> will
> > stay there until we are confident that they fixed any issue that they had
> > in their network. To be honest, we've been experiencing quite similar
> > issues with unstable latency on Arelion over the past couple of months,
> and
> > it's becoming quite frustrating
> >
> >
> >
> >
> > *Andrian Visnevschi*
> >
> > VP of Network & Security
> >
> > +373 68374133
> >
> > andr...@acreto.io | https://acreto.io
> >
> >
> >
> >
> > On Tue, Oct 24, 2023 at 6:03 PM David Hubbard <
> dhubb...@dino.hostasaurus.com>
> > wrote:
> >
> > > Hey all, anyone aware of issues with Arelion this morning?  We have a
> > > bunch of end users on at least Cox and Cogeco who are having serious
> issues
> > > with service access, and the problem appears to be on the return path
> where
> > > it traverses Arelion.  Source net is Lumen/L3 3356 but loss/latency
> doesn’t
> > > appear to creep up until already within Arelion’s network.
> > >
> > >
> > >
> > > Imperva mentioned outage/degradation due to a national ISP issue too,
> so I
> > > suspect it’s affecting more than just certain peerings.
> > >
> > >
> > >
> > > Thanks,
> > >
> > >
> > >
> > > David
> > >
>
>

Re: Arelion/Telia AS1299 issues?

[Elmar K. Bins]

We also observed this today, UTC morning, esp. across the pond, and our
alternative paths from Europe to the US were suffering from the still unfixed
fibre cut, so I was a bit unhappy with 200 extra ms, and 60% loss.

1299 seems to've found an alternative path in the meantime, looks good to us.

Elmar.


nanog@nanog.org (Andrian Visnevschi via NANOG) wrote:

> We had the same issue with Arelion this morning, a huge increase in the
> latency and jitter was happening across the US and of course for any
> traffic sourced from the EU flowing to the US.
> Within the US we noticed a latency spike from 20-50ms to ~200ms. From the
> EU to our US facilities, we noticed a spike from  ~130ms to ~400ms.
>
>
> We ended up shifting traffic from Arelion to a different carrier, and will
> stay there until we are confident that they fixed any issue that they had
> in their network. To be honest, we've been experiencing quite similar
> issues with unstable latency on Arelion over the past couple of months, and
> it's becoming quite frustrating
>
>
>
>
> *Andrian Visnevschi*
>
> VP of Network & Security
>
> +373 68374133
>
> andr...@acreto.io | https://acreto.io
>
>
>
>
> On Tue, Oct 24, 2023 at 6:03 PM David Hubbard 
> wrote:
>
> > Hey all, anyone aware of issues with Arelion this morning?  We have a
> > bunch of end users on at least Cox and Cogeco who are having serious issues
> > with service access, and the problem appears to be on the return path where
> > it traverses Arelion.  Source net is Lumen/L3 3356 but loss/latency doesn’t
> > appear to creep up until already within Arelion’s network.
> >
> >
> >
> > Imperva mentioned outage/degradation due to a national ISP issue too, so I
> > suspect it’s affecting more than just certain peerings.
> >
> >
> >
> > Thanks,
> >
> >
> >
> > David
> >

Re: Arelion/Telia AS1299 issues?

[Andrian Visnevschi via NANOG]

We had the same issue with Arelion this morning, a huge increase in the
latency and jitter was happening across the US and of course for any
traffic sourced from the EU flowing to the US.
Within the US we noticed a latency spike from 20-50ms to ~200ms. From the
EU to our US facilities, we noticed a spike from  ~130ms to ~400ms.


We ended up shifting traffic from Arelion to a different carrier, and will
stay there until we are confident that they fixed any issue that they had
in their network. To be honest, we've been experiencing quite similar
issues with unstable latency on Arelion over the past couple of months, and
it's becoming quite frustrating




*Andrian Visnevschi*

VP of Network & Security

+373 68374133

andr...@acreto.io | https://acreto.io




On Tue, Oct 24, 2023 at 6:03 PM David Hubbard 
wrote:

> Hey all, anyone aware of issues with Arelion this morning?  We have a
> bunch of end users on at least Cox and Cogeco who are having serious issues
> with service access, and the problem appears to be on the return path where
> it traverses Arelion.  Source net is Lumen/L3 3356 but loss/latency doesn’t
> appear to creep up until already within Arelion’s network.
>
>
>
> Imperva mentioned outage/degradation due to a national ISP issue too, so I
> suspect it’s affecting more than just certain peerings.
>
>
>
> Thanks,
>
>
>
> David
>

Arelion/Telia AS1299 issues?

[David Hubbard]

Hey all, anyone aware of issues with Arelion this morning?  We have a bunch of 
end users on at least Cox and Cogeco who are having serious issues with service 
access, and the problem appears to be on the return path where it traverses 
Arelion.  Source net is Lumen/L3 3356 but loss/latency doesn’t appear to creep 
up until already within Arelion’s network.

Imperva mentioned outage/degradation due to a national ISP issue too, so I 
suspect it’s affecting more than just certain peerings.

Thanks,

David

Re: Low to Mid Range DWDM Platforms

[Collin Rose]

Sorry for the late response, but I can speak about the FS M6200 product. We 
have been using the 10GOEO card for 10G DWDM/WDM on a span. The hardware works 
reasonably well though we had to reseat a card once in the last 18 months or so 
of operation. It also seems to be a bit finicky when you first install a new 
card. Their support had us slot/reslot and move around a few times before 
things started working as expected. My biggest complaint is that the ONLY way 
to manage the box is through the EMS system, which must be installed on a 
windows OS. It has an embedded apache server that provides the interface, so it 
doesn’t have to run on windows server. The EMS uses SNMP for all the 
configuration of the hardware itself. We figured out how to do some basic 
things like change the IP using snmp, but besides, that there is no way to 
manage it without connectivity back to the EMS, no CLI, no internal web 
interface, etc.

Collin R



From: NANOG  on behalf of Mike 
Hammett 
Date: Friday, October 6, 2023 at 5:43 PM
To: David Bass 
Cc: nanog@nanog.org 
Subject: Re: Low to Mid Range DWDM Platforms
Well, and that's kinda where I was going.

I've used FS passive systems for years. FS has an active platform or two (that 
I understand, they just whitebox). Does it really do everyone one would need to 
do? How much of a step is it to get something more?


-
Mike Hammett
Intelligent Computing Solutions
[Image removed by sender.][Image removed by 
sender.][Image 
removed by 
sender.][Image
 removed by sender.]
Midwest Internet Exchange
[Image removed by sender.][Image removed by 
sender.][Image 
removed by sender.]
The Brothers WISP
[Image removed by sender.][Image 
removed by sender.]

From: "David Bass" 
To: "Dave Bell" 
Cc: nanog@nanog.org
Sent: Friday, October 6, 2023 8:55:21 AM
Subject: Re: Low to Mid Range DWDM Platforms
On the same topic, anyone have experience with the stuff from 
fs.com?

On Fri, Oct 6, 2023 at 9:53 AM Dave Bell 
mailto:m...@geordish.org>> wrote:
Smartoptics?

https://smartoptics.com/

Regards,
Dave

On Fri, 6 Oct 2023 at 14:43, Mark Tinka  wrote:


On 10/6/23 15:07, Mike Hammett wrote:

> I've been using various forms of passive WDM for years. I have a couple 
> different projects on my plate that require me to look at the next level of 
> platform.
>
> In some projects, I'll be looking for needing to have someone long distances 
> of glass without any electronics. Some spans could be over 60 miles.
>
> In some projects, I'll need to transport multiple 100-gig waves.
>
> What is the landscape like between basic passive and something like a 30 
> terabit Ciena? I know of multiple vendors in that space, but I like to learn 
> more about what features I need and what features I don't need from somewhere 
> other than the vendor's mouth. Obviously, the most reliability at the least 
> cost as well.

400G-ZR pluggables will get you 400Gbps on a p2p dark fibre over 80km -
100km. So your main cost there will be routers that will support.

The smallest DCI solution from the leading DWDM vendors is likely to be
your cheapest option. Alternatively, if you are willing to look at the
open market, you can find gear based on older CMOS (40nm, for example),
which will now be EoL for any large scale optical network, but cost next
to nothing for a start-up with considerable capacity value.

There is a DWDM vendor that showed up on the scene back in 2008 or
thereabouts. They were selling a very cheap, 1U box that had a different
approach to DWDM from other vendors at the time. I, for the life of me,
cannot remember their name - but I do know that Randy introduced them to
me back then. Maybe he can remember :-). Not sure if they are still in
business.

Mark.