The Geography of a Sunrise?

By Victor Kuarsingh

I woke up early in San Francisco this week with the blinds open, the sky still dark, cold, and night. Looking out at Coit Tower from my hotel window, I couldn’t help but ask myself — “what is a sunrise to others on a given day?” Waking up early or late certainly has a significant bearing on this, but I also realized that even without traveling, where you live may impact one’s experience. Those of us who have lived in very northern or southern latitudes know there’s a large difference between summer and winter, with a gradual increase and decrease in daylight hours.

I also realized that, outside of this, where one lives impacts when the sun comes up and what the start of a day means. So again — “what is a sunrise to you?” It turns out that’s not a trivial question, and the answer isn’t just about discipline or being a “morning person.” It also has a lot to do with longitude.

Time zones are political. The sun is not. Each zone is a roughly fifteen-degree wedge of the earth, and one clock is asked to govern all of it — sunrise and sunset drift by as much as an hour across that wedge, even though every watch inside it says the same time. In a given time zone, one person can be waking up to a 6 AM sunrise slowly slipping into the day, while someone else wakes up to pitch black, fighting their body’s interpretation that “it’s still night.” By 9 AM, our eastern-biased friend is “ready to go,” and our western-biased friend is “still grappling with their start.”

Chronobiologists have a name for what happens next: social jetlag. It’s usually used to describe the gap between when your body wants to sleep and when your calendar makes you — most familiarly, the whiplash between a Friday-night bedtime and a Monday alarm. But a 2019 study in the Journal of Health Economics (Giuntella & Mazzonna) found the same mismatch happening geographically, quietly, every single day, to people who never cross a time zone at all. They just live on the wrong side of one.

The mechanism is almost absurdly simple. An extra hour of evening light delays the body’s release of melatonin. Bedtime drifts later while one’s alarm clock remains steadfast. Across US time-zone borders, that’s worth about 19 minutes of sleep a night, on average — not dramatic on any one night, but compounding, year after year, into measurably higher rates of obesity, diabetes, and cardiovascular disease, and into a subtle but real drag on regional income.

I have spent a lot of time between Toronto and Miami, both several degrees of longitude into the “late” side of Eastern time — later sunrise and sunset on the clock than cities like Montreal or New York, though neither is the most extreme case. That distinction goes to Detroit, which is geographically so far west it sits past the traditional Eastern time boundary, yet still runs on Eastern clocks. Its residents get the latest sunsets, and the latest, most reluctant sunrises, of any major Eastern city. But Miami and Toronto are both, in this particular sense, on the same side of the ledger as Detroit — cities where the sun shows up on the clock a little later than it “should,” and where 9 AM asks something of the body that the sky hasn’t quite delivered yet.

None of this is really about sunrise trivia. It’s about the fact that “a standard workday” is a fiction we apply uniformly to a population that does not experience the day uniformly. The same start time that feels natural in one city is a small, silent tax on another — paid in sleep, in health, and apparently in income. We’ve spent a lot of energy optimizing how people work. We’ve spent almost none asking where they’re doing it from, and what the sky outside their window actually looks like at 7 AM.

So: what time do the people you work with actually wake up? And when they do — do they see the sun?

Authentic Leadership

By Victor Kuarsingh

The Job No One Applauds

Senior roles come with a lot of things people assume are glamorous — the title, the room you’re now in, the decisions with your name attached. What they don’t often see is how much of the job is necessary and needfully unglamorous. Budgets, difficult conversations, finding clarity through obscurity – a duty many are not drawn to. Absorbing pressure from above so it doesn’t land unfiltered on your organization is essential. None of that gets a headline, yet all of it is the actual work.

For nearly three decades, across various career levels, I’ve watched this dynamic play out in enough rooms to trust it as a pattern rather than a one-off. When it comes to authenticity, I’ve come to believe that how an executive handles the unglamorous 80% says a lot more about them as a leader than the often-visible keynote and strategy deck does.

The Bridge You Forget You’re Supposed to Be

It’s easy, especially as scope grows, to get pulled almost entirely upward — reading the room above you, anticipating what leadership wants, managing the optics of your own function. That instinct isn’t wrong on its own; every executive has to do some of it. The problem is when it becomes the whole job, and you stop being the bridge your organization actually needs: the connective structure that translates strategy downward and reality upward, in both directions, honestly.

An org can feel the difference immediately. A leader spending most of their energy managing up starts to feel, from below, like a relay point instead of a person — present in meetings, absent in practice. The team ends up managing themselves, left to form, sort, and operate without real connection to the person meant to be leading them.

You Can’t Fake the Real Thing

