Final edits (#165)

* Final instructions tidying

* Instructions

* Add final slides

README.md

@@ -16,13 +16,16 @@ you get started with P4 programming, organized into several modules:
 * [Explicit Congestion Notification](./exercises/ecn)
 * [Multi-Hop Route Inspection](./exercises/mri)
 
-4. Advanced Data Structures
+4. Advanced Behavior
 * [Source Routing](./exercises/source_routing)
 * [Calculator](./exercises/calc)
-
-5. Dynamic Behavior
 * [Load Balancing](./exercises/load_balance)
 
+## Presentation 
+
+The slides are available [online](http://bit.ly/p4d2-2018-spring) and
+in the P4_tutorial.pdf in the tutorial directory.
+        
 ## Obtaining required software
 
 If you are starting this tutorial at the Spring 2018 P4 Developer Day,

exercises/ecn/README.md

@@ -165,7 +165,7 @@ There are several ways that problems might manifest:
    error emitted from the compiler and stop.
 2. `ecn.p4` compiles but does not support the control plane rules in
    the `sX-runtime.json` files that `make` tries to install using
-   the BMv2 CLI.  In this case, `make` will log the CLI tool output 
+   a Python controller. In this case, `make` will log the controller output 
    in the `logs` directory. Use these error messages to fix your `ecn.p4`
    implementation.
 3. `ecn.p4` compiles, and the control plane rules are installed, but

exercises/load_balance/README.md

@@ -4,10 +4,10 @@ In this exercise, you will implement a form of load balancing based on
 a simple version of Equal-Cost Multipath Forwarding. The switch you
 will implement will use two tables to forward packets to one of two
 destination hosts at random. The first table will use a hash function
-(applied to a 5-tuple consisting of the source and destination 
+(applied to a 5-tuple consisting of the source and destination IP
-IP addresses, IP protocol, and source and destination TCP ports) 
+addresses, IP protocol, and source and destination TCP ports) to
-to select one of two hosts. The second table will use the
+select one of two hosts. The second table will use the computed hash
-computed hash value to forward the packet to the selected host.
+value to forward the packet to the selected host.
 
 > **Spoiler alert:** There is a reference solution in the `solution`
 > sub-directory. Feel free to compare your implementation to the
@@ -63,16 +63,9 @@ control plane.  When a rule matches a packet, its action is invoked
 with parameters supplied by the control plane as part of the rule.
 
 In this exercise, the control plane logic has already been
-implemented.  As part of bringing up the Mininet instance, the
+implemented.  As part of bringing up the Mininet instance, the `make`
-`make` script will install packet-processing rules in the tables of
+script will install packet-processing rules in the tables of each
-each switch.  These are defined in the `s1-commands.txt` file.
+switch. These are defined in the `sX-runtime.json` files.
-
-**Important:** A P4 program also defines the interface between the
-switch pipeline and control plane. The `s1-commands.txt` file contains
-a list of commands for the BMv2 switch API. These commands refer to
-specific tables, keys, and actions by name, and any changes in the P4
-program that add or rename tables, keys, or actions will need to be
-reflected in these command files.
 
 ## Step 2: Implement Load Balancing
 
@@ -105,9 +98,6 @@ Follow the instructions from Step 1.  This time, your message from
 `h1` should be delivered to `h2` or `h3`. If you send several
 messages, some should be received by each server.
 
-### Food for thought
-
-
 ### Troubleshooting
 
 There are several ways that problems might manifest:
@@ -116,10 +106,10 @@ There are several ways that problems might manifest:
 report the error emitted from the compiler and stop.
 
 2. `load_balance.p4` compiles but does not support the control plane
-rules in the `sX-commands.txt` files that `make` tries to install
+rules in the `sX-runtime.json` files that `make` tries to install
-using the BMv2 CLI.  In this case, `make` will log the CLI tool output
+using the Python controller.  In this case, `make` will log the
-in the `logs` directory. Use these error messages to fix your `load_balance.p4`
+controller output in the `logs` directory. Use the error messages to
-implementation.
+fix your `load_balance.p4` implementation.
 
 3. `load_balance.p4` compiles, and the control plane rules are
 installed, but the switch does not process packets in the desired way.
@@ -139,4 +129,4 @@ mn -c
 
 ## Next Steps
 
-Congratulations, your implementation works! 
+Congratulations, your implementation works and you have finished the tutorial!

exercises/mri/README.md

@@ -210,22 +210,26 @@ got a packet
 There are several ways that problems might manifest:
 
 1. `mri.p4` fails to compile. In this case, `make` will report the
-error emitted from the compiler and stop.
+   error emitted from the compiler and stop.
+
 2. `mri.p4` compiles but does not support the control plane rules in
-the `sX-runtime.json` files that `make` tries to install using the BMv2 CLI.
+   the `sX-runtime.json` files that `make` tries to install using a
-In this case, `make` will log the CLI tool output in the `logs` directory.
+   Python controller. In this case, `make` will log the controller
-Use these error messages to fix your `mri.p4` implementation.
+   output in the `logs` directory.  Use these error messages to fix
+   your `mri.p4` implementation.
+
 3. `mri.p4` compiles, and the control plane rules are installed, but
-the switch does not process packets in the desired way. The
+   the switch does not process packets in the desired way. The
-`/tmp/p4s.<switch-name>.log` files contain trace messages describing
+   `/tmp/p4s.<switch-name>.log` files contain trace messages
-how each switch processes each packet. The output is detailed and can
+   describing how each switch processes each packet. The output is
-help pinpoint logic errors in your implementation.  The
+   detailed and can help pinpoint logic errors in your implementation.
-`build/<switch-name>-<interface-name>.pcap` also contains the pcap of
+   The `build/<switch-name>-<interface-name>.pcap` also contains the
-packets on each interface. Use `tcpdump -r <filename> -xxx` to print
+   pcap of packets on each interface. Use `tcpdump -r <filename> -xxx`
-the hexdump of the packets.
+   to print the hexdump of the packets.
+
 4. `mri.p4` compiles and all rules are installed. Packets go through
-and the logs show that the queue length is always 0.  Then either
+    and the logs show that the queue length is always 0.  Then either
-reduce the link bandwidth in `topology.json`.
+    reduce the link bandwidth in `topology.json`.
 
 #### Cleaning up Mininet
 
@@ -241,4 +245,3 @@ make stop
 
 Congratulations, your implementation works! Move on to [Source
 Routing](../source_routing).
-

exercises/source_routing/README.md

@@ -13,8 +13,8 @@ to the specified port number.
 Your switch must parse the source routing stack. Each item has a bos
 (bottom of stack) bit and a port number. The bos bit is 1 only for the
 last entry of stack.  Then at ingress, it should pop an entry from the
-stack and set the egress port accordingly.  Note that the last hop can
+stack and set the egress port accordingly. The last hop may also
-also revert back the etherType to `TYPE_IPV4`.
+revert back the etherType to `TYPE_IPV4`.
 
 > **Spoiler alert:** There is a reference solution in the `solution`
 > sub-directory. Feel free to compare your implementation to the