01 · Operate
Network Automation
Topology as data, configuration as intent, model-driven interfaces, and validation as a required step—not an afterthought.
Nokia SR Linux
Containerlab
Ansible
YANG / gNMI
Engineering Focus
Three layers of the same control problem
Programmable networks, software prototypes, and future-network study look different on the surface. I connect them through practical questions about state, observation, failure, and evidence.
02 · Coordinate
Go Distributed Systems
Learning-oriented prototypes for APIs, service boundaries, replication, secure communication, messaging, persistence, and observability.
Go
gRPC
RabbitMQ
PostgreSQL
03 · Rethink
Future Networks
NDN/ICN reading, DTN implementation work, and controlled LEO/NTN emulation for moving or intermittently connected networks.
NDN / ICN
DTN
LEO / NTN
NetSatBench
Shared Method
What stays constant across the three tracks
- Make the system rebuildableTopologies, dependencies, configurations, and run steps should be explicit.
- Separate intent from mechanismThe desired outcome should not disappear inside transport-specific commands.
- Treat failure as behaviorTimeouts, partitions, invalid state, and recovery paths belong in the design.
- Validate with evidenceLogs, queries, metrics, packet behavior, and test output make claims reviewable.
- Explain the boundaryFinished work, reproduced work, current learning, and future plans should remain distinguishable.
Evidence Map
Where each focus appears on this site
| Focus | Project evidence | Knowledge evidence |
|---|---|---|
| Network automation | SR Linux labs, CCNP labs | Automation checklist |
| Go systems | Tolerex, Inventory API, Netreka Nexus | gRPC control-plane note |
| Future networks | DTN labs, NDN labs, NetSatBench guide | Research reading library |