diff --git a/slides/kube/kubenet.md b/slides/kube/kubenet.md
index 7c567584..0b8519dc 100644
--- a/slides/kube/kubenet.md
+++ b/slides/kube/kubenet.md
@@ -52,9 +52,9 @@
(15 are listed in the Kubernetes documentation)
-- It *looks like* you have a level 3 network, but it's only level 4
+- Pods have level 3 (IP) connectivity, but *services* are level 4
- (The spec requires UDP and TCP, but not port ranges or arbitrary IP packets)
+ (Services map to a single UDP or TCP port; no port ranges or arbitrary IP packets)
- `kube-proxy` is on the data path when connecting to a pod or container,
and it's not particularly fast (relies on userland proxying or iptables)
@@ -72,10 +72,32 @@
- Unless you:
- routinely saturate 10G network interfaces
-
- count packet rates in millions per second
-
- run high-traffic VOIP or gaming platforms
-
- do weird things that involve millions of simultaneous connections
(in which case you're already familiar with kernel tuning)
+
+- If necessary, there are alternatives to `kube-proxy`; e.g.
+ [`kube-router`](https://www.kube-router.io)
+
+---
+
+## The Container Network Interface (CNI)
+
+- The CNI has a well-defined [specification](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration) for network plugins
+
+- When a pod is created, Kubernetes delegates the network setup to CNI plugins
+
+- Typically, a CNI plugin will:
+
+ - allocate an IP address (by calling an IPAM plugin)
+
+ - add a network interface into the pod's network namespace
+
+ - configure the interface as well as required routes etc.
+
+- Using multiple plugins can be done with "meta-plugins" like CNI-Genie or Multus
+
+- Not all CNI plugins are equal
+
+ (e.g. they don't all implement network policies, which are required to isolate pods)