Here’s the part I think gets underestimated: people know. Not eventually — pretty quickly. Teams can tell, often before an executive can admit it to themselves, who’s actually invested in the mission versus who’s here for the ride. To be clear, this isn’t a rare failure mode — most leaders I’ve worked with, at most companies, genuinely are what they present themselves to be. But every organization, without exception, has a handful who aren’t: people whose real orientation is their own trajectory, and whose teams figure that out long before leadership above them does. You can manage a narrative upward for a while. You can’t manage one downward for long, because the evidence is daily and specific — who shows up when it’s inconvenient, who takes the harder conversation instead of the easier one, who’s consistent when nobody senior is watching.

That’s really what authenticity is in a leadership context. Not a communication style. A track record that either holds up under close, repeated observation or doesn’t.

The Actual Job

Which brings me to what I think the real job is, underneath the title: making the organization stronger and better, and specifically making the people downstream of you more capable than they were before you got there. Not as a nice-to-have alongside the “real” work — as the real work. Everything else, the strategy, the roadmap, the board updates, is in service of that or it isn’t worth much.

I wrote about a version of this a few years ago in Everyone Deserves a Mentor — the idea that a leader only has 24 hours in a day, and the only real way to multiply your impact is by building other leaders who extend it. Authenticity is what makes that possible in practice. Mentorship that’s really just performance doesn’t hold up once things get hard — a bad quarter, a reorg, a crunch. Mentorship rooted in genuinely wanting someone to grow does. The bridge-building, the unglamorous work, the resistance to managing purely upward — it’s all the same discipline, just applied at different altitudes. Show up as who you actually are, consistently, and the org will trust you with more. Perform it, and eventually the org stops believing anything else you say.

Pacing, Not Stopping: What This Week’s AI Safety Moment Actually Means

By Victor Kuarsingh

Three AI CEOs who normally compete for the same customers, the same talent, and the same headlines agreed on something this week, and that alone is worth pausing on. Dario Amodei published an essay proposing the industry deliberately pace frontier AI development. Sam Altman backed it publicly, going as far as to tie OpenAI’s own decision to delay its IPO partly to unresolved safety questions. Elon Musk, who agrees with neither of them on much, offered two words: “Dario is right.”

Rivals don’t converge like this without a reason worth examining, and “AI leaders call for caution” is the kind of headline we tend to nod at and move past. The substance underneath it deserves more than that.

What “pacing” actually means

The easiest mistake here is hearing “slow down” and assuming someone means “stop.” No one serious does. Amodei’s framing is explicit: pacing, not stopping. The proposal has three concrete parts. Frontier labs should give independent safety evaluators the kind of standing access employees get — badges, laptops, desks, the ability to see what’s actually happening inside a lab rather than a sanitized summary after the fact. The U.S. government should grant a narrow antitrust waiver so competing labs can coordinate on safety standards without opening themselves to legal risk for talking to each other. And democratic governments need some mechanism to bring less cautious developers, into a common framework — otherwise a company pacing itself responsibly just hands its lead to whoever paces themselves the least.

This isn’t a September idea that appeared from nowhere. Back in July, more than 1,100 employees across the major labs — including Amodei, his Anthropic co-founders, OpenAI’s chief scientist, and safety leads at Meta and Google — signed a letter asking government to build the regulatory tools needed to pace development if it started accelerating beyond what anyone could meaningfully oversee. That letter didn’t call for an immediate slowdown either; it asked for the capability to slow down to exist before it’s needed, which is a more defensible ask than it sounds at first pass. As of this week, it’s moved from essays and letters to an actual working group: OpenAI, Anthropic, and Google have reportedly been meeting for weeks on a coordination framework modeled loosely on FINRA — voluntary 30-day pre-release reviews, embedded third-party evaluators, shared testing protocols.

We’ve been here before, just with different technology. The internet scaled globally not because one company set the rules for everyone, but because competing organizations agreed — often reluctantly — to coordinate through shared standards bodies rather than let raw speed dictate the outcome. That’s the entire premise behind standards processes many of us have spent years contributing to: rivals in the same room, building specifications none of them fully control, because a standard only holds if no single participant can bend it to their own advantage later. Pacing the frontier is, in effect, an attempt to build that same kind of coordination for AI, compressed into months instead of decades, with far higher stakes riding on getting it right the first time.

The part that shouldn’t get skipped

