On 10/29/20 19:12, colin johnston wrote:
Hey Mark,
Good shout with debug, same issue seen on MacBook Air with Catalina
10.15.6 beta, pings upto 150ms seen
iMac with Sierra zero jitter and usually sub 1m pings
Now need to find out why, I never noticed as wife using the MacBook Air :(
I cant
On 10/29/20 18:05, Blake Hudson wrote:
On the latest Catalina 10.15.7 from a MacBook Air (early 2014) via
WiFi to Google Wifi Mesh router (only a single unit network):
Over 2.4Ghz through 3 interior walls:
--- 192.168.86.1 ping statistics ---
100 packets transmitted, 100 packets received,
On 10/29/20 16:08, J. Hellenthal wrote:
I believe I have seen the same thing with a Mid 2015 11,4 running catalina. Not
diagnosing further because I could not find a reason for it fast enough and not
sure if it really had an impact at the moment…. but could you try the following
sudo
On 10/29/20 15:04, Cory Sell wrote:
Might be worth disabling each AP to see if there's one out there
having an issue playing nice with the MacBook. Also try different
combinations of two APs working together. It's possible the MacBook is
flip flopping because the power levels are fighting
On 10/29/20 14:40, Jared Mauch wrote:
I know there was a recent fix Apple did for devices talking to UBNT APs
for their handsets, perhaps there's a similar fix needed on your side?
I have all UBNT at home for wireless and periodically have some random
issues which I can't
On 10/29/20 14:37, Mike Hammett wrote:
Have you ruled out local wireless issues, such as a literal
side-by-side test?
Yes - all other wi-fi devices don't exhibit this issue, including my
wireless-connected PC. Only this MacBook running Catalina.
The problem exists at all wi-fi AP's
On 10/29/20 14:27, Matt Hoppes wrote:
Is it actually jitter or is it potentially the wireless network card
going into sleep mode? I have seen that type of behavior on Apple
products when the cards go into low power mode although I can’t say I
have noticed that on my laptop.
Not, not
2.5 232.1 54.9
Mark.
On 10/29/20 14:07, Mark Tinka wrote:
Hi all.
I've been on High Sierra for several years now due to a limitation
with an app that couldn't deal with Apple's latest rounds of system
permissions since Mojave. Eventually, I gave up on waiting for them to
fix
Hi all.
I've been on High Sierra for several years now due to a limitation with
an app that couldn't deal with Apple's latest rounds of system
permissions since Mojave. Eventually, I gave up on waiting for them to
fix it and upgraded my older Butterfly keyboard laptop to Catalina 4
weeks
On 11/Sep/20 20:58, Hunter Fuller wrote:
Hey Mark, I am here. At 10364 we have 7 network people, 3 of whom have
an understanding of BGP deeper than surface level. We have 3 peers and
2 transit providers total.
When we go to implement external-facing BGP policy, the #1 concern is
"What are
On 22/Sep/20 00:06, Greg Shepherd wrote:
Call me old, but I miss the days when this thread was still on the SRv6 rails.
Can we get back the proper bashing to match this thread title?
Probably not off-topic, since vendors may push SRv6 as a(n) (MPLS) VPN
replacement and new money-maker
On 21/Sep/20 12:47, Łukasz Bromirski wrote:
NANOGers,
Have you got email from 'dating.supp...@csvwebsupport.com’ immediately
after you post to nanog@? First time I thought it’s coincidence, but
today when I got it, it’s hardly one ;)
Topic is '[#WHB-257-41491]: Re: XX’ where is
On 19/Sep/20 22:53, Valdis Kl ē tnieks wrote:
Are there any actual countries heading that way? Seems like most of them insist
they have the ability to snoop unencrypted traffic (where "crypto that has a
baked-in
back door" counts as unencrypted).
Let's not give them a reason.
The most
On 19/Sep/20 05:56, mark seery wrote:
While I get your point, and it is a good one, no. Once lawyers, finance, and
other functions get involved, it goes from being just another technology, to a
pain for suppliers and customers alike. Export laws complicate implementation,
and vendors can
On 18/Sep/20 11:40, t...@pelican.org wrote:
I've got MACSec deployed for exactly one customer as a point solution. It
works once it's in, but the documentation, vendor or otherwise, and choice of
suitable equipment were fairly sparse. I certainly wouldn't want to offer it
at scale.
On 17/Sep/20 19:36, mark seery wrote:
Private line was a common term for leased lines. Leased lines were not
encrypted by the operator, AFAIK. This terminology morphed to virtual
private line, Ethernet Private Line, virtual private LAN service
(VPLS), etc.
"In telecommunication, a
On 17/Sep/20 17:56, mark seery wrote:
For operators already offering FR/ATM services, it was a replacement, using the
same principles of traffic separation over a common infrastructure, without
encryption as part of the service. So from that perspective only, it was not
much of a change
On 17/Sep/20 01:30, Łukasz Bromirski wrote:
And that’s fine. The fact that some Intellectual Property[1] was created
by one vendor or another (disclaimer - I work for Cisco) shouldn’t be
by default something that discredits the idea. And BTW, if You look into
the history of how SR started,
On 16/Sep/20 23:22, Anoop Ghanwani wrote:
It depends on the definition of VPN. In terms of services like
MPLS-based VPNs, it refers to the extension of a Private network
over a shared infrastructure, allowing entities using the shared
infrastructure to have their own private address space
On 16/Sep/20 02:05, Randy Bush wrote:
> neither srv6, srmpls, mpls, gre, ... provide privacy. they all
> transport the payload in nekkid cleartext.
C'mon, Randy. Don't tell the kids Santa isn't real. Where's your
humanity :-)...
Mark.
On 15/Sep/20 21:07, Nick Hilliard wrote:
> This gets complicated quickly, and that complication can only be
> solved by adding complication to silicon, which is what you want not
> to do when the speed of your underlying forwarding plane is increasing
> by leaps and bounds. Good, cheap, fast.
On 15/Sep/20 20:57, James W. Laferriere wrote:
>
>
> So then here we are back at the older days of hard wired devices
> configured on site by vendor 'X' to do what buyer 'Y' was told it
> would do .
> And Buyer 'Y' is still wondering WHEN it will be that kitchen sink
> it ordered .
On 15/Sep/20 20:12, Randy Bush wrote:
>
> as the packet payload is nekkid cleartext, where is the P in vpn?
On a piece of paper filed under "It feels good to know it sort of does
the same thing" :-).
Mark.
On 15/Sep/20 19:05, Saku Ytti wrote:
> Ultimately it is very simple, we need tunneling, then the question is
> how much does it cost to look up those tunnel headers and how much
> space they take on the wire (relevant for overspeed), everything else
> is noise.
As we've said many times
On 15/Sep/20 19:00, aar...@gvtc.com wrote:
> Sorry guys, I'm not aware of much of what you mention as far as agenda,
> vendor motive, and hardware support, etc
I'm not shy... this would be Cisco.
And somehow, they've managed to "convince" other vendors to go down this
rabbit hole,
On 15/Sep/20 11:53, Saku Ytti wrote:
> I think SRv6 is an
> abomination, it is complex SW, and very complex HW, because it exists.
> We pay the premium to add HW support for it.
And that is what the vendor(s) pushing this hope operators "realize"...
that SRv6 is a complex mess that needs some
On 15/Sep/20 11:11, Nick Hilliard wrote:
>
> yep, and you're not alone - the complexity level is pretty high, right
> from the control plane to the hardware.
>
> It's not clear that the modest net gain in functionality is worth it.
Well, we know who's pushing this agenda, and why...
Here's
On 14/Sep/20 22:42, aar...@gvtc.com wrote:
> Oh snap! Hey hey, that's good, thanks Nick. I had to go into the locator
> service of the remote pe and find a sid that would respond to ping.
>
> This is apparently an OAM Endpoint with Punt (End.OP)
>
>
On 10/Sep/20 21:09, aar...@gvtc.com wrote:
> Thanks for the heads up Mark... I see docs showing SRv6 not supported until
> XR 6.6, I put XR7 in my lab to start testing it...
I wasn't talking about SRv6... I am talking about SR-MPLS, signaled via
and supported for IPv6, in the IGP.
Mark.
On 10/Sep/20 10:40, Jeff Tantsura wrote:
> MPLS data plane could be instantiated over either IPv4 or IPv6
> (similarly to LDP6),
Be mindful of sketchy (or non-existent) IPv6 support in SR for IS-IS and
OSPF across all vendors.
Mark.
On 9/Sep/20 17:42, Robert Raszuk wrote:
>
> It's not about numbers ... it's about ability to uniformly express
> policy with chain of arguments.
>
> See even with large communities you can define a policy with an
> unstructured parameter and single action then you need to put it on
> all of
On 9/Sep/20 17:52, Mike Hammett wrote:
> No, but most network operators also aren't NANOG members, attend NANOG
> shows, subscribe to NANOG lists.
>
> They're small outfits where there's between 1 - 5 total networking people.
Yeah, I'll steer clear of that one :-)...
>
> Circling back to
On 9/Sep/20 15:25, Robert Raszuk wrote:
> That's not quite true.
>
> See the entire idea behind defining a common mechanism for signalling
> policy in communities in a flexible way for both intra and
> inter-domain use is to help you to use the same encoding acros policy
> engines of many
On 9/Sep/20 15:09, Mike Hammett wrote:
> If history has taught us anything, everything we do will be ignored by
> those that most need it. :-)
Touche :-)...
Mark.
On 9/Sep/20 15:06, Mike Hammett wrote:
> More operators don't use communities internally than the number of
> operators that do.
Do you have some empirical data on that?
I don't know if it's more, or less. But as Charlton Heston said in "True
Lies":
"So far this is not blowing my skirt up,
On 9/Sep/20 14:29, Chriztoffer Hansen wrote:
> Why not? As a service offering, it makes total sense.
Yes, makes total sense.
So why aren't jumping all over it?
>
> Thou, generally I agree with you. Trust, but verify any received
> announcement conforms to a base-set of expectations.
Midwest-IX
> http://www.midwest-ix.com
>
> ----
> *From: *"Mark Tinka"
> *To: *"Mike Hammett"
> *Cc: *nanog@nanog.org
> *Sent: *Wednesday, September 9, 2020 6:47:13 AM
> *Subject: *Re: BG
On 9/Sep/20 13:41, Mike Hammett wrote:
> How is that any different than any other network with minimal
> connectivity (say a non-ISP such as a school, medium business, local
> government, etc.)?
Because the existing flexibility of dis-aggregated BGP community design
can be done without any need
On 9/Sep/20 10:03, Jeff Tantsura via NANOG wrote:
> De-facto standards are as good as people implementing them, however in
> order to enforce non ambiguous implementations, it has to be de-jure
> (e.g. a standard track RFC).
> While I’m sympathetic to the idea, I’m quite skeptical about its
>
On 9/Sep/20 09:21, Robert Raszuk wrote:
> Nope .. it is the other way around.
>
> It is all easy if you look from your network centric view.
>
> But if I am connected to 10 ISPs in each POP I have to build 10
> different egress policies, each embedding custom policy, teach NOC to
> understand
On 9/Sep/20 09:15, Robert Raszuk wrote:
> On last point yes. The entire idea behind flow spec is to work
> inter-as to mitigate DDoS as close to a source as possible.
Indeed, that is the original intention. Any reason why we don't see it
happening in this way, today?
> And as far as wide
On 8/Sep/20 23:22, Douglas Fischer via NANOG wrote:
> Exactly Mike!
>
> The Idea would be to define some base levels, to make the creations of
> route-filtering simpler to everyone in the world.
> And what comes beyond that, is in charge of each autonomous system.
>
> It would make the
On 8/Sep/20 22:02, Tom Beecher via NANOG wrote:
> I also get that intent from the OP. However I disagree that there
> should be a 'de facto' standard created for such things. All flavors
> of BGP community specifications are designed to be flexible so that
> different networks can design a
On 8/Sep/20 20:35, Mike Hammett via NANOG wrote:
> How I see the OP's intent is to create a BCP of what defined
> communities have what effect instead of everyone just making up
> whatever they draw out of a hat, simplifying this process for everyone.
Which only matters if you are extending a
On 8/Sep/20 20:15, Robert Raszuk wrote:
> This does not require any more trust for say directly connected peers
> more then today when you publish communities on the web page.
I'd tend to disagree.
Trusting your direct peer to not send you default or to have a 24/7 NOC
to handle connectivity
On 8/Sep/20 18:41, Robert Raszuk wrote:
> I don't think this is the ask here.
>
> Today NO_EXPORT takes no parameters. I think it would be of benefit to
> all to be able to signal NO_EXPORT TO ASN_X in a common (std) way
> across all of my peers connected to ASN_X. Moreover policy on all
>
On 8/Sep/20 17:55, Douglas Fischer via NANOG wrote:
> Most of us have already used some BGP community policy to no-export
> some routes to some where.
>
> On the majority of IXPs, and most of the Transit Providers, the very
> common community tell to route-servers and routers "Please do
>
On 5/Sep/20 18:46, Randy Bush via NANOG wrote:
> fracking dmark illegal header hacking :(
>
> apologies
No worries :-).
Mark.
On 5/Sep/20 17:58, Randy Bush via NANOG wrote:
> spoken like a tier two
Even "Tier 1's" aren't present everywhere :-)...
Although I'm not sure whether having presence in every city means you
are a Tier-anything either...
Mark.
On 4/Sep/20 23:41, Tomas Lynch wrote:
>
> Oh, yes! Let's not start another "what's a tier one" war!
Oh no, let's :-).
We get over here in Africa as well. Local operators either calling
themselves Tier 1, or being called a Tier 1. Nonsensical.
Years back, our Marketing team asked me to
On 3/Sep/20 22:20, aar...@gvtc.com wrote:
> Thanks, how do I see the control plane reservation? I don’t seem to
> be seeing anything getting allocated
>
>
>
> RP/0/0/CPU0:r20#sh rsvp interface g0/0/0/1
>
> Thu Sep 3 15:15:55.825 CST
>
>
>
> *: RDM: Default I/F B/W % : 75% [default] (max
On 31/Aug/20 17:57, Bryan Holloway wrote:
> Not everyone will peer with you, notably, AS3356 (unless you're big
> enough, which few can say.)
I think Tomas meant more diverse peering, not peering with CL.
Mark.
On 3/Sep/20 17:54, Rubens Kuhl wrote:
> The outage that happened, while long, was the type that every big
> enough infrastructure will face one day or another.
This is probably the most sage piece of advice.
None of us are immune to this occurrence, regardless of size. Our only
hope is that
On 3/Sep/20 17:54, Rubens Kuhl wrote:
> The outage that happened, while long, was the type that every big
> enough infrastructure will face one day or another.
This is probably the most sage piece of advice.
None of us are immune to this occurrence, regardless of size. I our only
hope is
On 2/Sep/20 15:12, Baldur Norddahl wrote:
> I am not buying it. No normal implementation of BGP stays online,
> replying to heart beat and accepting updates from ebgp peers, yet
> after 5 hours failed to process withdrawal from customers.
A BGP RFC spec. is not the same thing as a vendor
On 2/Sep/20 13:36, Mike Hammett wrote:
> Sure, but I don't care how busy your router is, it shouldn't take
> hours to withdraw routes.
If only routers had feelings...
Mark.
On 2/Sep/20 05:53, Alain Hebert wrote:
>
> Beat installing a Cisco 12k solo with 2x4's to align the mounting
> holes...
I still have those in a rack somewhere, trapping air, if you want to
test that :-)...
Mark.
On 31/Aug/20 16:33, Tomas Lynch wrote:
> Maybe we are idealizing these so-called tier-1 carriers and we,
> tier-ns, should treat them as what they really are: another AS. Accept
> that they are going to fail and do our best to mitigate the impact on
> our own networks, i.e. more peering.
On 30/Aug/20 17:20, Matt Hoppes wrote:
> No clue. They’ve been progressively getting worse since 2010. I have no idea
> why anyone chooses them and they shouldn’t be considered a Tier1 carrier with
> the level of issues they have.
For us, the account management took a turn for the worse
On 30/Aug/20 17:15, vidister via NANOG wrote:
> Operating a CDN inside a Tier1 network is just shitty behaviour.
What's a Tier 1 network :-)?
Mark.
On 27/Aug/20 15:38, Mike Hammett wrote:
> Another approach (not likely to be any more successful than others
> mentioned) is to get the tech journalists to understand and write
> about the issues. That has the greatest chance of amplifying the
> message, but also given the poor quality of
On 27/Aug/20 10:33, Brian Johnson wrote:
> Let’s say that we switch to a model of all NAT444 for IPv4, with an exception
> for paid static IPv4 customers and that rate is linked to the current going
> rate for an IP address on the market. :)
>
> This is easily doable with any of the access
On 27/Aug/20 09:33, Brian Johnson wrote:
> If an ISP provides dual-stack to the customer, then the customer only uses
> IPv4 when required and then will only use NAT444 to compensate for a lack of
> IPv4 address space when an IPv4 connection is required. What am I missing?
While modern OS's
On 27/Aug/20 08:57, JORDI PALET MARTINEZ via NANOG wrote:
> This one is the published version:
>
> https://datatracker.ietf.org/doc/rfc8683/
Good man.
NAT64/DNS64 is broken. I found this out myself in 2011 when I deployed
it at $old_job in Malaysia. Skype broke, as did IPv4 literals.
At the
On 27/Aug/20 07:58, Bjørn Mork wrote:
> Because NAT64 implies DNS64, which avoids NATing any dual stack service.
> This makes a major difference today.
NAT64/DNS64 was the original solution.
464XLAT is the improved approach.
See:
On 26/Aug/20 22:23, JORDI PALET MARTINEZ via NANOG wrote:
> Maybe the only way to force this is to tell our customers (many ISPs in every
> country) "don't buy Sony PS, they are unable to support new technologies, so
> you games will be blocked by Sony". Of course, unless we all decide to
On 26/Aug/20 22:12, JORDI PALET MARTINEZ wrote:
> And the PS developers missed by themselves all about IPv6. Furthermore, I
> still see some game makers *encouraging customers* to disable IPv6. I call
> this a *criminal action*.
Most developers do not understand the constraints the industry
On 26/Aug/20 21:14, Brian Johnson wrote:
> I can prove, as an ISP, that I am delivering the packets. Many providers will
> have to do this until the content moves to IPv6, so what will their excuse
> be? The provider has no choice when they have more customers than IPv4
> address space.
On 26/Aug/20 20:38, Brian Johnson wrote:
> I‘m going further... They shouldn’t have to care. Sony should understand what
> they are delivering and the circumstance of that. That they refuse to serve
> some customers due to the technology they use is either a business decision
> or a faulty
On 26/Aug/20 20:20, Brian Johnson wrote:
> Either way. Nothing you can do in the network will help Sony enable IPv6
> capability, Or to serve their users even if using a technology that they do
> not like.
Agreed.
The problem is gaming customers that neither care for nor know about how
On 26/Aug/20 18:48, JORDI PALET MARTINEZ via NANOG wrote:
> I work and I'm in touch with many CPE vendors since long time ago ... many
> are on the way (I can remember about 12 on top of my head right now, but
> because contracts, can't name them). It takes time. However, in many cases,
>
On 26/Aug/20 20:14, Brian Johnson wrote:
> This sounds like a Sony problem more than a network problem. They need to get
> on the IPv6 train and play nice with the Internet. X-BOX has had IPv6 support
> since X-BOX One.
IIRC, someone here said the issue wasn't so much PS4 (which runs
On 26/Aug/20 18:42, JORDI PALET MARTINEZ via NANOG wrote:
> The crazy thing is that PSN doesn't (up to my knowledge) yet work with IPv6
> ...
To this day, my PS4, running Sony's latest code, does not support IPv6.
That might be a good place to start, for them.
At the rate they are doing,
On 26/Aug/20 16:38, Brian Johnson wrote:
> Over sub at around 20-40 to 1 is very easy now. With PBA, DET-NAT and other
> tools, the average customer largely doesn’t know it is happening and it
> solves for many provider side issues as well (logging being the biggest). For
> those customers
On 26/Aug/20 10:49, Bjørn Mork wrote:
> You aren't forcing anything if you allow the users to use any CPE and
> document the features it must/should have.
>
> You want IPv4 access without DNS? Then you need CLAT
> You don't know what CLAT is? Call your CPE vendor for support
> You don't
On 25/Aug/20 22:40, Brian Johnson wrote:
> I usually solve this problem by designing for NAT444 and dual-stack. This
> solves both problems and allows for users to migrate as they are able/need
> to. If you try and force the change, you will loose users.
At some point, you run out of IPv4.
On 25/Aug/20 22:15, Brandon Martin wrote:
> I really, really hate to force users to use my network edge router (I
> provide the ONT, though, and I provide an edge router that works and
> most users do take it), but it can be tough to ensure users have
> something that supports all the right
On 25/Aug/20 21:36, JORDI PALET MARTINEZ via NANOG wrote:
>
>
> A few years ago, I was thinking that the cost of the “replacement” of
> the CPE was too high for most of the operators. Not because the CPE
> itself, but the logistics or actually replacing it.
>
Which makes (or made) the case
On 25/Aug/20 19:36, JORDI PALET MARTINEZ via NANOG wrote:
>
>
>
>
> --- I’ve managed to get better support from vendors which are
> different than Mikrotik. Some years ago, I even offered Mikrotik
> **free** help to correctly do transition … and I’m still waiting for a
> single response. I
On 25/Aug/20 18:46, JORDI PALET MARTINEZ via NANOG wrote:
> Many vendors are running on top of OpenWRT or Linux, and both of them have
> CLAT support.
>
> Unfortunately, I can't give names which aren't already published, such as
> Sagemcom, D-Link, NEC and Technicolor. Believe me there are
On 25/Aug/20 18:28, Tom Hill wrote:
> I'd wager that a lot of them already build upon a Linux kernel of some
> flavour. Tore (et al) wrote a CLAT for Linux that builds upon TAYGA's
> NAT64 functionality: https://github.com/toreanderson/clatd
I guess my point was this is out in the wild on
On 25/Aug/20 18:28, Ca By wrote:
>
> Askey ships 464xlat boxes for T-Mobile in the USA, so they have the
> products and the knowledge to make it work
>
> https://www.askey.com.tw/index.html
>
> I am aware of other big CPE makers too, but this is the public one
> providing product today. Also,
On 24/Aug/20 17:21, JORDI PALET MARTINEZ via NANOG wrote:
> You probably mean 464XLAT
>
> Ask you vendors. They should support it. Ask for RFC8585 support, even better.
>
> If they don't do, is because they are interested only in selling new boxes
> ... just something to think in the
On 20/Aug/20 08:16, Saku Ytti wrote:
> On QSFP28 devices I would recommend always when possible run RS-FEC.
> By default LR4 doesn't run it, but the added value is fantastic. You
> will immediately during turn-up know if circuit works or not, without
> any ping testing or live traffic. You
On 19/Aug/20 19:34, Clinton Work wrote:
> What is the device on the other side of the MX204 100G link. We've had some
> incrementing PCS errors on 100G links when the other side was a Juniper
> PTX1000 using port et-0/0/25. Using a different port on the PTX1000
> resolved the
On 15/Aug/20 12:32, Etienne-Victor Depasquale wrote:
> +1
>
> You can't foresee everything, but no plan means foreseeing nothing, =
> blindfold.
In the absence of guidance from your Sales team on a forecast, keep the
50% threshold trigger, and standardize on lead times if urgent
feasibilities
On 15/Aug/20 11:35, Baldur Norddahl wrote:
> No plan survives contact with the enemy. Your careful made growth
> projection was fine until the brass made a deal with some major
> customer, which caused a traffic spike. Or any infinite other events
> that could and eventually will happen to
On 15/Aug/20 10:47, Etienne-Victor Depasquale wrote:
> I've seen the weekly profiles of traffic sourced from caches for the
> major global services (video, social media, search and general) for a
> specific metro area.
>
> For all services, the weekly profile is a repetition of the daily
>
On 15/Aug/20 01:45, Radu-Adrian Feurdean wrote:
>
> I think you're over-confident.
If you can resist the "let me make a plan" offer that CFO's would want
you to give them, you can be confident :-). Because when it hits the
fan, the CFO will say, "But Feurdean said he would make a plan. If he
On 13/Aug/20 13:44, Olav Kvittem wrote:
> sure, but I guess the loss rate depends of the nature of the traffic.
Packet loss is packet loss.
Some applications are more sensitive to it (live video, live voice, for
example), while others are less so. However, packet loss always
manifests badly
On 13/Aug/20 13:00, Nick Hilliard wrote:
>
> you could easily have 10% utilization and see packet loss due to
> insufficient bandwidth if you have egress << ingress and
> proportionally low buffering, e.g. UDP or iSCSI from a 40G/100 port
> with egress to a low-buffer 1G port.
>
> This sort of
On 13/Aug/20 12:23, Olav Kvittem via NANOG wrote:
> Wouldn't it be better to measure the basic performance like packet
> drop rates and queue sizes ?
>
> These days live video is needed and these parameters are essential to
> the quality.
>
> Queues are building up in milliseconds and people
On 12/Aug/20 19:10, adamv0...@netconsultings.com wrote:
> Fair enough, but you actually haven't answered my question about why you
> think that VNFs such as vTMS can not be implemented in a horizontal scaling
> model?
> In my opinion any NF virtual or physical can be horizontally scaled.
On 13/Aug/20 11:56, Simon Leinen wrote:
> I'd be curious whether other operators have such alert rules, and what
> N/M/X/Y they use - might well be different values for different kinds of
> links.
We use alerts to tell us about links that hit a threshold, in our NMS.
But yes, this is based on
On 12/Aug/20 17:08, m.Taichi wrote:
> Just my curiosity. May I ask how we can measure the link capacity
> loading? What does it mean by a 50%, 70%, or 90% capacity loading?
> Load sampled and measured instantaneously, or averaging over a certain
> period of time (granularity)?
>
> These are
On 12/Aug/20 17:08, m.Taichi wrote:
>
> Just my curiosity. May I ask how we can measure the link capacity
> loading? What does it mean by a 50%, 70%, or 90% capacity loading?
> Load sampled and measured instantaneously, or averaging over a certain
> period of time (granularity)?
>
> These are
On 12/Aug/20 10:50, Etienne-Victor Depasquale wrote:
> This point plays straight up the path of the argument I recounted.
>
> Yes, I agree that there's a relational problem inherent to the
> situation I described.
> Wouldn't any wise employer playing the relationship game ensure that
> he's
On 12/Aug/20 09:44, Saku Ytti wrote:
> Personally if the link is in a growth market, you should upgrade
> really early, 50% seems late, cost is negligible if you anticipate
> growth to continue. If it's not a growth market cost may become less
> than negligible.
The problem you have is "what
On 12/Aug/20 09:49, Etienne-Victor Depasquale wrote:
> Two more bits' worth ...
>
> About a year ago, during a discussion with a local network operator's CTO,
> I was told that dependency on the operator's employees
> for production of software gave the employees too much leverage over
> their
On 12/Aug/20 09:31, Hank Nussbacher wrote:
> At what point do commercial ISPs upgrade links in their backbone as
> well as peering and transit links that are congested? At 80%
> capacity? 90%? 95%?
>
We start the process at 50% utilization, and work toward completing the
upgrade by 70%
901 - 1000 of 2576 matches
Mail list logo
