Service Priorities

These are thoughts on what we prioritize or value for the Wi-Fi service specifically. This is not the core values set in the IT Strategic Plan, but is (in part) an extension of them, as it applies to specifically the Wi-Fi service. This is closely related to the AUAs, but is more general / broadly scoped in nature.

Key insights

  • Our users set the expectations for the service.
  • Our priorities are defined by the expectations.
  • The priorities drive the features and properties of the system.
  • All of this is constrained and guided by our core values.

What this looks like for Wi-Fi

Expectations

  1. Ubiquitous and seamless coverage
  2. Reliable access
  3. High bandwidth
  4. Reasonable latency

Priorities

  1. Robust
    1. Systems stay up
    2. Systems continue to provide service when they are up
    3. Systems are fault tolerant
    4. Debugable
  2. Flexible
    1. Well understood and solved problems should be solved out of the box
    2. The system should easily accommodate new ideas or deployments not considered by the vendor.
  3. Secure
  4. Coherent architecture

Properties

User end

  1. Frictionless access
  2. Latest standards
  3. Dual stacked now
  4. Single stack IPv6 limitations are external

Administrator end

  1. Fault tolerant
    1. Hardware should be able to fail without impacting users
    2. Replacing hardware should be low risk and (relatively) low effort
  2. API driven
    1. Complete
    2. Idempotent
  3. Single stacked IPv6
    1. IPv6 Addresses are not strings
  4. Fixing one part of the system should not depend another part of the system
  5. Centralized (or perhaps intent based) config (within what is allowed due to above)
  6. Integrated monitoring
  7. Observable
    1. Is the system itself healthy?
    2. What is the user facing status?
    3. Do I have the tools to see what is going on under the covers?
    4. Do I have tools to identify an unknown unknown problem?
  8. Configuration that is difficult (preferably impossible) to get out of sync.
  9. (Flexible)
    1. Sane defaults
    2. Extensive options
    3. Building-block config
    4. Clear and consistent mental model to the config
  10. Split control plane and data plane
  11. OOB access
  12. Key/cert based access
  13. Idempotent API/Config
  14. Auditable config
  15. Usable config system
  16. Easily spun up
    1. Lab purposes
    2. Ransomware recovery
  17. Life cycle
    1. Replacing hardware
    2. Hardware available
    3. Can the vendor do business?
      1. Is the vendor able to ship hardware?
      2. Can the vendor tell us how much we owe in support (in a reasonable time frame)?
      3. Can we predict how much we owe and what items we need?

Other notes / questions

  1. Ask for a packet walkthrough

See also