This is also where the story gets more interesting than “industry leaders show responsibility,” and where the coverage has mostly been too credulous. Cohere’s CEO called the coordination effort “a cartel by any other name.” David Sacks has argued the safety rationale is doing double duty as cover for ordinary commercial incentives — that reducing liability exposure and giving customers predictability is simply good business, dressed up as principle. Neither critique is unreasonable. The companies proposing to set the pace and the companies best positioned to benefit from a slower, more regulated frontier are the same companies, and standards built by whoever has the most to gain rarely serve everyone equally — ask any engineer who’s had to build around a proprietary “standard” that later became a market-share weapon. Meta, Microsoft, Amazon, and many other developers are, notably, not in this particular room. Whatever gets built here only means something once it extends to the players with the least incentive to slow down.

Why this matters beyond the frontier labs

The frontier-lab conversation is getting the headlines, but it’s not where most of us actually encounter AI. It’s downstream — in the products enterprises buy, the workflows we automate, the decisions we let a model make before a person ever reviews them. The same discipline Amodei, Altman, and Musk are applying to their own labs applies one level down, to every enterprise, provider, and consumer of AI pushing these systems into production: the same care, the same independent scrutiny, the same resistance to shipping capability faster than it can be verified as safe. A frontier lab pacing itself doesn’t accomplish much if the fifty enterprise deployments built on top of its models skip that same discipline in the name of shipping faster.

Where this leaves us

None of this is an argument for halting anything. It’s a case for intentional balancing — layering the right safeguards in as capability advances, from the foundation model providers building these systems down to the enterprises and teams putting them into production where the outcomes land on real people. The frontier labs made news this week for saying that out loud. The rest of us building on top of their work should be doing it just as deliberately, whether or not it makes headlines.

The Internet Society – Helping Democratize the Internet

By Victor Kuarsingh

I recall way back in the mid-90s, this new phenomenon called the “Internet”. Working in a Computer Store while in school, it was the perfect place to watch the fledgling Internet landscape grow from a consumer’s perspective.  Sure I had my model years priory surfing BBS sites – but this was different.  

Strolling the aisles in the store, I saw this interesting display of software packages frontingInternet access providers like Delphi and Microsoft Network as well as early browsers such as Mosaic and Netscape Navigator., 

Dial-up was the primary method of access. With the right modem, speeds progressed from 14.4 Kbps to 28.8 Kbps and 33.6 Kbps, eventually reaching 56 Kbps—after a brief protocol war between U.S. Robotics’ x2 and Lucent/Rockwell’s K56flex was settled by the universal V.90 standard.

If you were a business or had money to burn, ISDN was an option, unleashing 64 Kbps or dual-channel 128 Kbps. For large enterprises with real budgets, T1 lines providing a blazing 1.544 Mbps were the gold standard. As we moved past the 1990s into the 2000s, consumer speeds exploded with the arrival of telecom Digital Subscriber Line (DSL) offerings and cable internet, which matured into high-speed DOCSIS standards by the mid-2000s.

Moving through the 2000s and 2010s, we have seen continuous innovation in internet infrastructure to support an explosion of online services, digital experiences, and remote work built on this flourishing fabric. Today, it’s hard to imagine a world where we can’t work from home, attend classes, check social media with the tap of a screen, order food, book trips, video call loved ones, or stream our favorite shows.

Now, here is the kicker: this was and is my experience living in North America, a reality far removed from what many in the world experience today.

However, while many of us enjoy this as our daily normal, a massive portion of the global population does not. What we take for granted as ‘the Internet’ is often unreliable, severely restricted, or entirely unavailable elsewhere. Millions of eager, talented young people are limited in their educational pursuits, isolated from global news, and cut off from the rest of the world—not by choice, but by a lack of basic infrastructure.

This is why organizations like the Internet Society (ISOC) and the Internet Society Foundation are so crucial. For years, these non-profits have worked tirelessly to close the digital divide. Through hands-on programs that expand infrastructure, foster local tech communities, and champion open access, these heroes work to truly democratize the internet for everyone.

Seeing the face of a young student connecting to world-class educational resources for the first time, or a family reuniting across continents, or a remote village accessing lifesaving telemedicine warms the heart. This is the vital work that the Internet Society and Internet Society Foundation continue to drive forward. Powered by dedicated staff, passionate global chapters, and countless volunteers, they are changing lives every single day.

I normally don’t ask others to Donate, but for those who find it in their heart to support this critical work, the Internet Society would most definitely appreciate the opportunity to pay that forward.  Just look at the Impact Stories.

Risk Of Foundational Knowledge Beyond 2026

By Victor Kuarsingh

AI is pushing the boundaries of technological abstraction further than ever before. While no one is arguing we should abandon modern tooling and code like it’s 1965, this rapid evolution introduces a silent organizational risk. Every previous era of computing has shown that when an abstraction breaks, the organizations that are impacted most are the ones where technology creates problems and few or nobody is left in the building can reason about what is underneath.

The Challenge Ahead

