diff --git a/README.md b/README.md
index b6243d1f2..8ddc15655 100644
--- a/README.md
+++ b/README.md
@@ -20,7 +20,7 @@ Here's an illustration of the network interfaces attached to a pod, as provision
 
 ![multus-pod-image](doc/images/multus-pod-image.svg)
 
-## Quickstart Guide
+## Quickstart Installation Guide
 
 Multus may be deployed as a Daemonset, and is provided in this guide along with Flannel. Flannel is deployed as a pod-to-pod network that is used as our "default network" (a network interface that every pod will be created with). Each network attachment is made in addition to this default network.
 
@@ -32,7 +32,7 @@ We apply these files as such:
 $ cat ./images/{multus-daemonset.yml,flannel-daemonset.yml} | kubectl apply -f -
 ```
 
-This will configure your systems to be ready to use Multus CNI, but, to get started with adding additional interfaces to your pods, refer to our [usage guide](doc/how-to-use.md)
+This will configure your systems to be ready to use Multus CNI, but, to get started with adding additional interfaces to your pods, refer to our complete [quick-start guide](doc/quickstart.md)
 
 ## Additional installation Options
 
@@ -42,7 +42,8 @@ This will configure your systems to be ready to use Multus CNI, but, to get star
 - Or, roll-you-own and build from source
   - See [Development](doc/development.md)
 
-## Documentation
+## Comprehensive Documentation
+
 - [How to use](doc/how-to-use.md)
 - [Configuration](doc/configuration.md)
 - [Development](doc/development.md)
diff --git a/doc/how-to-use.md b/doc/how-to-use.md
index d502ad166..a41421442 100644
--- a/doc/how-to-use.md
+++ b/doc/how-to-use.md
@@ -1,41 +1,39 @@
 ## How to use multus-cni?
 
-### Prerequisite
+### Prerequisites
 
-Kubelet must be configured to run with the CNI network plugin. Please see [Kubernetes document for CNI](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni) for its detail.
+* Kubelet configured to use CNI 
+* Kubernetes version with CRD support (generally )
+
+Your Kubelet(s) must be configured to run with the CNI network plugin. Please see [Kubernetes document for CNI](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni) for more details.
 
 ### Install multus
 
-You could copy binary directory or could use daemonset yaml in multus repository.
+Generally we recommend two options: Manually place a Multus binary in your `/opt/cni/bin`, or use our [quick-start method](quickstart.md) -- which creates a daemonset that has an opinionated way of how to install & configure Multus CNI (recommended).
 
-- copy multus binary
+*Copy Multus Binary into place*
 
-    Copy multus binary into CNI binary directory, usually `/opt/cni/bin`.
+You may acquire the Multus binary via compilation (see the [developer guide](development.md)) or download the a binary from the [GitHub releases](https://github.com/intel/multus-cni/releases) page. Copy multus binary into CNI binary directory, usually `/opt/cni/bin`. Perform this on all nodes in your cluster (master and nodes).
 
-    ```
-    # Execute following commands at all Kubernetes nodes (i.e. master and minions)
     $ cp multus /opt/cni/bin
-    ```
 
-- use daemonset
+*Via Daemonset method*
 
-    As [Quickstart](https://github.com/intel/multus-cni/README.md#quickstart-guide), you could apply as such:
+As a [quickstart](quickstart.md), you may apply these YAML files (included in the clone of this repository). Run this command (typically you would run this on the master, or wherever you have access to the `kubectl` command to manage yoru cluster). 
 
-    ```
-    # Execute following command at Kubernetes master
     $ cat ./images/{multus-daemonset.yml,flannel-daemonset.yml} | kubectl apply -f -
-    ```
 
-    Then skip to following section and go to ['Create network attachment definition'](https://github.com/s1061123/multus-cni/blob/dev/update-readme/doc/how-to-use.md#create-network-attachment-definition)
+If you need more comprehensive detail, continue along with this guide, otherwise, you may wish to either [follow the quickstart guide]() or skip to the ['Create network attachment definition'](https://github.com/s1061123/multus-cni/blob/dev/update-readme/doc/how-to-use.md#create-network-attachment-definition) section.
 
-### Set up conf file in /etc/cni/net.d/ (daemonset automatically does)
+### Set up conf file in /etc/cni/net.d/ (Installed automatically by Daemonset)
 
 **If you use daemonset to install multus, skip this section and go to "Create network attachment"**
 
 You put CNI config file in `/etc/cni/net.d`. Kubernetes CNI runtime uses the alphabetically first file in the directory. (`"NOTE1"`, `"NOTE2"` are just comments, you can remove them at your configuration)
 
+Execute following commands at all Kubernetes nodes (i.e. master and minions)
+
 ```
