Re: Alien waves

[Saku Ytti]

Hey,

Does anyone have a comprehensive (or any) list of carriers doing alien
> wavelengths? (background:
> https://thecinict.com/2021/03/05/adding-alien-wavelengths/
> https://www.ekinops.com/solutions/optical-transport/alien-wavelength )
>

> Emphasis on subsea operators.
>

I'm going to hazard a guess that the exhaustive list is empty. Allowing 3rd
parties to launch alien waves to your system puts your existing waves at
the mercy of the 3rd party, power or lack thereof from the alien wave may
impact operation of other waves.

-- 
  ++ytti

Alien waves

[Lady Benjamin Cannon of Glencoe, ASCE]

Does anyone have a comprehensive (or any) list of carriers doing alien 
wavelengths? (background: 
https://thecinict.com/2021/03/05/adding-alien-wavelengths/ 
https://www.ekinops.com/solutions/optical-transport/alien-wavelength )

Emphasis on subsea operators.
—L.B.

Ms. Lady Benjamin PD Cannon of Glencoe, ASCE
6x7 Networks & 6x7 Telecom, LLC 
CEO 
l...@6by7.net 
"The only fully end-to-end encrypted global telecommunications company in the 
world.”
FCC License KJ6FJJ

Re: A crazy idea

[Chriztoffer Hansen]

On Tue, 20 Jul 2021 at 17:41, Bryan Fields  wrote:
> On 7/20/21 10:01 AM, Michael Loftis wrote:
> > My apologies to everyone using an HTML mail client.
>
> No reason to apologize for that.  If someone is careless enough to use an HTML
> client on a mailing list, they deserve what they get :-D

Enable the setting in Mailman to enforce plain-text E-mail delivery
from the list address?

Re: A crazy idea

[Bryan Fields]

On 7/20/21 10:01 AM, Michael Loftis wrote:
> My apologies to everyone using an HTML mail client.

No reason to apologize for that.  If someone is careless enough to use an HTML
client on a mailing list, they deserve what they get :-D

-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

Re: A crazy idea

[Michael Loftis]

On Tue, Jul 20, 2021 at 7:48 AM Michael Loftis  wrote:
>
> (Reply in-line)

My apologies to everyone using an HTML mail client.  Don't try in-line
replies with Google's iOS app.  *sigh*  Really, it's not a blank
reply...

The gist of my reply was.   Don't complain about DNS services when
you're not paying for DNS services.  register.com, godaddy, those are
registrars.  Go look for a managed DNS/authoritative DNS service
provider and almost any of them will happily accept a reverse DNS zone
delegation.  And for IPv4 less-than-boundary (well..I guess you could
use it for v6, but v6 should NEVER be on a less than boundary) see
RFC2317.

Again.  Apologies.  Honestly, it was my mail client that did it! :)

Re: A crazy idea

[Michael Loftis]

(Reply in-line)

On Mon, Jul 19, 2021 at 06:11 Stephen Satchell  wrote:

> First, I know this isn't the right place to propose this; need a pointer
> to where to propose an outlandish idea.
>
> PROBLEM:  IPv6 support is still in its birthing pangs.  I see a problem
> that limits deployment of IPv6 fully:  reverse PTR records in the
> ".in6.arpa." zones.
>
> (Now that I think about it, this may very well be a network operator
> issue.  Who maintains the ".in.arpa." zones delegated by IANA now?)
>
> I've been going 'round and 'round with AT about "static" IPv6
> addresses.  In particular, I can't get a PTR record in the ip6.arpa.
> zone to save my life.  Now, the problem is not really ripe yet, because
> the big reason for PTR records is for mail servers -- best practice
> calls for /PTR agreement, just like for IPv4 the best practice is
> for A/PTR agreement.
>
> The existing DNS providers can support delegation domains, so that I
> don't have to have DNS servers of my own if I don't want to.  It could
> be that one would need to "buy" the delegation domain, but that's a
> front-office consideration.  Personally, I use register.com for my
> domain DNS zones.  I believe strongly that other registrars that offer
> customer zone editing, plus DNS service providers, can support reverse
> delegation zones with a minimum of hassle, and without charging an arm
> and a leg for the service.


They’re not a DNS service provider. That is a registrar. Providing
authoritative DNS is incidental to their business and not their focus. Go
look for managed DNS or authoritative DNS services. There’s still the
problem of getting the  delegation which is largely unsupported for
consumer IP services. And honestly…I don’t really expect consumer (dynamic)
IP services to provide reverse delegation.  Business (definitely needs to)
and static IP services (really should) should provide either delegation of
the reverse zone or PTRs for non boundary ipv4 space per RFC2317.


 From the customers' viewpoint, a GUI would make the maintenance
> relatively painless.
>
> (Keying the information below took a long time.  Any rational DNS admin
> and DNS service provider would have automation in place to take out the
> painful work.)




>
>  > 96-103.194.65.99.in-addr.arpa. NS my-DNS-server-1
>  > 96-103.194.65.99.in-addr.arpa. NS my-DNS-server-2> $GENERATE 96-102 $
> IN CNAME $.96-103.194.65.99.in-addr.arpa.
>
> In my BIND9 zone file, it would look something like this:
>
> > $ORIGIN 96-103.194.65.99.in-addr.arpa.
> > @ SOA ...
> > @ NS my-dns-server-1.
> > @ NS my-dns-server-2.
> > 96 IN PTR server1.example.com.
> > 97 IN PTR server2.example.com.
>

See RFC2317.

>
> The advantage to this system to the number providers is they would have
> one administrative record per customer, instead of having to deal with
> each PTR record individually.  The advantage to customers is they don't
> have to beg and snivel to get PTR records, just beg and snivel once to
> get the delegation.  The advantage to DNS server providers is they have
> something else to sell.
>
> Want to encourage IPv6 adoption?  This would help.




> --

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler

RE: 100G, input errors and/or transceiver issues

[Kevin Menzel via NANOG]

Hey Graham,



We're running 6xDWDM PAM4 100G links currently (for approx. 24 months) - I just 
pulled up our 13 month statistics, and we've had less than 100 input errors 
across every link total across that time period.



Every single input error seems to correspond to a fibre cut/flap - I've seen an 
unprecedented 11 input errors total this month on one link. I'd note that “post 
covid economic reopening” has meant “run lots of construction equipment through 
fibre optic cables” and that's caused us more issues than any optic or 
interface has.



For reference, we're a Cisco/SmartOptics shop, and our links aren't super long 
distance - ~40-60km, nothing that would require coherent optics.



  *   Kevin Menzel

On July 19, 2021 13:19, Graham Johnston 
mailto:johnston.grah...@gmail.com>> wrote:

Saku,

I don't at this point have long term data collection compiled for the issues 
that we've faced. That said, we have two 100G transport links that have a 
regular background level of input errors at ranges that hover between 0.00055 
to 0.00383 PPS on one link, and none to 0.00135 PPS (that jumped to 0.03943 PPS 
over the weekend). The range is often directionally associated rather than 
variable behavior of a single direction. The data comes from the last 24 hours, 
the two referenced links are operated by different providers on very different 
paths (opposite directions). Over shorter distances, we've definitely seen 
input errors that have affected PNI connections within a datacenter as well. In 
the case of the last PNI issue, the other party swapped their transceiver, we 
didn't even physically touch our side; I note this only to express that I don't 
think this is just a case of the transceivers that we are sourcing.

Comparatively, other than clear transport system issues, I don't recall this 
sort of thing at all with 10G "wavelength" transport that we had purchased for 
years prior. I put wavelengths in quotes there knowing that it may have been a 
while since our transport was a literal wavelength as compared to being muxed 
into a 100G+ wavelength.

On Mon, 19 Jul 2021 at 12:01, Saku Ytti mailto:s...@ytti.fi>> 
wrote:
On Mon, 19 Jul 2021 at 19:47, Graham Johnston
mailto:johnston.grah...@gmail.com>> wrote:

Hey Graham,

> How commonly do other operators experience input errors with 100G interfaces?
> How often do you find that you have to change a transceiver out? Either for 
> errors or another reason.
> Do we collectively expect this to improve as 100G becomes more common and 
> production volumes increase in the future?

New rule. Share your own data before asking others to share theirs.

IN DC, SP markets 100GE has dominated the market for several years
now, so it rings odd to many at 'more common'. 112G SERDES is shipping
on the electric side, and there is nowhere more mature to go from
100GE POV. The optical side, QSFP112, is really the only thing left to
cost optimise 100GE.
We've had our share of MSA ambiguity issues with 100GE, but today
100GE looks mature to our eyes in failure rates and compatibility. 1GE
is really hard to support and 10GE is becoming problematic, in terms
of hardware procurement.


--
  ++ytti

Re: 100G, input errors and/or transceiver issues

[Lady Benjamin Cannon of Glencoe, ASCE]

We... don’t see anything like this... on the transport side, FEC is more than 
sufficient to effectively eliminate errors.   On the LAN side, check your 
connections.

Reiterating that this is not normal or expected behavior.
—L.B.

Ms. Lady Benjamin PD Cannon of Glencoe, ASCE
6x7 Networks & 6x7 Telecom, LLC 
CEO 
l...@6by7.net 
"The only fully end-to-end encrypted global telecommunications company in the 
world.”
FCC License KJ6FJJ



> On Jul 19, 2021, at 10:19 AM, Graham Johnston  
> wrote:
> 
> Saku,
> 
> I don't at this point have long term data collection compiled for the issues 
> that we've faced. That said, we have two 100G transport links that have a 
> regular background level of input errors at ranges that hover between 0.00055 
> to 0.00383 PPS on one link, and none to 0.00135 PPS (that jumped to 0.03943 
> PPS over the weekend). The range is often directionally associated rather 
> than variable behavior of a single direction. The data comes from the last 24 
> hours, the two referenced links are operated by different providers on very 
> different paths (opposite directions). Over shorter distances, we've 
> definitely seen input errors that have affected PNI connections within a 
> datacenter as well. In the case of the last PNI issue, the other party 
> swapped their transceiver, we didn't even physically touch our side; I note 
> this only to express that I don't think this is just a case of the 
> transceivers that we are sourcing.
> 
> Comparatively, other than clear transport system issues, I don't recall this 
> sort of thing at all with 10G "wavelength" transport that we had purchased 
> for years prior. I put wavelengths in quotes there knowing that it may have 
> been a while since our transport was a literal wavelength as compared to 
> being muxed into a 100G+ wavelength.
> 
> On Mon, 19 Jul 2021 at 12:01, Saku Ytti mailto:s...@ytti.fi>> 
> wrote:
> On Mon, 19 Jul 2021 at 19:47, Graham Johnston
> mailto:johnston.grah...@gmail.com>> wrote:
> 
> Hey Graham,
> 
> > How commonly do other operators experience input errors with 100G 
> > interfaces?
> > How often do you find that you have to change a transceiver out? Either for 
> > errors or another reason.
> > Do we collectively expect this to improve as 100G becomes more common and 
> > production volumes increase in the future?
> 
> New rule. Share your own data before asking others to share theirs.
> 
> IN DC, SP markets 100GE has dominated the market for several years
> now, so it rings odd to many at 'more common'. 112G SERDES is shipping
> on the electric side, and there is nowhere more mature to go from
> 100GE POV. The optical side, QSFP112, is really the only thing left to
> cost optimise 100GE.
> We've had our share of MSA ambiguity issues with 100GE, but today
> 100GE looks mature to our eyes in failure rates and compatibility. 1GE
> is really hard to support and 10GE is becoming problematic, in terms
> of hardware procurement.
> 
> 
> -- 
>   ++ytti

Re: 100G, input errors and/or transceiver issues

[Baldur Norddahl]

You could also enable FEC on the link. This will remove any errors until
the link quality is really far gone.

Regards

Baldur


man. 19. jul. 2021 20.06 skrev Graham Johnston :

> Thank you all for the consensus. What I hear from you is that 100G takes
> more care to operate error free, as compared to 10G, which wasn't
> surprising to me. Also, that generally, we should be able to operate
> without errors, or certainly less than I'm currently observing, and that
> connector and transceiver interface cleanliness is our first likely point
> of investigation.
>
> Thanks to all who responded.
>
> On Mon, 19 Jul 2021 at 12:58, Jared Mauch  wrote:
>
>>
>>
>> > On Jul 19, 2021, at 1:50 PM, Saku Ytti  wrote:
>> >
>> > On Mon, 19 Jul 2021 at 20:19, Graham Johnston
>> >  wrote:
>> >
>> >> I don't at this point have long term data collection compiled for the
>> issues that we've faced. That said, we have two 100G transport links that
>> have a regular background level of input errors at ranges that hover
>> between 0.00055 to 0.00383 PPS on one link, and none to 0.00135 PPS (that
>> jumped to 0.03943 PPS over the weekend). The range is often directionally
>> associated rather than variable
>> >
>> > On typical 100G link we do not get single FCS error in a typical day.
>> > However Ethernet spec still allows very high error rate of 10**-12. So
>> > 1 error per 1Tb (b not B). I.e. 1 error per 10s, or 0.1PPS would be
>> > in-spec. We see much better performance to this and vendors generally
>> > accept lower error rates as legitimate errors.
>> >
>>
>> I will confirm my experience with this at $dayjob as well.  We see
>> interfaces with no errors over much longer periods of time inclusive of
>> several of the technology options.  If you are seeing errors, there’s
>> likely something wrong like unclean fiber or bad optic/linecard etc.
>>
>> - Jared
>>
>>