When we look back over the past 60-70 years, the industry has come a long way from our early computing and programming era.  In those early days, the application user was most often the code developer with a necessarily deep understanding of the foundational computing system by which functions were built.   As operating environments evolved, such as the release of Unix by AT&T Bell Labs in the 1970s, programmers and users were able to leverage a more abstracted environment resulting in productivity gains. As we approached the 80s, that further evolved where end users were rarely the programmer, and even more unlikely to have a deep understanding of the foundational computing platforms. 

In the 1980s, the acceleration of networking was driven by the need to expand the early ARPANet that bloomed into the Internet by the mid 1990s.  Those early networking experts were most often computer scientists that formed early connectivity protocols and systems morphing into a defined discipline by the mid-1990s.  Early networking talent, just like the early systems and programming talent, was often very well versed in the foundational infrastructure’s base architecture, design and capabilities. Moving further into the 2000s, the rapid expansion of vendor supplied products, standard deployment models, and further abstraction began to distance users, administartors and programmers of networking systems from those foundational capabilities. 

The advantage of these abstractions both within the software and networking space were revolutionary in allowing for scaling and acceleration of deployments, modern applications and outcomes.  However, an artifact of this change is the slow and often silent deterioration of foundational expertise in many businesses. Areas where experience often now lacks includes networking, security, computing, operating systems and platforms.  The deep learning curve that was needed to be functional years ago, no longer is mandatory for most designers and engineers to operate within their areas of the business.  That separation and devolution of “making it work” contrasting to understanding “how it works” – poses a risk to business, especially when those foundations are needed for resiliency and overall business success.

AI, which has displaced so many foundational tasks and roles, not only further adds to the separation, but may further accelerate the deterioration of skills development and growth of cognitive reasoning when designing, using and improving systems or platforms.  The new risk somewhat exacerbated by AI is the release of engineering rigor as a pillar of development teams are able to produce without really knowing how the product (code or config) is being generated.   

With a declining population of highly competent engineers that understand the foundations, and an ever increasing demand for those people, its going to be interesting to see what transpires in the market and in businesses.  Early impacts will likely be filled with outages and missed opportunities for businesses.  The longer term impact may be foundationally  anemic businesses unable to produce substantive products and services relegated to producing fragmented and unreliable technical products.   The challenge we face as business leaders is – can we leverage AI to accelerate now without sacrificing our future success.

Modern examples where eroded engineering rigor and abstraction-layer failures caused significant business impact include CrowdStrike (2024), Meta (2021), and Knight Capital (2012) — each resulting in substantial financial loss and reputational harm.

So What

The challenge we face as leaders and within the Industry is clear.  We must leverage AI to accelerate our velocity without sacrificing our future integrity.  We need deliberate balancing between embracing this new layer of abstraction while still protecting our base of needed expertise. 

Allowing AI to completely sever our engineering teams from the underlying mechanics of our networks, systems, and platforms introduces a business risk. When a catastrophic failure inevitably occurs beneath the AI-generated layer, the absence of deep, cognitive reasoning won’t just cause a routine outage—it could result in an entirely unrecoverable situation where no one in the building knows how to rebuild the collapsed foundation.

AI can generate the code and configure the platforms, it cannot assume the risk. Moving forward, engineering rigor cannot be outsourced. We must intentionally cultivate, value, and retain the talent that understands the “how,” ensuring that as our technology becomes increasingly abstracted, our ability to govern, troubleshoot, and recover our businesses remains firmly intact.

Rethinking the Network Engineer Part 2: From Builders & Administrators to Software Innovation

By Victor Kuarsingh

Introduction – The Shift Beyond Building and Administration

For decades, network was largely anchored to an administrator’s perspective: building, configuring, crafting and maintaining systems with the mindset getting to runtime and keeping the lights on. This approach solved immediate problems effectively, but it also constrained networking to incremental change and reliance on humans for many operations even if some automation was present. Today’s landscape that includes cloud, automation, distributed systems, edge computing and complex security; demands a substantive change in how we build systems. The future of networking is no longer about administering devices; it is about engineering solutions at the software layer, with networking as one of several domains in play.

Lessons From Past Practice – Why the Old Model No Longer Fits

Traditional approaches relied on command-line mastery and vendor-specific skills. These were critical in the 1990s and 2000s, but they locked engineers into reactive modes of work: troubleshooting configurations, responding to outages, or scaling networks by manual effort. Basic building and management of networks can be argued to be a “solved problem” insomuch that there is an abundance of operational techniques and tactics known by our industry to deal with them —protocols, routing methods, and device management frameworks exist that address the common cases. What remains unsolved are the problems of scale, velocity, and flexibility in the face of continuous change. These are not CLI problems; they are systems design problems.