-# Execute following commands at all Kubernetes nodes (i.e. master and minions)
 $ mkdir -p /etc/cni/net.d
 $ cat >/etc/cni/net.d/30-multus.conf <<EOF
 {
diff --git a/doc/quickstart.md b/doc/quickstart.md
new file mode 100644
index 000000000..43dd7da6d
--- /dev/null
+++ b/doc/quickstart.md
@@ -0,0 +1,174 @@
+# Quickstart Guide
+
+This guide is intended as a way to get you off the ground, and using Multus CNI to create Kubernetes pods with multiple interfaces. If you're already using Multus and need more detail, see the [comprehensive usage guide](how-to-use.md). This document a quickstart and a getting started guide in one, intended for your first run-through of Multus CNI.
+
+We'll first install Multus CNI, and then we'll setup some configurations so that you can see how multiple interfaces are created for pods.
+
+## Key Concepts
+
+Two things we'll refer to a number of times through this document are:
+
+* "Default network" -- This is your pod-to-pod network. This is how pods communicate among one another in your cluster, how they have connectivity. Generally speaking, this is presented as the interface named `eth0`. This interface is always attached to your pods, so that they can have connectivity among themselves. We'll add interfaces in addition to this.
+* "CRDs" -- Custom Resource Definitions. Custom Resources are a way that the Kubernetes API is extended. We use these here to store some information that Multus can ready. Primarily, we use these to store the configurations for each of the additional interfaces that are attached to your pods.
+
+## Installation
+
+Our recommended quickstart method to deploy Multus is to deploy using a Daemonset. This method is provided in this guide along with [Flannel](https://github.com/coreos/flannel). Flannel is deployed as a pod-to-pod network that is used as our "default network" -- this provides connectivity between pods in your cluster. Each additional network attachment (i.e. for multiple interfaces in pods) is made in addition to this default network. This guide generally assumes a new Kubernetes cluster that hasn't yet had any networking configured. If it's your first time using Multus, you might consider using a fresh cluster to learn with, and then later configure it to work with an existing cluster.
+
+Firstly, clone this GitHub repository. 
+
+```
+git clone https://github.com/intel/multus-cni.git && cd multus-cni
+```
+
+We'll apply files to `kubectl` from this repo. The files we're applying here specify a "Daemonset" (pods that run on each node in the cluster), this Daemonset handles installing the Multus CNI binary, dropping a default configuration on each node in the cluster -- and then also installs Flannel to use as a default network.
+
+```
+$ cat ./images/{multus-daemonset.yml,flannel-daemonset.yml} | kubectl apply -f -
+```
+
+### Validating your installation
+
+Generally, the first step in validating your installation is to look at the `STATUS` field of your nodes, you can check it out by looking at:
+
+```
+$ kubectl get nodes
+```
+
+This will show each of the nodes in your cluster, take a look at the `STATUS` field, and look for `Ready` to appear for each of your nodes. This readiness is determined by the presence of a CNI configuration file on each of the nodes, and when that file appears.
+
+You may also wish to start any pod in your cluster (without any further configuration), and validate that it works as you'd otherwise expect -- especially that it can communicate over the default network.
+
+## Creating additional interfaces
+
+The first thing we'll do is create configurations for each of the additional interfaces that we attach to pods. We'll do this by creating Custom Resources. Part of the quickstart installation creates a "CRD" -- a custom resource definition that is the home where we keep these custom resources -- we'll store our configurations for each interface in these.
+
+### CNI Configurations
+
+Each configuration we'll add is a CNI configuration. If you're not familiar with them, let's break them down quickly. Here's an example CNI configuration:
+
+```
+{
+  "cniVersion": "0.3.0",
+  "type": "loopback",
+  "additional": "information"
+}
+```
+
+CNI configurations are JSON, and we have a structure here that has a few things we're interested in:
+
+1. `cniVersion`: Tells each CNI plugin which version is being used and can give the plugin information if it's using a too late (or too early) version.
+2. `type`: This tells CNI which binary to call on disk. Each CNI plugin is a binary that's called. Typically, these binaries are stored in `/opt/cni/bin` on each node, and CNI executes this binary. In this case we've specified the `loopback` binary (which create a loopback-type network interface).
+3. `additional`: This field is put here as an example, each CNI plugin can specify whatever configuration parameters they'd like in JSON. These are specific to the binary you're calling in the `type` field.
+
+For an even further example -- take a look at the [bridge CNI plugin README](https://github.com/containernetworking/plugins/tree/master/plugins/main/bridge) which shows additional
+
+If you'd like more information about CNI configuration, you can read [the entire CNI specification](https://github.com/containernetworking/cni/blob/master/SPEC.md). It might also be useful to look at the [CNI reference plugins](https://github.com/containernetworking/plugins) and see how they're configured.
+
+### Storing a configuration as a Custom Resource
+
+So, we want to create an additional interface. Let's create a macvlan interface for pods to use. We'll create a custom resource that defines the CNI configuration for interfaces.
+
+Note in the following command that there's a `kind: NetworkAttachmentDefinition`. This is our fancy name for our configuration -- it's a custom extension of Kubernetes that defines how we attach networks to our pods. 
+
+Secondarily, note the `config` field. You'll see that this is a CNI configuration just like we explained earlier.
+
+Lastly but *very* importantly, note under `metadata` the `name` field -- here's where we give this configuration a name, and it's how we tell pods to use this configuration. The name here is `macvlan-conf` -- as we're creating a configuration for macvlan.
+
+Here's the command to create this example configuration:
+
+```
+cat <<EOF | kubectl create -f -
+apiVersion: "k8s.cni.cncf.io/v1"
+kind: NetworkAttachmentDefinition
+metadata:
+  name: macvlan-conf
+spec:
+  config: '{
+      "cniVersion": "0.3.0",
+      "type": "macvlan",
+      "master": "eth0",
+      "mode": "bridge",
+      "ipam": {
+        "type": "host-local",
+        "subnet": "192.168.1.0/24",
+        "rangeStart": "192.168.1.200",
+        "rangeEnd": "192.168.1.216",
+        "routes": [
+          { "dst": "0.0.0.0/0" }
+        ],
+        "gateway": "192.168.1.1"
+      }
+    }'
+EOF
+```
+
+You can see which configurations you've created using `kubectl` here's how you can do that:
+
+```
+kubectl get network-attachment-definitions
+```
+
+You can get more detail by describing them:
+
+```
+kubectl describe network-attachment-definitions macvlan-conf
+```
+
+### Creating a pod that attaches an additional interface
+
+We're going to create a pod. This will look familiar as any pod you might have created before, but, we'll have a special `annotations` field -- in this case we'll have an annotation called `k8s.v1.cni.cncf.io/networks`. This field takes a comma delimited list of the names of your `NetworkAttachmentDefinition`s as we created above. Note in the comand below that we have the annotation of `k8s.v1.cni.cncf.io/networks: macvlan-conf` where `macvlan-conf` is the name we used above when we created our configuration.
+
+Let's go ahead and create a pod (that just sleeps for a really long time) with this command:
+
+```
+cat <<EOF | kubectl create -f -
+apiVersion: v1
+kind: Pod
+metadata:
+  name: samplepod
+  annotations:
+    k8s.v1.cni.cncf.io/networks: macvlan-conf
+spec:
+  containers:
+  - name: samplepod
+    command: ["/bin/bash", "-c", "sleep 2000000000000"]
+    image: dougbtv/centos-network
+EOF
+```
+
+You may now inspect the pod and see what interfaces interfaces are attached, like so:
+
+```
+$ kubectl exec -it samplepod -- ip a
+```
+
+You should note that there's 3 interfaces:
+
+* `lo` a loopback interface
+* `eth0` our default network
+* `net1` the new interface we created with the macvlan configuration.
+
+### What if I want more interfaces?
+
+You can add more interfaces to a pod by creating more custom resources and then referring to them in pod's annotation. You can also reuse configurations, so for example, to attach two macvlan interfaces to a pod, you could create a pod like so:
+
+```
+cat <<EOF | kubectl create -f -
+apiVersion: v1
+kind: Pod
+metadata:
+  name: samplepod
+  annotations:
+    k8s.v1.cni.cncf.io/networks: macvlan-conf,macvlan-conf
+spec:
+  containers:
+  - name: samplepod
+    command: ["/bin/bash", "-c", "sleep 2000000000000"]
+    image: dougbtv/centos-network
+EOF
+```
+
+Note that the annotation now reads `k8s.v1.cni.cncf.io/networks: macvlan-conf,macvlan-conf`. Where we have the same configuration used twice, separated by a comma. 
+
+If you were to create another custom resource with the name `foo` you could use that such as: `k8s.v1.cni.cncf.io/networks: foo,macvlan-conf`, and use any number of attachments.
\ No newline at end of file