Bottlenecks and link upgrades
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%? Thanks, Hank Caveat: The views expressed above are solely my own and do not express the views or opinions of my employer
Re: Bottlenecks and link upgrades
On Wed, 12 Aug 2020 at 10:35, 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%? I've worked for employees where policy has been anywhere from 50% or 80%. And I know this isn't complete range. Most do not subscribe to any single simple rule but act more tactically. 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. Sometimes networks congest particularly their edge interfaces strategically due to poor incentives, where irrelevant revenue wholesale arm might see some benefit from strategic congestion while also significantly hurting their money printing mobile arm reducing company wide bottom line while improving wholesale arm bottom line. -- ++ytti
Re: Has virtualization become obsolete in 5G?
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 employer (the operator, here). Perhaps industrial standardization of internal processes (including orchestration APIs) weakens this leverage. Cheers, Etienne On Tue, Aug 11, 2020 at 8:48 PM Mark Tinka wrote: > > > On 11/Aug/20 17:55, adamv0...@netconsultings.com wrote: > > > Can you elaborate? > > Apart from licensing scheme what stops one from redirecting traffic to > one vTMS instance per say each transit link or per destination /24 (i.e. > horizontal scaling)? (vTMS is not stateful or is it?) > > In an effort to control costs, we considered a vTMS from Arbor. > > Even Arbor didn't recommend it, which was completely unsurprising. > > Arbor can flog you a TMS that can sweep 10Gbps, 20Gbps, 40Gbps or > 100Gbps worth of traffic. I don't see how you can run that kind of > traffic in a VM. > > > > > Can you please point out any efforts where operators are trying to > standardize the orchestration piece? > > NETCONF, YANG, LSO. > > > > I think industry is not falling over on this just progressing at steady > rate while producing artefacts in the process that you may or may not want > to use (I actually find them very useful and not impeding). > > What's 10 years between friends :-)... > > > > Personally, I don't need a standard on how I should orchestrate network > services. There are very interesting and useful ideas, or better put > "frameworks", that anyone can follow (and most are), but standardizing > these, ...no point in my opinion. > > Now that's something we can agree on... and once folk realize that > getting your solution going is the end-goal - rather than bickering over > whether NETCONF or YANG or SSH or whatever should be the BCOP - is when > we shall finally see some real progress. > > Personally, I don't really care of you choose to keep CLI or employ > thousands of software heads to automate said CLI. As long as you are > happy and not wasting time taking every meeting from every vendor about > "automation". > > Mark. > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Bottlenecks and link upgrades
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% utilization. The period between 50% - 70% is just internal paperwork. Mark.
Re: Has virtualization become obsolete in 5G?
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 employer (the operator, here). > > Perhaps industrial standardization of internal processes (including > orchestration APIs) weakens this leverage. I'm not sure that's a viable argument considering that any good employee (network, software, e.t.c.) will inherently have considerable leverage over their employer. And any good employer knows what to do when they realize they have good talent - either they do what is required to maintain that talent, or live with the risk of losing that talent to the competition. Moreover, an employer doesn't have to give in to the whims of a conceited employee; and most do not. Standardizing processes would do little to allay the fears of a CTO who is worried about being "cornered" by his/her staff. The real fear such a CTO would have is in implementation and operation of those processes at a technology level, i.e., where the rubber meets the actual road. If companies are going to be that scared by their employees, and if employees are going to play games with their employers, they each have other problems to solve, first :-). Mark.
Re: Bottlenecks and link upgrades
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 is a growth market", especially over time as it stabilizes and see new entrants, but growth is now in a phase where you need massive scale to keep playing. You then shift from a "sales are guaranteed Day 1" to a "build it and hope for the best". Many Commercial get fearful at that point, because of the temptation to link capacity to guaranteed sales. > Sometimes networks congest particularly their edge interfaces > strategically due to poor incentives, where irrelevant revenue > wholesale arm might see some benefit from strategic congestion while > also significantly hurting their money printing mobile arm reducing > company wide bottom line while improving wholesale arm bottom line. I know a few :-). Mark.
Re: Has virtualization become obsolete in 5G?
> > Moreover, an employer doesn't have to give in to the whims of a > conceited employee; and most do not. > 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 got cards to play? And wouldn't the standardization approach be part of the deck? Cheers, Etienne On Wed, Aug 12, 2020 at 10:00 AM Mark Tinka wrote: > > > 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 employer (the operator, here). > > > > Perhaps industrial standardization of internal processes (including > > orchestration APIs) weakens this leverage. > > I'm not sure that's a viable argument considering that any good employee > (network, software, e.t.c.) will inherently have considerable leverage > over their employer. And any good employer knows what to do when they > realize they have good talent - either they do what is required to > maintain that talent, or live with the risk of losing that talent to the > competition. > > Moreover, an employer doesn't have to give in to the whims of a > conceited employee; and most do not. > > Standardizing processes would do little to allay the fears of a CTO who > is worried about being "cornered" by his/her staff. The real fear such a > CTO would have is in implementation and operation of those processes at > a technology level, i.e., where the rubber meets the actual road. > > If companies are going to be that scared by their employees, and if > employees are going to play games with their employers, they each have > other problems to solve, first :-). > > Mark. > > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Has virtualization become obsolete in 5G?
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 got cards to play? > And wouldn't the standardization approach be part of the deck? In theory, yes. But the department most interested in this might be HR, while the ones most able to implement it will be the CTO team. Until NOG's start having breakout sessions on employee-employer dynamics, or until HR conferences start thinking about telecoms industry orchestration standardizations to mitigate employee-employer dynamics, it will remain a theory :-). Mark.
Re: RPKI TAs
> We've also simplified our webpage: > https://afrinic.net/rpki/tal > > And the URL to the TAL: > https://rpki.afrinic.net/tal/afrinic.tal thanks! wfm randy
Re: Bottlenecks and link upgrades
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 questions have bothered me for long. Don't know if I can ask > about these by the way. I take care of the radio access network > performance at work. Found many things unknown in transport network. For this, we look at simpel 5-minute based SNMP data over the period. Nothing too fancy. It's stable Mark.
Re: Bottlenecks and link upgrades
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 questions have bothered me for long. Don't know if I can ask > about these by the way. I take care of the radio access network > performance at work. Found many things unknown in transport network. For this, we look at simple 5-minute based SNMP data over the period. Nothing too fancy. It's stable Mark.
RE: Has virtualization become obsolete in 5G?
> From: Mark Tinka > Sent: Tuesday, August 11, 2020 7:45 PM > > On 11/Aug/20 17:55, adamv0...@netconsultings.com wrote: > > > Can you elaborate? > > Apart from licensing scheme what stops one from redirecting traffic to > > one vTMS instance per say each transit link or per destination /24 > > (i.e. horizontal scaling)? (vTMS is not stateful or is it?) > > In an effort to control costs, we considered a vTMS from Arbor. > > Even Arbor didn't recommend it, which was completely unsurprising. > > Arbor can flog you a TMS that can sweep 10Gbps, 20Gbps, 40Gbps or > 100Gbps worth of traffic. I don't see how you can run that kind of traffic in > a > VM. > 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. > > > > Can you please point out any efforts where operators are trying to > standardize the orchestration piece? > > NETCONF, YANG, LSO. > Right, and of these 3 you mentioned, what is it that you'd say operators are waiting for to get standardized, in order for them to start implementing network services orchestration? > > > I think industry is not falling over on this just progressing at steady rate > while producing artefacts in the process that you may or may not want to use > (I actually find them very useful and not impeding). > > What's 10 years between friends :-)... > > > > Personally, I don't need a standard on how I should orchestrate network > services. There are very interesting and useful ideas, or better put > "frameworks", that anyone can follow (and most are), but standardizing > these, ...no point in my opinion. > > Now that's something we can agree on... and once folk realize that getting > your solution going is the end-goal - rather than bickering over whether > NETCONF or YANG or SSH or whatever should be the BCOP - is when we shall > finally see some real progress. > > Personally, I don't really care of you choose to keep CLI or employ thousands > of software heads to automate said CLI. As long as you are happy and not > wasting time taking every meeting from every vendor about "automation". > Agreed, all I'm trying to understand is what makes you claim things like: progress is slow, or there's a lack of standardization, or operators need to wait till things get standardized in order to start doing network service orchestration... I'm asking cause I just don't see that. My personal experience is quite different to what you're claiming. Yes the landscape is quite diverse ranging from fire and forget CLI scrapers (Puppet, Chef, Ansible, SaltStack) through open network service orchestration frameworks all the way to a range of commercial products for network service orchestration, but the point is options are there and one can start today, no need to wait for anything to get standardized or things to settle. adam
Re: RPKI TAs
Hi all, We've also simplified our webpage: https://afrinic.net/rpki/tal And the URL to the TAL: https://rpki.afrinic.net/tal/afrinic.tal Cheers, Amreesh Phokeer AFRINIC On Thu, Aug 6, 2020 at 4:59 PM Randy Bush wrote: > > https://tal.rpki.ripe.net/ripe-ncc.tal (preferred) > > looks great visually. stuffed in a dragon validator, just for qa. > > thanks! > > randy >
Re: Netflix people?
Hi Max, If you're continuing to receive unsatisfactory support on this issue, please reach out to me directly. mc On Mon, Aug 10, 2020 at 10:42 AM Max Tulyev wrote: > Hi All, > > is there anyone from Netflix? > > We have a strange problem: our customers also customers of Netflix when > connecting to Netfilx sees 404 error. If they change IP to another ISP - > everything works fine. The support can't solve it. >
Re: Bottlenecks and link upgrades
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 questions have bothered me for long. Don't know if I can ask about these by the way. I take care of the radio access network performance at work. Found many things unknown in transport network. Thanks and best regards, Taichi On Wed, Aug 12, 2020 at 3:54 PM Mark Tinka wrote: > > > 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% utilization. > > The period between 50% - 70% is just internal paperwork. > > Mark. >
Re: Bottlenecks and link upgrades
When I worked for an ISP, it was about 70%, not sure if that is the case with the other ones. On 8/12/2020 3:31 AM, 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%? Thanks, Hank Caveat: The views expressed above are solely my own and do not express the views or opinions of my employer
Re: Bottlenecks and link upgrades
On Wed, 12 Aug 2020, 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%? Thanks, Hank Caveat: The views expressed above are solely my own and do not express the views or opinions of my employer Why upgrade when you can legislate the problem instead. Charter tries to convince FCC that broadband customers want data caps. https://arstechnica.com/tech-policy/2020/08/charter-tries-to-convince-fcc-that-broadband-customers-want-data-caps/ Ted