Innovation by Inquiry – The Engineer as an Explorer

To move forward, network engineering needs the same culture of inquiry that drives innovation elsewhere. Extrapolated lessons from my post on Innovation by Inquiry, the emphasis should be on asking questions that reframe the problem space. So questions like – Why is this process manual? How could it be automated? What would a system look like if it were designed as code from the ground up? – are great ways to frame how to apply innovation to a problem.  This mindset turns engineers from operators into explorers, willing to experiment, fail, and iterate. Software engineering brings the tooling—automation frameworks, APIs, CI/CD pipelines—but inquiry provides the compass to ensure those tools are used to solve meaningful problems.

The Case for Network Engineers as Software Engineers

The emerging reality is that network engineers must become software engineers who also understand networking. Not the other way around. Writing infrastructure as code, modeling traffic flows as software artifacts, and integrating with service-based architectures are now table stakes. A software-first engineer can scale networking far beyond what was possible with administrator-centric practices. They can build abstractions, enforce policy through automation, and design resilient systems that are tested, versioned, and repeatable—just like any modern application. Networking knowledge remains essential, but it is no longer sufficient on its own.

Shifts We’ve Made Before – Reinvention Is the Norm

This isn’t the first time networking has reinvented itself. In the 1980s, networking often emerged from system administrators wiring together early LANs with technologies like Ethernet (IEEE 802.3), ARCNET, Token Ring, etc – solving the basic problem of how to connect PCs and share resources. By the 1990s, the explosion of the Internet demanded new thinking about the physical and routing layers. Vendors like Cisco and Juniper built high-capacity routers to support the first backbone networks, while advances such as fiber optics and DWDM (Dense Wavelength Division Multiplexing) reshaped how bandwidth could scale displacing early SONET and ATM technoloiges. Entering the 2000s and 2010s, the challenge shifted again: distributing and accelerating content. Content Delivery Networks (Akamai, Limelight), broadband build-outs, and global peering fundamentally changed how information was delivered. Each stage forced a leap away from past practice.

Today, the limiting factor is not physical speed but complexity—interconnected systems, microservices, cloud-native architectures, and global scale. Managing that complexity requires more than manual configuration or incremental improvements. It requires software: abstractions to tame complexity, automation to eliminate toil, and orchestration to ensure resilience. Just as we rethought wiring in the ’80s, backbone scale in the ’90s, and content distribution in the 2000s, we must now rethink networking through a software-first lens.

Forward-Looking Examples – Signs of the Next Shift

The industry is already showing us where this evolution is heading. Hyperscalers such as Google, AWS, and Microsoft have moved to intent-based, API-driven network models, where engineers declare desired outcomes and automation systems translate that into actual network states. Emerging 5G and edge networks rely heavily on network slicing and service orchestration, concepts that cannot exist without a software-first approach. These examples prove that the shift isn’t theoretical—it is already happening, and it rewards those who can think in code while understanding the fabric of connectivity underneath.

The unique challenge

The challenge—one somewhat unique to this space—is how to encourage a larger segment of networking innovators to adopt and excel at software-based approaches to solving problems, while still maintaining deep proficiency in foundational networking concepts. Developing such a polymathic, interdisciplinary skill set is difficult; this transition will be challenging to both foster and sustain. It takes years to become proficient in networking, and likewise to master the craft of building reliable software—yet our industry must rise to meet this dual expectation.

In many ways, this moment feels like a return to our roots. During the mid-to-late 20th century, it was computer scientists who designed many of the the early networks and the protocols that made them function. Perhaps it’s time to rekindle that spirit—to begin again with a software-first mindset.

Structuring the Future Differently

The shift is not optional. If we keep structuring solutions as administrators, we will keep solving yesterday’s problems. To address tomorrow’s, we must structure solutions fundamentally differently—through code, inquiry, and engineering discipline. This is not just about personal skills, but about reshaping the culture of networking teams to value experimentation, automation, and systems thinking. As with any transformation, the leaders who thrive will be those who combine the technical fluency of software with the critical inquiry of innovators, shaping networking into a platform for the next era of digital infrastructure.

Will AI take my job?

By Victor Kuarsingh

While the current buzz around AI has sparked curiosity for some and absorbed the attention of others, it has also created a sense of fear among those who believe AI may ultimately replace their jobs. There is of course a class of people who may not know what to think.

While the exact path of AI’s integration into the modern workplace remains uncertain, one thing is undeniable: its capabilities are accelerating at a staggering pace, and the disruption it brings is no longer a question of if, but when, how and where.

