• in naf3
  • 3 min read
Draft

NAF3 Day 1

Claudia De Luna

"In the beginning network was a bottleneck." -> "Networking has been slow to embrace automation." Consider centralized control vs Decentralized ('box by box')

"Controller based architecture never really took off with the network. Networking has been slow to embrace automation."

The challenge.

Why is automation the right solution for networking? "In retrospect, DevOps was a bad idea" - Adam Ard. Meant that it went a bit too far as one specific thing. "Small N, small A" network automation is better.

What we've really been talking about this whole time is actually software development.

"never asking the right questions." EG Marcus Aurelius quote:

"what is it in itself? what is its nature what does [it] do?" Legacy? Multi-vendor? Cloud?

The dirty word: Requirements.

Claudia started off in software development in NASA's Jet Propulsion Lab. Then moved to networking. Boss asks about structured cabling and tasks Claudio with learning it. Presents about it to Mission Managers (of missions to other planets.) Talking about putting structured cabling into the campus. Dick Matheson, revered and feared.

Prior to this, every mission ran their own infrastructure. IT WAS ADDITIVE!!!

Claudio presents a proposed labeling standard. Dick Matheson approves of it.

At that time requirements gathering was considered busywork, or just something to get through.

Our current Focus.

Operations: Source of truth, learning python, tools.

Operations is important

but not at the expense of design. No perspective from the trench. You are just trying to stay alive. But this still happens frequently.

Started in the middle.

Disorientation, ambiguous goals, ambiguous success, partial solutions, bad behavior, tortured paths. Overdevelopment of some muscles at the expense of others. Some (dick matheson) would say this is because we do not have requirements.

The Full landscape is emerging.

Begin at the beginning.

The end-to-end process. This is a pipeline that is hard to fill. Tools will not solve the problem. They may solve 1 problem. Tools are just exercise equipment, you still must do the work. This is probably why we gloss over it. This is probably why we can't articulate a framework. WE HAVE TO USE THE TOOLS CORRECTLY.

What if:

We lived in a world where we started with design. Would the truth be ambiguous? That world is already here. The tooling is here but you can start without it.

The source of truth struggle: If our process began with the details of what we were building, would truth be such a struggle?

Delivery -> Operations chasm. Operations asks about things not even on the design team's radar.

Start with the budget cycle.

Begin by asking the right questions.

  1. What problem are we trying to solve?
  2. How will this product or service help solve the problem?
  3. Who is going to implement the solution?
  4. How are we going to support the solution?

Does this project need a professional software developer? Usually yes.

Now we have the 'complete pipeline' design -> documentation -> switches aps installed. Handed over to operations, observation and monitoring validates the design data.

When the teams seperated, originally no one could join design without spending at least 1 month in operations.

New beginning: our 4 key questions.

  • Requirements
  • Leadership
  • Resources: Who is building it? "amateur" or professional? No wrong answer, but needs to be thought through.
  • Support

Beginnings are hard but you just need the first step. "Movement is life"

Distractions:

  • Why should I care? Is this getting me closer to the finish line? "we live in a world comprised almost entirely of distractions". How do we avoid them.

Autocon

This community is positioned to help with some tough decisions. Lets not forget about people just starting out, and we need to help those people.

Time to differentiate:

  • Personal productivity and skills
  • service delivery
  • net eng
  • software developer

It's good to recognize what you are good at and get someone to help with the rest.

Periodic Remote LLM Sources and LBS RAG

This week, as a follow-up to Remote LLM RAG this post, I have been working on additional RAG (Retrieval Augmented Generation) functionality for the rXg's built in LLM solution. This includes 2 components:

  1. LBS (Location Based Services): The rXg is now able to inform the user about what is near them.
  2. Periodic Sync of Remote LLM Sources: The rXg can now re-download remote LLM Sources, akin to redownloading config templates or content filter lists.

Remote LLM RAG

Recently my boss gave me an interesting challenge: Make our LLM (Large Language Model) system smarter by giving it access to remote data feeds.

LLMs are very good at knowing about events that are in their training data. But they are not able to know about new information.

RAG (Retrieval Augmented Generation) is a technique of finding contextually relevant data, based on the users' query and including it in the context sent to the LLM, so that the LLM can forumulate an up-to-date response, or a response that is informed by data beyond its training data.

Flight Gate Example

Continue reading for a concise explaination of how to accomplish this magic...

  • in CISSP
  • 1 min read

CISSP

Today I passed the CISSP on the 100th question. I used a combination of these resources to study intensively for about a month. As I went along, I also did spot-research whenever I felt like there was a gap in my knowledge. In general I found the different policy frameworks the most novel-to-me, so I focused on them a little extra compared the networking / PKI / Software Engineering topics.

  1. Syngress CISSP Study Guide 4th Edition (Eric Conrad/Seth Misenar/Joshua Feldman) (Read about the first 75% of it, worked through the test questions)
  2. "50 Hard CISSP Questions" Video
  3. Pocket Prep App ($20/month)
  4. Destination Certification CISSP Mindmap Youtube Series I watched the first 5 domains or so before the exam, skipping the OSI one because we work with that one a lot already at RG Nets

Config Templates

A High Level Source of Truth for your Configuration

Config templates are a powerful way of encoding business logic in a clear and concise way so that it can be applied programmatically to the rXg. These are just my notes about some features, for official documentation please see Config Templates

In my opinion, true mastery of config templates comes from combining 3 things.

  1. A mastery of how config templates work syntactically 1.1 ERB Expansion 1.2 YAML Ingestion

  2. A wide understanding of the vocabulary of what can be configured via config templates, ie all the scaffolds.

  3. The ability combine the first 2 within the context of a particular deployment or operational plan

For the teaching I am going to focus primarily on #1 because that is something that can reasonably be learned in one blog post or short teaching session.

A single template could configure everything an rXg needs from layer 1 to layer 7. For example, here are just some things that can be configured by a config template:

TxBF vs OFDMA

In the past, Transmit Beamforming (TxBF) was a very powerful way to deliver quality service to 802.11 clients in noisy environments. TxBF uses RF properties to "steer" RF transmission at where the transmitter believes the receiver to be.

Telemetry, Automation and Source of Truth

A couple weeks ago I listened to a couple of Heavy Networking podcasts, HN713 and HN717. Here are some of my reflections on what I absorbed from these podcasts and how I applied this knowledge to my work this week at RG Nets.

Recent updates

  • Passed CompTia Security+
  • Began working on a new exciting PMS integration opportunity
  • Worked on more Telemetry stuff, including developing my presentation for WLPC