fixed spelling

Author: Larry Peterson

arch.rst

@@ -30,12 +30,9 @@ An overview of the software stack is given in :numref:`Figure %s
 *Control Applications*. :numref:`Figure %s <fig-stack>` also calls out
 a corresponding set of exemplar open source components (*Trellis*,
 *ONOS*, and *Stratum*) on the right, as well as a related *P4
-Toolchain* on the left.\ [#]_ This chapter introduces these components, with
+Toolchain* on the left. This chapter introduces these components, with
 later chapters giving more detail.
 
-.. [#] We sometimes call this the **TOST** stack: **T**\rellis running
-	on **O**\NOS running on **S**\tratum running on **T**\ofino.
-
 Note the similarity between this diagram and :numref:`Figure %s
 <fig-market2>` in Chapter 1. Both figures include two open
 interfaces: one between the Control Apps and the Network OS, and a
@@ -95,7 +92,7 @@ Virtual Machines (VMs).
     the end hosts and the Virtual Machines (VMs) they host.
 
 This perspective highlights two important aspects of the system. The
-first re-enforces the point we’ve been making: that the Network OS
+first re-enforces the point we've been making: that the Network OS
 (e.g., ONOS) is network-wide, while the Switch OS (e.g., Stratum) is
 per-switch.
 

authors.rst

@@ -29,7 +29,7 @@ received a BS and MS in Computer Science from Stanford Univesity in
 2012 and 2013, respectively.
 
 **Thomas Vachuska** is Chief Architect at the Open Networking
-Forundation (ONF), where he leads the ONOS project. Before joining ONF,
+Foundation (ONF), where he leads the ONOS project. Before joining ONF,
 Vachuska was a Software Architect at Hewlett-Packard. Vachuska
 received a BA in Mathematics from California State
 University-Sacramento in 1994.

foreword.rst

@@ -47,7 +47,7 @@ This book explains why the SDN movement happened. It was essentially
 about a change in control: the owners and operators of big networks
 took control of how their networks work, grabbing the keys to
 innovation from the equipment vendors. It started with data center
-companies because they couldn’t build big-enough scale-out networks
+companies because they couldn't build big-enough scale-out networks
 using off-the-shelf networking equipment. So they bought switching
 chips and wrote the software themselves. Yes, it saved them money
 (often reducing the cost by a factor of five or more), but it was

future.rst

@@ -66,7 +66,7 @@ measurement, code generation, and verification elements needed for
 verifiable closed-loop control. Fine-grained measurements can be
 implemented using INT (Inband Network Telemetry), which allows every
 packet to be stamped by the forwarding elements to indicate the path
-it took, the queueing delay it experienced, and the rules it matched.
+it took, the queuing delay it experienced, and the rules it matched.
 These measurements can then be analyzed and fed back into code
 generation and formal verification tools. This closed loop complements
 the intrinsic value of disaggregation, which makes it possible to

intro.rst

@@ -201,7 +201,7 @@ Information Base (FIB)*, as depicted in :numref:`Figure %s <fig-fib>`.
 
 There is no controversy about the value of decoupling the network
 control and data planes. It is a well-established practice in
-networking, where closed/proprietary routers that pre-date SDN adopted
+networking, where closed/proprietary routers that predate SDN adopted
 this level of modularity. But the first principle of SDN is that the
 interface between the control and data planes should be both
 well-defined and open. This strong level of modularity is often
@@ -601,7 +601,7 @@ The first problem was that as SDN matured from a research experiment
 to a viable alternative to legacy, proprietary switches, performance
 became increasingly important. And while flow rules were general
 enough to say what forwarding behavior the controller wanted to
-program into a switch, switches didn’t necessarily have the capacity
+program into a switch, switches didn't necessarily have the capacity
 to implement that functionality in an efficient way. To ensure high
 forwarding performance, flow tables were implemented using highly
 optimized data structures that required specialized memories, like

stratum.rst

@@ -36,7 +36,7 @@ bare-metal switch. The details are drawn from Stratum, an open source
 project at the ONF that started with production-quality code made
 available by Google. :numref:`Figure %s <fig-stratum>` gives a
 high-level overview of Stratum, and to re-emphasize, it’s the exposed
-interfaces—P4Runtime, gNMI, and gNOI—that are the important take-aways
+interfaces—P4Runtime, gNMI, and gNOI—that are the important takeaways
 of this chapter. We show these few implementation details in this
 section only as a way of grounding the description of an end-to-end
 workflow for developers implementing SDN-based solutions.
@@ -369,7 +369,7 @@ platform variables (of which the switch’s fan speed is everyone’s
 favorite example).
 
 We conclude this section by briefly turning our attention to gNOI, but
-there isn’t a lot to say. This is because the underlying mechanism
+there isn't a lot to say. This is because the underlying mechanism
 used by gNOI is exactly the same as for gNMI, and in the larger scheme
 of things, there is little difference between a switch’s configuration
 interface and its operations interface. Generally speaking, persistent

switch.rst

@@ -403,7 +403,7 @@ common/non-differentiating features (e.g., simple match-action tables
 or a P4 extern to count packets)? Do I want the P4 program I develop
 to be public on GitHub?
 
-As for that forwarding program (which we’ve been generically referring
+As for that forwarding program (which we've been generically referring
 to as ``forward.p4``), an interesting tangible example is a program
 that faithfully implements all the features that a conventional L2/L3
 switch supports. Let’s call that program ``switch.p4``.\ [#]_ Strangely
@@ -456,7 +456,7 @@ control apps without regard to the specific details of the device
 forwarding pipeline. Introducing the P4 architecture model helps meet
 this goal, as it enables portability of the same forwarding pipeline
 (P4 program) across multiple targets (switching chips) that support
-the corresponding architecture model. However, it doesn’t totally
+the corresponding architecture model. However, it doesn't totally
 solve the problem because the industry is still free to define
 multiple forwarding pipelines. But looking beyond the current
 state-of-affairs, having one or more programmable switches opens the
@@ -595,7 +595,7 @@ core P4 language types, where their definitions can be found in
 example, PSA also defines ``range`` and ``selector`` matches.
 
 The final step of the ingress routine is to “apply” the table we just
-defined. This is done only if the parser (or previous pipeline strage)
+defined. This is done only if the parser (or previous pipeline stage)
 marked the IP header as valid.
 
 .. literalinclude:: code/ingress.p4
@@ -722,8 +722,8 @@ running a common SDN software stack. This can be accomplished by
 hiding both types of chips behind the ``v1model.p4`` (or similar)
 architecture model, and letting the P4 compiler output the backend
 code understood by their respective SDKs. Obviously this scenario
-doesn’t work for an arbitrary P4 program that wants to do something
-that the Tomahawk chip doesn’t support, but it will work for standard
+doesn't work for an arbitrary P4 program that wants to do something
+that the Tomahawk chip doesn't support, but it will work for standard
 L2/L3 switch behavior.
 
 4.5.2 SAI