Highlighted in Our World in Data (Data source: Kiela et al), by 2023 AI was already outperforming [average] humans in reading comprehension, image recognition, and language understanding—while matching us in handwriting recognition, and speech recognition. Predictive reasoning, math problem solutioning, code generation and complex reasoning were all getting close. And that was two years ago. Since then, AI’s capabilities have been doubling every ~7 months, according to Metr.org with AI’s ability to accomplish larger tasks.

Some argue that focusing on labor-intensive work or roles that seem to inherently require human involvement might offer temporary protection from AI and related future automation. Yet, advances in robotics are rapidly encroaching on even these opportunities.

While none of us can predict with certainty what the next 5–10 years will bring, one thing is clear: the ability to adapt, evolve, and embrace change will be essential for achieving success in the workforce of the future. So to answer, “Will AI Take my job?” – Maybe.

References:

Measuring AI Ability to Complete Long Tasks (METR)

AI Test Scores (Our World in Data)

Everyone deserves a mentor

By Victor Kuarsingh

Do you remember a great teacher you had in school?  Perhaps you have fond memories of a caring and understanding older sibling, relative or a parent.  No mater whom it was, you may remember the time, care and interest they took in you;  helping you grow as a person.  Well, often, that type of relationship can be considered one of a mentor and mentee.  For those lucky enough to have had such a relationship, it can mean the difference between success and failure.  Such persons likely saw past your your limitations, understood your capabilities and helped you realize your potential.


Such a relationship need not be limited to the home, school or amongst family.  Mentorship is a skill and aptitude that is able to build up and grow employees within a business as well.   For this blog, we will focus on mentorship in the workplace.   Why do we mentor?  Why should one care? What is the benefit?  All good questions to be addressed in this short blog.


First, just like ourselves, most people were not born with the refined skills they possess as they moved throughout their careers.  Skills, methods and patterns are learned, adopted and taught over the course of time.   Some people are more able to build skills based on their own ability to absorb  information and adapt;  whereas others may need more assistance.  No matter whom we are, even if we are the more self sufficient type, we should realize that people are more than capable of growing, if given the chance and receive the right mentorship.


Each skilled leader should realize that talent within their organization is ripe for growth and advancement, if only provided mentorship to unlock that potential.  So why do we do this?  Great leaders realize that one of their jobs is to grow talent.  Its the duty of each leader to understand their role in building organizations, of which, building better managers and contributors are an essential part of those duties.  


So is duty the only reason for this role as leaders?  No.  Often leaders are in positions where they need to advance a business, improve operations, grow capabilities and achieve other key objectives of the business.  To achieve these goals, one must realize that they only have 24 hrs in a day.   Even if one could personally achieve  super-person status, able to spend almost every waken hour working, you will still run out of time and can never put in more that 24 hours in a single day, and more realistically 10-14 if you forgo most other activities.   The only real way to truly grow an organization is to focus on building other leaders who can expand the impact of your group or function.  In this model, what was once one person’s output now becomes a team’s output.   Suddenly, with proper mentorship, nearly a limitless amount of hours, only capped by the number of people one has working with them, can be spent improving an organization and reaching business goals.


What is the benefit?  Well as discussed in the previous paragraph, organizational success is of primary benefit.  However, if one looks at the selfish aspect of  the equation (which many often do), there is another benefit as well.   A leader’s ability to increase scope and take on new challenges can be tied to good mentorship and making your team self sufficient.   Great leaders are always building an organization that dose not need them.  Why, because this unlocks the leader to continue to grow while the success of their team is realized by a well mentored team.

So in summary.  Why should you mentor as a leader?  First, because its your duty.  Second, it will allow you to achieve your business goals (unless you are a singles tennis player, in that case, you are a lone wolf).  And thirdly, you automatically put yourself in a position to advance and take on more.

Network scale, don’t get left behind

By Victor Kuarsingh

Picture: Carmo Convent Ruins form earthquake of 1755

What’s old is new again, so some have said. It is interesting to see how even in 2020 we continued to hit capacity walls with the sudden change in demand for one of the most precious resources on the Internet and inside networks – bandwidth. Clear to most is the trigger, COVID-19, for this onslaught of additional bits hurling across the networks.

In February 2020 many knew that something was brewing when news continued to flow that the new virus known as SARS-CoV2 was devastating Wuhan. What we did not know, at least not to any degree of certainty, was the sudden shift in demand as a large swath of the office going workforce hunkered down at home and began to use video conferencing as their main interface to conduct meetings, Interviews, and other work. Whereas some may claim this was a surprise that none of us could have foreseen, the phenomenon of a sudden shift in demand is not a new one.

Lets enter our virtual DeLorean, turn on the time circuits and enter the date 1985. Oh wait, that’s too far back! Lets set it for 20 years later, so 2005. Now that we are in 2005, our story begins. I recall many conversations as the rumbling began to emerge of this new phenomenon called YouTube. Until then, we saw the rapid, yet gradual increase of bandwidth within the ISP networks throwing caching infrastructure to help manage the customer’s experience while we applied the 2000s model of building out the broadband networks and peering needed to sustain our normal for that time. However, YouTube changed all that. Suddenly, the capacity models broke. It was increasingly hard to keep up with the customer demand for bandwidth as demand started to consume much more bandwidth per user than before. This demand was really new, and before that, the concept of mass customer generated content was really not a something we engineered around. Facebook had also hit the scene, but other than fighting for supremacy versus MySpace, it did not seem to push as many bits to the network …. yet. Many of us planning network scaling realized it was hard to predict what will drive demand for our networks especially since the use case was new and not predictable.

We learned our lesson and everyone worked perfectly since then. Well, not really. lets climb back into our fictional metal time machine and advance to the year 2010. Although Netflix streaming has started in the US prior to that year, in Canada (where I was at the time), Netflix hit the wire. Again, there was a massive shift in demand for the network. Traditional content distributors were baffled by the love for this pay service that seemed to have benign content, but a large audience none the less. Unlike models that worked for pay-per view and traditional movie rentals, streamed from more traditional ISP systems, this demand was different. People behaved differently and the old world of sitting in front of the TV at defined times to consume movies was displaced by watching content on other devices at any time. This seemed to also spawn the new social act of binge watching. Around the same time tablets hit the market, and as the next few years rolled on, people started to consume streaming services on many devices and families began watching content in parallel, putting pressure on the network once again. So finally, we got it, nothing left to learn. Once again, not really.

We don’t need to climb back in our our DeLorean again since around the same time over in our Wireless networks we saw a different transition hit. Smartphones had displaced older phones that often used WAP and now people were using their phones for content. These were not ordinary phones either, they were smartphones which were driven by Apple’s push in 2007 with the first iPhone. The old saying of “how many T1s do we need for that cell tower” was no longer sufficient to address this insatiable demand for bandwidth. New technology had effectively allowed people to use the Wireless network for new functions which of course included content viewing. Once again, the race was on to upgrade the Radio Access Networks, Wireless core, transit uplinks, peering and other network services. Often older network designs did not cut it, and new topologies and designs needed to be rolled out to address the demand for network bandwidth.

What was the point of this stroll down memory lane? Coming back to 2020, the lesson is that we cannot reliably predict demand as well as we think we can because new demand is often based on new phenomenon which we cannot model before we are exposed to it. If I told you last January (2020) that the vast majority of office personnel were going to work from home and use video conferencing you would likely have challenged me. So, what can we do if we can’t predict new demand based on existing models? Well one way is to just accept that things will happen and we need to shift and respond to new phenomenon. But business leaders and designers can do something more. When we produce our network and system designs and network scaling plans, we should do so with an expectation that we may need to not just scale our infrastructure based on known models. We should understand how we would scale for models based on ‘what-if’ scenarios which look like 10x, 20x, 50x and even 100x of our current network and service infrastructure. Businesses may not have the funds to support an advanced build out of capacity; however, we should know how we will get there if we need to. Waiting for the next emergency to figure out how to scale outside of our known curve is a sure fire way of getting left behind by those who can respond.

Leaders need to run these what-if scenarios, understand what technical constraints may exist, what business constraints may need to be overcome, and what time scale needs to be factored into achieving such goals. It is possible that some of the blockers cannot be addressed with current technology, funding or workforce, but knowing what needs to be done can be very helpful. Perhaps even knowing how to address one or two challenges with others left for future solutions can still provide a head start when a sudden scaling crisis arrives. If leaders find that they cannot deal with such scenarios such as a 10-100x increase in demand, then a hard look at what we have built may be in order. Making design changes and producing processes to scale even under extreme multipliers is best done before the emergency is upon us.

So practically, what can get in your way? What should a leader be aware of? First, do the designs in place support scaling, even at one to two orders of magnitude? If not, does it require a clean sheet design or are changes sufficient to meet such needs? Second, do your vendors have equipment types that support such a large change in capacity? If you use your own hardware, you would ask yourself the same question. What would supply chain need to look like? Especially Should extra or new equipment be needed? If you need to leverage a new vendor, have you put in the needed work to onboard that to fit the provisioning, configuration, management and operational models? Is training needed, especially if it relates to new potential hardware or software if deployed. If massive expansion is needed, are power needs able to be satisfied? What about time to build? Labor is often a challenge, especially during periods of high demand. There are many other self reflecting questions one can ask within their organization, but the important point is that leadership ask these in advance, and understands what is needed to provide a reasonable answer to them.

What will drive your business may be unique to what you offer, it may be related to more global drivers and behaviors. Never assume we know what’s next because the Internet and the industry in general has a weird way of teaching us that we can’t predict the demand of the future. If you ask me what’s next? 5G will likely continue to unleash new types of demand that are unlocked by having rich bandwidth resources and new application options opened up. Depending on where you play in the industry, you will want to figure out what that means for your business. Cloud acceptance is also continuing to gain acceptance to CIOs and CTOs, many of which were weary of such migrations just a few years ago. This impacts scale and performance. Ask hard questions now, before the next demand shift occurs.

To explain why I used the Carmo Convent ruins picture above, which I took while in Lisbon a few years ago, is a way to highlight crisis and preparedness. The initial impact of the 1755 quake was devastating. However, the ensuing inability to deal with fires throughout the city and recognizing the receding waters meant a tsunami was coming had caused much more impact than necessary. We may not always be in a position to eliminate all impact, but preparedness can help us avoid additional impact which can be managed with the right foresight and planning.

Data Center routing simplicity with LSVR

By Victor Kuarsingh, Co-Chair of Link State Vector Routing (LSVR) group at the IETF


Data centers have continued to drive the focus of innovators and practitioners of data center builds. With the every growing need for more data center capacity for cloud offerings or enterprise data centers, the extended need to support both massive scale and maintainability have never been more important. Operators continue to face the ever present need to build infrastructure that scales, however, the ability to configure, maintain, troubleshoot and resolve runtime problems is just as important as that need to build.


One recent development in some large scale data center networks, is the focus on building generic and scalable fabrics based on CLOS fabrics. This type of underlay network allows for scaling of the data centers using battle tested and simple to apply principles. A nice outcome of this mode is that it can also assist in providing vendor independence for operators in addition to the achieve massive scale. Another decision made by some of these large data center builders is forcing simplicity into the protocol layer of the network fabric as well. The decision there has led to the wide use of BGP, and in some cases, no underlying IGP at all. It is this second aspect of the large scale data centers that is of interest.


Why? Well, for years, I recall many architecture and design level discussions seeking to add more capability into the network, helping add and improve functionality. We had IGPs working, overlay technologies such as MPLS/VPN, needed QoS, and pushed a raft of improvements into the relative protocols to help round it all out, and iron out issues we faced by forcing additional complexity into the network.


As we hit the 2010s, a shift was well underway were we pushed much of the complexity into the overlay network. This left the underlay network relatively untethered, providing an opportunity to simplify the design. Even more recent improvements, such as pushing overlay technology purely into the software realm has also led to much faster progression of overlay capabilities which detached it from the more cumbersome and slow process of upgrading and updating network hardware.


In the most extreme examples, one can find network underlays that run nothing more than a single routing protocol – BGP. That can be assisted by a way to manage the device such as SSH and NETCONF and provide needed neighbour discovery using LLDP. In that model, no IGP is needed or even desired, with the trade-off granted to simplicity. This very basic model does lose out on some capabilities that you get with an IGP, however, in the world of cloud, many of those capabilities aren’t really needed for the underlay and the larger goal of simplicity and stability are much more important than finesse and speed.


In this extreme example, because BGP was not originally intended for this lone purpose of routing just internal traffic with no underlying traditional IGP, we are left with a few gaps in efficiency. This is where Link-State Vector Routing (LSVR) comes in. What is LSVR? Well it is BGP with some modifications to update how routes are calculated. Anyone using BGP in its modes of operation would be quickly familiar with LSVR. From a confirmation and behavior perspective it is BGP. In that world, we continue to support the simplicity of what we get with running as few protocols as possible on the underlay network, but also gain the efficiency of vectored routing on the underlay normally supplied by a full fledged IGP. The objective is not to gain the same level of protocol efficiency as an IGP, but maintain the much more lucrative and hard to achieve goal of operational simplicity with added efficiency.


The fewer things that need to be configured, updated and maintained, the better off an operational environment will be. There are fewer things to put into configuration models, less hurdles in integrating multiple vendors (only one routing protocol) and less protocols needed to be secured and troubleshot. Another benefit of this approach is that is uses a familiar protocol like BGP which we need to use anyway for exterior routing. Teams can onboard this new functionality with little new complexities to learn outside of the architects of the organization which would often need and want to understand the nuts and bolts of any protocol. However, the vast majority of the operational teams can continue to use the same simple model with under-the-hood improvements that allow them to keep things simple. And simple, for operators – is really the most important goal as it leads to lower costs and stability.

What is LSVR?